informa-tion, usually based on the individual, entered or accepted by healthcare providers, which can be distributed over a number of sites or aggregated at a particular source.
The information is organised primarily to support continuing, efficient and quality healthcare. The record is under the control of the consumer and is stored and trans-mitted securely.” Any EHR system providing the above function should ideally maintain future-proof recorded information2. The system should be built up of future-proof software and guarantee system interoperability at domain know-ledge level. However, health information is characterised by huge volumes of domain concepts, for example, as numerous as 350,000 terms in SNOMED
Archetypes, GEHR, openEHR and Electronic Health Records
Ping Yu
School of Information Technology and Computer Science, The University of Wollongong, Australia.
ABSTRACT
HealthConnect, the proposed National Health Information Network for Australia (HINA), has centred the activity of health informatics in Australia around the establishment of a national electronic health record (EHR). In Australia, Good Electronic Health Record (GEHR), openEHR and their two level modelling and archetype approach are well regarded by ex-perts on electronic health records. The two level modelling and archetype approach is a significant innovation in health information system design. The intention of adopting arche-types to empower domain experts to take the responsibility for domain knowledge model-ling and updating is an important concept. The technology offers the promise of bridging the knowledge and skill base of both software developers and domain experts to achieve the goal of building a ‘future-proof’ electronic health record system. This gives promise for the construction of a user-centred health information system. Several projects have been sponsored by the Australian government to develop and test the technology. This article briefly reviews the initiation, development and current status of EHRs, archetypes and two level modelling technology. Issues of concern in archetype implementation are addressed and the direction for the development of openEHR is recommended.
Yu
370 The Journal on Information Technology in Healthcare 2003; 1(5): 369–380
(Systematized Nomenclature of Medicine). The building blocks for EHR systems, such as domain knowledge, software and hardware technology are all subject to constant, rapid change with continuous introduction of new health concepts, treatment methodology and technology2. In response to the dynamic and compli-cated challenge of both domain knowledge and the information systems that carry and manipulate the knowledge, two Australian health informatics model-ling experts, Thomas Beale and Sam Heard, proposed a new concept ‘archetype’
and ‘two level modelling’ technology for EHR development. This two level model-ling technology has been successfully implemented in two General Practice Computing Group (GPCG) funded projects: GP systems to GEHR transforma-tion trial (GP to GEHR) and the OACIS-GEHR transformatransforma-tion project3.
This paper will briefly review the concepts of two level modelling, archetypes, GEHR and openEHR. The applicability of the technology in the current health information arena is discussed. Directions for the future development of openEHR and archetypes are recommended.
THE TWO LEVEL MODELLING AND REFERENCE MODEL
According to Beale et al.4, information is statements about specific entities. Know-ledge is statements that apply to all entities of a class. The separation of information from domain knowledge is achieved through the use of two models:
• A reference model • An archetype model5
Archetypes are used as part of a two level modelling methodology that aims to separate domain information from domain knowledge4. Systems are built from information models only and driven at runtime by knowledge-level concept defi-nitions or “archetypes”6. The reference model comprises non-volatile concepts that apply across the entire domain4. It is the framework for building the informa-tion system. For example, the EHR Reference Model4, which is the building block for openEHR, has classes such as:
• EHR – Consists of Folders and Transactions.
• Folder – High-level organisation of the EHR, e.g. per episode, per clinical speciality7, etc.
• Transaction – Data from a particular clinical event (event transactions), or particular categories of clinical data that have long-lived significance, e.g.
family history (persistent transactions).
• Organiser – Similar to a heading in a document. Consists of Organisers and Entries.
• Entry – Clinical “statements” about Observations, Evaluations, and In-structions7. It contains data structures (such as lists and tables) and data items (such as strings, booleans and codes from classification schemes).
The outer structure of an archetype is as follows4:
Archetypes, GEHR, openEHR and Electronic Health Records
The Journal on Information Technology in Healthcare 2003; 1(5): 369–380 371 • Header_part – archetype identification, meta-data
• Body_part – archetype definition
• Terminology_part – terminology definitions and binding
To explain the concept of archetypes, Schloeffel8 has used an analogy with language. Sentences are created using words from a dictionary and according to grammatical rules. Archetypes are the rules for constructing meaningful sen-tences. Without such rules, we can construct an infinite number of grammatically correct but meaningless sentences e.g. ‘My English feels hungry’ or ‘Good food eats well’8.
ARCHETYPES
Archetypes are defined as “domain concepts, expressed using constraints on instance structures of an underlying reference model”5. Archetypes are basically constraints.
They are, in simple terms, a set of rules that dictate how elements of the reference model can be organised into a meaningful form, and values that instances of the element can take. The purpose of an archetype approach is to let domain experts create and modify archetypes without the involvement of IT experts. The seman-tics of archetypes are defined in an archetype model corresponding to the reference model. According to Beale5, an unlimited number of archetypes can be derived from the archetype model. Each archetype should describe a distinct, complete clinical concept in an ontological space.
Bird et al.9 gave examples of a range of archetypes that could be used to constrain instances of the EHR Reference Model:
• Transaction level archetypes, such as patient contact, health summary and care plan
• Organiser (or document heading) level archetypes, such as problem lists, family history lists and discharge summary headings
• The archetype model may define that an observational content item owns a list of values
• Content item level archetypes, such as blood pressure, biochemistry and audiology test result
Figure 1 gives an example of a blood pressure archetype. Systolic and diastolic blood pressure are specialised types of general class blood pressure5. The first value in the “Proposition” list is “Systolic”. The value must be of type, quantity, with units
“mmHg”. The minimum value is 40, and the maximum value is 300. The second value in the “Proposition” list is “Diastolic”. The value must be of type, quantity, with units “mmHg”. The minimum value is 40, and the maximum value is 300.
Archetypes should have a formal, well-defined internal addressing mechanism that allows intelligent querying. Relationships between archetypes can be depend-ent on composition or specialisation, similar to that in an object-oridepend-ented approach7. Archetypes can be updated and revised.
Yu
372 The Journal on Information Technology in Healthcare 2003; 1(5): 369–380
GEHR AND OPENEHR
Good European Health Record (GEHR) was a three year project started in 1991, funded by the European Union’s Advanced Informatics in Medicine (AIM) initiative10. The GEHR consortium comprised 21 participating organisations in eight European countries. The project delivered a large body of work, including a comprehensive EHR architecture. It has significantly influenced the develop-ment of European standards. In 1998 Good European Health Record (GEHR) was renamed as the Good Electronic Health Record (GEHR). Two of the par-ticipants in the original GEHR project (Sam Heard and Thomas Beale) subsequently working on the development of EHRs in Australia proposed the concept of two level modelling, and the use of archetypes to separate informa-tion and knowledge4.
In 1999 the openEHR Foundation was established between Australian and European teams to encourage harmonisation and collaboration11. This has led to active development of standards for an electronic health record throughout Eu-rope and Australia. In 2002, the openEHR foundation began revising the GEHR model. The majority of concepts remain unchanged, but the GEHR is now re-ferred to as the openEHR model. The openEHR, therefore, actually originated from the Good Electronic Health Record11.
OPENEHR IN AUSTRALIA
In 1997, the IBM Consulting Group was contracted by the Commonwealth De-partment of Health and Family Services (DH&FS) General Practice Branch (GPB) to report on the issues surrounding the adoption and use of General Practice Computer Systems (GPCS) by Australian practitioners, and to develop a func-tional requirements specification and technical framework that would lead to widespread application.
Figure 1. Blood pressure instance in archetype approach (adopted from Bird et al.9)
BP: GROUP
Name = “Blood Pressure”
Item1: ITEM
Name = “systolic blood pressure”
Value = ??? (40 … 300 mmHg)
Name = “diastolic blood pressure”
Value = ??? (40 … 300 mmHg) Item2: ITEM
Archetypes, GEHR, openEHR and Electronic Health Records
The Journal on Information Technology in Healthcare 2003; 1(5): 369–380 373 The “Functional Requirements Specification Report”13 identified eight critical standards to form a Standards Framework. Regarding the category of Electronic Health Record Architecture, the report concluded: “In order to ensure optimal data management and interoperation between GPCS applications/functional components, it is vitally important that the GPCS is based on a standard electronic health record architecture. From extensive research, the IBM Consulting Group has concluded that the Good European Health Record (GEHR) Architecture is the most appropriate and comprehensive health record architecture currently in existence.”
As a consequence of the report, the General Practice Computing Group (GPCG) funded preliminary implementation trials for Good European Health Record. Further discussions and the outcomes of these trials can be found at:
http://www.gehr.org/gpcg/index.htm.
In November 1999, the Australian Federal Government formed the National Electronic Health Records Taskforce to coordinate a national approach to the development of electronic health records. Their report, “A Health Information Network for Australia (HINA)”, was released, and endorsed by the health minister in July 200014.
With respect to the standards to be used for the structure of the stored record, the Taskforce agreed that a standard format for data should be adopted, but accepted that there was no consensus as to the choice of standard. After much deliberation they proposed that GEHR be adopted . “The GEHR (Good Electronic Health Record) appears to have the best prospects and is the subject of a trial within Australian general practices through the General Practice Computing Group (GPCG) at present. The Taskforce therefore proposes that further work proceed in this area, building on developments to date.” As explained earlier GEHR is now known as openEHR.
A critical aspect of the openEHR framework is the concept of two level model-ling through incorporating archetypes. Currently, openEHR is in the process of conducting implementation trials through the Software Development and Clini-cal Trials Phase of HealthConnect’s openEHR work program, commissioned by the Department of Health and Ageing. The project is continuing.
THE ABILITY OF OPENEHR TO WORK WITH LEGACY AND SOURCE SYSTEMS
Trials funded by the Australian General Computing Group have demonstrated the feasibility and benefits of adopting GEHR. The OACIS-GEHR project15 proved that data could be extracted from a large clinical database and used with a GEHR system. The conversion of data was achieved in two steps using a process that was specifically developed for the OACIS-GEHR project:
1. A pre-processing phase involving the extraction of rows from the database in plain text and conversion of this text to Extensible Markup Language (XML).
Yu
374 The Journal on Information Technology in Healthcare 2003; 1(5): 369–380
This was followed by mapping of the database ‘fields’ to the GEHR archetype
‘fields’.
2. A generic phase, (which might be applicable to other systems), using the mapping tables produced in phase 1, XML technology and Extensible Stylesheet Language (XSLT). These processes automatically converted the database entries into the appropriate archetype format.
This data conversion involved a large amount of manual effort, and was not performed in a run-time situation. Nevertheless, the trial demonstrated the feasi-bility of achieving the conversion using current technology.
Another project, the GP-GEHR transmission project, used a conversion tool created by Distributed Systems Technology Center (DSTC)16. This conversion tool enabled the extraction of GEHR event summaries from the two dominant GP software packages in Australia, Medical Director and Locum Script, and ex-ported the extracted data to a GEHR-compliant EHR server.
In both experiments, the key success factor was the capability of mapping between the fields. If the system-specific pre-processing stage can be simplified, for example, through improved mapping tools, then the whole process will be feasible. Tools to aid in this process are planned for development in 2003–20049. APPLICATION OF ARCHETYPES IN THE OACIS-GEHR AND GP-GEHR PROJECTS
In openEHR, archetypes are expressed in XML format. Domain experts, in this case healthcare professionals, are given the convenience of creating and editing archetypes without the need for knowledge of either software development or XML knowledge. A prototype archetype editor, Clinical Model Builder, developed in Visual Basic by the Project Titanium team at the DSTC, has developed this tool5,7.
Archetypes should be stored in online repositories, easily accessible by the archetype editor. Systems are responsible for organising, searching and accessing archetypes, and their numerous versions created by multiple authors. Validator, a software component, is in charge of using archetypes for creating and manipulat-ing the content of the EHR. Information is retrieved at runtime from the online repository. A validator is any component that works with archetypes to ensure that the content is valid against both the reference model and the archetypes5. For example, the creation of EHR content at clinical source systems (such as a patient event) would require data validation, through either a kernel within the source system, or in a data extraction/conversion tool. Similarly, a server storing EHR information would validate data upon receiving or sending extracts of the EHR (such as a patient event)17.
Archetypes, GEHR, openEHR and Electronic Health Records
The Journal on Information Technology in Healthcare 2003; 1(5): 369–380 375 SOFTWARE IMPLEMENTATION
The exact mechanism for the implementation of the openEHR architecture is continuing to evolve, particularly through the planned stages of the Software Development and Clinical Trials Phase of HealthConnect’s openEHR work pro-gram OACIS-GEHR and GP-GEHR project.
A mechanism for validating archetypes has been outlined by Bird et al.9. First, archetypes are specified in XML in a specific Archetype Constraint Language. An EHR extract is first checked against the reference model, using XML Schema.
Then the extract is checked for conformance with the relevant archetypes by an XSLT processor, which uses a common XSLT script to retrieve archetypes from the online repository. Any errors in the EHR extract are then reported.
THE ROLE OF THE KERNEL
A kernel is a software component that implements the GEHR Object Model (GOM). It is responsible for loading archetype documents dynamically from a clinical knowledge server. The Reference Model and the set of stored archetype definitions are used to validate any clinical data placed inside a locally-created EHR, or sent from another EHR system as an EHR extract18.
THE IMPACT OF ARCHETYPES ON SOFTWARE DEVELOPMENT
The introduction of archetypes into health information system modelling is a significant innovation in software development. There are many software devel-opment models and although some of them emphasise the importance of user participation in software development, none of them empowers the user (or domain experts) with the authority of designing and manipulating components of the software. The intention of the archetype approach is to pass the task of archetype maintenance and evolution to domain experts. The domain experts are expected to add archetypes to the data model when new concepts arise. It is also the domain expert’s responsibility to delete, revise or update an existing archetype.
THE ADVANTAGE OF THE ARCHETYPE APPROACH
The separation of a knowledge model (archetype) from a reference model reduces the size of the information system that has to be designed and implemented by software developers. It empowers users in a domain to formally define and imple-ment their concepts in the information system. The system guides and validates user input at runtime to ensure that information ‘instances’ conform to domain requirements6. This is a significant innovation in software development. The
Yu
376 The Journal on Information Technology in Healthcare 2003; 1(5): 369–380
archetype approach provides a number of advantages in the maintainenance, interoperability and future applications of the final software system6.
PROBLEMS WITH OPENEHR AND THE ARCHETYPE APPROACH
Tun et al.17 pointed out that the problem with the two level modelling approach is that important clinical semantics may be lost. They gave an example of a blood pressure test that has to be represented by systolic and diastolic values, with each in a decimal number. “An EHR system using this approach would have to allow users to set both their own field names and values, which may result in data that is inconsistent and impossible to use.”
Classes in reference models are highly generic, and have no real meaning by themselves. As Bird et al.9 states, users can organise these classes and limit their instances in an ad hoc manner to express the components of an EHR system.
Without a strict standardisation process, inconsistency and poor interoperability between systems would result.
The Transformation of Data Automatically from non-GEHR Legacy Systems into GEHR XML Format and Vice Versa
This function is required to enable existing EHR systems to exchange data with each other. This may be achieved through using a common record architecture (namely GEHR) to enable interoperability among varieties of systems17.
How to Automatically Configure Interface Terminology to Reflect the Change of Archetypes?
A significant amount of domain terms are actually built into the interfaces of various gadgets and widgets such as buttons, text definitions for check boxes, radio buttons and text fields, etc. The problem of developing dynamic user inter-faces, which can automatically configure themselves in response to the creation and changing of archetypes, has yet to be addressed.
The Separation of Knowledge and Information Levels Significantly Increases the Information Content of the Application
If the two levels are stored in different locations in a distributed environment, an always-on Internet connection is a prerequisite for the proper functioning of the system. Compared with a normal information system, a two level system signifi-cantly increases the overheads of the information system and the load of the network traffic. Further investigations are needed to discover how much extra storage space and operating speed the model will need compared with the normal one-level approach, and whether current technology and the distributed environ-ment can handle this flow of information content?
Archetypes, GEHR, openEHR and Electronic Health Records
The Journal on Information Technology in Healthcare 2003; 1(5): 369–380 377 The Construction of a Comprehensive Set of Archetypes at the Start of the System Development is Required for the Success of an Archetype-driven EHR This requirement however diminishes the benefit of flexibility, adaptability and extensibility of archetypes. It could lead to the selection of the traditional single-level model as the most rational decision because of the simplicity of design and the popularity of the methodology in software industry.
THE FEASIBILITY OF ARCHETYPE CREATION AND MANAGEMENT
The question of whether domain experts have enough expertise and experience to handle the task of designing archetypes needs to be adddressed. Bird et al.9 real-ised that the success of the archetype approach relies largely on the capability of domain experts to understand and create archetypes. An archetype editor
The question of whether domain experts have enough expertise and experience to handle the task of designing archetypes needs to be adddressed. Bird et al.9 real-ised that the success of the archetype approach relies largely on the capability of domain experts to understand and create archetypes. An archetype editor