gms | German Medical Science

A myriad of reasons ranging from physician concerns about workflow to broad environmental issues are still inhibiting the adoption of Electronic Health Record (EHR) systems [Ref. 1]. Some argue the most important reason why clinicians are reluctant to adopt clinical IT systems is a perceived lack of added value [Ref. 2] The UK Royal College of Nursing finds in a recent study that 93% of nurses believe that training for EHRs is very important, but over 50% received no training [Ref. 3]. Clinicians commonly feel that it is others who benefit from their keyboard labours – health system administrators, payors, and – hopefully – the patient [Ref. 2]. To really add value for the clinician it is still a necessity to develop best-of-breed systems (e.g. [Ref. 4]) commonly by circumventing existing systems with a strong administrative focus. Best-of-breed systems are at best awkwardly integrated, often maintained with minimum resources, and not interoperable with other systems. Further complicating this matter, health care is constantly changing in three ways (breadth, depth, complexity): new information, information in finer-grained detail, and new relationships are always being discovered or becoming relevant. Therefore, knowledge inherent in EHR systems will eventually become irrelevant or wrong.

The openEHR archetype methodology (http://www.openEHR.org) is a possible solution to this dilemma as it claims to empower the clinician and ensure seamless integration and semantic interoperability. The aim of this paper is to shortly present the openEHR approach, analyse to what extend it empowers the clinician and what impact openEHR archetypes have on semantic interoperability.

We analysed current approaches to EHR systems, terminology and standards developments. In addition to literature reviews, we organised face-to-face and additional telephone interviews and teleconferences with members of ISO/TC 215, CEN EHR Taskforce, EHR SIG of HL7 International, Standards Australia Electronic Health Record Committee, the Australian Health Information Standards Advisory Committee, and founding members of the openEHR Foundation.

openEHR proposes a two-level-modelling approach for EHR systems, clearly separating knowledge from information. The first level is the reference information model which represents the minimum to support the medico-legal requirements and record management functions. This ensures that clinicians can exchange information with other providers – thus ensuring data interoperability. The second level models the knowledge using openEHR archetypes – thus evolving clinical knowledge can be shared and semantic interoperability ensured. Basically, an archetype represents one clinical or other domain specific concept by constraining instances of the openEHR information models to express a valid structure, valid data types, and values. A blood pressure archetype for example represents all the information a clinician needs about a blood pressure measurement. Design principles of openEHR are described in [Ref. 5]. The key innovation of the openEHR architecture is that it separates record keeping concerns from clinical data collection [Ref. 6].

Keeping in mind that knowledge in health care is open-ended and constantly changing, the only way is to “put the clinicians back into the driver’s seat”. This enables them to define and alter the accurate knowledge and information they need. The adoption of openEHR archetypes empowers domain experts to create and change the knowledge inherent in archetypes. For this the openEHR Archetype Editor was built – thus rendering the abstract openEHR archetype model tangible. This can be a powerful means to empower clinicians; however the archetype development will have to be coordinated to avoid “rank growth”. Most of the core set of archetypes has to be built by a relatively small group of clinicians. Individual groups of clinicians can then easily extend and adapt these archetypes to their needs.

With the openEHR reference model data interoperability – the basis for semantic interoperability – is increased, because data are communicated between systems only in terms of standard, open reference model instances, while semantic interoperability is achieved by the sharing of archetypes. Archetypes are used at both ends to validate and query the data. Adoption of the EN-ISO 13606-1 standard [Ref. 7] ensures an EHR system is able to manage this. Further, as agreed models of clinical or other domain specific concepts, archetypes are clinically meaningful entities. An EHR entry which has been archetyped will have the same meaning no matter where or in which EHR it appears. Thus, archetypes can be shared by multiple health systems and authorities, enabling information to be shared between different systems and types of healthcare professionals. Since the translation occurs within one archetype only – the meaning of the archetype is preserved across language borders.

The traditional method of clinical system development is to collect functional requirements, usually from a small number of ‘typical’ clinicians. Then the software is designed based on a single large model which incorporates both the generic business rules for the system and the domain-specific (clinical) requirements. However sophisticated this requirements engineering is (e.g. [Ref. 8]), the ‘impedance mismatch’ between IT specialists and clinicians, the complexity of clinical systems and the variability of work patterns between different clinicians, often means that the resulting clinical system is an inflexible ‘one size fits all’ compromise which in reality suits no-one [2]. We therefore believe that we have to go one step further than performing precise activity and requirement analyses and make the clinician ultimately control – not only influence – the clinical content of IT systems like EHRs. Otherwise, the peril is that no clinical value is added. Current clinical information systems directly incorporate clinical knowledge. The use of archetypes means that EHR software can now be considerably smaller than traditionally and requires little maintenance since all knowledge will reside in software-independent archetypes allowing changes to be made without altering software or databases, basing on a small and stable information model. This also enables the EHR to increasingly satisfy user needs, rather than degrading into obsolescence, as invariably happens with today's health systems.

The openEHR two-level modelling and archetype methodology cannot overcome all of the barriers to more efficient use of computerised clinical systems. Easier and faster data capture at the point of care remains a major challenge, which will only be overcome by a combination of more efficient technologies such as voice or handwriting recognition. openEHR can however, make a significant contribution to the flexibility and usability of clinical systems and to the improvement of data quality and semantic interoperability and thus also serve as the key enabler for intelligent decision support, care planning and other value-adding applications.

While HL7 primarily defines messages between applications and HL7 CDA is a generic model for the communication of clinical documents, and in this is similar to openEHR Transactions, openEHR’s focus is the EHR as a whole. Harmonisation between HL7, CDA, openEHR and standards like CEN 13606 is being strived for.

Firstly, to be acceptable to clinicians, computerised clinical systems must add value – at the point of care. Secondly, to enable (life-long) EHRs, semantic interoperability is of major importance. For both, the openEHR methodology – employing archetypes as the fundamental and flexible building blocks of the health knowledge environment and consistently separating knowledge and information – is of great value.