Background

Requirements

There are broadly three sets of requirements which inform this model, as described in the following subsections.

Original GEHR Requirements

From the European GEHR project (1992-5; [Ingram_1995]), the following broad requirements areas were identified:

  • the life-long EHR;

  • priority: Clinician / Patient interaction;

  • medico-legal faithfulness, traceability, audit-trailing;

  • technology & data format independent;

  • facilitate sharing of EHRs;

  • suitable for both primary & acute care;

  • secondary uses: education, research, population medicine;

  • open standard & software deliverables;

The original deliverables can be reviewed in detail at the GEHR page at CHIME, UCL.

GEHR Australia Requirements

The GEHR Australia project (1997-2001; [GeHR_Aus_gpcg], [GeHR_Aus_req]) introduced further requirements, including:

  • support for clinical data structures: lists, tables, time-series etc;

  • safer information model than the original (European) GEHR: context attributes only in valid places (but still similar style);

  • separate groups for "persistent", "demographic" and "event" information in EHR, which corresponds closely to real clinical querying patterns;

  • introduction of formally specified archetypes, and archetype-enabled information model;

  • interoperability at the knowledge level, i.e. level of domain definitions of information such as "discharge summary" and "biochemistry result";

  • XML-enabled;

  • consider compatibility with CEN 13606, Corbamed, HL7v3.

GEHR Australia produced a proof of concept implementation in which clinical archetypes were developed and used. See [Beale_2000] for a technical description of archetypes.

European Synapses and SynEx Project Requirements

Following the original Good European Health Record project the EU-funded Synapses (1996-8; [Synapses_req_B]) and SynEx (1998-2000; [Sottile_1999]) projects extended the original requirements basis of GEHR to include further requirements, as follows:

  • the requirements of a federation approach to unifying disparate clinical databases and EPR systems: the federated health record (FHR) [Synapses_req_A];

  • the need to separate a generic and domain independent high-level model for the federated health record from the (closely related) model of the meta-data which defines the domain specific health record characteristics of any given clinical specialty and any given federation of database schemata;

  • a formalism to define and communicate (share) knowledge about the semantic hierarchical organisation of an FHR, the permitted data values associated with each leaf node in a record hierarchy and any constraints on values that leaf nodes may take (the Synapses Object Dictionary) [Synapses_odp];

  • the core technical requirements of and interfaces for a federation middleware service [Synapses_req_B].

European EHCR Support Action Requirements

This EU Support Action project ("SupA"; [EHCR_supA_24], [EHCR_supA_31_32], [EHCR_supA_35]) consolidated the requirements published by a wide range of European projects and national health informatics organisations as a Consolidated List of Requirements [EHCR_supA_14].

ISO EHR Requirements

The above requirements publications and the recent experience of openEHR feed into the definition of a set of EHR requirements authored by ISO Technical Committee 215 (Health Informatics) - ISO TS 18308. The present draft [ISO_18308] has been reviewed by the authors of this document and openEHR will seek to maintain a close mapping between its information models and services and this international requirements work. The openEHR mapping to ISO 18308 can be found on the openEHR website.

openEHR Requirements

New requirements generated during the development of openEHR included the following:

  • major improvements in information models from the point of view of reducing progammer errors and ambiguity;

  • better modelling of time and context (temporal/spatial approach);

  • better understanding of legacy system / federation problem;

  • workflow modelling;

  • harmonise with CEN EN 13606;

  • integration with HL7v2 and other messaging systems;

  • numerous specific clinical requirements.

Relationship to other Health Information Models

Where relevant, the correspondences to other information models have been documented in this specification. Correspondences to the GEHR Australia and EU Synapses/SynEx models are shown, since these are the models on which the openEHR EHR information model is primarily based. The following sections summarise the other models and standards with which correspondences are shown.

CEN TC/251 prEN13606

These models have been influenced by and have also influenced the models in sCEN prEN13606 (2005 revision); accordingly, relationships to 13606 have been documented fairly precisely.

Since January 2002, the prEN13606 prestandard has been the subject of significant revision, as part of its transition to a full European Standard ("EN"). This work has been influenced by the openEHR specifications, and has itself been a source of further insights and changes to the openEHR specifications.

Particular areas of openEHR which have been changed due to this process include:

  • change of major class names (TRANSACTION → COMPOSITION etc; see CR-000013);

  • improved model of ATTESTATION (see CR-000025);

  • improved model of feeder audits (see CR-000027).

Implementation experience with Release 0.9 and 0.95 of openEHR has further improved these areas significantly. Nevertheless, openEHR is not a copy of CEN, for two reasons. Firstly, its scope includes systems, while EN13606 defines an EHR Extract; secondly, EN13606 suffers somewhat from "design by committee", and has no formal validation mechanism for its models.

HL7 Version 3

Correspondences to some parts of HL7 version 3 (ballot 5, July 2003) are also documented where possible, however, it should be understood that there are a number of difficulties with this. Firstly, while the HL7v3 Reference Information Model (RIM) - the closest HL7 artifact to an information model - provides similar data types and some related semantics, it is not intended to be a model of the EHR. In fact, it differs from the information model presented here (and for that matter most published information models) in two basic respects: a) it is an amalgam of semantics from many systems which would exist in a distributed health information environment, rather than a model of just one (the EHR); b) it is also not a model of data, but a combination of "analysis patterns" in the sense of Fowler [Fowler_1997] from which further specific models - subschemas - are developed by a custom process of "refinement by restriction", in order to arrive at message definitions. As a consequence, data in messages are not instances of HL7v3 RIM classes, as would be the case in other systems based on information models of the kind presented here.

Despite the differences, there are some areas that appear to be candidates for mapping, specifically the data types and terminology use, and the correspondence between openEHR Compositions and parts of the HL7 Clinical Document Architecture (CDA).

OMG HDTF

In general, the openEHR information models represent a more recent analysis of the required semantics of EHR and related information than can be found in the information viewpoint of the OMG HDTF specifications (particularly PIDS and COAS). However, the computational viewpoint (i.e. functional service interface definitions) is one of the inputs to the openEHR srevice model develpment activity.