The EHR Reference Model Demographic Information … instance examples added. Z Tun, T Beale 08 Jan 2003 1.2 General modifications, addition of CAPABILITY class. T Beale, D Lloyd 22

Release 1 .0 .1

The openEHR Reference Model

Demographic Information Model

Keywords: EHR, reference model, demographics, openehr

Editors: {T Beale, S Heard}a, {D Kalra, D Lloyd}b

a. Ocean Informaticsb. Centre for Health Informatics and Multi-professional Education, University College London

Revision: 2.0.1 Pages: 25 Date of issue: 23 Feb 2006

Data Structures

Data Types

DemographicEHR

Security

EHR Extract

Archetype OM

Support

Common

Integration

Composition openEHR Archetype Profile

Template OM

ADL

© 2003-2007 The openEHR Foundation.

The openEHR Foundation is an independent, non-profit community, facilitating the sharing of health records by consumers and clinicians via open-source, standards-based implementations.

Founding Chairman

David Ingram, Professor of Health Informatics, CHIME, University College London

Founding Members

Dr P Schloeffel, Dr S Heard, Dr D Kalra, D Lloyd, T Beale

email: [email protected] web: http://www.openEHR.org

http://www.openEHR.org

Demographic Information ModelRev 2.0.1

Copyright Notice

© Copyright openEHR Foundation 2001 - 2007All Rights Reserved

1. This document is protected by copyright and/or database right throughout the world and is owned by the openEHR Foundation.

2. You may read and print the document for private, non-commercial use. 3. You may use this document (in whole or in part) for the purposes of making

presentations and education, so long as such purposes are non-commercial and are designed to comment on, further the goals of, or inform third parties about, openEHR.

4. You must not alter, modify, add to or delete anything from the document you use (except as is permitted in paragraphs 2 and 3 above).

5. You shall, in any use of this document, include an acknowledgement in the form: "© Copyright openEHR Foundation 2001-2007. All rights reserved. www.openEHR.org"

6. This document is being provided as a service to the academic community and on a non-commercial basis. Accordingly, to the fullest extent permitted under applicable law, the openEHR Foundation accepts no liability and offers no warranties in relation to the materials and documentation and their content.

7. If you wish to commercialise, license, sell, distribute, use or otherwise copy the materials and documents on this site other than as provided for in paragraphs 1 to 6 above, you must comply with the terms and conditions of the openEHR Free Commercial Use Licence, or enter into a separate written agreement with openEHR Foundation covering such activities. The terms and conditions of the openEHR Free Commercial Use Licence can be found at http://www.openehr.org/free_commercial_use.htm

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

© 2003-2007 The openEHR Foundation.email: [email protected] web: http://www.openEHR.org


Amendment Record

Issue Details Raiser Completed

R E L E A S E 1.0.1

2.0.1 CR-000200. Correct Release 1.0 typographical errors. D Lloyd 23 Feb 2006

R E L E A S E 1.0

2.0 CR-000189. Add LOCATABLE.parent. New invariant in PARTY.CR-000190. Rename VERSION_REPOSITORY toVERSIONED_OBJECT.CR-000194: Correct anomalies with LOCATABLE.uid

CR-000161. Support distributed versioning.

S HeardT Beale

H FrankelT BealeT Beale

H Frankel

25 Jan 2006

R E L E A S E 0.96

R E L E A S E 0.95

1.4.7 CR-000133. Remove details /= Void invariant from PARTY R Chen 12 Mar 2005

1.4.6 CR-000048. Pre-release review of documents. CorrectedSTRUCTURE to be ITEM_STRUCTURE. Make ACTOR.languagesa List not a Set.

D Lloyd 22 Feb 2005

1.4.5 CR-000024. Revert meaning to STRING and rename asarchetype_node_id.CR-000118. Make package names lower case.

S Heard,T BealeT Beale

10 Jan 2005

R E L E A S E 0.9

1.4.4 CR-000041. Visually differentiate primitive types in openEHRdocuments.

D Lloyd 04 Oct 2003

1.4.3 CR-000013. Rename key classes, according to CEN ENV13606.

S Heard, D Kalra, T

Beale

15 Sep 2003

1.4.2 CR-000035. Clarify circular relationships between PARTY andPARTY_REL.

Z Tun 14 Aug 2003

1.4.1 CR-000003. Removed ARCHETYPED and VERSIONABLEclasses.

T Beale,Z Tun

18 Mar 2003

1.4 Formally validated using ISE Eiffel 5.2. Minor corrections toinvariants.

T Beale 25 Feb 2003

1.3.1 Review by H Frankel, MCA. Corrections to diagrams andclass texts. Improved PARTY_RELATIONSHIP semantics. AddedPatient instance example. Made time_validity attributesoptional.

T Beale 13 Feb 2003

1.3 Corrections to diagrams and class texts. Inheritance changed toARCHETYPED for most key classes. Some instance examplesadded.

Z Tun,T Beale

08 Jan 2003

1.2 General modifications, addition of CAPABILITY class. T Beale, D Lloyd

22 Oct 2002

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



AcknowledgementsThe work reported in this paper has been funded in by a number of organisations, including The Uni-versity College, London; The Cooperative Research Centres Program through the Department of thePrime Minister and Cabinet of the Commonwealth Government of Australia; Ocean Informatics,Australia.

1.1 Renamed CONTACT_DESCRIPTOR to CONTACT. Removed CON-TACT.role. Renamed PARTY_ROLE to ROLE. Changed CON-TACT.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

Issue Details Raiser Completed




Table of ContentsCopyright Notice .......................................................................................2Amendment Record ....................................................................................3Acknowledgements .....................................................................................4Table of Contents ........................................................................................5

1 Introduction.............................................................................. 71.1 Purpose...................................................................................................71.2 Related Documents ................................................................................71.3 Status......................................................................................................71.4 Peer review ............................................................................................71.5 Conformance..........................................................................................8

2 Demographic Package ............................................................. 92.1 Overview................................................................................................92.1.1 Archetyping ...................................................................................102.1.2 Names and Addresses ....................................................................102.1.3 Party Identification ........................................................................102.1.4 Party Relationships ........................................................................102.1.5 Versioning Semantics.....................................................................112.2 Class Definitions..................................................................................112.2.1 PARTY Class .................................................................................112.2.2 PARTY_IDENTITY Class.............................................................122.2.3 CONTACT Class ...........................................................................132.2.4 ADDRESS Class............................................................................132.2.5 ACTOR Class ................................................................................142.2.6 PERSON Class ..............................................................................152.2.7 ORGANISATION Class ................................................................152.2.8 GROUP Class ................................................................................162.2.9 AGENT Class ................................................................................162.2.10 ROLE Class ...................................................................................162.2.11 CAPABILITY Class ......................................................................172.2.12 PARTY_RELATIONSHIP Class ...................................................172.3 Instance Examples ...............................................................................182.3.1 Parties.............................................................................................182.3.1.1 Person ..........................................................................................................182.3.1.2 Clinician ......................................................................................................192.3.1.3 Health Care Facility ....................................................................................192.3.1.4 Group ..........................................................................................................192.3.2 Relationships..................................................................................212.3.2.1 Familial Relationship ..................................................................................212.3.2.2 Employment Relationship ...........................................................................212.3.2.3 Patient ..........................................................................................................21

A References ............................................................................... 23A.1 General.................................................................................................23A.2 CEN .....................................................................................................23A.3 GEHR Australia ...................................................................................23A.4 OMG ....................................................................................................23A.5 HL7 ......................................................................................................24A.6 Software Engineering ..........................................................................24




A.7 Resources............................................................................................. 24



Demographic Information Model IntroductionRev 2.0.1

1 Introduction

1.1 PurposeThis document describes the architecture of the openEHR Demographic Information Model. Thesemantics are drawn from previous work in GEHR, existing models in CEN 13606 and the HL7v3RIM, 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 DocumentsPrerequisite 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 StatusThis document is under development, and is published as a proposal for input to standards processesand 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 reviewAreas where more analysis or explanation is required are indicated with “to be continued” paragraphslike the following:

To Be Continued: more work required



http://svn.openehr.org/specification/TAGS/Release-1.0.1/publishing/architecture/rm/demographic_im.pdf

http://svn.openehr.org/specification/TAGS/Release-1.0.1/publishing/architecture/rm/demographic_im.pdf

http://svn.openehr.org/specification/TRUNK/publishing/architecture/rm/demographic_im.pdf

http://svn.openehr.org/specification/TRUNK/publishing/architecture/rm/demographic_im.pdf

Introduction Demographic Information ModelRev 2.0.1

Reviewers are encouraged to comment on and/or advise on these paragraphs as well as the main con-tent. Please send requests for information to [email protected]. Feedback should preferably beprovided on the mailing list [email protected], or by private email.

1.5 ConformanceConformance of a data or software artifact to an openEHR Reference Model specification is deter-mined by a formal test of that artifact against the relevant openEHR Implementation TechnologySpecification(s) (ITSs), such as an IDL interface or an XML-schema. Since ITSs are formal, auto-mated derivations from the Reference Model, ITS conformance indicates RM conformance.



mailto:[email protected]

mailto:[email protected]

Demographic Information Model Demographic PackageRev 2.0.1

2 Demographic Package

2.1 OverviewThe demographic model illustrated in FIGURE 1 is a generalised model of the facts one might expectto see in a demographic server. The purpose of the model is as a specification of a demographic serv-ice, 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 version-ing, to an existing service.

The general design is based on the scheme of party and accountability described by Fowler [19], andis 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 demo-graphic entities which exist regardless of particular clinical involvements or participations in particu-

ACTORlanguages[0..1]: List<DV_TEXT>roles[0..1]: Set<PARTY_REF>has_legal_identity: Boolean

FIGURE 1 rm.demographic Package

PARTY_IDENTITYdetails[1]: ITEM_STRUCTUREpurpose: DV_TEXTas_string: String

CONTACTtime_validity[0..1]:DV_INTERVAL<DV_DATE>purpose: DV_TEXT

1..*

ADDRESSdetails[1]: ITEM_STRUCTUREtype: DV_TEXTas_string: String

addresses

1..*

demographic

PERSONORGANISATION VERSIONED_PARTY

<<binding>><PARTY>

ROLEtime_validity[0..1]:DV_INTERVAL<DV_DATE>performer[1]: PARTY_REF

PARTY_RELATIONSHIPdetails[0..1]: ITEM_STRUCTUREtime_validity[0..1]:DV_INTERVAL<DV_DATE>source[1]:PARTY_REFtarget[1]:PARTY_REFtype: DV_TEXT

identities

0..*

relation-

PARTYdetails[0..1]: ITEM_STRUCTUREreverse_relationships[0..1]:Set<LOCATABLE_REF>

type: DV_TEXT

contacts

0..*

AGENT

CAPABILITYcredentials[1]:ITEM_STRUCTUREtime_validity[0..1]DV_INTERVAL<DV_DATE>

capabilities

0..*

GROUP

ships

parties

repository(“demographics”)

(rm.common.archetyped)LOCATABLE

(rm.common.change_control)VERSIONED_OBJECT<T>

logical targetsof xxx_REFs



Demographic Package Demographic Information ModelRev 2.0.1

lar events. Participations are meaningful only within the context of the health record or other relevantmodel where they record context-specific relationships between demographic entities and events inthe real world.

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

2.1.1 ArchetypingThe model is designed to be used with archetypes, hence the generic nature of all entities. Every classcontaining an attribute of the form details:STRUCTURE is a completely archetypable structure. As aresult, 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 AddressesClasses have been included for PARTY_IDENTITY and ADDRESS, even though they contain only alink to details, in the form of the generic STRUCTURE class. This is not strictly necessary - it couldhave been done simply using appropriately named attributes in the classes PARTY and CONTACT - butis done to provide a place to add specific semantics in future releases of the model. It is also expectedto make software development easier, since it provides explicit classes to which behaviour and otherimplementation attributes can be added. Lastly, it allows the notions of PARTY_IDENTITY andADDRESS to be explicitly used in archetype-authoring tools.

Instances of PARTY_IDENTITY, linked to PARTY by the attribute identities are intended to express thenames 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 givenby parents, tribes etc). Identifiers of Parties given by other organisations, or the state are not repre-sented in this way, and should be recorded in the PARTY.details structure instead (see below).

2.1.3 Party IdentificationIdentifiers 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 sys-tem 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-ref-erences between Parties, and between Parties and Perty_relationships.

2.1.4 Party RelationshipsRelationships between parties in the real world may be expressed using PARTY_RELATIONSHIPobjects, as illustrated in FIGURE 2.

FIGURE 2 General Relationship Model

relationshipsPARTY PARTY

PARTY_REL’SHIPreverse_relationships

source: OBJECT_REFtarget: OBJECT_REF




Relationships are considered directional, hence the use of the attribute names source and target, how-ever, 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 mod-els of Fowler [19]). Accordingly, each Party involved in a relationship includes it in its relationshipslist, 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 bywhich Party’s actions caused the relationship to come into being. For example, a relationship repre-senting the concept “patient”, between a health consumer and a health care organisation would havethe consumer as source and the organisation as target.

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

2.1.5 Versioning SemanticsThe class PARTY and its descendants ACTOR and ROLE are all potentially versioned in a demographicsystem. A Version of a PARTY includes all the compositional parts, such as identities, contacts, Partyrelatoinships 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)

Purpose

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

CEN healthcare agent

HL7 Entity

Inherit LOCATABLE

Attributes Signature Meaning

1..1(redefined)

uid: HIER_OBJECT_ID Identifier of this Party.

1..1identities: Set<PARTY_IDENTITY>

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




2.2.2 PARTY_IDENTITY Class

0..1 contacts: Set<CONTACT> Contacts for this party.

0..1 relationships: Set<PARTY_RELATIONSHIP>

Relationships in which this role takes part as source.

0..1 reverse_relationships: Set<LOCATABLE_REF>

Relationships in which this role takes part as target.

0..1 details: ITEM_STRUCTURE All other details for this party.

Functions Signature Meaning

type: DV_TEXT Type of party, such as “PERSON”, “ORGANISATION”, etc. Role name, e.g. “general practitioner”, “nurse”, “private citi-zen”. Taken from inherited name attribute.

Invariants

Uid_valid: uid /= VoidType_valid: type = nameIdentities_valid: identities /= Void and then not identities.is_emptyContacts_valid: contacts /= Void implies not contacts.is_emptyRelationships_validity: relationships /= Void implies (not relation-ships.is_empty and then relationships.for_all(source = Current)Reverse_relationships_validity: reverse_relationships /= Void implies (not reverse_relationships.empty and then reverse_relationships.for_all(item | reposi-tory(“demographics”).all_party_relationships.has_object(item) and then reposi-tory(“demographics”).all_party_relationships.object(item).target = Current))Is_archetype_root: is_archetype_rootNo_parent: parent = Void

CLASS PARTY_IDENTITY

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

CEN Person Name (data type).

HL7 Person Name (PN) (data type).

Inherit LOCATABLE


0..1details: ITEM_STRUCTURE The value of the indentity. This will often

taken the form of a parsable string or a small structure of strings.

CLASS PARTY (abstract)




2.2.3 CONTACT Class

2.2.4 ADDRESS Class


1..1

purpose: DV_TEXT Purpose of identity, e.g. “legal”, “sta-gename”, “nickname”, “tribal name”, “trad-ing name”. Taken from value of inherited name attribute.

as_string: String Identity in the form of a single string.

Invariants Purpose_valid: purpose = nameDetails_exists: details /= Void

CLASS CONTACT

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

Inherit LOCATABLE


0..1 time_validity: DV_INTERVAL <DV_DATE>

Valid time interval for this contact descrip-tor.

1..1 addresses: List<ADDRESS> A set of address alternatives for this purpose and time validity.


1..1purpose: 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 = nameAddresses_exists: addresses /= Void and then not addresses.empty

CLASS ADDRESS

Purpose Address of contact, which may be electronic or geographic.

CEN Address (data type)

HL7 Address (AD) (data type)

Inherit LOCATABLE

CLASS PARTY_IDENTITY




2.2.5 ACTOR Class


0..1

details: ITEM_STRUCTURE The details of the address, in the form of a ITEM_STRUCTURE. This may take the form of a ITEM_SINGLE, whose data item is a parsable string or a list or tree of many parts.


1..1type: DV_TEXT Type of address, e.g. “electronic”, “locality”.

Taken from value of inherited name attribute.

as_string: String Address in the form of a single string.

Invariants Type_valid: type = nameDetails_exists: details /= Void

CLASS ACTOR (abstract)

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

CEN healthcare party

HL7 Entity

Inherit PARTY


0..1 roles: Set<PARTY_REF> Identifiers of the Version container for each Role played by this party.

0..1languages: List<DV_TEXT> Languages which can be used to communi-

cate with this actor, in preferred order of use (if known, else order irrelevant).


1..1 has_legal_identity: Boolean True if one there is an identity with purpose “legal identity”

InvariantsRoles_valid: roles /= Void implies not roles.is_emptyLanguages_valid: languages /= Void implies not languages.is_emptyLegal_identity_exists: has_legal_identity

CLASS ADDRESS




2.2.6 PERSON Class

2.2.7 ORGANISATION Class

CLASS PERSON

Purpose Generic description of persons. Provides a dedicated type to which Person arche-types can be targeted.

CEN healthcare person

GEHR G1_PERSON

HL7 Person

Inherit ACTOR


Invariants

CLASS ORGANISATION

PurposeGeneric description of organisations. An organisation is a legally constitutedbody whose existence (in general) outlives the existence of parties considered tobe part of it.

CEN healthcare organisation

GEHR G1_HCF

HL7 ORGANIZATION

Inherit ACTOR


Invariants




2.2.8 GROUP Class

2.2.9 AGENT Class

2.2.10 ROLE Class

CLASS GROUP

Purpose

A group is a real world group of parties which is created by another party, usu-ally an organisation, for some specific purpose. A typical clinical example is thatof the specialist care team, e.g. “cardiology team”. The members of the groupusually work together.

Inherit ACTOR


Invariants

CLASS AGENT

Purpose Generic concept of any kind of agent, including devices, software systems, butnot humans or organisations.

CEN healthcare software, healthcare device

HL7 DEVICE

Inherit ACTOR


Invariants

CLASS ROLE

Purpose

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

Use Roles correspond to concepts like “general practitioner”, “nurse” and so on.

CEN healthcare agent in context




2.2.11 CAPABILITY Class

2.2.12 PARTY_RELATIONSHIP Class

HL7 ROLE

Inherit PARTY


0..1 capabilities: List <CAPABILITY>

The capabilities of this role.


Valid time interval for this role.

1..1 performer: PARTY_REF Reference to Version container of Actor playing the role.

Invariants Capabilities_valid: capabilities /= Void implies not capabilities.emptyPerformer_exists: performer /= Void

CLASS CAPABILITY

Purpose Capability of a role, such as “ehr modifier”, “health care provider”. Capabilityshould be backed up by credentials.

Use

Inherit LOCATABLE


1..1

credentials: ITEM_STRUCTURE The qualifications of the performer of the role for this capability. This might include professional qualifications and official iden-tifications such as provider numbers etc.


Valid time interval for the credentials of this capability.

Invariants Credentials_exists: credentials /= Void

CLASS PARTY_RELATIONSHIP

Purpose Generic description of a relationship between parties.

HL7 RELATIONSHIP_LINK

CLASS ROLE




2.3 Instance ExamplesIn the following instance examples, the values of the attributes uid, source, target, andreverse_relationships are not meant to be taken as literally valid OBJECT_IDs - for the purposes ofclarity, simple integers have been used.

2.3.1 Parties2.3.1.1 PersonFIGURE 3 illustrates a possible set of instances for a PERSON, with home and work contact informa-tion. There are separate archetypes for the PERSON, each ADDRESS, and each PARTY_IDENTITY. In

Inherit LOCATABLE


1..1(redefined)

uid: HIER_OBJECT_ID Identifier of this Party.

0..1 details: ITEM_STRUCTURE The detailed description of the relationship


Valid time interval for this relationship.

1..1 source: PARTY_REF Source of relationship.

1..1 target: PARTY_REF Target of relationship.


1..1 type: DV_TEXT Type of relationship, such as “employment”, “authority”, “health provision”

Invariants

Uid_valid: uid /= VoidType_validity: type = nameSource_valid: source /= Void and then source.relationships.has(Current)Target_valid: target /= Void and then not target.reverse_relationships.has(Cur-rent)

CLASS PARTY_RELATIONSHIP




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

2.3.1.2 Clinician

Credentials

2.3.1.3 Health Care Facility

2.3.1.4 GroupFIGURE 4 illustrates the demographic information for a cadiac surgery team in a hospital. The groupincludes a head surgeon, anaesthetist, assistant surgeon, and presumably others (not shown). Each of

PERSONuid = 01meaning = “PERSON”name = “xxx”

addressesitemsCONTACT

name = “home”time_validity = 12/jan/1998 -

ADDRESSmeaning = “tele-com address”name = “phone”

LIST_Smeaning = “items”name = “phone”

ELEMENTname = “area code”value = “08”

ELEMENTname = “number”value = “1234 4321”

identities

CONTACTname = “work”time_validity = 12/jan/1998 -

ADDRESSmeaning = “apartment address”name = “home address”

itemsLIST_Smeaning = “items”name = “address”

ELEMENTname = “number”value = “5a”

ELEMENTname = “street nr”value = “38”

ELEMENTname = “street name”value = “elm”

FIGURE 3 Person Demographic Information

PARTY_IDENTITYmeaning = “per-son name”name = “legal name”

itemsLIST_Smeaning = “items”name = “items”

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

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

contacts




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

PERSONuid = 01meaning = “PERSON”name = “Anita Black”

GROUPuid = 04meaning = “special-ist care group”name = “cardiac sur-gery team”reverse_relns = {93}

ROLEuid = 11meaning = “specialist”name = “cardiac surgeon”time_validity = 27/may/2001 - dec/2005reverse_relns = {90, 94}

PARTY_REL’SHIPuid = 90meaning = “group role”name = “head surgeon”time_validity = 04/jun/2001 - sep/2002source = 04target = 11

roles

PERSONuid = 02meaning = “PERSON”name = “Jim Ng”

ROLEuid = 12meaning = “specialist”name = “anaesthetist”time_validity = 16/mar/1998 - dec/2005reverse_relns = {91, 95}

roles

PERSONuid = 03meaning = “PERSON”name = “Mark Chiu”

ROLEuid = 13meaning = “specialist”name = “cardiac surgeon”time_validity = 27/may/2001 - dec/2005reverse_relns = {92, 96}

roles

contacts

identies

contacts

identies

contacts

identies

PARTY_REL’SHIPuid = 91meaning = “group role”name = “anaesthetist”time_validity = 16/mar/1998 - sep/2002source = 04target = 12

PARTY_REL’SHIPuid = 92meaning = “group role”name = “asst. surgeon”time_validity = 5/dec/1999 - sep/2002source = 04target = 13

ORGANISATIONuid = 05meaning = “organisa-tion”name = “health care facility” contacts

identies

PARTY_REL’SHIPuid = 93meaning = “cardiology team”name = “cardiac team #1”time_validity = 1/jan/1992 - sep/2002source = 05target = 04

rel’ships

rel’ships

PARTY_REL’SHIPuid = 94meaning = “employment”name = “cardiologist”time_validity = 27/may/2001 - dec/2005target = 11source = 05

FIGURE 4 Group Demographics

rel’ships

cont

acts

iden

ties

PARTY_REL’SHIPuid = 95meaning = “employment”name = “senior anaesthetist”time_validity = 15/feb/2003 - dec/2005target = 12source = 05

PARTY_REL’SHIPuid = 95meaning = “employment”name = “surgeon”time_validity = 01/Jun/2004 - dec/2005target = 13source = 05




2.3.2 Relationships2.3.2.1 Familial Relationship

2.3.2.2 Employment Relationship

2.3.2.3 PatientFIGURE 5 shows a simple way of representing the patient relationship between a person and a healthcare organisation.

FIGURE 6 shows the same logical relationship, but with both Parties acting through Roles, represent-ing their status as healthcare consumer and healthcare provider respectively. Each of these Roles hasassociated credentials which document its official nature within the healthcare system.

PERSONuid = 02meaning = “PERSON”name = “Linda Laney”reverse_relns = {90}

rel’nscontacts

identies PARTY_REL’SHIPuid = 90meaning = “patient”name = “patient”time_validity = 1/jan/1992 - 20/jan/1992source = 01target = 02

ORGANISATIONuid = 01meaning = “ORGANI-SATION”name = “Newcastle hospital”reverse_relns = {90}

rel’ns contacts

identies

FIGURE 5 Simple Patient Relationship

PERSONuid = 02meaning = “PERSON”name = “Linda Laney”

ROLEuid = 10meaning = “person role”name = “HC consumer”time_validity = 16/mar/1998 -

rolescontacts

identities

PARTY_REL’SHIPuid = 90meaning = “patient”name = “patient”time_validity = 1/jan/1992 - 20/jan/1992source = 01target = 02

ORGANISATIONuid = 01meaning = “ORGANI-SATION”name = “Newcastle hospital”

ROLEuid = 11meaning = “organisation role”name = “HC provider”time_validity = 16/mar/1998 -

rolescontacts

identities

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

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

FIGURE 6 Patient Relationship with Roles and Credentials

rel’ns

rel’ns

capabilities

capabilities






Demographic Information Model ReferencesRev 2.0.1

A References

A.1 General1 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 in-formation system. Toward an Electronic Health Record Europe 1999. Nov 1999; 259-266.

A.2 CEN7 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.3 GEHR Australia11 Beale T. Northern Territory Health Demographic Model.

12 Heard S. GEHR Project Australia, GPCG Trial. Available at http://www.ge-hr.org/gpcg/ehra.htm.

13 Beale T, Heard S. GEHR Technical Requirements. See http://www.gehr.org/technical/require-ments/gehr_requirements.html.

A.4 OMG14 CORBAmed document: Person Identification Service. (March 1999).

(Authors?)



http://www.deepthought.com.au/it/archetypes.html

http://www.deepthought.com.au/it/archetypes.html

http://www.gehr.org/gpcg/ehra.htm

http://www.gehr.org/gpcg/ehra.htm

http://www.gehr.org/technical/requirements/gehr_requirements.html

http://www.gehr.org/technical/requirements/gehr_requirements.html

References Demographic Information ModelRev 2.0.1

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

A.6 Software Engineering16 Meyer B. Object-oriented Software Construction, 2nd Ed.

Prentice Hall 1997

17 Walden K, Nerson J. Seamless Object-oriented Software Architecture.Prentice Hall 1994

18 Gamma E, Helm R, Johnson R, Vlissides J. Design patterns of Reusable Object-oriented Soft-wareAddison-Wesley 1995

19 Fowler M. Analysis Patterns: Reusable Object ModelsAddison Wesley 1997

20 Fowler M, Scott K. UML Distilled (2nd Ed.)Addison Wesley Longman 2000

21 Booch G, Rumbaugh J, Jacobsen I. The Unified Modelling Language User Guide. Addison es-ley 1999.

A.7 Resources22 Arden Syntax. http://www.cpmc.columbia.edu/arden/

23 Asbru / The Asgaard Project. http://smi-web.stanford.edu/projects/asgaard/

24 Digital Imaging ad Communications in Medicine (DICOM). http://medical.nema.org/di-com.html.

25 EON ref required

26 GLIF (Guideline Interchange Format). http://www.glif.org/.

27 IANA - http://www.iana.org/.

28 ProForma language for decision support. http://www.acl.icnet.uk/lab/proforma.html.

29 SynEx project, UCL. http://www.chime.ucl.ac.uk/HealthI/SynEx/.



http://www.hl7.org

http://www.cpmc.columbia.edu/arden/

http://smi-web.stanford.edu/projects/asgaard/

http://medical.nema.org/dicom.html

http://medical.nema.org/dicom.html

http://www.glif.org/

http://www.iana.org/

http://www.acl.icnet.uk/lab/proforma.html

http://www.chime.ucl.ac.uk/HealthI/SynEx/




END OF DOCUMENT