ISO 13606-1:2019

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

This document specifies a means for communicating part or all of the electronic health record (EHR) of one or more identified subjects of care between EHR systems, or between EHR systems and a centralised EHR data repository. It can also be used for EHR communication between an EHR system or repository and clinical applications or middleware components (such as decision support components), or personal health applications and devices, that need to access or provide EHR data, or as the representation of EHR data within a distributed (federated) record system. This document will predominantly be used to support the direct care given to identifiable individuals or self-care by individuals themselves, or to support population monitoring systems such as disease registries and public health surveillance. Uses 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 this document but such secondary uses might also find the document useful. This Part 1 of the multipart series is an Information Viewpoint specification as defined by the Open Distributed Processing ? Reference model: Overview (ISO/IEC 10746-1). This document is not intended to specify the internal architecture or database design of EHR systems.

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

Le présent document spécifie un moyen de communication de tout ou partie du dossier de santé informatisé (DSI) d'un seul ou de plusieurs sujets des soins identifiés entre systèmes de DSI, ou entre des systèmes de DSI et un référentiel de données de DSI centralisé. Il peut également être utilisé pour la communication de DSI entre un système ou référentiel de DSI et des applications médicales ou composants intergiciels (tels que des composants d'aide à la prise de décision) ou des applications et appareils de santé personnels nécessitant d'avoir accès aux ou de fournir des données de DSI, ou pour la représentation des données de DSI dans un système réparti (fédéré). Le présent document est destiné à être principalement utilisé pour prendre en charge les soins directs dispensés à des personnes identifiables ou les soins auto-administrés par les personnes elles-mêmes, 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'anonymisation ou l'agrégation de dossiers individuels de personnes physiques ne constitue pas l'objet du présent document; néanmoins, ces applications secondaires sont susceptibles de trouver un intérêt à ce document. La présente Partie 1 de la série en plusieurs parties est une spécification de point de vue d'information telle que définie par le Traitement réparti ouvert — Modèle de référence: Aperçu général (ISO/IEC 10746-1). Le présent document n'a pas pour vocation de spécifier l'architecture interne ou la conception de la base de données des systèmes de DSI.

General Information

• Status: Published
• Publication Date: 06-Jun-2019
• 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: 9092 - International Standard to be revised
• Start Date: 15-Jan-2025
• Completion Date: 13-Dec-2025

Relations

• Consolidates: ISO/PRF 17296-1 - Additive manufacturing - General principles - Part 1: Terminology
• Effective Date: 06-Jun-2022
• Revises: ISO 13606-1:2008 - Health informatics - Electronic health record communication - Part 1: Reference model
• Effective Date: 04-Nov-2015

Overview

ISO 13606-1:2019 - Health informatics: Electronic health record communication - Part 1: Reference model defines an interoperable reference model for communicating part or all of an electronic health record (EHR) between systems or between systems and a centralized EHR repository. It is an Information Viewpoint specification (per the Open Distributed Processing reference model - ISO/IEC 10746‑1) and is explicitly not a prescription of internal architecture or database design. The standard supports direct clinical care, self‑care, and population monitoring (e.g., disease registries, public health surveillance); secondary uses (research, audit) may also benefit from the model.

Key topics and technical requirements

The document focuses on an information model and key concepts needed for accurate, auditable EHR exchange:

• Actors and roles: representation of people and systems involved in care and documentation (composer, committer, subject of care, information provider).
• Common record component properties: definitions for base, record and structure components used across EHR content.
• Attestation and audit: metadata and requirements for attestation, provenance and audit trails to ensure trust and legal acceptability.
• Linking and references: mechanisms to link record components and to communicate referenced components or external links.
• Data types and element values: standardized datatypes (strings, coded values, quantities, dates/times, identifiers, attachments) and rules for data values.
• EHR components: canonical building blocks such as folders, compositions, content/sections, entries, items, clusters and elements.
• EHR and demographic extracts: how to package and exchange extracts of clinical and demographic information.
• Conformance: guidance on compliance with the reference model and informative annexes (e.g., ISO 21090 datatype profiling, alignment with HL7 FHIR).

Practical applications and who uses it

ISO 13606-1 is used by:

• EHR vendors and system integrators to design interoperable exchange formats and APIs that preserve provenance and structure.
• Healthcare IT architects implementing federated EHR systems, or centralized repositories and clinical middleware (decision support, CDS).
• Clinical application developers and personal health app makers needing to access or provide structured EHR data.
• Health information exchanges (HIEs) and public health agencies for standardized extract formats.
• Secondary stakeholders (researchers, auditors) may use the model where structured, de‑identified extracts are required.

Related standards

• ISO 13606 (multipart series) - Part 1 is the Reference model.
• ISO/IEC 10746-1 - Open Distributed Processing (Information Viewpoint).
• ISO 21090 - datatype profiles (informative annex).
• HL7 FHIR - alignment and mapping considerations (informative annex).

Keywords: ISO 13606-1:2019, EHR communication, reference model, health informatics, interoperability, EHR extract, audit, attestation, FHIR.

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 13606-1
Second edition
2019-06
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 2019
© ISO 2019
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Fax: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii © ISO 2019 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
3.1 Actors . 1
3.2 Concepts and terms . 3
3.3 Information management . 3
3.4 Privacy and security . 5
3.5 Process management . 6
4 Abbreviations. 6
5 Overview . 7
5.1 Overview of the reference model . 7
5.2 Representing roles and responsibilities within the EHR _EXTRACT. 8
5.2.1 General. 8
5.2.2 Actors playing a role in the actual healthcare process . 8
5.2.3 Actors contributing to the process of documenting care within the EHR . 8
5.2.4 Actors confirming the validity of the EHR documentation . 8
5.2.5 Subject of care . 9
5.2.6 Composer . 9
5.2.7 Committer .10
5.2.8 Subject of information . .10
5.2.9 Information provider .10
5.3 About the use of datatypes in this document .10
6 Common Properties of Record Components .11
6.1 Base, record and structure components .11
6.1.1 General.11
6.1.2 Base component .13
6.1.3 Electronic health record component .14
6.1.4 Structure component .15
6.2 Attestation.16
6.2.1 General.16
6.2.2 Attestation information .18
6.3 Audit information .19
6.4 Linking record components .22
6.4.1 General.22
6.4.2 Link usages .22
6.4.3 Communicating referenced record components .24
6.4.4 Link .24
6.4.5 External link .25
7 Elements and Data Values .26
7.1 General .26
7.2 Data value .27
7.2.1 Boolean .29
7.2.2 Attachment .29
7.2.3 String .32
7.2.4 Simple text .33
7.2.5 Coded simple value .33
7.2.6 Coded value .34
7.2.7 Instance identifier . .37
7.2.8 URI .39
7.2.9 Physical quantity.40
7.2.10 Duration.41
7.2.11 Real .42
7.2.12 Integer .43
7.2.13 Date time .43
7.2.14 Date .44
7.2.15 Time .45
7.2.16 Point in time .45
8 EHR Components .46
8.1 General .46
8.2 Folder .47
8.2.1 General.47
8.2.2 Folder .48
8.3 Compositions .49
8.3.1 General.49
8.3.2 Composition .50
8.4 Content and sections .51
8.4.1 General.51
8.4.2 Content .51
8.4.3 Section.52
8.5 Entries .53
8.5.1 General.53
8.5.2 Entry .53
8.6 Items and clusters .55
8.6.1 Item .55
8.6.2 Cluster .56
8.7 Element.57
9 EHR Extract .57
9.1 General .57
9.2 EHR extract.58
9.3 Extracted component set .59
9.4 Demographic extract .60
10 Demographics .61
10.1 General .61
10.2 Demographic folder .62
10.3 Demographic entity .63
10.4 Demographic item .64
10.5 Demographic cluster .65
10.6 Demographic element .66
11 Conformance .67
Annex A (informative) About the ISO 21090:2011 profile for datatypes .68
Annex B (informative) Alignment with HL7 FHIR .72
Annex C (informative) Cross-Domain Interoperability .73
Bibliography .78
iv © ISO 2019 – All rights reserved

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.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/directives).
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. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso
.org/iso/foreword .html.
This document was prepared by Technical Committee ISO/TC 215, Health Informatics.
This second edition cancels and replaces the first edition (ISO 13606-1:2008), which has been technically
revised. The main changes compared to the previous edition are summarised in the Introduction.
A list of all parts in the ISO 13606 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
Introduction
0.1  Preface
The overall goal of this document 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),
or for a group of patients whose information might need to be communicated together (for example, a
family). This is to support the interoperability of systems (see Annex C). and components that need to
communicate (access, transfer, add or modify) EHR data:
— preserving the original clinical meaning intended by the author;
— incorporating the necessary provenance metadata to inform the recipient or receiving system about
the context in which the EHR data were obtained and composed;
— observing and communicating the confidentiality of that data as intended by the author and subject
of care.
This document considers the EHR to be the persistent longitudinal and potentially multi-organisation
or multi-national record of health and care provision, most often relating to a single subject of care (the
patient), created and stored in one or more physical systems in order to inform each subject’s future
healthcare and to provide a medico-legal record of care that has been provided. This corresponds to the
definition provided in ISO 18308:2011 (Requirements for an Electronic Health Record Architecture).
This document 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 applications that might request 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. These might be used to communicate EHR data between
two repositories, to update a centralised regional or national EHR repository, or within a distributed
network of EHR components, systems and services. 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. this document 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.
This document 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. The components that might support an interface conforming to this
document will be not only electronic health record systems but also other middleware services such as
security components, guideline and workflow systems, alerting and decision support services, personal
health systems and applications, sensors and wearable devices, and medical knowledge management
services. This document might also prove useful for communicating data about individuals between
electronic health record systems and population registries, and also for conducting (approved) research
using electronic health records.
This document is part of a five-part standard series, published jointly by CEN and ISO through the
Vienna Agreement.
In this document dependency upon any of the other parts of this series is explicitly stated where it
applies.
0.2  Technical approach
This document is the second version of an original standard which was published in 2007 by CEN, and
in 2008 by ISO. This revision has taken into account the experiences gained by EHR system developers
and by large scale eHealth programmes from using the original standard. These were ascertained
through an international survey, a wide range of 1:1 interviews, a review of the academic literature,
and interactions with many experts active in R&D relating to the EHR. It also meets the relevant
requirements in ISO 18308:2011 (Requirements for an Electronic Health Record Architecture). The
vi © ISO 2019 – All rights reserved

revision has taken into account, and aligns as far as possible, with other CEN and ISO Standards and
Technical Specifications with which this document might also be used, with international terminology
standards and with emerging standards from HL7: Fast Healthcare Interoperability Resources (FHIR).
The specifications in this document have drawn from, and align as far as possible with, the reference
model specifications published by the openEHR Foundation, and with the archetype models published
by the openEHR Foundation and by the Clinical Information Modeling Initiative (CIMI).
The information model in this document is an Information Viewpoint of the ISO Reference Model for
Open Distributed Processing (ISO/IEC 10746-1:1998).
Given the diversity of deployed EHR systems, this document 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 of this series, and through normative term
lists (defined in Part 3 of this series).
0.3  The Dual Model approach
The challenge for EHR interoperability is to devise a generalised 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 healthcare 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 this standard series distinguishes a Reference Model, defined in this document
and used to represent the generic properties of health record information, and Archetypes (conforming
to an Archetype Model, defined in Part 2 of this series), which are meta-data used to define patterns for
the specific characteristics of the healthcare data that represents 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 of this series).
This generic information model needs to be complemented by a formal method of communicating and
sharing the organisational structure of predefined classes of EHR fragment corresponding to sets
of record components made in particular clinical situations. These are effectively pre-coordinated
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 organisations. 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 document,
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.
This document recognises that archetypes (or equivalent clinical models) are not always directly
incorporated within the present-day architectures of electronic health record systems. This document
therefore does not mandate that archetypes are used within such systems. It does, however, require
that the clinical information models or equivalents (data items, data item aggregations, data value
constraints, terminology bindings, units of measure etc.) that have been used to generate an EHR_
EXTRACT are themselves created and communicated, or referenced, within each EHR_EXTRACT. These
communicated or referenced archetypes have to conform to Part 2 of this standard series, and maybe
communicated through an interface conforming to part 5 of this Standard series.
0.4 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 organised under headings,
and contained in “documents” such as consultation notes, letters and reports. These documents
are usually filed in folders, and a subject of care may have more than one folder within a healthcare
enterprise (e.g. medical, nursing, and obstetric).
The EHR Communications Reference Model needs to reflect this hierarchical structure and organisation,
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 organised within heterogeneous EHR
systems.
These parts are summarised in Table 1 below.
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 or for a group
of subjects of care (such as a family), for com-
munication between an EHR Provider system
and an EHR Recipient.
FOLDER The high level organisation within an EHR, Diabetes care, Schizophrenia, Chole-
dividing it into compartments relating to care cystectomy, Paediatrics, St Mungo’s
provided to a single subject of care, for a sin- Hospital, GP Folder, Episodes 2000-
gle condition, by a clinical team or institution, 2001.
or over a fixed time period such as an episode
of care.
COMPOSITION The set of information committed to one EHR Progress note, Laboratory test result
by one agent, as a result of a single clinical form, Radiology report, Referral let-
encounter or record documentation session. ter, Clinic visit, Clinic letter, Discharge
summary, Functional health assess-
ment, Diabetes review.
SECTION EHR data within a COMPOSITION that Reason for encounter, Past history,
belongs under one clinical heading, usually Family history, Allergy information,
reflecting the flow of information gathering Subjective symptoms, Objective find-
during a clinical encounter, or structured for ings, Analysis, Plan, Treatment, Diet,
the benefit of future human readership. Posture, Abdominal examination,
Retinal examination.
ENTRY The information recorded in an EHR as a A symptom, an observation, one test
result of one clinical action, one observation, result, a prescribed drug, an allergy
one clinical interpretation, or an intention. reaction, a diagnosis, a differential
This is also known as a clinical statement. diagnosis, a differential white cell
count, blood pressure measurement.
CLUSTER The means of organising nested multi-part Audiogram results, electro-enceph-
data structures such as time series, and to alogram interpretation, weighted
represent the columns of a table. differential diagnoses.
ELEMENT The leaf node of the EHR hierarchy, contain- Systolic blood pressure, heart rate,
ing a single data value. drug name, symptom, body weight.
An EHR_EXTRACT contains EHR data as COMPOSITIONs, organised in a FOLDER hierarchy.
COMPOSITIONs contain ENTRYs, optionally contained within a SECTION hierarchy.
ENTRYs contain ELEMENTS, optionally contained within a CLUSTER hierarchy.
viii © ISO 2019 – All rights reserved

Representing participation: The Reference Model in the previous version of this standard provided
explicit classes at certain parts of the Record Component hierarchy through which it was possible to
represent the identity and roles played by actors contributing to healthcare and to its documentation.
In this version of the Reference Model the LINK class is intended to be used to reference demographic
entities. The roles played by these entities can be labelled using extended term lists defined in Part 3
of this standard series. This updated mechanism offers greater flexibility than the previous version in
where the references to such democratic entities may be represented within the Record Component
hierarchy.
Representing context: Any EHR_EXTRACT references any other RECORD_COMPONENTS that are
connected to the communicated content, for example via the RECORD_COMPONENT hierarchy and
via LINK targets. If the EHR exchange service (e.g. as specified in Part 5) permits access to referenced
components, any user would be able to access and review any additional areas of content that were not
originally included. (Archetypes bring together the key elements of immediate documentation context.)
Representing authenticity: Every EHR_EXTRACT may contain attested views: these might be PDF or
html or other renderings that are the authentic view of what was seen and persisted by the original
author. The proof may also optionally be included, which is the evidence of a digital signature.
EHR_EXTRACTS are created for specific purposes, and will not automatically guarantee that these will
be fit for other purposes.
0.5 Summary of changes made in this edition of the standard
The scope of all parts remains the same.
The objective of this revision was to:
— obtain implementer feedback on adoption experiences with the published version of the 13606
standard series;
— simplify the reference model by removing properties that have not proved useful to implementers;
— improve the demographics model to support the use of demographic archetypes;
— improve alignment with ISO 13940 System of concepts to support continuity of care (Contsys);
— align the data types with ISO 21090 Harmonized data types for information interchange (see
Annex A);
— prepare the ground for alignment with HL7 FHIR;
— update the archetype model to align with the openEHR Archetype Object Model 2.0;
— include reference archetypes for commonly needed information (e.g. demographics);
— update the audit log model to align with ISO 27789 Audit trails for electronic health records, and the
ISO 22600 series, Privilege management and access control.
Reference Model changes
Base Component
A class Base Component has been introduced higher in the inheritance hierarchy than Record
Component, which has a unique identifier, version history information and attestation information.
This allows all of the structures within an EHR Extract to be version managed and attested, including
LINK and demographic information, as well as the original family of Record Components.
Record Component
Several properties that had not proved useful have been removed from Record Component.
Importantly, the model now semantically labels Record Components through archetype ID, avoiding
duplicating and possibly conflicting semantic labels such as name and meaning.
Experience is that these different properties were not differentially well used, and resulted in
inconsistent practices.
Consultation with vendors and providers who do not intend to use archetypes has confirmed that they
could create a library of archetypes mapping their data structures, should they choose to adopt this
standard series.
Properties relating to sensitivity and policy ID have been moved to Composition, to avoid the risk of a
Composition containing data of mixed policies and therefore inconsistently complete access by different
parties.
Structure Component
A generic parent class Structure Component is now the universal parent class of all Record Components
and demographic classes.
All such classes inherit an archetype ID, which now also importantly allows demographic structures to
be defined through archetypes, which was a popular change request.
EHR_Extract
Extract Criteria has been removed as implementers did not find it useful.
EHR_EXTRACT may now contain a set of extracted EHR components, and so may contain data on
multiple subjects of care.
Folder
The Folder has the property subject of care, which allows an EHR extract potentially to contain
information about more than one subject of care, such as a family, which was an important change
request we received.
The EHR Extract is a kind of folder, with specific meta data about the extract generation.
Composition, Entry and Cluster
Some unused properties have been removed from Composition, Entry and Cluster.
This includes session_time, obs_time. Such dates and times are better included within relevant
archetypes with more precisely specified names and roles.
Element
The Element class, and its counterpart Demographic Element, are more genuinely leaf nodes with fewer
inherited properties and fewer inherited associations than in the past.
This is a response to a number of ICT vendors who indicated that the original Element was too property
rich, inviting inconsistent adoption practice.
Null flavour is no longer an explicit Reference Model property. Instead a Reference Archetype has been
defined in Part 3, to allow null to be asserted not only at Element level but higher up the hierarchy (e.g.
that a Cluster or Entry is not present).
Data Value
The data values are now all represented as a constrained subset of the data types in ISO 21090,
conforming to its mechanism for profiling (see Annex A).
Demographics
x © ISO 2019 – All rights reserved

Rather than being a separate package, demographic entities are represented using classes that inherit
many of the same mechanics as Record Components, simplifying adoption.
This is now also means that demographic entries in a demographic extract can be uniquely identified,
version managed and attested.
It is now much easier to refer specifically to actors within roles at care settings, in cases where actors
play multiple roles and work within different care settings over time, which is relatively common.
Link
The Link class has been simplified, but enriched so that Links have a unique identifier, and can be
versioned and attested.
Links can connect any identified components including demographic entities, which is now the way
that most participations are represented. This was an important and well supported change request, to
correct a less successfully modelled part of the previous standard.
The vocabulary for LINK has been greatly extended within part 3, and where appropriate aligned with
Contsys.
LINKS can continue to be used to represent clinically relevant connections between parts of a record,
point to point or as a linkage thread.
The former class FUNCTIONAL_ROLE and RELATED_PARTY have been removed, as the connection
to demographic entities can now be made through archetyped DEMOGRAPHIC ENTITY instances
connected to the relevant RECORD_COMPONENT via LINK.
A new class EXTERNAL_LINK enables references to be included to non-EHR data such as care protocols,
safety reports or academic publications.
Audit information
The audit info class now aligns with ISO 27789, as does the corresponding audit model in Part 4 of this
standard series.
0.6  Relationship of this standard to other relevant standards
— The data types used in this document are a profile of ISO 21090 Health informatics - Harmonized
data types for information interchange.
— Alignment has especially been undertaken with ISO 13940 Health informatics - System of concepts
to support continuity of care (Contsys). All of the terms and definitions within the standard series
have been harmonised across the five parts, with most of the terms being in Part 1. All of them have
been aligned with Contsys.
— An important 13606 FHIR profile project is in progress within HL7 (see Annex B). No challenges
have been identified with being able to create such a profile. However there are a few areas of
mapping alignment which need further work between ISO 13606 and HL7.
— Parts 1 and 4 align with ISO 27789 Health informatics - Audit trails for electronic health records.
Alignment in Part 4 has been maintained with ISO 22600 Health informatics - Privilege management
and access control.
INTERNATIONAL STANDARD ISO 13606-1:2019(E)
Health informatics — Electronic health record
communication —
Part 1:
Reference model
1 Scope
This document specifies a means for communicating part or all of the electronic health record (EHR)
of one or more identified subjects of care between EHR systems, or between EHR systems and a
centralised EHR data repository.
It can also be used for EHR communication between an EHR system or repository and clinical
applications or middleware components (such as decision support components), or personal health
applications and devices, that need to access or provide EHR data, or as the representation of EHR data
within a distributed (federated) record system.
This document will predominantly be used to support the direct care given to identifiable individuals
or self-care by individuals themselves, or to support population monitoring systems such as disease
registries and public health surveillance. Uses 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 this document
but such secondary uses mig
...

NORME ISO
INTERNATIONALE 13606-1
Deuxième édition
2019-06
Informatique de santé —
Communication du dossier de santé
informatisé —
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 2019
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2019
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, 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, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: [phone]
Fax: [phone]
E-mail: [e-mail]
Web: www.iso.org
Publié en Suisse
ii © ISO 2019 – Tous droits réservés

Sommaire Page
Avant-propos .v
Introduction .vi
1 Domaine d’application . 1
2 Références normatives . 1
3 Termes et définitions . 1
3.1 Acteurs . 2
3.2 Concepts et termes . 3
3.3 Gestion des informations . 3
3.4 Confidentialité et sécurité . 5
3.5 Gestion de processus . 6
4 Abréviations . 6
5 Vue d’ensemble . 7
5.1 Vue d’ensemble du modèle de référence . 7
5.2 Représentation des rôles et responsabilités au sein de l’EHR _EXTRACT . 8
5.2.1 Généralités . 8
5.2.2 Acteurs du processus de soins proprement dit . 9
5.2.3 Acteurs contribuant au processus de documentation des soins dans le DSI . 9
5.2.4 Acteurs confirmant la validité de la documentation du DSI . 9
5.2.5 Sujet des soins . 9
5.2.6 Compositeur .10
5.2.7 Consignateur .11
5.2.8 Objet de l’information .11
5.2.9 Émetteur d’informations .11
5.3 À propos de l’utilisation de types de données dans le présent document .11
6 Propriétés communes des éléments du dossier .12
6.1 Éléments de base, éléments du dossier et éléments de structure .12
6.1.1 Généralités .12
6.1.2 Élément de base.14
6.1.3 Élément du dossier de santé informatisé .16
6.1.4 Élément de structure . .17
6.2 Attestation.18
6.2.1 Généralités .18
6.2.2 Informations d’attestation .19
6.3 Informations d’expertise .21
6.4 Lier les éléments de dossier .23
6.4.1 Généralités .23
6.4.2 Utilisations du lien .24
6.4.3 Communiquer des éléments de dossier référencés . .26
6.4.4 Lien .26
6.4.5 Lien externe.27
7 Éléments et valeurs des données .28
7.1 Généralités .28
7.2 Valeur de données .29
7.2.1 Booléen .30
7.2.2 Pièce jointe .31
7.2.3 Chaîne .33
7.2.4 Texte simple .34
7.2.5 Valeur codée simple .35
7.2.6 Valeur codée.36
7.2.7 Identifiant d’instance .39
7.2.8 URI .41
7.2.9 Quantité physique .42
7.2.10 Durée .43
7.2.11 Réel .44
7.2.12 Entier .45
7.2.13 Date et heure .45
7.2.14 Date .46
7.2.15 Heure .47
7.2.16 Moment .48
8 Éléments du DSI .49
8.1 Généralités .49
8.2 Dossier .50
8.2.1 Généralités .50
8.2.2 Dossier .50
8.3 Compositions .52
8.3.1 Généralités .52
8.3.2 Composition .52
8.4 Contenu et sections .53
8.4.1 Généralités .53
8.4.2 Contenu .54
8.4.3 Section.55
8.5 Entrées .55
8.5.1 Généralités .55
8.5.2 Entrée .56
8.6 Items et grappes.57
8.6.1 Item .57
8.6.2 Grappe .58
8.7 Élément.59
9 Extrait de DSI .60
9.1 Généralités .60
9.2 Extrait de DSI .60
9.3 Ensemble d’éléments extrait .62
9.4 Extrait démographique .62
10 Données démographiques .64
10.1 Généralités .64
10.2 Dossier démographique .65
10.3 Entité démographique .66
10.4 Item démographique .67
10.5 Grappe démographique .68
10.6 Élément démographique .69
11 Conformité .70
Annexe A (informative) À propos des profils de types de données de l’ISO 21090:2011 .71
Annexe B (informative) Alignement sur la norme FHIR HL7 .75
Annexe C (informative) Interopérabilité inter-domaine .76
Bibliographie .81
iv © ISO 2019 – Tous droits réservés

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 (IEC) en ce qui
concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier de prendre note des différents
critères d’approbation requis pour les différents types de documents ISO. Le présent document a été
rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (voir www
.iso .org/directives).
L’attention est attiré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. Les détails concernant
les références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de
l’élaboration du document sont indiqués dans l’Introduction et/ou dans la liste des déclarations de
brevets reçues par l’ISO (voir www .iso .org/brevets).
Les appellations commerciales éventuellement mentionnées dans le présent document sont données
pour information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer un
engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions
spécifiques de l’ISO liés à l’évaluation de la conformité, ou pour toute information au sujet de l’adhésion
de l’ISO aux principes de l’Organisation mondiale du commerce (OMC) concernant les obstacles
techniques au commerce (OTC), voir le lien suivant: www .iso .org/iso/fr/avant -propos.
Le présent document a été élaboré par le comité technique ISO/TC 215, Informatique de santé.
Cette deuxième édition annule et remplace la première édition (ISO 13606-1:2008), qui a fait l’objet
d’une révision technique.
Les principales modifications par rapport à l’édition précédente sont récapitulées dans l’Introduction.
Une liste de toutes les parties de la série ISO 13606 se trouve sur le site web de l’ISO.
Il convient que l’utilisateur adresse tout retour d’information ou toute question concernant le présent
document à l’organisme national de normalisation de son pays. Une liste exhaustive desdits organismes
se trouve à l’adresse www .iso .org/fr/members .html.
Introduction
0.1  Préface
L’objet général du présent document est de définir une architecture d’information rigoureuse et durable
destinée à communiquer tout ou partie du Dossier de Santé Informatisé (DSI) d’un seul sujet des soins
(patient) ou d’un groupe de patients dont les informations peuvent devoir être communiquées ensemble
(par exemple une famille). Le but est de permettre l’interopérabilité des systèmes (voir l’Annexe C) et
des composants nécessitant de transmettre (accès, transfert, ajout ou modification) les données du DSI:
— en préservant le sens médical original que l’auteur a voulu donner;
— en intégrant les nécessaires métadonnées de provenance afin d’informer le destinataire ou le
système destinataire du contexte dans lequel les données du DSI ont été obtenues et composées;
— en respectant et en communiquant la confidentialité des données voulue par l’auteur et le sujet
des soins.
Le présent document considère le DSI comme un enregistrement pérenne et longitudinal de la santé
et des soins prodigués, le plus souvent relatifs à un sujet des soins individuel (le patient), 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
chaque sujet ainsi que, à titre médicolégal, l’enregistrement des soins qui lui ont été dispensés. Cette
définition correspond à celle donnée dans l’ISO 18308:2011 (Exigences relatives à une architecture de
l’enregistrement électronique en matière de santé).
Le présent document n’a pas pour vocation de spécifier l’architecture interne ou la conception de la base
de données des systèmes ou des composants de DSI. Elle n’a pas non plus vocation à définir les types
d’applications médicales susceptibles de demander ou de contribuer à des données de DSI dans des
configurations, domaines ou spécialités en particulier. C’est pourquoi le modèle d’information proposé
ici est nommé extrait de DSI et peut être employé pour définir un message, un document ou un schéma
XML, ou une interface objet. Ceux-ci peuvent être utilisés pour communiquer des données de DSI entre
deux référentiels, pour mettre à jour un référentiel de DSI centralisé régional ou national ou au sein
d’un réseau réparti de composants, systèmes et services de DSI. Tandis qu’un service ou un système de
DSI 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., le présent document n’aborde ces domaines que dans la mesure où une
trace permanente desdites interactions est exigée dans le DSI lui-même, et exige l’établissement de
caractéristiques spécifiques dans le modèle de référence pour permettre leur communication.
Même si le présent document peut apporter une contribution pratique et utile à la conception de systèmes
de DSI, 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. Les composants pouvant
prendre en charge une interface conforme au présent document sont non seulement les systèmes de
dossiers de santé informatisés mais aussi d’autres services intergiciels tels que les composants de
sécurité, les systèmes de recommandations et de déroulement des tâches, les services d’alerte et d’aide
à la décision, les systèmes et applications de santé personnels, les capteurs et les dispositifs portables
et les services de gestion de connaissances médicales. Le présent document peut également se révéler
utile pour communiquer des données relatives à des personnes entre des systèmes de dossiers de santé
informatisés et des registres de populations ainsi que pour mener des recherches (agréées) à l’aide de
dossiers de santé informatisés.
Le présent document fait partie d’une série de normes en cinq parties, publiées conjointement par
le CEN et l’ISO dans le cadre de l’Accord de Vienne.
Dans le présent document, la dépendance à l’une des autres parties de la série est explicitement indiquée
là où elle s’applique.
0.2  Approche technique
vi © ISO 2019 – Tous droits réservés

Le présent document est la seconde version d’une norme originale publiée en 2007 par le CEN et
en 2008 par l’ISO. La présente révision a pris en compte les expériences obtenues par les développeurs
de systèmes de DSI et par les programmes de santé électroniques à grande échelle à partir de
l’utilisation de la norme originale. Ces expériences ont été mises à profit par le biais d’une étude
internationale, d’une large gamme d’entretiens en face à face, d’une revue de la littérature universitaire
et d’interactions avec de nombreux experts actifs en R&D relative au DSI. Le présent document satisfait
également aux exigences pertinentes de l’ISO 18308:2011 (Exigences relatives à une architecture de
l’enregistrement électronique en matière de santé). La révision a tenu compte de et s’aligne le plus
possible sur les autres normes et spécifications techniques du CEN et de l’ISO avec lesquelles le présent
document peut aussi être utilisé, les normes terminologiques internationales et les normes émergentes
de HL7: Fast Healthcare Interoperability Resources (FHIR). Les spécifications du présent document
sont tirées de et s’alignent le plus possible sur les spécifications de modèles de référence publiées par la
Fondation openEHR et sur les modèles d’archétypes publiés par la Fondation openEHR et par la Clinical
Information Modeling Initiative (CIMI).
Le modèle d’information du présent document est un point de vue d’information du modèle de référence
ISO pour un traitement réparti ouvert (ISO/IEC 10746-1:1998).
En raison de la diversité des systèmes de DSI déployés, le présent document considère la plupart des
caractéristiques de la communication de DSI comme facultatives et non obligatoires. Cependant, il est
nécessaire d’exprimer certaines exigences pour qu’un système destinataire de DSI puisse traiter de
manière sûre des extraits de DSI. Cela est reflété par les propriétés obligatoires des modèles spécifiés
dans les Parties 1, 2 et 4 de la série, ainsi que par les listes de termes normatifs (définis dans la Partie 3
de la série).
0.3  L’approche du modèle double
Le défi que représente l’interopérabilité des DSI a été d’élaborer une approche généralisable permettant
de représenter de manière cohérente toutes les sortes imaginables de dossiers 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, ensembles de valeurs, modèles de document, etc. de soins
de santé, exigés 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é.
L’approche adoptée par la présente série de nomes distingue le modèle de référence, défini dans le
présent document et utilisé pour représenter les propriétés génériques des informations du dossier
de santé, et des archétypes (conformes au modèle d’archétype, défini dans la Partie 2 de la présente
série) qui sont des métadonnées servant à représenter les caractéristiques spécifiques de différentes
catégories de données de soins de santé, 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 éléments des dossiers de santé,
leur mode d’agrégation, et les informations contextuelles exigées 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 DSI. Il reflète les caractéristiques stables d’un dossier de santé informatisé et est
prévu pour être imbriqué dans un environnement de DSI réparti (fédéré, par exemple) sous la forme de
messages ou d’interfaces spécifiques (tels que spécifiés dans la Partie 5 de la présente série).
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 DSI correspondant
aux ensembles d’éléments 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 des 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 le présent document, 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.
Le présent document reconnaît que les archétypes (ou les modèles cliniques équivalents) ne sont pas
toujours directement intégrés aux architectures des systèmes de dossiers de santé informatisés actuels.
Le présent document ne rend donc pas obligatoire l’utilisation des archétypes dans ces systèmes. Elle
exige toutefois que les modèles d’information cliniques ou les équivalents (données, agrégations de
données, contraintes de valeur de données, associations terminologiques, unités de mesure, etc.) qui
ont été utilisés pour générer un EHR_EXTRACT soient eux-mêmes créés et communiqués ou référencés
dans chaque EHR_EXTRACT. Ces archétypes communiqués ou référencés doivent être conformes
à la Partie 2 de la présente série de normes et peuvent être communiqués par l’intermédiaire d’une
interface conforme à la Partie 5 de la présente série de normes.
0.4  Présentation générale de la hiérarchie du dossier relatif à EHR_EXTRACT
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 sujet des soins 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 communication de DSI 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 DSI en
parties dont il a été constaté qu’elles pouvaient assurer une mise en correspondance cohérente avec la
manière dont des DSI individuels sont organisés dans des systèmes de DSI hétérogènes.
Ces parties sont résumées dans le Tableau 1 ci-dessous.
Tableau 1 — Principaux éléments hiérarchiques du modèle de référence de l’extrait de DSI
ÉLÉMENT HIÉ- DESCRIPTION EXEMPLES
RARCHIQUE DU
DSI
EHR_EXTRACT Le conteneur au plus haut niveau de tout ou (Sans objet)
partie du DSI d’un seul sujet des soins ou
d’un groupe de sujets des soins (comme une
famille), destiné à la communication entre un
système émetteur de DSI et un système desti-
nataire de DSI.
FOLDER Organisation de haut niveau à l’intérieur Traitement du diabète, Schizophrénie,
d’un DSI, le divisant en compartiments relatifs Cholécystectomie, Pédiatrie, Hôpi-
aux soins dispensés à un seul sujet des soins tal Saint Michel, Classeur MG, Épi-
pour une seule affection par une équipe ou un sodes 2000-2001.
é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 DSI Note d’évolution, formulaire de résultat
par un agent, suite à une seule rencontre médi- d’essai de laboratoire, compte-rendu
cale ou séance de documentation de dossier. radiologique, demande de consultation,
consultation, lettre d’adressage, lettre de
sortie, évaluation de l’état fonctionnel,
bilan de diabète.
viii © ISO 2019 – Tous droits réservés

Tableau 1 (suite)
ÉLÉMENT HIÉ- DESCRIPTION EXEMPLES
RARCHIQUE DU
DSI
SECTION Données de DSI dans une COMPOSITION appar- Motif de la rencontre, Antécédents, Anté-
tenant à un en-tête médical, reflétant générale- cédents familiaux, indication d’allergies,
ment le flux d’informations collectées au cours symptômes subjectifs, constatations
d’une rencontre médicale, ou structurées pour objectives, Analyse, Plan, Traitement,
en faciliter la lecture ultérieure par l’œil humain. Régime, Posture, Examen abdominal,
Examen rétinien.
ENTRY Les informations enregistrées dans un DSI Un symptôme, une observation, un résul-
suite à un acte médical, une observation, une tat d’essai, un médicament spécifié, une
interprétation médicale ou une intention. réaction allergique, un diagnostic, un dia-
Également désigné par le vocable «donnée de gnostic différentiel, formule leucocytaire,
consultation». mesure de la pression artérielle.
CLUSTER Moyen permettant d’organiser des structures Résultats d’audiogramme, interprétation
de données multiples emboîtées telle une série d’électroencéphalogramme, diagnostics
chronologique, et de représenter les colonnes différentiels comparatifs.
d’un tableau.
ELEMENT La ramification distale de la hiérarchie de DSI, Pression artérielle systolique, pouls, nom
contenant une seule valeur de donnée. du médicament, symptôme, poids corporel.
Un EHR_EXTRACT contient des données de DSI de COMPOSITION, organisées selon une hiérarchie
de FOLDER.
Les COMPOSITION contiennent des ENTRY, facultativement contenues dans une hiérarchie SECTION.
Les ENTRY contiennent des ELEMENT, facultativement contenus dans une hiérarchie CLUSTER.
Représentation de la participation: Le modèle de référence de la version précédente de la présente
norme indiquait des classes explicites au niveau de certaines parties de la hiérarchie d’éléments du
dossier, grâce auxquelles il était possible de représenter l’identité et les rôles joués par les acteurs
contribuant aux soins de santé et à leur documentation. Dans la présente version du modèle de
référence, la classe LINK est destinée à être utilisée pour référencer les entités démographiques. Les
rôles joués par ces entités peuvent être étiquetés au moyen des listes de termes étendues définies dans
la Partie 3 de la présente série de normes. Ce mécanisme mis à jour offre une plus grande flexibilité que
la version précédente concernant l’endroit où les références à ces entités démographiques peuvent être
représentées dans la hiérarchie d’éléments du dossier.
Représentation du contexte: Toute référence à l’EHR_EXTRACT autre que les RECORD_COMPONENT
qui sont associés au contenu communiqué, par exemple par le biais de la hiérarchie de RECORD_
COMPONENT et des cibles LINK. Si le service d’échange de DSI (par exemple tel que spécifié dans la
Partie 5) autorise l’accès aux éléments référencés, tout utilisateur est capable d’accéder à et de revoir
toute zone de contenu supplémentaire non incluse à l’origine. (Les archétypes rassemblent les éléments
clés du contexte de documentation immédiat.)
Représentation de l’authenticité: Chaque EHR_EXTRACT peut contenir des vues soumis à essaies:
elles peuvent être en PDF ou html ou d’autres rendus qui constituent la représentation authentique de
ce qui est vu par l’auteur original. La preuve peut également être incluse en option, qui est la preuve
d’une signature numérique.
Les EHR_EXTRACT sont créés à des fins spécifiques et ne garantissent pas automatiquement qu’ils
soient adaptés à d’autres fins.
0.5 Récapitulatif des modifications apportées à la présente édition
Le domaine d’application de toutes les parties reste le même.
L’objectif de cette révision est de:
— obtenir un retour de la part des implémenteurs sur les expériences de l’adoption de la version
publiée de la série de normes 13606;
— simplifier le modèle de référence en supprimant les propriétés qui ne se sont pas révélées utiles aux
implémenteurs;
— améliorer le modèle démographique pour prendre en charge l’utilisation d’archétypes
démographiques;
— améliorer l’alignement sur le système de concepts de l’ISO 13940 pour prendre en charge la
continuité des soins (Contsys);
— aligner les types de données sur les types de données harmonisés de l’ISO 21090 pour l’échange
d’informations (voir l’Annexe A);
— préparer le terrain pour l’alignement sur la FHIR HL7;
— mettre à jour le modèle d’archétype pour l’aligner sur le modèle d’objet d’archétype 2.0 d’openEHR;
— inclure des archétypes de référence pour les informations communément nécessaires (par exemple
démographiques);
— mettre à jour le modèle de rapport d’expertise pour l’aligner sur l’ISO 27789 Historique d’expertise
des dossiers de santé informatisés et la série ISO 22600 Gestion de privilèges et contrôle d’accès.
Modifications du modèle de référence
Base Component (Élément de base)
Une classe Base Component a été introduite plus haut dans la hiérarchie que Record Component, qui a
un identifiant unique, des informations sur l’historique de version et des informations d’attestation.
Cela permet de gérer et d’attester la version de toutes les structures dans un extrait de DSI, y compris
LINK et les informations démographiques, ainsi que la famille d’origine des éléments de dossier.
Record Component (Élément du dossier)
Plusieurs propriétés qui ne se sont pas révélées utiles ont été supprimées de Record Component.
Il est important de comprendre que le modèle désigne maintenant la sémantique des éléments de
dossier par l’intermédiaire de l’ID d’archétype, ce qui évite la duplication et les éventuels conflits entre
étiquettes sémantiques telles que nom et signification.
L’expérience montre que ces différentes propriétés ne sont pas utilisées correctement et entraînent des
pratiques incohérentes.
Une consultation des fournisseurs et des prestataires qui n’ont pas l’intention d’utiliser les archétypes
a confirmé qu’ils peuvent créer une bibliothèque d’archétypes correspondant à leurs structures de
données, s’ils choisissent d’adopter la présente série de normes.
Les propriétés relatives à la sensibilité et à l’ID de politique ont été déplacées dans Composition, pour
éviter le risque d’une Composition contenant des données de politiques mélangées et donc un accès
différent par différentes parties.
Structure Component (Élément de structure)
Une classe parent générique Structure Component est maintenant la classe parent universelle de tous
les éléments de dossier et les classes démographiques.
Toutes ces classes héritent d’un ID d’archétype, qui permet maintenant de définir les structures
démographiques par l’intermédiaire d’archétypes. Cette demande de modification était très demandée.
x © ISO 2019 – Tous droits réservés

EHR_Extract (Extrait de DSI)
Le critère Extract a été supprimé, les implémenteurs ne le trouvant pas très utile.
EHR_EXTRACT peut maintenant contenir un ensemble d’éléments de DSI extraits, et peut donc contenir
des données sur de nombreux sujets des soins.
Folder (Dossier)
Folder a comme propriété sujet des soins, ce qui permet à un extrait de DSI de potentiellement contenir
des informations sur plusieurs sujets des soins, par exemple une famille. Cette demande de modification
était également très demandée.
L’extrait de DSI est un type de dossier contenant des métadonnées spécifiques sur la génération
d’extraits.
Composition, Entry et Cluster (Composition, Entrée et Grappe)
Certaines propriétés inutilisées ont été supprimées de Composition, Entry et Cluster.
Il s’agit entre autres de session_time, obs_time. Il est préférable que ces dates et heures soient incluses
dans les archétypes concernés, avec des noms et rôles précisément spécifiés.
Element (Élément)
La classe Element et sa contrepartie Demographic Element, sont plus précisément des ramifications
distales avec moins de propriétés héritées et moins d’associations héritées qu’auparavant.
Il s’agit de répondre à un certain nombre de fournisseurs de TIC qui ont indiqué que l’élément d’origine
contenait de trop nombreuses propriétés entraînant des pratiques d’adoption incohérentes.
Null flavour n’est plus une propriété explicite du modèle de référence. À la place, un archétype de
référence a été défini à la Partie 3 pour permettre de déclarer Null non seulement au niveau de l’élément
mais aussi plus haut dans la hiérarchie (par exemple déclarer qu’une grappe (Cluster) ou une entrée
(Entry) n’est pas présente).
Data Value (Valeur de données)
Les valeurs de données sont maintenant toutes représentées sous forme de sous-ensemble contraint
des types de données dans l’ISO 21090, conformément à son mécanisme de profilage (voir Annexe A).
Demographics (Données démographiques)
Plutôt que dans un paquet séparé, les entités démographiques sont représentées au moyen de classes
qui héritent de nombreux mécanism
...