EN ISO 13606-1:2012

SLOVENSKI STANDARD
01-december-2012
1DGRPHãþD
SIST EN 13606-1:2008
=GUDYVWYHQDLQIRUPDWLND.RPXQLNDFLMD]HOHNWURQVNLPL]DSLVLQDSRGURþMX
]GUDYVWYDGHO5HIHUHQþQLPRGHO,62
Health informatics - Electronic health record communication - Part 1: Reference model
(ISO 13606-1:2008)
Medizinische Informatik - Kommunikation von Patientendaten in elektronischer Form -
Teil 1: Referenzmodell (ISO 13606-1:2008)
Informatique de santé - Communication du dossier de santé informatisé - Partie 1:
Modèle de référence (ISO 13606-1:2008)
Ta slovenski standard je istoveten z: EN ISO 13606-1:2012
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 ISO 13606-1
NORME EUROPÉENNE
EUROPÄISCHE NORM
October 2012
ICS 35.240.80 Supersedes EN 13606-1:2007
English Version
Health informatics - Electronic health record communication -
Part 1: Reference model (ISO 13606-1:2008)
Informatique de santé - Communication du dossier de Medizinische Informatik - Kommunikation von
santé informatisé - Partie 1: Modèle de référence (ISO Patientendaten in elektronischer Form - Teil 1:
13606-1:2008) Referenzmodell (ISO 13606-1:2008)
This European Standard was approved by CEN on 24 August 2012.

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 CEN-CENELEC Management Centre 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 CEN-CENELEC Management Centre has the same
status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United
Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2012 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN ISO 13606-1:2012: E
worldwide for CEN national Members.

Contents Page
Foreword .3

Foreword
The text of ISO 13606-1:2008 has been prepared by Technical Committee ISO/TC 215 “Health informatics” of
the International Organization for Standardization (ISO) and has been taken over as EN ISO 13606-1:2012 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 2013, and conflicting national standards shall be withdrawn at the
latest by April 2013.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights.
This document supersedes EN 13606-1:2007.
According to the CEN/CENELEC Internal Regulations, the national standards organisations of the following
countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech
Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece,
Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal,
Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom.
Endorsement notice
The text of ISO 13606-1:2008 has been approved by CEN as a EN ISO 13606-1:2012 without any
modification.
INTERNATIONAL ISO
STANDARD 13606-1
FIrst edition
2008-02-15
Health informatics — Electronic health
record communication —
Part 1:
Reference model
Informatique de santé — Communication du dossier de santé
informatisé —
Partie 1: Modèle de référence
Reference number
ISO 13606-1:2008(E)
©
ISO 2008
ISO 13606-1:2008(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2008
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2008 – All rights reserved

ISO 13606-1:2008(E)
Contents Page
Foreword. iv
0 Introduction. v
1 Scope .1
2 Normative references .1
3 Terms and definitions .2
4 Abbreviations.6
5 Conformance.7
5.1 EHR System conformance.7
5.2 Member country conformance .7
6 Reference model.8
6.1 Index to packages.8
6.2 Package: EXTRACT package.9
6.3 Package: DEMOGRAPHICS package.26
6.4 Package: SUPPORT package .34
6.5 Primitive data types.42
Annex A (informative) UML profile .43
Annex B (informative) Relationship to other standards.45
Annex C (informative) Clinical example.59
Annex D (informative) Mapping to statements of requirement .72
Bibliography .80

ISO 13606-1:2008(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 13606-1 was prepared by Technical Committee ISO/TC 215, Health informatics.
ISO 13606 consists of the following parts, under the general title Health informatics — Electronic health record
communication:
⎯ Part 1: Reference model
⎯ Part 2: Archetype interchange specification
⎯ Part 3: Reference archetypes and term lists
⎯ Part 5: Interface specification
iv © ISO 2008 – All rights reserved

ISO 13606-1:2008(E)
0 Introduction
0.1 Preface
The overall goal of ISO 13606 is to define a rigorous and stable information architecture for communicating
part or all of the Electronic Health Record (EHR) of a single subject of care (patient). This is to support the
interoperability of systems and components that need to communicate (access, transfer, add or modify) EHR
data via electronic messages or as distributed objects:
⎯ preserving the original clinical meaning intended by the author;
⎯ reflecting the confidentiality of that data as intended by the author and patient.
ISO 13606 is not intended to specify the internal architecture or database design of EHR systems or
components. Nor is it intended to prescribe the kinds of clinical application that might require or contribute
EHR data in particular settings, domains or specialities. For this reason, the information model proposed here
is called the EHR Extract, and might be used to define a message, an XML document or schema, or an object
interface. The information model in this part of ISO 13606 is an ISO Reference Model for Open Distributed
Processing (RM-ODP) RM-ODP Information Viewpoint of the EHR Extract.
ISO 13606 considers the EHR to be the persistent longitudinal and potentially multi-enterprise or multi-
national record of health and care provision relating to a single subject of care (the patient), created and
stored in one or more physical systems in order to inform the subject’s future healthcare and to provide a
medico-legal record of care that has been provided. Whilst an EHR service or system will need to interact with
many other services or systems providing terminology, medical knowledge, guidelines, workflow, security,
persons registries, billing etc., ISO 13606 has only touched on those areas if some persistent trace of such
interactions is required in the EHR itself, and requires specific features in the reference model to allow their
communication.
ISO 13606 may offer a practical and useful contribution to the design of EHR systems but will primarily be
realised as a common set of external interfaces or messages built on otherwise heterogeneous clinical
systems.
This part of ISO 13606 is the first part to be published of a five-part series. In this part of ISO 13606
dependency upon one of the other parts of this series is explicitly stated where it applies.
0.2 Technical approach
ISO 13606 has drawn on the practical experience that has been gained in implementing a European precursor
prestandard, ENV 13606, other EHR-related standards and specifications, commercial systems and
demonstrator pilots in the communication of whole or part of patients’ EHRs, and on fifteen years of research
findings in the field. ISO 13606 builds on ENV 13606, in order to provide a more rigorous and complete
specification, to accommodate new requirements identified, to incorporate a robust means of applying the
generic models to individual clinical domains, and to enable communication using HL7 version 3 messages. A
mapping from the European prestandard is also provided to support implementers of systems that conformed
to it. The technical approach to producing ISO 13606 has taken into account several contemporary areas of
requirement.
a) In addition to a traditional message-based communication between isolated clinical systems, the
Electronic Health Record will in some cases be implemented as a middleware component (a record
server) using distributed object technology and/or web services.
ISO 13606-1:2008(E)
b) “Customers” of such record services will be not only other electronic health record systems but also other
middleware services such as security components, workflow systems, alerting and decision support
services and other medical knowledge agents.
c) There is wide international interest in this work, and this part of ISO 13606 has been drafted jointly
through CEN and ISO with significant input from many member countries.
d) Mapping to HL7 version 3 has been considered an important goal, to enable conformance to this part of
ISO 13606 within an HL7 version 3 environment.
e) The research and development (R & D) inputs on which ENV 13606 was based have moved forward
since 1999 and important new contributions to the field have been taken into account. The open EHR
foundation, integrating threads of R & D in Europe and Australia, is one such example.
Given the diversity of deployed EHR systems, ISO 13606 has made most features of EHR communication
optional rather than mandatory. However, some degree of prescription is required to make EHR Extracts
safely processable by an EHR recipient system, which is reflected through mandatory properties within the
models in Parts 1, 2, and 4, and through normative term lists (defined in Part 3).
ISO 13606 will, in practice, usually be adopted alongside other health informatics standards that define
particular aspects of health data representation. Annex B explains how ISO 13606 can be used alongside key
complementary standards, including the HL7 Version 3 Reference Information Model (RIM), EN 14822-1, EN
14822-2, EN 14822-3, CEN/TS 14822-4 (GPIC), prEN 12967 (HISA) and prEN13940 (CONTSYS).
0.3 The Dual Model approach
The challenge for EHR interoperability is to devise a generalized approach to representing every conceivable
kind of health record data structure in a consistent way. This needs to cater for records arising from any
profession, speciality or service, whilst recognising that the clinical data sets, value sets, templates, etc.
required by different healthcare domains will be diverse, complex and will change frequently as clinical
practice and medical knowledge advance. This requirement is part of the widely acknowledged health
informatics challenge of semantic interoperability.
The approach adopted by ISO 13606 distinguishes a reference model, defined in this part of ISO 13606 and
used to represent the generic properties of health record information, and archetypes (conforming to an
archetype model, defined in Part 2), which are meta-data used to define patterns for the specific
characteristics of the clinical data that represent the requirements of each particular profession, speciality or
service.
The Reference Model represents the global characteristics of health record components, how they are
aggregated, and the context information required to meet ethical, legal and provenance requirements. This
model defines the set of classes that form the generic building blocks of the EHR. It reflects the stable
characteristics of an electronic health record, and would be embedded in a distributed (federated) EHR
environment as specific messages or interfaces (as specified in Part 5).
This generic information model needs to be complemented by a formal method of communicating and sharing
the organizational structure of predefined classes of EHR fragment corresponding to sets of record
components made in particular clinical situations. These are effectively precoordinated combinations of
named RECORD_COMPONENT hierarchies that are agreed within a community in order to ensure
interoperability, data consistency and data quality.
An Archetype is the formal definition of prescribed combinations of the building-block classes defined in the
Reference Model for particular clinical domains or organizations. An archetype is a formal expression of a
distinct, domain-level concept, expressed in the form of constraints on data whose instances conform to the
reference model. For an EHR_Extract, as defined in this part of ISO 13606, an archetype instance specifies
(and effectively constrains) a particular hierarchy of RECORD_COMPONENT sub-classes, defining or
constraining their names and other relevant attribute values, optionality and multiplicity at any point in the
hierarchy, the data types and value ranges that ELEMENT data values may take, and other constraints.
vi © ISO 2008 – All rights reserved

ISO 13606-1:2008(E)
This part of ISO 13606 recognises that archetypes might be used to support communication between some
EHR systems in the future, or might be used as a knowledge specification by some EHR system external
interfaces when mapping parts of an EHR to an EHR_EXTRACT, or might not be used at all between some
EHR systems. The use of archetypes is therefore supported, but not made mandatory, by this part of
ISO 13606. A specification for communicating archetypes is defined by Part 2.
0.4 Requirements basis for this part of ISO 13606
From the early 1990s it was recognised that a generic representation is required for the communication of
arbitrary health record information between systems, and in Europe this has resulted in a succession of EU
sponsored R & D projects and two generations of CEN health informatics standards prior to this International
Standard. These projects and standards have sought to define the generic characteristics of EHR information
and to embody these in information models and message models that could provide a standard interface
between clinical systems. The vision of such work has been to enable diverse and specialist clinical systems
to exchange whole or parts of a person’s EHR in a standardized way that can rigorously and generically
represent the data values and contextual organization of the information in any originating system. A
complementary goal has been to accommodate the evolving nature of medical knowledge and the inherent
diversity of clinical practice.
Many investigations of user and enterprise requirements for the EHR have taken place over this period, which
have sought to span the information needs of diverse specialties across primary, secondary and tertiary care,
between professions and across countries. These requirements have been distilled and analysed by expert
groups, mainly within Europe, in order to identify the basic information that needs to be accommodated within
an EHR information architecture to:
⎯ capture faithfully the original meaning intended by the author of a record entry or set of entries;
⎯ provide a framework appropriate to the needs of professionals and enterprises to analyse and interpret
EHRs on an individual or population basis;
⎯ incorporate the necessary medico-legal constructs to support the safe and relevant communication of
EHR entries between professionals working on the same or different sites.
[41, 48, 57] [36-38] [42, 43]
This work includes the GEHR , EHCR-SupA , Synapses , I4C and Nora projects and
work by the Swedish Institute for Health Services Development (SPRI). These key requirement publications
are listed in the Bibliography [51]. These requirements have recently been consolidated on the international
[9]
stage within an ISO Technical Specification, ISO/TS 18308 .
In this reference model the key EHR contextual requirements for such faithfulness are related to a set of
logical building block classes, with suitable attributes proposed for each level in the EHR extract hierarchy.
ISO/TS 18308 has been adopted as the reference set of requirements to underpin the features within this
EHR communications reference model, and a mapping of these requirements statements to the constructs in
the reference model is given in Annex D.
0.5 Overview of the EHR extract record hierarchy
The information in a health record is inherently hierarchical. Clinical observations, reasoning and intentions
can have a simple or a more complex structure. They are generally organized under headings, and contained
in “documents” such as consultation notes, letters and reports. These documents are usually filed in folders,
and a patient may have more than one folder within a healthcare enterprise (e.g. medical, nursing, obstetric).
The EHR extract reference model needs to reflect this hierarchical structure and organization, meeting
published requirements in order to be faithful to the original clinical context and to ensure meaning is
preserved when records are communicated between heterogeneous clinical systems. To do this, the model
formally sub-divides the EHR hierarchy into parts that have been found to provide a consistent mapping to the
ways which individual EHRs are organized within heterogeneous EHR systems.
ISO 13606-1:2008(E)
These parts are summarised in Table 1.
Table 1 — Main hierarchy components of the EHR Extract Reference Model
EHR hierarchy
Description Examples
component
EHR_EXTRACT The top-level container of part or all of the Not applicable
EHR of a single subject of care, for
communication between an EHR provider
system and an EHR recipient.
FOLDER The high level organization within an EHR, Diabetes care, schizophrenia,
dividing it into compartments relating to care cholecystectomy, paediatrics, St Mungo’s
provided for a single condition, by a clinical Hospital, GP folder, Episodes 2000-2001,
team or institution, or over a fixed time Italy
period such as an episode of care.
COMPOSITION The set of information committed to one Progress note, laboratory test result form,
EHR by one agent, as a result of a single radiology report, referral letter, clinic visit,
clinical encounter or record documentation clinic letter, discharge summary, functional
session. health assessment, diabetes review
SECTION EHR data within a COMPOSITION that Reason for encounter, past history, family
belongs under one clinical heading, usually history, allergy information, subjective
reflecting the flow of information gathering symptoms, objective findings, analysis,
during a clinical encounter, or structured for plan, treatment, diet, posture, abdominal
the benefit of future human readership. examination, retinal examination
ENTRY The information recorded in an EHR as a A symptom, an observation, one test result,
result of one clinical action, one observation, a prescribed drug, an allergy reaction, a
one clinical interpretation, or an intention. diagnosis, a differential diagnosis, a
This is also known as a clinical statement. differential white cell count, blood pressure
measurement
CLUSTER The means of organizing nested multi-part Audiogram results, electro-encephalogram
data structures such as time series, and to interpretation, weighted differential
represent the columns of a table. diagnoses
ELEMENT The leaf node of the EHR hierarchy, Systolic blood pressure, heart rate, drug
containing a single data value. name, symptom, body weight
An EHR_EXTRACT contains EHR data as COMPOSITIONs, optionally organized by a FOLDER hierarchy.
COMPOSITIONs contain ENTRYs, optionally contained within a SECTION hierarchy.
ENTRYs contain ELEMENTS, optionally contained within a CLUSTER hierarchy.
viii © ISO 2008 – All rights reserved

ISO 13606-1:2008(E)
Figure 1 — Diagram of the EHR Extract hierarchy (Part 1)

Figure 2 — Diagram of the EHR Extract hierarchy (Part 2)
ISO 13606-1:2008(E)
0.6 Description of the main Reference Model classes
EHR_EXTRACT
The EHR_EXTRACT is used to represent part or all of the health record information extracted from an EHR
provider system for the purposes of communication to an EHR recipient (which might be another EHR system,
a clinical data repository, a client application or a middleware service such as an electronic guideline
component) and supporting the faithful inclusion of the communicated data in the receiving system.
The EHR_EXTRACT class contains attributes to identify the subject of care whose record this is, the EHR
Provider system from which it has been derived and the identifier of that subject’s EHR in that system, and
optionally the agent responsible for creating it.
The EHR_EXTRACT contains the EHR data, in three parts:
1) a set of COMPOSITIONs;
2) optionally, a directory of FOLDERs that provide a high-level grouping and organizing of the
COMPOSITIONs;
3) optionally, a set of demographic descriptors for each of the persons, organizations, devices or software
components that are identified within (1) and (2) above. This approach allows such entities to be
referenced uniquely via an identifier within the body of the EHR, without repetition of the descriptive
details each time, and also ensures that any EHR_EXTRACT can be interpreted in isolation if the
recipient system does not have access to the services needed to decode the entity identifiers used by the
EHR Provider.
A formal mechanism is defined in Part 4 of ISO 13606 for including access policy information within the
EHR_EXTRACT. This is intended to inform the EHR recipient about the wishes of the subject of care and of
healthcare providers for how future access requests for the data should be managed.
The EHR_EXTRACT also contains a summary of the filter or selection criteria by which this EHR_EXTRACT
was created. This may or may not correspond directly to the criteria in the EHR request, and provides a record
of the kind of subset this EHR_EXTRACT is of the overall EHR held by the EHR provider. This might be of
importance if the EHR_EXTRACT is retained intact by the EHR provider or EHR recipient, and subsequently
accessed by agents who do not have access to the original EHR request. For example, this class can specify
if this EHR_EXTRACT is limited to the most recent version of each COMPOSITION (as required for most
clinical care purposes) or if it includes all historic versions (which might be required for legal purposes). It
might specify the maximum level of sensitivity of the data (implying that data that is more sensitive than this
level may exist and have been filtered out), or that multi-media objects have been excluded to limit its total
size. If the EHR_EXTRACT was created by selecting particular categories of clinical data (e.g., only laboratory
data) then this may be indicated through a list of the archetypes that were included in the selection criteria. An
option exists to include additional criteria (expressed as strings); this may be used to provide additional human
readable information about this EHR_EXTRACT or may be used for locally-agreed computer-interpretable
constraint information.
RECORD_COMPONENT
The main building block classes that are used to construct the EHR data hierarchy within an EHR_EXTRACT
are kinds of RECORD_COMPONENT. This is an abstract class, the super-class of all of the concrete nodes in
the EHR hierarchy: FOLDER, COMPOSITION, SECTION, ENTRY, CLUSTER, ELEMENT, and also the
super-class for two other abstract class nodes: CONTENT and ITEM.
RECORD_COMPONENT defines the information properties that are common to all of these building blocks,
including:
⎯ the unique identifier that was issued to this EHR node by the EHR system in which it was first committed
(its originating EHR system); other holders of this RECORD_COMPONENT need to retain this attribute
value to ensure that any subsequent extracts are always consistently identified;
x © ISO 2008 – All rights reserved

ISO 13606-1:2008(E)
⎯ the clinical name, used in its originating EHR system to label this part of the EHR data;
⎯ optionally, a standardized coded concept to which the name has been mapped to support the semantic
interoperability of equivalent EHR instances even if these have been given different clinical names by
different EHR systems;
⎯ the identifier of the archetype node to which this RECORD_COMPONENT conforms, to be used by
archetype enabled-EHR systems or if archetypes have been used when mapping the data into the
EHR_EXTRACT format;
⎯ a sensitivity code and references to access control policies that should be used by the EHR recipient to
govern future access to the data;
⎯ support for links between any record components.
When generating an EHR_EXTRACT conformant to this part of ISO 13606 the EHR provider system might, in
some situations, need to introduce a RECORD_COMPONENT into the hierarchy that does not have a direct
correspondence with any original data in the EHR system. The synthesised attribute of
RECORD_COMPONENT permits the exporting EHR provider system to indicate that a
RECORD_COMPONENT has been created within the EHR_EXTRACT for this purpose.
Health record entries often refer to other pre-existing entries, and include them as “copies”. A common
example of this is a discharge summary, which might include copies of several parts of an inpatient stay
record such as the admission circumstances, the main diagnoses, principal interventions and treatments. In
most cases the EHR_EXTRACT needs to contain these referenced RECORD_COMPONENTS explicitly by
value, so that each COMPOSITION can be interpreted by the EHR Recipient. However, it is also important,
medico-legally, to communicate that these entries are copies, and that they originate from a different part of
that subject’s EHR. The optional attribute original_parent_ref may be used to represent the rc_id of the
original parent RECORD_COMPONENT if the data are a copy.
Any RECORD_COMPONENT may include audit data about when and by whom it was committed in its
originating EHR system. Each revised version of a RECORD_COMPONENT may document the version
status, the reason for the revision and the identifier of the preceding version. However, for data protection
reasons it is usually advised that previous (erroneous) versions of an EHR are not communicated as part of
normal clinical shared care, but only in circumstances where an EHR transfer is being made for legal reasons.
It is important that each RECORD_COMPONENT be uniquely and consistently identified across multiple
EHR_EXTRACTS, so that references to or between them remain valid. Examples of such references are
semantic links, revision and attestation. The rc_id attribute is of data type Instance Identifier (II), which
incorporates an ISO OID; II is currently considered internationally to be the most appropriate data type for
persistent identifiers that are required to be globally unique. It is unlikely that contemporary EHR systems will
have existing primary keys or internal identifiers that correspond directly to globally-unique II instances.
However, an EHR provider system that has been issued with an organizational OID might use its internal
references to construct unique local extensions to that OID and thereby construct globally-unique rc_id values.
Alternatively, it might create completely new rc_ids and retain a record of the mapping of these to each
internal identifier, so that any future EHR_EXTRACTS it generates will use consistent rc_id values. It is also
unlikely that an EHR recipient system will be able to use received rc_id values as its internal primary keys for
the data, since every database uses a slightly different approach to generating and using such keys. The EHR
recipient might therefore also need to keep a record of the mapping of imported rc_id values to its primary
keys, so that future references to those RECORD_COMPONENTS can be appropriately matched, and it can
create EHR_EXTRACTs that reapply those rc_id values to the exported data. An alternative approach is for
EHR systems to explicitly store the rc_id values along with the clinical data, and treat this as part of the
“payload” data and not attempt to use these also as primary keys. It should also be noted that the rc_id does
not function as a primary key equivalent within an EHR_EXTRACT i.e. duplicate values of rc_id are permitted
if each instance does indeed refer to the same piece of clinical data within the EHR provider system.
ISO 13606-1:2008(E)
FOLDER
This class is used to represent the highest-level organizations of EHR data within the EHR_EXTRACT, e.g., to
group COMPOSITIONs by episode, care team, clinical speciality, clinical condition or time interval.
Internationally, this kind of organizing structure is used variably: in some enterprises and systems the folder
concept is treated as an informal compartmentalization of the overall health record; in others it might represent
a significant legal portion of the EHR relating to the services provided by an enterprise or team.
In the EHR_EXTRACT, FOLDERs are an optional hierarchy. FOLDERs may contain other FOLDERs to form
a complete directory system, and may include any pertinent information about their committal or revision
within the EHR Provider system. FOLDERs reference COMPOSITIONs via a list of unique identifiers, rather
than by physically containing them. This permits any COMPOSITION to appear within more than one
FOLDER, which is a requirement that some vendors and jurisdictions have indicated.
In some situations FOLDERs might be created specifically to organize the EHR_EXTRACT, or contain only a
selected subset of the data in the corresponding folder in the EHR provider system. In such circumstances the
FOLDERs within the EHR_EXTRACT will not have a direct correspondence with those in the contributing
EHR provider system, i.e. they will have been synthesised.
A FOLDER may be used to group a set of COMPOSITIONS comprising the individual records made of
members of a multi-professional team during a single clinical encounter. In situations like this where a
FOLDER represents a finite interval of care, it may be attested. This approach should be used to
communicate that the FOLDER’s contents are a complete record of that interval of care. This also provides an
indication to the EHR recipient that additional COMPOSITIONS ought not to be added to this FOLDER.
Since folder systems are used variably within EHR systems, this International Standard cannot prescribe how
they should be handled within the EHR recipient’s system: i.e. it does not require that the EHR recipient
explicitly use these within its EHR system. However, if a FOLDER has been attested, an intact copy of this
information shall be retained for future reference and possible onward communication.
COMPOSITION
The COMPOSITION represents the set of RECORD_COMPONENTS composed (authored) during one user’s
clinical session or record documentation session, for committal within one EHR. Common examples of this
include a consultation note, a progress note, a report or a letter, an investigation report, a prescription form
and a set of bedside nursing observations. The COMPOSITION documents the date and time or interval of
the clinical encounter, and the legal jurisdiction in which the records were composed.
The composer is the agent (party, device or software) responsible for creating, synthesising or organizing
information that is committed to an EHR. This agent takes responsibility for its inclusion in that EHR, even if
not the originator of it and even if not the committer of it. The content of the COMPOSITION is primarily
attributed to this person. Whether or not the composer is changed when a revision is made is optional.
Applications will generally use the composer's name to label COMPOSITION data when used for clinical care.
There may be occasions when there is no single main composer (e.g. a multi-professional tele-consultation, or
a case conference); in such cases the composer role might not be formally specified even though each
participant and clinical role is declared. The composer is therefore optional.
Provision is made for a COMPOSITION to include the details and locations of any other participants involved
in the clinical encounter or record documentation session. Some of these might have participated from
different locations (for example on the telephone, or via a video-consultation).
The COMPOSITION is the main container class for EHR data within the extract itself, to ensure that a
consistent containment hierarchy is used within all Extracts: the EHR_EXTRACT contains a set of
COMPOSITIONs together with audit data about the committal of each within the EHR Provider’s system. A
COMPOSITION is always used to communicate version updates between EHR systems, even if the actual
updates refer to parts of that COMPOSITION. If multiple versions of EHR data are to be communicated within
one EHR_EXTRACT, this will be as a set of distinct COMPOSITIONs, each referencing the preceding version
and collectively referencing a version set identifier.
xii © ISO 2008 – All rights reserved

ISO 13606-1:2008(E)
Each COMPOSITION also optionally documents any attestations (e.g. digital signatures) that pertain to it or to
any of its contents.
Contribution The Contribution is the set of COMPOSITIONs committed by one user at one point in time in
the EHR of one subject of care. Some clinical applications include complex screens capable of presenting
multiple parts of an EHR simultaneously (for example through tabbed panes). On saving the screen, a user
might actually be committing data to more than one part of the patient’s EHR (e.g. the addition of a new
consultation note and the revision of a medication entry stored elsewhere in the EHR). The Contribution refers
to all of the changes and updates committed to that EHR during that committer’s session. All of the
COMPOSITIONs comprising one Contribution can be collectively identified by providing a common value for
the contribution_id attribute.
SECTION
The record entries relating to a single clinical session are usually grouped under headings that represent
phases or sub-topics within the clinical encounter, or assist with layout and navigation. Clinical headings
usually reflect the clinical workflow during a care session, and might also reflect the main author's reasoning
processes. Much research has demonstrated that headings are used differently by different professional
groups and specialties, and that headings are not used consistently enough to support safe automatic
processing of the EHR. They are therefore treated in this part of ISO 13606 as an optional (informal)
containment for human navigation, filtering and readability.
SECTIONs may be used to represent the containment hierarchy of clinical headings used within the EHR
provider system to group and organize entries within a COMPOSITION. Each SECTION may contain
additional SECTIONs and/or ENTRYs.
ENTRY
The ENTRY is the container class for the ITEM data structure that represents the information acquired and
recorded for a single observation or observation-set (battery or time series), a single clinical statement such
as a portion of the patient's history or an inference or assertion, or a single action that might be intended or
has actually been performed. The ENTRY class associates this ITEM structure with a set of context attributes
to facilitate safe interpretation:
⎯ information in an ENTRY may be about someone other than the patient (e.g. a relative): ENTRY defines
the subject of the information;
⎯ information in an ENTRY may have been provided by or is attributed to a particular individual: ENTRY
defines the information provider;
⎯ other participants might need to be associated with a particular ENTRY;
⎯ the ENTRY may represent the evolving status of a clinical act (e.g. requested, performed, reported,
cancelled) and may optionally carry an identifier that links it with a workflow system;
⎯ the ENTRY may use a flag to advise the EHR recipient that the data structure includes some indication of
uncertain findings or opinions, and that care needs to be taken when using the data for automated
processing.
The ENTRY contains a data structure represented using CLUSTERS and ELEMENTS. It is important to note
that ENTRY cannot contain further ENTRYs. The set of contexts defined at the ENTRY level (e.g. the subject
of information) apply to the whole data structure and cannot be overridden.
ITEM, CLUSTER and ELEMENT
The ITEM may represent both the actual data describing the observation, inference, or action, and optionally
the details describing the examination method, the patient’s physical state or details supporting the clinical
reasoning process such as a reference to an electronic guideline, decision support system or other knowledge
reference. The item_category attribute provides an optional means of distinguishing these different
...