Editors: {T Beale, S Heard}a, {D Kalra, D Lloyd}b
Revision: 1.0	Pages: 27	Date of issue: 08 Apr 2007

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 David Ingram, Professor of Health Informatics, Chairman CHIME, University College London

Copyright Notice

This document is protected by copyright and/or database right throughout the world and is owned by the openEHR Foundation.
You may read and print the document for private, non-commercial use.
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.
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).
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"
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.
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: 08 Apr 2007 Page 2 of 27 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

Support Terminology

Rev 1.0

Amendment Record

Issue	Details	Raiser	Completed
	R E L E A S E 1.0.1
1.0	CR-000219: Use constants instead of literals to refer to terminology in RM. CR-000221. Add normal_status to DV_ORDERED. Add new “normal status” terminology group. CR-000217: Additional math function. CR-000235: Make attestation-only commit require a Contribution. Add ‘attestation’ code to audit-change type. CR-000246: Correct openEHR terminology rubrics.	R Chen H Frankel S Heard A Patterson B Verhees M Forss	08 Apr 2007
	R E L E A S E 1.0
0.9	CR-000184. Separate out terminology from Support IM. CR-000182: Rationalise VERSION.lifecycle_state and ATTESTATION.status. Add new term set for attestation reason, deprecate attestation state term set. CR-000162. Allow party identifiers when no demographic data. Deprecate some terms from version lifecycle status group, add some new terms. CR-000140. Redevelop Instruction, based on workflow principles. Add term sets for Instruction State machine. CR-000192: Add display-as-absolute facility to delta Events in History	T Beale T Beale, D Kalra S Heard H Frankel S Heard T Beale S Heard	22 Oct 2005
	R E L E A S E 0.96

Acknowledgements

The work reported in this paper has been funded by The University College, London and Ocean Informatics, Australia.

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 3 of 27 Date of Issue: 08 Apr 2007

Support Terminology

Rev 1.0

Date of Issue: 08 Apr 2007 Page 4 of 27 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

Support Terminology

Rev 1.0

Contents

1 Introduction.............................................................................. 7

1.1 Purpose...................................................................................................7

1.3 Status......................................................................................................7

1.4 Peer review ............................................................................................7

1.5 Conformance..........................................................................................7

2 Terminology .............................................................................. 9

2.1 Overview................................................................................................9

2.2 Code Sets ...............................................................................................9

2.2.1 Countries........................................................................................10

2.2.2 Character Sets ................................................................................10

2.2.3 Compression algorithms ................................................................10

2.2.4 Integrity check algorithms .............................................................11

2.2.5 Languages ......................................................................................11

2.2.6 Media Types...................................................................................11

2.2.7 Normal Status.................................................................................12

2.3 The openEHR Terminology.................................................................12

2.3.1 Attestation Reason .........................................................................12

2.3.2 Audit Change Type ........................................................................13

2.3.3 Composition Category ...................................................................13

2.3.4 Event Math Function .....................................................................14

2.3.5 Instruction States............................................................................15

2.3.6 Instruction Transitions ...................................................................15

2.3.7 Null Flavours .................................................................................17

2.3.8 Participation Function....................................................................17

2.3.9 Participation Mode.........................................................................18

2.3.10 Property..........................................................................................19

2.3.11 Setting ............................................................................................22

2.3.12 Subject relationship........................................................................22

2.3.13 Term Mapping Purpose..................................................................24

2.3.14 Version Lifecycle State ..................................................................25

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 5 of 27 Date of Issue: 08 Apr 2007

Support Terminology

Rev 1.0

Date of Issue: 08 Apr 2007 Page 6 of 27 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

Support Terminology Introduction Rev 1.0

Introduction

1.1 Purpose

This document describes the openEHR Support Terminology and code sets, which define the vocabulary and codes needed for the openEHR Reference, Archetype and Service models. The openEHR terminology is not considered to be in the same space as externally defined terminologies such as SNOMED-CT, ICDx etc, since it is not an ontology of real facts, but of informational classifiers needed by the openEHR models. The code sets are generally a means of interfacing external codes such as ISO language identifiers, with openEHR.

The audience of this document includes:

Standards bodies producing health informatics standards;
Software development organisations developing EHR systems;
Academic groups studying the EHR;
The open source healthcare community.

1.2 Related Documents

Prerequisite documents for reading this document include:

The openEHR Architecture Overview
The openEHR Reference Model documents.

1.3 Status

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

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

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

Blue text indicates sections under active development.

1.4 Peer review

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

To Be Continued: more work required

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

1.5 Conformance

Conformance of a data or software artifact to an openEHR Reference Model specification is determined by a formal test of that artifact against the relevant openEHR Implementation Technology

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 7 of 27 Date of Issue: 08 Apr 2007

Introduction Support Terminology Rev 1.0

Specification(s) (ITSs), such as an IDL interface or an XML-schema. Since ITSs are formal, automated derivations from the Reference Model, ITS conformance indicates RM conformance.

Date of Issue: 08 Apr 2007 Page 8 of 27 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

Support Terminology Terminology Rev 1.0

Terminology

2.1 Overview

This document provides a documentary expression of the openEHR Support Terminology, consisting of code sets and vocabulary that provide values for the coded attributes in the openEHR Reference Model. The computable form of this terminology is available in the ‘computable’ part of the openEHR specification repository, and should always be considered the definitive expression, rather than this document. Access to the terminology in the openEHR reference model is via the classes defined in the package rm.support.terminology.

There are two types of coded entities used in openEHR. The first is that of codes that are self-defining, and which do not have separate rubrics, i.e. the code ‘stands for itself’. The ISO country and language codes are examples of this, as are code groups for such concepts as ‘integrity check algorithm names’. These are modelled in openEHR by the CODE_PHRASE type (found in the rm.data_types.text package). Value sets that cannot meaningfully be translated into other languages and which do not have definitions beyond their code value are usually candidates for being a code set rather than a terminology group. The code sets described in this document are mostly internet vocabularies defined by ISO or IETF. This document does not change the definition, it merely a) indicates which codes sets are used for what purpose in openEHR and b) assigns them a logical name by which they are referred to in the openEHR models.

The second category of coded entities are ‘proper’ coded terms, where each code is a concept identifier, for which there is a rubric and description, potentially in multiple languages. In other words, the way of ‘saying’ the concept is dependent on the language one is working in. Most clinical terminologies are in this category, e.g. ICD10, ICPC, as well as the openEHR Terminology. Terms in this category are modelled by the openEHR data type DV_CODED_TEXT, which uses the CODE_PHRASE type to contain its defining code, as well as any mapped codes. The openEHR Terminology is a lexicon of terms required for various attributes in the openEHR Reference and Archetype Models, arranged into groups, each identified by a logical name such as “audit change type”. This document describes only the openEHR terms; the contents of other terminologies are described by the relevant publications.

The openEHR Terminology groups provide mappings to other recognised terminologies or vocabularies where available. Given that the attributes defined here are mostly coded attributes (i.e. predefined in the openEHR Reference Model), mappings tend to be to terms in vocabularies defined by standards organisations such as CEN and HL7, rather than large clinical vocabularies such as ICD10 (WHO). openEHR does not specify the use of these latter vocabularies.

2.2 Code Sets

Code sets whose codes are derived from resources published by external authorities are not shown in full here; the definitive resource is referenced instead. The openEHR code-set databases contain the full set of codes in each case. In the header of each table:

the issuer is the name of the issuing organisation;
the “openEHR code set id” is the identifier used for code sets by the openEHR Reference Model;
the “external identifier” is an identifier assumed by openEHR to be the identifier of this code set, based on its published name, with spaces replaced by underscores.

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 9 of 27 Date of Issue: 08 Apr 2007

Terminology Support Terminology Rev 1.0

2.2.1 Countries

This ISO code set defined by the ISO 3166-1 standard consists of 2-character names of countries and country subdivisions. For a definitive online rendition see http://www.unicode.org/unicode/online dat/countries.html .

	Issuer: ISO openEHR code set id: “countries” External identifier: “ISO_3166-1”
Code	Description	Mappings
“af”	“Afghanistan”
“al”	“Albania”
...	...

2.2.2 Character Sets

This IANA (Internet Naming Authority) code set consists of the names of recognised character sets. See http://www.iana.org/assignments/character-sets for authoritative source.

	Issuer: IANA openEHR code set id: “character sets” External identifier: “IANA_character-sets”
Code	Description	Mappings
ISO-10646-UTF-1
...
ISO_8859-3:1988
...

2.2.3 Compression algorithms

This code set consists of the names of algorithms used to compress data, and is drawn from HL7’s CompressionAlgorithms domain.

	Issuer: openehr openEHR code set id: “compression algorithms” External identifier: “openehr_compression_algorithms”
Code	Description	Mappings
“compress”	Original UNIX compress algorithm and file format using the LZC algorithm (a variant of LZW).	HL7_CompressionAlgorithm::10624
“deflate”	The deflate compressed data format as specified in RFC 1951. See ftp://ftp.isi.edu/in-notes/rfc1951.txt.	HL7_CompressionAlgorithm::10621
“gzip”	A compressed data format that is compatible with the widely used GZIP utility as specified in RFC 1952. See ftp://ftp.isi.edu/in-notes/rfc1952.txt.	HL7_CompressionAlgorithm::10622
“zlib”	A compressed data format that also uses the deflate algorithm. Specified as RFC 1950 See ftp://ftp.isi.edu/innotes/rfc1950.txt	HL7_CompressionAlgorithm::10623
“other”	Some other type of compression; might be retrievable upon direct inspection of data.

Date of Issue: 08 Apr 2007 Page 10 of 27 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

Support Terminology		Terminology
		Rev 1.0
2.2.4	Integrity check algorithms

This code set consists of the names of algorithms used to generate hashes for the purpose of integrity checks on data; its initial values are drawn from the HL7 IntegrityCheckAlgorithm domain.

	Issuer: openehr openEHR code set id: “integrity check algorithms” External identifier: “openehr_integrity_check_algorithms”
Code	Description (en)	Mappings
“SHA-1”	Secure hash algorithm - 1. Defined in FIPS PUB 180-1: Secure Hash Standard. As of April 17, 1995.	HL7_IntegrityCheckAlgorithm::17386
“SHA-256”	secure hash algorithm - 256. Defined in FIPS PUB 180-2: Secure Hash Standard	HL7_IntegrityCheckAlgorithm::17387
...	...

2.2.5 Languages

This ISO code set defined by the ISO 639-1 standard consists of the “alpha-2” form of names of languages. This does not cover all languages, whereas ISO 639-2 “alpha-3” covers many more languages of cultural or indigenous interest, but which nevertheless are unlikely to be supported by current software or operating systems. See http://www.loc.gov/standards/iso639-2/langhome.html.

		Issuer: ISO openEHR code set id: “languages” External identifier: “ISO_639-1”
Code		Description	Mappings
“ab”	“Abkhazian”
...	...
“bg”	“Bulgarian”
...	...
“zh”	“Chinese”
...	...

2.2.6 Media Types

This IANA (Internet Naming Authority) code set consists of the names of MIME media types. See http://www.iana.org/assignments/media-types/text/ for authoritative source.

© 2005-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
	Issuer: IANA openEHR code set id: “media types” External identifier: “IANA_media-types”
Code	Description	Mappings
“text/plain”	Plain text encoded according to RFC3676	HL7_MediaType::14826
“text/html”	HTML text encoded according to RFC2854	HL7_MediaType::14828
“text/richtext”	Rich text encoded according to RFC2046
“text/rtf”	Rich text encoded according to ftp://indri.primate.wisc.edu/pub/RTF/RTF-Spec.rtf.	HL7_MediaType::14831
“text/sgml”		HL7_MediaType::14829
“text/ rfc822-headers”

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 11 of 27 Date of Issue: 08 Apr 2007

Terminology Support Terminology Rev 1.0

	Issuer: IANA openEHR code set id: “media types” External identifier: “IANA_media-types”
Code	Description	Mappings
“text/xml”		HL7_MediaType::14830

“audio/basic”		HL7_MediaType::14836
“audio/mpeg”		HL7_MediaType::14837

“application/pdf”		HL7_MediaType::14833
“application/msword”		HL7_MediaType::14834

...	...	...

2.2.7 Normal Status

This code set codifies statuses of quantitative values with respect to a normal range for the measured analyte or phenomenon. Use generally restricted to laboratory results. Maps to some codes in HL7v2 User-defined table 0078 - Abnormal flags and to the HL7v3 ObservationInterpretation vocabulary. The HL7v3 mappings are shown below.

	Issuer: openehr openEHR code set id: “normal statuses” External identifier: “openehr_normal_statuses”
Code	Description (en)	Mappings
“HHH”	Value is critically high; requires urgent intervention.	HL7_ObservationInterpretation::C10227 (>)
“HH”	Value is abnormally high.	HL7_ObservationInterpretation::C10213
“H”	Value is borderline high.	HL7_ObservationInterpretation::S10210
“N”	Value is normal (in the normal range).	HL7_ObservationInterpretation::C10207
“L”	Value is borderline low.	HL7_ObservationInterpretation::S10209
“LL”	Value is abnormally low.	HL7_ObservationInterpretation::C10212
“LLL”	Value is critically low; requires urgent intervention.	HL7_ObservationInterpretation::C10226 (<)

2.3 The openEHR Terminology

Within the openEHR terminology, terms are identified in groups, each with its own identifier. The identifiers of the groups is defined in the Support Information Model, Terminology package. Each set of terms is described below on a per-group basis.

2.3.1 Attestation Reason

This vocabulary codifies attestation statuses of Compositions or other elements of the health record,

Date of Issue: 08 Apr 2007 Page 12 of 27 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

Support Terminology Terminology Rev 1.0

and is drawn from the HL7 ParticipationSignature domain, as used in CDA.


Concept id	Rubric (en)	Description (en)	Mappings
240	“signed”	The attested information has been signed by its signatory.	HL7_ParticipationSignature::10284
648	“witnessed”	This attested information has been witnessed by the signatory.

2.3.2 Audit Change Type

This vocabulary codifies the kinds of changes to data which are recorded in audit trails.

	Terminology: openehr Group_name(“en”): “audit change type”
Concept id	Rubric (en)	Description (en)	Mappings
249	“creation”	Change type was creation.	HL7_CDA: CEN:
250	“amendment”	Change type was amendment, i.e. correction of the previous version.	HL7_CDA: CEN:
251	“modification”	Change type was update of the previous version.	HL7_CDA: CEN:
252	“synthesis”	Change type was creation synthesis of data due to conversion process, typically a data importer.	HL7_CDA: CEN:
523	“deleted”	Change type was logical deletion.	HL7_CDA: CEN:
666	“attestation”	Existing data were attested.	HL7_CDA: CEN:
253	“unknown”	Type of change unknown.	HL7_CDA: CEN:

2.3.3 Composition Category

This vocabulary codifies the values of the category attribute of the COMPOSITION class in the rm.composition package.

Terminology: openehr Group_name(“en”): “composition category”
Concept id	Rubric (en)	Description (en)	Mappings
431	“persistent”	This Composition contains information which remains valid for (more or less) the life of the EHR. Typical persistent Compositions include “family history”, “problem list”, “current medications”, and “vaccination history”. The usual change type when creating a new version of a persistent composition is “modification”.

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 13 of 27 Date of Issue: 08 Apr 2007

Terminology Support Terminology Rev 1.0

Terminology: openehr Group_name(“en”): “composition category”
Concept id	Rubric (en)	Description (en)	Mappings
433	“event”	This composition pertains to a point in time or brief episode. Change types may usually be “modification” or “

2.3.4 Event Math Function

This vocabulary codifies mathematical functions of non-instantaneous events.

© 2005-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Terminology: openehr Group_name(“en”): “event math function”
Concept id	Rubric (en)	Description (en)	Mappings
145	“minimum”	Value of the interval-event is the minimum value of the discrete events which the interval-event summarises.
144	“maximum”	Value of the interval-event is the maximum value of the discrete events which the interval-event summarises.
267	“mode”	Value of the interval-event is the modal (most common) value of the discrete events which the interval-event summarises.
268	“median”	Value of the interval-event is the median (centre value in sorted series) value of the discrete events which the interval-event summarises.
146	“mean”	Value of the interval-event is the average value of the discrete events which the interval-event summarises.
147	“change”	Value of the interval-event is the net change over the period which the interval-event summarises.
148	“total”	Value of the interval-event is the sum of the values of the discrete events which the interval-event summarises (typically differential flow measurements, e.g. blood loss).
149	“variation”	Value of the interval-event is difference between the point maximum and point minimum over the period, in other words the value band into which all sample during a period fit. Useful for specifying a maximal allowed variation in a datum to still be considered the same (approximate) value.
521	“decrease”	This is a change - as in 147 - except indicates that the value, while a positive number, is actually a negative change. Typically used for negative changes like “weight loss: 5kg” or “blood pressure postural drop of 10 mm[Hg]”.

Date of Issue: 08 Apr 2007 Page 14 of 27 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

Support Terminology Terminology Rev 1.0

Terminology: openehr Group_name(“en”): “event math function”
Concept id	Rubric (en)	Description (en)	Mappings
522	“increase”	This is also a change, but is only a positive change and cannot be expressed as a negative. This can be used for positive changes like “Weight gain: 2.5kg”.
640	“actual”	Value of the datum was the value indicated during the entire time of the event, i.e. it is not an averaged or other computed value.

2.3.5 Instruction States

This vocabulary codifies the names of the states in the standard Instruction state machine, documented in the openEHR EHR Information model (Entry section).

Terminology: openehr Group_name(“en”): “Instruction states”
Concept id	Rubric (en)	Description (en)	Mappings
524	“initial”	The instruction is recorded but no state is determined
526	“planned”	The instruction is planned
527	“postponed”	The instruction has been posponed - it had not be commenced
528	“cancelled”	The instruction has been cancelled - it had not been commenced and will not commence in the future
529	“scheduled”	The instruction has been scheduled to be carried out at a particular time
245	“active”	The instruction is currently being carried out
530	“suspended”	The instruction is suspended, it has been activated but is not active at present. It could be active again in the future.
531	“aborted”	The instruction is aborted, it has been activated but ceased before it has been completed and will not be restarted in the future.
532	“completed”	The instruction has been completed
533	“expired”	The instruction has expired, timed out - and assumed to have either been cancelled, aborted or completed

2.3.6 Instruction Transitions

This vocabulary codifies the names of the transitions in the standard Instruction state machine, docu

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 15 of 27 Date of Issue: 08 Apr 2007

Terminology Support Terminology Rev 1.0

mented in the openEHR EHR Information model (Entry section).

© 2005-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
Terminology: openehr Group_name(“en”): “Instruction transitions”
Concept id	Rubric (en)	Description (en)	Mappings
535	“initiate”	Initiate the planning of the Instruction.
536	“plan step”	Any step in the planned state of the Instruction, e.g. signing, approving.
537	“postpone”	Put a planned Instruction on hold, while still in the planning stage, i.e. before it has been booked or started.
538	“restore”	Restore a previously postponed Instruction back to the planned state.
166	“cancel”	Cancel a planned Instruction, before it is booked or started.
542	“postponed step”	Any step in the postponed state of the Instruction.
539	“schedule”	Where booking is required, book the activities in the Instruction in a scheduling system.
540	“start”	Start executing the activities in the Instruction, e.g. commence drug administration course.
541	“do”	Do the activities in the Instruction in one go, taking the state machine directly from the planned to the completed state. Used for Instructions whose activities are instantaneous in the practical sense, e.g. a single vaccination, single tablet.
543	“active step”	Any step taken during the active phase of the Instruction, e.g. nurse’s observation, adjustment of dose.
544	“suspend”	Suspend the activities from the active phase, with the possibility of later resumption.
545	“suspended step”	Any step taken in the suspended state, e.g. nurse’s observation, pathology test to determine if the Instruction should be resumed, remain suspended or aborted.
546	“resume”	Resume the Instruction from the suspended state.
547	“abort”	Abort the Instruction, i.e. stop its execution permanently after it has started.
548	“finish”	Finish performing the Instruction, taking it to the completed state.
549	“time out”	Time out has occurred, taking the Instruction from some pervious state into the expired state.
540	“notify aborted”	Occurs when notification of Instruction having been aborted is received after expiry.
551	“notify completed”	Occurs when notification of Instruction having been completed is received after expiry.

Date of Issue: 08 Apr 2007 Page 16 of 27 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

Support Terminology Terminology Rev 1.0

Terminology: openehr Group_name(“en”): “Instruction transitions”
Concept id	Rubric (en)	Description (en)	Mappings
552	“notify cancelled”	Occurs when notification of Instruction having been cancelled is received after expiry.

2.3.7 Null Flavours

This vocabulary codifies “flavours of null” for missing data items.

	Terminology: openehr Group_name(“en”): “null flavours”
Concept id	Rubric (en)	Description (en)	Mappings
271	“no information”	No information provided; nothing can be inferred as to the reason why, including whether there might be a possible applicable value or not.	HL7_NullFlavor::V10610
253	“unknown”	A possible value exists but is not provided.	HL7_NullFlavor::V10612
272	“masked”	The value has not been provided due to privacy settings.	HL7_NullFlavor::17932
273	“not applicable”	No valid value exists for this data item.	HL7_NullFlavor::10611

2.3.8 Participation Function

This vocabulary codifies functions of participation of parties in an interaction (used in PARTICIPATION class).

Terminology: openehr Group_name(“en”): “participation function”
Concept id	Rubric (en)	Description (en)	Mappings
253	unknown

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 17 of 27 Date of Issue: 08 Apr 2007

Terminology Support Terminology Rev 1.0

2.3.9 Participation Mode

This vocabulary codifies modes of participation of parties in an interaction (used in PARTICIPATION class). The initial set has been defined to be the same as HL7’s ParticipationMode vocabulary domain.

© 2005-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
	Terminology: openehr Group_name(“en”): “participation mode”
Concept id	Rubric (en)	Description (en)	Mappings
193	“not specified”	Mode of participation is not specified; use only for legacy data.
216	“face-to-face communication”	Face to face communications between parties in the same room.	HL7_ParticipationMode::16545
223	“interpreted face-toface communication”	Face to face communications between parties in the same room with an interpreter	HL7_ParticipationMode::16545
217	“signing (face-toface)”	Live face-to-face communication using a recognised sign language.
195	“live audiovisual; videoconference; videophone”	Any audio-visual communication in real time
198	“videoconferencing”	Live audio-visual communication over videoconferencing or other similar equipment.	HL7_ParticipationMode::16548
197	“videophone”	Live audio-visual communication
218	“signing over video”	Live video communication using sign language.
224	“interpreted video communication”	Live audio-visual communication involving an interpreter
194	“asynchronous audiovisual; recorded video”	Audio-visual communication that is not live
196	“recorded video”	Recorded video or video mail
202	“live audio-only; telephone; internet phone; teleconference”	Any live audio-only communication.	HL7_ParticipationMode::V16544 (includes live)
204	“telephone”	Live verbal communication over a telephone.	HL7_ParticipationMode::16546
203	“teleconference”	Live verbal communication over teleconference	HL7_ParticipationMode::16546
204	“internet telephone”	Live verbal communication over a the internet.	HL7_ParticipationMode::16546
222	“interpreted audio-only”	Any live audio-only communication using an interpreter.	HL7_ParticipationMode::V16544 (includes live)
199	“asynchronous audio-only; dictated; voice mail”	Audio-only communication that is not live.
200	“dictated”	Non-interactive audio-only information recorded on some medium, such as cassette tape.	HL7_ParticipationMode::16547
201	“voice-mail”	Audio messaging system

Date of Issue: 08 Apr 2007 Page 18 of 27 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

Support Terminology Terminology Rev 1.0

	Terminology: openehr Group_name(“en”): “participation mode”
Concept id	Rubric (en)	Description (en)	Mappings
212	“live text-only; internet chat; SMS chat; interactive written note”	Any live text-only communication
213	“internet chat”	Live text-only communication over the internet
214	“SMS chat”	Live text-only chat over mobile/cell phone
215	“interactive written note”	Live text-only communication using written notes	HL7_ParticipationMode::16550
206	“asynchronous text; email; fax; letter; handwritten note; SMS message”	Any text-only communication including email, written text, SMS message etc.	HL7_ParticipationMode::V16549
211	“handwritten note”	Written communication by handwritten document.	HL7_ParticipationMode::16550
210	“printed/typed letter”	Written communication by typewritten document.	HL7_ParticipationMode::16551
207	“email”	Written communication by email.	HL7_ParticipationMode::16553 [ inlcude HL7_ParticipationMode::16554 (electronic data)]
208	“facsimile/telefax”	Non-interactive written communication using a fax machine.	HL7_ParticipationMode::16552
221	“translated text”	Non-interactive written communication requiring translation	HL7_ParticipationMode::V16549
209	“SMS message”	Messages sent via mobile/cell phone
219	“physically present”	Participation by actions, where the participant is physically present.	HL7_ParticipationMode::16556
220	“physically remote”	Participation by actions, where the participant is not physically present, and the actions are transmitted by electronic means.	HL7_ParticipationMode::16557

2.3.10 Property

This vocabulary codifies purposes for physical properties corresponding to formal unit specifications, and allows comparison of Quantities with different units but which measure the same property. The vocabulary values are taken from:

CEN ENV 12435 - “Medical Informatics - Expression of results of measurements in health sciences”
HL7 “Unified Codes for Units of Measure”

		Terminology: openehr Group_name(“en”): “property”
Concept id	Rubric (en)	Description (en)	Mappings
339	Acceleration

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 19 of 27 Date of Issue: 08 Apr 2007

Terminology Support Terminology Rev 1.0

© 2005-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
		Terminology: openehr Group_name(“en”): “property”
Concept id	Rubric (en)	Description (en)	Mappings
342	Acceleration, angular
381	Amount (Eq)
384	Amount (mole)
497	Angle, plane
500	Angle, solid
335	Area
350	Density
362	Diffusion coefficient
501	Electrical capacitance
498	Electrical charge
502	Electrical conductance
334	Electrical current
377	Electrical field strength
121	Energy
366	Energy density
508	Energy dose
365	Energy per area
347	Flow rate, mass
352	Flow rate, mass/force
351	Flow rate, mass/volume
126	Flow rate, volume
348	Flux, mass
355	Force
357	Force, body
382	Frequency
373	Heat transfer coefficient
505	Illuminance
379	Inductance
122	Length
499	Light intensity
123	Loudness
504	Luminous flux
378	Magnetic flux

Date of Issue: 08 Apr 2007 Page 20 of 27 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

Support Terminology Terminology Rev 1.0

© 2005-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
	Terminology: openehr Group_name(“en”): “property”
Concept id	Rubric (en)	Description (en)	Mappings
503	Magnetic flux density
124	Mass
385	Mass (IU)
349	Mass per area
344	Moment inertia, area
345	Moment inertia, mass
340	Momentum
346	Momentum, flow rate
343	Momentum, angular
369	Power density
368	Power flux
367	Power, linear
125	Pressure
507	Proportion
380	Qualified real	This is a number with an arithmetic qualification (which may be no units, 103 etc) allowing integers to be expressed as reals raised to a nominated power, or for real numbers alone.
506	Radioactivity
375	Resistance
370	Specific energy
371	Specific heat, gas content
337	Specific surface
336	Specific volume
356	Surface tension
127	Temperature
128	Time
338	Velocity
341	Velocity, angular
360	Velocity, dynamic
361	Velocity, kinematic
374	Voltage, electrical
129	Volume
130	Work

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 21 of 27 Date of Issue: 08 Apr 2007

Terminology Support Terminology Rev 1.0

2.3.11 Setting

This vocabulary codifies broad types of settings in which clinical care is delivered. It is not intended to be a perfect classification of the real world, but instead a practical coarse-grained categorisation to aid querying.

		Terminology: openehr Group_name(“en”): “setting”
Concept id	Rubric (en)	Description (en)	Mappings
225	“home”	Care delivered in the patient’s home by patient or health professional.
227	“emergency care”	Care delivered in emergency situation, e.g. by ambulance workers.
228	“primary medical care”	Care delivered by a doctor within a primary care framework (generalist, non-referred).
229	“primary nursing care”	Care delivered by nurses within a primary care framework (community based, generalist clinic).
230	“primary allied health care”	Care delivered by allied health practitioners such as physiotherapists, osteopaths, chiropracters, optometrists, chiropodist/pediatrist etc. within a primary care framework (community based, generalist clinic)
231	“midwifery care”	Midwifery care in any framework
232	“secondary medical care”	Care delivered in an institutional or specialist setting - usually as a result of a referral.
233	“secondary nursing care”	Care delivered by nurses within a secondary care framework (inpatient, specialist clinic).
234	“secondary allied health care”	Care delivered by allied health care professionals within a secondary care framework (inpatient, specialist clinic).
235	“complementary health care”	Care delivered by chinese, ayurvedic, naturopath, homeopath etc practitioner.
236	“dental care”	Care delivered in a dental practitioner setting.
237	“nursing home care”	Care to the needs of patients in nursing homes, delivered in an institutional setting.
238	“other care”	Care delivered in setting not described by other terms in this vocabulary.

2.3.12 Subject relationship

This vocabulary codifies the relationship between the subject of care and some other party mentioned in the health record.

	Terminology: openehr Group_name(“en”): “subject relationship”
Concept id	Rubric (en-uk)	Description (en)	Mappings
0	“self”	The party is the subject of EHR	HL7_RoleCode:: CEN:

Date of Issue: 08 Apr 2007 Page 22 of 27 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

Support Terminology Terminology Rev 1.0

© 2005-2007 The openEHR Foundation. email: info@openEHR.org web: http://www.openEHR.org
	Terminology: openehr Group_name(“en”): “subject relationship”
Concept id	Rubric (en-uk)	Description (en)	Mappings
3	“foetus”	The party is a foetus	HL7: CEN:
10	“mother”	The party is the mother of the subject of EHR	HL7: CEN:
9	“father”	The party is the father of the subject of the EHR	HL7: CEN:
6	“donor”	The party is a donor of organs or other body products to the EHR subject.	HL7: CEN:
253	“unknown”	Relationship to party is unknown.	HL7: CEN:
261	“adopted daughter”	Relationship of adopted daughter to subject of EHR	HL7: CEN:
260	“adopted son”	Relationship of adopted son to subject of EHR	HL7: CEN:
259	“adoptive father”	Relationship of adoptive father to subject of EHR	HL7: CEN:
258	“adoptive mother”	Relationship of adoptive mother to subject of EHR	HL7: CEN:
256	“biological father”	Relationship of biological father to subject of EHR	HL7: CEN:
255	“biological mother”	Relationship of biological mother to subject of EHR	HL7: CEN:
23	“brother”	Relationship of brother to subject of EHR	HL7: CEN:
28	“child”	Relationship of child to subject of EHR	HL7: CEN:
265	“cohabitee”	Lives with the subject of EHR	HL7: CEN:
257	“cousin”	Relationship of cousin to subject of EHR	HL7: CEN:
29	“daughter”	Relationship of daughter to subject of EHR	HL7: CEN:
264	“guardian”	Relationship of guardianto subject of EHR	HL7: CEN:
39	“maternal aunt”	Relationship of maternal aunt to subject of EHR	HL7: CEN:
8	“maternal grandfather”	Relationship of maternal grandfather to subject of EHR	HL7: CEN:
7	“maternal grandmother”	Relationship of maternal grandmother to subject of EHR	HL7: CEN:
38	“maternal uncle”	Relationship of maternal uncle to subject of EHR	HL7: CEN:
189	“neonate”	Relationship of neonate to subject of EHR	HL7: CEN:
254	“parent”	Relationship of parent to subject of EHR	HL7: CEN:
22	“partner/spouse”	The husband or wife or life partner of the subject of EHR	HL7: CEN:
41	“paternal aunt”	Relationship of paternal aunt to subject of EHR	HL7: CEN:

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 23 of 27 Date of Issue: 08 Apr 2007

Terminology Support Terminology Rev 1.0

	Terminology: openehr Group_name(“en”): “subject relationship”
Concept id	Rubric (en-uk)	Description (en)	Mappings
36	“paternal grandfather”	Relationship of aternal grandfather to subject of EHR	HL7: CEN:
37	“paternal grandmother”	Relationship of paternal grandmother to subject of EHR	HL7: CEN:
40	“paternal uncle”	Relationship of paternal uncle to subject of EHR	HL7: CEN:
27	“sibling”	Relationship of sibling to subject of EHR	HL7: CEN:
24	“sister”	Relationship of sister to subject of EHR	HL7: CEN:
31	“son”	Relationship of son to subject of EHR	HL7: CEN:
263	“step father”	Relationship of step father to subject of EHR	HL7: CEN:
262	“step mother”	Relationship of step mother to subject of EHR	HL7: CEN:
25	“step or half brother”	Relationship of step or half brother to subject of EHR	HL7: CEN:
26	“step or half sister”	Relationship of step or half sister to subject of EHR	HL7: CEN:

2.3.13 Term Mapping Purpose

This vocabulary codifies purposes for term mappings as used in the class TERM_MAPPING. The use-case for this vocabulary is yet to be determined.

	Terminology: openehr Group_name(“en”): “term mapping purpose”
Concept id	Rubric (en)	Description (en)	Mappings
669	“public health”	Public health related term mapping.
670	“reimbursement”	Reimbrusement / billing related term mapping.
671	“research study”	Term mapping.for research study

Date of Issue: 08 Apr 2007 Page 24 of 27 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

Support Terminology		Terminology
		Rev 1.0
2.3.14	Version Lifecycle State

This vocabulary codifies lifecycle states of Compositions or other elements of the health record.

Terminology: openehr Group_name(“en”): “version lifecycle state”
Concept id	Rubric (en)	Description (en)	Mappings
532	“complete”	Item is complete at time of committal.
553	“incomplete”	Item is incomplete at time of committal, in the view of the author. Further editing or review needed before its status will be set to “finished”.
523	“deleted”	Item has been logically deleted.

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 25 of 27 Date of Issue: 08 Apr 2007

Terminology Support Terminology Rev 1.0

Date of Issue: 08 Apr 2007 Page 26 of 27 Editors:{T Beale, S Heard}, {D Kalra, D Lloyd}

Support Terminology

Rev 1.0

END OF DOCUMENT

Editors:{T Beale, S Heard}, {D Kalra, D Lloyd} Page 27 of 27 Date of Issue: 08 Apr 2007