SIST EN ISO 13606-2:2019

SLOVENSKI STANDARD
01-september-2019
Nadomešča:
SIST EN 13606-2:2008
Zdravstvena informatika - Komunikacija z elektronskimi zdravstvenimi zapisi - 2.
del: Specifikacija za zamenjavo arhetipov (ISO 13606-2:2019)
Health informatics - Electronic health record communication - Part 2: Archetype
interchange specification (ISO 13606-2:2019)
Medizinische Informatik - Kommunikation von Patientendaten in elektronischer Form -
Teil 2: Spezifikation für den Austausch von Archetypen (ISO 13606-2:2019)
Informatique de santé - Communication du dossier de santé informatisé - Partie 2:
Spécification d'échange d'archétype (ISO 13606-2:2019)
Ta slovenski standard je istoveten z: EN ISO 13606-2:2019
ICS:
35.240.80 Uporabniške rešitve IT v IT applications in health care
zdravstveni tehniki technology
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN ISO 13606-2
EUROPEAN STANDARD
NORME EUROPÉENNE
July 2019
EUROPÄISCHE NORM
ICS 35.240.80 Supersedes EN 13606-2:2007
English Version
Health informatics - Electronic health record
communication - Part 2: Archetype interchange
specification (ISO 13606-2:2019)
Informatique de santé - Communication du dossier de Medizinische Informatik - Kommunikation von
santé informatisé - Partie 2: Spécification d'échange Patientendaten in elektronischer Form - Teil 2:
d'archétype (ISO 13606-2:2019) Spezifikation für den Austausch von Archetypen (ISO
13606-2:2019)
This European Standard was approved by CEN on 2 July 2019.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

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

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2019 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN ISO 13606-2:2019 E
worldwide for CEN national Members.

Contents Page
European foreword . 3

European foreword
This document (EN ISO 13606-2:2019) has been prepared by Technical Committee ISO/TC 215 "Health
informatics" in collaboration with Technical Committee CEN/TC 251 “Health informatics” the
secretariat of which is held by NEN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by January 2020, and conflicting national standards shall
be withdrawn at the latest by January 2020.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document supersedes EN 13606-2:2007.
According to the CEN-CENELEC Internal Regulations, the national standards organizations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland,
Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of
North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the
United Kingdom.
Endorsement notice
The text of ISO 13606-2:2019 has been approved by CEN as EN ISO 13606-2:2019 without any
modification.
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 13606-2:2019(E)
©
ISO 2019
ISO 13606-2:2019(E)
© 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

ISO 13606-2:2019(E)
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
ISO 13606-2:2019(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
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

ISO 13606-2:2019(E)
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.
ISO 13606-2:2019(E)
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

ISO 13606-2:2019(E)
(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]"}
ISO 13606-2:2019(E)
}
}
}
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

ISO 13606-2:2019(E)
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/
ISO 13606-2:2019(E)
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

ISO 13606-2:2019(E)
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.
ISO 13606-2:2019(E)
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

ISO 13606-2:2019(E)
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 pres
...