The ISO 13606 standard

What it the objective of ISO 13606? What are archetypes? How can I use it to enable semantic interoperability of health data? In this section you will learn the basics of ISO 13606.


NOTICE: The new ISO 13606:2019

ISO 13606 has been revised by ISO and published under the reference ISO 13606:2019. The previous norm, ISO 13606:2008 is now withdrawn. This page includes information about the 2008 version, although the main principles of the standard remain intact.

What is ISO 13606?

ISO 13606 is a standard from the International Standardization Organization (ISO), originally designed by the European Committee for Standardization (CEN).

The overall objective of the ISO 13606 standard is to define a rigorous and stable information architecture for communicating part or all of the electronic health record (EHR) of a single subject of care (patient) between EHR systems, or between EHR systems and a centralized EHR data repository. It may also be used for EHR communication between an EHR system and clinical applications or middleware components (such as decision support components) that need to access EHR data, or as the representation of EHR data within a distributed (federated) record system.

Dual model architecture

To achieve this objective, ISO 13606 follows a Dual Model architecture. The Dual Model architecture defines a clear separation between information and knowledge. The former is structured through a Reference Model that contains the basic entities for representing any information of the EHR. The latter is based on archetypes, which are formal definitions of clinical information models, such as discharge report, glucose measurement or family history, in the form of structured and constrained combinations of the entities of a Reference Model. It provides a specific semantic meaning to a Reference Model structure. The combination of the Reference Model (to represent data instances) and the Archetype Model (to semantically describe those data) provides a powerful capability of evolution to the information systems. Clinical information models (archetypes) may change in the future, but data will always remain interoperable.

Semantic interoperability

Interoperability is the ability of diverse systems and organizations to work together seamlesly. That means exchanging information and using the information that has been exchanged. Two types of interoperability can be defined.

Syntactic Interoperability
If two or more systems are capable of communicating and exchanging data by using the same data formats or communication protocols. XML and JSON are examples of data exchange formats.

Semantic Interoperability
It is the ability to automatically interpret the information exchanged meaningfully and accurately in order to produce useful results for end users. To achieve semantic interoperability, both sides must defer to a common information exchange reference model. The content of the information exchange requests are unambiguously defined: what is sent is the same as what is understood.

In the field of health information, to achieve semantic interoperability is even a more important and difficult duty. The complexity of the health domain, its frequent variation and evolution and the differences between the information technologies domain and the health domain need a deep change on the methodologies of information management. New proposals have arisen during the last decade to solve the problem of semantic interoperability of health information. Among them, the dual model approach is the most promising approach. Having not only an information reference model but also a concept model that permits to build complex domain concepts eases the transition from just data structures to semantically interoperable knowledge.

Where can I find the complete ISO 13606 specifications?

You can buy the complete standard specifications at the ISO web page, or translated (in some countries) through your national standardization organization. You can also check your University or Organization library to know if you have free access to the specifications. Additionally, you can read the ISO 13606-1 introduction section freely.

ISO 13606 is composed of five parts. Parts 1, 2 and 3 are the most relevant for a basic implementation of the standard.


ISO 13606 reference model

A Reference Model is an Object-Oriented model that is used to represent the generic and stable properties of health record information. It includes a small set of classes that define the generic building blocks to construct EHRs. It specifies how health data should be aggregated to create more complex data structures and the context information that must accompany every piece of data in order to meet ethical and legal requirements. It does encode what it is meant, not how it is intended to be presented. ISO 13606 Reference Model contains:

  • A set of classes to represent clinical information, defining the building blocks of EHRs. Any annotation in an EHR must be an instance of one of these classes. ISO 13606 defines six clinical classes: folder, composition, section, entry, cluster and element. Additionally, it includes a class to represent an EHR Extract.
  • A set of classes to represent context information to be attached to an EHR annotation, including versioning information.
  • A set of classes to describe demographic data.
  • A set of classes to represent data types.

Clinical information

The main classes that contain clinical information in ISO 13606 are represented in the following diagram.

  • EHR_EXTRACT: The top-level container of part or all of the EHR of a single subject of care, for communication between an EHR Provider system and an EHR Recipient.
  • FOLDER: The high level organisation within an EHR, dividing it into compartments relating to care provided for a single condition, by a clinical team or institution, or over a fixed time period such as an episode of care. Examples of FOLDER are Diabetes care, Schizophrenia, Cholecystectomy, Paediatrics, St Mungo’s Hospital, GP Folder, Episodes 2000-2001, Italy.
  • COMPOSITION: The set of information committed to one EHR as a result of a clinical encounter or a record documentation session. Examples of COMPOSITION are Progress note, Laboratory test result form, Radiology report, Referral letter, Clinic visit, Clinic letter, Discharge summary, Functional health assessment, Diabetes review.
  • SECTION: EHR data within a COMPOSITION that belongs under one clinical heading, usually reflecting the flow of information gathering during a clinical encounter, or structured for the benefit of future human readership. Examples of SECTION are Reason for encounter, Past history, Family History, Allergy information, Subjective symptoms, Objective findings, Analysis, Plan, Treatment, Diet, Posture, Abdominal examination, Retinal examination.
  • ENTRY: The information recorded in an EHR as a result of one clinical action, one observation, one clinical interpretation, or an intention. This is also known as a clinical statement. Examples of ENTRY are a symptom, an observation, one test result, a prescribed drug, an allergy reaction, a diagnosis, a differential diagnosis, a differential white cell count, blood pressure measurement.
  • CLUSTER: The means of organising nested multi-part data structures such as time series, list or tables. Examples of CLUSTER are Audiogram results, electro-encephalogram interpretation, weighted differential diagnoses.
  • ELEMENT: The leaf node of the EHR hierarchy, containing a single data value. Each ELEMENT contains data of a particular Data Type. Examples of ELEMENT are Systolic blood pressure, heart rate, drug name, symptom, body weight.

Context information

Context information refers to all data that accompanies clninical data and helps to correctly interpret it. For exampla, data about the subject of care, the date and time of the clinical session, the time of data registry, the author, the legal authenticator, and information about any other participant in the health care process. ISO 13606 represents all that data using the following classes.

  • Audit_info: This class represents the committal and revision data of the clinical classes of the reference model. It helps to identify the information system and time at which clinical data was committed and therefore became part of that EHR of the subject of care. It also identifies the committer (the party responsible for committing the information), the version and the reason for revision.
  • Related_Party: This class identifies a person in terms of his or her relationship to the subject_of_care. For example, the mother of the patient.
  • Functional_Role: This class is used to document the participation of a person, device or software component in some activity recorded in the EHR. It includes the identifier of the entity, the function or role that was performed, the mechanism by which that participation was made, the organization at which the role was performed, and the type of service location at which the role was performed.
  • Attestation_info: This class documents the details of any attestations of the clinical information. The attestation is a mechanism whereby the attester can provide his or her authority that those contents are, in his or her opinion, correct. It includes a coded value giving the reason for this attestation, the date and time at which this attestation occurred, the instance identifiers of the information classes that was/were attested, the identification and role of the person making the attestation, a representation of the reproducible rendering (image or presentation specification) that was actually viewed by the attester, and the electronic signature (as encapsulated data, or as reference to it) that verifies the attestation.

Demographic information

All clinical and context information represented in an ISO 13606 instance can include an identifier that references to the entity that the information refers to, or that performed a particular role during the health care activity. These entities can be a person (subject of care or health profesional), organizations, or devices. ISO 13606 includes a set of classes that represent identification and detailed data about all these entities.

The objective of the ISO 13606 demographic classes is not to support the development of a complete demographic information server, but to allow the communication of the relevant demographic data of all participants in the EHR that is being documented. Thus, in case the receiver system does not have accesss to a shared demographic server, it can at least identify the main participants in the clinical acts.

Data types

ISO 13606:2008 uses the data types specified in the technical specification TS 14796 Health informatics – Data types. The next figure shows a summary of the main data types used in the standard.


ISO 13606 archetypes

An archetype is a representation of a clinical information model. That means that it defines a particular configuration of the reference model, with a specific meaning. For example, an archetype can represent the information structure that corresponds to a vital signs measurement, la laboratory test, or a complete family history report.

You can see an example of an archetype in the following figure, as seen in LinkEHR Studio archetype editor:


Archetypes are only templates or guidelines on how to combine the classes of the reference model to build something that is meaningful. Actual data will be represented as data instances of the reference model. Archetypes will only help to understand that data.

Archetypes are built by combining and constraining the existent classes of the reference model. To build an archetype, we have to define the structure and organization of the classes, select the data types, and constrain the range of possible values that can be registered. Additionally, archetypes can be mapped to terminologies in order to provide a specific meaning for the information structure, thus making it semantically interoperable.

Another powerful chacteristic of archetypes is their reusability. Archetypes that are defined can afterwards be reused by combining them into more complex archetypes, by specializing them to fit particular scenarios of use, and by versioning them to align to new requirements.

Archetype Definition Language (ADL)

Archetypes can be expressed using a formal language called Archetype Definition Language (ADL). This language was originally defined by openEHR and has been adopted by ISO 13606. In particular, ISO 13606:2008 supports ADL 1.4.

ADL specifications can be found in the openEHR web page: ADL 1.4 Specifications


ISO 13606 data instances

When you build an ISO 13606 data instance, you have to bear in mind wo rules:

  • The instance has to be sintactically compliant with the reference model. Most commonly, this means creating XML documents that are valid with regard to the ISO 13606 XML Schema.
  • Optionally, the instanceto can be compliant to the specifications of one or more archetypes that define a specific clinical information model. The archetypes will provide specific information about the meaning of the instance data structures, and the data contraints that apply.

The following code is an example of the minimal ISO 13606 EHR Extract data instance. In this example, it does not follow any archetype specification.

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="en13606/en13606.xslt"?>
<!-- EXTRACT -->
<EHR_EXTRACT xmlns:xsi="" xsi:noNamespaceSchemaLocation="en13606/EN13606-extract.xsd">
    <ehr_system xsi:type="II">
        <root xsi:type="OID">
    <ehr_id xsi:type="II">
        <root xsi:type="OID">
    <subject_of_care xsi:type="II">
        <root xsi:type="OID">
    <time_created xsi:type="TS">
    <rm_id>UNE-EN 13606-1:2007</rm_id>

    <!-- Content: a COMPOSITION -->
    <all_compositions xsi:type="COMPOSITION">
        <name xsi:type="SIMPLE_TEXT">
            <originalText>Minimal document</originalText>

        <rc_id xsi:type="II">
            <root xsi:type="OID">


        <committal xsi:type="AUDIT_INFO">
            <ehr_system xsi:type="II">
                <root xsi:type="OID">
            <time_committed xsi:type="TS">
            <committer xsi:type="II">
                <root xsi:type="OID">

        <!-- CONTENT: an ENTRY -->
        <content xsi:type="ENTRY">
            <name xsi:type="SIMPLE_TEXT">
                <originalText>Minimal example</originalText>

            <rc_id xsi:type="II">
                <root xsi:type="OID">



            <!-- CONTENT: an ELEMENT -->
            <items xsi:type="ELEMENT">
                <name xsi:type="SIMPLE_TEXT">

                <rc_id xsi:type="II">
                    <root xsi:type="OID">


                <!-- VALUE: a SIMPLE_TEXT -->
                <value xsi:type="SIMPLE_TEXT">