openEHR logo

Support Information Model

Issuer: openEHR Specification Program

Release: RM Release-1.0.4

Status: STABLE

Revision: [latest_issue]

Date: [latest_issue_date]

Keywords: EHR, openehr, identifiers, types
openEHR components
© 2003 - 2019 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 standards-based implementations.

Licence

image Creative Commons Attribution-NoDerivs 3.0 Unported. https://creativecommons.org/licenses/by-nd/3.0/

Support

Issues: Problem Reports
Web: specifications.openEHR.org

Amendment Record

Issue Details Raiser Completed

RM Release 1.0.4

1.8.0

SPECRM-62: Move most sections in Support IM to BASE component specifications.

openEHR SEC

20 Sep 2017

1.7.2

SPECRM-50: Change order of type parameters in Hash<V,K> type to Hash<K,V>.

D Boscá

13 Apr 2016

SPECRM-46: Correct OBJECT_REF.id_namespace to namespace (typo reported in SPECPR-159).+ Change Hash<T,U> to Hash<V,K> to match class documentation and more modern naming of type parameters.

S Iancu,
T Beale

02 Mar 2016

SPECRM-49: Improve ISO8601 date/time class string format templates (reported in SPECPR-157).+ Correct '±' characters in Date/time types section (reported in SPECPR-156).
Fix typo in ISO8601_DURATION.is_decimal_sign_comma (reported in SPECPR-155).
Add ':' to timezone, required in extended format. Change ISO8601_TIMEZONE to inherit from ISO8601_TYPE.

K Atalag,
P Pazos

RM Release 1.0.3

1.7.1

SPECRM-29: Change DV_COUNT.magnitude to Integer64 type.

R Chen

15 Aug 2015

1.7.0

SPECRM-31: Upgrade INTERNET_ID grammar to allow underscrores; clean up EBNF.

T Beale

10 Oct 2015

Release 1.0.2

1.6.1

SPEC-256: Correct extension_validity in UID_BASED_ID class.

R Chen

20 Oct 2008

SPEC-260: Correct the regex published for the ARCHETYPE_ID type. Improved explanatory text for composite identifiers, including statement on case-sensitivity. Warning on .v1draft non-conformance included.

P Gummer
J Arnett
E Browne

Release 1.0.1

1.6.0

SPECRM-215: Merge DV_PARTIAL_XX date/time classes and move ISO 8601 semantics to Support IM.

T Beale

08 Apr 2007

SPECRM-209: Minor changes to correctly define AUTHORED_RESOURCE.current_revision. Add minimal definition for List<T> class.

Y S Lim

SPEC-200: Correct Release 1.0 typographical errors. Move INTERVAL class definition to correct section. Add two invariants. Improved explanation of identifiers.

S Heard
G Grieve
D Lloyd

SPEC-202: Correct minor errors in VERSION.preceding_version_id. Added is_first function and invariant to VERSION_TREE_ID class. Added invariants for 1-based numbering

S Heard,
H Frankel
Y S Lim

SPEC-203: Release 1.0 explanatory text improvements.

A Patterson
G Grieve

SPEC-204: Add generic id subtype of OBJECT_ID.

H Frankel

SPEC-216: Allow mixture of W, D etc in ISO8601 Duration (deviation from standard).

S Heard

SPEC-219: Use constants instead of literals to refer to terminology in RM.

R Chen

SPEC-220: Tighten semantics of HISTORY.period and EVENT.time.

A Patterson

SPEC-144: Add new Ratio type: DV_PROPORTION. Add Real.floor.

S Heard

SPEC-221. Add normal_status to DV_ORDERED. Adjusted invariants.

H Frankel
T Beale

SPEC-228: Add minor deviations from ISO 8601 to assumed date/time types.

H Frankel

SPEC-229: Minor date/time corrections. Allow 2-digit timezones.

H Frankel

SPEC-236: Change use of Character to Octet in DV_MULTIMEDIA.

G Grieve

SPEC-239: Add common parent type of OBJECT_VERSION_ID and HIER_OBJECT_ID.

H Frankel

SPEC-243: Add template_id to ARCHETYPED class.

T Beale

SPEC-246: Correct openEHR terminology rubrics.

B Verhees
M Forss

Release 1.0

1.5

SPEC-162. Allow party identifiers when no demographic data. Relax invariant on PARTY_REF.

S Heard
H Frankel

06 Feb 2006

SPEC-184. Separate out terminology from Support IM.

T Beale

SPEC-188: Add generating_type function to ANY for use in invariants.

T Beale

SPEC-161. Support distributed versioning. Move OBJECT_ID.version to subtypes. Add OBJECT_VERSION_ID, VERSION_TREE_ID and LOCATABLE_REF types.

T Beale
H Frankel

Release 0.96

1.3

SPEC-135: Minor corrections to rm.support.terminology package.
SPEC-126. Correct details of partial date/time classes.
SPEC-112. Add DV_PARTIAL_DATE_TIME class

D Lloyd

25 Jun 2005

Release 0.95

1.2.1

SPEC-129. Fix errors in UML & specs of Identification package. Adjust invariants & postcondition of OBJECT_ID, HIER_OBJECT_ID, ARCHETYPE_ID and TERMINOLOGY_ID. Improve text to do with assumed abstract types Any and Ordered_numeric.

D Lloyd

25 Feb 2005

1.2

SPEC-128. Update Support assumed types to ISO 11404:2003.

T Beale

10 Feb 2005

SPEC-107. Add support for exclusion and inclusion of Interval limits.

A Goodchild

SPEC-116. Add PARTICIPATION.function vocabulary and invariant.

T Beale

SPEC-122. Fix UML in Terminology_access classes in Support model.

D Lloyd

SPEC-118. Make package names lower-case.

T Beale

SPEC-111. Move Identification Package to Support.

DSTC

SPEC-64. Re-evaluate COMPOSITION.is_persistent attribute. Add "composition category" vocabulary. Re-ordered vocabularies alphabetically.

D alra

Release 0.9

1.1

SPEC-47. Improve handling of codes for structural attributes. Populated Terminology and code_set codes.

S Heard

11 Mar 2004

1.0

SPEC-91. Correct anomalies in use of CODE_PHRASE and DV_CODED_TEXT. Add simple terminology service interface.

T Beale

09 Mar 2004

SPEC-95. Remove property attribute from Quantity package. Add simple measurement interface.

DSTC

Formally validated using ISE Eiffel 5.4.

T Beale

0.9.9

SPEC-63. ATTESTATION should have a status attribute.

D Kalra

13 Feb 2004

0.9.8

SPEC-68. Correct errors in INTERVAL class.

T Beale

20 Dec 2003

0.9.7

SPEC-32. Basic numeric type assumptions need to be stated.

DSTC

09 Oct 2003

SPEC-41. Visually differentiate primitive types in openEHR documents.
SPEC-43. Move External package to Common RM and rename to Identification (incorporates SPEC-36 - Add HIER_OBJECT_ID class, make OBJECT_ID class abstract.)

D Lloyd,
T Beale

0.9.6

SPEC-13. Rename key classes. Based on CEN ENV13606.
SPEC-38. Remove archetype_originator from multi-axial archetype id.
SPEC-39. Change archetype_id section separator from ':' to '-'.

T Beale

18 Sep 2003

0.9.5

SPEC-36. Add HIER_OBJECT_ID class, make OBJECT_ID class abstract.

T Beale

16 Aug 2003

0.9.4

SPEC-22. Code TERM_MAPPING.purpose.

G Grieve

20 Jun 2003

0.9.3

SPEC-7. Added forgotten terminologies for Subject_relationships and Provider_functions.

T Beale

11 Apr 2003

0.9.2

Detailed review by Ocean, DSTC, Grahame Grieve. Updated valid characters in OBJECT_ID.namespace.

G Grieve
DSTC

25 Mar 2003

0.9.1

Added specification for BOOLEAN type. Corrected minor error in ISO 639 standard strings - now conformant to TERMINOLOGY_ID. OBJECT_ID.version_id now optional. Improved document structure.

T Beale

18 Mar 2003

0.9

Initial Writing. Taken from Data types and Common Reference Models. Formally validated using ISE Eiffel 5.2.

T Beale

25 Feb 2003

Acknowledgements

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;

  • Distributed Systems Technology Centre (DSTC), under the Cooperative Research Centres Program through the Department of the Prime Minister and Cabinet of the Commonwealth Government of Australia.

Special thanks to David Ingram, Emeritus Professor of Health Informatics at UCL, who provided a vision and collegial working environment ever since the days of GEHR (1992).

1. Preface

1.1. Purpose

This document describes the openEHR Support Information Model, whose semantics are used by all openEHR Reference Models.

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.

1.2. Related Documents

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 https://specifications.openehr.org/releases/RM/latest/support.html.

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

TBD: (example To Be Determined paragraph)

1.4. Feedback

Feedback may be provided on the technical mailing list.

Issues may be raised on the specifications Problem Report tracker.

To see changes made due to previously reported issues, see the RM component Change Request tracker.

1.5. Conformance

Conformance of a data or software artifact to an openEHR 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 derivations from underlying models, ITS conformance indicates model conformance.

2. Support Package

2.1. Overview

The Support Reference Model comprises types used throughout the openEHR models, including assumed primitive types defined outside of openEHR. The package structure is illustrated below. The assumed_types 'pseudo-package' stands for types assumed by the openEHR specifcations to exist in an implementation technology, such as a programming language, schema language or database environment. The four Support packages define the semantics respectively for constants, terminology access, access to externally defined scientific units and conversion information. The class EXTERNAL_ENVIRONMENT_ACCESS is a mixin class providing access to the service interface classes.

RM support overview
Figure 1. rm.support and assumed_types Packages

2.2. Class Definitions

2.2.1. EXTERNAL_ENVIRONMENT_ACCESS Class

Class

EXTERNAL_ENVIRONMENT_ACCESS (abstract)

Description

A mixin class providing access to services in the external environment.

Inherit

TERMINOLOGY_SERVICE, MEASUREMENT_SERVICE

3. Assumed Types

Note
 These sections have been removed to a separate specification in the BASE component, as indicated in the sections below.

3.1. Inbuilt Primitive Types

Note
 The classes documented in this section are now available in the BASE component Foundation Types specification, Primitive Types section.

3.2. Assumed Library Types

Note
 The classes documented in this section are now available in the BASE component Foundation Types specification, Structure Types section.

3.3. Date/Time Types

Note
 The classes documented in this section are now available in the BASE component Foundation Types specification, Time Types section.

4. Identification Package

Note
 The classes documented in this section are now available in the BASE component Base Types specification, Definitions package section.

5. Terminology Package

5.1. Overview

This section describes the terminology package, which contains classes for accessing terminologies and code sets, including the openEHR Support Terminology, from within instances of classes defined in the reference model. The classes shown here would normally be inherited via the classes EXTERNAL_ENVIRONMENT_ACCESS and OPENEHR_DEFINITIONS, although the exact details of how this is done may vary depending on implementation language.

RM support.terminology
Figure 2. rm.support.terminology Package

5.2. Service Interface

5.2.1. Code Sets

A simple terminology service interface is defined according to FIGURE 6, enabling openEHR code sets and terminology to be referenced formally from within the Reference Model. Two types of coded entities are distinguished in openEHR, and are accessible via the service interface. The first is codes from 'code sets', which are the kind of terminology where the code stands for itself, such as the ISO 639-1 language codes. The identifiers themselves of these code sets do not appear to be standardised, but names such as "ISO_639-1" are expected to be used (see below).

In any case, code sets needed within the openEHR models themselves (e.g. for attributes whose value is a language code) are not referred to directly by an external name such as "ISO_639-1", but via an internal constant, in this case, the constant Code_set_id_languages, whose value is defined to be "languages". These constants are defined in the class OPENEHR_CODE_SET_IDENTIFIERS in the UML diagram. The mapping between the internal identifiers and external names should be done in configuration files. The service function TERMINOLOGY_SERVICE.code_set_for_id() is used to retrieve code sets on the basis of a constant. The current mapping and external identifiers assumed in openEHR is defined in the openEHR Support Terminology document. This use of indirection is employed to ensure that the obsoleting and superseding of code-sets does not directly affect openEHR software.

For code sets not mapped to internally used constants, i.e. code sets not required in the openEHR model itself, but otherwise known in the terminology service, the function TERMINOLOGY_SERVICE.code_set() can be used to retrieve these code sets by their external identifier.

5.2.2. Terminologies

Terminologies, including the openEHR Support Terminology are accessed via the TERMINOLOGY_SERVICE functions terminology() and terminology_identifiers(), where the argument includes "openehr", "centc251" (for CEN TC/251codes) and names from the US NLM terminologies list (see below). The openEHR Terminology supports groups, and the set of groups required by the reference model is defined in the class OPENEHR_TERMINOLOGY_GROUP_IDENTIFIERS. These groups correspond to coded attributes found in the openEHR Reference Model.

5.2.3. Terms and Codes in the openEHR Reference Model

True coded attributes in the Reference Model (i.e. attributes of type DV_CODED_TEXT), such as FEEDER_AUDIT.change_type are defined by an invariant in the enclosing class, such as the following:

Change_type_valid: terminology (Terminology_id_openehr).has_code_for_group_id
    (Group_id_audit_change_type, change_type.defining_code)

This is a formal way of saying that the attribute change_type must have a value such that its defining_code (its CODE_PHRASE) is in the set of CODE_PHRASEs in the openEHR Terminology which are in the group whose indentifier is Group_id_audit_change_type.

A similar invariant is used for attributes of type CODE_PHRASE, which come from a code_set. The following invariant appears in the class ENTRY (rm.composition.content.entry package):

Language_valid: media_type /= Void and then code_set (Code_set_languages).has_code (language)

5.3. Identifiers

In openEHR, the identifier of a terminology or code set is found in the terminology_id attribute of the class CODE_PHRASE (Data Types Information Model, text package).

5.3.1. Code Set Identifiers

Internal code set identifiers (such as "languages") used in openEHR are defined in the class OPENEHR_CODE_SET_IDENTIFIERS; assumed external identifiers (such as "ISO_639-1") for code sets used by the openEHR Reference Model are defined in the openEHR Support Terminology document.

5.3.2. Terminology Identifiers

Valid identifiers that can be used for this attribute for terminologies include but are not limited to the following:

  • "openehr"

  • "centc251"

  • an identifier value from the first column of the US National Library or Medicine (NLM) UMLS terminology identifiers table below, in either of two forms:

    • as is, e.g. "ICD10AM_2000", "ICPC93";

    • with any trailing section starting with an underscore removed, e.g. "ICD10AM".

Other identification schemes are used in some standards, such as ISO Oids. These are not specified for direct use in openEHR for various reasons:

  • they are not currently used by the NLM, and no definitive published list of terminology identifiers is available;

  • ISO Oids are long identifiers and may significantly increase the size of persisted information due to the ubiquity of coded terms;

  • determing the identity of the terminology in data always requires a request to a service containing the Oid / name mapping;

  • there is a safety factor in having human readable terminology identifiers in the data.

The use of Oid-based or other terminology identification schemes is not however incompatible with openEHR; all that is required is a terminology identifier / name mapping service or table.

The following table is a snapshot of the US National Library of Medicine UMLS terminology identifiers list. A definitive up-to-date list may be found on the NLM website [NLM_UML_list].

UMLS 2003 Terminology Identifiers

Identifier

Description

AIR93

AI/RHEUM,1993

ALT2000

Alternative Billing Concepts, 2000

AOD2000

Alcohol and Other Drug Thesaurus, 2000

BI98

Beth Israel Vocabulary, 1.0

BRMP2002

Portuguese translation of the Medical Subject Headings, 2002

BRMS2002

Spanish translation of the Medical Subject Headings, 2002

CCPSS99

Canonical Clinical Problem Statement System, 1999

CCS99

Clinical Classifications Software, 1999

CDT4

Current Dental Terminology(CDT), 4

COSTAR_89-95

COSTAR, 1989-1995

CPM93

Medical Entities Dictionary, 1993

CPT01SP

Physicians' Current Procedural Terminology, Spanish Translation, 2001

CPT2003

Physicians' Current Procedural Terminology, 2003

CSP2002

CRISP Thesaurus, 2002

CST95

COSTART, 1995

DDB00

Diseases Database, 2000

DMD2003

German translation of the Medical Subject Headings, 2003

DMDICD10_1995

German translation of ICD10, 1995

DMDUMD_1996

German translation of UMDNS, 1996

DSM3R_1987

DSM-III-R, 1987

DSM4_1994

DSM-IV, 1994

DUT2001

Dutch Translation of the Medical Subject Headings, 2001

DXP94

DXplain, 1994

FIN2003

Finnish translations of the Medical Subject Headings, 2003

HCDT4

HCPCS Version of Current Dental Terminology(CDT), 4

HCPCS03

Healthcare Common Procedure Coding System, 2003

HCPT03

HCPCS Version of Current Procedural Terminology(CPT), 2003

HHC96

Home Health Care Classification, 1996

HL7_1998-2002

Health Level Seven Vocabulary, 1998-2002

HLREL_1998

ICPC2E-ICD10 relationships from Dr. Henk Lamberts, 1998

HPC99

Health Product Comparison System, 1999

ICD10AE_1998

ICD10, American English Equivalents, 1998

ICD10AMAE_2000

International Statistical Classification of Diseases and Related Health Problems, Australian Modification, Americanized English Equivalents, 2000

ICD10AM_2000

International Statistical Classification of Diseases and Related Health Problems, 10th Revision, Australian Modification, January 2000 Release

ICD10_1998

ICD10, 1998

ICD9CM_2003

ICD-9-CM, 2003

ICPC2AE_1998

International Classification of Primary Care, Americanized English Equivalents, 2E, 1998

ICPC2E_1998

International Classification of Primary Care 2nd Edition, Electronic, 2E, 1998

ICPC2P_2000

International Classification of Primary Care, Version2-Plus, 2000

ICPC93

International Classification of Primary Care, 1993

ICPCBAQ_1993

ICPC, Basque Translation, 1993

ICPCDAN_1993

ICPC, Danish Translation, 1993

ICPCDUT_1993

ICPC, Dutch Translation, 1993

ICPCFIN_1993

ICPC, Finnish Translation, 1993

ICPCFRE_1993

ICPC, French Translation, 1993

ICPCGER_1993

ICPC, German Translation, 1993

ICPCHEB_1993

ICPC, Hebrew Translation, 1993

ICPCHUN_1993

ICPC, Hungarian Translation, 1993

ICPCITA_1993

ICPC, Italian Translation, 1993

ICPCNOR_1993

ICPC, Norwegian Translation, 1993

ICPCPAE_2000

International Classification of Primary Care ,Version2-Plus, Americanized English Equivalents, 2000

ICPCPOR_1993

ICPC, Portuguese Translation, 1993

ICPCSPA_1993

ICPC, Spanish Translation, 1993

ICPCSWE_1993

ICPC, Swedish Translation, 1993

INS2002

French translation of the Medical Subject Headings, 2002

ITA2003

Italian translation of Medical Subject Headings, 2003

JABL99

Online Congenital Multiple Anomaly/ Mental Retardation Syndromes, 1999

LCH90

Library of Congress Subject Headings, 1990

LNC205

LOINC, 2.05

LOINC

LOINC

MCM92

McMaster University Epidemiology Terms, 1992

MDDB99

MasterDrug DataBase, 1999

MDR51

Medical Dictionary for Regulatory Activities Terminology (MedDRA), 5.1

MDRAE51

Medical Dictionary for Regulatory Activities Terminology (MedDRA), American English Equivalents, 5.1

MDREA51

Medical Dictionary for Regulatory Activities Terminology (MedDRA), American English, with expanded abbreviations, 5.1

MDREX51

Medical Dictionary for Regulatory Activities Terminology (MedDRA), with expanded abbreviations, 5.1

MDRPOR51

Medical Dictionary for Regulatory Activities Terminology (MedDRA), 5.1, Portuguese Edition

MDRSPA51

Medical Dictionary for Regulatory Activities Terminology (MedDRA), 5.1, Spanish Edition

MIM93

Online Mendelian Inheritance in Man, 1993

MMSL01

Multum MediSource Lexicon, 2001

MMX01

Micromedex DRUGDEX, 2001-08

MSH2003_2002_10_24

Medical Subject Headings, 2002_10_24

MTH

UMLS Metathesaurus

MTHCH03

Metathesaurus CPT Hierarchical Terms, 2003

MTHHH03

Metathesaurus HCPCS Hierarchical Terms, 2003

MTHICD9_2003

Metathesaurus additional entry terms for ICD-9-CM, 2003

MTHMST2001

Metathesaurus Version of Minimal Standard Terminology Digestive Endoscopy, 2001

MTHMSTFRE_2001

Metathesaurus Version of Minimal Standard Terminology Digestive Endoscopy, French Translation, 2001

MTHMSTITA_2001

Metathesaurus Version of Minimal Standard Terminology Digestive Endoscopy, Italian Translation, 2001

NAN99

Classification of Nursing Diagnoses, 1999

NCBI2001

NCBI Taxonomy, 2001

NCI2001a

NCI Thesaurus, 2001a

NCISEER_1999

NCISEER ICD Neoplasm Code Mappings, 1999

NDDF01

FirstDataBank National Drug DataFile, 2001-07

NEU99

Neuronames Brain Hierarchy, 1999

NIC99

Nursing Interventions Classification, 1999

NOC97

Nursing Outcomes Classification, 1997

OMIM97

OMIM, Online Mendelian Inheritance in Man, 1997

OMS94

Omaha System, 1994

PCDS97

Patient Care Data Set, 1997

PDQ2002

Physician Data Query, 2002

PPAC98

Pharmacy Practice Activity Classification , 1998

PSY2001

Thesaurus of Psychological Index Terms, 2001

QMR96

Quick Medical Reference (QMR), 1996

RAM99

QMR clinically related terms from Randolph A. Miller, 1999

RCD99

Clinical Terms Version 3 (CTV3) (Read Codes), 1999

RCDAE_1999

Read thesaurus, American English Equivalents, 1999

RCDSA_1999

Read thesaurus Americanized Synthesized Terms, 1999

RCDSY_1999

Read thesaurus, Synthesized Terms, 1999

RUS2003

Russian Translation of MeSH, 2003

RXNORM_03AA

RXNORM Project, META2003AA

SNM2

SNOMED-2, 2

SNMI98

SNOMED International, 1998

SNOMED-CT

SNOMED International Clinical Terms, 2002

SPN02

Standard Product Nomenclature, 2002

SRC

Metathesaurus Source Terminology Names

ULT93

UltraSTAR, 1993

UMD2003

UMDNS: product category thesaurus, 2003

UMLS

UMLS: National Library of Medicine, USA

UWDA155

University of Washington Digital Anatomist, 1.5.5

VANDF01

Veterans Health Administration National Drug File, 2001

WHO97

WHO Adverse Reaction Terminology, 1997

WHOFRE_1997

WHOART, French Translation, 1997

WHOGER_1997

WHOART, German Translation, 1997

WHOPOR_1997

WHOART, Portuguese Translation, 1997

WHOSPA_1997

WHOART, Spanish Translation, 1997

5.4. Class Definitions

5.4.1. TERMINOLOGY_SERVICE Class

Class

TERMINOLOGY_SERVICE

Description

Defines an object providing proxy access to a terminology service.

Inherit

OPENEHR_TERMINOLOGY_GROUP_IDENTIFIERS, OPENEHR_CODE_SET_IDENTIFIERS

Functions

Signature

Meaning

terminology (
name: String[1]
): TERMINOLOGY_ACCESS

Return an interface to the terminology named name. Allowable names include:-

code_set (
name: String[1]
): CODE_SET_ACCESS
Pre: has_code_set (name)

Return an interface to the code_set identified by the external identifier name (e.g. ISO_639-1).

code_set_for_id (
id: String[1]
): CODE_SET_ACCESS
Pre: valid_code_set_id (id)

Return an interface to the code_set identified internally in openEHR by id.

has_terminology (
name: String[1]
): Boolean

True if terminology named name known by this service. Allowable names include:-

has_code_set (
name: String[1]
): Boolean

True if code_set linked to internal name (e.g. languages ) is available.

terminology_identifiers (): List<String>

Set of all terminology identifiers known in the terminology service. Values from the US NLM UMLS meta-data list at:- http://www.nlm.nih.gov/research/umls/metaa1.html

openehr_code_sets (): Hash<String, String>

Set of all code set identifiers known in the terminology service.

code_set_identifiers (): List<String>

Set of all code sets identifiers for which there is an internal openEHR name; returned as a Map of ids keyed by internal name.

5.4.2. TERMINOLOGY_ACCESS Interface

Interface

TERMINOLOGY_ACCESS

Description

Defines an object providing proxy access to a terminology.

Functions

Signature

Meaning

id (): String

Identification of this Terminology.

all_codes (): CODE_PHRASE

Return all codes known in this terminology.

codes_for_group_id (
a_group_id: String[1]
): List<CODE_PHRASE>

Return all codes under grouper 'a_group_id' from this terminology.

codes_for_group_name (
a_lang: String[1],
a_name: String[1]
): List<CODE_PHRASE>

Return all codes under grouper whose name in 'a_lang' is 'a_name' from this terminology.

has_code_for_group_id (): Boolean

True if a_code' is known in group group_id' in the openEHR terminology.

rubric_for_code (
a_code: String[1]
): String

Return all rubric of code code' in language lang'.

5.4.3. CODE_SET_ACCESS Interface

Interface

CODE_SET_ACCESS

Description

Defines an object providing proxy access to a code_set.

Functions

Signature

Meaning

id (): String

External identifier of this code set.

all_codes (): List<CODE_PHRASE>

Return all codes known in this code set.

has_lang (
a_lang: String[1]
): Boolean

True if code set knows about 'a_lang' .

has_code (
a_code: String[1]
): Boolean

True if code set knows about 'a_code'.

5.4.4. OPENEHR_TERMINOLOGY_GROUP_IDENTIFIERS Class

Class

OPENEHR_TERMINOLOGY_GROUP_IDENTIFIERS

Description

List of identifiers for groups in the openEHR terminology.

Constants

Signature

Meaning

1..1

Terminology_id_openehr: String = "openehr"

Name of openEHR’s own terminology.

1..1

Group_id_audit_change_type: String = "audit change type"

1..1

Group_id_attestation_reason: String = "attestation reason"

1..1

Group_id_composition_category: String = "composition category"

1..1

Group_id_event_math_function: String = "event math function"

1..1

Group_id_instruction_states: String = "instruction states"

1..1

Group_id_instruction_transitions: String = "instruction transitions"

1..1

Group_id_null_flavours: String = "null flavours"

1..1

Group_id_property: String = "property"

1..1

Group_id_participation_function: String = "participation function"

1..1

Group_id_participation_mode: String = "participation mode"

1..1

Group_id_setting: String = "setting"

1..1

Group_id_term_mapping_purpose: String = "term mapping purpose"

1..1

Group_id_subject_relationship: String = "subject relationship"

1..1

Group_id_version_life_cycle_state: String = "version lifecycle state"

Functions

Signature

Meaning

valid_terminology_group_id (
an_id: Boolean[1]
): Boolean

Validity function to test if an identifier is in the set defined by this class.

5.4.5. OPENEHR_CODE_SET_IDENTIFIERS Class

Class

OPENEHR_CODE_SET_IDENTIFIERS

Description

List of identifiers for code sets in the openEHR terminology.

Constants

Signature

Meaning

1..1

Code_set_id_character_sets: String = "character sets"

1..1

Code_set_id_compression_algorithms: String = "compression algorithms"

1..1

Code_set_id_countries: String = "countries"

1..1

Code_set_integrity_check_algorithms: String = "integrity check algorithms"

1..1

Code_set_id_languages: String = "languages"

1..1

Code_set_id_media_types: String = "media types"

1..1

Code_set_id_normal_statuses: String = "normal statuses"

Functions

Signature

Meaning

valid_code_set_id (
an_id: String[1]
): Boolean

Validity function to test if an identifier is in the set defined by this class.

6. Measurement Package

6.1. Overview

The Measurement package defines a minimum of semantics relating to quantitative measurement, units, and conversion, enabling the Quantity package of the openEHR Data Types Information Model to be correctly expressed. As for the Terminology package, a simple service interface is assumed, which provides useful functions to other parts of the reference model. The definitions underlying measurement and units come from a variety of sources, including:

These of course rest in turn upon a vast amount of literature and standards, mainly from ISO on the subject of scientific measurement.

6.2. Service Interface

A simple measurement data service interface is defined according to the figure below, enabling quantitative semantics to be used formally from within the Reference Model. Note that this service as currently defined in no way seeks to properly model the semantics of units, conversions etc - it provides only the minimum functions required by the openEHR Reference Model.

RM support.measurement
Figure 3. rm.support.measurement Package

6.3. Class Definitions

6.3.1. TERMINOLOGY_SERVICE Class

Class

TERMINOLOGY_SERVICE

Description

Defines an object providing proxy access to a terminology service.

Inherit

OPENEHR_TERMINOLOGY_GROUP_IDENTIFIERS, OPENEHR_CODE_SET_IDENTIFIERS

Functions

Signature

Meaning

terminology (
name: String[1]
): TERMINOLOGY_ACCESS

Return an interface to the terminology named name. Allowable names include:-

code_set (
name: String[1]
): CODE_SET_ACCESS
Pre: has_code_set (name)

Return an interface to the code_set identified by the external identifier name (e.g. ISO_639-1).

code_set_for_id (
id: String[1]
): CODE_SET_ACCESS
Pre: valid_code_set_id (id)

Return an interface to the code_set identified internally in openEHR by id.

has_terminology (
name: String[1]
): Boolean

True if terminology named name known by this service. Allowable names include:-

has_code_set (
name: String[1]
): Boolean

True if code_set linked to internal name (e.g. languages ) is available.

terminology_identifiers (): List<String>

Set of all terminology identifiers known in the terminology service. Values from the US NLM UMLS meta-data list at:- http://www.nlm.nih.gov/research/umls/metaa1.html

openehr_code_sets (): Hash<String, String>

Set of all code set identifiers known in the terminology service.

code_set_identifiers (): List<String>

Set of all code sets identifiers for which there is an internal openEHR name; returned as a Map of ids keyed by internal name.

7. Definition Package

Note
 The classes documented in this section are now available in the BASE component Base Types specification, Definitions package section.

References

Publications - e-Health

Articles, Books

  1. [Beale_2000] Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information Systems. 2000. Available at http://www.openehr.org/files/resources/publications/archetypes/archetypes_beale_web_2000.pdf .

  2. [Beale_2002] Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information Systems. Eleventh OOPSLA Workshop on Behavioral Semantics: Serving the Customer (Seattle, Washington, USA, November 4, 2002). Edited by Kenneth Baclawski and Haim Kilov. Northeastern University, Boston, 2002, pp. 16-32. Available at http://www.openehr.org/files/resources/publications/archetypes/archetypes_beale_oopsla_2002.pdf .

  3. [Beale_Heard_2007] Beale T, Heard S. An Ontology-based Model of Clinical Information. 2007. pp760-764 Proceedings MedInfo 2007, K. Kuhn et al. (Eds), IOS Publishing 2007. See http://www.openehr.org/publications/health_ict/MedInfo2007-BealeHeard.pdf.

  4. [Cimino_1997] Cimino J J. Desiderata for Controlled Medical vocabularies in the Twenty-First Century. IMIA WG6 Conference, Jacksonville, Florida, Jan 19-22, 1997.

  5. [Elstein_1987] Elstein AS, Shulman LS, Sprafka SA. Medical problem solving: an analysis of clinical reasoning. Cambridge, MA: Harvard University Press 1987.

  6. [Elstein_Schwarz_2002] Elstein AS, Schwarz A. Evidence base of clinical diagnosis: Clinical problem solving and diagnostic decision making: selective review of the cognitive literature. BMJ 2002;324;729-732.

  7. [Ingram_1995] Ingram D. The Good European Health Record Project. Laires, Laderia Christensen, Eds. Health in the New Communications Age. Amsterdam: IOS Press; 1995; pp. 66-74.

  8. [Object_Z] Smith G. The Object Z Specification Language. Kluwer Academic Publishers 2000. See http://www.itee.uq.edu.au/~smith/objectz.html .

  9. [GLIF] Lucila Ohno-Machado, John H. Gennari, Shawn N. Murphy, Nilesh L. Jain, Samson W. Tu, Diane E. Oliver, Edward Pattison-Gordon, Robert A. Greenes, Edward H. Shortliffe, and G. Octo Barnett. The GuideLine Interchange Format - A Model for Representing Guidelines. J Am Med Inform Assoc. 1998 Jul-Aug; 5(4): 357–372.

  10. [Rector_1994] Rector A L, Nowlan W A, Kay S. Foundations for an Electronic Medical Record. The IMIA Yearbook of Medical Informatics 1992 (Eds. van Bemmel J, McRay A). Stuttgart Schattauer 1994.

  11. [Rector_1999] Rector A L. Clinical terminology: why is it so hard? Methods Inf Med. 1999 Dec;38(4-5):239-52. Available at http://www.cs.man.ac.uk/~rector/papers/Why-is-terminology-hard-single-r2.pdf .

  12. [Sottile_1999] Sottile P.A., Ferrara F.M., Grimson W., Kalra D., and Scherrer J.R. The holistic healthcare information system. Toward an Electronic Health Record Europe. 1999. Nov 1999; 259-266.

  13. [Van_de_Velde_Degoulet_2003] Van de Velde R, Degoulet P. Clinical Information Systems: A Component-Based Approach. 2003. Springer-Verlag New York.

  14. [Weed_1969] Weed LL. Medical records, medical education and patient care. 6 ed. Chicago: Year Book Medical Publishers Inc. 1969.

Standards

  1. [Corbamed_PIDS] Object Management Group. Person Identification Service. March 1999. See http://www.omg.org/spec/PIDS/ .

  2. [Corbamed_LQS] Object Management Group. Lexicon Query Service. March 1999. http://www.omg.org/spec/LQS/ .

  3. [hl7_cda] HL7 International. HL7 version Clinical Document Architecture (CDA). Available at http://www.hl7.org.uk/version3group/cda.asp.

  4. [HL7v3_ballot2] HL7 International. HL7 version 3 2nd Ballot specification. Available at http://www.hl7.org.

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

  6. [hl7_v3_rim] HL7 International. HL7 v3 RIM. See http://www.hl7.org .

  7. [hl7_arden] HL7 International. HL7 Arden Syntax. See http://www.hl7.org/Special/committees/Arden/index.cfm .

  8. [hl7_gello] HL7 International. GELLO Decision Support Language. http://www.hl7.org/implement/standards/product_brief.cfm?product_id=5 .

  9. [IHTSDO_URIs] IHTSDO. SNOMED CT URI Standard. http://ihtsdo.org/fileadmin/user_upload/doc/download/doc_UriStandard_Current-en-US_INT_20140527.pdf?ok.

  10. [NLM_UML_list] National Library of Medicine. UMLS Terminologies List. http://www.nlm.nih.gov/research/umls/metaa1.html.

  11. [ISO_13606-1] ISO 13606-1 - Electronic healthcare record communication - Part 1: Extended architecture. See https://www.iso.org/standard/40784.html.

  12. [ISO_13606-2] ISO 13606-2 - Electronic healthcare record communication - Part 2: Domain term list. See https://www.iso.org/standard/50119.html.

  13. [ISO_13606-3] ISO 13606-3 - Electronic healthcare record communication - Part 3: Distribution rules. See https://www.iso.org/standard/50120.html.

  14. [ISO_13606-4] ISO 13606-4 - Electronic Healthcare Record Communication standard Part 4: Messages for the exchange of information. See https://www.iso.org/standard/50121.html.

  15. [ISO_18308] Schloeffel P. (Editor). Requirements for an Electronic Health Record Reference Architecture. See https://www.iso.org/standard/52823.html.

  16. [ISO_20514] ISO. The Integrated Care EHR. See https://www.iso.org/standard/39525.html .

  17. [ISO_13940] ISO. Health informatics - System of concepts to support continuity of care. See https://www.iso.org/standard/58102.html.

  18. [ISO_22600] ISO. Health informatics - Privilege management and access control. See https://www.iso.org/standard/62653.html.

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 http://www.chime.ucl.ac.uk/HealthI/EHCR-SupA/del1-4v1_3.PDF.

  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 http://www.chime.ucl.ac.uk/HealthI/EHCRSupA/documents.htm.

  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 http://www.chime.ucl.ac.uk/HealthI/EHCR-SupA/documents.htm.

  4. [EHCR_supA_31_32] Lloyd D, et al. EHCR Support Action Deliverable 3.1&3.2 “Interim Report to CEN”. July 1998. Available at http://www.chime.ucl.ac.uk/HealthI/EHCR-SupA/documents.htm.

  5. [GEHR_del_4] Deliverable 4: GEHR Requirements for Clinical Comprehensiveness. GEHR Project 1992. Available at http://www.openehr.org/files/resources/related_projects/gehr/gehr_deliverable-4.pdf .

  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. Available at http://www.openehr.org/files/resources/related_projects/gehr/gehr_deliverable-8.pdf .

  8. [GEHR_del_19_20_24] Deliverable 19,20,24: GEHR Architecture. GEHR Project 30/6/1995. Available at http://www.openehr.org/files/resources/related_projects/gehr/gehr_deliverable-19_20_24.pdf .

  9. [GeHR_AUS] Heard S, Beale T. The Good Electronic Health Record (GeHR) (Australia). See http://www.openehr.org/resources/related_projects#gehraus .

  10. [GeHR_Aus_gpcg] Heard S. GEHR Project Australia, GPCG Trial. See http://www.openehr.org/resources/related_projects#gehraus .

  11. [GeHR_Aus_req] Beale T, Heard S. GEHR Technical Requirements. See http://www.openehr.org/files/resources/related_projects/gehr_australia/gehr_requirements.pdf .

  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. See http://discovery.ucl.ac.uk/66235/ .

  15. [synex] University College London. SynEx project. http://www.chime.ucl.ac.uk/HealthI/SynEx/ .