Background

From the European GEHR project 1992-5 [1], the following broad requirements areas were identified:

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

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

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

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

This EU Support Action project ('SupA'; [9], [10], [11]) consolidated the requirements published by a wide range of European projects and national health informatics organisations as a Consolidated List of Requirements [12].

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 18308. This has been reviewed and a mapping to openEHR developed.

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

These models have been influenced by and have also influenced the models in ISO 13606 (2005 revision); accordingly, relationships to 13606 have been documented fairly precisely. Particular areas of openEHR which have been changed due to this process include:

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 ISO 13606 defines an EHR Extract; secondly, ISO 13606 suffers somewhat from 'design by committee", and has no formal validation mechanism for its models.

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 [13] 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).

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 OMG PIDS and OMG COAS. However, the computational viewpoint (i.e. functional service interface definitions) is one of the inputs to the openEHR service model development activity.