openEHR logo

Resource Model Specification

Issuer: openEHR Specification Program

Release: latest

Status: STABLE

Revision: [latest_issue]

Date: [latest_issue_date]

Keywords: openehr, resources

openEHR components
© 2003 - 2018 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


SPECPUB-6Correct UML package nesting and paths in documents; insert base parent package; rename expressions package to expression.

T Beale

27 Nov 2017


SPECBASE-13: Separate out from openEHR Common IM 2.1.2 / RM Release 1.0.3.


15 Feb 2016

Re-engineer AUTHORED_RESOURCE classes according to AOM2 requirements.

T Beale,
S Garde,
I McNicoll,
H Leslie,
S Ljosland-Bakke,
D Bosca

R E L E A S E     1.0.1


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

Y S Lim

08 Apr 2007

SPEC-203: Release 1.0 explanatory text improvements.

A Patterson
G Grieve

R E L E A S E     0.95

SPEC-118. Make package names lower-case.

T Beale

R E L E A S E     0.9


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


09 Mar 2004

Formally validated using ISE Eiffel 5.4.

T Beale


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

T Beale

25 Feb 2003


Primary Author

  • Thomas Beale, Ars Semantica; openEHR Foundation Management Board.


This specification has benefited from formal and informal input from the openEHR and wider health informatics community. The openEHR Foundation would like to recognise the following people for their contributions.

  • Silje Ljosland Bakke, RN, National ICT health trust, Norway

  • Diego Boscá, IBIME, Technical University Valencia, VeraTech for Health, Spain

  • Sebastian Garde PhD, Ocean Health Systems, Germany

  • Grahame Grieve, Health Intersections, Australia

  • Heather Leslie MD, FRACGP, FACHI, Ocean Health Systems, Australia

  • Ian McNicoll MD, FreshEHR UK

  • Andrew Patterson PhD, LLM, Federation Health Software, Australia


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 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 Resource Model, a model of any 'authored resource', including identification, meta-data, annotations and translations.

The intended audience includes:

  • Standards bodies producing health informatics standards;

  • Academic groups using openEHR;

  • Solution vendors;

  • Medical informaticians and clinicians interested in health information.

Prerequisite documents for reading this document include:

1.3. Status

The content of this specification were separated out from the Common IM specification, in order to allow re-use by any openEHR component.

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. Resource Package

2.1. Overview

The openEHR BASE component resource package defines the structure and semantics of the general notion of an online resource which has been created by a human author, and consequently for which natural language is a factor. The package is illustrated below.

BASE resource
Figure 1. resource Package

2.1.1. Natural Languages and Translation

Authored resources contain natural language elements, and are therefore created in some original language, recorded in the orginal_language attribute of the AUTHORED_RESOURCE class. Information about translations is included in the translations attribute, which allows for one or more sets of translation details to be recorded. A resource is translated by doing the following:

  • translating every language-dependent element to the new language;

  • adding a new TRANSLATION_DETAILS instance to translations, containing details about the translator, organisation, quality assurance and so on.

  • any further translations to language-specific elements in a instances of descendent type of AUTHORED_RESOURCE.

The languages_available function provides a complete list of languages in the resource.

2.1.2. Meta-data

What is normally considered the 'meta-data' of a resource, i.e. its author, date of creation, purpose, and other descriptive items, is described by the RESOURCE_DESCRIPTION and RESOURCE_DESCRIPTION_ITEM classes. The parts of this that are in natural language, and therefore may require translated versions, are represented in instances of the RESOURCE_DESCRIPTION_ITEM class. Thus, if a RESOURCE_DESCRIPTION has more than one RESOURCE_DESCRIPTION_ITEM, each of these should carry exactly the same information in a different natural language.

The AUTHORED_RESOURCE.description attribute is optional, allowing for resources with no meta-data at all, e.g. resources in a partial state of construction. The translations attribute may still be required, since there may be other parts of the resource object (specified by a class into which AUTHORED_RESOURCE is inherited) that are language-dependent.

2.1.3. Revision History

When the resource is considered to be in a state where changes to it should be controlled, the is_controlled attribute is set to True, and all subsequent changes should have an audit trail recorded. Usually controlled resources would be managed in a versioned repository (e.g. implemented by CVS, Subversion or similar systems), and audit information will be stored somewhere in the repository (e.g. in version control files). The revision_history attribute defined in the AUTHORED_RESOURCE class is intended to act as a documentary copy of the revision history as known inside the repository, for the benefit of users of the resource. Given that resources in different places may well be managed in different kinds of repositories, having a copy of the revision history in a standardised form within the resource enables it to be used interoperably by authoring and other tools.

Every change to a resource committed to the relevant repository causes a new addition to the revision_history.

2.2. Class Descriptions





Abstract idea of an online resource created by a human author.





original_language: Terminology_code

Language in which this resource was initially authored. Although there is no language primacy of resources overall, the language of original authoring is required to ensure natural language translations can preserve quality. Language is relevant in both the description and ontology sections.


is_controlled: Boolean

True if this resource is under any kind of change control (even file copying), in which case revision history is created.



Description and lifecycle information of the resource.


uid: UUID

Unique identifier of the family of archetypes having the same interface identifier (same major version).



Annotations on individual items within the resource, keyed by path. The inner table takes the form of a Hash table of String values keyed by String tags.


translations: Hash<String,TRANSLATION_DETAILS>

List of details for each natural translation made of this resource, keyed by language. For each translation listed here, there must be corresponding sections in all language-dependent parts of the resource. The original_language does not appear in this list.




current_revision (): String
Post: Result = revision_history.most_recent_version

Most recent revision in revision_history if is_controlled else (uncontrolled) .

languages_available (): List<String>

Total list of languages available in this resource, derived from original_language and translations.


Original_language_valid: code_set (Code_set_id_languages).has_code (original_language.as_string)

Current_revision_valid: (current_revision /= Void and not is_controlled) implies current_revision.is_equal (“(uncontrolled)”)

Translations_valid: translations /= Void implies (not translations.is_empty and not translations.has (orginal_language.code_string))

Description_valid: translations /= Void implies (description.details.for_all (d | translations.has_key (d.language.code_string)))

Languages_available_valid: languages_available.has (original_language)

Revision_history_valid: is_controlled xor revision_history = Void





Class providing details of a natural language translation.





language: Terminology_code

Language of the translation, coded using ISO 639-1 (2 character) language codes.


author: Hash<String, String>

Translator name and other demographic details.


accreditaton: String

Accreditation of translator, usually a national translator’s registration or association membership id.


other_details: Hash<String, String>

Any other meta-data.


version_last_translated: String

Version of this resource last time it was translated into the language represented by this TRANSLATION_DETAILS object.





Defines the descriptive meta-data of a resource.





original_author: Hash<String, String>

Original author of this resource, with all relevant details, including organisation.


original_namespace: String

Namespace of original author’s organisation, in reverse internet form, if applicable.


original_publisher: String

Plain text name of organisation that originally published this artefact, if any.


other_contributors: List<String>

Other contributors to the resource, each listed in "name <email>" form.


lifecycle_state: Terminology_code

Lifecycle state of the resource, typically including states such as: initial, in_development, in_review, published, superseded, obsolete.


parent_resource: AUTHORED_RESOURCE = 

Reference to owning resource.


custodian_namespace: String

Namespace in reverse internet id form, of current custodian organisation.


custodian_organisation: String

Plain text name of current custodian organisation.


copyright: String

Optional copyright statement for the resource as a knowledge resource.


licence: String

Licence of current artefact, in format "short licence name <URL of licence>", e.g. "Apache 2.0 License <>"


ip_acknowledgements: Hash<String, String>

List of acknowledgements of other IP directly referenced in this archetype, typically terminology codes, ontology ids etc. Recommended keys are the widely known name or namespace for the IP source, as shown in the following example:

ip_acknowledgements = <
    ["loinc"] = <"This content from LOINC® is copyright © 1995 Regenstrief Institute, Inc. and the LOINC Committee, and available at no cost under the license at">
    ["snomedct"] = <"Content from SNOMED CT® is copyright © 2007 IHTSDO <>">


references: Hash<String, String>

List of references of material on which this artefact is based, as a keyed list of strings. The keys should be in a standard citation format.


resource_package_uri: String

URI of package to which this resource belongs.


conversion_details: Hash<String, String>

Details related to conversion process that generated this model from an original, if relevant, as a list of name/value pairs. Typical example with recommended tags:

conversion_details = <
    ["source_model"] = <"CEM model xyz <>">
    ["tool"] = <"cem2adl v6.3.0">
    ["time"] = <"2014-11-03T09:05:00">


other_details: Hash<String, String>

Additional non language-senstive resource meta-data, as a list of name/value pairs.



Details of all parts of resource description that are natural language-dependent, keyed by language code.





Language-specific detail of resource description. When a resource is translated for use in another language environment, each RESOURCE_DESCRIPTION_ITEM needs to be copied and translated into the new language.





language: Terminology_code

The localised language in which the items in this description item are written. Coded using ISO 639-1 (2 character) language codes.


purpose: String

Purpose of the resource.


keywords: List<String>

Keywords which characterise this resource, used e.g. for indexing and searching.


use: String

Description of the uses of the resource, i.e. contexts in which it could be used.


misuse: String

Description of any misuses of the resource, i.e. contexts in which it should not be used.


original_resource_uri: List<Hash<String, String>>

URIs of original clinical document(s) or description of which resource is a formalisation, in the language of this description item; keyed by meaning.


other_details: Hash<String, String>

Additional language-senstive resource metadata, as a list of name/value pairs.




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

e-Health Standards

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

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

  3. [hl7_cda] HL7 International. HL7 version Clinical Document Architecture (CDA). Available at

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

  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 .

  7. [hl7_arden] HL7 International. HL7 Arden Syntax. See .

  8. [hl7_gello] HL7 International. GELLO Decision Support Language. .


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

  11. [ISO_13606-1] ISO 13606-1 - Electronic healthcare record communication - Part 1: Extended architecture. See

  12. [ISO_13606-2] ISO 13606-2 - Electronic healthcare record communication - Part 2: Domain term list. See

  13. [ISO_13606-3] ISO 13606-3 - Electronic healthcare record communication - Part 3: Distribution rules. See

  14. [ISO_13606-4] ISO 13606-4 - Electronic Healthcare Record Communication standard Part 4: Messages for the exchange of information. See

  15. [ISO_18308] Schloeffel P. (Editor). Requirements for an Electronic Health Record Reference Architecture. See

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

  17. [ISO_13940] ISO. Health informatics - System of concepts to support continuity of care. See

  18. [ISO_22600] ISO. Health informatics - Privilege management and access control. 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. [EHCR_supA_31_32] 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. Available at .

  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 .

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

  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. See .

  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. See .

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

General Standards

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

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

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

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

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

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

  7. [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.

  8. [rfc_2440] RFC 2440: OpenPGP Message Format. See and

  9. [rfc_3986] RFC 3986: Uniform Resource Identifier (URI): Generic Syntax. IETF. See .

  10. [rfc_4122] RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace. IETF. See .

  11. [rfc_2781] IETF. RFC 2781: UTF-16, an encoding of ISO 10646 See

  12. [rfc_5646] IETF. RFC 5646. Available at

  13. [sem_ver] Semantic Versioning. .

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

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

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

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