ISO 13606-2:2008

INTERNATIONAL ISO
STANDARD 13606-2
First edition
2008-12-01

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:2008(E)
©
ISO 2008

---------------------- Page: 1 ----------------------
ISO 13606-2:2008(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.


COPYRIGHT PROTECTED DOCUMENT


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

ii © ISO 2008 – All rights reserved

---------------------- Page: 2 ----------------------
ISO 13606-2:2008(E)
Contents Page
Foreword. iv
Introduction . v
1 Scope . 1
2 Conformance. 1
3 Normative references . 1
4 Terms and definitions. 2
5 Symbols and abbreviations . 3
6 Archetype representation requirements . 4
6.1 General. 4
6.2 Archetype definition, description and publication information. 4
6.3 Archetype node constraints . 6
6.4 Data value constraints. 8
6.5 Profile in relation to EN 13606-1 Reference Model. 10
7 Archetype model. 11
7.1 Introduction . 11
7.2 Overview . 14
7.3 The archetype package . 18
7.4 The archetype description package. 20
7.5 The constraint model package . 24
7.6 The assertion package . 31
7.7 The primitive package . 35
7.8 The ontology package. 42
7.9 The domain extensions package . 44
7.10 The support package. 47
7.11 Generic types package. 56
7.12 Domain-specific extensions (informative) . 57
8 Archetype Definition Language (ADL). 58
8.1 dADL — Data ADL. 58
8.2 cADL — Constraint ADL. 79
8.3 Assertions . 106
8.4 ADL paths . 110
8.5 ADL — Archetype definition language . 111
Bibliography . 123

© ISO 2008 – All rights reserved iii

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

---------------------- Page: 4 ----------------------
ISO 13606-2:2008(E)
Introduction
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 series of International Standards, 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 the names, structure and
context required for it to be interpreted faithfully on receipt, even if its organization 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 be 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 to safely process EHR data that have
come from heterogeneous sources.
Archetypes
The challenge for EHR interoperability is therefore to devise a generalized approach to representing every
conceivable kind of health record data structure in a consistent way. This needs to cater for records arising
from any profession, speciality or service, whilst recognising that the clinical data sets, value sets, templates,
etc., required by different 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 part of ISO 13606 distinguishes a Reference Model, used to represent the
generic properties of health record information, and Archetypes (conforming to an Archetype Model), which
are metadata 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 ISO 13606 series of
International Standards, the Reference Model is defined in ISO 13606-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 ISO 13606-5).
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 subclasses, defining or constraining their names and other
relevant attribute values, optionality and multiplicity at any point in the hierarchy, the data types and value
ranges that ELEMENT data values may take, and may include other dependency constraints. Archetype
© ISO 2008 – All rights reserved v

---------------------- Page: 5 ----------------------
ISO 13606-2:2008(E)
instances themselves conform to a formal model, known as an Archetype Model (which is a constraint model,
also specified as an ODP Information Viewpoint Model). Although the Archetype Model is stable, individual
archetype instances may 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 may be used within EHR systems to govern the EHR data committed to a repository. However, for
the purposes of this interoperability standard, no assumption is made about the use of archetypes within the
EHR provider system whenever this standard is used for EHR communication. It is assumed that the original
EHR data, if not already archetyped, may be mapped to a set of archetypes, if desired, when generating the
EHR_EXTRACT.
The Reference Model defined in ISO 13606-1 has attributes 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. The meaning attribute, in the case of archetyped data, refers to the
primary concept to which the corresponding archetype node relates. However, it should be noted that
ISO 13606-1 does not require that archetypes be used to govern the hierarchy of RECORD_COMPONENTS
within an EHR_EXTRACT; the archetype-related attributes are optional in that model. It is recognised that the
international adoption of an archetype approach will be gradual, and may take some years.
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 currently 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. The use of standardized 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 organizations and professional bodies in the
development of archetypes will enable this approach to contribute to the pursuit of quality evidence-based
clinical practice. The next key challenge is to foster communities to build up libraries of archetypes. It is
beyond the scope of this part of ISO 13606 to assert how this work should be advanced, but, in several
countries so far it would appear that national health programmes are beginning to organize clinical-
informatics-vendor teams to develop and operationalize 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 useage will also require
processes to verify and certify the quality of shared archetypes, which are also beyond the scope of this part
vi © ISO 2008 – All rights reserved

---------------------- Page: 6 ----------------------
ISO 13606-2:2008(E)
of ISO 13606 but are being taken forward by non-profit-making organizaitons such as the openEHR
Foundation and the EuroRec Institute.
Communicating archetypes
This part of ISO 13606 specifies the requirements for a comprehensive and interoperable archetype
representation, and defines the ODP Information Viewpoint representation for the Archetype Model and an
optional archetype interchange format called Archetype Definition Language (ADL).
This part of ISO 13606 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 be capable of being mapped to the Archetype Model
defined in this part of ISO 13606 in order to support EHR communication and interoperability within an
EHR-sharing community.
Overview of the archetype model
This section provides a general informative description of the model that is specified in Clause 7.
The overall archetype model consists of identifying information, a description (its metadata), a definition
(expressed in terms of constraints on instances of an object model), and an ontology. Identifying information
and lifecycle state are part of the ARCHETYPE class. The archetype description is separated into revision
history information and descriptive information about the archetype. Revision history information is concerned
with the committal of the archetype to a repository, and takes the form of a list of audit trail items, while
descriptive information describes the archetype itself (regardless of whether it has been committed to a
repository of any kind).
The archetype definition, the “main” part of the archetype model, is an instance of a C_COMPLEX_OBJECT,
since the root of the constraint structure of an archetype shall always take the form of a constraint on a non-
primitive object type. The fourth main part of the archetype model, the ontology, is represented by its own
class, and is what allows the archetypes to be natural-language- and terminology-neutral.
An enumeration class, VALIDITY_KIND, is also included in the archetype package. This is intended to be
used as the type of any attribute in this constraint model whose value is logically “mandatory”, “optional”, or
“disallowed”. It is used in this model in the classes C_Date, C_Time and C_Date_Time.
Archetypes contain some natural language elements, including the description and ontology definitions. Every
archetype is therefore created in some original language, which is recorded in the original_language attribute
of the ARCHETYPE class. An archetype is translated by doing the following:
⎯ translating every language-dependent element into the new language;
⎯ adding a new TRANSLATION_DETAILS instance to ARCHETYPE.translations, containing details about
the translator, organization, quality assurance and so on.
The languages_available function provides a complete list of languages in the archetype.
The archetype definition
The main definitional part of an archetype consists of alternate layers of object- and attribute-constraining
nodes, each containing the next level of nodes. In this section, the word “attribute” refers to any data property
of a class, regardless of whether it is regarded as a “relationship” (i.e. association, aggregation, or
composition) or a “primitive” (i.e. value) attribute. At the leaves are primitive object constrainer nodes
constraining primitive types such as String, Integer, etc. There are also nodes that represent internal
references to other nodes, constraint reference nodes that refer to a text constraint in the constraint binding
part of the archetype ontology, and archetype constraint nodes, which represent constraints on other
archetypes allowed to appear at a given point.
© ISO 2008 – All rights reserved vii

---------------------- Page: 7 ----------------------
ISO 13606-2:2008(E)
The full list of node types is as follows:
⎯ C_complex_object: any interior node representing a constraint on instances of a non-primitive type, e.g.
ENTRY, SECTION;
⎯ C_attribute: a node representing a constraint on an attribute (i.e. UML “relationship” or “primitive
attribute”) in an object type;
⎯ C_primitive_object: a node representing a constraint on a primitive (built-in) object type;
⎯ Archetype_internal_ref: a node that refers to a previously defined object node in the same archetype; the
reference is made using a path;
⎯ Constraint_ref: a node that refers to a constraint on (usually) a text or coded term entity, which appears in
the ontology section of the archetype, and in ADL, and is referred to using an “acNNNN” code; the
constraint is expressed in terms of a query on an external entity, usually a terminology or ontology;
⎯ Archetype_slot: a node whose statements define a constraint that determines which other archetypes
may appear at that point in the current archetype; logically it has the same semantics as a
C_COMPLEX_OBJECT, except that the constraints are expressed in another archetype, not the current
one.
The archetype description
What is normally considered the “metadata” of an archetype, i.e. its author, date of creation, purpose, and
other descriptive items, is described by the ARCHETYPE_DESCRIPTION and
ARCHETYPE_DESCRIPTION_ITEM classes. The parts of this that are in natural language, and therefore
may require translated versions, are represented in instances of the ARCHETYPE_DESCRIPTION_ITEM
class. If an ARCHETYPE_DESCRIPTION has more than one ARCHETYPE_DESCRIPTION_ITEM, each of
these should carry exactly the same information in a different natural language.
When an archetype is translated for use in another language environment, each
ARCHETYPE_DESCRIPTION_ITEM needs to be copied and translated into the new language.
The AUDIT_DETAILS class is concerned with the creation and modification of the archetype in a repository.
Each instance of this class in an actual archetype represents one act of committal to the repository, with the
attributes documenting who, when and why.
NOTE Revision of an archetype should be limited to modifying the descriptive information and adding language
translations and/or term bindings. If the definition part of an archetype is no longer valid it should instead be replaced with
a new archetype to ensure that corresponding EHR data instances each conform to the same archetype specification.
The archetype ontology
All linguistic entities are defined in the ontology part of the archetype. There are four major parts in an
archetype ontology: term definitions, constraint definitions, term bindings and constraint bindings. The former
two define the meanings of various terms and textual constraints which occur in the archetype; they are
indexed with unique identifiers that are used within the archetype definition body. The latter two ontology
sections describe the mappings of terms used internally to external terminologies.
Archetype specialization
Archetypes may be specialized: an archetype is considered a specialization of another archetype if it specifies
that archetype as its parent, and only makes changes to its definition such that its constraints are “narrower”
than those of the parent. Any data created via the use of the specialized archetype shall be conformant both
to it and to its parent.
Every archetype has a “specialization depth”. Archetypes with no specialization parent have depth 0, and
specialized archetypes add one level to their depth for each step down a hierarchy required to reach them.
viii © ISO 2008 – All rights reserved

---------------------- Page: 8 ----------------------
ISO 13606-2:2008(E)
Archetype composition
Archetypes may be composed to form larger structures semantically equivalent to a single large archetype.
Archetype slots are the means of composition, and are themselves defined in terms of constraints.
Data types and the support package
The model is dependent on three groups of assumed types, whose names and assumed semantics are
described by ISO/IEC 11404.
The first group comprises the most basic types:
⎯ Any
⎯ Boolean
⎯ Character
⎯ Integer
⎯ Real
⎯ Double
⎯ String
The second comprises the assumed library types:
⎯ date
⎯ time
⎯ date_time
⎯ duration
These types are supported in most implementation technologies, including XML, Java and other programming
languages. They are not defined in this specification, allowing them to be mapped to the most appropriate
concrete types in each implementation technology.
The third group comprises the generic types:
⎯ List (ordered, duplicates allowed)
⎯ Set (unordered, no duplicates)
⎯ Hash (keyed list of items of any type)
⎯ Interval (interval of instances of any ordered type)
Although these types are supported in most implementation technologies, they are not yet represented in UML.
The semantics of these types are therefore defined in the Generic_Types package of the UML model.
The remaining necessary types are defined in the Support Package of the Archetype Model.
⎯ ARCHETYPE_ID
⎯ HIER_OBJECT_ID
⎯ TERMINOLOGY_ID
© ISO 2008 – All rights reserved ix

---------------------- Page: 9 ----------------------
ISO 13606-2:2008(E)
⎯ CODE_PHRASE
⎯ CODED_TEXT
The support package also includes two enumeration classes to provide controlled data sets needed by this
part of ISO 13606.
The constraint model package
Any archetype definition is an instance of a C_COMPLEX_OBJECT, which expresses constraints on a class
in the underlying Reference Model (see ISO 13606-1), recorded in the attribute rm_type_name. A
C_COMPLEX_OBJECT consists of attributes of the type C_ATTRIBUTE, which are constraints on the
attributes (i.e. any property, including relationships) of that Reference Model class. Accordingly, each
C_ATTRIBUTE records the name of the constrained attribute (in rm_attribute_name), the existence and
cardinality expressed by the constraint (depending on whether the attribute it constrains is a multiple or single
relationship), and the constraint on the object to which this C_ATTRIBUTE refers via its children attribute
(according to its reference model) in the form of further C_OBJECTs.
The key subtypes of C_OBJECT are:
⎯ C_COMPLEX_OBJECT
⎯ C_PRIMITIVE_OBJECT
⎯ ARCHETYPE_SLOT
ARCHETYPE_INTERNAL_REF and CONSTRAINT_REF are used to express, respectively, a “slot” where
further archetypes may be used to continue describing constraints; a reference to a part of the current
archetype that expresses exactly the same constraints needed at another point; a reference to a constraint on
a constraint defined in the archetype ontology, which in turn points to an external knowledge resource, such
as a terminology.
The effect of the model is to create archetype description structures that are a hierarchical alternation of object
and attribute constraints. The repeated object/attribute hierarchical structure of an archetype provides the
basis for using paths to reference any node in an archetype. Archetype paths follow a syntax that is a subset
of the W3C Xpath syntax.
All node types
All nodes in an archetype constraint structure are instances of the supertype ARCHETYPE_CONSTRAINT,
which provides a number of important common features to all nodes.
The any_allowed Boolean, if true, indicates that any value permitted by the reference model for that attribute
is allowed by the archetype; its use permits the logical idea of a completely “open” constraint being simply
expressed, avoiding the need for any further substructure.
Attribute nodes
Constraints on attributes are represented by instances of the two subtypes of C_ATTRIBUTE:
C_SINGLE_ATTRIBUTE and C_MULTIPLE_ATTRIBUTE. For both subtypes, the common constraint is
whether the corresponding instance (defined by the rm_attribute_name attribute) must exist. Both subtypes
have a list of children, representing constraints on the object value(s) of the attribute.
Single-valued attributes are constrained by instances of the type C_SINGLE_ATTRIBUTE, which uses the
children to represent multiple alternative object constraints for the attribute value.
Multiple-valued attributes are constrained by an instance of C_MULTIPLE_ATTRIBUTE, which allows multiple
co-existing member objects of the container value of the attribute to be constrained, along with a cardinality
constraint, describing ordering and uniqueness of the container.
x © ISO 2008 – All rights reserved

---------------------- Page: 10 ----------------------
ISO 13606-2:2008(E)
Cardinality is only required for container objects such
...