ISO/FDIS 13606-4

• Abstract:

  This document describes a methodology for specifying the privileges necessary to access EHR data. This methodology forms part of the overall EHR communications architecture defined in ISO 13606-1. 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 at 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: Not Published
• 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: 5020 - FDIS ballot initiated: 2 months. Proof sent to secretariat
• Start Date: 29-Apr-2026
• Completion Date: 29-Apr-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/FDIS 13606-4: Health Informatics - Electronic Health Record Communication - Part 4: Security is an international standard developed by ISO/TC 215. It outlines a methodology for specifying and communicating the privileges necessary to access electronic health record (EHR) data. As a key part of the broader ISO 13606 series, this document focuses specifically on EHR communications, addressing requirements and providing a framework to represent EHR-specific security information that supports informed access decisions.

This part of the standard is intended to aid healthcare organizations, system developers, and policy makers in securing EHR data exchanges, helping to ensure compliance with privacy and confidentiality requirements while enabling safe and effective information sharing.

Key Topics

• Access Privilege Specification: ISO/FDIS 13606-4 describes how to define and communicate access privileges linked to EHR data, ensuring only authorized individuals or systems gain the necessary access.

• Security Framework: The document sets out a flexible and scalable security framework that can adapt to different healthcare environments, national legislations, and organizational policies.

• Role-Based Access Control (RBAC): It offers guidance on mapping functional roles to access privileges using established standards such as ISO 22600 and ISO 21298, ensuring interoperable role definitions across different jurisdictions.

• EHR Data Sensitivity Classification: The standard introduces classifications for EHR data sensitivity levels, enabling healthcare providers to align data access controls with both legal and patient privacy expectations.

• Audit and Accountability: The methodology emphasizes audit trail creation, referencing ISO 27789, to log EHR data access events. This supports transparency and accountability in healthcare information systems.

• Interoperability and Policy Communication: The document defines models for communicating access policies and audit information as part of EHR extracts, facilitating consistent enforcement of security requirements across organizational and national borders.

Applications

ISO/FDIS 13606-4 is valuable in the following real-world scenarios:

• Healthcare System Development: System vendors apply the standard to integrate access control and security features into EHR software, supporting secure data sharing between clinicians, patients, and authorized third parties.

• Cross-Organizational Data Exchange: Healthcare providers and networks use the standard’s framework to establish and automate secure EHR transfers, including filtering data based on recipient privileges and patient consent.

• Patient Privacy and Consent Management: Organizations utilize methodologies described in ISO/FDIS 13606-4 to respect patient preferences on data sharing, including the classification of sensitive health information.

• Compliance with Data Protection Regulations: The standard helps healthcare entities demonstrate compliance with national laws and international regulations concerning health data confidentiality and access (e.g., GDPR).

• Audit and Incident Response: By adopting the audit log requirements, healthcare organizations can monitor, review, and respond to unauthorized access events, enhancing trust and accountability.

Related Standards

To achieve comprehensive and harmonized health information security, ISO/FDIS 13606-4 references and works in conjunction with several related standards:

• ISO 13606-1: Defines the overall EHR communications architecture and reference model.
• ISO/IEC 27002 & ISO 27799: Provide guidelines for general and health sector-specific information security management.
• ISO 22600: Outlines privilege management and access control architectures for health informatics, supporting policy-driven security decisions.
• ISO 22857: Offers guidance for cross-border healthcare information security.
• ISO 21298: Specifies role-based access control concepts for consistent international implementation.
• ISO 27789: Details requirements and models for EHR audit trails and logging.

Adoption of ISO/FDIS 13606-4 enables healthcare organizations to establish robust, interoperable, and standards-based security frameworks for electronic health record communications, enhancing both privacy protection and efficient care delivery.

FINAL DRAFT
International
Standard
ISO/TC 215
Health informatics — Electronic
Secretariat: ANSI
health record communication —
Voting begins on:
2026-04-29
Part 4:
Security
Voting terminates on:
2026-07-22
Informatique de santé — Communication du dossier de santé
informatisé —
Partie 4: Sécurité
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
ISO/CEN PARALLEL PROCESSING LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
Reference number
FINAL DRAFT
International
Standard
ISO/TC 215
Health informatics — Electronic
Secretariat: ANSI
health record communication —
Voting begins on:
Part 4:
Security
Voting terminates on:
Informatique de santé — Communication du dossier de santé
informatisé —
Partie 4: Sécurité
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
© ISO 2026
IN ADDITION TO THEIR EVALUATION AS
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
ISO/CEN PARALLEL PROCESSING
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
or ISO’s member body in the country of the requester.
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
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 Reference number
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).
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.
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 patients 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 take place only with patient consent (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
[1]
them being processed in an ethically-acceptable way) . More details can be found in ISO 22600-3 . For
[2]
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 patient’s record should only be accessed by those persons who have
permissions to view that information, specified by or approved by the patient and reflecting the dynamic
nature of the set of persons with legitimate duty of care towards the patient 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 patient feels is too personal
for them to access. On the opposite side, the labelling by patients 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 health care providers having such a filtered perspective that
1)
they are misled into managing the patient inappropriately. Patients’ 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. Patients 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 patient during the course of modern health care;
— the large number of health care personnel, often rotating through posts, who can potentially come into
contact with a patient at any one time;
— the large number of organisations with which a patient can come into contact during their lifetime;
— the difficulty (for a patient 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
patient, and to which classes of user;
— 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;
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 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 patients to have their consent for disclosure
recorded and respected;
— the low level of concern the majority of patients 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 health care 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 this 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 this 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 patients 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
patient’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
[3]
defined in ISO 13606-1 , and defines specific information structures that are to be communicated as part
[3]
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
[4]
theISO 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
[5]
. 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 patient, 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 patient, 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
[5]
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
[5]
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 patient 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 patient.
[5]
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 shared care pathway or to add new data to an existing EHR.
[3]
The EHR_EXTRACT is required to conform to the Reference Model defined in ISO 13606-1 , and to the
[5]
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 patient 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.
[5]
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 patient or to a healthcare professional might require that some
entries are filtered out (such as those referring to EHR data to which the patient does not have access).
[5]
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 patient.
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
[6]
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
[7]
ISO 27799 . This will facilitate the formulation of common security polices across healthcare, and should
[8]
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
[2]
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
[7]
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 polices 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.
[8]
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
[8]
defined in the ISO 22600 series.
[8]
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
[8]
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 patient. 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
[8]
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.
[9]
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 negotiation
[9]
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.
[10]
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
[10]
defines a profile (sub-set) of the ISO 27789 audit log model specifically for the purpose of communicating
with patients and other authorised parties’ information about who has accessed the EHR of a specified
patient, when and why.
[11]
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
[3] [12] [11]
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
[3]
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 it. 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), patients 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 cant be impractical for these data sharing agreements to be negotiated in traditional
human-to-human, document-based ways. It is therefore likely that such agencies will establish framework

xi
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 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 patients) the norm is to share health record information openly. It is indeed the
wish of the vast majority of patients that teams do this, and many patients 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 health care systems, national health services and millions
of patients 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 patient evolve would also be a
complex process.
Whilst a suite of access policies might in theory be defined (by patients or by others) to provide a multi-
level access level 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 patient. (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 patients
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 patient has complete access to their EHR. The majority of this patient’s
EHR is accessible to any party providing direct clinical care. However, the EHR does contain several private
entries; some are restricted to the patient’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 patient 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 patient 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 patient in order to play their role in the
overall delivery of efficient care, such as knowing that a patient 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 patients 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 patient.
Whilst a set of rich policies can be defined for specific kinds of patients, specific settings, or in cases where
patients 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
...

ISO/DISFDIS 13606-4
ISO/TC 215
Secretariat: ANSI
Date: 2026-03-04-13
Health informatics — Electronic health record communication —
Part 4:
Security
Informatique de santé — Communication du dossier de santé informatisé —
Partie 4: Sécurité
DISFDIS stage
TTTTTTTTTTTThhhhhhhhhhhhiiiiiiiiiiiis drs drs drs drs drs drs drs drs drs drs drs draaaaaaaaaaaafffffffffffftttttttttttt i i i i i i i i i i i is s s s s s s s s s s s susususususususususususubbbbbbbbbbbbmmmmmmmmmmmmiiiiiiiiiiiitttttttttttttttttttttttteeeeeeeeeeeed d d d d d d d d d d d ttttttttttttoooooooooooo      aaaaaaaaaaaa      ppppppppppppaaaaaaaaaaaarrrrrrrrrrrraaaaaaaaaaaallellellellellellellellellellellellel l l l l l l l l l l l vvvvvvvvvvvvooooooooooootttttttttttteeeeeeeeeeee i i i i i i i i i i i innnnnnnnnnnn      IIIIIIIIIIIISSSSSSSSSSSSOOOOOOOOOOOO,,,,,,,,,,,,      CCCCCCCCCCCCEEEEEEEEEEEEN.N.N.N.N.N.N.N.N.N.N.N.

ISO/DISFDIS 13606-4:2026(en)
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
E-mail: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
ISO/DISFDIS 13606-4:2026(en)
Contents
Foreword . iv
Introduction . vi
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 . 4
6.3 Mapping of Functional Role to COMPOSITION sensitivity . 4
7 Representing access policy information within an EHR_EXTRACT . 5
7.1 Overview . 5
7.2 UML representation of the archetype of the access policy COMPOSITION . 7
7.3 Access policy model properties . 8
7.4 Archetype of the access policy COMPOSITION. 12
8 Representing audit log information . 12
8.1 General . 12
8.2 EHR audit log extract . 14
8.3 Audit log constraint . 15
8.4 EHR audit log entry . 15
8.5 EHR extract description . 17
8.6 Demographic extract . 18
Annex A (informative) Illustrative access control example . 19
Annex B (informative) Relations of this document to alternative approaches . 26
Bibliography . 29

iii
ISO/DISFDIS 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).
Attention is drawnISO draws attention to the possibility that some of the elementsimplementation of this
document may beinvolve the subjectuse 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 . ISO shall not be held responsible
for identifying any or all such patent rights. Details of any patent rights identified during the development of
the document will be in the Introduction and/or on the ISO list of patent declarations received (see ).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation onof 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.htmlthe following URL: .
This document was prepared by Technical Committee ISO/TC 215, Health Informatics.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).
This firstsecond edition of ISO 13606-4 cancels and replaces the first edition of (ISO/TS 13606-4:2009,2019),
of which has been technically revised.it constitutes a minor revision. The main changes compared to the
previous edition are as follows:
— the tables in Clause 7 and Clause 8Functional Roles
— Some terms for functional roles have been numbered;
— the examples in Annex B have been anonymized;
— corrections were made to Clause 2updated and Clause 3 to align with CONTSYSreflect the technical content
of the document.
— The rules for using this vocabulary now state that jurisdictions can nominate alternatives or
specialisations of these terms if needed.
— Access policy model
The access policy model now also permits jurisdictional alternative terms to be used where appropriate.
iv
ISO/DISFDIS 13606-4:2026(en)
— Audit log model
The audit log model now aligns with the ISO 27789 standard for EHR audit trails. It contains more
information than is present in ISO 27789: it is a kind of specialisation specifically dealing with the
communication of EHR information and audit log information. It therefore includes information about the
EHR extract or the audit log extract being communicated, which is beyond the scope of ISO 27789.
A list of all parts in the ISO 13606 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
v
ISO/DISFDIS 13606-4:2026(en)
Introduction
0.1 General
This document, is part of a five-part standard series, published jointly by CEN and ISO through the Vienna
Agreement 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 patients 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 his or hertheir EHR, as well
as rightsthe right to be informed of its contents. The communication of health record information to third
parties should take place only with patient consent (which can be any freely-given specific and informed
indication of his or hertheir wishes, by which the data subject signifies his or hertheir agreement to personal
data relating to him or herthem being processed in an ethically-acceptable way) . More details can be found in
ISO 22600-3ISO 22600-3. For EHR communication across national borders, ISO 22857ISO 22857 provides
guidance that can be used to define appropriate security policy specifications.
Ideally, each fine-grained entry in a patient'spatient’s record should only be accessed by those persons who
have permissions to view that information, specified by or approved by the patient and reflecting the dynamic
nature of the set of persons with legitimate duty of care towards the patient through his or hertheir 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 patient feels is too
personal for them to access. On the opposite side, the labelling by patients 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 health care providers having such a filtered
perspective that they are misled into managing the patient inappropriately. Patients'Patients’ views on the
1)
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. Patients 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 patient during the course of modern health care;
— the large number of health care personnel, often rotating through posts, who mightcan potentially come
into contact with a patient at any one time;
— the large number of organisations with which a patient mightcan come into contact during his or hertheir
lifetime;
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).

vi
ISO/DISFDIS 13606-4:2026(en)
— the difficulty (for a patient or for anyone else) of classifying in a standardized way how sensitive a record
entry mightcan be;
— the difficulty of determining how important a single health record entry mightcan be to the future care of
a patient, and to which classes of user;
— 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 patients to have their consent for disclosure
recorded and respected;
— the low level of concern the majority of patients 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 health care 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 this 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 this 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 patients 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 patient’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
defined in ISO 13606-1ISO 13606-1,, and defines specific information structures that are to be communicated
as part of an EHR_EXTRACT defined in ISO 13606-1ISO 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 theISO 22600ISO 22600 (Privilege Management and Access Control). 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).
vii
ISO/DISFDIS 13606-4:2026(en)
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
ISO 13606-5. 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
need to beare 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.
viii
ISO/DISFDIS 13606-4:2026(en)
ix
ISO/DISFDIS 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 mightcan be healthcare professionals, the patient,
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 patient, 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.
The requirements for this interaction will be reflected in the REQUEST_EHR_EXTRACT interface model
defined in ISO 13606-5ISO 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
document and the corresponding interface defined in ISO 13606-5ISO 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 patient or representatives. These might not
x
ISO/DISFDIS 13606-4:2026(en)
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 patient.
No healthcare-specific security considerations– the interface model is defined in ISO 13606-5ISO 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 shared care pathway or to add new data to an existing EHR.
The EHR_EXTRACT is required to conform to the Reference Model defined in ISO 13606-1ISO 13606-1,, and
to the interface model defined in ISO 13606-5ISO 13606-5.
The EHR_EXTRACT shshould 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
This is now considered to be desirable practice, to enable a patient to discover who has accessed part or all of
his/hertheir 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.
The interface model is defined in ISO 13606-5ISO 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.
xi
ISO/DISFDIS 13606-4:2026(en)
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 patient or to a healthcare professional might require that some
entries are filtered out (such as those referring to EHR data to which the patient does not have access).
The interface model is defined in ISO 13606-5ISO 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 patient.
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
personal data are published in ISO/IEC 27002ISO/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 ISO 27799ISO 27799 (Health informatics – Security management in health using
ISO/IEC 27002). This will facilitate the formulation of common security polices across healthcare, and should
help promote the adoption of interoperable security components and services. The ISO 22600ISO 22600
(Health informatics — Privilege management and access control) series defines a comprehensive
architectural approach to formally and consistently defining and managing such policies. For EHR
communication across national borders ISO 22857ISO 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.
This document therefore requires that an overall security policy or set of policies conforming to ISO
27799ISO 27799 is in place at all of the sites participating in an EHR communication, and alsoassumes that
these policies conform to national or trans-border data protection legislation. Additional polices 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.
xii
ISO/DISFDIS 13606-4:2026(en)
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.
The ISO 22600ISO 22600 (all parts) 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 defined in the ISO 22600ISO 22600 (all parts). series.

Figure 2 — Main concepts and policy types defined in Role Based Access Control [ISO
22600[ISO 22600 (all parts)] series]
Defining constraints on roles, processes, target objects and related privileges by policies, Figure 2 turns into
Figure 3, according to the ISO 22600ISO 22600 (all parts). series.
xiii
ISO/DISFDIS 13606-4:2026(en)
Figure 3 — Policy-driven RBAC Schema
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 patient. 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 propagation.
Whilst this document assumes the adoption of the ISO 22600that standard 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.
As a complement to that standard, ISO 21298ISO 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
negotiation phase of an access decision). This document also assumes the adoption of ISO 21298that standard,,
and aligns with it.
xiv
ISO/DISFDIS 13606-4:2026(en)
The relationship of the policy model defined in this document to the HL7 Healthcare Privacy and Security
Classification System is explained in Annex B.
ISO 27789ISO 27789 defines a comprehensive representation of audit log and audit trail information relating
to all of the events that mightcan 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 defines a profile (sub-set) of the ISO 27789ISO 27789 audit log model specifically for the
purpose of communicating with patients and other authorised parties’ information about who has accessed
the EHR of a specified patient, when and why.
A large number of EHR-specific medico-legal and ethical requirements are expressed within ISO
18308ISO 18308,, although complianceconformity with these is primarily met through specific classes and
attributes of the EHR Reference Model (published in ISO 13606-1ISO 13606-1).). The ISO 13606ISO 13606
standard as a whole series enables conformanceconformity to ISO 18308ISO 18308,, and this document
specifically enables conformance to its ethical and legal requirements and fair information principles.
05  EHR access policy model
0.4.3 Overall approach
In the ISO 13606-1ISO 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 it. 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)),
patients 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 might notcant be practicalimpractical for these data sharing agreements to be negotiated in
traditional 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 complyconform 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 not be ableunable 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
vocabulariesclassifications that can provide a minimum basis for making an access policy decision, and ensure
a basic level 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);
xv
ISO/DISFDIS 13606-4:2026(en)
b) a high-level classification of EHR Requesters and Recipients, through a set of Functional Roles.
0.4.4 Defining 'Need “need-to Know'-know” when handling EHR data
Within many healthcare environments (within and between collaborating healthcare teams involved in the
direct provision of care to patients) the norm is to share health record information openly. It is indeed the
wish of the vast majority of patients that teams do this, and many patients 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 health care systems, national health services and millions of
patients 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 patient evolve would also be a complex process.
Whilst a suite of access policies might in theory be defined (by patients or by others) to provide a multi-level
access level 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 patient. (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 patients 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.
xvi
ISO/DISFDIS 13606-4:2026(en)
Key
A private entries shared with GP
xvii
ISO/DISFDIS 13606-4:2026(en)
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
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— Illustration of access — Access domains within an example EHR
In Figure 4this illustration,, it is assumed that the patient has complete access to his or hertheir EHR. The
majority of this patient’s EHR is accessible to any party providing direct clinical care. However, the EHR does
contain several private entries; some are restricted to the patient’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 patient mightcan nominate other parties to
access these subsets of the EHR if he or she wishesthey wish). One aspect of privilege is the assignment by an
organisation of roles to a clinician that mightcan be exercised in an emergency that confer privileges that
exceed those of his or hertheir normal role. Such an emergency override mightcan, for example, confer access
to a wider set of patient 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 have need to know certain key facts about a patient in order to play their role in the
overall delivery of efficient care, such as knowing that a patient has special health advocacy needs or that
hethey will need to have 24 % oxygen and a wheelchair in order to be transported to the radiology
department.
This example does not illustrate how patients 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 patient.
Whilst a set of rich policies mightcan be defined for specific kinds of patients, specific settings, or just because
one patient is more concernedin cases where patients have specific concerns about his or hertheir EHR than
another, 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.
xviii
ISO/DISFDIS 13606-4:2026(en)
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.4.5 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 E
...

PROJET FINAL
Norme
internationale
ISO/TC 215
Informatique de santé —
Secrétariat: ANSI
Communication du dossier de santé
Début de vote:
informatisé —
2026-04-29
Partie 4:
Vote clos le:
2026-07-22
Sécurité
Health informatics — Electronic health record communication —
Part 4: Security
LES DESTINATAIRES DU PRÉSENT PROJET SONT
INVITÉS À PRÉSENTER, AVEC LEURS OBSERVATIONS,
NOTIFICATION DES DROITS DE PROPRIÉTÉ DONT ILS
AURAIENT ÉVENTUELLEMENT CONNAISSANCE ET À
FOURNIR UNE DOCUMENTATION EXPLICATIVE.
OUTRE LE FAIT D’ÊTRE EXAMINÉS POUR
ÉTABLIR S’ILS SONT ACCEPTABLES À DES FINS
INDUSTRIELLES, TECHNOLOGIQUES ET COM-MERCIALES,
AINSI QUE DU POINT DE VUE DES UTILISATEURS, LES
PROJETS DE NORMES
TRAITEMENT PARALLÈLE ISO/CEN
INTERNATIONALES DOIVENT PARFOIS ÊTRE CONSIDÉRÉS
DU POINT DE VUE DE LEUR POSSI BILITÉ DE DEVENIR DES
NORMES POUVANT
SERVIR DE RÉFÉRENCE DANS LA RÉGLEMENTATION
NATIONALE.
Numéro de référence
PROJET FINAL
Norme
internationale
ISO/TC 215
Informatique de santé —
Secrétariat: ANSI
Communication du dossier de santé
Début de vote:
informatisé —
2026-04-29
Partie 4:
Vote clos le:
2026-07-22
Sécurité
Health informatics — Electronic health record communication —
Part 4: Security
LES DESTINATAIRES DU PRÉSENT PROJET SONT
INVITÉS À PRÉSENTER, AVEC LEURS OBSERVATIONS,
NOTIFICATION DES DROITS DE PROPRIÉTÉ DONT ILS
AURAIENT ÉVENTUELLEMENT CONNAISSANCE ET À
FOURNIR UNE DOCUMENTATION EXPLICATIVE.
DOCUMENT PROTÉGÉ PAR COPYRIGHT
OUTRE LE FAIT D’ÊTRE EXAMINÉS POUR
ÉTABLIR S’ILS SONT ACCEPTABLES À DES FINS
© ISO 2026 INDUSTRIELLES, TECHNOLOGIQUES ET COM-MERCIALES,
AINSI QUE DU POINT DE VUE DES UTILISATEURS, LES
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, aucune partie de cette
PROJETS DE NORMES
TRAITEMENT PARALLÈLE ISO/CEN
INTERNATIONALES DOIVENT PARFOIS ÊTRE CONSIDÉRÉS
publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique,
DU POINT DE VUE DE LEUR POSSI BILITÉ DE DEVENIR DES
y compris la photocopie, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
NORMES POUVANT
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
SERVIR DE RÉFÉRENCE DANS LA RÉGLEMENTATION
NATIONALE.
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 Numéro de référence
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 .18
Annexe B (informative) Relations entre le présent document et des approches alternatives .22
Bibliographie .24

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 patients 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 patient (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 de
[1]
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 patient soit accessible uniquement
par les personnes qui ont l’autorisation de voir ces informations, spécifiées ou approuvées par le patient et
reflétant la nature dynamique de l’ensemble des personnes disposant d’un devoir de soins légitime envers le
patient 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 patient considère comme trop personnelles pour les leur
divulguer. Par ailleurs, il convient que l’étiquetage par les patients 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 erreur dans la gestion du patient. Le point de vue
1)
des patients 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 patients 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 patient;
— le grand nombre de personnels de soins de santé, changeant souvent de postes, pouvant potentiellement
entrer en contact avec un patient à tout moment;
— le grand nombre d’organisations avec lesquelles un patient peut entrer en contact au cours de sa vie;
— la difficulté (pour le patient ou pour toute autre personne) à classer de manière normalisée la sensibilité
éventuelle d’un élément de dossier;
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é à déterminer l’importance éventuelle d’une entrée unique dans un dossier de santé pour les
soins futurs du patient 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 patients de voir leur consentement
à la divulgation enregistré et respecté;
— le faible niveau de demandes relatives à ces exigences de la part de la majorité des patients, 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 ce 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 patients 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 patient.
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).
0.3  Scénarios de communication
0.3.1  Flux de données
vi
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 patient, 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
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.
vii
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 patient 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 patient 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 patient.
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
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 .

viii
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 patient 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 patient 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 patient 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
patient.
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.
0.4  Exigences et approche technique
0.4.1 Exigences générales relatives à la sécurité des soins de santé

ix
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 .
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 ]
x
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 patient. 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
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
patients et les autres parties autorisées des informations indiquant qui a accès au DSI d’un patient 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

xi
[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 y accéder. 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 patients 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
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 patients), la norme est de partager les informations
du dossier de santé de manière ouverte. La grande majorité des patients souhaite que cela se passe ainsi
et de nombreux patients 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.

xii
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 patients 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 patient é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 patients 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 patient. (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 patients et les professionnels puissent avoir
besoin par moments de restreindre l’accès à certaines données du DSI plus personnelles et sensibles. Il est
...