ISO 13606-1:2008

Health informatics - Electronic health record communication - Part 1: Reference model

ISO 13606-1:2008 specifies the communication of part or all of the electronic health record (EHR) of a single identified subject of care between EHR systems, or between EHR systems and a centralized EHR data repository. It may also be used for EHR communication between an EHR system or repository and clinical applications or middleware components (such as decision support components) that need to access or provide EHR data, or as the representation of EHR data within a distributed (federated) record system. ISO 13606-1:2008 will predominantly be used to support the direct care given to identifiable individuals, or to support population monitoring systems such as disease registries and public health surveillance. Use of health records for other purposes such as teaching, clinical audit, administration and reporting, service management, research and epidemiology, which often require anonymization or aggregation of individual records, are not the focus of ISO 13606-1:2008 but such secondary uses might also find this document useful.

Informatique de santé — Communication du dossier de santé informatisé — Partie 1: Modèle de référence

L'ISO 13606-1:2008 spécifie la communication de tout ou partie du dossier informatisé de santé (DIS) d'un seul sujet de soins identifié entre systèmes de DIS, ou entre des systèmes de DIS et un réceptacle de données de DIS centralisé. Elle peut également être utilisée pour la communication de DIS entre un système ou réceptacle de DIS et des applications médicales ou composants intergiciels (tels que des composants d'aide à la prise de décision) nécessitant d'avoir d'accès aux ou de fournir des données DIS dans un système réparti (fédéré). L'ISO 13606-1:2008 est destinée à être principalement utilisée pour prendre en charge les soins directs dispensés à des personnes identifiables, ou les systèmes d'observation de la population tels que les registres de maladies et l'observation de la santé publique. L'utilisation des dossiers de santé pour d'autres finalités telles que l'enseignement, l'évaluation médicale, l'administration et l'établissement de rapports, la gestion des services de santé, la recherche et l'épidémiologie, qui nécessitent l'agrégation de dossiers individuels de personnes physiques ne constitue pas l'objet de l'ISO 13606-1:2008; néanmoins, ces applications secondaires sont susceptibles de trouver un intérêt à cette norme.

General Information

• Status: Withdrawn
• Publication Date: 06-Feb-2008
• Withdrawal Date: 06-Feb-2008
• ICS: 35.240.80 - IT applications in health care technology
• Technical Committee: ISO/TC 215 - Health informatics
• Drafting Committee: ISO/TC 215/WG 1 - Architecture, Frameworks and Models
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 07-Jun-2019
• Completion Date: 13-Dec-2025

Relations

• Revised: ISO 13606-1:2019 - Health informatics - Electronic health record communication - Part 1: Reference model
• Effective Date: 04-Nov-2015

Standards Content (Sample)

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 2008
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 [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO 2008 – All rights reserved

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

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

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.
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

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.
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

Figure 1 — Diagram of the EHR Extract hierarchy (Part 1)

Figure 2 — Diagram of the EHR Extract hierarchy (Part 2)
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

⎯ 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.
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

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 parts of a
data structure, as an aid to the automated analysis or filtering of the ITEMS in an ENTRY. The codeset for this
attribute is defined in ISO 13606-3.
Information in an ITEM (CLUSTER or ELEMENT) might have originated at a date/time different from the care
activity or its recording. The obs_time attribute permits representation of a single date or time or an interval, to
any level of granularity. This would permit, for example, an operation to be dated only by the year, the onset of
a symptom to a month and year, a period of employment to be a precise date range or an interval in years, the
precise time-stamping of an arrhythmia, or an angiogram to be organized as a time series of images.
Information in an ITEM might be emphasised by the author as being exceptional or noteworthy. This part of
ISO 13606 does not define a code set for this attribute; any agreed terminology may be used to specify the
degree of emphasis or to specify the kind of exception.
The CLUSTER supports the representation of complex data structures needed to represent the actual data
values within a multi-part (nested) observation, clinical statement or instruction. These may need to be
represented as a table, a tree or a time series. Specific examples include an ECG tracing, a full blood count,
ankle reflex examination, the prescription of an intravenous drug infusion.
The ELEMENT class represents the leaf node within the EHR hierarchy. Each instance of this class will have
a single data value. (A ratio, an interval or a co-ordinated term are considered here to be examples of single
data values). Examples of ELEMENT might include reason for encounter, body weight, pulse. An ELEMENT
may have a null data value, for example if a value is not known.
Data values
Each ELEMENT contains one data value, to represent the actual instance values. This is one of the CEN Data
Types (CEN/TS 14796) for:
⎯ text and coded terms;
⎯ quantities including ratios, intervals and durations;
⎯ dates and time;
⎯ graphical and other MIME type (e.g. image, signal).
It is recognised that, at the time of producing this part of ISO 13606, a new set of health informatic data types
is being developed by ISO/TC 215. Once this is published, CEN is expected to deprecate CEN/TS 14796 in
favour of this new standard. In doing so, it will need to provide a mapping correspondence to the new data
type standard, and this mapping will also need to be used in order to adopt the new data types alongside this
part of ISO 13606.
In order to support the adoption of this part of ISO 13606 more widely internationally than the jurisdiction of
CEN/TS 14967, the set of attribute data types actually used within this reference model (other than the data
value of ELEMENT) are explicitly included in this part of ISO 13606 in a support package. These should also
be deprecated in favour of ISO data types once published.
NOTE Primitive data types such as Boolean, Integer are assumed to follow ISO/IEC 11404 and are not further
defined here.
xiv © ISO 2008 – All rights reserved

0.7 Description of the other principal classes of the reference model
AUDIT_INFO
It is a medico-legal requirement to document and to communicate when and by whom EHR data were entered
into an EHR system. It is also important to track changes to EHR data if modifications are made, and to
communicate this within an EHR_EXTRACT. The AUDIT_INFO class is used to represent these audit data:
a) for any RECORD_COMPONENT, as a permanent record of its commitment in its originating EHR
system;
b) for any COMPOSITION, as a record of its commitment within the EHR provider system that has
generated this EHR_EXTRACT.
A COMPOSITION might therefore have up to two audit data sets, one relating to its originating EHR system
(called “feeder_audit”) and one to its subsequent commitment within the EHR provider’s system (called
“committal”), if these are different. This part of ISO 13606 does not, however, require or support the
communication of an indefinite accumulation of audit data sets for every system into which a COMPOSITION
is committed. This is because a cumulative set of audit data sets without the actual clinical data to show the
details of what was changed each time is not considered to be of clinical value. If a full change history is
required to be communicated, each version of the COMPOSITION needs to be included in the
EHR_EXTRACT.
For committal, the AUDIT_INFO class represents the timestamp of committal, it identifies the committer, and
the EHR system into which the data were committed. The timestamp reflects when this
RECORD_COMPONENT was persisted with in an EHR system and therefore became part of the EHR of the
subject of care. The committer is responsible for including this RECORD_COMPONENT within the EHR, but
might not be responsible for deciding upon the clinical content being committed.
The committer and time committed attributes are optional, to allow for the possibility that some data will have
been imported from simple legacy systems in which the clinical data originated but for which these values are
not known. However, for the committal AUDIT_INFO association these at
...

NORME ISO
INTERNATIONALE 13606-1
Première édition
2008-02-15
Informatique de santé — Communication
des dossiers de santé informatisés —
Partie 1:
Modèle de référence
Health informatics — Electronic health record communication —
Part 1: Reference model
Numéro de référence
©
ISO 2008
DOCUMENT PROTÉGÉ PAR COPYRIGHT

©  ISO 2008
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite ni utilisée sous
quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit
de l'ISO à l'adresse ci-après ou du comité membre de l'ISO dans le pays du demandeur.
ISO copyright office
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Version française parue en 2012
Publié en Suisse
ii © ISO 2008 – Tous droits réservés

Sommaire Page
Avant-propos . iv
0.1  Préface . v
0.2  L’approche technique . vi
0.3  L’approche du Modèle double . vi
0.4  Base des exigences relatives à la présente partie de l'ISO 13606 . vii
0.5  Présentation générale de la hiérarchie du dossier relatif à l'extrait de DIS . viii
0.6  Description des classes principales du Modèle de référence . xi
0.7  Description des autres classes principales du modèle de référence . xvii
0.8  Approche des domaines de représentation spécifiques . xx
0.9  Comparaison entre l'ISO 13606-1 et l'EN 13606-1 . xxvii
1  Domaine d’application . 1
2  Références normatives . 1
3  Termes et définitions . 1
4  Abréviations . 6
5  Conformité . 7
5.1  Conformité du Système de DIS . 7
5.2  Conformité des pays membres . 8
6  Modèle de référence . 8
6.1  Index relatif aux paquets . 8
6.2  Paquet: Paquet EXTRACT . 9
6.3  Paquet: Paquet DEMOGRAPHICS . 26
6.4  Paquet: Paquet SUPPORT . 34
6.5  Types de données primitifs . 42
Annexe A (informative) Profil UML . 43
Annexe B (informative) Relation avec d'autres normes . 45
Annexe C (informative) Exemple clinique . 60
Annexe D (informative) Correspondance avec diverses déclarations d'exigences . 72
Bibliographie . 82

Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux de
normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général confiée
aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude a le droit de faire partie du
comité technique créé à cet effet. Les organisations internationales, gouvernementales et non
gouvernementales, en liaison avec l'ISO participent également aux travaux. L'ISO collabore étroitement avec
la Commission électrotechnique internationale (CEI) en ce qui concerne la normalisation électrotechnique.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/CEI,
Partie 2.
La tâche principale des comités techniques est d'élaborer les Normes internationales. Les projets de Normes
internationales adoptés par les comités techniques sont soumis aux comités membres pour vote. Leur
publication comme Normes internationales requiert l'approbation de 75 % au moins des comités membres
votants.
L'attention est appelée sur le fait que certains des éléments du présent document peuvent faire l'objet de
droits de propriété intellectuelle ou de droits analogues. L'ISO ne saurait être tenue pour responsable de ne
pas avoir identifié de tels droits de propriété et averti de leur existence.
L'ISO 13606-1 a été élaborée par le comité technique ISO/TC 215, Informatique de santé.
L'ISO 13606 comprend les parties suivantes, présentées sous le titre général Informatique de santé —
Communication des dossiers de santé informatisés:
 Partie 1: Modèle de référence
 Partie 2: Spécification d'échange d’archétype
 Partie 3: Archétypes de référence et listes de termes
 Partie 5: Spécification d'interfaces
iv © ISO 2008 – Tous droits réservés

Introduction
0.1 Préface
L’objet général de l'ISO 13606 est de définir une architecture d’information rigoureuse et durable destinée à
communiquer tout ou partie du Dossier Informatisé de Santé (DIS) d'un seul sujet de soins (patient) afin de
permettre l’interopérabilité des systèmes et composants nécessitant de transmettre (accès, transfert, ajout ou
modification) les entrées du dossier DIS via des messages électroniques ou des objets répartis:
 en préservant le sens médical original que l’auteur a voulu donner;
 en reflétant la confidentialité des données voulue par l’auteur et le patient.
L'ISO 13606 n’a pas pour vocation de spécifier l’architecture interne ou la conception de la base de données
des systèmes ou composants du DIS. Elle n’a pas non plus vocation à définir les types d’application médicale
susceptible d’être requérante ou contributrice de données de DIS dans des configurations, domaines ou
spécialités en particulier. C’est pourquoi le modèle d’information proposé ici est nommé Extrait de DIS et peut
être employé pour définir un message, un document ou un schéma XML, ou une interface objet. Le modèle
d’information de la présente partie de l'ISO 13606 correspond à un Modèle de référence ISO pour le point de
vue informationnel contenu dans l’ISO RM-ODP de l'Extrait de DIS.
L'ISO 13606 envisage le DIS comme enregistrement de la santé et des soins prodigués relatifs à un sujet de
soins individuel (le patient), enregistrement pérenne et longitudinal, s'étendant potentiellement à plusieurs
structures de soins ou à plusieurs pays, créé et conservé dans un ou plusieurs systèmes physiques. Il apporte
les informations nécessaires aux soins médicaux futurs de ce sujet ainsi que, à titre médico-légal,
l’enregistrement des soins qui lui ont été dispensés. Tandis qu’un service ou un système de DIS nécessite
une interaction avec de nombreux autres services ou systèmes fournissant terminologie, connaissances
médicales, recommandations, déroulement des tâches, sécurité, enregistrements de personnes, facturation,
etc., l'ISO 13606 n’aborde ces domaines que dans la mesure où une trace permanente desdites interactions
est requise dans le DIS lui-même, et nécessite l’établissement de caractéristiques spécifiques dans le Modèle
de référence pour permettre leur communication.
Même si l'ISO 13606 peut apporter une contribution pratique et utile à la conception de systèmes de DIS, elle
doit avant tout être mise en pratique comme un ensemble commun d’interfaces ou de messages externes
bâtis sur des systèmes médicaux hétérogènes par ailleurs.
La présente partie de l'ISO 13606 est la première partie à publier d'une série en cinq parties. Dans la présente
partie de l'ISO 13606, la dépendance sur l'un des autres parties de la série est explicitement indiquée là où
elle s'applique.
0.2 L’approche technique
L'ISO 13606 s'appuie d'une part sur l’expérience pratique acquise dans la mise en œuvre d'une prénorme
européenne novatrice, l’ENV 13606 à laquelle elle succède, d’autres normes et spécifications liées au DIS
pour communiquer tout ou partie des DIS de patients, de systèmes commercialisés et de pilotes
démonstrateurs, et d'autre part sur les découvertes de la recherche menée pendant quinze années dans ce
domaine. L'ISO 13606, bâtie sur l’ENV 13606, afin de la rendre plus rigoureuse et complète, de s’adapter aux
nouvelles exigences identifiées, intégrer un moyen solide pour appliquer les modèles génériques aux
domaines médicaux particuliers et permettre la communication à l'aide de messages conformes à la version 3
d’HL7. Elle comporte également une mise en correspondance avec la prénorme européenne innovante, pour
faciliter la tâche des personnes ayant précédemment mis en œuvre des systèmes conformément à ses
préconisations. L'approche technique de l'ISO 13606 a pris en compte plusieurs domaines d’exigence
nouveaux.
a) Outre la traditionnelle communication par messages entre systèmes médicaux isolés, le dossier
informatisé de santé est mis en œuvre, dans certains cas, comme un composant intergiciel (serveur
dossier) utilisant une technologie d’objets répartis et/ou de services web.
b) Les «clients» de tels services dossier ne sont pas uniquement d’autres systèmes de dossier informatisé
de santé, mais également d’autres services intergiciels comme les composants de sécurité, les systèmes
de déroulement des tâches, les services d’alertes et de support de décision et d’autres agents apportant
une connaissance médicale.
c) Ces travaux du CEN et de l'ISO suscitent un large intérêt au niveau international et l’expérience
précieuse de nombreux pays membres a permis d’apporter une contribution à l'ISO 13606.
d) L’harmonisation avec l’HL7 version 3 a été considérée comme un but important pour permettre la
conformité à la présente partie de l'ISO 13606 dans un environnement HL7 version 3.
e) L’apport des travaux de recherche et développement (R&D), qui est à la base de l’ENV 13606, progresse
depuis 1999 et il a été tenu compte des nouvelles contributions importantes dans ce domaine. La
Fondation Open EHR, qui intègre des filières de recherche et développement en provenance d’Europe et
d’Australie, en est un exemple.
En raison de la diversité des systèmes de DIS déployés, l'ISO 13606 considère la plupart des caractéristiques
de la communication de DIS comme facultatives et non obligatoires. Cependant, il est nécessaire d'exprimer
certaines exigences pour qu’un Système destinataire de DIS puisse traiter de manière sûre des Extraits de
DIS. Ceci est reflété par les propriétés obligatoires des modèles spécifiés dans les Parties 1, 2 et 4, ainsi que
par les listes de termes normatifs (définis dans la Partie 3).
Dans la pratique, l'ISO 13606 sera généralement adoptée conjointement à d’autres normes en matière
d’informatique de la santé définissant des aspects particuliers de la représentation des données de santé.
L’Annexe B explique la manière dont l'ISO 13606 peut être utilisée conjointement aux normes
complémentaires de base, y compris le Modèle d'information de référence (RIM) HL7 Version 3, l’EN 14822-1,
l'EN 14822-2, l'EN 14822-3, la CEN/TS 14822-4 (GPIC), la prEN 12967 (HISA) et la prEN 13940 (CONTSYS).
0.3 L’approche du Modèle double
Le défi que représente l'interopérabilité des DIS a été d’élaborer une approche généralisable permettant de
représenter de manière cohérente toutes les sortes imaginables de dossier de santé. Cela nécessite de
prendre en compte des dossiers provenant de n'importe quelle profession, spécialité ou service, tout en
admettant que les ensembles de données cliniques, ensembles de valeurs, modèles de document, etc. requis
par différents domaines de soins sont divers, complexes et changent fréquemment à mesure que la pratique
clinique et les connaissances médicales avancent. Cette exigence est inhérente au défi largement reconnu
que représente l'interopérabilité sémantique pour l'informatique de la santé.
vi © ISO 2008 – Tous droits réservés

L’approche adoptée par l'ISO 13606 distingue le Modèle de référence, défini dans la présente partie de
l'ISO 13606, et utilisé pour représenter les propriétés génériques des informations du dossier de santé et des
archétypes (se conformant au Modèle d’archétype, défini dans la Partie 2) qui sont des métadonnées servant
à représenter les caractéristiques spécifiques de différentes catégories de données cliniques, susceptibles de
nécessiter une représentation pour répondre aux exigences de chaque profession, spécialité ou service
particulier.
Le Modèle de référence représente les caractéristiques globales des entrées des dossiers de santé, leur
mode d’agrégation, et les informations contextuelles nécessaires pour satisfaire aux exigences relatives à
l’éthique, au droit et à la provenance. Ce modèle définit un ensemble de classes formant les briques de base
génériques du DIS. Il reflète les caractéristiques stables d’un dossier informatisé de santé et est prévu pour
être imbriqué dans un environnement de DIS réparti (fédéré, par exemple) sous la forme de messages ou
interfaces spécifiques (tels que spécifiés dans l'ISO 13606-5).
Il est nécessaire de compléter le modèle d’information générique par un mode formel de communication et de
partage de la structure organisationnelle de classes prédéfinies de fragment du DIS correspondant aux
ensembles de composants du dossier constitués lors de situations cliniques particulières. Il s'agit de
combinaisons pré-coordonnées des hiérarchies RECORD_COMPONENT nommées et convenues au sein
d'une communauté afin d’assurer l’interopérabilité, l’homogénéité et la qualité des données.
Un archétype représente la définition formelle de combinaisons préétablies de classes considérées comme
briques de base définies dans le Modèle de référence pour des domaines ou des organisations médicaux
particuliers. Un archétype représente l'expression formelle d’un concept de domaine distinct, exprimé sous
forme de contraintes imposées aux données dont les instances se conforment au modèle de référence. Pour
un EHR_Extract, tel que défini dans la présente partie de l'ISO 13606, une instance d'archétype spécifie (et
contraint efficacement) une hiérarchie particulière de sous-classes RECORD_COMPONENT, par définition ou
contrainte imposée à leurs noms et autres valeurs d’attribut pertinentes, optionalité et cardinalité en tout point
de la hiérarchie, types de données et gammes de valeurs que les valeurs de données de l’ELEMENT peuvent
prendre, ainsi que d'autres contraintes.
La présente partie de l'ISO 13606 reconnaît que les archétypes pourront à l’avenir être utilisés pour prendre
en charge la communication entre certains systèmes de DIS, ou qu’ils pourront être utilisés comme une
spécification de connaissances par certaines interfaces externes de système de DIS lors de la mise en
correspondance de parties d’un DIS avec un EHR_EXTRACT, voire qu’ils pourront ne pas être utilisés du tout
entre certains systèmes de DIS. La présente partie de l'ISO 13606 prend par conséquent en charge
l’utilisation des archétypes, sans toutefois la rendre obligatoire. Une spécification relative à la communication
des archétypes est définie dans la Partie 2.
0.4 Base des exigences relatives à la présente partie de l'ISO 13606
Depuis le début des années 1990, il est reconnu que la communication d’informations arbitraires du dossier
de santé entre systèmes requiert une représentation générique adaptée. En Europe, cela a donné naissance
à une succession de projets de recherche et développement parrainés par l’UE ainsi qu'à deux générations
de normes CEN sur l’Informatique de la santé qui ont précédé la présente Norme internationale. Ces projets
et normes ont cherché à définir les caractéristiques génériques des informations contenues dans un DIS et de
résumer celles-ci dans les modèles d’information et modèles de message susceptibles de fournir une
interface standard entre systèmes médicaux. La vision retenue pour ce travail a été de donner la possibilité à
des systèmes médicaux variés et spécialisés d’échanger tout ou partie du DIS d’une personne d’une façon
normalisée permettant la représentation rigoureuse et générique des valeurs de données et de l’organisation
contextuelle des informations dans tout système émetteur. Un objectif complémentaire était de s’adapter à la
nature évolutive des connaissances médicales et à la diversité inhérente à la pratique clinique.
Au cours de cette période, de nombreuses recherches approfondies sur les exigences du DIS relatives aux
utilisateurs et aux structures de soins ont été effectuées dans le but de jeter un pont entre les besoins en
informations des différentes spécialités couvrant les soins primaires, secondaires et tertiaires, ainsi qu'entre
les professions et entre les pays. Ces exigences ont été distillées et analysées par des groupes d’experts,
principalement en Europe, de façon à identifier les informations de base qui doivent être prises en compte
dans l’architecture d’information du DIS pour
 saisir fidèlement le sens original que l’auteur a voulu donner à une entrée ou un ensemble d’entrées du
dossier,
 fournir un cadre approprié aux besoins des professionnels et des structures de soins pour analyser et
interpréter les DIS au niveau des personnes ou des populations,
 intégrer les dispositions à visée médico-légale nécessaires pour assurer une communication sûre et
pertinente des entrées de DIS entre professionnels travaillant sur des sites identiques ou différents.
[41, 48, 57] [36-38] [42, 43]
Ce travail inclut les projets GEHR , DSOI-SupA , Synapses , I4C et Nora, ainsi que le
travail réalisé en Suède par l'Institut suédois pour le développement des services de santé (SPRI). La liste
des publications relatives à ces exigences clés est fournie dans la Bibliographie [51]. Ces exigences ont
récemment été consolidées sur la scène internationale au sein de la spécification technique de
[9]
l’ISO/TS 18308 .
Dans ce Modèle de référence, les exigences contextuelles clés du DIS relatives à ce concept de fidélité sont
liées à un ensemble de classes briques de base logiques dotées d’attributs appropriés proposés à chaque
niveau de la hiérarchie de l’extrait de DIS. L’ISO/TS 18308 a été adoptée comme ensemble d'exigences de
référence pour étayer les caractéristiques contenues dans le présent Modèle de référence relatif aux
communications de DIS. L’Annexe D du présent document comprend la mise en correspondance de ces
exigences avec les constructions proposées dans le Modèle de référence.
0.5 Présentation générale de la hiérarchie du dossier relatif à l'extrait de DIS
Les informations contenues dans un dossier de santé sont, par nature, structurées hiérarchiquement. Les
observations, les intentions et le raisonnement médicaux peuvent avoir une structure simple ou plus complexe.
Ces éléments, figurant généralement sous des en-têtes, sont contenus dans des «documents» comme les
notes de consultation, les lettres et les comptes rendus. Ces documents sont habituellement rangés dans des
classeurs; plusieurs classeurs peuvent concerner un patient au sein d’une même structure de soins (par
exemple, un classeur pour la médecine, un classeur pour les soins infirmiers et un autre pour l'obstétrique).
Le modèle de référence de l’extrait de DIS doit refléter cette structure et cette organisation hiérarchiques,
satisfaire aux exigences publiées afin d’être fidèle au contexte médical original et garantir que la signification
est conservée lorsque les dossiers sont échangés entre des systèmes médicaux hétérogènes. Pour ce faire,
le modèle décompose de manière formelle la hiérarchie du DIS en parties dont il a été constaté qu'elles
pouvaient assurer une mise en correspondance cohérente avec la manière dont des DIS individuels sont
organisés dans des systèmes de DIS hétérogènes.
Ces parties sont résumées dans le Tableau 1.
viii © ISO 2008 – Tous droits réservés

Tableau 1— Principaux composants hiérarchiques du Modèle de référence de l'extrait de DIS
Composant
hiérarchique DU
Description Exemples
DIS
EHR_EXTRACT Le conteneur au plus haut niveau de tout ou Sans objet
partie du DIS d’un seul sujet de soins,
destiné à la communication entre un
Système émetteur de DIS et un Système
destinataire de DIS.
FOLDER Organisation de haut niveau à l'intérieur Traitement du diabète, Schizophrénie,
d'un DIS, le divisant en compartiments Cholécystectomie, Pédiatrie, Hôpital Saint
relatifs aux soins dispensés pour une seule Michel, Classeur MG, Épisodes 2000-2001,
affection par une équipe ou un Italie
établissement de santé, ou au cours d'une
période de temps définie, telle que, par
exemple, un épisode de soins.
COMPOSITION L’ensemble d’informations consigné dans un Note d'évolution, formulaire de résultat
DIS par un agent, suite à une seule d’essai de laboratoire, compte-rendu
rencontre médicale ou séance de radiologique, demande de consultation,
documentation de dossier. consultation, lettre d'adressage, lettre de
sortie, évaluation de l’état fonctionnel, bilan
de diabète
SECTION Données de DIS dans une COMPOSITION Motif de la rencontre, Antécédents,
appartenant à un en-tête médical, reflétant Antécédents familiaux, indication
généralement le flux d’informations d’allergies, symptômes subjectifs,
collectées au cours d’une rencontre constatations objectives, Analyse, Plan,
médicale, ou structurées pour en faciliter la Traitement, Régime, Posture, Examen
lecture ultérieure par l'œil humain. abdominal, Examen rétinien
ENTRY Les informations enregistrées dans un DIS Un symptôme, une observation, un résultat
suite à un acte médical, une observation, d’essai, un médicament prescrit, une
une interprétation médicale, ou une réaction allergique, un diagnostic, un
intention. Également désigné par le vocable diagnostic différentiel, formule leucocytaire,
«donnée de consultation». mesure de la pression artérielle
CLUSTER Moyen permettant d’organiser des Résultats d’audiogramme, interprétation
structures de données multiples emboîtées d’électroencéphalogramme, diagnostics
telle une série chronologique, et de différentiels comparatifs
représenter les colonnes d’un tableau.
ELEMENT La ramification distale de la hiérarchie de Pression artérielle systolique, pouls, nom
DIS, contenant une seule valeur de donnée. du médicament, symptôme, poids corporel
Un EHR_EXTRACT contient des données de DIS de COMPOSITION, facultativement organisées selon une
hiérarchie FOLDER.
Les COMPOSITION contiennent des ENTRY, facultativement contenues dans une hiérarchie SECTION.
Les ENTRY contiennent des ELEMENTS, facultativement contenus dans une hiérarchie CLUSTER.
Figure 1 — Diagramme de la hiérarchie d'Extrait de DIS (partie 1)

Figure 2 — Diagramme de la hiérarchie d'Extrait de DIS (partie 2)
x © ISO 2008 – Tous droits réservés

0.6 Description des classes principales du Modèle de référence
EHR_EXTRACT
L’EHR_EXTRACT sert à représenter une partie ou l’intégralité des informations contenues dans les dossiers
de santé extraites d’un système émetteur de DIS, en vue d’être communiquées à un processus destinataire
de DIS (qui peut être un autre système de DIS, un réceptacle de données, une application cliente ou un
service intergiciel tel qu’un moteur de recommandations électronique). Il permet aussi une intégration fidèle
des données communiquées dans le système destinataire.
La classe EHR_EXTRACT contient des attributs permettant d’identifiant le sujet de soins rattaché à ce dossier,
le système émetteur de DIS duquel le dossier a été extrait et l’identifiant du DIS de ce sujet dans le système
en question, et, le cas échéant, la partie responsable de sa création.
L’EHR_EXTRACT classe les données du DIS dans trois parties distinctes:
1) un ensemble de COMPOSITIONs;
2) facultativement, un répertoire de FOLDER (classeurs) qui permet le regroupement et l’organisation des
COMPOSITIONs à un niveau élevé;
3) facultativement, un ensemble de descripteurs démographiques pour chacun des composants associés
aux personnes, organisations, dispositifs ou logiciels identifiés aux alinéas (1) et (2) ci-dessus. Cette
approche permet à de telles entités d’être référencées de manière univoque par un identifiant dans le
corps du DIS, sans redondance des détails descriptifs. Elle garantit également que tout EHR_EXTRACT
peut être interprété isolément, si le système destinataire n’a pas accès aux services nécessaires au
décodage des identifiants employés par l'Émetteur de DIS.
Un mécanisme formel est défini dans l'ISO 13606-4 pour intégrer des informations sur les politiques d’accès
au sein de l’EHR_EXTRACT. Ceci permet d’informer le Système destinataire de DIS quant aux souhaits du
sujet de soins et des prestataires de soins relativement à la manière dont il convient de gérer les données lors
de futures demandes d’accès.
L'EHR_EXTRACT contient également un résumé des critères de filtrage ou de sélection selon lesquels cet
EHR_EXTRACT a été créé. Ces éléments peuvent ou non correspondre directement aux critères spécifiés
dans l’EHR_Request (Demande_de_DIS), et ils fournissent un enregistrement du type de sous-ensemble que
constitue cet EHR_EXTRACT par rapport à la totalité du DIS, conservé par l’Émetteur_de_DIS. Ceci peut
revêtir une importance particulière si l’EHR_EXTRACT est laissé tel quel par l’Émetteur de DIS ou le Système
destinataire de DIS et que, par conséquent, certains agents peuvent y avoir accès alors qu’ils ne sont pas
autorisés à accéder à la Demande de DIS originale. Par exemple, cette classe peut spécifier si cet
EHR_EXTRACT est limité à la version la plus récente de chaque COMPOSITION (tel que requis aux fins de
la plupart des soins médicaux) ou s’il comprend toutes les versions précédentes (susceptibles d’être requises
à des fins juridiques). Elle peut spécifier le niveau maximal de sensibilité des données (impliquant que des
données présentant un niveau de sensibilité supérieur au niveau indiqué peuvent exister et qu’elles ont été
filtrées), ou indiquer que les objets multimédia ont été exclus pour limiter sa taille totale. Si l’EHR_EXTRACT a
été créé en sélectionnant des catégories particulières de données médicales (par exemple, uniquement des
données de laboratoires), ceci peut être indiqué au moyen d’une liste des archétypes déjà inclus dans les
critères de sélection. Il est également possible d’inclure des critères supplémentaires (exprimés sous forme
de chaînes de caractères) et de les utiliser pour fournir, pour cet EHR_EXTRACT, des informations
supplémentaires lisibles en texte clair ou pour fournir des informations de contrainte convenues au niveau
local sous forme interprétables par ordinateur.
RECORD_COMPONENT
Les classes principales de brique de base utilisées pour construire la hiérarchie de données de DIS au sein
d'un EHR_EXTRACT sont des types de RECORD_COMPONENT. Il s'agit d'une classe abstraite qui est la
super-classe de tous les nœuds concrets au sein de la hiérarchie du DIS: FOLDER, COMPOSITION,
SECTION, ENTRY, CLUSTER, ELEMENT, et pour les deux nœuds de classes abstraites: CONTENT et ITEM.
RECORD_COMPONENT définit les propriétés d'information communes à toutes ces briques de base, y
compris:
 l’identifiant unique créé pour ce nœud de DIS par le Système de DIS dans lequel il avait été consigné en
premier lieu (son Système émetteur de DIS); les autres détenteurs de ce RECORD_COMPONENT
doivent conserver cette valeur d’attribut pour garantir que tout extrait ultérieur sera toujours identifié de
manière cohérente;
 la dénomination médicale utilisée dans le système émetteur de DIS d'origine pour étiqueter cette partie
des données de DIS;
 facultativement, un concept codé standardisé avec lequel la dénomination a été mise en correspondance
pour permettre l'interopérabilité sémantique d'instances de DIS équivalentes, même si celles-ci ont reçu
des dénominations médicales différentes de divers systèmes de DIS;
 l’identifiant du nœud d’archétype auquel se conforme ce RECORD_COMPONENT, que doivent utiliser
les Systèmes de DIS permettant l'usage d'archétypes ou si les archétypes ont été utilisés lors de la mise
en correspondance des données au format du EHR_EXTRACT format;
 le code de sensibilité et les références aux politiques de contrôle d’accès qu’il convient que le système
destinataire de DIS utilise généralement pour régir l'accès ultérieur aux données;
 la prise en charge de Liens entre les Composants de dossiers.
Lors de la génération d’un EHR_EXTRACT conforme à la présente partie de l'ISO 13606, le système
émetteur de DIS peut, dans certaines situations, nécessiter l’introduction d’un RECORD_COMPONENT dans
la hiérarchie, sans aucune correspondance directe avec les données d’origine du système de DIS. L’attribut
«synthesised» de RECORD_COMPONENT permet au système émetteur de DIS réalisant l’exportation
d’indiquer qu’un RECORD_COMPONENT a été créé à cette fin dans l’EHR_EXTRACT.
Les entrées du dossier de santé renvoient souvent à d’autres entrées préexistantes, qu’elles incluent en tant
que «copies». Le compte rendu d’hospitalisation en constitue un exemple fréquent; il peut inclure des copies
de diverses parties d’un dossier de séjour d’un malade hospitalisé, telles que les circonstances de l’admission,
les diagnostics, interventions et traitements principaux. Dans la plupart des cas, il est nécessaire que
l’EHR_EXTRACT contienne les RECORD_COMPONENT auxquels les entrées font référence sous la forme
explicite de valeurs de données afin de permettre au Système destinataire de DIS d'interpréter chaque
COMPOSITION. Toutefois, pour des raisons médico-légales, il est important de communiquer le fait que ces
entrées sont des copies et qu’elles proviennent d’une partie différente du DIS du patient en question. L’attribut
facultatif original_parent_ref peut être employé pour représenter le rc_id du parent RECORD_COMPONENT
d’origine lorsque les données sont des copies.
Tout RECORD_COMPONENT peut comprendre des données d'audit relatives au moment et à la personne
chargée de sa consignation dans son système émetteur de DIS d'origine. Chaque version révisée d’un
RECORD_COMPONENT peut comporter l’état de la révision, le motif de la révision et l’ID de la version
précédente. Cependant, conformément aux exigences en matière de protection des données, il est
recommandé de ne pas communiquer les versions antérieures (erronées) des composants dans le cadre du
partage des soins habituel mais de ne les communiquer que lorsqu’un transfert de DIS est effectué pour des
raisons légales.
xii © ISO 2008 – Tous droits réservés

Il est important que, dans plusieurs EHR_EXTRACTS, chaque RECORD_COMPONENT soit identifié de
manière univoque et cohérente, de sorte que les références faites ou échangées entre eux restent valides.
Exemples de références de ce type: liens sémantiques, révision et attestation. L’attribut rc_id, du type de
données Identifiant d’instance (II), intègre un OID ISO. Il est aujourd'hui considéré au niveau international
comme le type de données le plus approprié aux identifiants permanents devant être universellement uniques.
Il est peu probable que les systèmes de DIS actuels disposeront de clés primaires ou d’identifiants internes
existants susceptibles de correspondre aux instances II universellement uniques. Cependant, un Système
émetteur de DIS créé avec un OID organisationnel pourrait utiliser ses propres références internes pour
construire des extensions locales uniques vis à vis de l’OID considéré et de ce fait construire des valeurs de
rc_id universellement uniques. Il pourrait également créer des rc_ids totalement nouveaux et conserver un
enregistrement de leur mise en correspondance avec chaque identifiant interne, de sorte que tout
EHR_EXTRACT ultérieur qu’il génère utilise des valeurs de rc_id cohérentes. Il est également peu probable
qu’un Système destinataire de DIS soit en mesure d’utiliser les valeurs de rc_id reçues comme clés primaires
internes pour les données, étant donné que chaque base de données utilise une approche légèrement
différente pour générer et utiliser ces clés. Par conséquent, le Système destinataire de DIS pourrait
également nécessiter de conserver un enregistrement de la mise en correspondance des valeurs de rc_id
importées avec ses propres clés primaires, de sorte que les références ultérieures à ces
RECORD_COMPONENT puissent être ajustées de manière appropriée, avec la possibilité de créer des
EHR_EXTRACT capables de réappliquer ces valeurs de rc_id aux données exportées. Une autre approche
consiste à ce que les Systèmes de DIS conservent de manière explicite les valeurs de rc_id avec les données
médicales, et les traitent dans le cadre du «contenu signifiant» des données sans tenter de les utiliser
également comme clés primaires. Il convient également de noter que le rc_id ne fonctionne pas comme un
équivalent de clé primaire dans un EHR_EXTRACT, c'est-à-dire qu'il est admis de dupliquer des valeurs de
rc_id si chaque instance renvoie effectivement aux mêmes données médicales dans le Système émetteur de
DIS.
FOLDER
Cette classe sert à représenter les organisations au niveau le plus élevé de l’EHR_EXTRACT, par exemple
pour regrouper des parties du dossier par épisode, équipe de soins, spécialité médicale, état clinique ou
intervalle de temps. Au niveau international, ce type de structure d’organisation est utilisé de façon diverse:
dans certaines organisations et certains systèmes, le Classeur est traité comme un compartimentage informel
du dossier de santé global; dans d’autres, il peut représenter une partie juridique importante du DIS en
rapport avec la structure ou l’équipe de soins.
Dans l'EHR_EXTRACT, les FOLDERs font partie d’une hiérarchie facultative. Ils peuvent contenir d’autres
FOLDERs pour former un système de répertoire complet; ils peuvent inclure des informations pertinentes
relatives à leur consignation ou révision dans le Système émetteur de DIS. Les FOLDERs renvoient aux
COMPOSITION par une liste d'identifiants uniques, plutôt qu'en les contenant physiquement. Ceci permet à
toute COMPOSITION de figurer dans plusieurs FOLDERs, exigence que certains éditeurs et législations ont
spécifiée.
Dans certains cas, les FOLDERs peuvent être créés uniquement dans le but d’organiser l’EHR_EXTRACT ou
ne contenir qu’un sous-ensemble défini des données du Classeur correspondant dans le système émetteur
de DIS. Dans de telles circonstances, les FOLDERs de l’EHR_EXTRACT ne correspondent pas directement à
ceux figurant dans le système émetteur de DIS, c'est-à-dire qu'ils ont été synthétisés.
Un FOLDER peut être utilisé pour regrouper un ensemble de COMPOSITIONs comprenant les
enregistrements constitués individuellement par les membres d’une équipe pluridisciplinaire lors d’une
rencontre médicale unique. Dans les situations où un FOLDER représente un intervalle fini de soins, il peut
faire l’objet d’une attestation. Il convient d’utiliser cette approche pour communiquer le fait que le contenu de
ce FOLDER est un enregistrement complet de cet intervalle de soins. Cela permet également d’indiquer au
destinataire du DIS qu’il est déconseillé d’ajouter des COMPOSITIONs supplémentaires à ce FOLDER.
Dans la mesure où les systèmes de classeurs sont utilisés de manière différente dans les Systèmes de DIS,
la présente Norme internationale ne peut pas spécifier la manière dont il convient de les traiter dans les
systèmes destinataire de DIS: c'est-à-dire qu'elle n'exige pas que le système destinataire de DIS les utilise de
manière explicite dans son système de DIS. Cependant, si un FOLDER a été attesté, une copie intacte de
cette information doit être conservée pour pouvoir y faire référence à l'avenir ou pour d'éventuelles nouvelles
communications.
COMPOSITION
La COMPOSITION représente l’ensemble de RECORD_COMPONENT composés (créés) lors d’une séance
clinique d’un utilisateur ou d’une interaction avec un dossier, aux fins de consignation dans un DIS. Les
exemples les plus courants sont les éléments suivants: une note de consultation, une note d’évolution, un
rapport ou une lettre, un rapport d'examen, une ordonnance et un ensemble d’observations infirmières au lit
du malade. La COMPOSITION documente la date et l'heure ou l'intervalle de la rencontre médicale, et le
cadre juridique dans lequel les dossiers ont été composés.
Le compositeur est l'agent (partie, dispositif ou logiciel) en charge de la création, de la synthèse et de
l’organisation des informations consignées dans un DIS. Cet agent prend la responsabilité d’intégrer ces
informations dans le DIS, même s’il n’en est ni l'émetteur, ni même le consignateur. Le contenu de cette
COMPOSITION est attribué en priorité à cette personne. Le changement ou non de compositeur en cas de
révision est facultatif. Les applications utilisent généralement le nom du compositeur pour l’étiquetage des
données de COMPOSITION utilisées en soins médicaux. Dans certains cas, il peut ne pas exister de
compositeur principal unique (par exemple lors d'une téléconsultation professionnelle multiple ou d'une
réunion de concertation), auquel cas le rôle du compositeur peut ne pas être spécifié de manière formelle,
même si chaque participant et chaque rôle médical est déclaré. Le compositeur reste par conséquent
facultatif.
Il est prévu qu’une COMPOSITION puisse comprendre des informations provenant de ou générées par
d’autres participants à la rencontre ou à l'interaction avec le dossier. Certains d'entre eux peuvent avoir
participé depuis différents endroits (par exemple au téléphone, ou par vidéo-consultation).
La COMPOSITION représente la classe conteneur principale pour les données du DIS figurant dans l’extrait
permettant de garantir l'utilisation d'une hiérarchie d'emboîtement cohérente dans tous les Extraits:
l’EHR_EXTRACT contient un ensemble de COMPOSITIONs associées aux données d'audit sur chaque
consignation dans le système émetteur de DIS. Une COMPOSITION est toujours utilisée pour communiquer
des mises à jour de version entre les Systèmes de DIS, même si les mises à jour réelles font référence à des
parties de la COMPOSITION considérée. Si plusieurs versions de données de DIS doivent être
communiquées au sein d'un seul EHR_EXTRACT, il s'agira d'un ensemble de COMPOSITIONs séparées,
chacune renvoyant à titre individuel à la version précédente et à titre collectif faisant référence à un identifiant
d'ensemble de versions.
Chaque COMPOSITION documente également, de manière facultative, toutes attestations (par exemple
signatures numériques) lui appartenant ou appartenant à l'un de ses contenus.
Contribution La Contribution est un ensemble de COMPOSITIONs consignées, à un moment donné, par un
utilisateur dans le DIS d’un sujet de soins. Certaines applications médicales comportent des écrans
complexes permettant de présenter simultanément plusieurs parties d’un DIS (au moyen d'onglets, par
exemple). En sauvegardant l’écran, un utilisateur peut en fait consigner des données dans plusieurs parties
du DIS du patient (par exemple, en ajoutant une nouvelle note de consultation ou en effectuant une correction
dans une entrée relative au traitement médicamenteux conservée dans une autre partie du DIS). La
Contribution se réfère à tous les changements et mises à jour consignés dans ce DIS durant la session du
consignateur. Toutes les COMPOSITIONs comprenant une Contribution peuvent être identifiées
collectivement en fournissant une valeur commune à l'attribut contribution_id.
xiv © ISO 2008 – Tous droits réservés

SECTION
Les entrées du dossier liées à une séance médicale unique sont généralement regroupées sous des en-têtes
représentant des phases ou des sous-thèmes de la rencontre ou facilitant la présentation et la navigation. En
général, les en-têtes cliniques reflètent le déroulement des tâches médicales au cours d’une séance de soins;
ils peuvent également refléter les principaux processus de raisonnement de l’auteur. De nombreuses
recherches ont démontré que les en-têtes sont utilisés différemment par les divers groupes et spécialités
professionnels et qu’ils ne sont en général pas employés de manière assez cohérente pour permettre un
traitement automatique et fiable des DIS. En conséquence, ils sont traités comme un emboîtement facultatif
(informel) dans la présente partie de l'ISO 13606 pour faciliter la navigation, le filtrage et la lisibilité par l'œil
humain.
Les SECTIONs peuvent servir à représenter l'emboîtement hiérarchique des en-têtes médicaux utilisés dans
le système émetteur de DIS pour regrouper et classer les entrées d’une COMPOSITION. Les SECTIONs
peuvent contenir d'autres SECTIONs et/ou ENTRYs.
ENTRY
La classe ENTRY contient (en tant qu’ITEM) les informations acquises et enregistrées pour une seule
observation ou un ensemble d’observations (batterie ou série chronologique), une seule constatation clinique
telle qu’une partie des antécédents médicaux du patient, une déduction ou assertion, une action unique
prévue ou réellement effectuée. La classe ENTRY associe cette structure ITEM à un ensemble d’attributs de
contexte de façon à faciliter une interprétation correcte:
 les informations contenues dans une ENTRY peuvent concerner une personne différente du patient (par
exemple un parent): l'ENTRY définit l'objet de l'information;
 les informations contenues dans une ENTRY peuvent avoir été fournies par ou sont attribuées à une
personne
...