SIST EN 14822-1:2006
(Main)Health informatics - General purpose information components - Part 1: Overview
Health informatics - General purpose information components - Part 1: Overview
This European Standard specifies General Purpose Information Components to be used in standards for information exchange and information models supporting various health specific business requirements. The components defined in this standard are the most commonly needed basic building blocks for such standardization but these components may require further specialisation and be complemented by other objects required for specific purposes not met by these generally useful components. Such standardization using these general purpose information components could be performed both on a European (CEN) level or be done nationally or for specific user communities regionally as well as internationally.
This European Standard provides an informative overview of this series of standards and includes rules for using the components defined in the other parts and on conformance claims.
Medizinische Informatik - Allgemein verwendbare Informationskomponenten - Teil 1: Überblick
Informatique de la santé - Composants d'information d'usage général - Partie 1: Vue d'ensemble
La présente Norme européenne spécifie les composants d’information d’usage général (GPIC) a utiliser dans les normes relatives aux échanges d’information et aux modeles d’information qui répondent aux diverses exigences propres aux activités liées a la santé. Les composants définis dans la présente norme correspondent aux briques de base les plus nécessaires pour de telles normes mais ils peuvent nécessiter une adaptation particuliere et etre complétés par d’autres attributs requis a des fins spécifiques auxquelles les composants d’information d’usage général ne répondent pas. Une normalisation utilisant ces composants d’information d’usage général pourraient intervenir au niveau tant européen (CEN) que national et pour des groupes d’utilisateurs spécifiques au niveau régional ou international.
Le présent document donne une vue d’ensemble informative de cette série de normes et comporte des regles relatives a l’utilisation des unités définies dans les autres parties et employés dans les déclarations de conformité.
Zdravstvena informatika – Informacijske komponente za splošno uporabo – 1. del: Pregled
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
SIST EN 14822-1:2006
01-april-2006
Zdravstvena informatika – Informacijske komponente za splošno uporabo – 1. del:
Pregled
Health informatics - General purpose information components - Part 1: Overview
Medizinische Informatik - Allgemein verwendbare Informationskomponenten - Teil 1:
Überblick
Informatique de la santé - Composants d'information d'usage général - Partie 1: Vue
d'ensemble
Ta slovenski standard je istoveten z: EN 14822-1:2005
ICS:
35.240.80 Uporabniške rešitve IT v IT applications in health care
zdravstveni tehniki technology
SIST EN 14822-1:2006 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
SIST EN 14822-1:2006
---------------------- Page: 2 ----------------------
SIST EN 14822-1:2006
EUROPEAN STANDARD
EN 14822-1
NORME EUROPÉENNE
EUROPÄISCHE NORM
October 2005
ICS 35.240.80
English Version
Health informatics - General purpose information components -
Part 1: Overview
Informatique de santé - Unité d'information dans les Medizinische Informatik - Allgemein verwendbare
messages - Partie 1: Vue d'ensemble Informationskompomenten - Teil 1: Überblick
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-1:2005: E
worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
SIST EN 14822-1:2006
EN 14822-1:2005 (E)
Contents Page
Foreword .3
Introduction.4
1 Scope .5
2 Normative references .5
3 Terms and definitions.5
4 Symbols and abbreviations.5
5 General Purpose Information Components – their design .5
5.1 Basic design objectives .5
5.2 General Purpose Information Components and the Health Level Seven RIM.6
5.3 Health Level 7 (HL7) Reference Information Model.8
6 Common features of the general purpose information components.19
7 Use of general purpose information components in communication .21
8 Localisation of the general purpose information components .21
9 Overview of the content of EN 14822-2 and EN 14822-3 .22
9.1 EN 14822-2 GPICs: Non-Clinical .22
9.2 EN 14822-3 GPICs: Clinical .22
Annex A (informative) How to read the models.23
A.1 Introduction.23
A.2 Classes .23
A.3 Associations between classes.23
A.4 Generalisation/specialisation.24
Annex B (informative) HL7 RIM Class specialisations.25
B.1 Introduction.25
B.2 Entity class and its specialisations .25
B.3 Role class and its specialisations .26
B.4 Act class and its specialisations .27
Bibliography.28
2
---------------------- Page: 4 ----------------------
SIST EN 14822-1:2006
EN 14822-1:2005 (E)
Foreword
This European Standard (EN 14822-1:2005) has been prepared by Technical Committee CEN/TC 251
“Health informatics”, the secretariat of which is held by SIS.
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 one of a multipart standard under the heading:
Health informatics - General purpose information components
with the following parts:
Part 1: Overview
Part 2: Non-clinical
Part 3: Clinical
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.
3
---------------------- Page: 5 ----------------------
SIST EN 14822-1:2006
EN 14822-1:2005 (E)
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 communication 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
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 Modelling 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 similar 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 with the European expert team.
4
---------------------- Page: 6 ----------------------
SIST EN 14822-1:2006
EN 14822-1:2005 (E)
1 Scope
This European Standard specifies General Purpose Information Components to be used in standards for
information exchange and information models supporting various health specific business requirements. The
components defined in this standard are the most commonly needed basic building blocks for such
standardization but these components may require further specialisation and be complemented by other
objects required for specific purposes not met by these generally useful components. Such standardization
using these general purpose information components could be performed both on a European (CEN) level or
be done nationally or for specific user communities regionally as well as internationally.
This European Standard provides an informative overview of this series of standards and includes rules for
using the components defined in the other parts and on conformance claims.
2 Normative references
Not applicable.
3 Terms and definitions
For the purposes of this European Standard, the following terms and definitions apply.
3.1
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.2
Health Related Service
service provided to one or more persons or other living subjects aiming at improving the health status or
diminishing the probability of disease service provided to one or more persons or other living subjects aiming
at improving the health status or diminishing the probability of disease
4 Symbols and abbreviations
HL7 Health Level Seven Inc.
GPIC General Purpose Information Component
RIM Reference Information Model
UML Unified Modelling Language
5 General Purpose Information Components – their design
5.1 Basic design objectives
The healthcare information components which are presented in EN 14822-1 and EN 14822-2 and have been
selected to meet major requirements from existing European message standards and some projected
requirements for other types of information exchange.
5
---------------------- Page: 7 ----------------------
SIST EN 14822-1:2006
EN 14822-1:2005 (E)
It is noteworthy that this document may be useful in the design of interacting components in a local
application as well as for remote communication across organisational boundaries. The information
components defined in this series can support database design, interacting objects using SOAP (Simple
Object Access Protocol), COM (Common Object Model) or CORBA (Common Object Request Broker
Architecture) as well as traditional store and forward messaging systems.
5.2 General Purpose Information Components and the Health Level Seven RIM
A General Purpose Information Component (GPIC) is a specification of a component of an information
system or of a communication between such systems and we may use a number of these components in
order to build a larger systems or communications.
In particular, the GPICs which are the subject of this multipart standard are generated so as to provide a set
of generic templates for commonly encountered concepts that are found in healthcare information systems
and in the communication between such systems.
Given that GPICs are a set of components that may be used in combination to describe a larger whole, there
is a need to have consistency in the internal design principles of the GPICs and also in the external
interfaces which allow components to be combined in a consistent manner. If such principles are rigorously
adhered to it becomes easier to provide tools to support the development of messaging and other
communication systems.
Achieving the necessary degree of consistency in the internal design and external interfacing of the GPICs
has been facilitated by the use of the Health Level Seven (HL7) Reference Information Model (RIM). It shall
be understood that this RIM is NOT a model of healthcare nor of healthcare records; rather it is a high level
model of healthcare information elements and the relationships between these elements. The RIM therefore
provides us with an abstract model from which those elements that we need in order to design the relevant
GPICs can be selected. In effect the RIM provides the basic building blocks from which we construct larger
building blocks: the GPICs (see Figure 1).
6
---------------------- Page: 8 ----------------------
SIST EN 14822-1:2006
EN 14822-1:2005 (E)
Health Level 7 Reference Information Model
GPIC B
GPIC A
General Purpose
Information Components
GPIC C
GPIC D
Figure 1 — HL7 reference information model and GPIC design
Figure 1 illustrates that RIM classes are being used to construct a number of different GPICs which may be
further combined, either with additional RIM classes or other GPICs to make larger, more complex GPICs.
An example may be used to illustrate the basics of the process. The RIM contains a concept of person
which could be used in GPICs which describe patients, doctors, nurses, next of kin, animal owners etc. A
GPIC design will use those attributes of the Person class which are appropriate to the function of the
particular GPIC and then combine this with another RIM concept of Role to produce a tailored description of
the person/role that describes the person playing the role of patient, nurse etc.
The RIM provides the generic classes such as Act, Entity and Person (see next subclause) together with a
set of generic attributes with their data types and rules concerning the number and type of relationships with
other RIM classes. The GPIC takes from the RIM those classes, attributes and class associations that are
required and imposes constraints by defining:
7
---------------------- Page: 9 ----------------------
SIST EN 14822-1:2006
EN 14822-1:2005 (E)
the precise purpose of the combination of RIM classes, i.e. what is the scope of the GPIC;
the sub-set of attributes which are being used in each class. For example, the use of the Person
attribute ‘deceased_time’ may be appropriate to the concept of Patient but not to the concept of
Healthcare Professional;
the exact purpose of each attribute. For example in different GPICs, the use of the attribute ‘code’
derived from the Entity class may be used to provide a coded description of a very wide range of ‘things’
such as the type of medicinal product pack or the kind of care setting or the type of device etc.;
limitations upon data types associated with each attribute. For example, although most of the RIM
attributes are associated with precise data types there are many attributes where a wide range of data
types are allowed. This is especially prevalent in describing time where there may be requirements for a
date/time, a date/time range, a period of time, and so on. In designing a GPIC the use of each attribute
is more focussed. This permits the imposition of constraints upon the data types and also of the
underlying vocabulary sets associated with coded attributes.
5.3 Health Level 7 (HL7) Reference Information Model
5.3.1 Introduction
The General Purpose Information Components described within this multi-part standard conform to HL7’s
Reference Information Model Version 3 Version 2.01 (successfully balloted July 2003). This subclause
describes those aspects of the Reference Information Model that is relevant to the design of the General
Purpose Information Components.
The HL7 RIM consists of a large number of classes and relationships. Four of these classes are, however,
of prime importance and form the ‘backbone’ of the RIM. These classes are Entity, Role, Participation and
Act. These four classes (plus the ‘relationship classes) are shown in Figure 2 below.
The backbone may be read left to right as: an Entity (e.g. person) plays a Role (e.g. patient) and participates
in some Act (e.g. consultation). The backbone can be read from right to left as: an Act (e.g. appendectomy)
has the participation, of Entity (person) who is in the Role of nurse.
8
---------------------- Page: 10 ----------------------
SIST EN 14822-1:2006
EN 14822-1:2005 (E)
Act
Entity Role Participation
Act
Role
Relationship
Link
Figure 2 — HL7 Reference information backbone
5.3.2 Entities
General description
Entities represent physical things such as persons, animals, organisations, medicinal products, devices,
places, samples etc. A simplified model of Entity and its more important specialisations are shown in
Figure 3 below.
Within these standards Entities are indicated by the colour green.
Entities may only be associated with classes of type Role, i.e. Entities cannot be directly associated with
1
each other , only through Role classes.
An entity may be associated with any number of instances of Role classes.
NOTE A fuller representation of the HL7 Entity Classes is provided in Annex B. Further note that this material is
owned by HL7 Inc. and subject to their terms and conditions.
1
Although Entity may me associated with Language Communication which is also coloured green in these standards.
9
---------------------- Page: 11 ----------------------
SIST EN 14822-1:2006
EN 14822-1:2005 (E)
plays
0.*
Entity Role
Person Non-person
Organisation Device Material
living subject
Figure 3 — Entity specialisations
Description of specialisations
Here some information about some of the more important attributes is included, especially those where their
function is less obvious.
Entity: this core class includes:
classCode: a means of defining which specialisation of Entity is being used. In this, Entity itself may be
the specialisation (i.e. no specialisation). The classCode shall always be present. The values which
classCode may adopt are presented in 10.1.1 of EN 14822-2:2005.
determinerCode: provides a means of specifying whether the instance of Entity (or its specialisation) is
describing an actual instance of something, e.g. an actual pack of medicine that has been issued to a
patient, a ‘kind’ of thing, e.g. the type of pack of medicine that is being ordered for a patient, or a
quantified_kind, for example a three packs of medicine. Allowed values are:
INST = Instance of;
KIND = Kind of;
QUANTIFIED_KIND.
code: is the main classifying attribute of the Entity class and all of its specialisations. This code
indicates what kind of Entity is being referred to by using a code from one of several coding systems
depending on the class of entities, such as living subjects (typed by animal and plant taxonomies),
chemical substance (e.g. IUPAC(International Union of Pure and Applied Chemistry) code),
organizations, place, device etc.
desc: provides a description of an entity or is specialisations using free text or multimedia data.
id: provides a unique identifier for an entity. Ideally each entity will have only one identifier assigned to it,
however, since different systems will maintain different data bases, there may be different instance
identifiers assigned by different systems.
name: provides a name of the entity, for example, person name, animal name, organisation name,
device name etc.
quantity: specifies the quantity of the given entity. In this context the quantity is an extensive "amount"
type of quantity (e.g., number, length, volume, mass, surface area, energy etc.).
10
---------------------- Page: 12 ----------------------
SIST EN 14822-1:2006
EN 14822-1:2005 (E)
handlingCode: a code or set of codes to describe how the entity needs to be handled to avoid damage
to it or other entities. Examples include: keep at room temperature; keep frozen below 0 °C; keep in a
dry environment; keep upright, do not turn upside down.
riskCode: a code or set of codes indicating the existence of a risk or hazard associated with the Entity.
Person: inherits the Entity attributes plus ‘Person’ type attributes which include the usual person
demographics such as date of birth/death, gender, address(es), religious affiliation, marital status, ethnic
group etc. Note that the fact that the person is a patient or a doctor, or an employee etc. is reflected in the
Role that they are playing and their patient number, doctor id, or employee number, and other such details
are to be found in the particular Role specialisation.
Non-person living subject: is limited in this standard to animals. Inherits the Entity attributes plus ‘Animal’
type attributes which include taxonomic classification, breed, date of birth/death, gender and gender status.
Organisation: inherits the Entity attributes plus ‘Organisation’ type attributes which are organisation type
and address(es).
Place: describes a physical place or site with its contained structures, if any. Place may be natural or man-
made. The geographic position of a place may or may not be constant. Examples include a field, lake, city,
county, state, country, building, pipeline, power line, playground, ship, truck. Places may be work facilities
(where relevant acts occur), homes (where people live) or offices (where people work). Places may contain
sub-places (floor, room, booth, bed). Places may also be sites that are investigated in the context of health
care, social work, public health administration (e.g., buildings, picnic grounds, day care centres, and prisons).
Place inherits the Entity attributes plus ‘Location’ type attributes which include textual, coded and identifier
links to the location being described.
Device: a device is anything used in an activity without being substantially changed through that activity.
This includes durable (reusable) medical equipment as well as disposable equipment.
Device inherits the Entity attributes plus ‘Device’ specific attributes which describe, for example, the last
calibration date, the software incorporated and the manufacture’s name for the model.
Material: examples of Material are pharmaceutical substances (including active vaccines containing
retarded virus), disposable supplies, durable equipment, implantable devices, food items (including meat or
plant products), waste, traded goods etc.
Material inherits the Entity attributes plus ‘Material’ specific attributes which describe, for example, the form
of the material (e.g. tablet), its expiration date, lot number and stability time.
5.3.3 Roles
General description
Role defines the competency of an Entity in a particular Role to participate in any particular Act.
Thus, a person in the role of practitioner can participate in a patient emergency encounter as the attending
physician or as one who assesses the patient’s lung function. The Role defines the competency of the Entity
irrespective of any Act, as opposed to Participation which is limited to the scope of an Act.
A simplified model of Role and its more important specialisations are shown in Figure 5 below.
Within these standards, Roles are indicated by the colour yellow.
A Role shall be associated with at least one Entity:
11
---------------------- Page: 13 ----------------------
SIST EN 14822-1:2006
EN 14822-1:2005 (E)
An Entity may play a role that is ‘scoped’ by another Entity. For example, a person may have a position of
‘Trainee Nurse’ with respect to a particular hospital. This is shown below in Figure 4.
Person (nurse)
plays role
Employee
(Trainee Nurse)
Employer (hos pital)
scoped by
Figure 4 — A scoped role
Two Roles may be associated using an instance of Role Link. A Role may be linked to several other Roles
in this way. For example, one may wish to denote that Dr. X who has the role of junior doctor, is supervised
by Dr. Y who as the role of hospital consultant.
An Entity in a Role may be associated with zero, one or many Acts through associated Participations.
Figure 5 — Role specialisations
NOTE A fuller representation of the HL7 RoleClasses is provided in Annex B. Further note that this material is
owned by HL7 Inc. and subject to their terms and conditions.
Description of specialisations
Here some information about some of the more important attributes of Role and some of its specialisations
are included.
Role: this core class includes:
classCode: provides a means of defining the broad category of Role the entity is playing. EN 14822-2
contains a list of codes.
code: describes the role being played by the entity using a code value.
effectiveTime: describes the time or time interval during which the Entity played this Role.
quantity: used with composition-relationships (e.g. has-parts, has-ingredient, has-content) and specifies
that a numerator amount of the target entity is comprised by a denominator amount of the source entity
12
---------------------- Page: 14 ----------------------
SIST EN 14822-1:2006
EN 14822-1:2005 (E)
of such composition-relationship. For example an Estracombi combination pack contains 4 Estraderm
patches and 4 Estragest patches.
id: provides an identifier for the entity when playing that particular role. For example: patient hospital
number, doctor id.
addr: address that is appropriate to the entity in this Role. For example: address for consulting
physician.
telecom: telecommunication numbers and addresses associated with the entity in this Role. For
example, Physician’s office number.
Employee: inherits the Role attributes to which are added ‘Employee’ type attributes. In particular, this
specialisation is used to describe persons who are employed as healthcare professionals. This
specialisation includes attributes that can describe the healthcare professional’s position and their healthcare
specialty.
Patient: inherits the Role attributes plus ‘patient’ type attributes which include any particular confidentiality
constraints placed upon their healthcare information, e.g. member of staff.
Access: inherits the Role attributes plus attributes associated with the routing of treatment, (especially
medication) to a particular anatomical site. These attribute are limited to:
guageQuantity: the gauge of an access as a measure of the inner diameter of an access tube;
approachSiteCode: a code representing the anatomic site where the line or drain first enters the body.
For example in an arteria pulmonalis catheter targets a pulmonary artery but the access approach site is
typically the vena carotis interna at the neck, or the vena subclavia at the fossa subclavia;
targetSiteCode: a code representing the target site of the access, i.e., the compartment into which
material is administered or from which it is collected. For example, a pulmonary artery catheter will have
the target site arteria pulmonalis with or without a known laterality. For environmental testing this could
be the incubation chamber or the cooling tower or the overflow reservoir etc.
Resource: Inherits the Role attributes plus an extra attribute concerned with the size of the time slot
allocated to the use of the resource. For example: Thursday’s well men clinic.
5.3.4 Participations
General description
Participations represent the part played be the entity in some activity. For example, the person in the role of
nurse may administer medication to the patient, and may be responsible during recovery from anaesthesia.
Within these standards, Participations are indicated by the colour blue.
Participations are always associated with a single Act class but this could be external to the GPIC.
has as participant
1
Role
Participation Act
1 in
Participations are always associated with a single Role class but this could be external to the GPIC.
Figure 6 — Participation associations
13
---------------------- Page: 15 ----------------------
SIST EN 14822-1:2
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.