Health informatics - Electronic health record communication - Part 2: Archetype interchange specification

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) 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 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 standard series but such secondary uses might also find it useful. This document defines an Archetype Model to be used to represent Archetypes when communicated between repositories, and between archetype services. It defines an optional serialised representation, which may be used as an exchange format for communicating individual archetypes. Such communication might, for example, be between archetype libraries or between an archetype service and an EHR persistence or validation service.

Informatique de santé — Communication du dossier de santé informatisé — Partie 2: Spécification d'échange d'archétype

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) nécessitant d'avoir d'accès aux ou de fournir des données DSI, ou pour la représentation des données 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 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 exigent souvent l'anonymisation ou l'agrégation de dossiers individuels, ne constitue pas l'objet de la présente série de normes; néanmoins, ces applications secondaires sont susceptibles d'y trouver un intérêt. Le présent document définit un modèle d'archétype à utiliser pour représenter des archétypes lorsqu'ils sont communiqués entre des référentiels et entre des services d'archétypes. Il définit une représentation en série facultative qui peut être utilisée comme format d'échange pour la communication d'archétypes individuels. Cette communication peut par exemple avoir lieu entre des bibliothèques d'archétypes ou entre un service d'archétype et un service de permanence ou de validation de DSI.

General Information

Status
Published
Publication Date
06-Jun-2019
Current Stage
9093 - International Standard confirmed
Start Date
11-Dec-2024
Completion Date
13-Dec-2025

Relations

Effective Date
06-Jun-2022
Effective Date
16-Jun-2012

Overview

ISO 13606-2:2019 - "Health informatics - Electronic health record communication - Part 2: Archetype interchange specification" defines an Archetype Model and optional serialized representation for exchanging archetypes used in Electronic Health Record (EHR) communication. The standard supports interoperable transfer of part or all of an EHR between systems, between systems and central repositories, and between archetype services, libraries and clinical/middleware components. It focuses on enabling semantic interoperability through rigorously defined archetype structures and metadata.

Key topics and technical requirements

  • Archetype Model (AOM): Formal object model describing archetype meta-data, structural definitions, constraints and governance needed for consistent EHR content modelling.
  • Archetype interchange format: An optional serialized representation for communicating individual archetypes between repositories, libraries and services.
  • Constraint and rules packages: Specification of node-level constraints, data value constraints, second‑order constraints and validation rules to ensure consistent interpretation of clinical content.
  • Terminology bindings: Support for external term bindings expressed as URIs (IHTSDO-style), and explicit value‑sets for coded terms.
  • Identification and governance: Multi-part namespace archetype identifiers and governance metadata to manage versioning and lifecycle.
  • Model enhancements in 2019 edition: New internal coding scheme (id-codes, at-codes, ac-codes), tuple constraints for co‑varying attributes (e.g., quantities), re-engineered primitive constrainers (C_STRING, C_DATE, etc.), full specialisation support and node-level annotations.
  • Conformance and semantics: Requirements for how archetypes are represented and validated, enabling consistent mapping to the ISO 13606 Reference Model used for EHR extracts.

Practical applications

  • Enable semantic interoperability across heterogeneous EHR systems by exchanging reusable archetypes that define clinical data structure and constraints.
  • Exchange archetypes between archetype libraries, EHR persistence/validation services and clinical decision support or middleware components.
  • Support creation of standardized EHR extracts for direct patient care, as well as population monitoring (disease registries, public health surveillance).
  • Facilitate template development, version control and governance of clinical models used in integration projects, analytics and quality reporting (secondary uses often require anonymization/aggregation).

Who should use ISO 13606-2:2019

  • EHR vendors and system integrators building interoperable interfaces
  • Health IT architects and clinical modelling teams creating archetypes and templates
  • National/regional health repositories and archetype library maintainers
  • Developers of clinical applications, middleware and decision support systems that consume or validate EHR data

Related standards

  • ISO 13606-1 (Reference Model), ISO 13606-3 (Reference archetypes), ISO 13606-5 (Exchange models)
  • openEHR archetype specifications and Clinical Information Modelling Initiative (CIMI) - collaborative inputs referenced in the standard

Keywords: ISO 13606-2, EHR communication, archetype interchange, archetype model, health informatics, semantic interoperability, electronic health record.

Standard

ISO 13606-2:2019 - Health informatics — Electronic health record communication — Part 2: Archetype interchange specification Released:6/7/2019

English language
71 pages
sale 15% off
Preview
sale 15% off
Preview
Standard

ISO 13606-2:2019 - Informatique de santé — Communication du dossier de santé informatisé — Partie 2: Spécification d'échange d'archétype Released:6/7/2019

French language
75 pages
sale 15% off
Preview
sale 15% off
Preview

Frequently Asked Questions

ISO 13606-2:2019 is a standard published by the International Organization for Standardization (ISO). Its full title is "Health informatics - Electronic health record communication - Part 2: Archetype interchange specification". This standard covers: 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) 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 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 standard series but such secondary uses might also find it useful. This document defines an Archetype Model to be used to represent Archetypes when communicated between repositories, and between archetype services. It defines an optional serialised representation, which may be used as an exchange format for communicating individual archetypes. Such communication might, for example, be between archetype libraries or between an archetype service and an EHR persistence or validation service.

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) 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 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 standard series but such secondary uses might also find it useful. This document defines an Archetype Model to be used to represent Archetypes when communicated between repositories, and between archetype services. It defines an optional serialised representation, which may be used as an exchange format for communicating individual archetypes. Such communication might, for example, be between archetype libraries or between an archetype service and an EHR persistence or validation service.

ISO 13606-2:2019 is classified under the following ICS (International Classification for Standards) categories: 35.240.80 - IT applications in health care technology. The ICS classification helps identify the subject area and facilitates finding related standards.

ISO 13606-2:2019 has the following relationships with other standards: It is inter standard links to ISO/TS 3632-1:2003, ISO 13606-2:2008. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.

You can purchase ISO 13606-2:2019 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.

Standards Content (Sample)


INTERNATIONAL ISO
STANDARD 13606-2
Second edition
2019-06
Health informatics — Electronic
health record communication —
Part 2:
Archetype interchange specification
Informatique de santé — Communication du dossier de santé
informatisé —
Partie 2: Spécification d'échange d'archétype
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: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2019 – All rights reserved

Contents Page
Foreword .iv
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviations. 2
5 Conformance . 2
6 Archetype representation requirements . 3
6.1 General . 3
6.2 Archetype definition, description and publication information . 3
6.3 Archetype node constraints . 6
6.4 Data value constraints . 8
7 Archetype object model .10
7.1 Preface .10
7.1.1 Purpose .10
7.1.2 Nomenclature .10
7.2 Model overview .10
7.2.1 Package structure .10
7.2.2 Definition and utility classes .11
7.3 The archetype package .13
7.3.1 Overview .13
7.3.2 Archetype identification .15
7.3.3 Top-level meta-data . .16
7.3.4 Governance meta-data .16
7.3.5 Structural definition.18
7.3.6 Class descriptions .22
7.3.7 Validity rules .29
7.4 Constraint model package .30
7.4.1 Overview .30
7.4.2 Semantics .32
7.4.3 Second order constraints.38
7.4.4 AOM type substitutions .39
7.4.5 Class definitions.41
7.5 The rules package .56
7.5.1 Overview .56
7.5.2 Semantics .57
7.5.3 Class descriptions .57
7.6 Terminology package .62
7.6.1 Overview .62
7.6.2 Semantics .64
7.6.3 Class descriptions .65
7.7 Templates.67
Annex A (informative) Archetype Definition Language .69
Annex B (informative) Example Representation .70
Bibliography .71
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-2:2008), which has been
technically revised. The main changes compared to the previous edition are as follows:
— Introduction of new internal coding scheme, consisting of id-codes, at-codes and ac-codes.
— Replace string archetype identifier with multi-part, namespace identifier.
— Addition of explicit value-sets replacing in-line value sets in the terms and definitions.
— Renaming archetype ontology section to terminology.
— Expression of all external term bindings as URIs following IHTSDO format.
— Introduction of ‘tuple’ constraints for co-varying attributes within Quantity, Ordinal structures.
— Re-engineering of all primitive constrainer types, i.e. C_STRING, C_DATE etc.
— Removal of the Archetype Profile specification.
— Full specialisation support: the addition of an attribute to the C_ATTRIBUTE class, allowing the
inclusion of a path that enables specialised archetype redefinitions deep within a structure.
— Addition of node-level annotations.
— Structural simplification of archetype ontology section.
— The name of the invariant section has been changed to rules, to better reflect its purpose.
— A template is now just an archetype.
A list of all parts in the ISO 13606 series can be found on the ISO website.
iv © ISO 2019 – All rights reserved

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
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.
Comprehensive, multi-enterprise and longitudinal electronic health records will often in practice be
achieved through the joining up of multiple clinical applications, databases (and increasingly devices)
that are each tailored to the needs of individual conditions, specialties or enterprises.
This requires that Electronic Health Record (EHR) data from diverse systems be capable of being
mapped to and from a single comprehensive representation, which is used to underpin interfaces
and messages within a distributed network (federation) of EHR systems and services. This common
representation has to be sufficiently generic and rich to represent any conceivable health record data,
comprising part or all of an EHR (or a set of EHRs) being communicated.
The approach adopted in the ISO 13606 standards series, underpinned by international research on the
EHR, has been to define a rigorous and generic Reference Model that is suitable for all kinds of data and
data structures within an EHR, and in which all labelling and context information is an integral part of
each construct. An EHR Extract (as defined in ISO 13606-1) will contain all of the names, structure and
context required for it to be interpreted faithfully on receipt even if its organisation and the nature of
the clinical content have not been “agreed” in advance.
However, the wide-scale sharing of health records, and their meaningful analysis across distributed
sites, also requires that a consistent approach is used for the clinical (semantic) data structures that
will be communicated via the Reference Model, so that equivalent clinical information is represented
consistently. This is necessary in order for clinical applications and analysis tools safely to process EHR
data that have come from heterogeneous sources.
0.1  Archetypes
The challenge for EHR interoperability is therefore 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 clinical data sets,
value sets, templates etc. required by different health care 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, used to represent the
generic properties of health record information, and Archetypes (conforming to an Archetype Model),
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 is specified as an Open Distributed Processing (ODP) Information Viewpoint
model, representing the global characteristics of health record components, how they are aggregated,
and the context information required to meet ethical, legal and provenance requirements. In the 13606
standards series, the Reference Model is defined in Part 1. 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 standard series).
Archetypes are effectively pre-coordinated combinations of named RECORD_COMPONENT hierarchies
that are agreed within a community in order to ensure semantic interoperability, data consistency and
data quality.
For an EHR_EXTRACT, as defined in ISO 13606-1, an archetype 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
datatypes and value ranges that ELEMENT data values can take, and might include other dependency
constraints. Archetype instances themselves conform to a formal model, known as an Archetype Model
vi © ISO 2019 – All rights reserved

(which is a constraint model, also specified as an ODP Information Viewpoint Model). Although the
Archetype Model is stable, individual archetype instances can be revised or succeeded by others as
clinical practice evolves. Version control ensures that new revisions do not invalidate data created with
previous revisions.
Archetypes can be used within EHR systems to govern the EHR data committed to a repository.
However, for the purposes of this interoperability standard series, no assumption is made about the
use of archetypes within the EHR Provider system whenever this standard series is used for EHR
communication. It is assumed that the original EHR data, if not already archetyped, can be mapped to a
set of archetypes, if desired, when generating the EHR_EXTRACT.
The reference model defined in ISO 13606-1 has a property that can be used to specify the archetype
to which any RECORD_COMPONENT within an EHR_EXTRACT conforms. The class RECORD_
COMPONENT includes an attribute archetype_id to identify the archetype and node to which that
RECORD_COMPONENT conforms.
Part 3 of this standard series includes a set of Reference Archetypes: which are base archetypes that
are likely to be specialised further before they are used. Those archetypes are example instances of
this Archetype Model.
The Archetype Model specified in this document was originally developed by the openEHR Foundation,
which publishes its archetypes using Archetype Definition Language, conforming to this Archetype
Model, referenced within Annex A. The Archetype Model has been the subject of collaborative updating
to incorporate the requirements and modelling inputs from the Clinical Information Modeling Initiative
(CIMI). CIMI is in the process of submitting a modelling language (Archetype Modeling Language, AML)
to the Object Management Group. AML also aligns to this Archetype Model.
0.2  Archetype datatypes
It should be noted that ISO 13606-1 and ISO 13606-2 use datatypes for different purposes.
Part 1 defines datatypes to represent the properties of the Reference Model, as a profile of ISO 21090,
in 5.3. It separately defines in Clause 7 the data types that can be the values of Element, also a subset
of ISO 21090. All these datatypes are finally expressed in terms of the so-called “primitive” datatypes
(Integer, Real, String, Boolean, Date/Time/Datetime).
Part 2 uses the same set of primitive datatypes to represent the properties of the Archetype Object
Model. Additionally, Part 2 defines a set of classes that allow defining constraints over primitive
datatypes of Part 1. These constraining classes are shown in Figure 9 of Part 2, as descendants of the
C_PRIMITIVE_OBJECT class.
A single Part 1 complex datatype (e.g. PHYSICAL_QUANTITY) can be constrained by a combination of
the constraining classes of the Archetype Object Model, defining constraints on both the complex and
primitive datatypes it contains. Thus, Part 1 complex datatypes are treated as classes when defining
constraints with Part 2, while Part 1 primitive data types are constrained by the C_PRIMITIVE_OBJECT
hierarchy.
An example of a PHYSICAL_QUANTITY archetype can be seen in the example below. In this example,
the value on a PHYSICAL_QUANTITY shall be between 0.0 and 1000.0 and their units shall be UCUM
‘mm[Hg]’ code.
PHYSICAL_QUANTITY matches {
value matches {|0.0.<1000.0|}
units matches {
CODED_SIMPLE matches {
value matches {"mm[Hg]"}
}
}
}
This example archetype, expressed in terms of the Archetype Object Model, would have the structure
shown in Table 1.
Table 1 — Example structure for representing physical quantity
Reference Model class, attribute or primitive
Archetype Model constraining class
value
PHYSICAL_QUANTITY C_COMPLEX_OBJECT
value      C_ATTRIBUTE
Real            C_REAL
units      C_ATTRIBUTE
CODED_SIMPLE            C_COMPLEX_OBJECT
value                     C_ATTRIBUTE
String                           C_STRING
Since the Archetype Object Model is also used to constrain other reference models, as for example
the openEHR Reference Model, there will be a need to transform openEHR archetypes to ISO 13606
archetypes, and vice versa. The openEHR Reference Model also uses the same primitive datatypes, but
1)
includes a different set of complex datatypes, such as DV_ORDINAL, or DV_TEXT . When transforming
an openEHR archetype constraint to an ISO 13606 archetype, it might be necessary to introduce an
additional CLUSTER structure to represent the equivalent openEHR sub-components as ELEMENTs.
For example, a representation of an openEHR DV_ORDINAL in ISO 13606 would have the structure
shown in Table 2.
Table 2 — Example structure for representing an ordinal data value
openEHR ISO 13606
DV_ORDINAL CLUSTER matches { -- DV_ORDINAL
parts matches {
symbol         ELEMENT matches { -- symbol
value matches {
DV_CODED_TEXT                  CODED_VALUE matches {*}
}
}
value         ELEMENT matches { -- value
value matches {
Integer                  INTEGER matches {*}
}
}
}
}
An example of how the LINK class defined in Part 1 of this standard series can be represented using the
Archetype Object Model defined in this document is given in Annex B.
1) Please see http: //www .openehr .org/releases/RM/latest/docs/data _types/data _types .html # _text _package for
the specification of this datatype.
viii © ISO 2019 – All rights reserved

0.3  Archetype repositories
The range of archetypes required within a shared EHR community will depend upon its range of clinical
activities. The total set needed on a national basis is presently unknown, but there might eventually be
several thousand archetypes globally. The ideal sources of knowledge for developing such archetype
definitions will be clinical guidelines, care pathways, scientific publications and other embodiments of
best practice. However, “de facto” sources of agreed clinical data structures might also include:
— the data schemata (models) of existing clinical systems;
— the lay-out of computer screen forms used by these systems for data entry and for the display of
analyses performed;
— data-entry templates, pop-up lists and look-up tables used by these systems;
— shared-care data sets, messages and reports used locally and nationally;
— the structure of forms used for the documentation of clinical consultations or summaries within
paper records;
— health information used in secondary data collections;
— the pre-coordinated terms in terminology systems.
Despite this list of de facto ways in which clinical data structures are currently represented, these
formats are very rarely interoperable without substantial costs. The use of standardised archetypes
provides an interoperable way of representing and sharing these specifications, in support of consistent
(good quality) health care record-keeping and the semantic interoperability of shared EHRs.
The involvement of national health services, academic organisations and professional bodies in the
development of archetypes will enable this approach to contribute to the pursuit of quality evidence-
based clinical practice. A key next challenge is to foster communities to build up libraries of archetypes.
It is beyond the scope of this document to assert how this work should be advanced, but in several
countries so far it would appear that national eHealth programmes are beginning to organise clinical-
informatics-vendor teams to develop and operationalise sets of archetypes to meet the needs of specific
healthcare domains. In the future regional or national public domain libraries of archetype definitions
might be accessed via the Internet, and downloaded for local use within EHR systems. Such usage will
also require processes to verify and certify the quality of shared archetypes, which are also beyond the
scope of this document but are being taken forward by not for profit organisations such as the open
EHR Foundation (www .openehr .org), the Clinical Information Modeling Initiative (CIMI, http: //www
.opencimi .org) the EN13606 Association (http: //www .en13606 .org) and the European Institute for
Innovation through Health Data (www .i -hd .eu).
0.4  Communicating archetypes
This document specifies, in Clause 6, the requirements for a comprehensive and interoperable
archetype representation and defines, in Clause 7, the ODP Information Viewpoint representation for
the Archetype Object Model.
This document does not require that any particular model be adopted as the internal architecture
of archetype repositories, services or components used to author, store or deploy archetypes in
collaboration with EHR services. It does require that these archetypes are capable of being mapped
to the Archetype Object Model defined in this document in order to support EHR communication and
interoperability within an EHR-sharing community.
A more detailed overview of archetypes can be found here:
http: //www .openehr .org/releases/AM/latest/docs/Overview/Overview .html
INTERNATIONAL STANDARD ISO 13606-2:2019(E)
Health informatics — Electronic health record
communication —
Part 2:
Archetype interchange specification
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) 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
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 standard series but such secondary uses might also find it useful.
This document defines an Archetype Model to be used to represent Archetypes when communicated
between repositories, and between archetype services. It defines an optional serialised representation,
which may be used as an exchange format for communicating individual archetypes. Such
communication might, for example, be between archetype libraries or between an archetype service
and an EHR persistence or validation service.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 639-1, Codes for the representation of names of languages — Part 1: Alpha-2 code
ISO 8601, Data elements and interchange formats — Information interchange — Representation of dates
and times
ISO 13606-1, Health informatics — Electronic health record communication — Part 1: Reference model
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 13606-1 and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/
3.1
archetype repository
persistent repository of archetype definitions, accessed by a client authoring tool or by a run-time
component within an electronic health record service
3.2
concept
unit of knowledge created by a unique combination of characteristics
[SOURCE: ISO 1087-1:2000]
Note 1 to entry: Concepts are not necessarily bound to particular languages. They are, however, influenced by
the social or cultural background often leading to different categorizations.
3.3
operational template
template in which all references have been substituted by the corresponding structure
3.4
template
archetype defining a particular document or message intended for specific use cases
4 Abbreviations
For the purposes of this document, the following abbreviations apply.
ADL Archetype Definition Language
AOM Archetype Object Model (synonym for Archetype Model)
CIMI Clinical Information Modelling Initiative
EHR Electronic Health Record
ODP Open Distributed Processing (ISO/IEC 10746 series, used for describing distributed
systems)
OWL Ontology Web Language
RM Reference Model e.g. the ISO 13606 Part 1 Reference Model
UML Unified Modelling Language
XML Extensible Mark-up Language
5 Conformance
The communication of an archetype that is used to constrain part of an EHR_EXTRACT shall conform
to the information model defined in Clause 7. Conformance to the functions defined for each class in
Clause 7, where specified, is optional. This document does not prescribe any particular representation
of archetypes to be used internally within an archetype repository, server or EHR system. The
representation of archetypes shall meet the requirements listed in Clause 6.
2 © ISO 2019 – All rights reserved

6 Archetype representation requirements
6.1 General
This clause lists a set of formal requirements for an archetype representation. This provides the basis
on which the archetype model specified in 7.2 has been designed.
6.2 Archetype definition, description and publication information
6.2.1 The definition of an archetype shall include the following information.
6.2.1.1 The globally-unique identifier of this archetype definition.
6.2.1.2 The identifier of the repository in which this archetype originated or is now primarily held, or
of the authority responsible for maintaining it. This repository shall be the one in which the definitive
publication status of this archetype will be managed.
6.2.1.3 The concept that best defines the overall clinical scope of instances conforming to this
archetype as a whole, expressed as a coded term or as free text in a given natural language.
6.2.1.4 The health informatics domain to which this archetype applies (e.g. EHR). This shall map to a
set of reference models with which this archetype may be used.
6.2.1.5 The underlying reference model for which this archetype was ideally fashioned.
NOTE An archetype can be capable of use with more than one relevant reference model within a given health
informatics domain, but it is expected that the archetype will be optimised for one.
6.2.1.6 The natural language in which this archetype was originally defined, represented by its
ISO 639-code. In the event of imprecise translations, this is the definitive language for interpretation of
the archetype.
6.2.2 The definition of an archetype may include the following information, if applicable.
6.2.2.1 The globally-unique identifier for the archetype of which this archetype is a specialisation and
to which it shall also conform.
6.2.2.2 The globally-unique identifier of the former archetype that this definition replaces, if it not the
first version of an archetype.
6.2.2.3 The reason for defining this new version of a pre-existing archetype.
6.2.2.4 The identifier of the replacement for this archetype, if it has been superseded.
NOTE It is possible that this information can only be added by reference within a version-controlled
repository; how this is effected is not in scope for this document.
6.2.2.5 An archetype shall have one or more description sets, defining its usage and purpose. Multiple
versions of this information may be included, represented in different natural languages or to inform
different kinds of potential user.
6.2.3 An archetype description set shall include the following information.
6.2.3.1 The uniquely-identified person or organisation responsible for providing this description set.
This may include contact information for that person or organisation.
6.2.3.2 The uniquely-identified person or organisation responsible for defining the archetype
hierarchy itself. This may include contact information for that person or organisation.
6.2.3.3 The natural language in which this description set is provided, represented by its ISO 639-code.
6.2.3.4 A formal statement defining the scope and purpose of this archetype, expressed as a coded
term or as free text in a given natural language.
NOTE These criteria can be expressed as coded terms to improve queries for relevant archetypes from the
repository.
EXAMPLE The scope and purpose can specify:
1) the principal clinical specialty or kinds of user for which it is intended;
2) A list of clinical terms (keywords): diagnoses, acts, drugs, findings etc.;
3) the kind of patient in whom it is intended to be used (age, gender, etc.);
4) the kind of demographic entities it is intended to represent.
6.2.4 An archetype description set may include the following information, if applicable.
6.2.4.1 A formal statement of the intended use of this archetype.
NOTE Ideally this can be a coded expression, although a suitable terminology for this is not yet available.
6.2.4.2 A formal statement of situations in which users might erroneously believe this archetype
should be used. This may also stipulate any kinds of Reference Model for which it is unsuitable.
6.2.4.3 A detailed explanation of the purpose of this archetype, including any features of particular
interest or note. This may include an indication of the persons for which this definition is intended e.g.
for students. This information might be included explicitly, and/or by reference (e.g. via a URL).
6.2.4.4 A description, reference or link to the published medical knowledge that has underpinned the
definition of this archetype.
6.2.4.5 Information about evidence that has informed its development, e.g. an existing specification or
standard, published knowledge or clinical experience.
6.2.4.6 How the archetype may be used in quality healthcare delivery.
6.2.4.7 The care processes it has been designed to support.
6.2.4.8 Information about which organisations, professional bodies or government bodies have
endorsed the model, when this endorsement occurred, and under which criteria.
6.2.5 An archetype definition shall include a statement of its publication status.
6.2.5.1 An archetype definition may evolve through a series of publication states, for example an
approval process, without otherwise being changed. These successive states shall be retained as part of
4 © ISO 2019 – All rights reserved

the archetype, for audit purposes. However, the modification of the publication status of an archetype
shall not itself constitute a formal revision of the identifier by which the archetype is referenced within
an EHR_EXTRACT, since the constraint specification will not have been changed.
6.2.6 The publication status of an archetype shall specify the following information.
6.2.6.1 The publication status of this archetype, taken from the following list:
— Test;
— In development;
— Release candidate;
— Rejected;
— Definitive;
— Deprecated.
6.2.6.2 The date when this particular publication status applied
NOTE The first instance of a publication status for this archetype will also be the date when it was first
composed.
6.2.6.3 The unique identifier of the person committing this archetype to the repository and thereby
asserting this publication status. This identification might optionally include the organisation which that
person represents.
6.2.6.4 The unique identifier of the body authorising this change in publication status.
6.2.6.5 The date when it is anticipated that the present publication status, and the archetype content
itself, ought to be reviewed to confirm it remains valid.
6.2.6.6 The unique identifier of the person or organisation that is nominated, authorised or has
accepted responsibility for reviewing the validity of the archetype and optionally for updating it, when
appropriate.
6.2.6.7 A clear statement of any copyright or licensing restrictions which apply to the use of the
archetype.
6.2.6.8 The copyright holder and/or governing authority.
6.2.7 Version management.
6.2.7.1 An archetype definition shall indicate the version of the constraints it specifies.
6.2.7.2 An archetype definition may indicate the person or organization responsible for that version.
6.2.7.3 An archetype definition may indicate the date on which the current version was created.
6.2.7.4 The archetype version identifiers or other properties may indicate the nature of changes made
from the previous version, and in particular if EHR instances communicated with the current and the
previous version are compatible with each other.
6.3 Archetype node constraints
6.3.1 General
An archetype definition shall include a specification of the hierarchical schema to which instances of
data (e.g. EHR data) shall conform. This schema defines the hierarchical organisation of a set of nodes,
the relationships between them, and constraints on the permitted values of attributes and data values.
These shall also conform to the underlying reference model(s) for which this definition is applicable.
6.3.2 Archetype node references
6.3.2.1 Any node in the archetype hierarchy might be defined explicitly or, by reference, be specified to
be part or whole of a pre-existing archetype.
6.3.2.2 A reference to a pre-existing archetype or archetype fragment may be explicit, by specifying the
archetype identifier, and optionally the identifier of the node of the archetype fragment.
6.3.2.3 A reference to an archetype fragment may be internal to (i.e. part of) the current archetype.
6.3.2.4 An archetype node may be specified to be one of a set of possible archetypes, by defining an
explicit list of candidates and/or by specifying a set of constraints on any of the attributes of an archetype
definition.
6.3.2.5 In addition to specifying one or more archetype fragments by reference or constraint, it shall
be possible to include an explanation of the rationale for incorporating that specification at the given
point in the current archetype hierarchy.
6.3.3 The specification of an archetype node (if not by reference) shall include the following
information.
6.3.3.1 A unique identifier of this archetype node. Either in itself or when combined with the globally-
unique identifier of this archetype definition, it shall be a globally unique reference to the node itself.
6.3.3.2 The class in the EHR instance hierarchy, mapping to the underlying reference model that this
archetype constrains, that shall be instantiated in order to conform to this archetype node.
6.3.3.3 The number of occurrences, expressed as a range that may be instantiated corresponding to
this archetype node within an instance hierarchy.
6.3.3.4 Other constraints and rules may optionally be specified to govern the creation of instances
corresponding to this archetype node.
6.3.3.5 Constraint rules may be expressed as logical conditions, and may include reference to
environment parameters such as the current time or location or participants, or be related to the (pre-
existing) values other nodes in the instance hierarchy. Constraint rules may be used to represent the
relationship between EHR data and workflow or care pathway processes.
6.3.3.6 Constraint rules may be expressed as inclusion or exclusion criteria.
6.3.3.7 An archetype shall identify the formalism (including version) in which constraint rules are
expressed (e.g. ADL, OWL).
6 © ISO 2019 – All rights reserved

6.3.4 Binding archetype nodes to terms
6.3.4.1 Every node of an archetype schema hierarchy shall be associated with at least one term, which
most accurately expresses the intended concept to be represented by that node on instantiation in the
corresponding instance hierarchy. This term can usually be included or referenced within the instance.
6.3.4.2 Every node of an archetype schema hierarchy may additionally be associated with a description
that elaborates on the meaning given by the term labelling that node.
6.3.4.3 Any node of an archetype may be mapped to any number of additional concepts, terms and
synonyms from terminology systems, to support either the interrogation of the archetype repository or
of the corresponding instances.
6.3.4.4 Any concept mapping term or text shall specify the purpose that this mapping serves, using
one of the following list of values:
— Principal concept;
— Term binding;
— Synonym;
— Language translation.
6.3.4.5 Any reference to a coded term shall include the code, rubric, and identify the coding system
(including version) from which the code and rubric have been taken. In addition, it shall be possible to
specify the natural language in which this term was mapped, or in which a translation is expressed.
6.3.4.6 The meaning of every node in an archetype should be defined through a binding to the
appropriate concept identifier from an appropriate concept model.
6.3.4.7 The meaning of any specif
...


NORME ISO
INTERNATIONALE 13606-2
Deuxième édition
2019-06
Informatique de santé —
Communication du dossier de santé
informatisé —
Partie 2:
Spécification d'échange d'archétype
Health informatics — Electronic health record communication —
Part 2: Archetype interchange specification
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.: +41 22 749 01 11
Fax: +41 22 749 09 47
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
ii © ISO 2019 – Tous droits réservés

Sommaire Page
Avant-propos .iv
Introduction .vi
1 Domaine d’application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Abréviations . 2
5 Conformité . 2
6 Exigences de représentation des archétypes . 3
6.1 Généralités . 3
6.2 Définition, description et informations de publication de l’archétype . 3
6.3 Contraintes de nœud d’archétype . 6
6.4 Contraintes de valeurs de données . 8
7 Modèle d’objet d’archétype .10
7.1 Préface .10
7.1.1 Objet.10
7.1.2 Nomenclature .10
7.2 Vue d’ensemble du modèle .11
7.2.1 Structure du paquetage . .11
7.2.2 Classes de définition .11
7.3 Paquetage archétype .14
7.3.1 Vue d’ensemble .14
7.3.2 Identification de l’archétype .16
7.3.3 Métadonnées de niveau supérieur .17
7.3.4 Métadonnées de gouvernance.17
7.3.5 Définition structurelle .19
7.3.6 Descriptions de classes .23
7.3.7 Règles de validité .30
7.4 Paquetage de modèle de contrainte .31
7.4.1 Vue d’ensemble .31
7.4.2 Sémantique .33
7.4.3 Contraintes de second ordre .40
7.4.4 Substitutions de type d’AOM .42
7.4.5 Définitions de classes . .43
7.5 Le paquetage de règles .60
7.5.1 Vue d’ensemble .60
7.5.2 Sémantique .61
7.5.3 Descriptions de classes .61
7.6 Paquetage de terminologie .66
7.6.1 Vue d’ensemble .66
7.6.2 Sémantique .68
7.6.3 Descriptions de classes .69
7.7 Modèles .72
Annexe A (informative) Langage de définition d’archétype (Archetype Definition Language) .73
Annexe B (informative) Exemple de représentation .74
Bibliographie .75
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 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-2:2008), qui a fait l’objet
d’une révision technique. Les principales modifications par rapport à l’édition précédente sont les
suivantes:
— Introduction d’un nouveau schéma de codage interne, constitué de codes id-code, at-code et ac-code;
— Remplacement de l’identifiant d’archétype de chaîne par un identifiant d’espace de nom à plusieurs
parties;
— Ajout d’ensembles de valeurs explicites remplaçant les ensembles de valeurs correspondants de la
section termes et définitions;
— Renommage de la section ontologie de l’archétype en terminologie;
— Expression de toutes les associations de termes sous forme d’URI conformément au format IHTSDO;
— Introduction de contraintes d’uplets pour les attributs covariants dans les structures Quantité,
Ordinal;
— Reconfiguration de tous les types de contrainte primitifs, c’est-à-dire C_STRING, C_DATE, etc.;
— Suppression de la spécification du profil d’archétype;
— Support de spécialisation complet: l’ajout d’un attribut à la classe C_ATTRIBUTE, permettant
l’inclusion d’un chemin qui autorise des redéfinitions d’archétypes spécialisés en profondeur dans
une structure;
iv © ISO 2019 – Tous droits réservés

— Ajout d’annotations au niveau du nœud;
— Simplification structurelle de la section ontologie d’archétype;
— Le nom de la section des invariants est devenu «règles» afin de mieux refléter son objectif;
— Un modèle est maintenant simplement un archétype.
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
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.
Dans la pratique, les dossiers de santé informatisés complets, inter-entreprises et longitudinaux sont
souvent obtenus en regroupant plusieurs applications médicales, bases de données (et de plus en plus
de dispositifs), chacun étant configuré sur mesure pour répondre aux besoins de conditions, spécialités
ou entreprises spécifiques.
Cette pratique exige que les données de dossiers de santé informatisés (DSI) de systèmes divers
puissent être mises en correspondance vers et depuis une représentation complète unique, qui est
utilisée pour étayer les interfaces et les messages dans un réseau (une fédération) réparti de systèmes
et de services de DSI. Il convient que cette représentation commune soit suffisamment générale et
riche pour représenter toutes les données de dossier de santé envisageables, dont une partie ou un DSI
complet (ou un ensemble de DSI) communiqués.
L’approche adoptée par la série de normes ISO 13606, soutenue par la recherche internationale sur
les DSI, a consisté à définir un modèle de référence générique rigoureux qui soit adapté à tous les types
de données et de structures de données dans un DSI, et dans lequel toutes les informations d’étiquetage
et de contexte fassent partie intégrante de chaque représentation. Un extrait de DSI (tel que défini dans
l’ISO 13606-1) contient tous les noms, la structure et le contexte exigés pour une interprétation fiable
à la réception, même si l’organisation et la nature du contenu médical n’ont fait l’objet d’aucun «accord»
préalable.
Cependant, le partage à grande échelle des dossiers de santé et leur analyse significative sur des
sites répartis exigent également d’utiliser une approche cohérente pour les structures de données
médicales (sémantiques) qui seront communiquées par le biais du modèle de référence, afin de pouvoir
représenter de façon cohérente des informations médicales équivalentes. Cela est nécessaire afin
que les applications médicales et les outils d’analyse traitent en toute sécurité les données de DSI qui
proviennent de sources hétérogènes.
0.1  Archétypes
Le défi que représente l’interopérabilité des DSI a donc é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 cliniques, ensembles de valeurs, modèles de
document, etc. 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 normes distingue le modèle de référence, utilisé pour
représenter les propriétés génériques des informations du dossier de santé et les archétypes (conformes
au modèle d’archétype) qui sont des métadonnées servant à représenter les caractéristiques spécifiques
de différentes catégories de données médicales, 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 est spécifié comme un modèle de point de vue d’information de traitement
ouvert réparti (ODP) représentant 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. Dans la série de normes ISO 13606, le modèle de référence est défini
dans l’ISO 13606-1. 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 l’ISO 13606-5).
vi © ISO 2019 – Tous droits réservés

Les archétypes sont des combinaisons pré-coordonnées de hiérarchies de RECORD_COMPONENT
(éléments de dossier) nommées et convenues au sein d’une communauté afin d’assurer l’interopérabilité
sémantique, l’homogénéité et la qualité des données.
Pour un EHR_EXTRACT (extrait de DSI), tel que défini dans l’ISO 13606-1, un 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. Les instances d’archétypes
elles-mêmes sont conformes à un modèle formel, appelé modèle d’archétype (qui est un modèle
contraint, également spécifié en tant que modèle de point de vue d’information ODP). Bien que le modèle
d’archétype soit stable, les instances d’archétypes individuelles peuvent être révisées ou remplacées
par d’autres à mesure que la pratique médicale évolue. Le contrôle de version assure que les nouvelles
révisions n’invalident pas les données créées par les révisions précédentes.
Les archétypes peuvent être utilisés dans les systèmes de DSI pour orienter les données de DSI
consignées dans un référentiel. Cependant, aux fins de la présente série de normes d’interopérabilité,
aucune hypothèse n’est faite quant à l’utilisation d’archétypes dans le système émetteur de DSI dès lors
que la présente série de normes est utilisée pour la communication de DSI. Il est pris pour hypothèse que
les données de DSI originales, si elles ne sont pas déjà soumises à un archétype, peuvent éventuellement
être mises en correspondance avec un ensemble d’archétypes lors de la génération de l’EHR_EXTRACT.
Le modèle de référence défini dans l’ISO 13606-1 dispose d’une propriété qui peut être utilisée pour
spécifier l’archétype auquel est conforme tout RECORD_COMPONENT dans un EHR_EXTRACT. La classe
RECORD_COMPONENT comprend un attribut archetype_id pour identifier l’archétype et le nœud auquel
ce RECORD_COMPONENT est conforme.
L’ISO 13606-3 inclut un ensemble d’archétypes de référence, qui sont des archétypes de base
susceptibles d’être plus spécialisés avant leur utilisation. Ces archétypes sont des exemples d’instances
de ce modèle d’archétype.
Le modèle d’archétype spécifié dans le présent document a été développé à l’origine par la Fondation
openEHR, qui publie ses archétypes au moyen du langage de définition d’archétype conforme à
ce modèle d’archétype, référencé à l’Annexe A. Le modèle d’archétype a été le sujet d’une mise à
jour collaborative pour intégrer les exigences et les données de modélisation de l’initiative CIMI
(Clinical Information Modeling Initiative, processus de modélisation des informations médicales). CIMI
est en cours de développement d’un langage de modélisation (Archetype Modeling Language, AML) à
soumettre à l’Object Management Group. L’AML est également aligné sur le présent modèle d’archétype.
0.2  Types de données d’archétypes
Il convient de noter que l’ISO 13606-1 et l’ISO 13606-2 utilisent les types de données à des fins
différentes.
L’ISO 13606-1 définit les types de données qui représentent les propriétés du modèle de référence,
en tant que profil de l’ISO 21090, en 5.3. Elle définit séparément à l’Article 7 les types de données qui
peuvent être les valeurs d’un Élément, également un sous-ensemble de l’ISO 21090. Tous ces types de
données sont enfin exprimés en termes de ce que l’on appelle les types de données «primitifs» (Integer,
Real, String, Boolean, Date/Time/Date_time).
L’ISO 13606-2 utilise le même ensemble de types de données primitifs pour représenter les propriétés
du modèle d’objet d’archétype. De plus l’ISO 13606-2 définit un ensemble de classes qui permettent de
définir les contraintes sur les types de données primitifs de l’ISO 13606-1. Ces classes de contrainte sont
représentées à la Figure 9 de l’ISO 13606-2, en tant que descendants de la classe C_PRIMITIVE_OBJECT.
Un type de données complexe unique de l’ISO 13606-1 (par exemple PHYSICAL_QUANTITY) peut être
contraint par une combinaison des classes de contrainte du modèle d’objet d’archétype définissant les
contraintes sur les types de données complexes et primitifs qu’il contient. Ainsi, les types de données
complexes de l’ISO 13606-1 sont traités comme des classes pour la définition des contraintes au moyen
de l’ISO 13606-2, tandis que les types de données primitifs de l’ISO 13606-1 sont contraints par la
hiérarchie C_PRIMITIVE_OBJECT.
L’exemple ci-dessous montre un exemple d’archétype PHYSICAL_QUANTITY. Dans cet exemple, il
convient que la valeur d’une PHYSICAL_QUANTITY soit comprise entre 0,0 et 1 000,0 et que les unités
soient «mm[Hg]» selon le code UCUM.
PHYSICAL_QUANTITY correspond à {
valeur correspond à {|0.0. < 1000.0|}
unités correspond à {
CODED_SIMPLE correspond à {
valeur correspond à {”mm[Hg]”}
}
}
}
Cet exemple d’archétype, exprimé selon le modèle d’objet d’archétype, présente la structure présentée
au Tableau 1.
Tableau 1 — Exemple de structure de représentation de la quantité physique
Classe de modèle de référence, attribut ou valeur
Classe de contrainte du modèle d’archétype
primitive
PHYSICAL_QUANTITY C_COMPLEX_OBJECT
value      C_ATTRIBUTE
Real            C_REAL
units      C_ATTRIBUTE
CODED_SIMPLE            C_COMPLEX_OBJECT
value                     C_ATTRIBUTE
String                           C_STRING
Puisque le modèle d’objet d’archétype est également utilisé pour contraindre d’autres modèles de
référence, comme par exemple le modèle de référence openEHR, il est nécessaire de transformer
les archétypes openEHR en archétypes ISO 13606 et vice-versa. Le modèle de référence openEHR
utilise également les mêmes types de données primitifs mais comprend un ensemble de types de
1)
données complexes différent, comme DV_ORDINAL ou DV_TEXT . Lors de la transformation d’une
contrainte d’archétype openEHR en un archétype ISO 13606, il peut être nécessaire d’introduire une
structure CLUSTER supplémentaire pour représenter les sous-composants openEHR équivalents en
tant qu’ELEMENT.
Par exemple, une représentation d’un DV_ORDINAL openEHR de l’ISO 13606 présente la structure
présentée au Tableau 2.
1) Consulter http: //www .openehr .org/releases/RM/latest/docs/data _types/data _types .html # _text _package
pour la spécification de ce type de données.
viii © ISO 2019 – Tous droits réservés

Tableau 2 — Exemple de structure de représentation d'une valeur de données ordinale
openEHR ISO 13606
DV_ORDINAL CLUSTER correspond à { -- DV_ORDINAL
parties correspond à {
symbol         ELEMENT correspond à { -- symbole
valeur correspond à {
DV_CODED_TEXT                  CODED_VALUE correspond à {*}
}
}
value         ELEMENT correspond à { -- valeur
valeur correspond à {
Integer                  INTEGER correspond à {*}
}
}
}
}
L’Annexe B donne un exemple de la représentation possible de la classe LINK définie dans l’ISO 13606-1
au moyen du modèle d'objet d’archétype défini dans le présent document.
0.3  Référentiels d’archétypes
La gamme d’archétypes exigée dans une communauté de DSI partagée dépend de sa gamme d’activités
médicales. Le total nécessaire sur une base nationale est aujourd’hui inconnu mais il pourrait représenter
plusieurs milliers d’archétypes. Les sources de connaissance idéales pour le développement de ces
définitions d’archétypes sont les lignes directrices médicales, les protocoles de soins, les publications
scientifiques et d’autres mises en œuvre de bonnes pratiques. Toutefois, les sources «de facto» de
structures de données médicales homologuées peuvent également inclure les éléments suivants:
— les schémas conceptuels (modèles) de données des systèmes cliniques existants;
— la mise en page des formulaires d’écrans d’ordinateurs utilisés par ces systèmes pour la saisie de
données et l’affichage des analyses effectuées;
— les modèles de saisie de données, listes déroulantes et tableaux de consultation utilisés par ces
systèmes;
— les ensembles de données de soins partagés, les messages et les rapports utilisés aux niveaux local
et national;
— la structure des formulaires utilisés pour la documentation des consultations médicales ou de leurs
résumés dans les dossiers papier;
— les informations de santé utilisées dans les collectes de données secondaires;
— les termes pré-coordonnés des systèmes terminologiques.
Malgré cette liste de moyens de facto par lesquels les structures de données médicales sont aujourd’hui
représentées, ces formats sont très rarement interopérables sans entraîner des coûts importants.
L’utilisation d’archétypes normalisés procure un moyen interopérable de représenter et de partager
ces spécifications, en soutien à un archivage de soins de santé cohérent (de bonne qualité) et à
l’interopérabilité sémantique des DSI partagés.
L’implication de services de santé nationaux, d’organisations universitaires et d’organismes
professionnels dans le développement des archétypes permettra que cette approche contribue à la
poursuite d’une pratique médicale basée sur la preuve de la qualité. L’un des défis suivants consiste
à encourager les communautés à élaborer des bibliothèques d’archétypes. La manière dont il convient
de faire avancer ce travail ne fait pas partie du domaine d’application du présent document, mais il
semble que dans plusieurs pays les programmes nationaux commencent à organiser des équipes de
fournisseurs médicaux informatiques pour développer et mettre en œuvre des ensembles d’archétypes
en vue de satisfaire aux besoins de secteurs spécifiques de la santé. Des bibliothèques publiques
nationales ou locales de définitions d’archétypes pourraient à l’avenir être accessibles par Internet et
téléchargées pour un usage local dans les systèmes de DSI. Cet usage exige également des processus
permettant de vérifier et de certifier la qualité des archétypes partagés, qui sont également au-delà
du domaine d’application du présent document mais qui sont développés par des organismes à but non
lucratif tels que la Fondation openEHR (www .openehr .org), l’initiative Clinical Information Modeling
Initiative (CIMI, http: //www .opencimi .org) l’Association EN 13606 (http: //www .en13606 .org) et
l’Institut européen pour l’innovation par les données de santé (www .i -hd .eu).
0.4  Communication des archétypes
Le présent document spécifie, à l’Article 6, les exigences pour une représentation complète et
interopérable des archétypes et définit, à l’Article 7, la représentation de point de vue d’information ODP
pour le modèle d’objet d’archétype.
Le présent document n’exige pas qu’un modèle particulier soit adopté en tant qu’architecture interne
des référentiels d’archétypes, services ou composants utilisés pour créer, stocker ou déployer des
archétypes en collaboration avec les services de DSI. Il exige cependant que ces archétypes puissent
être mis en correspondance avec le modèle d’objet d’archétype du présent document, afin de prendre
en charge la communication et l’interopérabilité des DSI au sein d’une communauté de partage de DSI.
Une vue d’ensemble plus détaillée des archétypes peut être consultée à l’adresse:
http: //www .openehr .org/releases/AM/latest/docs/Overview/Overview .html
x © ISO 2019 – Tous droits réservés

NORME INTERNATIONALE ISO 13606-2:2019(F)
Informatique de santé — Communication du dossier de
santé informatisé —
Partie 2:
Spécification d'échange d'archétype
1 Domaine d’application
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) nécessitant d’avoir d’accès aux ou de fournir des données DSI, ou pour la représentation des
données 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 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 exigent souvent
l’anonymisation ou l’agrégation de dossiers individuels, ne constitue pas l’objet de la présente série de
normes; néanmoins, ces applications secondaires sont susceptibles d’y trouver un intérêt.
Le présent document définit un modèle d’archétype à utiliser pour représenter des archétypes lorsqu’ils
sont communiqués entre des référentiels et entre des services d’archétypes. Il définit une représentation
en série facultative qui peut être utilisée comme format d’échange pour la communication d’archétypes
individuels. Cette communication peut par exemple avoir lieu entre des bibliothèques d’archétypes ou
entre un service d’archétype et un service de permanence ou de validation de DSI.
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu’ils constituent, pour tout ou partie de leur
contenu, des exigences du présent document. Pour les références datées, seule l’édition citée s’applique.
Pour les références non datées, la dernière édition du document de référence s'applique (y compris les
éventuels amendements).
ISO 639-1, Codes pour la représentation des noms de langue — Partie 1: Code alpha-2
ISO 8601, Éléments de données et formats d'échange — Échange d'information — Représentation de la
date et de l'heure
ISO 13606-1, Informatique de santé — Communication du dossier de santé informatisé — Partie 1: Modèle
de référence
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions de l’ISO 13606-1, ainsi que les suivants,
s’appliquent.
L’ISO et l’IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en
normalisation, consultables aux adresses suivantes:
— ISO Online browsing platform: disponible à l'adresse https: //www .iso .org/obp;
— IEC Electropedia: disponible à l'adresse http: //www .electropedia .org/.
3.1
référentiel d’archétypes
référentiel permanent de définitions d’archétypes, accessible à l’aide d’un outil de création client ou
d’un composant d’exécution au sein d’un service de dossiers de santé informatisés
3.2
concept
unité de connaissance créée par une combinaison unique de caractères
[SOURCE: ISO 1087-1:2000]
Note 1 à l'article: Les concepts ne sont pas nécessairement liés à des langues particulières. Ils sont cependant
soumis à l’influence du contexte socioculturel qui conduit souvent à des catégorisations différentes.
3.3
modèle opérationnel
modèle dans lequel toutes les références ont été remplacées par la structure correspondante
3.4
modèle
archétype définissant un document ou un message particulier destiné à des cas spécifiques
4 Abréviations
Pour les besoins du présent document, les abréviations suivantes s’appliquent.
ADL Langage de définition d’archétype (Archetype Definition Language)
AOM Modèle d’objet d’archétype (Archetype Object Model), synonyme de modèle d’archétype
CIMI Initiative pour la modélisation des informations médicales (Clinical Information Modelling
Initiative)
DSI Dossier de santé informatisé
MR Modèle de référence, par exemple le modèle de référence de l’ISO 13606-1
ODP Traitement réparti ouvert (Open Distributed Processing) (série ISO/IEC 10746, utilisée pour
décrire les systèmes répartis)
OWL Langage d’ontologie Web (Ontology Web Language)
UML Langage de modélisation unifié (Unified Modelling Language)
XML Langage de balisage extensible (eXtensible Mark-up Language)
5 Conformité
La communication d’un archétype qui est utilisé pour contraindre une partie d’un EHR_EXTRACT
doit être conforme au modèle d’information défini à l’Article 7. La conformité aux fonctions définies
pour chaque classe dans l’Article 7, lorsqu’elle est spécifiée, est facultative. Le présent document ne
spécifié aucune représentation particulière des archétypes à utiliser en interne dans un référentiel
2 © ISO 2019 – Tous droits réservés

d’archétypes, un serveur ou un système de DSI. La représentation des archétypes doit satisfaire aux
exigences énumérées à l’Article 6.
6 Exigences de représentation des archétypes
6.1 Généralités
Le présent article énumère les exigences formelles nécessaires à la représentation d’un archétype. Cela
fournit la base sur laquelle le modèle d’archétype spécifié en 7.2 a été conçu.
6.2 Définition, description et informations de publication de l’archétype
6.2.1 La définition d’un archétype doit inclure les informations suivantes.
6.2.1.1 L’identifiant universel unique de cette définition d’archétype.
6.2.1.2 L’identifiant du référentiel duquel provient cet archétype ou dans lequel il est principalement
conservé ou de l’autorité responsable de sa conservation. Ce référentiel doit être celui dans lequel le
statut de publication définitif de cet archétype sera géré.
6.2.1.3 Le concept qui définit le mieux le domaine d’application médical général des instances
conformes à cet archétype dans son ensemble, exprimé sous forme de texte codé ou de texte libre dans
une langue naturelle donnée.
6.2.1.4 Le domaine de l’informatique de santé auquel cet archétype s’applique (par exemple DSI). Cela
doit correspondre à un ensemble de modèles de référence avec lesquels cet archétype peut être utilisé.
6.2.1.5 Le modèle de référence sous-jacent pour lequel cet archétype a été façonné dans l’idéal.
NOTE Un archétype peut être apte à être utilisé avec plusieurs modèles de référence pertinents dans un
domaine donné de l’informatique de santé mais les archétypes sont censés être optimisés pour un modèle.
6.2.1.6 La langue naturelle dans laquelle cet archétype a été défini à l’origine, représentée par son code
ISO 639. En cas de traductions imprécises, il s’agit de la langue définitive d’interprétation de l’archétype.
6.2.2 Le cas échéant, la définition d’un archétype peut inclure les informations suivantes.
6.2.2.1 L’identifiant universel unique de l’archétype duquel cet archétype constitue une spécialisation
et auquel il doit également être conforme.
6.2.2.2 L’identifiant universel unique de l’archétype précédent que cette définition remplace, s’il ne
s’agit pas de la première version d’un archétype.
6.2.2.3 La raison de la définition de cette nouvelle version d’un archétype préexistant.
6.2.2.4 L’identifiant du remplacement de cet archétype s’il a été remplacé.
NOTE Il est possible que cette information ne puisse être ajoutée que par référence dans un référentiel à
versions contrôlées; ceci ne fait pas partie du domaine d’application du présent document.
6.2.2.5 Un archétype doit disposer de un ou plusieurs ensembles de description qui définissent son
usage et son objectif. Plusieurs versions de cette information peuvent être incluses, représentées en
différentes langues naturelles ou pour informer différents types d’utilisateurs potentiels.
6.2.3 Un ensemble de description d’archétype doit inclure les informations suivantes.
6.2.3.1 L’identifiant unique de la personne ou de l’organisation responsable de cet ensemble de
définitions. Cela peut comprendre les informations de contact de cette personne ou organisation.
6.2.3.2 L’identifiant unique de la personne ou de l’organisation responsable de la définition de la
hiérarchie de l’archétype. Cela peut comprendre les informations de contact de cette personne ou
organisation.
6.2.3.3 La langue naturelle dans laquelle cet ensemble de descriptions a été donné, représentée par
son code ISO 639.
6.2.3.4 Une déclaration formelle du domaine d’application et de l’objectif de cet archétype, exprimée
sous forme de texte codé ou de texte libre dans une langue naturelle donnée.
NOTE Ces critères peuvent être exprimés en termes codés pour améliorer les requêtes d’archétypes
pertinents dans le référentiel.
EXEMPLE Le domaine d’application et l’objectif peuvent spécifier:
1) la spécialité médicale principale ou les types d’utilisateurs auxquels il est destiné;
2) une liste de termes médicaux (mots clés): diagnostics, actes, médicaments, conclusions, etc.;
3) le type de patient pour lequel il est destiné à être utilisé (âge, genre, etc.);
4) le type d’entités démographiques qu’il est destiné à représenter.
6.2.4 Le cas échéant, un ensemble de description d’archétype peut inclure les informations
suivantes.
6.2.4.1 Une déclaration formelle de l’utilisation prévue de cet archétype.
NOTE Dans l’idéal, il peut s’agir d’une expression codée, même si aucune terminologie adaptée n’est encore
disponible pour celle-ci.
6.2.4.2 Une déclaration formelle des situations dans lesquelles les utilisateurs pourraient croire à tort
qu’il convient d’utiliser cet archétype. Elle peut également stipuler tout type de modèle de référence pour
lequel il est inadapté.
6.2.4.3 Une explication détaillée de l’objectif de cet archétype incluant toute caractéristique d’intérêt
particulier. Cela peut inclure une indication des personnes auxquelles cette définition est destinée,
par exemple des étudiants. Cette information peut être incluse explicitement et/ou référencée
(par exemple par le biais d’une URL).
6.2.4.4 Une description, une référence ou un lien vers les informations médicales publiées qui ont aidé
à définir cet archétype.
6.2.4.5 Des informations sur les preuves qui ont permis le développement, par exemple une
spécification ou une norme existante, des informations publiées ou une expérience médicale.
6.2.4.6 La manière dont l’archétype peut être utilisé dans la fourniture de soins de santé de qualité.
6.2.4.7 Les processus de soins qu’il est conçu pour prendre en charge.
6.2.4.8 Des informations sur les organisations, organismes professionnels ou gouvernementaux qui
ont appliqué le modèle, la date de cette application et ses critères.
4 © ISO 2019 – Tous droits réservés

6.2.5 Une définition d’archétype doit inclure une déclaration de son statut de publication.
6.2.5.1 Une définition d’archétype peut évoluer à mesure d’une série d’états de publication, par exemple
un processus d’approbation, sans autre modification. Ces états successifs doivent être conservés comme
faisant partie de l’archétype à des fins d’expertise. Cependant, la modification du statut de publication
d’un archétype ne doit pas elle-même constituer une révision formelle de l’identifiant qui référence
l’archétype dans un EHR_EXTRACT, puisque la spécification de contrainte n’est pas modifiée.
6.2.6 Le statut de publication d’un archétype doit spécifier les informations suivantes.
6.2.6.1 Le statut de publication de cet archétype, pris dans la liste qui suit:
— essai;
— en développement;
— candidat à la publication;
— rejeté;
— définitif;
— déconseillé.
6.2.6.2 La date à laquelle ce statut de publication particulier s’applique
NOTE La première instance d’un statut de publication pour cet archétype est également la date à laquelle il a
été composé en premier lieu.
6.2.6.3 L’identifiant unique de la personne consignant cet archétype dans le référentiel et affirmant
ainsi ce statut de publication. Cette identification peut facultativement inclure l’organisation que cette
personne représente.
6.2.6.4 L’identifiant unique de l’organisme autorisant ce changement de statut de publication.
6.2.6.5 La date à laquelle il est prévu que le statut de publication présent, et le contenu de l’archétype
lui-même, soient révisés pour confirmer leur validité.
6.2.6.6 L’identifiant unique de la personne ou de l’organisation qui est nominée, autorisée ou qui a
accepté la responsabilité de la révision de la validité de l’archétype et facultativement, sa mise à jour, le
cas échéant.
6.2.6.7 Une déclaration claire de toute restriction de droits d’auteur ou d’autorisation d’exploitation
qui s’applique à l’utilisation de l’archétype.
6.2.6.8 Le titulaire des droits d’auteur et/ou l’autorité dirigeante.
6.2.7 Gestion des versions.
6.2.7.1 La définition d’un archétype doit indiquer la version des contraintes qu’il spécifie.
6.2.7.2 La définition d’un archétype peut indiquer la personne ou l’organisation responsable de la
version.
6.2.7.3 La définition d’un archétype peut indiquer la date à laquelle la version actuelle a été créée.
6.2.7.4 Les identifiants de version de l’a
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...