openEHR logo

Demographic Information Model

Issuer: openEHR Specification Program

Release: RM Release-1.0.4

Status: STABLE

Revision: [latest_issue]

Date: [latest_issue_date]

Keywords: EHR, demographics, openehr

openEHR components
© 2003 - 2019 The openEHR Foundation

The openEHR Foundation is an independent, non-profit community organisation, facilitating the sharing of health records by consumers and clinicians via open standards-based 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.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 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 CEN 13606 and the HL7v3 RIM, and other work done in Australia.

The intended audience includes:

  • Standards bodies producing health informatics standards;

  • Academic groups using openEHR;

  • The open source healthcare community;

  • Solution vendors;

  • Medical informaticians and clinicians interested in health information.

Prerequisite documents for reading this document include:

Other documents describing related models, include:

1.3. Status

This specification is in the Stable state. The development version of this document can be found at 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 technical mailing list.

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 [Fowler_1997], and is influenced by clinical adaptations including work done in Australia and the HL7v3 RIM [HL7v3_ballot2] (itself influenced by the Fowler models).

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

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

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

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

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

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

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

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

General IT Publications

Articles, Books

  1. [Anderson_1996] Ross Anderson. Security in Clinical Information Systems. Available at http://www.cl.cam.ac.uk/users/rja14/policy11/policy11.html.

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

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

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

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

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

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

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

  9. [Kifer_Lausen_Wu_1995] Kifer M, Lausen G, Wu J. Logical Foundations of Object-Oriented and FrameBased Languages. JACM May 1995. See See ftp://ftp.cs.sunysb.edu/pub/TechReports/kifer/flogic.pdf.

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

  11. [Maier_2000] Maier M. Architecting Principles for Systems-of-Systems. Technical Report, University of Alabama in Huntsville. 2000. Available at http://www.infoed.com/Open/PAPERS/systems.htm

  12. [Martin] Martin P. Translations between UML, OWL, KIF and the WebKB-2 languages (For-Taxonomy, Frame-CG, Formalized English). May/June 2003. Available at http://www.webkb.org/doc/model/comparisons.html as at Aug 2004.

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

  14. [Object_Z] Smith G. The Object Z Specification Language. Kluwer Academic Publishers 2000. See http://www.itee.uq.edu.au/~smith/objectz.html .

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

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

Online Resources

  1. [] Wikipedia. Covariance and contravariance. See https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science) .

Standards

  1. [OCL] The Object Constraint Language 2.0. Object Management Group (OMG). Available at http://www.omg.org/cgi-bin/doc?ptc/2003-10-14 .

  2. [IEEE_828] IEEE. IEEE 828-2005: standard for Software Configuration Management Plans.

  3. [ISO_8601] ISO 8601 standard describing formats for representing times, dates, and durations. See https://en.wikipedia.org/wiki/ISO_8601.

  4. [ISO_2788] ISO. ISO 2788 Guide to Establishment and development of monolingual thesauri.

  5. [ISO_5964] ISO. ISO 5964 Guide to Establishment and development of multilingual thesauri.

  6. [Perl_regex] Perl.org. Perl Regular Expressions. Available at http://perldoc.perl.org/perlre.html .

Publications - e-Health

Articles, Books

  1. [Beale_2000] Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information Systems. 2000. Available at http://www.openehr.org/files/resources/publications/archetypes/archetypes_beale_web_2000.pdf .

  2. [Beale_2002] Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information Systems. Eleventh OOPSLA Workshop on Behavioral Semantics: Serving the Customer (Seattle, Washington, USA, November 4, 2002). Edited by Kenneth Baclawski and Haim Kilov. Northeastern University, Boston, 2002, pp. 16-32. Available at http://www.openehr.org/files/resources/publications/archetypes/archetypes_beale_oopsla_2002.pdf .

  3. [Beale_Heard_2007] Beale T, Heard S. An Ontology-based Model of Clinical Information. 2007. pp760-764 Proceedings MedInfo 2007, K. Kuhn et al. (Eds), IOS Publishing 2007. See http://www.openehr.org/publications/health_ict/MedInfo2007-BealeHeard.pdf.

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

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

  6. [Elstein_Schwarz_2002] Elstein AS, Schwarz A. Evidence base of clinical diagnosis: Clinical problem solving and diagnostic decision making: selective review of the cognitive literature. BMJ 2002;324;729-732.

  7. [Ingram_1995] Ingram D. The Good European Health Record Project. Laires, Laderia Christensen, Eds. Health in the New Communications Age. Amsterdam: IOS Press; 1995; pp. 66-74.

  8. [Object_Z] Smith G. The Object Z Specification Language. Kluwer Academic Publishers 2000. See http://www.itee.uq.edu.au/~smith/objectz.html .

  9. [GLIF] Lucila Ohno-Machado, John H. Gennari, Shawn N. Murphy, Nilesh L. Jain, Samson W. Tu, Diane E. Oliver, Edward Pattison-Gordon, Robert A. Greenes, Edward H. Shortliffe, and G. Octo Barnett. The GuideLine Interchange Format - A Model for Representing Guidelines. J Am Med Inform Assoc. 1998 Jul-Aug; 5(4): 357–372.

  10. [Rector_1994] Rector A L, Nowlan W A, Kay S. Foundations for an Electronic Medical Record. The IMIA Yearbook of Medical Informatics 1992 (Eds. van Bemmel J, McRay A). Stuttgart Schattauer 1994.

  11. [Rector_1999] Rector A L. Clinical terminology: why is it so hard? Methods Inf Med. 1999 Dec;38(4-5):239-52. Available at http://www.cs.man.ac.uk/~rector/papers/Why-is-terminology-hard-single-r2.pdf .

  12. [Sottile_1999] Sottile P.A., Ferrara F.M., Grimson W., Kalra D., and Scherrer J.R. The holistic healthcare information system. Toward an Electronic Health Record Europe. 1999. Nov 1999; 259-266.

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

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

Standards

  1. [Corbamed_PIDS] Object Management Group. Person Identification Service. March 1999. See http://www.omg.org/spec/PIDS/ .

  2. [Corbamed_LQS] Object Management Group. Lexicon Query Service. March 1999. http://www.omg.org/spec/LQS/ .

  3. [hl7_cda] HL7 International. HL7 version Clinical Document Architecture (CDA). Available at http://www.hl7.org.uk/version3group/cda.asp.

  4. [HL7v3_ballot2] HL7 International. HL7 version 3 2nd Ballot specification. Available at http://www.hl7.org.

  5. [HL7v3_data_types] Schadow G, Biron P. HL7 version 3 deliverable: Version 3 Data Types. (2nd ballot 2002 version).

  6. [hl7_v3_rim] HL7 International. HL7 v3 RIM. See http://www.hl7.org .

  7. [hl7_arden] HL7 International. HL7 Arden Syntax. See http://www.hl7.org/Special/committees/Arden/index.cfm .

  8. [hl7_gello] HL7 International. GELLO Decision Support Language. http://www.hl7.org/implement/standards/product_brief.cfm?product_id=5 .

  9. [IHTSDO_URIs] IHTSDO. SNOMED CT URI Standard. http://ihtsdo.org/fileadmin/user_upload/doc/download/doc_UriStandard_Current-en-US_INT_20140527.pdf?ok.

  10. [NLM_UML_list] National Library of Medicine. UMLS Terminologies List. http://www.nlm.nih.gov/research/umls/metaa1.html.

  11. [ISO_13606-1] ISO 13606-1 - Electronic healthcare record communication - Part 1: Extended architecture. See https://www.iso.org/standard/40784.html.

  12. [ISO_13606-2] ISO 13606-2 - Electronic healthcare record communication - Part 2: Domain term list. See https://www.iso.org/standard/50119.html.

  13. [ISO_13606-3] ISO 13606-3 - Electronic healthcare record communication - Part 3: Distribution rules. See https://www.iso.org/standard/50120.html.

  14. [ISO_13606-4] ISO 13606-4 - Electronic Healthcare Record Communication standard Part 4: Messages for the exchange of information. See https://www.iso.org/standard/50121.html.

  15. [ISO_18308] Schloeffel P. (Editor). Requirements for an Electronic Health Record Reference Architecture. See https://www.iso.org/standard/52823.html.

  16. [ISO_20514] ISO. The Integrated Care EHR. See https://www.iso.org/standard/39525.html .

  17. [ISO_13940] ISO. Health informatics - System of concepts to support continuity of care. See https://www.iso.org/standard/58102.html.

  18. [ISO_22600] ISO. Health informatics - Privilege management and access control. See https://www.iso.org/standard/62653.html.

Projects

  1. [EHCR_supA_14] Dixon R, Grubb P A, Lloyd D, and Kalra D. Consolidated List of Requirements. EHCR Support Action Deliverable 1.4. European Commission DGXIII, Brussels; May 2001 59pp Available from http://www.chime.ucl.ac.uk/HealthI/EHCR-SupA/del1-4v1_3.PDF.

  2. [EHCR_supA_35] Dixon R, Grubb P, Lloyd D. EHCR Support Action Deliverable 3.5: "Final Recommendations to CEN for future work". Oct 2000. Available at http://www.chime.ucl.ac.uk/HealthI/EHCRSupA/documents.htm.

  3. [EHCR_supA_24] Dixon R, Grubb P, Lloyd D. EHCR Support Action Deliverable 2.4 "Guidelines on Interpretation and implementation of CEN EHCRA". Oct 2000. Available at http://www.chime.ucl.ac.uk/HealthI/EHCR-SupA/documents.htm.

  4. [EHCR_supA_31_32] Lloyd D, et al. EHCR Support Action Deliverable 3.1&3.2 “Interim Report to CEN”. July 1998. Available at http://www.chime.ucl.ac.uk/HealthI/EHCR-SupA/documents.htm.

  5. [GEHR_del_4] Deliverable 4: GEHR Requirements for Clinical Comprehensiveness. GEHR Project 1992. Available at http://www.openehr.org/files/resources/related_projects/gehr/gehr_deliverable-4.pdf .

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

  7. [GEHR_del_8] Deliverable 8: Ethical and legal Requirements of GEHR Architecture and Systems. GEHR Project 1994. Available at http://www.openehr.org/files/resources/related_projects/gehr/gehr_deliverable-8.pdf .

  8. [GEHR_del_19_20_24] Deliverable 19,20,24: GEHR Architecture. GEHR Project 30/6/1995. Available at http://www.openehr.org/files/resources/related_projects/gehr/gehr_deliverable-19_20_24.pdf .

  9. [GeHR_AUS] Heard S, Beale T. The Good Electronic Health Record (GeHR) (Australia). See http://www.openehr.org/resources/related_projects#gehraus .

  10. [GeHR_Aus_gpcg] Heard S. GEHR Project Australia, GPCG Trial. See http://www.openehr.org/resources/related_projects#gehraus .

  11. [GeHR_Aus_req] Beale T, Heard S. GEHR Technical Requirements. See http://www.openehr.org/files/resources/related_projects/gehr_australia/gehr_requirements.pdf .

  12. [Synapses_req_A] Kalra D. (Editor). The Synapses User Requirements and Functional Specification (Part A). EU Telematics Application Programme, Brussels; 1996; The Synapses Project: Deliverable USER 1.1.1a. 6 chapters, 176 pages.

  13. [Synapses_req_B] Grimson W. and Groth T. (Editors). The Synapses User Requirements and Functional Specification (Part B). EU Telematics Application Programme, Brussels; 1996; The Synapses Project: Deliverable USER 1.1.1b.

  14. [Synapses_odp] Kalra D. (Editor). Synapses ODP Information Viewpoint. EU Telematics Application Programme, Brussels; 1998; The Synapses Project: Final Deliverable. 10 chapters, 64 pages. See http://discovery.ucl.ac.uk/66235/ .

  15. [synex] University College London. SynEx project. http://www.chime.ucl.ac.uk/HealthI/SynEx/ .