ISO 13606-4:2019
(Main)Health informatics — Electronic health record communication — Part 4: Security
Health informatics — Electronic health record communication — Part 4: Security
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.
Informatique de santé — Communication du dossier de santé informatisé — Partie 4: Sécurité
Le présent document décrit une méthodologie permettant de spécifier les privilèges nécessaires pour accéder aux données de DSI. Cette méthodologie forme une partie de l'architecture générale de communication de DSI définie dans l'ISO 13606-1. Le présent document cherche à traiter uniquement les exigences relatives aux communications de DSI et à représenter et communiquer les informations spécifiques au DSI qui permettent de prendre une décision d'accès. Elle fait également référence aux exigences de sécurité générale qui s'appliquent aux communications de DSI et signale des solutions techniques et des normes qui spécifient les détails de services répondant à ces besoins de sécurité. NOTE Les exigences de sécurité pour les systèmes de DSI non associées à la communication de DSI ne relèvent pas du domaine d'application du présent document.
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 13606-4
First edition
2019-06
Health informatics — Electronic
health record communication —
Part 4:
Security
Informatique de santé — Communication du dossier de santé
informatisé —
Partie 4: Sécurité
Reference number
©
ISO 2019
© ISO 2019
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
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2019 – All rights reserved
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.2.1 Access policy. 7
7.2.2 Target . 7
7.2.3 Request criterion . 8
7.2.4 Sensitivity constraint . 9
7.2.5 Attestation information .10
7.3 Archetype of the access policy COMPOSITION .11
8 Representing audit log information .11
8.1 General .11
8.1.1 EHR audit log extract .11
8.1.2 Audit log constraint .12
8.1.3 EHR audit log entry .13
8.1.4 EHR extract description .14
8.1.5 Demographic extract .15
Annex A (informative) Illustrative access control example .16
Annex B (informative) Relations of ISO 13606-4 to alternative approaches .20
Bibliography .22
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on 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 the following
URL: www .iso .org/iso/foreword .html.
This document was prepared by Technical Committee ISO/TC 215, Health Informatics.
This first edition of ISO 13606-4 cancels and replaces the first edition of ISO/TS 13606-4:2009, which
has been technically revised. The main changes compared to the previous edition are as follows:
— Functional Roles
— Some terms for functional roles have been updated to align with CONTSYS.
— 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.
— 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.
iv © ISO 2019 – All rights reserved
Introduction
0.1 General
This document, is part of a five-part standard series, published jointly by CEN and ISO through the
Vienna Agreement. In this document, dependency upon any of the other parts of this series is explicitly
stated where it applies.
0.2 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 her electronic health record, as well as rights 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 her wishes
by which the data subject signifies his or her agreement to personal data relating to him or her being
processed). More details can be found in ISO 22600-3. For EHR communication across national borders,
ISO 22857 provides guidance that can be used to define appropriate security policy specifications.
Ideally, each fine grained entry in a 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 his or
her 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
1)
inappropriately. Patients' views on the inherent sensitivity of entries in their health record 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 might potentially
come into contact with a patient at any one time;
— the large number of organisations with which a patient might come into contact during his or her
lifetime;
— the difficulty (for a patient or for anyone else) of classifying in a standardized way how sensitive a
record entry might be;
— the difficulty of determining how important a single health record entry might be to the future care
of a patient, and to which classes of user;
1) The term sensitivity is widely used in the security domain for a broad range of safeguards and controls, but in
this document the term refers only to access controls.
— 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-1, and defines specific information structures that are to be
communicated as part 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 ISO 22600 (Privilege Management and Access Control).
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. 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 be considered by this document. For each key data flow there will be an acknowledgement
response, and optionally a rejection may be returned instead of the requested data.
vi © ISO 2019 – All rights reserved
Figure 1 — Principal data flows and security-related business processes covered by this
document
The EHR Requester, EHR Recipient and Audit Log Reviewer might 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-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-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.
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.
The EHR_EXTRACT is required to conform to the Reference Model defined in ISO 13606-1, and to the
interface model defined in ISO 13606-5.
The EHR_EXTRACT sh include or reference any relevant access policies, represented in conformance
with this document, to govern any onward propagation of the EHR data being communicated. Policies
may only be referenced if the EHR recipient is known to have direct access to the same information by
another means.
0.3.8 Acknowledge receipt of EHR_EXTRACT
No healthcare-specific security considerations.
0.3.9 Generate EHR access log entry
As described in 0.3.3.
0.3.10 Request EHR access log view
viii © ISO 2019 – All rights reserved
This is now considered to be desirable practice, to enable a patient to discover who has accessed part
or all of his/her 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-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).
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 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 ISO 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. ISO 22600 (Health informatics —
Privilege management and access control) defines a comprehensive architectural approach to formally
and consistently defining and managing such 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.
This document therefore requires that an overall security policy or set of policies conforming to
ISO 27799 is in place at all of the sites participating in an EHR communication, and also 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.
ISO 22600 (all parts) 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 ISO 22600 (all parts).
Figure 2 — Main concepts and policy types defined in Role Based Access Control
[ISO 22600 (all parts)]
Defining constraints on roles, processes, target objects and related privileges by policies, Figure 2 turns
into Figure 3, according to ISO 22600 (all parts).
Figure 3 — Policy-driven RBAC Schema
x © ISO 2019 – All rights reserved
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 that standard 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 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 that standard,
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.
ISO 27789 defines a comprehensive representation of audit log and audit trail information relating
to all of the events that might 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 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 18308,
although compliance with these is primarily met through specific classes and attributes of the EHR
Reference Model (published in ISO 13606-1). The ISO 13606 standard as a whole enables conformance
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
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 might not be practical 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 comply 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 able 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
vocabularies 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 © ISO 2019 – All rights reserved
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 — Illustration of access domains within an example EHR
In this illustration, it is assumed that the patient has complete access to his or her 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 might nominate
other parties to access these subsets of the EHR if he or she wishes). One aspect of privilege is the
assignment by an organisation of roles to a clinician that might be exercised in an emergency that confer
privileges that exceed those of his or her normal role. Such an emergency override might, 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 he 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 might be defined for specific kinds of patients, specific settings, or just
because one patient is more concerned about his or her 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.
In practice any given EHR system might have other mechanisms for indicating the sensitivity of EHR
data or some equivalent concept. This document does not require EHR systems to store data according
to the sensitivity levels defined in 6.1, but to be able to map to this classification on generating an EHR_
EXTRACT.
0.5.3 Functional Roles for accessing EHR data
In order to make an access decision, the profile and purpose of a proposed EHR Recipient need to be
matched to the policies applying to the EHR held by the EHR provider, including the sensitivity of the
specific RECORD_COMPONENTS that have been requested.
The profile of the requester and/or recipient therefore needs to be specified in an interoperable way.
As discussed earlier, the requirements, legislation, attributes and vocabularies used for this in each
country vary, and cannot yet be standardized.
However, in order to provide a basic level of interoperability minimum conformance to this document
does require either that any request for an EHR_EXTRACT include, as part of the request specification,
the Functional Role of the intended EHR Recipient, as defined in 6.2 and corresponding to those defined
in ISO 21298, or that an alternative jurisdictionally-specified term list be used.
The correlation between Functional Role and EHR sensitivity, for the purpose of granting or denying an
access request, or for filtering the EHR_EXTRACT, is defined in s 6.3.
This mapping provides a basic (coarse-grained) way of limiting the scope of EHR access according to
the kind of party who is making the access request. Additional sophistication can always be added in
situations for which an interoperable specification of the requester profile has been defined at a local
or national level. An illustration of the way in which this basic mapping might be combined with a small
number of additional specifications to specify a relatively rich set of access constraints is provided in
Annex A.
0.6 Audit log interoperability
It is widely recognized that the details of interactions with an EHR system need to be retained for
auditability purposes. However, the way in which these kinds of audit logs are implemented is quite
specific for each EHR system, partly determined by the persistence (such as database storage) approach
adopted, and might also partly be directed by local or national legislation.
Requirements for EHR audit trails are specified in ISO 27789:2013 Health informatics – Audit trails
for electronic health records. That standard specifies a common framework for audit t
...
NORME ISO
INTERNATIONALE 13606-4
Première édition
2019-06
Informatique de santé —
Communication du dossier de santé
informatisé —
Partie 4:
Sécurité
Health informatics — Electronic health record communication —
Part 4: Security
Numéro de référence
©
ISO 2019
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2019
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, aucune partie de cette
publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique,
y compris la photocopie, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: +41 22 749 01 11
Fax: +41 22 749 09 47
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
ii © ISO 2019 – Tous droits réservés
Sommaire Page
Avant-propos .iv
Introduction .vi
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.2.1 Politique d’accès . 7
7.2.2 Cible . 8
7.2.3 Critère de demande . 9
7.2.4 Contrainte de sensibilité .10
7.2.5 Informations d’attestation .11
7.3 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.1.1 Extrait de rapport d’expertise de DSI .13
8.1.2 Contrainte de rapport d’expertise .13
8.1.3 Entrée de rapport d’expertise de DSI .14
8.1.4 Description de l’extrait de DSI .15
8.1.5 Extrait démographique .16
Annexe A (informative) Exemple illustratif de contrôle d’accès.17
Annexe B (informative) Relations entre l’ISO 13606-4 et des approches alternatives .21
Bibliographie .23
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 www
.iso .org/directives).
L’attention est attirée sur le fait que certains des éléments du présent document peuvent faire l’objet de
droits de propriété intellectuelle ou de droits analogues. L’ISO ne saurait être tenue pour responsable
de ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails concernant
les références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de
l’élaboration du document sont indiqués dans l’Introduction et/ou dans la liste des déclarations de
brevets reçues par l’ISO (voir www .iso .org/brevets).
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/iso/fr/avant -propos.
Le présent document a été élaboré par le comité technique ISO/TC 215, Informatique de santé.
Cette première édition de l’ISO 13606-4 annule et remplace la première édition de l’ISO/TS 13606-
4:2009, qui a fait l’objet d’une révision technique.
Les modifications par rapport à l’édition précédente sont les suivantes:
— rôles fonctionnels;
— certains termes relatifs aux rôles fonctionnels ont été mis à jour pour s’aligner sur CONTSYS;
— les règles d’utilisation de ce vocabulaire stipulent maintenant que les juridictions peuvent
nommer des alternatives ou des spécialisations de ces termes si nécessaire;
— modèle de politique d’accès;
Le modèle de politique d’accès permet maintenant d’utiliser les termes alternatifs des juridictions
le cas échéant.
— modèle de rapport d’expertise.
Le modèle de rapport d’expertise est maintenant aligné sur la norme ISO 27789 pour les historiques
d’expertise de DSI. Il contient plus d’informations qu’il n’y en a dans l’ISO 27789: il s’agit d’un
type de spécialisation traitant spécifiquement de la communication des informations du DSI et
des informations du rapport d’expertise. Il inclut donc des informations sur l’extrait de DSI ou
l’extrait de rapport d’expertise communiqué, ce qui ne fait pas partie du domaine d’application de
l’ISO 27789.
Une liste de toutes les parties de la série ISO 13606 se trouve sur le site web de l’ISO.
iv © ISO 2019 – Tous droits réservés
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/fr/members .html.
Introduction
0.1 Généralités
Le présent document fait partie d’une série de normes en cinq parties, publiées conjointement par
le CEN et l’ISO dans le cadre de l’Accord de Vienne. 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 la présente partie de l’ISO 13606
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 dossier
de santé informatisé, 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 ses données personnelles). L’ISO 22600-3 donne
de 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
1)
erreur dans la gestion du patient. Le point de vue 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;
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.
vi © ISO 2019 – Tous droits réservés
— 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;
— 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 l’architecture générale définie dans l’ISO 13606-1 et définit les structures
d’information spécifiques qui 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 l’ISO 22600 (Gestion de privilèges et contrôle d’accès).
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
Les interfaces et les modèles de message exigés pour prendre en charge la communication de DSI
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 que le présent
document doit envisager. 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
viii © ISO 2019 – Tous droits réservés
prévu. Dans certains cas, le demandeur du DSI peut ne pas être la même partie que le destinataire
du DSI, par exemple, un agent logiciel peut déclencher une notification contenant des données de DSI
à envoyer à un professionnel de santé. Dans ce cas, ce sont les justificatifs du destinataire du DSI qui
déterminent principalement la décision d’accès à prendre.
Une demande de DSI peut devoir inclure ou faire référence à des accords d’accès et des mandats de
soins, par exemple par la fourniture d’une forme quelconque de consentement explicite de la part du
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 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 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
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.
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
modèle d’interface défini dans l’ISO 13606-5.
L’EHR_EXTRACT doit inclure ou faire 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.
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).
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
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
x © ISO 2019 – Tous droits réservés
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é
Les exigences les plus largement acceptées pour une approche générale de sécurité dans les domaines
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. Un guide spécifique à la santé pour la présente norme générale a été publié dans l’ISO 27799
(Informatique de santé — Management de la sécurité de l’information relative à la santé en utilisant
l’ISO/IEC 27002). Celui-ci facilite la formulation de politiques de sécurité communes en soins de santé, et
il est censé promouvoir l’adoption de composants et de services de sécurité interopérables. L’ISO 22600
(Informatique de santé — Gestion de privilèges et contrôle d’accès) définit une approche architecturale
complète de définition et de gestion formelles et cohérentes de ces politiques. 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é.
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 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.
L’ISO 22600 (toutes les parties) 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 d’accès basé sur les rôles défini dans l’ISO 22600 (toutes les parties).
Figure 2 — Principaux concepts et types de politiques définis dans le contrôle d’accès basé sur
les rôles [ISO 22600 (toutes les parties)]
Avec la définition des contraintes sur les rôles, les processus, les objets cibles et les privilèges associés
par les politiques, la Figure 2 devient la Figure 3, conformément à l’ISO 22600 (toutes les parties).
Figure 3 — Schéma RBAC selon la politique
Comme illustré sur 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 sur 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 de la norme, 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
xii © ISO 2019 – Tous droits réservés
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.
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 document prend également pour hypothèse l’adoption de cette norme 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.
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) 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
l’ISO 18308, bien que la conformité avec celles-ci soit principalement satisfaite par l’intermédiaire
des classes et attributs spécifiques du modèle de référence de DSI (publié dans l’ISO 13606-1). La
norme ISO 13606 dans son entier 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
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 se révéler peu 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 vocabulaires 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.
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 courant également dans la plupart des services de santé d’isoler
certains milieux médicaux comme contenant des parties exclusives d’un DSI (par exemple les cliniques
de santé sexuelle).
Ce type d’isolement de milieux médicaux ou le marquage des données du DSI comme particulièrement
sensibles est tout à fait distinct de toute subdivision du DSI qui peut être définie pour aider à la
navigation et au flux de travail dans les spécialités médicales, par exemple en définissant des parties
relatives au cancer ou au diabète dans le DSI. La Figure 4 propose une représentation de la manière dont
un DSI peut être subdivisé logiquement du point de vue du besoin de connaître, la classification de la
confidentialité (sensibilité) étant représentée au moyen de classes d’utilisateurs et pour des contextes
de soins particuliers.
xiv © ISO 2019 – Tous droits réservés
Légende
A entrées privées partagées avec le MG
B entrées restreintes à l’équipe de santé sexuelle
C entrées accessibles au personnel administratif
D entrées accessibles au personnel de soutien médical
E entrées accessibles aux équipes de soins directs
F entrées privées partagées avec plusieurs parties nommées
G entrées restreintes aux services de santé en prison
Figure 4 — Représentation des domaines d’accès dans un exemple de DSI
Dans cette représentation, il est pris pour hypothèse que le patient dispose d’un accès complet à son DSI.
La majorité du DSI de ce patient est accessible à toute partie fournissant des soins médicaux directs.
Cependant, le DSI contient plusieurs entrées p
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...