openEHR logo

Integration Information Model

Issuer: openEHR Specification Program

Revision: [latest_issue]

Date: [latest_issue_date]

Status: STABLE

Keywords: EHR, data structures, openehr

openEHR components
© 2003 - 2015 The openEHR Foundation

The openEHR Foundation is an independent, non-profit community organisation, facilitating the sharing of health records by consumers and clinicians via open-source, standards-based implementations.


image Creative Commons Attribution-NoDerivs 3.0 Unported.



Amendment Record

Issue Details Raiser Completed

R E L E A S E     1.0.2

R E L E A S E     1.0.1


SCR-000203: Release 1.0 explanatory text improvements. Added section on openEHR Extract. Added integration architecture diagram.

T Beale

22 Jul 2006

R E L E A S E     1.0


Initial writing.

T Beale

15 Sep 2005


The work reported in this paper has been funded in by the following organisations:

  • University College London - Centre for Health Informatics and Multi-professional Education (CHIME);

  • Ocean Informatics;

Special thanks to Prof David Ingram, head of CHIME, who provided a vision and collegial working environment ever since the days of GEHR (1992).

1. Preface

1.1. Purpose

This document describes the architecture of the openEHR Integration Information Model, designed for use in legacy and other integration situations.

The intended audience includes:

  • Standards bodies producing health informatics standards;

  • Academic groups using openEHR;

  • The open source healthcare community;

  • Solution vendors;

  • Medical informaticians and clinicians interested in health information.

  • Health data managers.

Prerequisite documents for reading this document include:

1.3. Status

This specification is in the Stable state. The development version of this document can be found at

Known omissions or questions are indicated in the text with a 'to be determined' paragraph, as follows:

TBD: (example To Be Determined paragraph)

Users are encouraged to comment on and/or advise on these paragraphs as well as the main content. Feedback should be provided either on the technical mailing list, or on the specifications issue tracker.

1.4. Conformance

Conformance of a data or software artifact to an openEHR Reference Model specification is determined by a formal test of that artifact against the relevant openEHR Implementation Technology Specification(s) (ITSs), such as an IDL interface or an XML-schema. Since ITSs are formal, automated derivations from the Reference Model, ITS conformance indicates RM conformance.

2. Integration Package

2.1. Requirements

Getting data in and out of the EHR is one of the most basic requirements openEHR aims to satisfy. In "greenfield" (new build) situations, and for data being created by GUI applications via the openEHR EHR APIs, there is no issue, since native openEHR structures and semantics are being used. In almost all other situations, existing data sources and sinks have to be accounted for. In general, external or ‘legacy’ data (here the term is used for convenience, and does not imply anything about the age or quality of the systems in question) have different syntactic and semantic formats than openEHR data, and seamless conversion requires addressing both levels.

Typical examples of legacy data sources and sinks include relational databases, HL7v2 messages, and HL7 CDA documents. HL7v2 messages are probably one of the most common sources of pathology messages in many countries; EDIFACT messages are another. More recently, HL7v2 messages have been designed for referrals and even discharge summaries. Not all legacy systems are standardised; many if not most hospitals as well as GP and other desktop products have their own private models of data and terminology usage. Technically speaking, there is not much difference between standardised and non-standardised legacy models; only the reusability of the solution differs.

Another important category of externally sourced data addressed by the Integration package described here is data expressed in a form of a CEN EN13606 Extract. Part 1 of EN13606 defines a information model which is nearly identical to that of openEHR at the COMPOSITION and SECTION levels. The CEN EN13606 Entry class is a generic structure with a minimum of contextual metadata, and can easily be mapped to the openEHR Entry type described in this specification.

The primary need with respect to legacy data is to be able to convert data from multiple mutually incompatible sources into a single, standardised patient-centric EHR for each patient, that can then be longitudinally viewed and queried. This is what enables GP and specialist notes, diagnoses and plans to be integrated with laboratory results from multiple sources, patient notes, administrative data and so on, to provide a coherent record of the patient journey.

In technical terms, a number of types of incompatibility have to be dealt with. There is no guarantee of correspondence of scope of incoming transactions and target openEHR structures - an incoming document for example might correspond to a number of clinical archetypes. Structure will not usually correspond, with legacy data (particularly messages) usually having flatter structures than those defined in target archetypes. Terminology use is extremely variable in existing systems and messages, and also has to be dealt with. Data types will also not correspond directly, so that for example, a mapping between an incoming string "110/80 mmHg" and the target openEHR form of two DV_QUANTITY objects each with their own value and units has to be made.

2.2. Design Basis

2.2.1. Overview

The design basis for connecting existing systems to openEHR is founded upon a clear separation of the syntactic and semantic transformations required on data. The syntactic transformation converts source data from its original form (or whatever intermediate form it may have been converted to) to a format obeying a special class in the openEHR reference model, but whose logical structure and semantics are controlled by ‘integration’ archetypes so as to mimic the design of the source data. This step brings the data into the openEHR computational context. The second step causes transformation on this intermediate openEHR data into data which are a) instances of the main openEHR reference model, and b) obey ‘designed’ clinical archetypes.

The additional elements of the openEHR architecture which make this transformation possible are:

  • a class GENERIC_ENTRY, which is a sibling of SECTION and ENTRY, and contains completely generic, archetypable structures;

  • ‘integration’ archetypes, i.e. archetypes defined against the GENERIC_ENTRY class;

  • semantic transformation rules from openEHR data based on GENERIC_ENTRY and integration archetypes to data based on the subtypes of ENTRY, and designed archetypes.

The figure below illustrates the rm.integration package, which contains a single class GENERIC_ENTRY. Unlike other classes in the openEHR reference model, GENERIC_ENTRY contains no hard-wired attributes at all, only one generic attribute, data. No assumptions at all are made about the actual shape of such data.

RM integration
Figure 1. rm.integration Package

2.2.2. Semantics of GENERIC_ENTRY

A number of useful consequences follow from this modelling approach. Firstly, instances of GENERIC_ENTRY will contain attributes inherited from the LOCATABLE class, including archetype_node_id, and are thus archetypable in the same way as all other classes in the openEHR reference model. The LOCATABLE attribute feeder_audit is also inherited, and may be used to mark every node of data with relevant meta-data from the source system record or message. Secondly, as a subtype of CONTENT_ITEM, GENERIC_ENTRY is a valid value for COMPOSITION.content. This is a completely desirable situation, since the same rules apply to GENERIC_ENTRY as to other content: instances can only be committed to the record as part of a COMPOSITION instance. GENERIC_ENTRY data are thus audit-trailed and versioned in the normal way. Thirdly, GENERIC_ENTRY instances can occur within a hierarchy of SECTIONs, which is useful for data sources which have headings or section equivalents (this is quite common in hospital information systems containing physician notes). Lastly, in common with all other openEHR data, design-time paths can be constructed for archetypes of GENERIC_ENTRY, while runtime paths can be extracted from data based on such archetypes. These path sets can be used for writing the data transformation rules.

It should be remembered that while GENERIC_ENTRY provides a standardised syntactic form for externally sourced data within openEHR, it provides no semantic coherence. This is particularly true for GENERIC_ENTRY instances sourced from numerous data sources: there is no guarantee that the GENERIC_ENTRY representations of "cholesterol result" from system A will be congruent with those sourced from system B. It is not even required that the data sources be vastly different for this problem to occur. Examples of messages can be found coming from different pathology laboratories, which obey the same minor version of HL7v2 (e.g. 2.3.1) and supposedly implement the same message type (e.g. "complete blood picture") but which differ in actual structure and content. The consequence of this situation is that GENERIC_ENTRY data cannot in general be safely used for clinical computation (e.g. decision support), and will not in general even support reliable clinical querying. In other words, a repository of GENERIC_ENTRYs (within appropriate COMPOSITION structures) does not constitute a reliable or interoperable health record - it can only be considered a standardised health information data store whose primary purpose is as the input to or output of semantic conversion processes, or for other auditing or non-clinical data management purposes.

2.2.3. Use with openEHR Extracts

The GENERIC_ENTRY class provides a way to represent data from non-openEHR systems that implement the openEHR Extract specification in order to either communicate with openEHR systems, or to communicate with other systems also implementing the openEHR Extract specification.

2.2.4. Integration with CEN EN13606

The GENERIC_ENTRY class provides a convenient basis for making openEHR systems EN13606- compliant, which in turn gives openEHR a gateway capability in heterogeneous environments where EN13606 is being used to communicate data. A CEN EN13606 EHR Extract can be converted to a series of COMPOSITIONs containing GENERIC_ENTRY objects which obey appropriate integration archetypes; this data can then be semantically converted into orthodox openEHR objects for integration into a coherent EHR. Similarly, openEHR data can be converted into the GENERIC_ENTRY-based intermediate form for further conversion into EN13606 EHR Extracts.

2.3. Data Conversion Architecture

The integration archetype-based strategy for importing data into an openEHR system, shown in the following figure, consists of two steps.

integration environment
Figure 2. Data Integration using openEHR

Firstly, data are converted from their original syntactic format into openEHR COMPOSITION/SECTION/ GENERIC_ENTRY structures, shown in the openEHR integration switch. Most of the data will appear in the GENERIC_ENTRY part, controlled by an integration archetype designed to mimic the incoming structure (such as an HL7v2 lab message) as closely as possible; FEEDER_AUDIT structures are used to contain integration meta-data. The result of this step is data that are expressed in the openEHR type system (i.e. as instances of the openEHR reference model), and are immediately amenable to processing with normal openEHR software.

In the second step, semantic transformation is effected, by the use of mappings between integration and designed archetypes. Such mappings are created by archetype authors using tools. The mapping rules are the key to defining structural transformations, use of terminological codes, and other changes. Serious challenges of course remain in the business of integrating heterogeneous systems; some of these are dealt with in the Common IM document sections on Feeder systems.

2.4. Class Descriptions

2.4.1. GENERIC_ENTRY Class




This class is used to create intermediate representations of data from sources not otherwise conforming to openEHR classes, such as HL7 messages, relational databases and so on.








The ‘data’ from the source message or record.




  1. [bfo] Institute for Formal Ontology and Medical Information Science (IFOMIS). Basic Formal Ontology (BFO). .

  2. [FMA] .

  3. [Horrocks_owl] Patel-Schneider P, Horrocks I, Hayes P. OWL Web Ontology Language Semantics and Abstract Syntax. See .

  4. [IAO] Information Artefact Ontology. .

  5. [OBO] The Open Biological and Biomedical Ontologies. See .

  6. [OGMS] Ontology for General Medical Science (OGMS). .


  1. [cov_contra] Wikipedia. Covariance and contravariance. See .

e-Health Standards

  1. [ENV_13606-1] ENV 13606-1 - Electronic healthcare record communication - Part 1: Extended architecture. CEN/ TC 251 Health Informatics Technical Committee.

  2. [ENV_13606-2] ENV 13606-2 - Electronic healthcare record communication - Part 2: Domain term list. CEN/TC 251 Health Informatics Technical Committee.

  3. [ENV_13606-3] ENV 13606-3 - Electronic healthcare record communication - Part 3: Distribution rules. CEN/TC 251 Health Informatics Technical Committee.

  4. [ENV_13606-4] ENV 13606-4 - Electronic Healthcare Record Communication standard Part 4: Messages for the exchange of information. CEN/ TC 251 Health Informatics Technical Committee.

  5. [Corbamed_PIDS] Object Management Group. Person Identification Service. March 1999.

  6. [Corbamed_LQS] Object Management Group. Lexicon Query Service. March 1999.

  7. [HL7v3_ballot2] JL7 International. HL7 version 3 2nd Ballot specification. Available at

  8. [HL7v3_data_types] Schadow G, Biron P. HL7 version 3 deliverable: Version 3 Data Types. (2nd ballot 2002 version).

  9. [hl7_v3_rim] HL7. HL7 v3 RIM. See .

  10. [ICD10AM]. WHO / ACCD. International Classification of Diseases, 10th Revision, Australian Modifications. See

  11. [IHTSDO] International Health Terminology Standards Development Organisation (IHTSDO).


  13. [NLM_UML_list] National Library of Medicine. UMLS Terminologies List.

  14. [SNOMED_CT] IHTSDO. Sytematised Nomenclature for Medicine. See

  15. [WHO_ICD] World Health Organisation (WHO). International Classification of Diseases (ICD). See: .

  16. [ISO_18308] Schloeffel P. (Editor). Requirements for an Electronic Health Record Reference Architecture. (ISO TC 215/SC N; ISO/WD 18308). International Standards Organisation, Australia, 2002.

  17. [ISO_20514] ISO. The Integrated Care EHR. See .

  18. [UCUM] Schadow G, McDonald C J. The Unified Code for Units of Measure, Version 1.4 2000. Regenstrief Institute for Health Care, Indianapolis. See

e-Health Projects

  1. [EHCR_supA_14] Dixon R, Grubb P A, Lloyd D, and Kalra D. Consolidated List of Requirements. EHCR Support Action Deliverable 1.4. European Commission DGXIII, Brussels; May 2001 59pp Available from

  2. [EHCR_supA_35] Dixon R, Grubb P, Lloyd D. EHCR Support Action Deliverable 3.5: "Final Recommendations to CEN for future work". Oct 2000. Available at

  3. [EHCR_supA_24] Dixon R, Grubb P, Lloyd D. EHCR Support Action Deliverable 2.4 "Guidelines on Interpretation and implementation of CEN EHCRA". Oct 2000. Available at

  4. [ Lloyd D, et al. EHCR Support Action Deliverable 3.1&3.2 “Interim Report to CEN”. July 1998. Available at

  5. [GEHR_del_4] Deliverable 4: GEHR Requirements for Clinical Comprehensiveness. GEHR Project 1992

  6. [GEHR_del_7] Deliverable 7: Clinical Functional Specifications. GEHR Project 1993

  7. [GEHR_del_8] Deliverable 8: Ethical and legal Requirements of GEHR Architecture and Systems. GEHR Project 1994

  8. [GEHR_del_19_20_24] Deliverable 19,20,24: GEHR Architecture. GEHR Project 30/6/1995

  9. [GeHR_AUS] Heard S, Beale T. The Good Electronic Health Record (GeHR) (Australia). See .

  10. [GeHR_Aus_gpcg] Heard S. GEHR Project Australia, GPCG Trial. Available at

  11. [GeHR_Aus_req] Beale T, Heard S. GEHR Technical Requirements. See

  12. [Synapses_req_A] Kalra D. (Editor). The Synapses User Requirements and Functional Specification (Part A). EU Telematics Application Programme, Brussels; 1996; The Synapses Project: Deliverable USER 1.1.1a. 6 chapters, 176 pages.

  13. [Synapses_req_B] Grimson W. and Groth T. (Editors). The Synapses User Requirements and Functional Specification (Part B). EU Telematics Application Programme, Brussels; 1996; The Synapses Project: Deliverable USER 1.1.1b.

  14. [Synapses_odp] Kalra D. (Editor). Synapses ODP Information Viewpoint. EU Telematics Application Programme, Brussels; 1998; The Synapses Project: Final Deliverable. 10 chapters, 64 pages.

  15. [synex] University College London. SynEx project. .

General Standards

  1. [OCL] The Object Constraint Language 2.0. Object Management Group (OMG). Available at .

  2. [IANA] IANA.

  3. [IEEE_828] IEEE. IEEE 828-2005: standard for Software Configuration Management Plans.

  4. [ISO_8601] ISO 8601 standard describing formats for representing times, dates, and durations. See e.g. and

  5. [ISO_2788] ISO. ISO 2788 Guide to Establishment and development of monolingual thesauri.

  6. [ISO_5964] ISO. ISO 5964 Guide to Establishment and development of multilingual thesauri.

  7. [Perl_regex] Perl Regular Expressions. Available at .

  8. [Protege] Stanford University. See .

  9. [rfc_2396] Berners-Lee T. Universal Resource Identifiers in WWW. Available at This is a World-Wide Web RFC for global identification of resources. In current use on the web, e.g. by Mosaic, Netscape and similar tools. See for a starting point on URIs.

  10. [rfc_2440] openPGP. See and

  11. [rfc_4122] UUIDs. IETF. See .

  12. [rfc2781] IETF. RFC 2781. See

  13. [rfc5646] IETF. RFC 5646. Available at

  14. [sem_ver] Semantic Versioning. .

  15. [Xpath] W3C Xpath 1.0 specification. 1999. Available at

  16. [uri_syntax] Uniform Resource Identifier (URI): Generic Syntax, Internet proposed standard. January 2005. see .

  17. [w3c_owl] W3C. OWL - the Web Ontology Language. See .

  18. [w3c_xpath] W3C. XML Path Language. See .

openEHR Resources

  1. [openehr_18308] The openEHR Foundation. Conformance of openEHR architecture to ISO TS 18308, "Requirements for EHR Architectures". See

  2. [openEHR_ADL_workbench] The openEHR Foundation. The openEHR ADL Workbench. .

  3. [openehr_am_overview] The openEHR Foundation. The openEHR Archetypes Technical Overview. See

  4. [openehr_am_adl] The openEHR Foundation. Archetype Definition Language (ADL2). Available at

  5. [openehr_am_aom] The openEHR Foundation. Archetype Object Model (AOM2). Available at

  6. [openehr_am_identification] The openEHR Foundation. Archetype Identification specification. Available at

  7. [openehr_CKM] The openEHR Clinical Knowledge Manager (CKM). See

  8. [openehr_overview] The openEHR Foundation. The openEHR Architecture Overview. See

  9. [openehr_query_aql] The openEHR Foundation. The openEHR Archetype Query language (AQL). See

  10. [openehr_rm_data_types] openEHR. Data Types Information Model. See

  11. [openehr_rm_data_structures] openEHR. Data Structures Information Model. See

  12. [openehr_rm_common] openEHR. Common Information Model. See

  13. [openehr_rm_ehr] The openEHR Foundation. The EHR Information Model.

  14. [openehr_rm_support] openEHR. Support Information Model. See

  15. [openehr_terminology] The openEHR Foundation. The openEHR Terminology

  16. [openehr_terminology_resources] The openEHR Foundation. The openEHR Terminology project (GitHub) .