prEN ISO 13606-1

• Abstract:

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

• Status: Not Published
• Publication Date: 19-Dec-2027
• ICS: 35.240.80 - IT applications in health care technology
• Technical Committee: CEN/TC 251 - Medical informatics
• Drafting Committee: CEN/TC 251/WG 1 - Information models
• Current Stage: 4060 - Closure of enquiry - Enquiry
• Start Date: 21-Sep-2026
• Completion Date: 21-Sep-2026
• Ref Project: oSIST prEN ISO 13606-1:2026 - Health informatics - Electronic health record communication - Part 1: Reference model (ISO/DIS 13606-1:2026)

• Revises: EN ISO 13606-1:2019 - Health informatics - Electronic health record communication - Part 1: Reference model (ISO 13606-1:2019)
• Effective Date: 22-Jan-2025

prEN ISO 13606-1 is the CEN and ISO draft for Health informatics - Electronic health record communication - Part 1: Reference model. It specifies a reference model for communicating part or all of an electronic health record (EHR) between EHR systems, repositories, clinical applications, middleware, and personal health applications and devices. The model is aimed at implementers who need to exchange, archive, or reference EHR data while preserving clinical meaning, provenance, and confidentiality.

What does prEN ISO 13606-1 specify?

prEN ISO 13606-1 specifies how to represent EHR content for communication, not how to build the internal database or architecture of an EHR system. It is an Information Viewpoint specification, so it defines the structure and semantics of exchanged EHR information in a way that supports safe interoperability.

The document is organized into clauses covering terms, overview, common record-component properties, elements and data values, EHR components, the EHR_EXTRACT, demographics, and conformance. It also includes three informative annexes.

Annex	What it covers
Annex A	The ISO 21090:2011 profile for the datatypes used in this series, including the mapping to DATA_VALUE specializations and the treatment of null_flavor
Annex B	Alignment work with Health Level Seven (HL7) Fast Healthcare Interoperability Resources (FHIR)
Annex C	Cross-domain interoperability, the Interoperability Reference Architecture Model, and a glossary

The scope is broad enough for direct care, self-care, and population monitoring systems such as registries and public health surveillance. Uses such as teaching, clinical audit, administration, reporting, service management, research, and epidemiology are not the focus, although they may still benefit from the model.

What are the key requirements of prEN ISO 13606-1?

prEN ISO 13606-1 is built around a stable reference model, explicit versioning, and a strict hierarchy for EHR communication. In practice, that means a system must be able to identify each communicated component, preserve its history, carry the relevant context, and express it in a form that can be processed consistently by the receiving system.

Versioning, provenance, and attestation

Clause 6 defines base properties such as rc_id, previous_version, version_set_id, version_status, and reason_for_revision. These fields let the recipient keep track of what was communicated, what it revises, and the medico-legal status of the version. That matters when extracts are reused, updated, or audited later.

Clause 6.2 defines ATTESTATION_INFO. It records the component being attested, the time, the attester, the reason for attestation, the mechanism used, and optionally the proof and the attested view. In practice, this is how the model carries evidence that a person certified the content and what they actually saw.

Clause 6.3 defines AUDIT_INFO as a minimum profile on ISO 27789. It records the committer, audited event, action code, timestamp, and source system, with the extract limited to create, update, and delete actions. That gives traceability for revision histories and security investigations.

EHR extract structure and metadata

Clause 9 makes EHR_EXTRACT the root node for communication. It identifies the EHR provider system, the EHR itself, the creation time, the optional authorising party, the reference model identifier, and any access policy identifiers. For a reader, this is the metadata that tells the recipient where the extract came from and how it should be governed.

The EHR_EXTRACT content is arranged in four parts: a folder hierarchy of COMPOSITIONs, an optional DEMOGRAPHIC_EXTRACT, an optional EXTRACTED_COMPONENTS set for linked content, and access policy information. This structure matters because it lets a recipient interpret the extract on its own, even when external demographic services are not available.

Hierarchy and clinical content

Clause 8 defines the core clinical hierarchy: FOLDER, COMPOSITION, SECTION, ENTRY, ITEM, CLUSTER, and ELEMENT. A FOLDER groups COMPOSITIONs; a COMPOSITION contains CONTENT; CONTENT can be a SECTION or an ENTRY; ITEM can be a CLUSTER or an ELEMENT; and ELEMENT is the leaf node with a single DATA_VALUE. That is the main pattern implementers use when mapping consultations, reports, observations, and similar records.

Clause 8 also requires subject_of_care for an EHR_EXTRACT folder, and it requires separate folders when a composition concerns someone other than the main subject of care. That prevents mixed-person content from being merged into one undifferentiated record.

Clause 8.3 adds composer, sensitivity, and policy_ids to COMPOSITION. Clause 8.5 adds subject_of_information_category and information_provider to ENTRY, and Clause 8.6 adds emphasis to ITEM. In practice, these fields preserve who created the content, how sensitive it is, who provided the information, and what the author considered noteworthy.

Linking and referencing

Clause 6.4 defines LINK and EXTERNAL_LINK, including link_description, target, source, target_system, and target_information_type. The model uses links to reference components in the same EHR, another EHR for the same subject of care, demographic components, attestations, and information in external systems. This is important because it avoids duplication while keeping cross-references explicit.

Clause 9.3 defines EXTRACTED_COMPONENT_SET for structure components that must be included as targets for links. That makes sure referenced content can travel with the extract when needed, so the recipient does not lose the context needed to interpret the links.

Data values and datatype constraints

Clause 7 defines DATA_VALUE and the allowed specializations used when creating archetypes. The document uses a constrained subset of ISO 21090:2011 and states that implementations claiming conformance shall not use the listed excluded attributes from classes such as ANY, HXIT, II, ED, and TEL.URL. In practice, this keeps data values predictable and aligned with the profile the series expects.

The allowed value types cover text, coded values, quantities, dates and times, identifiers, URIs, binary attachments, and related forms. If a value is absent, the model allows omission of the DATA_VALUE and recording the reason through null_flavor, using the term list in Part 3. That is useful when a clinical item is required but the value is genuinely unavailable.

Demographics and access control

Clause 10 defines the demographic side of the model, including DEMOGRAPHIC_EXTRACT, DEMOGRAPHIC_FOLDER, DEMOGRAPHIC_ENTITY, DEMOGRAPHIC_ITEM, DEMOGRAPHIC_CLUSTER, and DEMOGRAPHIC_ELEMENT. This supports describing persons, devices, software agents, and organisations once and reusing those identities across the extract. For implementers, it reduces repetition and supports matching to local or shared demographic services.

Clause 9 also carries access policy identifiers, and the overview notes alignment with Part 4 and ISO 27789. That makes the extract usable in controlled environments where access rights must travel with the data or be resolved against an external policy service.

Conformance

Clause 11 says a system is conformant if all information exchanged within the scope of the document can be expressed with a direct correspondence to the UML information model of the EHR_EXTRACT in Clauses 5 to 10. In practice, conformance means the sender and receiver can map the communicated structure to the standard model without losing the intended meaning.

What terms does prEN ISO 13606-1 define?

prEN ISO 13606-1 defines the core actors and concepts used throughout the model. These terms matter because they separate clinical responsibility, technical action, and record content.

• attester - the person who certifies and records legal responsibility for a unit of information.
• committer - the party, device, or software whose direct actions cause information to be committed.
• composer - the healthcare actor responsible for creating, synthesising, or organising information that enters the EHR.
• subject of care - the person seeking, receiving, or having received care.
• electronic health record (EHR) - the health record whose information is stored on electronic media.
• archetype - an instance of the archetype model that specifies clinical concepts and value constraints for record components.
• healthcare process - the set of related healthcare activities that transforms inputs into outputs.

Who uses prEN ISO 13606-1?

prEN ISO 13606-1 is used by EHR system vendors, repository operators, and interoperability architects who need a common extract model for exchange. It is also relevant to developers of clinical applications, middleware, personal health applications, and connected devices that must read or supply EHR data.

Quality, privacy, and audit teams use it when they need clear provenance, attestation, revision history, and access-policy handling. Public health and registry teams can use it when communicating identifiable records or population-monitoring data. Healthcare information modelers use it to design archetypes and map clinical content into a stable extract structure.

What changed in prEN ISO 13606-1 from the previous edition?

prEN ISO 13606-1 is described as the third version of the original standard published in 2007 by CEN and in 2008 by ISO. The revision aligns as far as possible with other CEN and ISO standards and technical specifications, international terminology standards, HL7 FHIR, and the openEHR reference model and archetype models.

The overview also states an updated approach to participation: the LINK class is used to reference demographic entities, and roles can be labelled using the extended term lists in Part 3. Compared with the previous version, this gives more flexibility in where references to demographic entities are represented within the record-component hierarchy.

Which standards are used with prEN ISO 13606-1?

Clause 2 lists no normative references, but the document is built and aligned with several companion standards and related profiles.

Standard or part	What it contributes
ISO/IEC 10746-1	The Information Viewpoint basis for the model
ISO 18308	EHR architecture requirements that frame the overall approach
ISO 13940	Shared concepts and harmonized definitions across the series
ISO 21090:2011	The datatype profile used for DATA_VALUE specializations and Annex A
ISO 27789	The audit-trail profile used for AUDIT_INFO and alignment in the series
ISO 22600 series	Access control alignment for Part 4
Part 2 of this series	Archetype interchange syntax and the archetype_id syntax
Part 3 of this series	Term lists and code sets, including role labels and link descriptions
Part 4 of this series	Access policy information and sensitivity-related handling
Part 5 of this series	EHR exchange interfaces and messages in distributed environments
HL7 FHIR	Ongoing alignment work described in Annex B
openEHR reference model and archetype models	Technical alignment cited in the overview

What does the prEN ISO 13606-1 document contain?

prEN ISO 13606-1 contains UML models, attribute tables, relationship tables, and textual guidance for the EHR extract and demographics hierarchy. It also provides datatype profiles and annex material for ISO 21090 mapping, HL7 FHIR alignment, and cross-domain interoperability.

For design and implementation work, the most practical parts are the class diagrams for BASE_COMPONENT, ATTESTATION_INFO, AUDIT_INFO, LINK, ELEMENT, EHR_EXTRACT, and the demographic classes, plus the tables that define their properties and associations. Annex C adds figures and a glossary that are useful when analyzing interoperability architecture and documenting how the model fits wider cross-domain integration work.

SLOVENSKI STANDARD
01-september-2026
Zdravstvena informatika - Komunikacija z elektronskimi zdravstvenimi zapisi - 1.
del: Referenčni model (ISO/DIS 13606-1:2026)
Health informatics - Electronic health record communication - Part 1: Reference model
(ISO/DIS 13606-1:2026)
Medizinische Informatik - Kommunikation von Patientendaten in elektronischer Form -
Teil 1: Referenzmodell (ISO/DIS 13606-1:2026)
Informatique de santé - Communication du dossier de santé informatisé - Partie 1:
Modèle de référence (ISO/DIS 13606-1:2026)
Ta slovenski standard je istoveten z: prEN ISO 13606-1
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.

DRAFT
International
Standard
ISO/DIS 13606-1
ISO/TC 215
Health informatics — Electronic
Secretariat: ANSI
health record communication —
Voting begins on:
Part 1: 2026-06-29
Reference model
Voting terminates on:
2026-09-21
Informatique de santé — Communication du dossier de santé
informatisé —
Partie 1: Modèle de référence
ICS: 35.240.80
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENTS AND APPROVAL. IT
IS THEREFORE SUBJECT TO CHANGE
AND MAY NOT BE REFERRED TO AS AN
INTERNATIONAL STANDARD UNTIL
PUBLISHED AS SUCH.
This document is circulated as received from the committee secretariat.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
ISO/CEN PARALLEL PROCESSING
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
NATIONAL REGULATIONS.
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
PROVIDE SUPPORTING DOCUMENTATION.
Reference number
ISO/DIS 13606-1:2026(en)
DRAFT
ISO/DIS 13606-1:2026(en)
International
Standard
ISO/DIS 13606-1
ISO/TC 215
Health informatics — Electronic
Secretariat: ANSI
health record communication —
Voting begins on:
Part 1:
Reference model
Voting terminates on:
Informatique de santé — Communication du dossier de santé
informatisé —
Partie 1: Modèle de référence
ICS: 35.240.80
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENTS AND APPROVAL. IT
IS THEREFORE SUBJECT TO CHANGE
AND MAY NOT BE REFERRED TO AS AN
INTERNATIONAL STANDARD UNTIL
PUBLISHED AS SUCH.
This document is circulated as received from the committee secretariat.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
© ISO 2026
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
STANDARDS MAY ON OCCASION HAVE TO
ISO/CEN PARALLEL PROCESSING
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
BE CONSIDERED IN THE LIGHT OF THEIR
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
or ISO’s member body in the country of the requester.
NATIONAL REGULATIONS.
ISO copyright office
RECIPIENTS OF THIS DRAFT ARE INVITED
CP 401 • Ch. de Blandonnet 8
TO SUBMIT, WITH THEIR COMMENTS,
CH-1214 Vernier, Geneva
NOTIFICATION OF ANY RELEVANT PATENT
Phone: [phone]
RIGHTS OF WHICH THEY ARE AWARE AND TO
PROVIDE SUPPORTING DOCUMENTATION.
Email: [e-mail]
Website: www.iso.org
Published in Switzerland Reference number
ISO/DIS 13606-1:2026(en)
ii
ISO/DIS 13606-1:2026(en)
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
3.1 Actors .1
3.2 Concepts and terms .3
3.3 Information management .3
3.4 Privacy and security .5
3.5 Process management .6
4 Abbreviations . 6
5 Overview . 6
5.1 Overview of the reference model .6
5.2 Representing roles and responsibilities within the EHR _EXTRACT .7
5.2.1 General .7
5.2.2 Actors playing a role in the actual healthcare process .7
5.2.3 Actors contributing to the process of documenting care within the EHR .8
5.2.4 Actors confirming the validity of the EHR documentation .8
5.2.5 Subject of care .8
5.2.6 Composer .9
5.2.7 Committer .9
5.2.8 Subject of information .9
5.2.9 Information provider .10
5.3 About the use of datatypes in this document .10
6 Common Properties of Record Components .11
6.1 Base, record and structure components .11
6.1.1 General .11
6.1.2 Base component . 12
6.1.3 Electronic health record component . 13
6.1.4 Structure component . 15
6.2 Attestation .16
6.2.1 General .16
6.2.2 Attestation information .17
6.3 Audit information .18
6.4 Linking record components .21
6.4.1 General .21
6.4.2 Link usages .21
6.4.3 Communicating referenced record components . 23
6.4.4 Link . 23
6.4.5 External link .24
7 Elements and data values .25
7.1 General . 25
7.2 Data value. 26
7.2.1 Boolean .27
7.2.2 Attachment . 28
7.2.3 String . 30
7.2.4 Simple text .31
7.2.5 Coded simple value .31
7.2.6 Coded value .32
7.2.7 Instance identifier . 34
7.2.8 URI.37
7.2.9 Physical quantity . . 38

iii
ISO/DIS 13606-1:2026(en)
7.2.10 Duration . 39
7.2.11 Real . 39
7.2.12 Integer . 40
7.2.13 Instant .41
7.2.14 Date .42
7.2.15 Time .42
7.2.16 Date time .43
7.2.17 Data value . 44
8 EHR Components .45
8.1 General .45
8.2 Folder . 46
8.2.1 General . 46
8.2.2 Folder .47
8.3 Compositions . . 48
8.3.1 General . 48
8.3.2 Composition . 48
8.4 Content and sections . 50
8.4.1 General . 50
8.4.2 Content . 50
8.4.3 Section .51
8.5 Entries .51
8.5.1 General .51
8.5.2 Entry .52
8.6 Items and clusters . . 53
8.6.1 Item . 53
8.6.2 Cluster . 54
8.7 Element . 55
9 EHR Extract . .56
9.1 General . 56
9.2 EHR extract . 56
9.3 Extracted component set .57
9.4 Demographic extract. 58
10 Demographics .59
10.1 General .59
10.2 Demographic folder . 60
10.3 Demographic entity .61
10.4 Demographic item .61
10.5 Demographic cluster .62
10.6 Demographic element . . 63
11 Conformance .64
[5]
Annex A (informative) About the ISO 21090:2011 profile for datatypes .65
Annex B (informative) Alignment with HL7 FHIR .69
Annex C (informative) Cross-Domain Interoperability .70
Bibliography .75

iv
ISO/DIS 13606-1:2026(en)
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 third edition cancels and replaces previous editions, which have been technically revised
— The scope of all parts remains the same.
— The alignment with HL7 FHIR and with the openEHR Reference Model has been improved, utilising the
[1]
guide published in ISO/PAS 24305 .
— The name attribute has been reinstated in this revision against circumstances to cater better for vendors
and providers who do not intend to use archetypes.
— The structural alignment with the openEHR Reference Model and archetype-based semantics has been
improved. However, the explicitly separate template layer that openEHR uses has not been introduced,
and is an area of consideration for future harmonisation guidance.
A list of all parts in the ISO 13606 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

v
ISO/DIS 13606-1:2026(en)
Introduction
0.1  Preface
The overall goal of this document is to define a rigorous and stable information architecture for exchanging
or archiving part or all of the electronic health record (EHR) of a single subject of care (patient), or for a
group of patients whose information might need to be communicated together (for example, a family). This is
to support the interoperability of systems (see Annex C). and components that need to communicate (access,
transfer, add or modify) EHR data. The information architecture defined in this document is intended to
support safe processing of exchanged EHR data by ensuring that the exchange can:
— preserve the original clinical meaning intended by the author;
— incorporate the necessary provenance metadata to inform the recipient or receiving system about the
context in which the EHR data were obtained and composed;
— observe and communicate the confidentiality of that data as intended by the author and subject of care .
This document considers the EHR to be the persistent longitudinal and potentially multi-organisation or
multi-national record of health and care provision, most often relating to a single subject of care (the patient),
created and stored in one or more physical systems. Its primary purpose is to support future healthcare for
the subject of care and to provide a medico-legal record of care delivered. This corresponds to the definition
[2]
provided in ISO 18308 .
This document is not intended to specify the internal architecture or database design of EHR systems or
components, nor is it intended to prescribe the kinds of clinical applications that might request or contribute
EHR data in particular settings, domains or specialities. For this reason, the information model proposed
here is called the EHR Extract, and might be used to define a message, an XML document or schema, or
an object interface. These might be used to communicate EHR data between two repositories, to update
a centralised regional or national EHR repository, or within a distributed network of EHR components,
systems and services. Whilst an EHR service or system will need to interact with many other services or
systems providing terminology, medical knowledge, guidelines, workflow, security, persons registries,
billing etc. this document has only touched on those areas if some persistent trace of such interactions is
required in the EHR itself, and therefore requires specific features in the reference model to communicate
that trace.
This document may offer a practical and useful contribution to the design of EHR systems but will primarily
be realised as a common set of external interfaces or messages built on otherwise heterogeneous clinical
systems. The components that might support an interface conforming to this document will be not only
electronic health record systems but also other middleware services such as security components, guideline
and workflow systems, alerting and decision support services, personal health systems and applications,
sensors and wearable devices, and medical knowledge management services. This document might also
prove useful for communicating data about individuals between electronic health record systems and
population registries, and also for conducting (approved) research using electronic health records.
This document is part of a five-part standard series, published jointly by CEN and ISO through the Vienna
Agreement.
In this document dependency upon any of the other parts of this series is explicitly stated where it applies.
0.2  Technical approach
This document is the third version of an original standard which was published in 2007 by CEN, and in 2008
[2]
by ISO. It meets the relevant requirements in ISO 18308 .
The revision has taken into account, and aligns as far as possible, with other CEN and ISO Standards and
Technical Specifications with which this document might also be used, with international terminology
standards and with emerging standards from HL7: Fast Healthcare Interoperability Resources (FHIR). The
specifications in this document have drawn from, and align as far as possible with, the reference model
specifications published by the openEHR Foundation, and with the archetype models published by the
openEHR Foundation.
vi
ISO/DIS 13606-1:2026(en)
The information model in this document is an Information Viewpoint of the ISO Reference Model for Open
[3]
Distributed Processing (ISO/IEC 10746-1 ). In practical terms, this document defines the structure and
semantics of EHR information to be exchanged, rather than prescribing technologies, storage architectures,
or deployment patterns.
Given the diversity of deployed EHR systems, this document permits optionality for many features of EHR
communication. However, a minimum level of prescription is required to ensure that EHR extracts can
be processed safely and consistently by EHR recipient systems. This is reflected in mandatory properties
within the models in Parts 1, 2 and 4 of this series, and through normative term lists (defined in Part 3).
0.3  The Dual Model approach
The challenge for EHR interoperability is to devise a generalised approach to representing every conceivable
kind of health record data structure in a consistent way. This needs to cater for records arising from any
profession, speciality or service, whilst recognising that the healthcare data sets, value sets and other
context-specific clinical content artefacts required by different healthcare domains will be diverse, complex
and will change frequently as clinical practice and medical knowledge advance. This requirement is part of
the widely acknowledged health informatics challenge of semantic interoperability .
The approach adopted by this standard series distinguishes a Reference Model, defined in this document
and used to represent the generic properties of health record information , and Archetypes (conforming
[4]
to an archetype model , defined in ISO 13606-2:2019 ), which are meta-data used to define patterns
for the specific characteristics of the healthcare data that represents the requirements of each particular
profession, speciality or service.
This document adopts a dual model approach based on a stable Reference Model and archetype constraints.
However, readers should note that openEHR operationalises a more explicit multi-level modelling pattern
in which archetypes define reusable domain concepts and templates apply context-specific constraints for
particular use cases, workflows and deployment settings. In this document, such template-level concerns
are not separated with the same degree of formality, and this has implications for granularity, semantic
governance and implementation guidance.
The Reference Model represents the global characteristics of health record components, how they are
aggregated, and the context information required to meet ethical, legal and provenance requirements.
This model defines the set of classes that form the generic building blocks of the EHR. It reflects the stable
characteristics of an electronic health record , and would be embedded in a distributed (federated) EHR
environment as specific messages or interfaces (as specified in Part 5 of this series).
This generic information model needs to be complemented by a formal method of communicating and
sharing the organisational structure of predefined classes of EHR fragment corresponding to sets of record
components made in particular clinical situations. These are effectively pre-coordinated combinations
of named RECORD_COMPONENT hierarchies that are agreed within a community in order to ensure
interoperability, data consistency and data quality.
An Archetype is the formal definition of prescribed combinations of the building-block classes defined in
the Reference Model for particular clinical domains or organisations. An archetype is a formal expression of
a distinct, domain-level concept, expressed in the form of constraints on data whose instances conform to the
reference model. For an EHR_EXTRACT, as defined in this document, an archetype instance specifies (and
effectively constrains) a particular hierarchy of RECORD_COMPONENT sub-classes, defining or constraining
their names and other relevant attribute values, optionality and multiplicity at any point in the hierarchy,
the data types and value ranges that ELEMENT data values may take, and other constraints.
This document recognises that archetypes (or equivalent clinical models) are not always directly
incorporated within the present-day architectures of electronic health record systems. This document
therefore does not mandate that archetypes are used within such systems. It does, however, require that
the clinical information models or equivalents (data items, data item aggregations, data value constraints,
terminology bindings, units of measure etc.) that have been used to generate an EHR_EXTRACT are
themselves created and communicated, or referenced, within each EHR_EXTRACT. These communicated or
referenced archetypes have to conform to Part 2 of this standard series, and maybe communicated through
an interface conforming to part 5 of this Standard series.

vii
ISO/DIS 13606-1:2026(en)
In this document, archetypes are the primary formal mechanism for expressing domain-level constraints
over the reference model. Where implementers use templates or equivalent contextual artefacts, these are
better understood as implementation-specific assemblies or refinements of archetypal content rather than
as a separately formalised modelling layer.
0.4 Overview of the EHR_EXTRACT record hierarchy
The information in a health record is inherently hierarchical. Clinical observations, reasoning and intentions
can have a simple or a more complex structure. They are generally organised under headings, and contained
in “documents” such as consultation notes, letters and reports. These documents are usually filed in folders,
and a subject of care may have more than one folder within a healthcare enterprise (e.g. medical, nursing,
and obstetric).
The EHR Communications Reference Model needs to reflect this hierarchical structure and organisation,
meeting published requirements in order to be faithful to the original clinical context and to ensure meaning
is preserved when records are communicated between heterogeneous clinical systems. To do this, the model
formally sub-divides the EHR hierarchy into parts that have been found to provide a consistent mapping to
the ways which individual EHRs are organised within heterogeneous EHR systems.
These parts are summarised in Table 1 below.
Table 1 — Main hierarchy components of the EHR Extract Reference Model
EHR HIERARCHY DESCRIPTION EXAMPLES
COMPONENT
EHR_EXTRACT The top-level container of part or all of the (Not applicable)
EHR of a single subject of care or for a group of
subjects of care (such as a family), for communi-
cation between an EHR Provider system and an
EHR Recipient.
FOLDER The high level organisation within an EHR, Diabetes care, Schizophrenia, Cholecys-
dividing it into compartments relating to care tectomy, Paediatrics, St Mungo’s Hospi-
provided to a single subject of care , for a single tal, GP Folder, Episodes 2000-2001.
condition, by a clinical team or institution, or
over a fixed time period such as an episode of
care.
COMPOSITION The set of information committed to one EHR Progress note, Laboratory test result
by one agent, as a result of a single clinical en- form, Radiology report, Referral letter,
counter or record documentation session. Clinic visit, Clinic letter, Discharge sum-
mary, Functional health assessment,
Diabetes review.
SECTION EHR data within a COMPOSITION that belongs Reason for encounter, Past history,
under one clinical heading, usually reflecting Family history, Allergy information
the flow of information gathering during a , Subjective symptoms, Objective
clinical encounter, or structured for the benefit findings, Analysis, Plan, Treatment,
of future human readership. Diet, Posture, Abdominal examination,
Retinal examination.
ENTRY The information recorded in an EHR as a result A symptom, an observation, one test
of one clinical action, one observation, one clin- result, a prescribed drug, an allergy
ical interpretation, or an intention. This is also reaction, a diagnosis, a differential di-
known as a clinical statement. agnosis, a differential white cell count,
blood pressure measurement.
CLUSTER The means of organising nested multi-part data Audiogram results, electro-encephalo-
structures such as time series, and to represent gram interpretation, weighted differen-
the columns of a table. tial diagnoses.
ELEMENT The leaf node of the EHR hierarchy, containing a Systolic blood pressure, heart rate, drug
single data value. name, symptom, body weight.
An EHR_EXTRACT contains EHR data as COMPOSITIONs, organised in a FOLDER hierarchy.
COMPOSITIONs contain ENTRYs, optionally contained within a SECTION hierarchy.

viii
ISO/DIS 13606-1:2026(en)
ENTRYs contain ELEMENTS, optionally contained within a CLUSTER hierarchy.
Representing participation: The Reference Model in the previous version of this standard provided explicit
classes at certain parts of the Record Component hierarchy through which it was possible to represent the
identity and roles played by actors contributing to healthcare and to its documentation. In this version of the
Reference Model the LINK class is intended to be used to reference demographic entities. The roles played
by these entities can be labelled using extended term lists defined in Part 3 of this standard series. This
updated mechanism offers greater flexibility than the previous version in where the references to such
democratic entities may be represented within the Record Component hierarchy.
Representing context: Any EHR_EXTRACT references any other RECORD_COMPONENTS that are
connected to the communicated content, for example via the RECORD_COMPONENT hierarchy and via LINK
targets. If the EHR exchange service (e.g. as specified in Part 5) permits access to referenced components,
any user would be able to access and review any additional areas of content that were not originally included.
(Archetypes bring together the key elements of immediate documentation context.)
Representing authenticity: Every EHR_EXTRACT may contain attested views: these might be PDF or html
or other renderings that are the authentic view of what was seen and persisted by the original author. The
proof may also optionally be included, which is the evidence of a digital signature .
EHR_EXTRACTS are created for specific purposes, and will not automatically guarantee that these will be fit
for other purposes.
0.5  Relationship of this standard to other relevant standards
[5]
— The data types used in this document are a profile of ISO 21090:2011 .
[6]
— Alignment has especially been undertaken with ISO 13940 . All of the terms and definitions within the
ISO 13606 series have been harmonised across the five parts, with most of the terms being in Part 1. All
[6]
of them have been aligned with ISO 13940 .
— An important 13606 FHIR profile project is in progress within HL7 (see Annex B). No challenges have
been identified with being able to create such a profile.
[7]
— Parts 1 and 4 align with ISO 27789 . Alignment in Part 4 has been maintained with ISO 22600 series .

ix
DRAFT International Standard ISO/DIS 13606-1:2026(en)
Health informatics — Electronic health record
communication —
Part 1:
Reference model
1 Scope
This document specifies a means for communicating, or preserving as an archive, part or all of the electronic
health record (EHR) of one or more identified subjects of care between EHR systems, or between EHR
systems and a centralised EHR data repository .
It can also be used for EHR communication between an EHR system or repository and clinical applications
or middleware components (such as decision support components), or personal health applications and
devices, that need to access or provide EHR data, or as the representation of EHR data within a distributed
(federated) record system.
This document will predominantly be used to support the direct care given to identifiable individuals or
self-care by individuals themselves, or to support population monitoring systems such as disease registries
and public health surveillance, animals, and events such as pollution, poisons, etc. . Uses of health records for
other purposes such as teaching, clinical audit, administration and reporting, service management, research
and epidemiology, which often require anonymization or aggregation of individual records, are not the focus
of this document but such secondary uses might also find the document useful.
[3]
This document is an Information Viewpoint specification as defined ISO/IEC 107
...