ISO 13606-4:2026

• Abstract:

  This document describes a methodology for specifying the privileges necessary to access electronic health record (EHR) data. This methodology forms part of the overall EHR communications architecture defined in ISO 13606-1 [17]. This document seeks to address those requirements uniquely pertaining to EHR communications and to represent and communicate EHR-specific information that will inform an access decision. It also refers to general security requirements that apply to EHR communications and points to technical solutions and standards that specify details on services meeting these security needs. NOTE Security requirements for EHR systems not related to the communication of EHRs are outside the scope of this document.

• Status: Published
• Publication Date: 25-Aug-2026
• ICS: 35.240.80 - IT applications in health care technology
• Technical Committee: ISO/TC 215 - Health informatics
• Drafting Committee: ISO/TC 215/WG 4 - Security, Safety and Privacy
• Current Stage: 6060 - International Standard published
• Start Date: 26-Aug-2026
• Due Date: 15-Jan-2028
• Completion Date: 26-Aug-2026

• Consolidates: EN ISO 13606-4:2026 - Health informatics - Electronic health record communication - Part 4: Security (ISO 13606-4:2026)
• Effective Date: 12-Feb-2026
• Consolidates: IEC/TR 63319:2025 - A meta-modelling analysis approach to smart manufacturing reference models
• Effective Date: 12-Apr-2025
• Revises: ISO 13606-4:2019 - Health informatics — Electronic health record communication — Part 4: Security
• Effective Date: 18-Jan-2025

Overview

ISO 13606-4:2026 – Health Informatics Electronic Health Record Communication: Part 4 – Security is an international standard developed by ISO/TC 215, specifically designed to address the security requirements of electronic health record (EHR) communications. This part forms an integral component of the broader ISO 13606 series, which sets out the architecture for EHR interoperability.

The standard outlines a methodology for specifying the access privileges necessary for EHR data, with an emphasis on defining, representing, and communicating EHR-specific information that supports access control decisions. ISO 13606-4:2026 focuses on the unique needs of securely sharing EHR data-across organizations and even international borders-while referring implementers to other standards for generic security measures.

Key Topics

• Access Privilege Specification: Defines a standard methodology for detailing who is permitted to access EHR data, integrating roles and data sensitivity mapping to inform access control decisions.
• EHR Communication Security: Addresses the confidentiality, integrity, and informed patient control over EHR data exchange, in line with evolving legal and ethical guidelines.
• Access Policy Representation: Establishes a communicable framework for representing EHR access policies, including mechanisms to express both coarse- and fine-grained policy details within EHR extracts.
• Functional Roles & Sensitivity Classification: Provides classifications for both user roles and EHR data sensitivity, allowing systems to automate decision-making regarding data disclosures.
• Audit Logging: Aligns EHR communication audit models with standards such as ISO 27789, ensuring traceability and accountability for all access to EHR data.
• Interoperability Framework: Ensures the security requirements are compatible with international data protection legislation and can be adapted for local or national policies.

Applications

ISO 13606-4:2026 is primarily leveraged by:

• Healthcare IT Vendors & System Integrators: When developing or updating EHR solutions, this standard enables structured specification and implementation of access control, supporting automation and interoperability.
• Hospitals, Clinics, and Health Networks: Ensures that shared patient records, especially across organizational or geographical boundaries, comply with well-defined security protocols while honoring patient consents and privacy preferences.
• Policy Makers & Compliance Managers: Provides a reference for establishing or auditing EHR communication policies within the context of local, national, or trans-border health information exchange.
• Researchers and Public Health Managers: Supports the secure sharing of EHR data for secondary uses, such as research or public health, while maintaining patient data confidentiality and ethical standards.

Typical scenarios for use include:

• Granting healthcare professionals, patients, or authorized third parties access to appropriate portions of EHRs based on role and data sensitivity.
• Automating policy-driven access decisions in distributed healthcare environments.
• Recording and communicating audit trails for every EHR disclosure or access event, supporting transparency and incident investigation.
• Filtering EHR extracts for recipients, so that only permissible data is disclosed.

Related Standards

ISO 13606-4:2026 is part of a network of closely related health informatics standards including:

• ISO 13606-1: Reference Model – Defines the core EHR communication architecture within which part 4 operates.
• ISO 13606-5: Interface Specification – Details the communication interfaces needed for secure EHR data exchange.
• ISO 22600: Privilege Management and Access Control – Offers comprehensive models for privilege definitions, roles, and automated access decisions.
• ISO 21298: Role Profiles – Standardizes healthcare functional and structural roles internationally.
• ISO 27799: Health Information Security Management – Guides the implementation of ISO/IEC 27002 security controls within health care.
• ISO 27789: Audit Trails – Provides detailed requirements for audit logging in EHR systems.
• ISO 22857 – Addresses security and privacy requirements for cross-border EHR communication.

By referencing and aligning with these standards, ISO 13606-4 facilitates robust, interoperable EHR communication security, helping healthcare organizations worldwide achieve compliance, interoperability, and patient trust in their digital health initiatives.

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 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: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
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
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
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
— 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
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
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
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
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
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
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 represented through classes of user, and for
particular care settings.
xii
Key
A private entries shared with GP
B entries restricted to sexual health team
C entries accessible to administrative staff
D entries accessible to clinical support staff
E entries accessible to direct care teams
F private entries shared with several named parties
G entries restricted to prison health services
Figure 4 — Access domains within an example EHR
In Figure 4, it is assumed that the subject of care has complete access to their EHR. The majority of this
subject of care’s EHR is accessible to any party providing direct clinical care. However, the EHR does contain
several private entries; some are restricted to the subject of care’s general (family) practitioner and some to
a separate list of named parties. The EHR also contains some entries created by and restricted to a sexual
health clinic, and others restricted to the prison health service – both can only be accessed by parties with
relevant additional privilege to that sub-domain (however, the subject of care can nominate other parties to
access these subsets of the EHR if they wish). One aspect of privilege is the assignment by an organisation
of roles to a clinician that can be exercised in an emergency that confer privileges that exceed those of their
normal role. Such an emergency override can, for example, confer access to a wider set of subject of care
records than is normally under the care of that clinician (such use of an emergency status would need to be
specifically logged and regularly reviewed).
Some parts of the EHR are deliberately also accessible to clinical support staff, who might need to review
certain clinical findings in order to perform tasks such as planning or performing investigations. A very
small part of this example EHR has also been made accessible to administrative staff. Appointments clerks,
secretaries and porters all need to know certain key facts about a subject of care in order to play their role in
the overall delivery of efficient care, such as knowing that a subject of care has special health advocacy needs
or that they will need to have 24 % oxygen and a wheelchair in order to be transported to the radiology
department.
xiii
This example does not illustrate how subjects of care can be excluded from access to portions of the EHR,
but such stipulations can be made using the generic policy framework of Clause 7, if permitted under data
protection legislation. An example of this will be if the EHR data was provided in confidence by a relative of
the subject of care.
While a set of rich policies can be defined for specific kinds of subjects of care, specific settings, or in cases
where subjects of care have specific concerns about their EHR, the adoption of distributed EHR solutions
needs to be managed on the basis that a sensible set of defaults and a simple framework will satisfy the
majority of cases in the near future. This is because a rich set of policies might not be capable of direct
interpretation and incorporation within the EHR system of an EHR Recipient, even if the information in
those policies can be communicated in a standardized way.
In addition to the generic representation of EHR access policy information, this document therefore also
defines a specification for a minimum basis for communicating the sensitivity of EHR data within an EHR_
EXTRACT, by specifying the sensitivity of the COMPOSITIONs within it according to the classification defined
in 6.1. This classification corresponds to the various sub-domains of EHR data illustrated in Figure 4.
In practice any given EHR system might have other mechanisms for indicating the sensitivity of EHR data
or some equivalent concept. This document does not require EHR systems to store data according to the
sensitivity levels defined in 6.1, but to be able to map to this classification on generating an EHR_EXTRACT.
0.5.3  Functional Roles for accessing EHR data
In order to make an access decision, the profile and purpose of a proposed EHR Recipient need to be
matched to the policies applying to the EHR held by the EHR provider, including the sensitivity of the specific
RECORD_COMPONENTS that have been requested.
The profile of the Requester or Recipient, or both, therefore needs to be specified in an interoperable way. As
discussed earlier, the requirements, legislation, attributes and vocabularies used for describing requester
profiles in each country vary, and cannot yet be standardized.
However, in order to provide a basic level of interoperability, minimum conformance to this document
does require either that any request for an EHR_EXTRACT include, as part of the request specification,
the Functional Role of the intended EHR Recipient, as defined in 6.2 and corresponding to those defined in
[10]
ISO 21298 , or that an alternative jurisdictionally-specified term list be used.
The correlation between Functional Role and EHR sensitivity, for the purpose of granting or denying an
access request, or for filtering the EHR_EXTRACT, is defined in 6.3.
This mapping provides a basic (coarse-grained) way of limiting the scope of EHR access according to the
kind of party who is making the access req
...

Norme
internationale
ISO 13606-4
Deuxième édition
Informatique de santé —
2026-08
Communication du dossier de santé
informatisé —
Partie 4:
Sécurité
Health informatics — Electronic health record communication —
Part 4: Security
Numéro de référence
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2026
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, aucune partie de cette
publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique,
y compris la photocopie, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: [phone]
E-mail: [e-mail]
Web: www.iso.org
Publié en Suisse
ii
Sommaire Page
Avant-propos .iv
Introduction .v
1 Domaine d'application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Abréviations . 2
5 Conformité . 3
6 Sensibilité des éléments du dossier et rôles fonctionnels . 3
6.1 Sensibilité de RECORD_COMPONENT .3
6.2 Rôles fonctionnels .4
6.3 Mise en correspondance du rôle fonctionnel avec la sensibilité de COMPOSITION .4
7 Représentation des informations de politique d’accès dans un EHR_EXTRACT . 5
7.1 Vue d'ensemble .5
7.2 Représentation UML de l’archétype de la politique d’accès COMPOSITION .7
7.3 Propriétés du modèle de politique d’accès .7
7.3.1 Politique d'accès .7
7.3.2 Cible.8
7.3.3 Critère de demande .9
7.3.4 Contrainte de sensibilité .11
7.3.5 Informations d'attestation . 12
7.4 Archétype de la COMPOSITION de politique d’accès . 12
8 Représentation des informations du rapport d’expertise.12
8.1 Généralités . 12
8.2 Extrait de rapport d’expertise de DSI . 13
8.3 Contrainte de rapport d’expertise .14
8.4 Entrée de rapport d’expertise de DSI . 15
8.5 Description de l’extrait de DSI .16
8.6 Extrait démographique .17
Annexe A (informative) Exemple illustratif de contrôle d’accès . 19
Annexe B (informative) Relations entre le présent document et des approches alternatives .23
Bibliographie .25

iii
Avant-propos
L’ISO (Organisation internationale de normalisation) est une fédération mondiale d’organismes nationaux
de normalisation (comités membres de l’ISO). L’élaboration des Normes internationales est en général
confiée aux comités techniques de l’ISO. Chaque comité membre intéressé par une étude a le droit de faire
partie du comité technique créé à cet effet. Les organisations internationales, gouvernementales et non
gouvernementales, en liaison avec l’ISO participent également aux travaux. L’ISO collabore étroitement avec
la Commission électrotechnique internationale (IEC) en ce qui concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier, de prendre note des différents
critères d’approbation requis pour les différents types de documents ISO. Le présent document
a été rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2
(voir https://www.iso.org/directives).
L’ISO attire l’attention sur le fait que la mise en application du présent document peut entraîner l’utilisation
d’un ou de plusieurs brevets. L’ISO ne prend pas position quant à la preuve, à la validité et à l’applicabilité de
tout droit de brevet revendiqué à cet égard. À la date de publication du présent document, l’ISO n’avait pas
reçu notification qu’un ou plusieurs brevets pouvaient être nécessaires à sa mise en application. Toutefois,
il y a lieu d’avertir les responsables de la mise en application du présent document que des informations
plus récentes sont susceptibles de figurer dans la base de données de brevets, disponible à l’adresse
www.iso.org/brevets. L’ISO ne saurait être tenue pour responsable de ne pas avoir identifié tout ou partie de
tels droits de brevet.
Les appellations commerciales éventuellement mentionnées dans le présent document sont données pour
information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer un engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions
spécifiques de l’ISO liés à l’évaluation de la conformité, ou pour toute information au sujet de l’adhésion de
l’ISO aux principes de l’Organisation mondiale du commerce (OMC) concernant les obstacles techniques au
commerce (OTC), voir le lien suivant: www.iso.org/avant-propos.
Le présent document a été élaboré par le comité technique ISO/TC 215, Informatique de santé, en collaboration
avec le comité technique CEN/TC 251, Informatique de santé, du Comité européen de normalisation (CEN)
conformément à l’Accord de coopération technique entre l’ISO et le CEN (Accord de Vienne).
Cette deuxième édition annule et remplace la première édition (ISO 13606-4:2019), dont elle constitue une
révision mineure. Les modifications sont les suivantes:
— les tableaux de l’Article 7 et de l’Article 8 ont été numérotés;
— les exemples de l'Annexe B ont été rendus anonymes;
— des corrections ont été apportées à l'Article 2 et à l'Article 3 pour refléter le contenu technique du
document.
Une liste de toutes les parties de la série ISO 13606 se trouve sur le site web de l’ISO.
Il convient que l’utilisateur adresse tout retour d’information ou toute question concernant le présent
document à l’organisme national de normalisation de son pays. Une liste exhaustive desdits organismes se
trouve à l’adresse www.iso.org/members.html.

iv
Introduction
0.1  Généralités
Le présent document fait partie d’une série de normes comprenant cinq parties. Dans le présent document,
la dépendance à l’une des autres parties de la série est explicitement indiquée là où elle s’applique.
0.2  Sujets abordés dans le présent document
La communication des dossiers de santé informatisés (DSI) complets ou de parties de ceux-ci, dans les limites
d’une organisation et entre organisations, quelquefois même au-delà des frontières nationales, pose des
problèmes du point de vue de la sécurité. Il convient de créer, traiter et gérer les dossiers de santé de manière
à assurer la confidentialité de leur contenu et à permettre aux sujets des soins de contrôler la manière
dont ils sont utilisés. Dans le monde entier, ces principes s’inscrivent progressivement dans les législations
nationales de protection des données. Ces instruments déclarent que le sujet des soins a le droit de jouer
un rôle central dans les décisions prises sur le contenu et la distribution de son DSI, ainsi que le droit d’être
informé de son contenu. Il convient que la communication des informations des dossiers de santé à des tiers
se fasse uniquement avec l’accord du sujet des soins (qui peut être toute indication spécifique et informée
donnée librement de son souhait, par laquelle le sujet des informations signifie son accord avec le traitement
[1]
de ses données personnelles d'une manière acceptable d'un point de vue éthique). L’ISO 22600-3 donne de
[2]
plus amples détails. Pour la communication des DSI au-delà des frontières nationales, l’ISO 22857 donne
des recommandations qui peuvent être utilisées pour définir des spécifications appropriées de politique de
sécurité.
Dans l’idéal, il convient que chaque entrée affinée dans le dossier d’un sujet des soins soit accessible
uniquement par les personnes qui ont l’autorisation de voir ces informations, spécifiées ou approuvées par
le sujet des soins et reflétant la nature dynamique de l’ensemble des personnes disposant d’un devoir de
soins légitime envers le sujet des soins tout au long de sa vie. La liste de contrôle d’accès inclut également
dans l’idéal les personnes qui ont l’autorisation d’accéder aux données pour des raisons autres que le
devoir de soins (comme la gestion d’un service de soins, l’épidémiologie et la santé publique, la recherche
consentie) mais exclut toute information qu’elles n’ont pas besoin de connaître ou que le sujet des soins
considère comme trop personnelles pour les leur divulguer. Par ailleurs, il convient que l’étiquetage par les
sujets des soins ou leurs représentants d’informations comme étant personnelles ou privées ne gêne pas les
personnes ayant un besoin légitime de voir les informations en cas d’urgence ni n’ait pour conséquence que
des authentiques prestataires de soins de santé disposent d’un point de vue incomplet qui les induirait en
1)
erreur dans la gestion du sujet des soins. Le point de vue des sujets des soins sur la sensibilité inhérente
des données de leur dossier de santé peut évoluer dans le temps, à mesure que leurs angoisses à propos de
leur santé ou que les attitudes sociétales envers leurs problèmes de santé changent. Les sujets des soins
peuvent souhaiter que leur famille, leurs amis, les soignants et les membres de leur communauté bénéficient
de niveaux d’accès différents. Les familles peuvent souhaiter offrir un moyen leur permettant d’accéder à
des parties du dossier les uns des autres (pas nécessairement dans la même mesure) afin de surveiller les
progrès des états de santé hérités au sein d’une famille.
Un tel ensemble d’exigences est sans doute plus complet que celui qui est exigé des contrôleurs de données
dans la plupart des autres domaines industriels. Dans la pratique, il est rendu extrêmement complexe en
raison des éléments suivants:
— le grand nombre d’entrées dans le dossier de santé au cours des soins de santé administrés de nos jours
au sujet des soins;
— le grand nombre de personnels de soins de santé, changeant souvent de postes, pouvant potentiellement
entrer en contact avec un sujet des soins à tout moment;
— le grand nombre d’organisations de soins de santé avec lesquelles un sujet des soins peut entrer en
contact au cours de sa vie;
1) Le terme sensibilité est largement utilisé dans le domaine de la sécurité pour une large gamme de protections et de
contrôles mais dans le présent document, ce terme se réfère uniquement aux contrôles d’accès.

v
— la difficulté (pour le sujet des soins ou pour toute autre personne) à classer de manière normalisée la
sensibilité éventuelle d’un élément de dossier;
— la difficulté à déterminer l’importance éventuelle d’une entrée unique dans un dossier de santé pour les
soins futurs du sujet des soins et pour les classes d’utilisateurs;
— la nature logiquement indélébile du DSI et le besoin de gérer de manière rigoureuse les révisions des
autorisations d’accès, de la même manière que les révisions des entrées du DSI elles-mêmes;
— le besoin de déterminer très rapidement un accès approprié, en temps réel et potentiellement dans un
environnement informatique réparti;
— le niveau élevé de demandes exprimées par une minorité croissante de sujets des soins de voir leur
consentement à la divulgation enregistré et respecté;
— le faible niveau de demandes relatives à ces exigences de la part de la majorité des sujets des soins, qui a
historiquement limité l’engagement prioritaire à s’attaquer à cet aspect de la communication des DSI.
Afin de prendre en charge des DSI interopérables et des communications sans interruption des données
du DSI entre les prestataires de soins de santé, il convient que la négociation exigée pour déterminer s’il
convient qu’un demandeur quelconque de données de DSI reçoive les données puisse être automatisée. Si
une négociation automatisée n’était pas possible, les délais et la charge de travail nécessaires à la gestion des
décisions humaines pour toutes les communications de dossiers ou presque rendraient inutiles tout effort de
permettre l’interopérabilité des données.
Les grands principes de l’approche du développement des normes dans le domaine du contrôle d’accès des
communications de DSI consistent à faire correspondre les caractéristiques et les paramètres d’une demande
et les politiques de l’émetteur du DSI, ainsi que tout contrôle d’accès ou déclaration de consentement dans
le DSI spécifié, pour tenir à jour les preuves appropriées de la divulgation et permettre un traitement
automatisé. Dans la pratique, des efforts sont en cours pour développer des normes internationales de
définition de systèmes de contrôle d’accès et de gestion des privilèges qui soient capables de négociation
entre ordinateurs. Ce type de travail est cependant fondé sur les services de santé qui se mettent d’accord
sur un cadre mutuellement cohérent de définition des privilèges qu’ils souhaitent attribuer au personnel
ainsi que sur le spectre de sensibilité qu’ils permettent aux sujets des soins de définir dans leurs DSI. Cela
exige de la cohérence dans la manière d’exprimer les informations pertinentes, afin que cette sensibilité soit
évolutive au moment de la définition (lors de l’ajout de nouvelles entrées au DSI), au moment de l’exécution
(lorsqu’un DSI complet est récupéré ou interrogé) et qu’elle soit durable sur toute la durée de vie du sujet des
soins. Il est important également de reconnaître que, dans un avenir prévisible, des différences continueront
d’exister entre les pays sur des approches spécifiques de sécurisation des communications de DSI, dont des
législations différentes, et qu’une approche fortement prescriptive de la normalisation n’est pas possible à
l’heure actuelle.
Le présent document ne spécifie donc pas les règles d’accès elles-mêmes. Il ne spécifie pas à qui il convient
de donner l’accès, à quoi et par quels mécanismes de sécurité; il convient que celles-ci soient déterminées
par les communautés d’utilisateurs, les lignes directrices et la législation nationales. Elle définit un cadre de
base qui peut être utilisé comme spécification minimale de la politique d’accès au DSI et une représentation
générique plus riche pour la communication d’informations de politique plus détaillées. Ce cadre complète
[3]
l’architecture générale définie dans l’ISO 13606-1 et définit les structures d’information spécifiques qui
[3]
doivent être communiquées en tant que parties d’un EHR_EXTRACT, défini dans l’ISO 13606-1. Certains
types d’accords nécessaires à la sécurité des communications de DSI sont inévitablement en dehors
du domaine d’application du présent document et sont traités de manière plus complète dans la série
[4]
ISO 22600 .
Il convient de noter qu’il existe un certain nombre de dépendances explicites et implicites sur l’utilisation
d’autres normes conjointement au présent document, pour la cohésion générale d’un déploiement de
sécurité de l’information interopérable. Outre l’accord relatif à la série complète de normes appropriées, un
régime d’assurance adapté semble nécessaire (lequel ne fait pas partie du domaine d’application du présent
document).
vi
0.3  Scénarios de communication
0.3.1  Flux de données
Les interfaces et les modèles de message exigés pour prendre en charge la communication de DSI
[5]
constituent le sujet de l’ISO 13606-5. La description présentée ici est une vue d’ensemble du processus
de communication permettant de montrer les interactions pour lesquelles des fonctions de sécurité sont
nécessaires. La Figure 1 représente les flux de données principaux et les scénarios pris en compte dans le
présent document. Pour chaque flux de données principal, il existe une réponse d’accusé de réception et
facultativement un rejet peut être retourné à la place des données demandées.
Figure 1 — Principaux flux de données et processus relatifs à la sécurité couverts par
le présent document
Le demandeur du DSI, le destinataire du DSI et le réviseur du rapport d’expertise peuvent être des
professionnels de santé, le sujet des soins, un représentant légal ou toute autre partie ayant les autorisations
suffisantes pour accéder aux informations de soins de santé. L’EHR_EXTRACT comme le rapport d’expertise,
s’ils sont fournis, peuvent devoir être filtrés pour limiter la divulgation afin de respecter les privilèges
du destinataire. Cet aspect du contrôle d’accès sera discuté plus loin dans l’introduction (toutes les
parties représentées ici, et pas uniquement l’émetteur du DSI, doivent tenir à jour un rapport d’expertise.
Cependant, pour une meilleure lisibilité, les autres processus de rapport d’expertise ne sont pas représentés
ni décrits ici).
Les paragraphes qui suivent décrivent chaque flux de données de la Figure 1.
0.3.2  Demander des données de DSI
Cette interaction n’est pas toujours exigée (par exemple, les données de DSI peuvent être poussées de
l’émetteur vers le destinataire comme dans le cas d’une lettre de sortie). L’interface de demande doit inclure
un profil du demandeur suffisant pour permettre à l’émetteur du DSI de pouvoir prendre une décision

vii
d’accès, pour remplir un rapport d’expertise et fournir les données appropriées au destinataire prévu. Dans
certains cas, le demandeur du DSI peut ne pas être la même partie que le destinataire du DSI, par exemple, un
agent logiciel peut déclencher une notification contenant des données de DSI à envoyer à un professionnel de
santé. Dans ce cas, ce sont les justificatifs du destinataire du DSI qui déterminent principalement la décision
d’accès à prendre.
Une demande de DSI peut devoir inclure ou faire référence à des accords d’accès et des mandats de soins, par
exemple par la fourniture d’une forme quelconque de consentement explicite de la part du sujet des soins ou
d’un mandat de soins.
La négociation entre le demandeur et l’émetteur des données de DSI sera de plus en plus automatisée et
il convient que les informations incluses dans cette interaction suffisent à permettre une négociation
totalement informatisée.
Les exigences relatives à cette interaction sont reflétées par le modèle d’interface REQUEST_EHR_EXTRACT
[5]
défini dans l’ISO 13606-5 .
0.3.3  Générer une entrée de journal d’accès au DSI
Il s’agit d’une pratique prise pour hypothèse de tout système de DSI, mais elle n’est pas spécifiée en
tant qu’interface normative en raison des nombreuses approches et capacités des systèmes actuels.
L’interopérabilité des systèmes d’expertise internes de tout système de DSI n’est pas exigée, sauf pour la
prise en charge du modèle défini à l’Article 8 du présent document et de l’interface correspondante définie
[5]
dans l’ISO 13606-5 .
0.3.4  Accuser réception de la demande de DSI
Aucune considération de sécurité spécifique aux soins de santé.
0.3.5 Prendre la décision d’accès, filtrer les données de DSI
Lors du traitement de la demande de DSI, les politiques relatives à l’émetteur du DSI et les politiques d’accès
du DSI lui-même doivent toutes être prises en compte pour déterminer quelles données sont extraites du DSI
cible. Le présent document ne peut pas dicter l’ensemble complet de politiques pouvant influencer l’émetteur
du DSI, potentiellement dérivées de législations nationales, régionales, spécifiques à l’organisation,
professionnelles et autres.
Une décision de filtrer les données de DSI sur la base de leur sensibilité et des privilèges du demandeur et
du destinataire du DSI doit être conforme aux politiques concernées et peut devoir trouver l’équilibre entre
les risques cliniques du refus d’accès à l’information et les risques médicolégaux relatifs à la divulgation de
l’information.
Le présent document définit toutefois un cadre général de représentation interopérable des politiques
d’accès qui peut concerner tout DSI particulier créé par le sujet des soins ou par ses représentants. Celles-ci
peuvent ne pas être stockées dans le système de DSI physique de cette manière; elles peuvent par exemple
être intégrées dans un serveur de politique relié au serveur de DSI.
Cette décision d’accès est discutée plus en détails à l’Article 7.
0.3.6  Refuser la fourniture de l’EHR_EXTRACT
Si la décision d’accès est un refus, un ensemble grossier de raisons doit être défini afin de développer un
ensemble de raisons adaptées de la part de l’émetteur du DSI. Cependant, il est important que le refus et
l’éventuelle raison donnée n’indiquent pas au destinataire que les données de DSI demandées n’existent pas.
La simple divulgation de leur existence peut être dommageable pour un sujet des soins.
Aucune considération de sécurité spécifique aux soins de santé. Le modèle d’interface est défini dans
[5]
l’ISO 13606-5 .
0.3.7  Fournir l’EHR_EXTRACT
Il convient de noter que le destinataire du DSI peut ne pas être le même que le demandeur du DSI et que
la fourniture d’un DSI peut ne pas avoir été déclenchée par une demande. Elle peut avoir été initiée par

viii
l’émetteur dans le cadre d’un protocole de soins partagé ou pour ajouter de nouvelles données à un DSI
existant.
[3]
Il est exigé que l’EHR_EXTRACT soit conforme au modèle de référence défini dans l’ISO 13606-1 et au
[5]
modèle d’interface défini dans l’ISO 13606-5 .
Il convient que l’EHR_EXTRACT inclue ou fasse référence à toute politique d’accès pertinente, représentée
conformément au présent document, pour orienter toute propagation à venir des données de DSI
communiquées. Les politiques ne peuvent être référencées que si le destinataire du DSI est connu comme
ayant un accès direct aux mêmes informations par d’autres moyens.
0.3.8  Accuser réception de l’EHR_EXTRACT
Aucune considération de sécurité spécifique aux soins de santé.
0.3.9  Générer une entrée de journal d’accès au DSI
Comme décrit en 0.3.3.
0.3.10 Demander à voir le journal d’accès au DSI
Permettre à un sujet des soins de découvrir qui a eu accès à tout ou partie de son DSI dans un environnement
de partage des informations est aujourd’hui considéré comme une pratique souhaitable. Le domaine
d’application de cette interface, tel que défini dans le présent document, consiste à demander à voir le
rapport d’expertise qui informe le destinataire de qui a accédé à quelles parties de son DSI dans un système
de DSI donné et quand. Cette interface n’est pas destinée à prendre en charge les situations dans lesquelles
un contrôle complet d’un rapport d’expertise est exigé à des fins légales ou pour d’autres investigations.
Cette interface est expliquée à l’Article 6.
[5]
Le modèle d’interface est défini dans l’ISO 13606-5 .
0.3.11  Générer une entrée de journal d’accès au DSI
Comme décrit en 0.3.3.
0.3.12  Fournir le journal d’accès au DSI
Il s’agit d’une pratique souhaitable qui exige une représentation interopérable de cette entrée (ou de cet
ensemble d’entrées). Cette interface est expliquée à l’Article 6.
Bien qu’une investigation légale exige qu’un rapport d’expertise soit fourni sous forme complète et non
modifiée, la présentation d’un rapport d’expertise à un sujet des soins ou à un professionnel de santé peut
exiger de filtrer certaines entrées (par exemple celles qui font référence à des données du DSI auxquelles le
sujet des soins n’a pas accès).
[5]
Le modèle d’interface est défini dans l’ISO 13606-5 .
0.3.13  Refuser le journal d’accès au DSI
Si la demande n’est pas satisfaite, il est nécessaire de définir un ensemble grossier de raisons. Cependant, il
est important que le refus et l’éventuelle raison donnée n’indiquent pas au destinataire que les données de
DSI demandées n’existent pas. La simple divulgation de leur existence peut être dommageable pour un sujet
des soins.
Aucune considération de sécurité spécifique aux soins de santé. Le modèle d’interface est défini dans
[5]
l’ISO 13606-5 .
0.3.14  Accuser réception du journal d’accès au DSI
Aucune considération de sécurité spécifique aux soins de santé.
0.3.15  Générer une entrée de journal d’accès au DSI
Comme décrit en 0.3.3.
ix
0.4  Exigences et approche technique
0.4.1 Exigences générales relatives à la sécurité des soins de santé
Les exigences les plus largement acceptées pour une approche générale de sécurité dans les domaines
[6]
traitant de données sensibles et personnelles sont publiées dans l’ISO/IEC 27002. Celle-ci spécifie
les types de mesures qu’il convient de prendre pour protéger les biens tels que les données de DSI et les
manières de communiquer ces données en sécurité dans le cadre d’un environnement informatique réparti.
[7]
Un guide spécifique à la santé pour la présente norme générale a été publié dans l’ISO 27799. Celui-ci
facilite la formulation de politiques de sécurité communes en soins de santé, et il est censé promouvoir
[8]
l’adoption de composants et de services de sécurité interopérables. La série ISO 22600 définit une
approche architecturale complète de définition et de gestion formelles et cohérentes de ces politiques. Pour
[2]
la communication des DSI au-delà des frontières nationales, l’ISO 22857 donne des recommandations qui
peuvent être utilisées pour définir des spécifications appropriées de politique de sécurité.
Les exigences de sécurité précises qui doivent être satisfaites pour autoriser une instance de communication
de DSI particulière dépendent d’un certain nombre de politiques nationales et locales sur les sites d’envoi
et de réception et au niveau de tous les liens intermédiaires sur la chaîne de communication. Beaucoup
de ces politiques s’appliquent aux communications de soins de santé en général et varient selon les pays
et les contextes médicaux d’une manière qu’il convient que le présent document ne définisse pas et qu’il
ne peut pas définir. L’approche prise lors de la rédaction du présent document a donc consisté à prendre
pour hypothèse que les politiques, composants et services de sécurité généraux contribuent à une phase de
négociation (la “décision d’accès”) avant de sanctionner la communication d’un extrait de DSI et protègent
les flux de données effectifs du DSI.
Le présent document prend par conséquent pour hypothèse qu’une politique ou un ensemble de politiques de
[7]
sécurité générale conforme à l’ISO 27799 est en place sur tous les sites participant à une communication
de DSI et que ces politiques sont conformes aux législation nationales ou internationales sur la protection
des données. Des politiques supplémentaires peuvent être exigées pour la conformité aux règlementations
spécifiques nationales, locales, professionnelles ou de l’organisation, applicables à la communication ou à
l’utilisation de données de DSI. La définition de ces politiques ne fait pas partie du domaine d’application du
présent document.
0.4.2  Relations avec d’autres normes de sécurité
L’accès légitime aux données du DSI est déterminé par une large gamme de politiques, dont certaines
peuvent exister sous forme de documents, certaines sont codées dans des applications et certaines dans
des composants de systèmes d’autorisation formels. Il est connu que les fournisseurs et les organisations
diffèrent dans leur manière de mettre en œuvre les politiques et les services de contrôle d’accès et leur degré
d’informatisation actuel.
[8]
La série ISO 22600 définit un modèle logique générique pour la représentation des privilèges des acteurs
principaux (entités), des politiques de contrôle d’accès relatives à des objets cibles potentiels et du processus
de négociation exigé pour parvenir à une décision d’accès. La Figure 2 représente les concepts du contrôle
[8]
d’accès basé sur les rôles défini dans la série ISO 22600 .

x
Figure 2 — Principaux concepts et types de politiques définis dans le contrôle d’accès basé sur
[8]
les rôles (série ISO 22600 )
Avec la définition des contraintes sur les rôles, les processus, les objets cibles et les privilèges associés par
[8]
les politiques, la Figure 2 devient la Figure 3, conformément à la série ISO 22600 .
Figure 3 — Schéma RBAC selon la politique
Comme illustré à la Figure 3, les acteurs principaux (personnes, agents, etc.) sont mis en correspondance
avec un ou plusieurs rôles fonctionnels qui sont influencés par les rôles structurels qu’ils sont autorisés à
tenir. Par exemple, une personne médicalement qualifiée et un spécialiste en pédiatrie peuvent tenir un ou
plusieurs rôles structurels (comme pédiatre consultant dans un hôpital, responsable du dépistage chez les
enfants pour la région). Ces rôles structurels peuvent permettre à la personne de tenir à certains moments
le rôle fonctionnel de clinicien personnel envers un sujet des soins. Le rôle fonctionnel peut être permanent
ou limité à une seule session d’utilisateur. Les rôles fonctionnels sont mis en correspondance avec des
permissions d’exécuter des opérations particulières (comme la saisie de nouvelles entrées dans le DSI) et
avec des objets particuliers (par exemple les données du DSI que le détenteur du rôle est autorisé à voir).
Aux fins du présent document, la classe Target_Component représentée à la Figure 3 représente les données du
DSI détenues par l’émetteur du DSI. L’association Permission_Assignment définit les politiques qui autorisent
ou refusent l’accès à tout ou partie du DSI, qui doivent également être communiquées au destinataire du DSI
pour adoption et propagation ultérieures. Bien que le présent document prenne pour hypothèse l’adoption
[8]
de la série ISO 22600, il est reconnu que les structures et la terminologie fonctionnelles nationales peuvent
différer et que des variantes sont possibles. Le présent document spécifie toutefois uniquement le modèle de
politique en tant que cadre de communication interopérable des politiques d’accès réelles. Il ne définit pas

xi
lui-même le contenu des politiques d’accès qui doivent être déterminées au niveau juridictionnel ou plus
local.
[9]
En tant que complément de la présente norme, l’ISO 21298 définit les ensembles de rôles structurels et de
rôles fonctionnels qui peuvent être utilisés à l’international pour prendre en charge la négociation et la mise
en relation des politiques (par exemple pendant la phase de négociation d’une décision d’accès). Le présent
[9]
document prend également pour hypothèse l’adoption de l'ISO 21298 et s’aligne sur elle.
La relation entre le modèle de politique défini dans le présent document et le système de classification de
confidentialité et de sécurité des soins de santé HL7 est expliquée à l’Annexe B.
[10]
L’ISO 27789 définit une représentation complète des informations de rapport d’expertise et d’historique
d’expertise relatives à tous les évènements qui peuvent se produire dans les systèmes de dossier de santé
informatisé de santé. Cela inclut la communication des données du DSI entre les référentiels et les systèmes.
Le présent document prend pour hypothèse la conformité à cette norme et définit un profil (sous-ensemble)
[10]
du modèle de rapport d’expertise de l’ISO 27789 spécifiquement destiné à la communication avec les
sujets des soins et les autres parties autorisées des informations indiquant qui a accès au DSI d’un sujet des
soins spécifique, quand et pourquoi.
Un grand nombre d’exigences médicolégales et éthiques spécifiques au DSI sont exprimées dans
[11]
l’ISO 18308, bien que la conformité avec celles-ci soit principalement satisfaite par l’intermédiaire
[3]
des classes et attributs spécifiques du modèle de référence de DSI (publié dans l’ISO 13606-1 ). La
[11]
série ISO 13606 permet la conformité à l’ISO 18308 et le présent document permet spécifiquement la
conformité à ses exigences éthiques et légales et à ses principes d’information juste.
0.5  Modèle de politique d’accès au DSI
0.5.1  Approche générale
[3]
Dans le modèle de référence de l’ISO 13606-1, chaque COMPOSITION dans l’EHR_EXTRACT inclut un
attribut access_policy_id facultatif pour permettre de faire référence à ces politiques à tout niveau de
détail dans la hiérarchie d’imbrication du DSI. Chaque COMPOSITION peut par conséquent référencer tout
nombre de politiques d’accès ou de déclarations de consentement qui définissent les privilèges nécessaires
prévus ainsi que les profils des acteurs principaux (utilisateurs, agents, logiciels, dispositifs, délégués, etc.)
pour un accès futur aux données du DSI référencées. Le modèle d’information de l’Article 7, destiné à la
représentation et à la communication des informations de politique d’accès, a été délibérément gardé très
général pour permettre la diversité des critères de politiques stipulées dans différents pays et différents
réseaux régionaux de soins de santé. Des vocabulaires normalisés sont définis sous forme de listes de
termes par défaut pour certaines des principales propriétés du modèle. Bien qu’il soit recommandé de les
adopter dès lors qu’elles sont adaptées, il est reconnu que les juridictions peuvent posséder des exigences,
des législations ou des investissements existants qui signifient qu’elles ne peuvent pas adopter ces listes de
termes internationales normalisées. Le présent document autorise par conséquent les juridictions à déclarer
la conformité au moyen de listes de termes alternatives.
Les environnements de santé et de soins comprennent des réseaux de plus en plus complexes d’agences et
d’acteurs de milieux de soins de santé classiques, d’aide sociale, de prestataires et d’agences informels et
bénévoles (comme les organismes caritatifs d’aide sociale), comprenant également les sujets des soins eux-
mêmes, les familles et quelquefois leurs réseaux sociaux. Tous ces acteurs peuvent par moments établir des
accords pour permettre le partage de données de santé personnelles. Étant donnée la nature dynamique de
cette “équipe de soins virtuelle”, il peut ne pas être pratique de négocier ces accords de partage de données
de manière classique à base de documents échangés entre les personnes. Il est donc probable que ces agences
établissent des accords-cadres qui spécifient à l’avance les normes auxquelles chacune se conforme, toutes
les correspondances entre leurs domaines de privilèges respectifs et la manière dont les données doivent être
gérées dans chacun de ces domaines de privilèges. Comme indiqué ci-dessus, ce modèle de politique permet
à la place aux juridictions de déclarer les listes de termes alternatives qu’elles utilisent. Cela permet une
certaine flexibilité dans l’adoption du présent document, qui reconnaît que des environnements complexes
de partage de données peuvent devoir établir de nouveaux vocabulaires potentiellement plus riches pour
décrire la gamme plus large d’acteurs et de rôles dans cet environnement.
Un certain nombre de systèmes existants et hérités peuvent ne pas pouvoir intégrer des spécifications de
politiques riches en définitions et de nombreuses régions de soins de santé peuvent ne pas être en mesure

xii
de définir ces politiques pendant quelques années. Par conséquent, en tant que complément au modèle de
politique général de l’Article 7, le présent document définit deux classifications qui peuvent fournir une
base minimale pour une prise de décision relative à la politique d’accès et garantir une interopérabilité de
politique d’accès de base, bien qu’à un niveau relativement grossier.
Ces deux vocabulaires sont les suivants:
a) une classification de la sensibilité des données du DSI (au niveau de COMPOSITION);
b) une classification de haut niveau des demandeurs et des destinataires de DSI, par le biais d’un ensemble
de rôles fonctionnels.
0.5.2 Définition du “besoin de connaître” dans le traitement des données de DSI
Dans de nombreux environnements de soins de santé (dans et entre des équipes de soins de santé qui
collaborent dans la mise à disposition directe de soins aux sujets des soins), la norme est de partager les
informations du dossier de santé de manière ouverte. La grande majorité des sujets des soins souhaite que
cela se passe ainsi et de nombreux sujets des soins sont en fait surpris du fait que leur dossier de santé soit
peu partagé aujourd’hui lorsqu’il conviendrait de le partager plus pour la sécurité et la continuité des soins.
Quelques systèmes actuels de soins de santé (sous format papier ou électronique) définissent des
cloisonnements de contrôle d’accès internes complexes des dossiers de santé qu’ils contiennent. Même s’il
est considéré comme utile de définir de nombreuses politiques d’accès finement définies, dans la pratique
les systèmes de soins de santé, les services de santé nationaux et les millions de sujets des soins pourraient
avoir besoin de beaucoup de temps pour spécifier des politiques de contrôle d’accès adaptées à toutes leurs
données de DSI et pour mettre en œuvre des composants logiciels aptes à exécuter de nombreux calculs
complexes de mise en relation des politiques en temps réel. La maintenance de ces politiques à mesure que
les exigences de soins médicaux relatives à chaque sujet des soins évoluent représente elle aussi un processus
complexe.
Tandis qu’une suite de politiques d’accès peut être définie en théorie (par les sujets des soins ou par d’autres)
pour offrir un cadre à plusieurs niveaux d’accès dans tout DSI donné, dans la pratique la plupart des milieux
médicaux opèrent sur la base de privilèges par défaut accordés dans le dossier de santé à tout professionnel
de soins de santé ou médical ayant un intérêt légitime pour le sujet des soins. (La définition des personnes
ayant un intérêt légitime varie selon les organisations et ne fait pas partie du domaine d’application du
présent document). Cependant, il est également bien accepté que les sujets des soins et les professionnels
puissent avoir besoin par moments de restreindre l’accès à certaines données du DSI plus personnelles et
sensibles. Il est courant également dans la plupart des services de santé d’isoler certains milieux médicaux
comme contenant des parties exclusives d’un DSI (par exemple les cliniques de santé sexuelle).
Ce type d’isolement de milieux médicaux ou le marquage des données du DSI comme particulièrement
sensibles est tout à fait distinct de toute subdivision du DSI qui peut être définie pour aider à la navigation et
au flux de travail dans les spécialités médicales, par exemple en définissant des parties relatives au cancer ou
au diabète dans le DSI. La Figure 4 propose une représentation de la manière dont un DSI peut être subdivisé
logiquement du point de vue du besoin de connaître, la classification de la confidentialité (sensibilité) étant
représentée au moyen de classes d’utilisateurs et pour des contextes de soins particuliers.

xiii
Légende
A entrées privées partagées avec le MG
B entrées restreintes à l’équipe de santé sexuelle
C entrées accessibles au personnel administratif
D entrées accessibles au personnel de soutien médical
E entrées accessibles aux équipes de soins directs
F entrées privées partagées avec plusieurs parties nommées
G entrées restreintes aux services de santé en prison
Figure 4 — Domaines d’accès dans un
...