SIST EN ISO 13606-4:2026

SLOVENSKI STANDARD
01-november-2026
Nadomešča:
SIST EN ISO 13606-4:2019
Zdravstvena informatika - Komunikacija z elektronskimi zdravstvenimi zapisi - 4.
del: Varnost (ISO 13606-4:2026)
Health informatics - Electronic health record communication - Part 4: Security (ISO
13606-4:2026)
Medizinische Informatik - Kommunikation von Patientendaten in elektronischer Form -
Teil 4: Sicherheit (ISO 13606-4:2026)
Informatique de santé - Communication du dossier de santé informatisé - Partie 4:
Sécurité (ISO 13606-4:2026)
Ta slovenski standard je istoveten z: EN ISO 13606-4:2026
ICS:
35.030 Informacijska varnost IT Security
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-4
EUROPEAN STANDARD
NORME EUROPÉENNE
September 2026
EUROPÄISCHE NORM
ICS 35.240.80 Supersedes EN ISO 13606-4:2019
English Version
Health informatics - Electronic health record
communication - Part 4: Security (ISO 13606-4:2026)
Informatique de santé - Communication du dossier de Medizinische Informatik - Kommunikation von
santé informatisé - Partie 4: Sécurité (ISO 13606- Patientendaten in elektronischer Form - Teil 4:
4:2026) Sicherheit (ISO 13606-4:2026)
This European Standard was approved by CEN on 23 August 2026.

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, Türkiye 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
© 2026 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN ISO 13606-4:2026 E
worldwide for CEN national Members.

Contents Page
European foreword . 3

European foreword
This document (EN ISO 13606-4:2026) 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 March 2027, and conflicting national standards shall
be withdrawn at the latest by March 2027.
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 ISO 13606-4:2019.
Any feedback and questions on this document should be directed to the users’ national standards
body/national committee. A complete listing of these bodies can be found on the CEN website.
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, Türkiye and the
United Kingdom.
Endorsement notice
The text of ISO 13606-4:2026 has been approved by CEN as EN ISO 13606-4:2026 without any
modification.
International
Standard
ISO 13606-4
Second edition
Health informatics — Electronic
2026-08
health record communication —
Part 4:
Security
Informatique de santé — Communication du dossier de santé
informatisé —
Partie 4: Sécurité
Reference number
ISO 13606-4:2026(en) © ISO 2026

ISO 13606-4:2026(en)
© ISO 2026
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
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
ISO 13606-4:2026(en)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviations . 2
5 Conformance . 2
6 Record Component Sensitivity and Functional Roles. 3
6.1 RECORD_COMPONENT sensitivity .3
6.2 Functional roles .3
6.3 Mapping of Functional Role to COMPOSITION sensitivity .4
7 Representing access policy information within an EHR_EXTRACT . 4
7.1 Overview .4
7.2 UML representation of the archetype of the access policy COMPOSITION .6
7.3 Access policy model properties .7
7.3.1 Access policy .7
7.3.2 Target . .7
7.3.3 Request criterion .8
7.3.4 Sensitivity constraint .9
7.3.5 Attestation information .10
7.4 Archetype of the access policy COMPOSITION .11
8 Representing audit log information .11
8.1 General .11
8.2 EHR audit log extract . 12
8.3 Audit log constraint . 12
8.4 EHR audit log entry . . 13
8.5 EHR extract description .14
8.6 Demographic extract. 15
Annex A (informative) Illustrative access control example .16
Annex B (informative) Relations of this document to alternative approaches .20
Bibliography .22

iii
ISO 13606-4: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).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
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, in collaboration with
the European Committee for Standardization (CEN) Technical Committee CEN/TC 251, Health informatics, in
accordance with the Agreement on technical cooperation between ISO and CEN (Vienna Agreement).
[1]
This second edition cancels and replaces the first edition (ISO 13606-4:2019 ), of which it constitutes a
minor revision. The changes are as follows:
— the tables in Clause 7 and Clause 8 have been numbered;
— the examples in Annex B have been anonymized;
— corrections were made to Clause 2 and Clause 3 to reflect the technical content of the document.
[2]
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.

iv
ISO 13606-4:2026(en)
Introduction
0.1  General
This document is part of a series including five parts. In this document, dependency upon any of the other
parts of this series is explicitly stated where it applies.
0.2  Challenge addressed by this document
The communication of electronic health records (EHRs) in whole or in part, within and across organisational
boundaries, and sometimes across national borders, is challenging from a security perspective. Health
records should be created, processed and managed in ways that assure the confidentiality of their contents
and legitimate control by subjects of care in how they are used. Around the globe, these principles are
progressively becoming enshrined in national data protection legislation. These instruments declare that
the subject of care has the right to play a pivotal role in decisions on the content and distribution of their
EHR, as well as the right to be informed of its contents. The communication of health record information to
third parties should normally take place only with consent from the subject of care (which can be any freely-
given specific and informed indication of their wishes, by which the data subject signifies their agreement to
personal data relating to them being processed in an ethically-acceptable way) . More details can be found in
[3] [4]
ISO 22600-3 . For EHR communication across national borders, ISO 22857 provides guidance that can
be used to define appropriate security policy specifications.
Ideally, each fine-grained entry in a subject of care’s record should only be accessed by those persons who
have permissions to view that information, specified by or approved by the subject of care and reflecting
the dynamic nature of the set of persons with legitimate duty of care towards the subject of care through
their lifetime. The access control list will ideally also include those persons who have permissions to access
the data for reasons other than a duty of care (such as health service management, epidemiology and public
health, consented research) but exclude any information that they do not need to see or which the subject
of care feels is too personal for them to access. On the opposite side, the labelling by subjects of care or
their representatives of information as personal or private should ideally not hamper those who legitimately
need to see the information in an emergency, nor accidentally result in genuine healthcare providers having
such a filtered perspective that they are misled into managing the subject of care inappropriately. Subject
1)
of care’s views on the inherent sensitivity of entries in their health records can evolve over time, as their
personal health anxieties alter or as societal attitudes to health problems change. Subjects of care might
wish to offer some heterogeneous levels of access to family, friends, carers and members of their community.
Families might wish to provide a means by which they are able to access parts of each other’s records (but
not necessarily to equal extents) in order to monitor the progress of inherited conditions within a family
tree.
Such a set of requirements is arguably more extensive than that required of the data controllers in most
other industry sectors. It is in practice made extremely complex by:
— the large number of health record entries made on a subject of care during the course of modern
healthcare;
— the large number of healthcare personnel, often rotating through posts, who can potentially come into
contact with a subject of care at any one time;
— the large number of healthcare organisations with which a subject of care can come into contact during
their lifetime;
— the difficulty (for a subject of care or for anyone else) of classifying in a standardized way how sensitive
a record entry can be;
— the difficulty of determining how important a single health record entry can be to the future care of a
subject of care, and to which classes of user;
1) The term sensitivity is widely used in the security domain for a broad range of safeguards and controls, but in this
document the term refers only to the characteristic of a resource (EHR data) that implies its value or importance (and by
implication the extent of confidentiality and therefore to the functional roles that should have access to it).

v
ISO 13606-4:2026(en)
— the logically indelible nature of the EHR and the need for revisions to access permissions to be rigorously
managed in the same way as revisions to the EHR entries themselves;
— the need to determine appropriate access very rapidly, in real time, and potentially in a distributed
computing environment;
— the high level of concern expressed by a growing minority of subjects of care to have their consent for
disclosure recorded and respected;
— the low level of concern the majority of subjects of care have about these requirements, which has
historically limited the priority and investment committed to tackling this aspect of EHR communications.
To support interoperable EHRs, and seamless communication of EHR data between healthcare providers,
the negotiation required to determine if a given Requester for EHR data should be permitted to receive the
data should be capable of automation. If automated negotiation were not possible, the delays and workload
of managing human decisions for all or most record communications would obviate any value in striving for
data interoperability.
The main principles of the approach to standards development in the area of EHR communications access
control are to match the characteristics and parameters of a request to the EHR provider’s policies, and
to any access control or consent declarations within the specified EHR, to maintain appropriate evidence
of the disclosure, and to make the overall access decision process capable of automated processing. In
practice, efforts are in progress to develop international standards for defining access control and privilege
management systems that would be capable of computer-to-computer negotiation. However, this kind
of work is predicated upon health services agreeing a mutually consistent framework for defining the
privileges they wish to assign to staff, and the spectrum of sensitivity they offer for subjects of care to define
within their EHRs. This requires consistency in the way the relevant information is expressed, to make this
sensibly scalable at definition-time (when new EHR entries are being added), at run-time (when a whole EHR
is being retrieved or queried), and durable over a subject of care’s lifetime. It is also important to recognize
that, for the foreseeable future, diversity will continue to exist between countries on the specific approaches
to securing EHR communications, including differing legislation, and that a highly prescriptive approach to
standardization is not presently possible.
This document therefore does not prescribe the access rules themselves. It does not specify who should
have access to what and by means of which security mechanisms; these need to be determined by user
communities, national guidelines and legislation. However, it does define a basic framework that can be used
as a minimum specification of EHR access policy, and a richer generic representation for the communication
of more fine-grained detailed policy information. This framework complements the overall architecture
[5]
defined in ISO 13606-1 , and defines specific information structures that are to be communicated as part
[5]
of an EHR_EXTRACT defined in ISO 13606-1 . Some of the kinds of agreement necessary for the security of
EHR communication are inevitably outside the scope of this document, and are covered more extensively in
[6]
the ISO 22600 series.
It should be noted that there are a number of explicit and implicit dependencies on use of other standards
alongside this document, for overall cohesion of an interoperable information security deployment. In
addition to agreement about the complete range of appropriate standards, a relevant assurance regime
would be required (which is beyond the scope of this document).
0.3  Communication scenarios
0.3.1 Data flows
The interfaces and message models required to support EHR communication are the subject of ISO 13606-5
[7]
. The description here is an overview of the communications process in order to show the interactions for
which security features are needed. Figure 1 illustrates the key data flows and scenarios that are considered
by this document. For each key data flow there will be an acknowledgement response, and optionally a
rejection may be returned instead of the requested data.

vi
ISO 13606-4:2026(en)
Figure 1 — Principal data flows and security-related business processes covered by this document
The EHR Requester, EHR Recipient and Audit Log Reviewer can be healthcare professionals, the subject of
care, a legal representative or another party with sufficient authorization to access healthcare information.
Both the EHR_EXTRACT and the audit log, if provided, might need to be filtered to limit the disclosure to
match the privileges of the Recipient. This aspect of access control is discussed later in this introduction (all
parties shown here will need to maintain an audit log, not just the EHR Provider. However, for readability
the other audit log processes are not shown or described here).
The following subclauses describe each data flow in Figure 1.
0.3.2  Request EHR data
This interaction is not always required (for example, EHR data might be pushed from Provider to Recipient
as in the case of a discharge summary). The request interface needs to include a sufficient profile of the
Requester to enable the EHR Provider to be in a position to make an access decision, to populate an audit log,
and provide the appropriate data to the intended Recipient. In some cases the EHR Requester might not be
the same party as the EHR Recipient – for example a software agent might trigger a notification containing
EHR data to be sent to a healthcare professional. In such cases it is the EHR Recipient’s credentials that will
principally determine the access decision to be made.
An EHR request might need to include or reference consents for access and mandates for care, for example
by providing some form of explicit consent from the subject of care, or a care mandate.
The negotiation between Requester and Provider of EHR data will increasingly be automated, and the
information included in this interaction should be sufficient to enable a fully computerised policy negotiation.

vii
ISO 13606-4:2026(en)
The requirements for this interaction will be reflected in the REQUEST_EHR_EXTRACT interface model
[7]
defined in ISO 13606-5 .
0.3.3  Generate EHR access log entry
This is assumed practice in any EHR system, but it is not specified as a normative interface because of the
diverse approaches and capabilities in present-day systems. The internal audit systems within any EHR
system are not required to be interoperable except in support of the model defined in Clause 8 of this
[7]
document and the corresponding interface defined in ISO 13606-5 .
0.3.4  Acknowledge receipt of the EHR request
No healthcare-specific security considerations.
0.3.5 Make access decision, filter EHR data
When processing the EHR request, policies pertaining to the EHR Provider and access policies in the EHR
itself all need to be taken into account in determining what data are extracted from the target EHR. This
document cannot dictate the overall set of policies that might influence the EHR Provider, potentially
deriving from national, regional, organisation-specific, professional and other legislation.
A decision to filter the EHR data on the basis of its sensitivity and the privileges of the EHR Requester and
Recipient will need to conform to relevant policies and might need to balance the clinical risks of denying
access to information with the medico-legal risks of releasing information.
This document however does define an overall framework for representing in an interoperable way the
access policies that might relate to any particular EHR, authored by the subject of care or representatives.
These might not be stored in the physical EHR system in this way; they might instead, for example, be
integrated within a policy server linked to the EHR server.
This access decision is discussed in more detail in Clause 7.
0.3.6  Deny provision of the EHR_EXTRACT
If the access decision is to decline, a coarse-grained set of reasons needs to be defined in order to frame a
suitable set of responses from the EHR Provider. However, it is important that the denial and any reason
given does not imply to the Recipient that the requested EHR data does exist – even the disclosure of its
existence could itself be damaging to a subject of care.
[7]
No healthcare-specific security considerations– the interface model is defined in ISO 13606-5 .
0.3.7  Provide the EHR_EXTRACT
It should be noted that the EHR Recipient need not be the same as an EHR Requester, and indeed the provision
of an EHR need not have been triggered by a request. It might instead have been initiated by the provider as
part of a shared care pathway or to add new data to an existing EHR.
[5]
The EHR_EXTRACT is required to conform to the Reference Model defined in ISO 13606-1 , and to the
[7]
interface model defined in ISO 13606-5 .
The EHR_EXTRACT should include or reference any relevant access policies, represented in conformance
with this document, to govern any onward propagation of the EHR data being communicated. Policies may
only be referenced if the EHR Recipient is known to have direct access to the same information by another
means.
0.3.8  Acknowledge receipt of EHR_EXTRACT
No healthcare-specific security considerations.
0.3.9  Generate EHR access log entry
As described in 0.3.3.
0.3.10  Request EHR access log view

viii
ISO 13606-4:2026(en)
This is now considered to be desirable practice, to enable a subject of care to discover who has accessed
part or all of their EHR in an information-sharing environment. The scope of this interface, as defined in
this document, is to request a view of the audit log that informs the Recipient about who has accessed what
parts of his or her EHR within a given EHR system, and when. This interface is not intended to support
situations where a full inspection of an audit log is required for legal purposes or for other investigations.
This interface is discussed in Clause 6.
[7]
The interface model is defined in ISO 13606-5 .
0.3.11  Generate EHR access log entry
As described in 0.3.3.
0.3.12  Provide EHR access log view
This is desirable practice, and requires an interoperable representation of such an entry (or set of entries).
This interface is discussed in Clause 6.
Although a legal investigation will require that an audit log is provided in a complete and unmodified form,
the presentation of an audit log view to a subject of care or to a healthcare professional might require that
some entries are filtered out (such as those referring to EHR data to which the subject of care does not have
access).
[7]
The interface model is defined in ISO 13606-5 .
0.3.13  Deny EHR access log view
If the request is not to be met, a coarse-grained set of reasons needs to be defined. However, it is important
that the denial and any reason given does not imply to the Recipient that the requested EHR data does exist
– even the disclosure of its existence could itself be damaging to a subject of care.
No healthcare-specific security considerations – the interface model is defined in ISO 13606-5.
0.3.14  Acknowledge receipt of EHR access log view
No healthcare-specific security considerations.
0.3.15  Generate EHR access log entry
As described in 0.3.3.
0.4  Requirements and technical approach
0.4.1  Generic healthcare security requirements
The most widely accepted requirements for an overall security approach in domains handling sensitive and
[8]
personal data are published in ISO/IEC 27002 . This specifies the kinds of measures that should be taken
to protect assets such as EHR data, and ways in which such data might safely be communicated as part of a
distributed computing environment. A health specific guide to this general standard has been published in
[9]
ISO 27799 . This will facilitate the formulation of common security polices across healthcare, and should
[6]
help promote the adoption of interoperable security components and services. The ISO 22600 series
defines a comprehensive architectural approach to formally and consistently defining and managing such
[4]
policies. For EHR communication across national borders ISO 22857 provides guidance that can be used
to define appropriate security policy specifications.
The exact security requirements that need to be met to permit any particular EHR communication instance
will be governed by a number of national and local policies at both the sending and receiving sites, and
at any intermediate links in the communications chain. Many of these policies will apply to healthcare
communications in general, and will vary between countries and clinical settings in ways that cannot and
should not be directed by this document. The approach taken in drafting this document has therefore been
to assume that generic security policies, components and services will contribute to a negotiation phase (the
“access decision”) prior to sanctioning the communication of an EHR Extract, and will protect the actual
EHR data flows.
ix
ISO 13606-4:2026(en)
This document therefore requires that an overall security policy or set of policies conforming to ISO 27799
[9]
is in place at all of the sites participating in an EHR communication, and assumes that these policies
conform to national or trans-border data protection legislation. Additional policies might be required to
conform to specific national, local, professional or organisation regulations applicable to the communication
or use of EHR data. Defining such policies is beyond the scope of this document.
0.4.2  Relationship to other related security standards
Legitimate access to EHR data will be determined by a wide range of policies, some of which might exist
as documents, some will be encoded within applications, and some within formal authorization system
components. It is recognized that vendors and organisations differ in how they have implemented access
control policies and services, and the extent to which these are presently computerized.
[6]
The ISO 22600 series defines a generic logical model for the representation of the privileges of principals
(entities), of access control policies that pertain to potential target objects, and of the negotiation process
that is required to arrive at an access decision. Figure 2 depicts the concepts of Role Based Access Control
[6]
defined in the ISO 22600 series.
[6]
Figure 2 — Main concepts and policy types defined in Role Based Access Control (ISO 22600
series)
Defining constraints on roles, processes, target objects and related privileges by policies, Figure 2 turns into
[6]
Figure 3, according to the ISO 22600 series.
Figure 3 — Policy-driven RBAC Schema

x
ISO 13606-4:2026(en)
As illustrated in Figure 3, principals (persons, agents etc.) are mapped to one or more Functional Roles,
which will be influenced by the Structural Roles that they are permitted to hold. For example, a person
who is medically qualified and a specialist in child health might hold one or more Structural Roles (such
as Consultant Paediatrician at a hospital, Head of Child Screening for the region). Those Structural Roles
might permit him or her at times to act with the Functional Role of Personal Clinician to a subject of care.
The Functional Role might be persistent or limited to a single user session. Functional Roles are mapped
to permissions to perform particular operations (such as writing new entries in an EHR) and to particular
objects (such as the EHR data which that role-holder is permitted to view).
For the purposes of this document, the Target_Component class shown in Figure 3 is the EHR data held
by the EHR Provider. The Permission_Assignment association defines policies to permit or deny access to
part or all of the EHR, which need also to be communicated to the EHR Recipient for onward adoption and
[6]
propagation. Whilst this document assumes the adoption of the ISO 22600 series, it is acknowledged that
national operational structures and terminology will differ and that variances will be possible. However,
this document only specifies the policy model as a framework to communicate actual access policies in an
interoperable way. It does not itself define the content of the access policies that are to be determined at
jurisdictional or more local levels.
[10]
As a complement to that standard, ISO 21298 define sets of Structural Roles and Functional Roles that
can be used internationally to support policy negotiation and policy bridging (for example during the
[10]
negotiation phase of an access decision). This document also assumes the adoption of ISO 21298 , and
aligns with it.
The relationship of the policy model defined in this document to the HL7 Healthcare Privacy and Security
Classification System is explained in Annex B.
[11]
ISO 27789 defines a comprehensive representation of audit log and audit trail information relating to
all of the events that can occur within electronic health record systems. This includes the communication
of EHR data between repositories and systems. This document assumes conformance to that standard, and
[11]
defines a profile (sub-set) of the ISO 27789 audit log model specifically for the purpose of communicating
with subjects of care and other authorized parties’ information about who has accessed the EHR of a
specified subject of care, when and why.
[12]
A large number of EHR-specific medico-legal and ethical requirements are expressed within ISO 18308 ,
although conformity with these is primarily met through specific classes and attributes of the EHR Reference
[5] [2] [12]
Model (published in ISO 13606-1 ). The ISO 13606 series enables conformity to ISO 18308 , and
this document specifically enables conformance to its ethical and legal requirements and fair information
principles.
05  EHR access policy model
0.5.1  Overall approach
[5]
In the ISO 13606-1 Reference Model every COMPOSITION within the EHR_EXTRACT includes an optional
access_policy_ids attribute to permit references to such policies to be made at any level of granularity within
the EHR containment hierarchy. Every COMPOSITION may therefore reference any number of access policies
or consent declarations that define the intended necessary privileges and profiles of principals (users, agents,
software, devices, delegated actors, etc.) for future access to the referenced EHR data. The information
model in Clause 7 for representing and communicating access policy information has been deliberately kept
very generic, to allow for the diversity of policy criteria that will be stipulated in different countries and
regional healthcare networks. Standardized vocabularies for some of the main properties of the model are
defined as default term lists. Although it is recommended that these be adopted whenever they are suitable,
it is recognised that jurisdictions might have requirements or legislation or existing investments that mean
that they cannot adopt these internationally-standardised term lists. This document therefore permits
jurisdictions to declare conformance using alternative term lists.
Health and care environments increasingly comprise complex networks of agencies and actors from
traditional healthcare settings, social care, informal carers and voluntary agencies (such as welfare
charities), subjects of care themselves, families and sometimes their social networks. All of these might at
times establish agreements to permit data sharing of personal health data. Given the dynamic nature of this
“virtual care team” it can be impractical for these data sharing agreements to be negotiated in traditional

xi
ISO 13606-4:2026(en)
human-to-human, document-based ways. It is therefore likely that such agencies will establish framework
agreements that specify in advance the standards they each conform with, any mappings between their
respective domains of privilege and how data are to be handled within each such privilege domain. As
stated above, this policy model permits jurisdictions to instead declare alternative term lists that they will
use. This allows for some flexibility in adoption of this document, recognising that complex data sharing
environments might need to establish new, potentially richer, vocabularies to describe the wider range of
actors and roles in that environment.
A number of existing and legacy systems might be unable to incorporate richly-defined policy specifications,
and many healthcare regions might not be in a position to define such policies for some years. Therefore,
as a complement to the overall policy model in Clause 7, this document defines two classifications that can
provide a minimum basis for making an access policy decision, and ensure a basic level of access policy
interoperability, albeit at a coarse-grained level.
These two vocabularies are:
a) a sensitivity classification of EHR data (at the level of COMPOSITION);
b) a high-level classification of EHR Requesters and Recipients, through a set of Functional Roles.
0.5.2 Defining “need-to-know” when handling EHR data
Within many healthcare environments (within and between collaborating healthcare teams involved in
the direct provision of care to subjects of care) the norm is to share health record information openly. It
is indeed the wish of the vast majority of subjects of care that teams do this, and many subjects of care are
actually surprised at how little of their health record is shared today when it should be, for safety and for
good continuity of care.
Few contemporary healthcare systems (on paper or electronically) define complex internal access control
partitions to the health records that they hold. Even if it were considered useful to define numerous fine-
grained access policies, in practice it might take healthcare systems, national health services and millions of
subjects of care quite a long time to specify suitable access control policies for all of their EHR data, and to
implement software components that can perform many complex policy-bridging computations in real time.
Maintenance of these policies as the clinical care requirements of each subject of care evolve would also be
a complex process.
While a suite of access policies might in theory be defined (by subjects of care or by others) to provide a
multilevel access framework within any given EHR, in practice most clinical settings operate on the basis
of default privileges granted throughout the health record to any healthcare or health-related professional
who has a legitimate interest in that subject of care. (The definition of who has such a legitimate interest will
vary between organisations, and is not the scope of this document.) However, it is also well accepted that
subjects of care and professionals might at times need to restrict access to some more personally-sensitive
EHR data. It is also common in most health services to ring-fence certain clinical settings as having exclusive
portions of an EHR (for example, sexual health clinics).
This kind of ring-fencing of clinical settings or the marking of EHR data as particularly sensitive is quite
distinct from any sub-divisions of the EHR that might be defined to assist navigation and workflow within
clinical specialties, for example by defining cancer or diabetes portions within the EHR. Figure 4 provides
an illustration of the way in which an EHR might logically be subdivided from a need-to-know point of
view, in which the confidentiality classification (sensitivity) is represent
...