openEHR logo

Demographic Information Model

Issuer: openEHR Specification Program

Release: Release-1.0.3

Status: STABLE

Revision: [latest_issue]

Date: [latest_issue_date]

Keywords: EHR, demographics, 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.3


SPECRM-36: Remove ADDRESS.as_string() and PARTY_IDENTITY.as_string() functions.

S Iancu

15 Aug 2015

SPEC-45. Remove ACTOR.has_legal_entity() function.

S Iancu

R E L E A S E     1.0.2


SPEC-257: Correct minor typos and clarify text. Make PARTY_IDENTITY.details and ADDRESS.details mandatory in class definitions.

T Cook
C Ma,
R Chen

02 Aug 2008

R E L E A S E     1.0.1


SPEC-200: Correct Release 1.0 typographical errors.

D Lloyd

23 Feb 2006

R E L E A S E     1.0


SPEC-189. Add LOCATABLE.parent. New invariant in PARTY.

S Heard

25 Jan 2006


T Beale

SPEC-194. Correct anomalies with LOCATABLE.uid.

H Frankel
T Beale

SPEC-161. Support distributed versioning.

T Beale
H Frankel

R E L E A S E     0.96

R E L E A S E     0.95


SPEC-133. Remove details /= Void invariant from PARTY.

R Chen

12 Mar 2005


SPEC-48. Pre-release review of documents. Corrected STRUCTURE to be ITEM_STRUCTURE. Make ACTOR.languages a List not a Set.

D Lloyd

22 Feb 2005


SPEC-24. Revert meaning to STRING and rename as archetype_node_id.

S Heard,
T Beale

10 Jan 2005

SPEC-118. Make package names lower case.

T Beale

R E L E A S E     0.9


SPEC-41. Visually differentiate primitive types in openEHR documents.

D Lloyd

04 Oct 2003


SPEC-13. Rename key classes, according to CEN ENV 13606.

S Heard,
D Kalra,
T Beale

15 Sep 2003


SPEC-35. Clarify circular relationships between PARTY and PARTY_REL.

Z Tun

14 Aug 2003



T Beale,
Z Tun

18 Mar 2003


Formally validated using ISE Eiffel 5.2. Minor corrections to invariants.

T Beale

25 Feb 2003


Review by H Frankel, MCA. Corrections to diagrams and class texts. Improved PARTY_RELATIONSHIP semantics. Added Patient instance example. Made time_validity attributes optional.

T Beale

13 Feb 2003


Corrections to diagrams and class texts. Inheritance changed to ARCHETYPED for most key classes. Some instance examples added.

Z Tun,
T Beale

08 Jan 2003


General modifications, addition of CAPABILITY class.

T Beale,
D Lloyd

22 Oct 2002


Renamed CONTACT_DESCRIPTOR to CONTACT. Removed CONTACT.role. Renamed PARTY_ROLE to ROLE. Changed CONTACT.address to addresses. Renamed SPATIAL to STRUCTURE. Introduced PARTY and ACTOR classes.

T Beale

18 Sep 2002


Created from EHR RM.

T Beale

28 Aug 2002


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 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 Demographic Information Model. The semantics are drawn from previous work in GEHR, existing models in CEN 13606 and the HL7v3 RIM, and other work done in Australia.

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.

Prerequisite documents for reading this document include:

Other documents describing related models, 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. Demographic package

2.1. Overview

The demographic model illustrated in the UML diagram below is a generalised model of the facts one might expect to see in a demographic server. The purpose of the model is as a specification of a demographic service, either standalone, or a "wrapper" service for an existing system such as a patient master index (PMI). In the latter situation, it is used to add the required openEHR semantics, particularly versioning, to an existing service.

RM demographic
Figure 1. rm.demographic package

The general design is based on the scheme of party and accountability described by Fowler [Fowler_1997], and is influenced by clinical adaptations including work done in Australia and the HL7v3 RIM [HL7v3_ballot2] (itself influenced by the Fowler models).

One of the main design criteria of the model is that it expresses attributes and relationships of demographic entities which exist regardless of particular clinical involvements or participations in particular events. Participations are meaningful only within the context of the health record or other relevant model where they record context-specific relationships between demographic entities and events in the real world.

Another criterion is that instances of the classes in the model must be serialisable into an EHR Extract in an unambgiuous way. This requires that each PARTY be a self-contained hierarchy of data, in the same way as distinct COMPOSITIONs in the EHR model are distinct hierarchies in an Extract. In order to ensure this condition, PARTY_RELATIONSHIPs must be implemented correctly, so as to prevent endless traversal of all PARTY objects through their relationships, when serialising. See Party Relationships below for details.

2.1.1. Archetyping

The model is designed to be used with archetypes, hence the generic nature of all entities. Every class containing an attribute of the form details:`STRUCTURE` is a completely archetypable structure. As a result, archetypes can be defined for concepts such as particular kinds of PERSON, ORGANISATION; for actual ROLEs such as "health care practitioner", and for party identities and addresses.

2.1.2. Names and Addresses

Classes have been included for PARTY_IDENTITY and ADDRESS, even though they contain only a link to details, in the form of the generic STRUCTURE class. This is not strictly necessary - it could have been done simply using appropriately named attributes in the classes PARTY and CONTACT - but is done to provide a place to add specific semantics in future releases of the model. It is also expected to make software development easier, since it provides explicit classes to which behaviour and other implementation attributes can be added. Lastly, it allows the notions of PARTY_IDENTITY and ADDRESS to be explicitly used in archetype-authoring tools.

Instances of PARTY_IDENTITY, linked to PARTY by the attribute identities are intended to express the names of people, organisations, and other actors - that is names which are "owned" by the party, e.g. self-declared (in the case of institutions and companies) or by virtue of social relations (names given by parents, tribes etc). Identifiers of Parties given by other organisations, or the state are not represented in this way, and should be recorded in the PARTY.details structure instead (see below).

2.1.3. Party Identification

Identifiers of Parties given by organisations or the state are treated as any other attribute of a Party, i.e. recorded as part of the data in the PARTY.details structure. Identifiers of Party instances in the system are provided in the same way as identifiers of Compositions in the EHR: via the uid attribute (type OBJECT_VERSION_ID) of the containing VERSION. These identifiers are used in all cross-references between Parties, and between Parties and Party_relationships.

2.1.4. Party Relationships

Relationships between parties in the real world may be expressed using PARTY_RELATIONSHIP objects, as illustrated below.

general model
Figure 2. General Relationship Model

Relationships are considered directional, hence the use of the attribute names source and target, however, these names are otherwise neutral, and give no indication as to the meaning of the relationships, such as which party is responsible and which accountable (for comparison, see the demographic models of Fowler [Fowler_1997]). Accordingly, each Party involved in a relationship includes it in its relationships list, if it is at the source end, or in the reverse_relationships list, if at the target end.

The usual way to determine the directionality of a relationship between two Parties is usually by which Party’s actions caused the relationship to come into being. For example, a relationship representing the concept "patient", between a health consumer and a health care organisation would have the consumer as source and the organisation as target.

PARTY_RELATIONSHIPs are stored as part of the data of the PARTY designated as the source. This means that the relationships attribute is by value, while reverse_relationships is by references, as are PARTY_RELATIONSHIP.source and target. The actual kind of reference is via the use of OBJECT_REFs containing HIER_OBJECT_IDs to denote the Version container of a Party, rather than OBJECT_VERSION_IDs, which would denote particular versions. Logically this implements the semantic that such relationships in the real world are between continuants, i.e. the real Parties, not just one of their version instances in a demographic system.

2.1.5. Versioning Semantics

The class PARTY and its descendants ACTOR and ROLE are all potentially versioned in a demographic system. A Version of a PARTY includes all the compositional parts, such as identities, contacts, Party relatoinships of which it is the source. Every Party is stored in its own Version container.

2.2. Class Definitions

2.2.1. PARTY Class


PARTY (abstract)


Ancestor of all party types, including real world entities and their roles. A party is any entity which can participate in an activity. The name attribute inherited from LOCATABLE is used to indicate the actual type of party (note that the actual names, i.e. identities of parties are indicated in the identities attribute, not the name attribute).







identities: List<PARTY_IDENTITY>

Identities used by the party to identify itself, such as legal name, stage names, aliases, nicknames and so on.


contacts: List<CONTACT>

Contacts for this party.



All other details for this party.


reverse_relationships: List<LOCATABLE_REF>

Relationships in which this role takes part as target.


relationships: List<PARTY_RELATIONSHIP>

Relationships in which this role takes part as source.



Identifier of this Party.





Type of party, such as PERSON , ORGANISATION , etc. Role name, e.g. general practitioner , nurse , private citizen . Taken from inherited name attribute.


Type_valid: type = name

Contacts_valid: contacts /= Void implies not contacts.is_empty

Relationships_validity: relationships /= Void implies (not relationships.is_empty and then relationships.for_all (r | r.source = self)

Reverse_relationships_validity: reverse_relationships /= Void implies (not reverse_relationships.empty and then reverse_relationships.for_all (item | repository ("demographics").all_party_relationships.has_object (item) and then repository("demographics").all_party_relationships.object (item).target = self))

Is_archetype_root: is_archetype_root

2.2.2. ROLE Class




Generic description of a role performed by an actor. The role corresponds to a competency of the party. Roles are used to define the responsibilities undertaken by a party for a purpose. Roles should have credentials qualifying the performer to perform the role.







time_validity: DV_INTERVAL<DV_DATE>

Valid time interval for this role.


performer: PARTY_REF

Reference to Version container of Actor playing the role.


capabilities: List<CAPABILITY>

The capabilities of this role.


Capabilities_valid: capabilities /= Void implies not capabilities.empty





Generic description of a relationship between parties.








The detailed description of the relationship.


time_validity: DV_INTERVAL<DV_DATE>

Valid time interval for this relationship.


source: PARTY_REF

Source of relationship.


target: PARTY_REF

Target of relationship.




type: DV_TEXT

Type of relationship, such as employment, authority, health provision


Source_valid: source /= Void and then source.relationships.has (self)

Target_valid: target /= Void and then not target.reverse_relationships.has (self)

Type_validity: type = name





An identity owned by a PARTY, such as a person name or company name, and which is used by the party to identify itself. Actual structure is archetyped.








The value of the indentity. This will often taken the form of a parsable string or a small structure of strings.




purpose: DV_TEXT

Purpose of identity, e.g. legal , stagename , nickname , tribal name , trading name . Taken from value of inherited name attribute.


Purpose_valid: purpose = name

2.2.5. CONTACT Class




Description of a means of contact of a party. Actual structure is archetyped.







addresses: List<ADDRESS>

A set of address alternatives for this purpose and time validity.


time_validity: DV_INTERVAL<DV_DATE>

Valid time interval for this contact descriptor.




purpose: DV_TEXT

Purpose for which this contact is used, e.g. mail , daytime phone , etc. Taken from value of inherited name attribute.


Purpose_valid: purpose = name

2.2.6. ADDRESS Class




Address of contact, which may be electronic or geographic.











type: DV_TEXT

Type of address, e.g. electronic , locality . Taken from value of inherited name attribute.


Type_valid: type = name

2.2.7. CAPABILITY Class




Capability of a role, such as ehr modifier , health care provider . Capability should be backed up by credentials.







credentials: ITEM_STRUCTURE

The qualifications of the performer of the role for this capability. This might include professional qualifications and official identifications such as provider numbers etc.


time_validity: DV_INTERVAL<DV_DATE>

Valid time interval for the credentials of this capability.

2.2.8. ACTOR Class


ACTOR (abstract)


Ancestor of all real-world types, including people and organisations. An actor is any real-world entity capable of taking on a role.







languages: List<DV_TEXT>

Languages which can be used to communicate with this actor, in preferred order of use (if known, else order irrelevant).


roles: List<PARTY_REF>

Identifiers of the Version container for each Role played by this party.

2.2.9. PERSON Class




Generic description of persons. Provides a dedicated type to which Person archetypes can be targeted.



2.2.10. ORGANISATION Class




Generic description of organisations. An organisation is a legally constituted body whose existence (in general) outlives the existence of parties considered to be part of it.



2.2.11. GROUP Class




A group is a real world group of parties which is created by another party, usually an organisation, for some specific purpose. A typical clinical example is that of the specialist care team, e.g. cardiology team . The members of the group usually work together.



2.2.12. AGENT Class




Generic concept of any kind of agent, including devices, software systems, but not humans or organisations.



2.3. Instance Examples

In the following instance examples, the values of the attributes uid, source, target, and reverse_relationships are not meant to be taken as literally valid OBJECT_IDs - for the purposes of clarity, simple integers have been used.

2.3.1. Parties


The diagram below illustrates a possible set of instances for a PERSON, with home and work contact information. There are separate archetypes for the PERSON, each ADDRESS, and each PARTY_IDENTITY. In the following figure, "meaning" is the meaning from the value of the archetype_node_id attribute, functionally derived from the archetype local ontology.

person demographics
Figure 3. Person Demographic Information
Health Care Facility

The figure below illustrates the demographic information for a cadiac surgery team in a hospital. The group includes a head surgeon, anaesthetist, assistant surgeon, and presumably others (not shown). Each of these members of the team have an employment relationship with the hospital (shown only for one surgeon, in the interests of clarity).

group demographics
Figure 4. Group Demographics

2.3.2. Relationships

Familial Relationship
Employment Relationship

The figure below shows a simple way of representing the patient relationship between a person and a health care organisation.

simple patient relationship
Figure 5. Simple Patient Relationship

The following diagram shows the same logical relationship, but with both Parties acting through Roles, representing their status as healthcare consumer and healthcare provider respectively. Each of these Roles has associated credentials which document its official nature within the healthcare system.

roles and credentials
Figure 6. Patient Relationship with Roles and Credentials



  1. [Anderson_1996] Ross Anderson. Security in Clinical Information Systems. Available at

  2. [Baretto_2005] Barretto S A. Designing Guideline-based Workflow-Integrated Electronic Health Records. 2005. PhD dissertation, University of South Australia. Available at

  3. [Beale_2000] Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information Systems. 2000. Available at .

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

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

  6. [Booch_1994] Booch G. Object-Oriented Analysis and Design with applications. 2nd ed. Benjamin/Cummings 1994.

  7. [Browne_2005] Browne E D. Workflow Modelling of Coordinated Inter-Health-Provider Care Plans. 2005. PhD dissertation, University of South Australia. Available at

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

  9. [Eiffel] Meyer B. Eiffel the Language (2nd Ed). Prentice Hall, 1992.

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

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

  12. [Fowler_1997] Fowler M. Analysis Patterns: Reusable Object Models. Addison Wesley 1997

  13. [Fowler_Scott_2000] Fowler M, Scott K. UML Distilled (2nd Ed.). Addison Wesley Longman 2000.

  14. [Gray_reuter_1993] Gray J, Reuter A. Transaction Processing Concepts and Techniques. Morgan Kaufmann 1993.

  15. [Hein_2002] Hein J L. Discrete Structures, Logic and Computability (2nd Ed). Jones and Bartlett 2002.

  16. [Hnìtynka_2004] Hnìtynka P, Plášil F. Distributed Versioning Model for MOF. Proceedings of WISICT 2004, Cancun, Mexico, A volume in the ACM international conference proceedings series, published by Computer Science Press, Trinity College Dublin Ireland, 2004.

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

  18. [Kifer_Lausen_Wu_1995] Kifer M, Lausen G, Wu J. Logical Foundations of Object-Oriented and FrameBased Languages. JACM May 1995. See See

  19. [Kilov_1994] Kilov H, Ross J. Information Modelling - an object-oriented approach. Prentice Hall 1994.

  20. [Maier_2000] Maier M. Architecting Principles for Systems-of-Systems. Technical Report, University of Alabama in Huntsville. 2000. Available at

  21. [Martin] Martin P. Translations between UML, OWL, KIF and the WebKB-2 languages (For-Taxonomy, Frame-CG, Formalized English). May/June 2003. Available at as at Aug 2004.

  22. [Meyer_OOSC2] Meyer B. Object-oriented Software Construction, 2nd Ed. Prentice Hall 1997

  23. [Müller_2003] Müller R. Event-oriented Dnamic Adaptation of Workflows: Model, Architecture, and Implementation. 2003. PhD dissertation, University of Leipzig. Available at

  24. [Object_Z] Smith G. The Object Z Specification Language. Kluwer Academic Publishers 2000. See .

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

  26. [Rector] Rector A L. Clinical terminology: why is it so hard? Methods Inf Med. 1999 Dec;38(4-5):239-52. Available at .

  27. [Richards_1998] Richards E G. Mapping Time - The Calendar and its History. Oxford University Press 1998.

  28. [Sowa_2000] Sowa J F. Knowledge Representation: Logical, philosophical and Computational Foundations. 2000, Brooks/Cole, California.

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

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

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



  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. [CIMI] Clinical Information Modelling Initiative (CIMI) Project. See

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  16. [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] RFC 2440: OpenPGP Message Format. See and

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

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

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

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

  15. [sem_ver] Semantic Versioning. .

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

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

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

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


  1. [Template_Designer] Template Designer. Ocean Informatics.

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_adl14] The openEHR Foundation. Archetype Definition Language 1.4 (ADL1.4). Available at

  5. [openehr_am_aom14] The openEHR Foundation. Archetype Object Model 1.4 (AOM1.4). Available at

  6. [openehr_am_adl2] The openEHR Foundation. Archetype Definition Language 2 (ADL2). Available at

  7. [openehr_am_aom2] The openEHR Foundation. Archetype Object Model 2 (AOM2). Available at

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

  9. [openehr_am_def_pri] The openEHR Foundation. Archetype Definitions and Principles. (deprecated) Available at

  10. [openehr_am_sys] The openEHR Foundation. The Archetype System. (deprecated) Available at

  11. [openehr_am_oap] The openEHR Foundation. The openEHR Archetype Profile. .

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

  13. [openehr_odin] The openEHR Foundation. Object Data Instance Notation (ODIN). Available at

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

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

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

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

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

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

  20. [openehr_rm_ehr_extract] The openEHR Foundation. The EHR Extrct Information Model.

  21. [openehr_rm_integration] The openEHR Foundation. The Integration Information Model.

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

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

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