Demographic Information Model

Issuer: openEHR Specification Program
Release: RM Release-1.0.2	Status: STABLE
Revision: [latest_issue]	Date: [latest_issue_date]
Keywords: EHR, demographics, reference model, openehr

Issuer: openEHR Specification Program

Release: RM Release-1.0.2

Status: STABLE

Keywords: EHR, demographics, reference model, openehr

© 2003 - 2021 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	Creative Commons Attribution-NoDerivs 3.0 Unported. https://creativecommons.org/licenses/by-nd/3.0/
Support	Issues: Problem Reports Web: specifications.openEHR.org

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

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

Issue	Details	Raiser	Completed
R E L E A S E 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
R E L E A S E 1.0.1
2.0.1	CR-0002004: 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`.	S Heard	25 Jan 2006
	CR-000190. Rename `VERSION_REPOSITORY` to `VERSIONED_OBJECT`.	T Beale
	CR-000194. Correct anomalies with `LOCATABLE`.`uid`.	H Frankel T Beale
	CR-000161. 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
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. Corrected `STRUCTURE` to be `ITEM_STRUCTURE`. Make `ACTOR`.`languages` a `List` not a `Set`.	D Lloyd	22 Feb 2005
1.4.5	CR-000024. Revert meaning to `STRING` and rename as `archetype_node_id`.	S Heard, T Beale	10 Jan 2005
	CR-000118. Make package names lower case.	T Beale
R E L E A S E 0.9
1.4.4	CR-000041. Visually differentiate primitive types in openEHR documents.	D Lloyd	04 Oct 2003
1.4.3	CR-000013. Rename key classes, according to CEN ENV 13606.	S Heard, D Kalra, T Beale	15 Sep 2003
1.4.2	CR-000035. Clarify circular relationships between `PARTY` and `PARTY_REL`.	Z Tun	14 Aug 2003
1.4.1	CR-000003. 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

R E L E A S E 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

R E L E A S E 1.0.1

2.0.1

CR-0002004: 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.

S Heard

25 Jan 2006

CR-000190. Rename VERSION_REPOSITORY to VERSIONED_OBJECT.

T Beale

CR-000194. Correct anomalies with LOCATABLE.uid.

H Frankel
T Beale

CR-000161. 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

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. Corrected STRUCTURE to be ITEM_STRUCTURE. Make ACTOR.languages a List not a Set.

D Lloyd

22 Feb 2005

1.4.5

CR-000024. Revert meaning to STRING and rename as archetype_node_id.

S Heard,
T Beale

10 Jan 2005

CR-000118. Make package names lower case.

T Beale

R E L E A S E 0.9

1.4.4

CR-000041. Visually differentiate primitive types in openEHR documents.

D Lloyd

04 Oct 2003

1.4.3

CR-000013. Rename key classes, according to CEN ENV 13606.

S Heard,
D Kalra,
T Beale

15 Sep 2003

1.4.2

CR-000035. Clarify circular relationships between PARTY and PARTY_REL.

Z Tun

14 Aug 2003

1.4.1

CR-000003. 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

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 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:

The openEHR Architecture Overview.

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.

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

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

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).
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>`	Relationships in which this role takes part as target.
0..1	relationships: `List<PARTY_RELATIONSHIP>`	Relationships in which this role takes part as source.
1..1 (redefined)	uid: `HIER_OBJECT_ID`	Identifier of this Party.
Functions	Signature	Meaning
1..1	type (): `ITEM_STRUCTURE`	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`

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

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>

Relationships in which this role takes part as target.

0..1

relationships: List<PARTY_RELATIONSHIP>

Relationships in which this role takes part as source.

1..1
(redefined)

uid: HIER_OBJECT_ID

Identifier of this Party.

Functions

Signature

Meaning

1..1

type (): ITEM_STRUCTURE

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

2.2.2. 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`

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.3. 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.
0..1	time_validity: `DV_INTERVAL<DV_DATE>`	Valid time interval for this relationship.
1..1	source: `PARTY_REF`	Source of relationship.
1..1	target: `PARTY_REF`	Target 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`

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.

0..1

time_validity: DV_INTERVAL<DV_DATE>

Valid time interval for this relationship.

1..1

source: PARTY_REF

Source of relationship.

1..1

target: PARTY_REF

Target 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.4. 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 indentity. This will often taken the form of a parsable 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.
1..1	as_string (): `String`	Identity in the form of a single string.
Invariants	Purpose_valid: `purpose = name`

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 indentity. This will often taken the form of a parsable 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.

1..1

as_string (): String

Identity in the form of a single string.

Invariants

Purpose_valid: purpose = name

2.2.5. 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 purpose and time validity.
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`

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 purpose and time validity.

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

Class	ADDRESS
Description	Address of contact, which may be electronic or geographic.
Inherit	`LOCATABLE`
Attributes	Signature	Meaning
1..1	details: `ITEM_STRUCTURE`
Functions	Signature	Meaning
1..1	type (): `DV_TEXT`	Type of address, e.g. electronic , locality . Taken from value of inherited name attribute.
1..1	as_string (): `String`	Address in the form of a single string.
Invariants	Type_valid: `type = name`

Class

ADDRESS

Description

Address of contact, which may be electronic or geographic.

Inherit

LOCATABLE

Attributes

Signature

Meaning

1..1

details: ITEM_STRUCTURE

Functions

Signature

Meaning

1..1

type (): DV_TEXT

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

1..1

as_string (): String

Address in the form of a single string.

Invariants

Type_valid: type = name

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

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.8. 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
1..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).
1..1	roles: `List<PARTY_REF>`	Identifiers of the Version container for each Role played by this party.
Functions	Signature	Meaning
1..1	has_legal_identity (): `Boolean`	True if one there is an identity with purpose legal identity.
Invariants	Legal_identity_exists: `has_legal_identity`

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

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

1..1

roles: List<PARTY_REF>

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

Functions

Signature

Meaning

1..1

has_legal_identity (): Boolean

True if one there is an identity with purpose legal identity.

Invariants

Legal_identity_exists: has_legal_identity

2.2.9. PERSON Class

Class	PERSON
Description	Generic description of persons. Provides a dedicated type to which Person archetypes can be targeted.
Inherit	`ACTOR`

Class

PERSON

Description

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

Inherit

ACTOR

2.2.10. 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`

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

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.12. AGENT Class

Class	AGENT
Description	Generic concept of any kind of agent, including devices, software systems, but not humans or organisations.
Inherit	`ACTOR`

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.

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

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.

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.

Figure 6. Patient Relationship with Roles and Credentials

References

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