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 |
|
| © 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 |
|
Support |
Issues: Problem Reports |
Amendment Record
| Issue | Details | Raiser | Completed |
|---|---|---|---|
RM Release 1.0.4 |
|||
SPECRM-76: Add |
S Iancu |
||
SPECRM-46: Fix RM Release 1.0.3 typos and minor documentary errors: correct type of |
S Iancu |
||
RM Release 1.0.3 |
|||
2.0.3 |
SPECRM-36: Remove |
S Iancu |
15 Aug 2015 |
SPEC-45. Remove |
S Iancu |
||
Release 1.0.2 |
|||
2.0.2 |
SPEC-257: Correct minor typos and clarify text. Make |
T Cook |
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 |
S Heard |
25 Jan 2006 |
SPEC-190. Rename |
T Beale |
||
SPEC-194. Correct anomalies with |
H Frankel |
||
SPEC-161. Support distributed versioning. |
T Beale |
||
Release 0.96 |
|||
Release 0.95 |
|||
1.4.7 |
SPEC-133. Remove |
R Chen |
12 Mar 2005 |
1.4.6 |
SPEC-48. Pre-release review of documents. Corrected |
D Lloyd |
22 Feb 2005 |
1.4.5 |
SPEC-24. Revert meaning to |
S Heard, |
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, |
15 Sep 2003 |
1.4.2 |
SPEC-35. Clarify circular relationships between |
Z Tun |
14 Aug 2003 |
1.4.1 |
SPEC-3. Removed |
T Beale, |
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 |
T Beale |
13 Feb 2003 |
1.3 |
Corrections to diagrams and class texts. Inheritance changed to |
Z Tun, |
08 Jan 2003 |
1.2 |
General modifications, addition of |
T Beale, |
22 Oct 2002 |
1.1 |
Renamed |
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.
1.2. Related Documents
Prerequisite documents for reading this document include:
Other documents describing related models, include:
1.3. Status
This specification is in the Stable state. The development version of this document can be found at https://specifications.openehr.org/releases/RM/latest/demographic.html.
Known omissions or questions are indicated in the text with a 'to be determined' paragraph, as follows:
TBD: (example To Be Determined paragraph)
1.4. Feedback
Feedback may be provided on the 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.
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.
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 |
|
Inherit |
|
|
Attributes |
Signature |
Meaning |
1..1 |
identities: |
Identities used by the party to identify itself, such as legal name, stage names, aliases, nicknames and so on. |
0..1 |
contacts: |
Contacts for this party. |
0..1 |
details: |
All other details for this Party. |
0..1 |
reverse_relationships: |
References to relationships in which this Party takes part as target. |
0..1 |
relationships: |
Relationships in which this Party takes part as source. |
Functions |
Signature |
Meaning |
type (): |
Type of party, such as |
|
Invariants |
Type_valid: |
|
Contacts_valid: |
||
Relationships_validity: |
||
Reverse_relationships_validity: |
||
Is_archetype_root: |
||
Uid_mandatory: |
||
2.2.2. VERSIONED_PARTY Class
Class |
VERSIONED_PARTY |
|
|---|---|---|
Description |
Static type formed by binding generic parameter of |
|
Inherit |
|
|
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 |
|
|
Attributes |
Signature |
Meaning |
0..1 |
time_validity: |
Valid time interval for this role. |
1..1 |
performer: |
Reference to Version container of Actor playing the role. |
0..1 |
capabilities: |
The capabilities of this role. |
Invariants |
Capabilities_valid: |
|
2.2.4. PARTY_RELATIONSHIP Class
Class |
PARTY_RELATIONSHIP |
|
|---|---|---|
Description |
Generic description of a relationship between parties. |
|
Inherit |
|
|
Attributes |
Signature |
Meaning |
0..1 |
details: |
The detailed description of the relationship. |
1..1 |
target: |
Target of relationship. |
0..1 |
time_validity: |
Valid time interval for this relationship. |
1..1 |
source: |
Source of relationship. |
Functions |
Signature |
Meaning |
type (): |
Type of relationship, such as employment, authority, health provision |
|
Invariants |
Source_valid: |
|
Target_valid: |
||
Type_validity: |
||
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 |
|
|
Attributes |
Signature |
Meaning |
1..1 |
details: |
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 (): |
Purpose of identity, e.g. legal , stagename, nickname, tribal name, trading name. Taken from value of inherited |
|
Invariants |
Purpose_valid: |
|
2.2.6. CONTACT Class
Class |
CONTACT |
|
|---|---|---|
Description |
Description of a means of contact of a Party. Actual structure is archetyped. |
|
Inherit |
|
|
Attributes |
Signature |
Meaning |
1..1 |
addresses: |
A set of address alternatives for this contact purpose and time validity combination. |
0..1 |
time_validity: |
Valid time interval for this contact descriptor. |
Functions |
Signature |
Meaning |
purpose (): |
Purpose for which this contact is used, e.g. mail, daytime phone, etc. Taken from value of inherited |
|
Invariants |
Purpose_valid: |
|
2.2.7. ADDRESS Class
Class |
ADDRESS |
|
|---|---|---|
Description |
Address of contact, which may be electronic or geographic. |
|
Inherit |
|
|
Attributes |
Signature |
Meaning |
1..1 |
details: |
Archetypable structured address. |
Functions |
Signature |
Meaning |
type (): |
Type of address, e.g. electronic, locality. Taken from value of inherited |
|
Invariants |
Type_valid: |
|
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 |
|
|
Attributes |
Signature |
Meaning |
1..1 |
credentials: |
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: |
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 |
|
|
Attributes |
Signature |
Meaning |
0..1 |
languages: |
Languages which can be used to communicate with this actor, in preferred order of use (if known, else order irrelevant). |
0..1 |
roles: |
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 |
|
|
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 |
|
|
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 |
|
|
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.
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).
2.3.2. Relationships
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.
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.
References
General IT Publications
Articles, Books
-
[Anderson_1996] Ross Anderson. Security in Clinical Information Systems. Available at http://www.cl.cam.ac.uk/users/rja14/policy11/policy11.html.
-
[Booch_1994] Booch G. Object-Oriented Analysis and Design with applications. 2nd ed. Benjamin/Cummings 1994.
-
[Eiffel] Meyer B. Eiffel the Language (2nd Ed). Prentice Hall, 1992.
-
[Fowler_1997] Fowler M. Analysis Patterns: Reusable Object Models. Addison Wesley 1997
-
[Fowler_Scott_2000] Fowler M, Scott K. UML Distilled (2nd Ed.). Addison Wesley Longman 2000.
-
[Gray_reuter_1993] Gray J, Reuter A. Transaction Processing Concepts and Techniques. Morgan Kaufmann 1993.
-
[Hein_2002] Hein J L. Discrete Structures, Logic and Computability (2nd Ed). Jones and Bartlett 2002.
-
[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.
-
[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.
-
[Kilov_1994] Kilov H, Ross J. Information Modelling - an object-oriented approach. Prentice Hall 1994.
-
[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
-
[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.
-
[Meyer_OOSC2] Meyer B. Object-oriented Software Construction, 2nd Ed. Prentice Hall 1997
-
[Object_Z] Smith G. The Object Z Specification Language. Kluwer Academic Publishers 2000. See http://www.itee.uq.edu.au/~smith/objectz.html .
-
[Richards_1998] Richards E G. Mapping Time - The Calendar and its History. Oxford University Press 1998.
-
[Sowa_2000] Sowa J F. Knowledge Representation: Logical, philosophical and Computational Foundations. 2000, Brooks/Cole, California.
Online Resources
-
[] Wikipedia. Covariance and contravariance. See https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science) .
Standards
-
[OCL] The Object Constraint Language 2.0. Object Management Group (OMG). Available at http://www.omg.org/cgi-bin/doc?ptc/2003-10-14 .
-
[IEEE_828] IEEE. IEEE 828-2005: standard for Software Configuration Management Plans.
-
[ISO_8601] ISO 8601 standard describing formats for representing times, dates, and durations. See https://en.wikipedia.org/wiki/ISO_8601.
-
[ISO_2788] ISO. ISO 2788 Guide to Establishment and development of monolingual thesauri.
-
[ISO_5964] ISO. ISO 5964 Guide to Establishment and development of multilingual thesauri.
-
[Perl_regex] Perl.org. Perl Regular Expressions. Available at http://perldoc.perl.org/perlre.html .
Publications - e-Health
Articles, Books
-
[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 .
-
[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 .
-
[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.
-
[Cimino_1997] Cimino J J. Desiderata for Controlled Medical vocabularies in the Twenty-First Century. IMIA WG6 Conference, Jacksonville, Florida, Jan 19-22, 1997.
-
[Elstein_1987] Elstein AS, Shulman LS, Sprafka SA. Medical problem solving: an analysis of clinical reasoning. Cambridge, MA: Harvard University Press 1987.
-
[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.
-
[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.
-
[Object_Z] Smith G. The Object Z Specification Language. Kluwer Academic Publishers 2000. See http://www.itee.uq.edu.au/~smith/objectz.html .
-
[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.
-
[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.
-
[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 .
-
[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.
-
[Van_de_Velde_Degoulet_2003] Van de Velde R, Degoulet P. Clinical Information Systems: A Component-Based Approach. 2003. Springer-Verlag New York.
-
[Weed_1969] Weed LL. Medical records, medical education and patient care. 6 ed. Chicago: Year Book Medical Publishers Inc. 1969.
Standards
-
[Corbamed_PIDS] Object Management Group. Person Identification Service. March 1999. See http://www.omg.org/spec/PIDS/ .
-
[Corbamed_LQS] Object Management Group. Lexicon Query Service. March 1999. http://www.omg.org/spec/LQS/ .
-
[hl7_cda] HL7 International. HL7 version Clinical Document Architecture (CDA). Available at http://www.hl7.org.uk/version3group/cda.asp.
-
[HL7v3_ballot2] HL7 International. HL7 version 3 2nd Ballot specification. Available at http://www.hl7.org.
-
[HL7v3_data_types] Schadow G, Biron P. HL7 version 3 deliverable: Version 3 Data Types. (2nd ballot 2002 version).
-
[hl7_v3_rim] HL7 International. HL7 v3 RIM. See http://www.hl7.org .
-
[hl7_arden] HL7 International. HL7 Arden Syntax. See http://www.hl7.org/Special/committees/Arden/index.cfm .
-
[hl7_gello] HL7 International. GELLO Decision Support Language. http://www.hl7.org/implement/standards/product_brief.cfm?product_id=5 .
-
[IHTSDO_URIs] IHTSDO. SNOMED CT URI Standard. http://ihtsdo.org/fileadmin/user_upload/doc/download/doc_UriStandard_Current-en-US_INT_20140527.pdf?ok.
-
[NLM_UML_list] National Library of Medicine. UMLS Terminologies List. http://www.nlm.nih.gov/research/umls/metaa1.html.
-
[ISO_13606-1] ISO 13606-1 - Electronic healthcare record communication - Part 1: Extended architecture. See https://www.iso.org/standard/40784.html.
-
[ISO_13606-2] ISO 13606-2 - Electronic healthcare record communication - Part 2: Domain term list. See https://www.iso.org/standard/50119.html.
-
[ISO_13606-3] ISO 13606-3 - Electronic healthcare record communication - Part 3: Distribution rules. See https://www.iso.org/standard/50120.html.
-
[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.
-
[ISO_18308] Schloeffel P. (Editor). Requirements for an Electronic Health Record Reference Architecture. See https://www.iso.org/standard/52823.html.
-
[ISO_20514] ISO. The Integrated Care EHR. See https://www.iso.org/standard/39525.html .
-
[ISO_13940] ISO. Health informatics - System of concepts to support continuity of care. See https://www.iso.org/standard/58102.html.
-
[ISO_22600] ISO. Health informatics - Privilege management and access control. See https://www.iso.org/standard/62653.html.
Projects
-
[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.
-
[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.
-
[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.
-
[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.
-
[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 .
-
[GEHR_del_7] Deliverable 7: Clinical Functional Specifications. GEHR Project 1993.
-
[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 .
-
[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 .
-
[GeHR_AUS] Heard S, Beale T. The Good Electronic Health Record (GeHR) (Australia). See http://www.openehr.org/resources/related_projects#gehraus .
-
[GeHR_Aus_gpcg] Heard S. GEHR Project Australia, GPCG Trial. See http://www.openehr.org/resources/related_projects#gehraus .
-
[GeHR_Aus_req] Beale T, Heard S. GEHR Technical Requirements. See http://www.openehr.org/files/resources/related_projects/gehr_australia/gehr_requirements.pdf .
-
[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.
-
[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.
-
[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/ .
-
[synex] University College London. SynEx project. http://www.chime.ucl.ac.uk/HealthI/SynEx/ .