Demographic Information Model

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;
• Software development groups using openEHR;
• Academic groups using openEHR;
• The open source healthcare community;
• Medical informaticians and clinicians intersted in health information;
• Health data managers.

1.2 Related Documents

Prerequisite documents for reading this document include:

• The openEHR Architecture Overview
• The openEHR Modelling Guide
• The openEHR Support Information Model
• The openEHR Data Types Information Model

• The openEHR Common Information Model Other documents describing related models, include:

• The openEHR EHR Information Model
• The openEHR Demographic Model

1.3 Status

This document is under development, and is published as a proposal for input to standards processes and implementation works.

This document is available at http://svn.openehr.org/specification/TAGS/Release 1.0.1/publishing/architecture/rm/demographic_im.pdf .

The latest version of this document can be found at http://svn.openehr.org/specifica tion/TRUNK/publishing/architecture/rm/demographic_im.pdf .

1.4 Peer review

Areas where more analysis or explanation is required are indicated with “to be continued” paragraphs like the following:

To Be Continued: more work required

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 7 of 25 Date of Issue: 23 Feb 2006

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Introduction Demographic Information Model Rev 2.0.1

Reviewers are encouraged to comment on and/or advise on these paragraphs as well as the main content. Please send requests for information to info@openEHR.org. Feedback should preferably be provided on the mailing list openehr-technical@openehr.org, or by private email.

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

Date of Issue: 23 Feb 2006 Page 8 of 25 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Demographic Information Model Demographic Package Rev 2.0.1

2.1 Overview

The demographic model illustrated in FIGURE 1 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.

LOCATABLE

(rm.common.archetyped)

repository

VERSIONED_OBJECT<T>

(“demographics”)

(rm.common.change_control)

FIGURE 1 rm.demographic Package

The general design is based on the scheme of party and accountability described by Fowler [19] , and is influenced by clinical adaptations including work done in Australia [11] and the HL7v3 RIM [15] (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 particu

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 9 of 25 Date of Issue: 23 Feb 2006

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Demographic Package Demographic Information Model Rev 2.0.1

lar 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.4 Party Relationships

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

reverse_relationships

relationships

FIGURE 2 General Relationship Model

Date of Issue: 23 Feb 2006 Page 10 of 25 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Demographic Information Model Demographic Package Rev 2.0.1

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 [19] ). 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_REFscontaining 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.2 Class Definitions

2.2.1 PARTY Class

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 11 of 25 Date of Issue: 23 Feb 2006

Demographic Package Demographic Information Model Rev 2.0.1

2.2.2 PARTY_IDENTITY Class

Date of Issue: 23 Feb 2006 Page 12 of 25 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Demographic Information Model Demographic Package Rev 2.0.1

2.2.3 CONTACT Class

2.2.4 ADDRESS Class

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 13 of 25 Date of Issue: 23 Feb 2006

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Demographic Package Demographic Information Model Rev 2.0.1

2.2.5 ACTOR Class

Date of Issue: 23 Feb 2006 Page 14 of 25 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Demographic Information Model Demographic Package Rev 2.0.1

2.2.6 PERSON Class

2.2.7 ORGANISATION Class

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 15 of 25 Date of Issue: 23 Feb 2006

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Demographic Package Demographic Information Model Rev 2.0.1

2.2.8 GROUP Class

2.2.9 AGENT Class

2.2.10 ROLE Class

Date of Issue: 23 Feb 2006 Page 16 of 25 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Demographic Information Model Demographic Package Rev 2.0.1

2.2.11 CAPABILITY Class

2.2.12 PARTY_RELATIONSHIP Class

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 17 of 25 Date of Issue: 23 Feb 2006

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Demographic Package Demographic Information Model Rev 2.0.1

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

FIGURE 3 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

Date of Issue: 23 Feb 2006 Page 18 of 25 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Demographic Information Model Demographic Package Rev 2.0.1

the following figure, “meaning” is the meaning from the value of the archetype_node_id attribute, functionally derived from the archetype local ontology.

PARTY_IDENTITY

meaning = “person name” name = “legal name”

CONTACT

name = “home” time_validity =

12/jan/1998 -

ELEMENT

items

name = “first names” value = “Robert James”

LIST_S

meaning = “items” name = “items”

ELEMENT

name = “titles” value = “Dr (med)”

addresses

LIST_S ADDRESS

meaning = com address”

meaning = “tele

“items” name = “phone”

name = “phone”

items ELEMENT

name = “area code” value = “08”

ADDRESS

meaning = “apartment address” name = “home address”

CONTACT

name = “work” time_validity =

12/jan/1998 -

ELEMENT

name = “number” value = “1234 4321”

items

LIST_S

meaning = “items” name = “address”

ELEMENT

name = “number” value = “5a”

ELEMENT

name = “street nr” value = “38”

ELEMENT

name = “street name” value = “elm”

FIGURE 3 Person Demographic Information

2.3.1.2 Clinician Credentials

2.3.1.3 Health Care Facility

2.3.1.4 Group

FIGURE 4 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

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 19 of 25 Date of Issue: 23 Feb 2006

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Demographic Package Demographic Information Model Rev 2.0.1

these members of the team have an employment relationship with the hospital (shown only for one surgeon, in the interests of clarity).

PARTY_REL’SHIP

ROLE

identies

roles

uid = 90

uid = 11

ROLE PARTY_REL’SHIP

roles

uid = 13

uid = 92 meaning = “group role” name = “head surgeon” time_validity = 04/jun/2001 - sep/2002

source = 04 target = 11 meaning = “specialist” name = “cardiac surgeon” time_validity = 27/may/2001 - dec/2005

reverse_relns = {90, 94}

contacts

PARTY_REL’SHIP

ROLE

identies

roles

uid = 12

contacts

meaning = “specialist”

name = “anaesthetist” time_validity = 16/mar/1998 - sep/2002

source = 04 target = 12 name = “anaesthetist” time_validity = 16/mar/1998 - dec/2005

reverse_relns = {91, 95}

identies

meaning = “group role” name = “asst. surgeon” time_validity = 5/dec/1999 - sep/2002

source = 04 target = 13 meaning = “specialist” name = “cardiac surgeon” time_validity = 27/may/2001 - dec/2005

reverse_relns = {92, 96}

contacts

PARTY_REL’SHIP

PARTY_REL’SHIP

rel’ships

rel’ships

uid = 94

uid = 93

meaning = “employment”

name = “cardiologist”

time_validity = 27/may/2001 -

dec/2005

target = 11

source = 05 meaning = “cardiology team”

name = “cardiac team #1”

time_validity = 1/jan/1992

sep/2002

source = 05

target = 04

PARTY_REL’SHIP

uid = 95

meaning = “employment” name = “senior anaesthetist” time_validity = 15/feb/2003 - dec/2005

target = 12 source = 05

FIGURE 4 Group Demographics

Date of Issue: 23 Feb 2006 Page 20 of 25 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Demographic Information Model Demographic Package Rev 2.0.1

2.3.2 Relationships

2.3.2.1 Familial Relationship

2.3.2.2 Employment Relationship

2.3.2.3 Patient

FIGURE 5 shows a simple way of representing the patient relationship between a person and a health care organisation.

identies

PARTY_REL’SHIP

identies rel’ns

uid = 90

rel’ns

contacts contacts

meaning = “patient” name = “patient” time_validity = 1/jan/1992 - 20/jan/1992

source = 01 target = 02

FIGURE 5 Simple Patient Relationship

FIGURE 6 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.

CAPABILITY

credentials = medicare nr: 999 time_validity = 16/mar/1998 -

identities contacts

rel’ns roles contacts

identities

capabilities

CAPABILITY

credentials = provider nr: 111 time_validity = 1/jan/1980 -

PARTY_REL’SHIP

uid = 90

meaning = “patient” name = “patient” time_validity = 1/jan/1992 - 20/jan/1992

source = 01 target = 02

FIGURE 6 Patient Relationship with Roles and Credentials

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 21 of 25 Date of Issue: 23 Feb 2006

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Demographic Package Demographic Information Model Rev 2.0.1

Date of Issue: 23 Feb 2006 Page 22 of 25 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

Demographic Information Model References Rev 2.0.1

A.1 General

1 Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information Systems. See http://www.deepthought.com.au/it/archetypes.html .

2 Beale T et al. Design Principles for the EHR. See http://www.deepthought.com.au/openEHR .

3 Gray J, Reuter A. Transaction Processing Concepts and Techniques. Morgan Kaufmann 1993.

4 Sowa J F. Knowledge Representation: Logical, philosophical and Computational Foundations. 2000, Brooks/Cole, California.

5 Schloeffel P. (Editor). Requirements for an Electronic Health Record Reference Architecture. International Standards Organisation, Australia; Feb 2002; ISO TC 215/SC N; ISO/WD 18308.

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

A.2 CEN

7 ENV 13606-1 - Electronic healthcare record communication - Part 1: Extended architecture. CEN/ TC 251 Health Informatics Technical Committee.

8 ENV 13606-2 - Electronic healthcare record communication - Part 2: Domain term list. CEN/ TC 251 Health Informatics Technical Committee.

9 ENV 13606-3 - Electronic healthcare record communication - Part 3: Distribution rules. CEN/ TC 251 Health Informatics Technical Committee.

10 ENV 13606-4 -Electronic Healthcare Record Communication standard Part 4: Messages for the exchange of information. CEN/ TC 251 Health Informatics Technical Committee.

A.4 OMG

14 CORBAmed document: Person Identification Service. (March 1999). (Authors?)

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 23 of 25 Date of Issue: 23 Feb 2006

© 2003-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org

References Demographic Information Model Rev 2.0.1

A.5 HL7

15 HL7 version 3 2nd Ballot specification. Available at http://www.hl7.org .