EN 13609-1:2005

SLOVENSKI STANDARD
01-september-2005
=GUDYVWYHQDLQIRUPDWLND±6SRURþLOD]DY]GUåHYDQMHLQIRUPDFLMVNHSRGSRUHSUL
VLVWHPLK]GUDYVWYHQHJDYDUVWYD±GHO2EQDYOMDQMHNRGLUQLKVKHP
Health informatics - Messages for maintenance of supporting information in healthcare
systems - Part 1: Updating of coding schemes
Medizinische Informatik - Nachrichten für die Pflege von unterstützender Information in
medizinischen Systemen - Teil 1: Aktualisierung der Kodierungsschemata
Informatique de santé - Messages pour la maintenance de l'information
d'accompagnement dans les systemes de santé -Partie 1: Mise a jour des schémas de
codage
Ta slovenski standard je istoveten z: EN 13609-1:2005
ICS:
35.240.80 Uporabniške rešitve IT v IT applications in health care
zdravstveni tehniki technology
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD
EN 13609-1
NORME EUROPÉENNE
EUROPÄISCHE NORM
May 2005
ICS 35.240.80
English version
Health informatics - Messages for maintenance of supporting
information in healthcare systems - Part 1: Updating of coding
schemes
Informatique de santé - Messages pour la maintenance de Einführendes Element - Haupt-Element - Teil 1:
l'information d'accompagnement dans les systèmes de Ergänzendes Element
santé -Partie 1: Mise à jour des schémas de codage
This European Standard was approved by CEN on 15 March 2005.
CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European
Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such national
standards may be obtained on application to the Central Secretariat or to any CEN member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation
under the responsibility of a CEN member into its own language and notified to the Central Secretariat has the same status as the official
versions.
CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France,
Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia,
Slovenia, Spain, Sweden, Switzerland and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: rue de Stassart, 36  B-1050 Brussels
© 2005 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 13609-1:2005: E
worldwide for CEN national Members.

Contents
Foreword.4
Introduction .5
1 Scope .6
2 Normative references .7
3 Terms and definitions .7
4 Requirements.9
5 Communication roles and supported services .10
5.1 General.10
5.2 Communication roles .10
5.3 Communication roles, services and General Message Description .10
6 General Message Description .11
6.1 Introduction.11
6.2 The modelling approach .11
6.3 The Healthcare Agent in Context Sub-System .11
6.4 Update Coding Scheme Message .12
6.4.1 Purpose of Message.12
6.4.2 Scope of Message.12
6.4.3 Hierarchical General Message Description.13
7 Domain Information Model .13
7.1 Introduction.13
7.2 Top Level Model.14
7.2.1 Introduction.14
7.3 Communicating Parties subsystem.15
7.3.1 General Description.15
7.3.2 Coding Scheme Provider .15
7.3.3 Coding Scheme Information Receiver.15
7.4 Healthcare Agent subsystem .16
7.4.1 General Description.16
7.4.2 Healthcare Agent .17
7.4.3 Healthcare Agent in Context.17
7.4.4 Healthcare Agent Relationship.18
7.4.5 Healthcare Organisation .18
7.4.6 Healthcare Party.19
7.4.7 Healthcare Person .19
7.5 Coding Scheme Update subsystem.20
7.5.1 General Description.20
7.5.2 Update Coding Scheme Message.21
7.5.3 Coding Scheme Information.21
7.5.4 Coding Scheme Originator .22
7.6 Coding Scheme Update Operation subsystem .22
7.6.1 General Description.22
7.6.2 Code Value Entry.23
7.6.3 Aggregate Code Value .24
7.6.4 Associated Code Value.25
7.6.5 Code Value Group .25
7.6.6 Code Value Validation.26
7.6.7 Code Meaning .27
7.6.8 Mapping Term Entry.28
7.7 Common Sub-Classes.29
7.7.1 Address.29
7.7.2 Associated Code.29
7.7.3 Coding scheme details.30
7.7.4 Person name details.30
7.7.5 Structured address.31
7.7.6 Structured person name .31
7.7.7 Structured telecommunication number .32
7.7.8 Telecommunication.32
7.7.9 Unstructured address .33
7.7.10 Validity dates.33
7.8 Other Simple Data Types .33
7.8.1 Introduction.33
7.8.2 CS: Coded Simple Value.34
7.8.3 CV: Coded Value.34
7.8.4 II: Instance Identifier.35
Annex A (informative) Unified Modeling Language Notation used within this document.36
A.1 Model Components.36
A.2 Packages .36
A.3 Classes .36
A.4 Types of relationships between classes.37
Annex B (informative) Scenarios and Message Explanation.39
B.1 The transfer of a set of EDIFACT codes for use in a Laboratory Request Message.39
B.2 Implementation of the IFCC/IUPAC coding scheme .40
Bibliography.42

Foreword
This document (EN 13609-1:2005) has been prepared by Technical Committee CEN/TC 251 “Health informatics”,
the secretariat of which is held by SIS.
This standard consists of the following parts, under the general title Messages for maintenance of supporting
information in healthcare systems:
- Part 1: Updating of coding schemes
- Part 2: Updating of medical laboratory specific information
This European Standard shall be given the status of a national standard, either by publication of an identical text or
by endorsement, at the latest by November 2005, and conflicting national standards shall be withdrawn at the latest
by November 2005.
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to implement this European Standard: Austria, Belgium, Cyprus, Czech Republic, Denmark,
Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta,
Netherlands, Norway, Poland, Portugal, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.

Introduction
The increased use of data processing and telecommunications capabilities has made possible the interchange of
information in machine readable and machine processable formats. As automated interchange of information in
healthcare increases, it is essential to provide appropriate information interchange standards.
Computer systems are now used by healthcare professionals for a wide range of purposes. The healthcare specific
data held on these systems is often held in a coded form, i.e. code values are used to represent particular concepts
or meanings which are used to represent items of data such as diagnoses, procedures, investigations, medicinal
items, organisations and professionals, etc. This European Standard defines a syntax independent specification of
a message that may be used to provide a means of supplying receiving systems with sufficient information to
populate a locally defined coding scheme.
The choice of coding scheme(s) used by an application will depend upon a number of factors: the supplier’s policy,
the nature of the application, national or regional policy, etc. When information is exchanged between applications
in coded format, there is often a need to convert from code values taken from a coding scheme used in the
originating application to equivalent code values from another coding scheme. The code value mapping
information will generally be held in a database available to the user of the coding scheme and this European
Standard provides a syntax independent description of a message that may be used to maintain the information in
such a database.
This European Standard is intended for use by message developers. Its provisions are directly relevant to
suppliers of computer systems for use generally within healthcare. Its provisions are also relevant to those
planning, specifying, procuring or implementing information systems for use in hospitals, general practices, clinical
departments and specialist clinics.
The main normative provisions in this European Standard are expressed in clauses 4, 5, 6 and 7.
Much, although not all, of the representation used in this European Standard is drawn from the Unified Modeling
Language (UML). The reader should, however, interpret the representations within this European Standard
according to the provisions laid out in informative Annex A.
1 Scope
1.1
This European Standard specifies messages for electronic information exchange between computer systems using
coding schemes in healthcare. It describes a message that may be used to populate or update the content of a
coding scheme at user applications.

1.2
This European Standard is limited to a definition of the content of a message that serves the following functions:

a) to populate a new coding scheme where individual entries are composed of a code value related to zero or
more (textual) code meanings,
b) to add new entries into an existing coding scheme where these entries are composed of new code values and
their associated meanings,
c) to mark existing code value entries as no longer active,
d) to mark new and existing code meanings to be of a certain status (e.g. preferred, obsolete, etc.),
e) to mark new and existing code values with dates of applicability,
f) to mark new and existing code meanings with dates of applicability.
1.3
This European Standard provides a specification of a message that may be used to populate or update a mapping
between a single code value in a coding scheme and simple list of code values that together have an equivalent
meaning in the same coding scheme. This meets the requirements of ENV 1614 – Healthcare informatics –
Structure for nomenclature, classification and coding of properties in clinical laboratory sciences.

1.4
This European Standard provides a specification of a message that may be used to populate or update a mapping
showing equivalence between code values in two different coding schemes. The specification supports mappings
in which:
a) a single code value in one (source) coding scheme is mapped to a single equivalent code value within another
(target) coding scheme,
b) a single code value in the source coding scheme is mapped to a set of code values which together represent
an equivalent concept within the target coding scheme.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated references,
only the edition cited applies. For undated references, the latest edition of the referenced document (including any
amendments) applies.
ENV 1613 Medical informatics - Messages for exchange of laboratory information
CR 12587 Medical Informatics – Methodology for the development of healthcare
messages
CEN/TS 14796 Health informatics – Data types
ISO 2382-4 Information technology – Vocabulary – Part 4: Organisation of data
ISO/IEC 6523-1 Information technology – Structure for the identification of organizations and
organization parts – Part 1: Identification of organization identification schemes
ISO/IEC 8824-1 Information technology - Abstract Syntax Notation One (ASN.1): Specification
of basic notation
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
association
binary predicate applied to an ordered pair of types. The first type is referred to as the source type and the second
as the target type
3.2
concept
subset of knowledge constructed through combining characteristics

3.3
coded concept
element within a coded set
EXAMPLE: "Paris Charles-De-Gaulle" which is mapped on to the three-letter abbreviation "CDG" by the coding
scheme for three-letter abbreviations of airport names.

3.4
coded set
set of elements that is mapped onto another set according to a code
[ISO 2382-4]
EXAMPLE: A list of the names of airports which is mapped on to a set of three letter abbreviations.

3.5
code meaning
element within a coded set
EXAMPLE "Paris Charles-De-Gaulle" which is mapped on to the three-letter abbreviation "CDG" by the coding
scheme for three-letter abbreviations of airport names.

3.6
code value
result of applying a code to an element of a coded set
[ISO 2382-4]
EXAMPLE: "CDG" as the representation of "Paris Charles-De-Gaulle" in the coding scheme for three-letter
representations of airport names.

3.7
coding scheme
collection of rules that maps the elements of a first set onto the elements of a second set
[ISO 2382-4]
3.8
domain information model
DIM
conceptual model describing common concepts and their relationships for communication parties required to
facilitate exchange of information between these parties within a specific domain of healthcare
[ENV 1613]
3.9
general message description
GMD
subset of a domain information model prescribing the information content and semantic structure of a message
used to meet one or more identified information interchange requirements
[ENV 1613]
3.10
healthcare organisation
organisation responsible for the direct or indirect provision of healthcare services
[ENV 1613]
3.11
hierarchical relation
relation between two concepts arranged in graded order
[ISO 2382-4]
3.12
message type
identified, named and structured set of functionally related information which fulfils a specific business purpose
[ENV 1613]
3.13
organisation
unique framework of authority within which a person or persons act, or are designated to act towards some
purpose
[ISO/IEC 6523-1]
4 Requirements
4.1 A compliant implementation shall conform to the provisions laid out in 4.2, and to any or all of the requirements
identified by message type and laid out in 4.3 and 4.4. as specified in this document.

4.2 An Update Coding Scheme Message from a coding scheme provider to the user of the coding scheme covered
by the scope of this document, shall conform to the mandatory provisions defined in 7.3, 7.5 and 7.6 subject to the
provisions laid out in the following sub-clauses:
- All mandatory requirements and conditions laid out in 7.6.2 and 7.6.7, shall be fully complied with.
- A conformant message implementation may, if appropriate, not include the provisions concerning Aggregate
Code Value within 7.6.3. If the message does include such facilities it shall conform fully to the requirements laid
out in 7.6.3 and may be described as ‘Aggregate Code Value compliant’.
- A conformant message implementation may, if appropriate, not include the provisions concerning Associated
Code Values within 7.6.4. If the message does include such facilities it shall conform fully to the requirements
laid out in 7.6.4 and may be described as ‘Associated Code Value compliant’.
- A conformant message implementation may, if appropriate, not include the provisions laid out in 7.6.5 (Code
Value Group). If the message does include such facilities it shall conform fully to the requirements laid out in
7.6.5 and may be described as ‘Code Value Group compliant’.
- A conformant message implementation may, if appropriate, not include the provisions laid out in 7.6.6 (Code
Value Validation). If the message does include such facilities it shall conform fully to the requirements laid out in
7.6.6 and may be described as ‘Code Value Validation compliant’.
- A conformant message implementation may, if appropriate, not include the provisions laid out in 7.6.8 (Mapping
Term Entry). If the message does include such facilities it shall conform fully to the requirements laid out in 7.6.8
and may be described as ‘Mapping Term Entry compliant’.
4.3 Implementable message specifications (IMS) shall conform to the General Message Description defined in this
document. They shall support both mandatory and optional objects subject to the provisions laid out in 4.2 above.
Where appropriate they shall also support the relationships between objects as defined by the General Message
Description.
4.4 Implementable message specifications should be expressed in terms of a syntax which is an International
standard except where the healthcare user requirements cannot be met by using such a standard syntax.
5 Communication roles and supported services
5.1 General
This clause defines the communication roles compliant with the specifications of this document when exchanging
information on coding schemes within the scope. It establishes the relationships between the communication roles
and the General Message Description.
5.2 Communication roles
This document defines a single message structure. Coding scheme suppliers in co-operation with their message
recipients may choose their own message sub-sets or profiles depending upon their particular requirements.
The communicating parties shall adopt one of two communication roles: the message originating role or the
message destination role. These roles are assumed by two types of healthcare organisations: the coding scheme
provider and the coding scheme information receiver
5.3 Communication roles, services and General Message Description
5.3.1 The service that shall be supported by a communication party with a message originating role for an Update
Coding Scheme Message shall be to:
issue update instances which comply with the General Message Description and which convey in a complete and
exact way the information as intended by the originator and as to be understood by the receiver.
5.3.2 The service that shall be supported by a communication party with a message destination role for an
Update Coding Scheme Message shall be to:
receive update instances which comply with the General Message Description and which allow the complete and
exact understanding of the information by the coding scheme receiver as intended by the coding scheme
provider.
6 General Message Description
6.1 Introduction
This section provides a description of the message using a hierarchical structure.
This document does not set limits on the number of repetitions of objects and attributes but implementations which
do set practical limits are not by that reason alone considered to be deviating from the standard.

6.2 The modelling approach
The General Message Descriptions (GMDs) are shown in the form of a hierarchical structure indicating the objects
(class instances) and their associated multiplicities that are required to implement the message. Many objects
within the GMD are shown as optional and for an implementation intended for a given coding scheme these objects
may be excluded. Where an object is included in the implementation, the structure of the object and the rules that
apply to it shall conform to the appropriate class descriptions shown within the Domain Information Model.
The GMD has appended notes and explanations that supply additional guidance.

6.3 The Healthcare Agent in Context Sub-System
Within the General Message Description provided in 6.4, there are three classes, namely: Coding Scheme Provider,
Coding Scheme Information Receiver and Coding Scheme Originator, which are specialisations of Healthcare
Agent in Context. Where these classes are encountered within the General Message Description (see Figure 2),
the structure shown in Figure 1 shall be substituted.

healthcare agent in context – see 7.4.3
healthcare agent – see 7.4.2
0.1
healthcare party – see 7.4.6
healthcare person - see 7.4.7
is specialised as
one of
healthcare organisation - see 7.4.5
0.*
healthcare agent relationship– see 7.4.4
healthcare agent – see 7.4.2
0.1
healthcare party – see 7.4.6
healthcare person - see 7.4.7
is specialised as
one of
healthcare organisation - see 7.4.5

Figure 1  — Healthcare Agent in Context Sub System
6.4 Update Coding Scheme Message
6.4.1 Purpose of Message
This is a message which provides the full range of coding scheme update facilities.  The user may utilise sub-
sets of the message in order to carry out particular updates of certain aspects of the coding scheme.

6.4.2 Scope of Message
This message is intended to cover the following scope:
(a) creation of a new simple coding scheme
(b) addition of new terms (code values with meanings) within an existing coding scheme
(c) changing of the status of an existing code value (e.g. making redundant)
(d) addition or removal of aggregated code values within an existing coding scheme
(e) addition or removal of associations of the code values with other code values (e.g. showing preferred
term or replacement code value)
(f) addition or removal of grouping information for a new or existing code value within a coding scheme
(g) addition or removal of validation information for a new or existing term within a coding scheme
(h) addition or removal of code meanings and/or the status of such code meanings within a coding
scheme
(i) creation of a new mapping table which provides the cross-referencing of terms that exist in different
coding schemes
(j) updating of mapping tables
6.4.3 Hierarchical General Message Description
Update Coding Scheme Message – see 7.5.2
Coding Scheme Information- see 7.5.3
0.1
Coding Scheme Originator - see 7.5.4
Coding Scheme Provider - see 7.3.2
Coding Scheme Information Receiver - see 7.3.3
1.*
Code Value Entry - see 7.6.2
0, 2.*
Aggregate Code Value – see 7.6.3
0.*
Associated Code Value – see 7.7.2
0.*
Code Value Group – see 7.6.5
0.*
Code Value Validation – see 7.6.6
0.*
Code Meaning – see 7.6.7
0.*
Mapping Term Entry – see 7.6.8

Figure 2  — Hierarchical General Message Description – Update Coding Scheme Message

7 Domain Information Model
7.1 Introduction
The Domain Information Model (DIM) and the General Message Description (GMD) are built based on the
approach defined by CR 12587, but the modelling used here is based upon the Unified Modeling Language (UML).
To enhance readability other symbols have been used within the presentation.
The DIM is presented initially as top level representation of the whole domain, showing the various subsystems that
constitute this message domain and the nature of the relationships between them. This is followed by detailed
descriptions of each of the subsystems, which define the constituent classes, their attributes and the relationships.
Conformance to the Standard necessitates conformance to the requirements laid out within these normative
subsystem descriptions.
It is essential to interpret the models in accordance with the provisions laid out in Annex A, “How to Read the
Models”.
7.2 Top Level Model
7.2.1 Introduction
This clause contains formal textual specifications of the classes used in the message specified in clause 6. The
model shows the major groupings of information classes that are encountered in the messages

Communicating Parties see 7.3
Healthcare Agent subsystem (incomplete) see 7.4

Coding Scheme Information
Coding Scheme Provider
Healthcare Agent in
Receiver
Context
see 7.3.2 See 7.3.3
see 7.4.3
Coding Scheme Update subsystem see 7.5
Update Coding Scheme Coding Scheme Information
Coding Scheme Originator
Message
0.1
see 7.5.2 see 7.5.3 see 7.5.4
Coding Scheme Update Operation subsystem
see 7.6
1.*
Code Value Entry 0.* Code Meaning Entry

see 7.6.7
see 7.6.2
0, 2.*
0.*
Mapping Term Entry
Aggregate Code Value
see 7.6.8
see 7.6.3
0.* 0.*
0.*
Code Value Group Code Value Validation
Associated Code Value
see 7.6.6
see 7.6.4 see 7.6.5
Figure 3  — Top Level Domain Information Model – Update Coding Scheme
7.3 Communicating Parties subsystem General Description
Healthcare Agent
Coding Scheme Update
subsystem (incomplete)
subsystem (incomplete)
Coding Scheme
Provider
see 7.3.2
Coding Scheme Update Coding Scheme
Healthcare Agent in Message
Information Receiver
Context
1 1
see 7.5.2
see 7.3.3
see 7.4.3
Figure 4  — Communicating parties subsystem and associations

This subsystem provides details of the organisations that send or receive coding scheme update information
within this domain. Each of these communicating parties are described in a way which is conformant to
preceding European Prestandards (ENVs ).

7.3.2 Coding Scheme Provider
Type: class
Specialisation of Healthcare Agent in Context
Used to identify the communicating party that sends the message.
Associations
An instance of Coding Scheme Provider is associated with one instance of Update Coding
Scheme Message.
Attributes:
Attributes of generalisation Healthcare Agent in Context (7.4.3)

7.3.3 Coding Scheme Information Receiver
Type: class
Specialisation of Healthcare Agent in Context
Used to identify the communicating party (receiver of the message) that is the organisation that
is the user of the coding scheme.
Associations
An instance of Coding Scheme Receiver is associated with one instance of Update Coding
Scheme Message.
Attributes:
Attributes of generalisation Healthcare Agent in Context (7.4.3)

7.4 Healthcare Agent subsystem
7.4.1 General Description
The healthcare agent subsystem supports different ways of referring to healthcare persons and healthcare
organisations from within a message. The figure provides a diagrammatic representation of the relationships
between the various types of healthcare agent.
A Healthcare Agent in Context is an explicit representation of a Healthcare Agent acting within a particular context.
This context is described as a relationship with other Healthcare Agents. For example, a secretary acting on behalf
of a clinician, a person working in a particular organisation or a department within a hospital.
The same Healthcare Agent can be the subject of several Healthcare Agent in Context and thus distinctions can be
drawn between activities of the Healthcare Person while serving in two different capacities.
The figure provides a diagrammatic representation of the relationships between the various types of healthcare
agent.
Healthcare Organisation
see 7.4.5
Healthcare Party
see 7.4.6
Healthcare Person
see 7.4.7
Healthcare Agent
Coding Scheme
Information Provider
see 7.4.2
see 7.3.2
Healthcare Agent in
Context
Coding Scheme
0.
Information Receiver
see 7.4.3
*
Healthcare Agent
see 7.3.3
Relationship
0.*
Coding Scheme
see 7.4.4
Originator
see 7.5.4
Figure 5  — Healthcare Agent subsystem and its associations
7.4.2 Healthcare Agent
Type: class
Information about a Healthcare Party (7.4.6) that performs a role in the updating of a coding
scheme.
NOTE The class Healthcare Agent contains only an identifier but its specialisations contain
other attributes enabling details about different types of Healthcare Agents to be
conveyed.
This is not an abstract class as it may exist without a specialisation. In this case the
identifier should refer to a Healthcare Agent about which all of the communicating
parties or systems already share a common set of information and which have agreed
to utilise this common identifier. Where such agreements are not available, details from
the specialisation should be made available in any communicative act.
Specialisations
A Healthcare Agent may be specialised as a Healthcare Party (7.4.6)
Associations
A Healthcare Agent may be the subject of any number of Healthcare Agent in Context
(7.4.3).
A Healthcare Agent may be the subject of any number of Healthcare Agent Relationship
(7.4.4).
Attributes:
1 to many
healthcare agent identifier Type: II (instance identifier)
An identifier referring to a Healthcare Agent.

7.4.3 Healthcare Agent in Context
Type: class
Information about one or more Healthcare Agents related together in a specified manner for the
purposes of performing a particular role in a healthcare activity.
NOTE A Healthcare Agent in Context represents a Healthcare Agent in the context of its
relationships with other Healthcare Agents.
Specialisations
A Healthcare Agent in Context may be specialised as a Coding Scheme Provider
(7.3.2), a Coding Scheme Information Receiver (7.3.3) or a Coding Scheme
Originator (7.5.4)
Associations
A Healthcare Agent in Context includes one Healthcare Agent (7.4.2).
A Healthcare Agent in Context may include any number of Healthcare Agent
Relationship (7.4.4).
Attributes:
healthcare agent in context identifier Type: II (instance identifier) 1
A single identifier referring to a Healthcare Agent
NOTE The identifier should be unique across communicating parties.
Healthcare Agent (7.4.2) class 1
Information about a healthcare person, healthcare organisation, that performs a role in a
healthcare activity.
healthcare agent function CV (coded value) 0 or 1
Information about the function being carried out by the Healthcare Agent.
Healthcare Agent Relationship class 0 to many
(7.4.4)
A relationship between the subject of this Healthcare Agent in Context and another Healthcare
Agent. Each Healthcare Agent Relationship specifies part of the context surrounding the
subject Healthcare Agent.
7.4.4 Healthcare Agent Relationship
Type: class
A relationship between two Healthcare Agents.
NOTE
A Healthcare Agent Relationship may apply for a specified period of time.
A healthcare agent relationship may be specific to a particular healthcare agent role.
EXAMPLES
Employee / employer
On behalf of / responsible for.
Associations
A Healthcare Agent Relationship is part of a Healthcare Agent in Context
A Healthcare Agent Relationship includes a Healthcare Agent.
Attributes:
Healthcare Agent (7.4.2) class 1
Information about a Healthcare Person or Healthcare Organisation that performs a role in the
supply and/or communication of the coding scheme.
healthcare agent relationship type 1
Type: CV (coded value)
The nature of the association between two healthcare agents.
EXAMPLES:   Employer of, responsible for, employee of, responsible to, sub-division of,
parent organisation of, etc.
7.4.5 Healthcare Organisation
Type: class
Specialisation of: Healthcare Party (7.4.6)
Information about an organisation involved in the direct or indirect provision of healthcare
services to an individual or to a population.
NOTE Groupings or subdivisions of an organisation, such as departments or sub-departments,
may also be considered as organisations where there is need to identify them.
Attributes:
Attributes of generalisation Healthcare Party (7.4.6)
name of healthcare organisation Type: ST (string) 0 or 1
type of organisation Type: CV (coded value) 0 or 1
EXAMPLES     University hospital, private clinic, laboratory service provider.

7.4.6 Healthcare Party
Type: class
Specialisation of: Healthcare Agent (7.4.2)
Information about an organisation or person responsible for the direct or indirect provision of
healthcare services, or involved in the provision of healthcare related services.
NOTE This may be a healthcare sub-department, department, organisation or person.
Specialisations
A Healthcare Party is specialised as a Healthcare Organisation (7.4.5) or a Healthcare
Person (7.4.7).
Attributes:
Attributes of generalisation Healthcare Agent (7.4.2)
address of healthcare party Type: address (7.7.1) 0 to many
An address expressed in a structured or unstructured form.
telecommunication of healthcare Type: telecommunication (7.7.8) 0 to many
party
Telephone, facsimile and other telecommunication numbers or electronic addresses in a
structured or unstructured form.
NOTE Email and web site addresses are specified using the unstructured telecommunication
number with the appropriate telecommunication type.

7.4.7 Healthcare Person
Type: class
Specialisation of: Healthcare Party (7.4.6)
Information about a person involved in the direct or indirect provision of healthcare services
to an individual or to a population.
EXAMPLES   Primary care physician, dentist, nurse, social worker, pharmacist, medical
secretary.
Attributes:
Attributes of generalisation Healthcare Party (7.4.6)
type of healthcare person Type: CV (coded value) 0 or 1
EXAMPLES   Medical doctor, nurse, pharmacist, diagnostic service worker.
name of healthcare person Type: person name details 0 or 1
(7.7.4)
position of healthcare person Type: CV (coded value) 0 or 1
EXAMPLES   Head of department, trainee GP, hospital consultant.
qualification of healthcare person Type: CV (coded value) 0 to many
NOTE This information is provided as supplied by the healthcare person or the
organisation within which they work and is not proof of qualification to undertake
healthcare services.
EXAMPLES   MD, M.Sc.
military rank of healthcare person Type: CV (coded value) 0 or 1
EXAMPLES   Captain, Major.
7.5 Coding Scheme Update subsystem
7.5.1 General Description
This subsystem operates as the starting point for the messages relating to the update of coding schemes. The
messages are sent from a provider of coding schemes or their agent to healthcare parties or their systems in a
wide range of healthcare organisation environments. This subsystem provides information about:
- the message itself;
- details which uniquely identify the coding scheme and its version that is being updated;
- the identification of the final version of the coding scheme that is produced by the update process;
- the originator of the
...