EN 14822-2:2005

SLOVENSKI STANDARD
01-april-2006
=GUDYVWYHQDLQIRUPDWLND±,QIRUPDFLMVNHNRPSRQHQWH]DVSORãQRXSRUDER±GHO
1HNOLQLþQLSRGDWNL
Health informatics - General purpose information components - Part 2: Non-clinical
Medizinische Informatik - Allgemein verwendbare Informationskomponenten - Teil 2:
Nicht klinische Informationen
Informatique de santé - Unité d'information dans les messages - Partie 2: Non-clinique
Ta slovenski standard je istoveten z: EN 14822-2: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 14822-2
NORME EUROPÉENNE
EUROPÄISCHE NORM
October 2005
ICS 35.240.80
English Version
Health informatics - General purpose information components -
Part 2: Non-clinical
Informatique de santé - Unité d'information dans les Medizinische Informatik - Allgemein verwendbare
messages - Partie 2: Non-clinique Informationskompomenten - Teil 2: Nichtklinische
Informationen
This European Standard was approved by CEN on 16 August 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 14822-2:2005: E
worldwide for CEN national Members.

Contents Page
Foreword .5
Introduction.6
1 Scope .7
2 Normative references .7
3 Terms and definitions.7
4 Symbols and abbreviations.8
5 Rules governing the use of general purpose information components .9
6 Common Attribute Groups (CAG).11
6.1 Introduction.11
6.2 Entity Name CAG .11
6.2.1 Entity Name .11
6.2.2 Entity Name Part .12
6.3 Postal Address CAG.13
6.3.1 Postal Address.13
6.3.2 Postal Address Part.14
6.4 Telecom CAG .14
6.4.1 Telecom .14
7 Common Sub-Components.15
7.1 General description .15
7.1.1 Overview.15
7.1.2 Context inheritance.16
7.2 Non Healthcare Person Participation .16
7.3 Healthcare Professional Participation.19

7.4 Healthcare Organisation Participation .21
7.5 Device Participation.23
7.6 Healthcare Agent Participation .24
8 General Purpose Information Components – an overview.26
9 General Purpose Information Components .34
9.1 Living Subject GPICs.34
9.1.1 Overview (informative) .34
9.1.2 Person.35
9.1.3 Language Communication .37
9.1.4 Place of Birth.39
9.1.5 Residence Information .41
9.2 Organisation Related GPICs .43
9.2.1 Overview (informative) .43
9.2.2 Organisation.43
9.2.3 Identified Organisation .46
9.2.4 Organisation Hierarchy .47
9.2.5 Related Organisation .49
9.2.6 Contact Person .50
9.3 Subject of Care Identification GPICs.52
9.3.1 Overview (informative) .52
9.3.2 Subject Of Care Identification .52
9.3.3 Identified Living Subject.54
9.3.4 Subject Of Care Person Identification .56
9.3.5 Subject Of Care Animal Identification .58
9.4 Subject of Care GPICs.59
9.4.1 Overview (informative) .59
9.4.2 Subject Of Care .60
9.4.3 Subject Of Care Person .63
9.4.4 Patient Standard Information.66
9.4.5 Patient Extended Information .69
9.4.6 Subject Of Care Animal .72
9.4.7 Subject Of Care Animal Group.75
9.5 Subject of Care Related GPICs .76
9.5.1 Overview (informative) .76
9.5.2 Related Subject Of Care .77
9.5.3 Subject Of Care Related Party .81
9.6 Subject of Care And Related Parties Involvement in Activities GPICs.83
9.6.1 Overview (informative) .83
9.6.2 Referenced Subject of Care .84
9.6.3 Participating Subject of Care .86
9.6.4 Participating Patient .88
9.6.5 Identified Participating Patient.89
9.6.6 Participating Patient Related Party.91
9.6.7 Participating Related Subject of Care .93
9.6.8 Care Service Recipient .94
9.6.9 Subject Of Investigation .97
9.7 Healthcare Agent GPICs - General principles.101
9.8 Healthcare Professional GPICs.101
9.8.1 Healthcare Professional .101
9.8.2 Identified Healthcare Professional .105
9.8.3 Related Healthcare Professional .107
9.9 Healthcare Organisation GPICs.109
9.9.1 Healthcare Organisation.109
9.9.2 Identified Healthcare Organisation.111
9.9.3 Related Healthcare Organisation.113
9.10 Healthcare Agent GPICs.115
9.10.1 Healthcare Party.115
9.10.2 Identified Healthcare Party.116
9.10.3 Healthcare Agent .118
9.10.4 Identified Healthcare Agent.120
9.10.5 Related Healthcare Agent.122
9.11 Referenced Healthcare Agent GPICs.124
9.11.1 Referenced Healthcare Professional.124

9.11.2 Referenced Healthcare Organisation .125
9.11.3 Referenced Healthcare Device.127
9.11.4 Referenced Healthcare Party .128
9.11.5 Referenced Healthcare Agent .130
9.12 Healthcare Agent Involvement in Activity GPICs .131
9.12.1 Participating Healthcare Professional.131
9.12.2 Identified Participating Professional .133
9.12.3 Participating Healthcare Organisation .134
9.12.4 Identified Participating Organisation.135
9.13 Participating Healthcare Agent GPICs .136
9.13.1 Participating Healthcare Party .136
9.13.2 Participating Healthcare Agent .138
9.14 Device GPICs.139
9.14.1 Device .139
9.14.2 Identified Device .141
9.14.3 Related Device .143
9.14.4 Related Identified Device.144
9.14.5 Device In Use.146
9.14.6 Identified Device In Use.147
9.14.7 Device Parameter.148
9.15 Location GPICs .150
9.15.1 Care Location .150
9.15.2 Care Location In Use .152
9.15.3 Geographic Location .154
9.16 Transportation GPICs .156
9.16.1 Living Subject Transportation .156
9.16.2 Non Living Entity Transportation.161
9.16.3 Related Living Subject Transportation.164
9.16.4 Related Non Living Entity Transportation.165
9.17 Financial GPICs.166
9.17.1 Care Cost.166
9.17.2 Authorisation.169
9.17.3 Service Agreement.171
10 Structural Vocabularies.175
10.1 Entity Vocabularies.175
10.1.1 Entity Class .175
10.1.2 Entity Determiner .176
10.2 Role Vocabularies.176
10.2.1 Role Class.176
10.3 Participation Vocabularies .181
10.3.1 Participation Type.181
10.3.2 Participation Status .185
10.3.3 Participation Mode.185
10.4 Context Control Participation .186
Annex A (informative) Rationale for this document on General Purpose Information Components.188
Annex B (informative) How to read the models.189
B.1 Introduction.189
B.2 Associations between classes.189
B.3 Generalisation/Specialisation .190
Annex C (informative) Health Level 7 (HL7) Reference Information Model.191
Annex D (informative) Common features of the general purpose information components.193
Annex E (informative) Localisation of the general purpose information components .195
Bibliography.196

Foreword
This European Standard (EN 14822-2:2005) has been prepared by Technical Committee CEN/TC 251 “Health
informatics”, the secretariat of which is held by NEN.
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 April 2006, and conflicting national standards shall be withdrawn at the
latest by April 2006.
This is part two of a multipart standard under the heading:
Health informatics - General purpose information components:
 Part 1: Overview
 Part 2: Non-clinical
 Part 3: Clinical
This European Standard is definition of a set of non-clinical general purpose information components.
IMPORTANT —Within this document each of the General Purpose Information Components and
various sub-components are provided with identifiers, which are unique only internally within this
document.
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
Many previous messaging and information structure standards for health have overlapping parts with a
number of objects being defined in separate documents, sometimes with small variations making
implementation of conformant applications more difficult. It therefore makes sense to define a set of general
purpose components that can be used for definition of message structures for different purposes . This
approach was suggested and approved as a strategy for CEN/TC 251 in the Short Strategic Study on
message standards alignment in 1999 examining a set of five European prestandards for messages. This
European Standard is aiming to provide such a set of components and has been developed jointly with a new
European Standard for Service Request and Report messages that is using the components defined herein.
Another important background to the development of this European Standard has been the wish for a
harmonisation of information models for health developed in Europe and the USA expressed in the
collaboration agreement entered March 2000 between CEN/TC 251 and HL7 (Health Level Seven, Ann Arbor.
Michigan). The goal was set for a maximum degree of alignment while maintaining their independence and
need to serve the business requirements of the respective markets but also to make the results available to
ISO for possible international standardization.
HL7 have adapted a general strategy similar to CEN/TC 251 using information modelling expressed in UML
(Unified Modeling Language) for their new standards and a lot of interaction and information sharing has
occurred between CEN experts and HL7 in an open spirit of collaboration.
This European Standard includes a large number of objects which are technically identical to descriptions in
draft documents of HL7, although partly described differently due to the fact that CEN is following the ISO
rules for drafting and presentation of standards which HL7 is not. CEN wishes to express its gratitude towards
HL7 experts for generously sharing their models and other technical outputs with the European expert team.
This European Standard contains definition of a set of non-clinical General Purpose Information Components.

See Annex A: Rationale for this document on General Purpose Information Components.
1 Scope
This European Standard specifies the definition and structuring of information relating to entities that are
commonly encountered in communications with and between clinical information computer systems.
Within the scope of this European Standard is a description of components and their use. In particular, these
components relate to the following sub-domains:
 Subjects of care: including persons, animals and groups of animals. This sub-domain includes
descriptions of the parameters for the identification of the subjects of care.
 Subject of care related parties: including next of kin and other persons and organisations related to the
subject of care (including other subjects of care).
 Healthcare agents: including healthcare professionals, organisations and devices.
 Devices: including descriptions of their settings and use within a particular use event.
 Locations: of two types:
 care locations, for example, ward and bed where patient receive inpatient care, a clinic where
physiotherapy booked, a nursing home, the patient’s home etc.;
 geographic locations: which are non-healthcare specific places that are related to laboratory
investigations. For example: kitchens, shop counters, hotel air conditioning systems.
 Transport: including the transportation of persons (patient, related person), animals, or samples/body
parts.
Financial: including costs associated with care services, authorisation and service agreements (contracts).
2 Normative references
Not applicable.
3 Terms and definitions
For the purposes of this European Standard, the following terms and definitions apply.
3.1
care location
place, often located within a healthcare organisation, where healthcare services are provided
EXAMPLES Ward, room, bed, GP surgery, clinic, patient’s home, residential home.
3.2
General Purpose Information Component
GPIC
commonly useful information component that is a specialisation of classes in an international reference
information model which is intended to be used in the specification of an information service for health or of a
communication between health information systems.
3.3
healthcare
provision of health related services
[ENV 13940:2001 - modified]
NOTE 1 This includes more than performing procedures on subjects of care. It includes also, for example, the
management of the information about patients, their health status and their relations within the health care framework.
NOTE 2 In this document, the term 'care' may be used as a synonym for 'health care'.
3.4
healthcare agent
healthcare person, healthcare organisation, healthcare device or that performs a role in a healthcare activity
[ENV 13940:2001]
3.5
healthcare device
device or equipment involved in the direct or indirect provision of healthcare services to an individual or to a
population
[ENV 13606-4:2000]
EXAMPLES ECG machine, auto-analyser, syringe pump.
3.6
healthcare organisation
organisation involved in the direct or indirect provision of healthcare services
3.7
healthcare party
organisation or person involved in the direct or indirect provision of healthcare services to an individual or to a
population
[ENV 13606-4:2000]
3.8
healthcare professional
person involved in the direct or indirect provision of healthcare services to an individual or to a population
[ENV 13606-4:2000 - revised]
3.9
organisation
unique framework of authority within which a person or persons act, or are designated to act towards some
purpose
NOTE Groupings or subdivisions of an organisation may also be considered as organisations where there is need to
identify them for information interchange. (see ISO/IEC 6523:1998)
3.10
subject of care
person or other living subject, or group of persons or other living subjects, scheduled to receive or receiving
healthcare services
3.11
transportation
movement of a person, animal, group of animals or analysable object between two physical locations
4 Symbols and abbreviations
NOTE All those marked by ‡ as defined in the CEN/TS 14796:2003, “Health informatics - Data types”.
BL  ‡ Boolean
CAG Common Attribute Group (see Section 6)
CD  ‡   Concept Descriptor
CS  ‡ Coded Simple value
CV  ‡ Coded Value
ED  ‡ Encapsulated Data
GP General Practitioner
GPIC General Purpose Information Component
II   ‡ Instance Identifier
IVL ‡ Interval
IVL ‡ Interval of Physical Quantity
IVL ‡ Interval of Time
INT ‡ Integer
PQ  ‡ Physical Quantity
ST  ‡ String
TS  ‡ Time stamp (point in time)
UML Unified Modeling Language
5 Rules governing the use of general purpose information components
5.1
When using a GPIC, a system which conforms to this document shall implement the features (classes,
2 3
associations, attributes) that are described within the GPIC core . In particular:
 A conformant system that utilises a GPIC shall be able to receive and process information present in all
classes and attributes, even where attributes are specified as being optional.
 A conformant system that utilises a GPIC design to send information shall not be obliged to populate
optional attributes.
5.2
Each of the classes and embedded GPICs that constitute a GPIC description has a class type. These are
,
4 5
shown as follows :
See EN 14822-1 for explanation of ‘GPIC Core’.
See Annex B: How to read the models.
See Annex C: Health Level 7 (HL7) Reference Information Model.
Within this document the exception is that the class ‘Language Communication’ does not have any specific type.
A
Act These describe actions, plans, etc.
EXAMPLES Observations, tests, referrals, transportation
etc.
P
Participation
Used as a way of linking Acts to Entities. May include
information about the type of participation of the Entity.

R
Role Used as a way of linking Entities together and provides
information about the competences or qualification of the

entities, for example, a person who is qualified to act as a
nurse.
RL
RoleLink Used as a way of linking two Entity/Role pairs together, for
example person/employee ↔ organisation/employer.

E
Entity The world of physical things. May be people, animals,
samples, organisations, places, materials, devices etc.

None of Above A class that is none of the above types. Limited to the
Language Communication class in this document.

5.3
A GPIC description shall not include optional associations between classes within the GPIC core.
5.4
For each GPIC there is a definition of the type(s) of objects to which the GPIC may be attached within any
external models or implementations. A conformant system will restrict GPIC use accordingly .
5.5
GPICs may be associated with other GPICs in ways which extend their functionality. These extensions are
informative in nature and shall not be subject to conformance testing. The set of extensions to the GPICs
shown in this document shall not be considered to be exhaustive.
5.6
A user community, e.g. a national body or a message development agency, may wish to ‘localise’ a GPIC for
use in a particular circumstance. The rules which underpin such localisation are :

See Annex D: Common features of the General Purpose Information Components.
See Annex E: Localisation of the general purpose information components.
 All mandatory attributes shall be present in any design using the GPIC, i.e. it is not permitted to omit
these features.
 A user community may:
 specify that certain optional attributes are omitted;
 restrict (constrain) a data type: For example, the data type ST (string) being defined in place of ED
(multimedia data);
 define constraints on the allowable values of an attribute;
 define constraints on the vocabulary sets that may be associated with a coded attribute.
It is strongly recommended that where any of these actions are taken, that the user community provide the
resulting GPIC with a new Object Identifier (i.e. register a new GPIC):
 A user community shall not:
 omit mandatory attributes and associations but may restrict values and vocabulary sets as outlined
above;
 add attributes;
 add associations except to other GPICs as external extensions.
Users may create new GPICs.
6 Common Attribute Groups (CAG)
6.1 Introduction
This clause provides groups of attributes that are commonly encountered in demographic data. It is
convenient to define these once and then to refer to them as though they were complex data types.
6.2 Entity Name CAG
6.2.1 Entity Name
Common Attribute Group
EntityName
Description Specifies a name of a person, organisation, place or thing.
Examples "Leonardo da Vinci", "United Nations Organisation", "Eiffel Tower", etc.
Comments An entity name may be as simple as a character string or may consist of several
entity name parts.  The entity name data type is essentially a sequence of entity
name part values.
Attributes O Type Description
entityName M SET NamePart>
EXAMPLES
 Eiffel Tower (place name)
 Anderson (family name)
 John (given name)
use O CV Code representing the purpose/primary use of
the name
validTime O IVL Interval of time associated with the entity
name.
NOTE The valid time may provide a:
start date/time, or
an end date/time, or
both.
6.2.2 Entity Name Part
Common Attribute Group
EntityNamePart
Description Specifies a name of a person, organisation, place or thing.
Examples "United Nations Organisation", "Thomas”
Attributes O Type Description
entityNamePart M ST The name part represented as a string.
namePartType O CS VALUES:
 FAM = family
 GIV = given
 PFX = prefix
 SFX = suffix
namePartQualifier O CS VALUES:
 AC = academic
 NB = nobility
 PR = professional
 W = prefix (voorvoegsel)
 BR = birth
 CL = preferred name
 IN = initial
6.3 Postal Address CAG
6.3.1 Postal Address
Common Attribute Group
PostalAddress
Description Used to represent the mailing, home or business address.
Comments Addresses are essentially sequences of address parts.
Attributes O Type Description
postalAddress M SET ssPart>
postalCode O ST The postal or zip code.
addressUse O SET One or more codes advising a system or user
which address in a set of like addresses to
select for a given purpose.
VALUES:
 BIR (birthplace)
 H (home)
 HP (primary home)
 HV (vacation address)
 WP (work place)
validTime O IVL Interval of time associated with the address.
NOTE  The valid time may provide a:
start date/time, or
an end date/time, or
both.
6.3.2 Postal Address Part
Common Attribute Group
PostalAddressPart
Description An address line.
Comments Addresses are conceptualised as text with added mark-up. The mark-up may
break the address into lines and may describe in detail the role of each address
part if it is known.
Attributes O Type Description
addressLine M ST The address part represented as a string.
addressLineType O CS VALUES:
 BNM = boat name
 CNT = country
 CPA = county or parish
 CTY = city/town
 FNM = flat number
 HNR = house number
 HNM = house name
 POB = post box
 SAL = street address line
 STA = state or province
 STR = street name
6.4 Telecom CAG
6.4.1 Telecom
Common Attribute Group
Telecom
Description Locator for some resource (information or services) mediated by
telecommunication equipment.
Comments The responder of a telecom address may be an automatic service that can
respond with information (e.g. FTP or HTTP services). In such case a telecom
address is a reference to that information accessible through that address.
A given telecom address value may have limited validity through time and may
be tagged by a use code to indicate under what circumstances a specific
telecommunication address may be preferred among a set of alternatives.
The telecommunication address is an extension of the Universal Resource
Locator (URL) that specifies as an Internet standard RFC 1738.
Attributes O Type Description
telecomAddress M URL The address is a character string whose
format is entirely defined by the URL scheme.
use O SET VALUES:
 HT = home telephone
 WT = work telephone
 AS = answering service
 EC = emergency contact
 MC = mobile contact
 PG = pager
 FX = fax
 EM = email
validTime O SET{IVL  One or more time range when this
< TS>} telecommunication type is appropriate (e.g.
after 18:00).
7 Common Sub-Components
7.1 General description
7.1.1 Overview
This clause presents a set of classes which describe the ‘Participation’ that a person, organisation or device
may have in healthcare activities. These sub-components differ from GPICs inasmuch as they do not
describe Entities (mainly found in this document), or Acts (mainly found in EN 14822-3), but provide a
‘template’ that may be used to describe the type of participation that one or more Entities have within some
activities. This means that unlike the GPICs presented in Clause 8, there is no description of the external
connection types since these shall always be Role + Act (or specialisations of), i.e.

Person, Organisation or
Act
Device
Entity
participates in in this activity
playing a
the following
role
way
Participation Sub-Component
Role
Role
scoped
0.1
Person, Organisation or
Device
Figure 1 — How Participation Sub-Components are to be used
7.1.2 Context inheritance
When describing some healthcare activities it is often necessary to utilise many instances of Act that are
associated together using Act Relationships. For example, the act of examining a patient may involve a
number of sub-activities such as taking measurements, making observations, asking questions, recording
results, etc. In such cases it is usual for the group of acts to have the same participant(s). However, in a
communication it would be wasteful to specifically state the participant(s) for each of these acts.
It is possible in the examination process that the physician captures the fact that the patient’s mother had a
history of diabetes. It is then necessary to correctly specify that this particular item of clinical information
(expressed as an Observation Act) relates to a family member (different participant), not directly to the patient,
while at the same time the other participations to this group of acts (examining physician, data recorder, etc.)
remain unaltered.
In order to facilitate the extent of the participation of any given actors (persons, organisations, places, etc.)
attributes are used in the Participation and Act Relationship classes. Within this document there are no
GPICs defined which utilise Act Relationship classes, but many which utilise Participation classes. There are
four values permitted within a participation class in order to define the extent of the context of the participating
GPIC. These values and their explanations are provided in 10.4.
7.2 Non Healthcare Person Participation
Sub-component Name
P
NonHealthcarePersonParticipation GPIC_ID =  2.001
Description Information about the participation of a human subject of care or a related non-
healthcare person in one or more aspects of healthcare service provision.
HL7 RIM Participation
Class
External This component shall be associated explicitely or implicitely with:
Connection
an Entity/Role combination which identifies and/or describes the person that is
Types
participating. Details of the role played by the person may be provided by the
context of another healthcare party such as an organisation. For example, the job
title and identification of a contact person may be those used in the context of a
particular employer organisation.
an Act which identifies and/or describes the activity that this person is participating in.
Note The activity may be in the past, present or future: it may be an actual activity, a
planned or recommended activity, etc.
UML Representation
NonHealthcarePerson
Participation
typeCode: CS
contextControlCode: CS
functionCode: CV
awarenessCode: CV
Attributes O Type Description
typeCode M CS Identifies the broad category of person that is
participating.
A value shall be chosen from those present in
10.3.1.
The following sub-set of the vocabulary entries
may be of particular importance in this sub-
component:
 PAT (patient)
 NOK (patient’s next of kin)
 CN
...