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

Licence

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

Support

Issues: https://openehr.atlassian.net/browse/SPECPR/
Web: http://www.openehr.org/

Amendment Record

Issue Details Raiser Completed

1.8.0

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

openEHR SEC

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

1.6.0

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

1.0

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

DSTC

09 Mar 2004

Formally validated using ISE Eiffel 5.4.

T Beale

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

Primary Author

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

Contributors

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

Supporters

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 http://www.openehr.org/releases/BASE/latest/release.html.

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

2.2.1. AUTHORED_RESOURCE Class

Class

AUTHORED_RESOURCE (abstract)

Description

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

Attributes

Signature

Meaning

1..1

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.

0..1

is_controlled: Boolean

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

0..1

description: RESOURCE_DESCRIPTION

Description and lifecycle information of the resource.

0..1

uid: UUID

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

0..1

annotations: RESOURCE_ANNOTATIONS

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.

0..1

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.

Functions

Signature

Meaning

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.

Invariants

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

2.2.2. TRANSLATION_DETAILS Class

Class

TRANSLATION_DETAILS

Description

Class providing details of a natural language translation.

Attributes

Signature

Meaning

1..1

language: Terminology_code

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

1..1

author: Hash<String, String>

Translator name and other demographic details.

0..1

accreditaton: String

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

0..1

other_details: Hash<String, String>

Any other meta-data.

0..1

version_last_translated: String

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

2.2.3. RESOURCE_DESCRIPTION Class

Class

RESOURCE_DESCRIPTION

Description

Defines the descriptive meta-data of a resource.

Attributes

Signature

Meaning

1..1

original_author: Hash<String, String>

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

0..1

original_namespace: String

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

0..1

original_publisher: String

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

0..1

other_contributors: List<String>

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

1..1

lifecycle_state: Terminology_code

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

1..1

parent_resource: AUTHORED_RESOURCE = 

Reference to owning resource.

0..1

custodian_namespace: String

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

0..1

custodian_organisation: String

Plain text name of current custodian organisation.

0..1

copyright: String

Optional copyright statement for the resource as a knowledge resource.

0..1

licence: String

Licence of current artefact, in format "short licence name <URL of licence>", e.g. "Apache 2.0 License <http://www.apache.org/licenses/LICENSE-2.0.html>"

0..1

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 http://loinc.org/terms-of-use">
    ["snomedct"] = <"Content from SNOMED CT® is copyright © 2007 IHTSDO <ihtsdo.org>">
>

0..1

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.

0..1

resource_package_uri: String

URI of package to which this resource belongs.

0..1

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 <http://location.in.clinicalelementmodels.com>">
    ["tool"] = <"cem2adl v6.3.0">
    ["time"] = <"2014-11-03T09:05:00">
>

0..1

other_details: Hash<String, String>

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

0..1

details: Hash<String,RESOURCE_DESCRIPTION_ITEM>

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

2.2.4. RESOURCE_DESCRIPTION_ITEM Class

Class

RESOURCE_DESCRIPTION_ITEM

Description

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.

Attributes

Signature

Meaning

1..1

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.

1..1

purpose: String

Purpose of the resource.

0..1

keywords: List<String>

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

0..1

use: String

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

0..1

misuse: String

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

0..1

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.

0..1

other_details: Hash<String, String>

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

References

Resources

General

  1. [cov_contra] Wikipedia. Covariance and contravariance. See https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science) .

e-Health 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.

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

General Standards

  1. [OCL] The Object Constraint Language 2.0. Object Management Group (OMG). Available at http://www.omg.org/cgi-bin/doc?ptc/2003-10-14 .

  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 https://en.wikipedia.org/wiki/ISO_8601.

  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.org. Perl Regular Expressions. Available at http://perldoc.perl.org/perlre.html .

  7. [rfc_2396] Berners-Lee T. Universal Resource Identifiers in WWW. Available at http://www.ietf.org/rfc/rfc2396.txt. 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 http://www.w3.org/Addressing for a starting point on URIs.

  8. [rfc_2440] RFC 2440: OpenPGP Message Format. See http://www.ietf.org/rfc/rfc2440.txt and http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-18.txt

  9. [rfc_3986] RFC 3986: Uniform Resource Identifier (URI): Generic Syntax. IETF. See http://www.ietf.org/rfc/rfc3986.txt .

  10. [rfc_4122] RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace. IETF. See http://www.ietf.org/rfc/rfc4122.txt .

  11. [rfc_2781] IETF. RFC 2781: UTF-16, an encoding of ISO 10646 See http://tools.ietf.org/html/rfc2781.

  12. [rfc_5646] IETF. RFC 5646. Available at http://tools.ietf.org/html/rfc5646.

  13. [sem_ver] Semantic Versioning. http://semver.org .

  14. [Xpath] W3C Xpath 1.0 specification. 1999. Available at http://www.w3.org/TR/xpath.

  15. [uri_syntax] Uniform Resource Identifier (URI): Generic Syntax, Internet proposed standard. January 2005. see http://www.ietf.org/rfc/rfc3986.txt .

  16. [w3c_owl] W3C. OWL - the Web Ontology Language. See http://www.w3.org/TR/2003/CR-owl-ref-20030818/ .

  17. [w3c_xpath] W3C. XML Path Language. See http://w3c.org/TR/xpath .