openEHR logo

Demographic Information Model

Issuer: openEHR Specification Program

Release: RM latest

Status: STABLE

Revision: [latest_issue]

Date: [latest_issue_date]

Keywords: EHR, demographics, reference model, openehr
openEHR components
© 2003 - 2023 The openEHR Foundation

The openEHR Foundation is an independent, non-profit foundation, facilitating the sharing of health records by consumers and clinicians via open specifications, clinical models and open platform 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.1.0

2.0.5

SPECPUB-7: Convert citations to bibtex form.

T Beale

15 Dec 2019

SPECRM-88. Improve documentation relating to use of uid in versioning and LOCATABLE descendants in change_control package (addresses SPECPR-322).

P Pazos,
M Polajnar,
S Iancu,
T Beale

10 Oct 2019

RM Release 1.0.4

2.0.4

SPECRM-76: Add VERSIONED_PARTY class definition to demographics specs.
SPECRM-75: Fix description of PARTY.relationships (See SPECPR-104). SPECRM-82: Remove redefinition of PARTY.uid in UML; make ACTOR.languages and roles 0 to many (fixes SPECPR-282, SPECPR-283).

S Iancu

13 Nov 2018

SPECRM-46: Fix RM Release 1.0.3 typos and minor documentary errors: correct type of PARTY.type to DV_TEXT. (SPECPR-176).

S Iancu

04 Apr 2016

RM Release 1.0.3

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

Release 1.0.2

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

Release 1.0.1

2.0.1

SPEC-200: Correct Release 1.0 typographical errors.

D Lloyd

23 Feb 2006

Release 1.0

2.0

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

S Heard

25 Jan 2006

SPEC-190. Rename VERSION_REPOSITORY to VERSIONED_OBJECT.

T Beale

SPEC-194. Correct anomalies with LOCATABLE.uid.

H Frankel
T Beale

SPEC-161. Support distributed versioning.

T Beale
H Frankel

Release 0.96

Release 0.95

1.4.7

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

R Chen

12 Mar 2005

1.4.6

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

1.4.5

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

Release 0.9

1.4.4

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

D Lloyd

04 Oct 2003

1.4.3

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

S Heard,
D Kalra,
T Beale

15 Sep 2003

1.4.2

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

Z Tun

14 Aug 2003

1.4.1

SPEC-3. Removed ARCHETYPED and VERSIONABLE classes.

T Beale,
Z Tun

18 Mar 2003

1.4

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

T Beale

25 Feb 2003

1.3.1

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

1.3

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

1.2

General modifications, addition of CAPABILITY class.

T Beale,
D Lloyd

22 Oct 2002

1.1

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

1.0

Created from EHR RM.

T Beale

28 Aug 2002

Acknowledgements

Editor

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

Contributors

This specification benefited from wide 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.

  • Rong Chen MD, PhD, Cambio Healthcare Systems, Sweden

  • Heath Frankel, CTO Ocean Informatics, Australia

  • Sam Heard MD, Ocean Informatics, Australia

  • Sebastian Iancu, Architect, Code24, Netherlands

  • Dipak Kalra MD, PhD, Professor Health Informatics, CHIME, UCL, UK

  • David Lloyd (ret), CHIME, UCL, UK

  • Chunlan Ma PhD, MD, Ocean Informatics, Australia

  • Zar zar Tun, DSTC, Australia

Support

The work reported in this paper has been funded in part 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 architecture of the openEHR Demographic Information Model. The semantics are drawn from previous work in GEHR, existing models in ISO 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.

1.2. Related Documents

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 https://specifications.openehr.org/releases/RM/latest/demographic.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 openEHR RM specifications forum.

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. 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, 1997), and is influenced by clinical adaptations including work done in Australia and HL7v3 (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 Section 2.1.4 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 relationships of which it is the source. Every Party is stored in its own Version container.

2.2. Class Definitions

2.2.1. PARTY Class

Class

PARTY (abstract)

Description

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

Note
 It is strongly recommended that the inherited attribute uid be populated in PARTY objects, using the UID copied from the object_id() of the uid field of the enclosing VERSION object.
For example, the ORIGINAL_VERSION.uid 87284370-2D4B-4e3d-A3F3-F303D2F4F34B::uk.nhs.ehr1::2 would be copied to the uid field of the PARTY object.

Inherit

LOCATABLE

Attributes

Signature

Meaning

1..1

identities: List<PARTY_IDENTITY>

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

0..1

contacts: List<CONTACT>

Contacts for this party.

0..1

details: ITEM_STRUCTURE

All other details for this Party.

0..1

reverse_relationships: List<LOCATABLE_REF>

References to relationships in which this Party takes part as target.

0..1

relationships: List<PARTY_RELATIONSHIP>

Relationships in which this Party takes part as source.

Functions

Signature

Meaning

1..1

type (): DV_TEXT

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

Invariants

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

Uid_mandatory: uid /= Void

2.2.2. VERSIONED_PARTY Class

Class

VERSIONED_PARTY

Description

Static type formed by binding generic parameter of VERSIONED_OBJECT<T> to PARTY.

Inherit

VERSIONED_OBJECT

2.2.3. ROLE Class

Class

ROLE

Description

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.

Inherit

PARTY

Attributes

Signature

Meaning

0..1

time_validity: DV_INTERVAL<DV_DATE>

Valid time interval for this role.

1..1

performer: PARTY_REF

Reference to Version container of Actor playing the role.

0..1

capabilities: List<CAPABILITY>

The capabilities of this role.

Invariants

Capabilities_valid: capabilities /= Void implies not capabilities.empty

2.2.4. PARTY_RELATIONSHIP Class

Class

PARTY_RELATIONSHIP

Description

Generic description of a relationship between parties.

Inherit

LOCATABLE

Attributes

Signature

Meaning

0..1

details: ITEM_STRUCTURE

The detailed description of the relationship.

1..1

target: PARTY_REF

Target of relationship.

0..1

time_validity: DV_INTERVAL<DV_DATE>

Valid time interval for this relationship.

1..1

source: PARTY_REF

Source of relationship.

Functions

Signature

Meaning

1..1

type (): DV_TEXT

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

Invariants

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

2.2.5. PARTY_IDENTITY Class

Class

PARTY_IDENTITY

Description

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.

Inherit

LOCATABLE

Attributes

Signature

Meaning

1..1

details: ITEM_STRUCTURE

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

Functions

Signature

Meaning

1..1

purpose (): DV_TEXT

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

Invariants

Purpose_valid: purpose = name

2.2.6. CONTACT Class

Class

CONTACT

Description

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

Inherit

LOCATABLE

Attributes

Signature

Meaning

1..1

addresses: List<ADDRESS>

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

0..1

time_validity: DV_INTERVAL<DV_DATE>

Valid time interval for this contact descriptor.

Functions

Signature

Meaning

1..1

purpose (): DV_TEXT

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

Invariants

Purpose_valid: purpose = name

2.2.7. ADDRESS Class

Class

ADDRESS

Description

Address of contact, which may be electronic or geographic.

Inherit

LOCATABLE

Attributes

Signature

Meaning

1..1

details: ITEM_STRUCTURE

Archetypable structured address.

Functions

Signature

Meaning

1..1

type (): DV_TEXT

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

Invariants

Type_valid: type = name

2.2.8. CAPABILITY Class

Class

CAPABILITY

Description

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

Inherit

LOCATABLE

Attributes

Signature

Meaning

1..1

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.

0..1

time_validity: DV_INTERVAL<DV_DATE>

Valid time interval for the credentials of this capability.

2.2.9. ACTOR Class

Class

ACTOR (abstract)

Description

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

Inherit

PARTY

Attributes

Signature

Meaning

0..1

languages: List<DV_TEXT>

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

0..1

roles: List<PARTY_REF>

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

2.2.10. PERSON Class

Class

PERSON

Description

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

Inherit

ACTOR

2.2.11. ORGANISATION Class

Class

ORGANISATION

Description

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.

Inherit

ACTOR

2.2.12. GROUP Class

Class

GROUP

Description

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.

Inherit

ACTOR

2.2.13. AGENT Class

Class

AGENT

Description

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

Inherit

ACTOR

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

2.3.1.1. Person

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
2.3.1.2. Clinician
2.3.1.3. Credentials
2.3.1.4. Health Care Facility
2.3.1.5. Group

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

2.3.2.1. Familial Relationship
2.3.2.2. Employment Relationship
2.3.2.3. Patient

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

References

Fowler, M. (1997). Analysis Patterns: Reusable Object Models. Addison Wesley.