ISO 27789:2021
(Main)Health informatics - Audit trails for electronic health records
Health informatics - Audit trails for electronic health records
This document specifies a common framework for audit trails for electronic health records (EHR), in terms of audit trigger events and audit data, to keep the complete set of personal health information auditable across information systems and domains. It is applicable to systems processing personal health information that create a secure audit record each time a user reads, creates, updates, or archives personal health information via the system. NOTE Such audit records at a minimum uniquely identify the user, uniquely identify the subject of care, identify the function performed by the user (record creation, read, update, etc.), and record the date and time at which the function was performed. This document covers only actions performed on the EHR, which are governed by the access policy for the domain where the electronic health record resides. It does not deal with any personal health information from the electronic health record, other than identifiers, the audit record only containing links to EHR segments as defined by the governing access policy. It does not cover the specification and use of audit logs for system management and system security purposes, such as the detection of performance problems, application flaw, or support for a reconstruction of data, which are dealt with by general computer security standards such as ISO/IEC 15408 (all parts)[9]. Annex A gives examples of audit scenarios. Annex B gives an overview of audit log services.
Informatique de santé — Historique d'expertise des dossiers de santé informatisés
Le présent document définit un cadre commun pour les pistes d'audit des dossiers de santé informatisés (DSI), en termes d'événements déclencheurs d'audit et de données d'audit, afin de conserver l'ensemble complet des informations personnelles de santé auditables, quels que soient les systèmes et les domaines d'information. Le présent document s'applique aux systèmes de traitement des informations personnelles de santé qui créent un enregistrement d'audit sécurisé chaque fois qu'un utilisateur crée des informations personnelles de santé, qu'il les lit, qu'il les met à jour ou qu'il les archive par le biais du système. NOTE Au minimum, ces enregistrements d'audit identifient de manière unique l'utilisateur, identifient de manière unique le sujet de soins, identifient la fonction exécutée par l'utilisateur (création d'un dossier, lecture d'un dossier, mise à jour d'un dossier, etc.) et enregistrent la date et l'heure auxquelles la fonction a été exécutée. Le présent document ne couvre que les actions effectuées sur le dossier de santé informatisé, qui sont régies par une politique d'accès propre au domaine dans lequel s'inscrit le dossier de santé informatisé. Il ne traite d'aucune information personnelle de santé issue de dossiers de santé informatisés, à l'exception des identifiants, les enregistrements d'audit ne contenant que des liens pointant vers des segments du DSI, tels que définis par la politique d'accès applicable. Le présent document ne couvre pas non plus la spécification et l'utilisation des journaux d'audit à des fins de gestion et de sécurité du système, par exemple, la détection des problèmes de performance, des failles au niveau des applications, ou le support de reconstruction des données, qui sont traités par les normes de sécurité informatique générales, telles que l'ISO/IEC 15408 (toutes les parties)[9]. L'Annexe A donne des exemples de scénarios d'audit. L'Annexe B donne un aperçu des services de journal d'audit.
General Information
- Status
- Published
- Publication Date
- 04-Oct-2021
- Technical Committee
- ISO/TC 215 - Health informatics
- Drafting Committee
- ISO/TC 215/WG 4 - Security, Safety and Privacy
- Current Stage
- 9092 - International Standard to be revised
- Start Date
- 29-Jun-2025
- Completion Date
- 13-Dec-2025
Relations
- Effective Date
- 06-Jun-2022
- Effective Date
- 27-Jan-2018
Overview
ISO 27789:2021 - Health informatics - Audit trails for electronic health records - specifies a common framework for audit trails in Electronic Health Record (EHR) systems. It applies to systems that process personal health information (PHI) and create a secure audit record each time a user reads, creates, updates, or archives PHI. The standard ensures that actions on EHRs are auditable across systems and domains while limiting audit records to identifiers and links (not PHI content).
Key point: audit records must at minimum uniquely identify the user and the subject of care, record the function performed (create/read/update/archive), and capture date/time.
Key topics and technical requirements
ISO 27789 defines the structure, content and management of audit logs for health informatics. Major technical topics include:
- Trigger events - which user actions generate audit entries (access, query, create, update, archive).
- Audit record format - required elements such as Event ID, action code, date/time, outcome indicator and event type.
- User and role identification - unique user IDs, alternative IDs, user names, role codes and purpose-of-use indicators.
- Participant object identification - identifiers for EHR segments, object type, lifecycle events and sensitivity.
- Access point and audit source - network access point IDs, audit enterprise/site IDs and source type codes to support cross-domain tracing.
- Security and lifecycle management - requirements for secure storage, availability, confidentiality, integrity, retention, and controlled access to audit data.
- Scope limitations - audit records should not contain PHI beyond identifiers/links; system management/security logs (e.g., performance monitoring) are out of scope and addressed by general security standards.
- Informative annexes - Annex A provides audit scenarios; Annex B outlines audit log services.
Applications and who uses it
ISO 27789 is used to design, implement and validate auditable EHR systems for:
- EHR vendors and software developers (audit log design and interoperability)
- Health IT architects and system integrators (cross-domain audit frameworks)
- Clinical and hospital IT managers, CISOs and compliance officers (governance, access monitoring)
- Auditors, privacy officers and regulators (investigations, incident response, legal evidence)
- Health information exchanges and multi‑site deployments (consistent auditing across domains)
Practical uses include forensic investigations, compliance with privacy laws, patient access and rights requests, supervision of access policy compliance, and retention/evidence management.
Related standards
- ISO/IEC 15408 (general computer and security assurance) - complements system security and management logging.
- DICOM audit interoperability - ISO 27789 harmonizes aspects with DICOM audit formats.
- ISO/TC 215 (Health informatics) outputs and regional/national EHR regulations may reference or adopt ISO 27789.
ISO 27789:2021 - Health informatics — Audit trails for electronic health records Released:10/5/2021
ISO 27789:2021 - Informatique de santé — Historique d'expertise des dossiers de santé informatisés Released:10/5/2021
Frequently Asked Questions
ISO 27789:2021 is a standard published by the International Organization for Standardization (ISO). Its full title is "Health informatics - Audit trails for electronic health records". This standard covers: This document specifies a common framework for audit trails for electronic health records (EHR), in terms of audit trigger events and audit data, to keep the complete set of personal health information auditable across information systems and domains. It is applicable to systems processing personal health information that create a secure audit record each time a user reads, creates, updates, or archives personal health information via the system. NOTE Such audit records at a minimum uniquely identify the user, uniquely identify the subject of care, identify the function performed by the user (record creation, read, update, etc.), and record the date and time at which the function was performed. This document covers only actions performed on the EHR, which are governed by the access policy for the domain where the electronic health record resides. It does not deal with any personal health information from the electronic health record, other than identifiers, the audit record only containing links to EHR segments as defined by the governing access policy. It does not cover the specification and use of audit logs for system management and system security purposes, such as the detection of performance problems, application flaw, or support for a reconstruction of data, which are dealt with by general computer security standards such as ISO/IEC 15408 (all parts)[9]. Annex A gives examples of audit scenarios. Annex B gives an overview of audit log services.
This document specifies a common framework for audit trails for electronic health records (EHR), in terms of audit trigger events and audit data, to keep the complete set of personal health information auditable across information systems and domains. It is applicable to systems processing personal health information that create a secure audit record each time a user reads, creates, updates, or archives personal health information via the system. NOTE Such audit records at a minimum uniquely identify the user, uniquely identify the subject of care, identify the function performed by the user (record creation, read, update, etc.), and record the date and time at which the function was performed. This document covers only actions performed on the EHR, which are governed by the access policy for the domain where the electronic health record resides. It does not deal with any personal health information from the electronic health record, other than identifiers, the audit record only containing links to EHR segments as defined by the governing access policy. It does not cover the specification and use of audit logs for system management and system security purposes, such as the detection of performance problems, application flaw, or support for a reconstruction of data, which are dealt with by general computer security standards such as ISO/IEC 15408 (all parts)[9]. Annex A gives examples of audit scenarios. Annex B gives an overview of audit log services.
ISO 27789:2021 is classified under the following ICS (International Classification for Standards) categories: 35.240.80 - IT applications in health care technology. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO 27789:2021 has the following relationships with other standards: It is inter standard links to ISO 11140-6:2022, ISO 27789:2013. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO 27789:2021 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 27789
Second edition
2021-10
Health informatics — Audit trails for
electronic health records
Informatique de santé — Historique d'expertise des dossiers de santé
informatisés
Reference number
© ISO 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 5
5 Requirements and uses of audit data.5
5.1 Ethical and formal requirements . 5
5.1.1 General . 5
5.1.2 Access policy . 5
5.1.3 Unambiguous identification of information system users. 6
5.1.4 User roles . 6
5.1.5 Secure audit records . 6
5.2 Uses of audit data . 6
5.2.1 Governance and supervision . 6
5.2.2 Subjects of care exercising their rights . 7
5.2.3 Evidence and retention requirements . 7
6 Trigger events . 7
6.1 General . 7
6.2 Details of the event types and their contents . 8
6.2.1 Access events to the personal health information . 8
6.2.2 Query events to the personal health information . 8
7 Audit record details . 8
7.1 The general record format . 8
7.2 Trigger event identification . . . 10
7.2.1 Event ID . 10
7.2.2 Event action code . 11
7.2.3 Event date and time . 11
7.2.4 Event outcome indicator .12
7.2.5 Event type code .12
7.3 User identification .12
7.3.1 User ID . 12
7.3.2 Alternative user ID .13
7.3.3 User name .13
7.3.4 User is requestor .13
7.3.5 Role ID code . 13
7.3.6 Purpose of use . 14
7.4 Access point identification .15
7.4.1 Network access point type code . 15
7.4.2 Network access point ID . 16
7.5 Audit source identification . 16
7.5.1 Overview . 16
7.5.2 Audit enterprise site ID . 17
7.5.3 Audit source ID . . . 17
7.5.4 Audit source type code . 17
7.6 Participant object identification . 18
7.6.1 Overview . 18
7.6.2 Participant object type code . 19
7.6.3 Participant object type code role . 19
7.6.4 Participant object data life cycle and record entry lifecycle events .20
7.6.5 Participant object ID type code . 22
7.6.6 Participant object Permission PolicySet . 23
iii
7.6.7 Participant object sensitivity . 23
7.6.8 Participant object ID . 24
7.6.9 Participant object name . 24
7.6.10 Participant object query . 24
7.6.11 Participant object detail, Participant object description . 24
8 Audit records for individual events .25
8.1 Access events . 25
8.2 Query events . 26
9 Secure management of audit data .28
9.1 Security considerations .28
9.2 Securing the availability of the audit system .28
9.3 Retention requirements .29
9.4 Securing the confidentiality and integrity of audit trails .29
9.5 Access to audit data .29
Annex A (informative) Audit scenarios .30
Annex B (informative) Audit log services .36
Bibliography .45
iv
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 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 27789: 2013), which has been technically
revised.
The main changes are as follows:
— harmonization between audit record format and DICOM format;
— review of the content in Annex A;
— review of the chart in Annex B;
— bibliography update.
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
Introduction
0.1 General
Personal health information is regarded by many as among the most confidential of all types of personal
information and protecting its confidentiality is essential to maintain the privacy of subjects of care. In
order to protect the consistency of health information, it is also important that its entire life cycle be
fully auditable. Health records should be created, processed and managed in ways that guarantee the
integrity and confidentiality of their contents and that support legitimate control by subjects of care in
how the records are created, used and maintained.
Trust in electronic health records requires physical and technical security elements along with data
integrity elements. Among the most important of all security requirements to protect personal health
information and the integrity of records are those relating to audit and logging. These help to ensure
accountability for subjects of care who entrust their information to electronic health record (EHR)
systems. They also help to protect record integrity, as they provide a strong incentive to users of such
systems to conform to organizational policies on the use of these systems.
Effective audit and logging can help to uncover misuse of EHR systems or EHR data and can help
organisations and subjects of care obtain redress against users abusing their access privileges. For
auditing to be effective, it is necessary that audit trails contain sufficient information to address a wide
variety of circumstances (see Annex A).
Audit logs are complementary to access controls. The audit logs provide a means to assess conformity
with organizational access policy and can contribute to improving and refining the policy itself. But as
such a policy needs to anticipate the occurrence of unforeseen or emergency cases, analysis of the audit
logs becomes the primary means of ensuring access control for those cases.
This document is strictly limited in scope to logging of events. Changes to data values in fields of
an EHR are presumed to be recorded in the EHR database system itself and not in the audit log. It is
presumed that the EHR system itself contains both the previous and updated values of every field. This
is consistent with contemporary point-in-time database architectures. The audit log itself is presumed
to contain no personal health information other than identifiers and links to the record.
Electronic health records on an individual person can reside in many different information systems
within and across organisational or even jurisdictional boundaries. To keep track of all actions that
involve records on a particular subject of care, a common framework is a prerequisite. This document
provides such a framework. To support audit trails across distinct domains, it is essential to include
references in this framework to the policies that specify the requirements within the domain,
such as access control rules and retention periods. Domain policies may be referenced implicitly by
identification of the audit log source.
0.2 Benefits of using this document
Standardization of audit trails on access to electronic health records aims at two goals:
— ensuring that information captured in an audit log is sufficient to clearly reconstruct a detailed
chronology of the events that have shaped the content of an electronic health record;
— ensuring that an audit trail of actions relating to a subject of care’s record can be reliably followed,
even across organizational domains.
This document is intended for those responsible for overseeing health information security or privacy
and for healthcare organizations and other custodians of health information seeking guidance on audit
trails, together with their security advisors, consultants, auditors, vendors and third-party service
providers.
0.3 Related standards on electronic health record audit trails
vi
This document builds upon, and is consistent with, the work begun in RFC 3881 with respect to access
to the EHR. This document also builds upon and is consistent with the content in ISO/TS 21089:2018.
vii
INTERNATIONAL STANDARD ISO 27789:2021(E)
Health informatics — Audit trails for electronic health
records
1 Scope
This document specifies a common framework for audit trails for electronic health records (EHR), in
terms of audit trigger events and audit data, to keep the complete set of personal health information
auditable across information systems and domains.
It is applicable to systems processing personal health information that create a secure audit record
each time a user reads, creates, updates, or archives personal health information via the system.
NOTE Such audit records at a minimum uniquely identify the user, uniquely identify the subject of care,
identify the function performed by the user (record creation, read, update, etc.), and record the date and time at
which the function was performed.
This document covers only actions performed on the EHR, which are governed by the access policy
for the domain where the electronic health record resides. It does not deal with any personal health
information from the electronic health record, other than identifiers, the audit record only containing
links to EHR segments as defined by the governing access policy.
It does not cover the specification and use of audit logs for system management and system
security purposes, such as the detection of performance problems, application flaw, or support for
a reconstruction of data, which are dealt with by general computer security standards such as ISO/
[9]
IEC 15408 (all parts) .
Annex A gives examples of audit scenarios. Annex B gives an overview of audit log services.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 27799:2016, Health informatics — Information security management in health using ISO/IEC 27002
ISO 8601-1, Date and time — Representations for information interchange — Part 1: Basic rules
ISO/TS 21089:2018, Health informatics — Trusted end-to-end information flows
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/TS 21089:2018 and the
following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
access control
means to ensure that access to assets is authorized and restricted based on business and security
requirements
[SOURCE: ISO/IEC 27000:2018, 3.1]
3.2
access policy
definition of the obligations for authorizing access to a resource
3.3
accountability
obligation of an individual or organization to account for its activities, for completion of a deliverable
or task, accept responsibility for those activities, deliverables or tasks, and to disclose the results in a
transparent manner
[SOURCE: ISO/TS 21089:2018, 3.3.1]
3.4
agent
entity that takes programmed actions, such as software or a device
[SOURCE: ISO/TS 21089:2018, 3.6.4]
3.5
alert
what is sent when the monitor service notices that a series of events matches a pattern
3.6
audit
independent review and examination of records and activities to assess the adequacy of system
controls, to ensure compliance with established policies and operational procedures, and to recommend
necessary changes in controls, policies or procedures
[SOURCE: ISO/TS 21089:2018, 3.20]
3.7
audit archive
archival collection of one or more audit logs
3.8
audit data
data obtained from one or more audit records
3.9
audit log
chronological sequence of audit records, each of which contains data about a specific event
3.10
audit record
record of a single specific event in the life cycle of an electronic health record
3.11
audit system
information processing system that maintains one or more audit logs
3.12
audit trail
chronological record of system activities that is sufficient to enable the reconstruction, reviewing and
examination of the sequence of environments and activities surrounding or leading to an operation, a
procedure, or an event in a transaction from its inception to final results
[SOURCE: GCST]
3.13
authentication
provision of assurance that a claimed characteristic of an entity is correct
[SOURCE: ISO/IEC 27000:2018, 3.5]
3.14
authorization
granting of rights, which includes the granting of access based on access rights
[SOURCE: ISO/IEC 2382:2015, 2126256, modified — Notes to entry deleted.]
3.15
availability
property of being accessible and useable upon demand by an authorized entity
[SOURCE: ISO/IEC 27000:2018, 3.7]
3.16
confidentiality
property that information is not made available or disclosed to unauthorized individuals, entities, or
processes
[SOURCE: ISO/IEC 27000:2018, 3.10]
3.17
coordinated universal time
UTC
time scale which forms the basis of a coordinated radio dissemination of standard frequencies and time
signals
Note 1 to entry: UTC corresponds exactly in rate with international atomic time, but differs from it by an integral
number of seconds.
[SOURCE: IEC 60050-713:1998, 05-20]
3.18
data integrity
property of data whose accuracy and consistency are preserved regardless of changes made
[SOURCE: ISO 2382:2015, 2126247, modified — Notes to entry deleted.]
3.19
electronic health record
EHR
repository of (organized sets of) information regarding the health status of a subject of care, in
computer processable form
[SOURCE: ISO/TR 20514:2005, 2.11, modified — Text in parenthesis added.]
3.20
electronic health record segment
EHR segment
part of an electronic health record that constitutes a distinct resource for the access policy
3.21
identification
process of recognizing the attributes that identify the object
[SOURCE: ISO 16678:2014, 2.1.7]
3.22
identifier
one or more characters used to identify or name a data element and possibly to indicate certain
properties of that data element
[SOURCE: ISO/IEC 2382:2015, 2121623]
3.23
information security
preservation of confidentiality, integrity and availability of information
[SOURCE: ISO/IEC 27000:2018, 3.28]
3.24
integrity
property of accuracy and completeness
[SOURCE: ISO/IEC 27000:2018, 3.36]
3.25
object identifier
OID
globally unique identifier for an information object
Note 1 to entry: The object identifiers used in this document refer to code systems. These code systems can be
defined in a standard or locally defined per implementation. The object identifier is specified using the Abstract
Syntax Notation One (ASN.1) defined in ISO/IEC 8824-1 and ISO/IEC 8824-2.
3.26
policy
set of rules related to a particular purpose
Note 1 to entry: A rule can be expressed as an obligation, an authorization, a permission or a prohibition.
[SOURCE: ISO 19101-2:2018, modified — Note 1 to entry added]
3.27
privilege
capacity assigned to an entity by an authority
3.28
records management
field of management responsible for control of creation, receipt, maintenance, use and disposition of
records, including processes for capturing and maintaining evidence of and information about business
activities and transactions in the form of records
[SOURCE: ISO 15489-1:2016, 3.15, modified]
3.29
role
set of competences and/or performances associated with a task
3.30
security policy
plan or course of action adopted for providing computer security
[SOURCE: ISO/IEC 2382:2015, 2126246, modified — Notes to entry deleted.]
3.31
sensitivity
measure of the potential or perceived potential to abuse or misuse data about subjects or to harm them
3.32
subject of care
person or defined groups of persons receiving or registered as eligible to receive healthcare services or
having received healthcare services
Note 1 to entry: For example, a patient, client, customer, or health plan member.
[SOURCE: ISO/TS 17975:2015, modified — Note to entry added.]
3.33
user
person or other entity authorized by a provider to use some or all of the services provided by the
provider
Note 1 to entry: Also, human being using the system to issue requests to objects in order to get them to perform
functions in the system on his/her behalf.
[SOURCE: COACH; OMG]
4 Abbreviated terms
HL7 ® Health Level Seven
EV Enumerated Value
5 Requirements and uses of audit data
5.1 Ethical and formal requirements
5.1.1 General
Healthcare providers have their professional ethical responsibilities to meet. Among these are protecting
the privacy of subjects of care and documenting the findings and activities of care. Restricting access to
health records and ensuring their appropriate use are both essential requirements in healthcare and in
many jurisdictions, these requirements are set down in law.
Secure audit trails of access to electronic health records can support conformity with professional
ethics, organizational policies and legislation, but they are not sufficient in themselves to assess
completeness of an electronic health record.
5.1.2 Access policy
Access to the audit trail shall be governed by an access policy. This policy should be determined by the
organization responsible for maintaining the audit log.
The access policy shall be in accordance with ISO 27799:2016, 9.1.1.
NOTE 1 The access policy is presumed to define an EHR segment structure.
NOTE 2 In the audit record the access policy is identified by the audit log source.
[6]
Guidance on specifying and implementing access policies can be found in ISO 22600 (all parts). A field
“Participant object Permission PolicySet” is defined in 7.6.6 to support referencing the actual policies in
the audit record.
5.1.3 Unambiguous identification of information system users
The audit trails shall provide sufficient data to unambiguously identify all authorized health information
system users. Users of the information system can be persons, but also other entities.
The audit trails shall provide sufficient data to determine which authorized users and external systems
have accessed or been sent health record data from the system.
5.1.4 User roles
The audit trail shall show the role of the user while performing the recorded action on personal health
information.
Information systems processing personal health information should support role-based access control
capable of mapping each user to one or more roles, and each role to one or more system functions, as
recommended in ISO 27799:2016, 9.2.3.
[4]
Functional and structural roles are documented in ISO 21298. Additional guidance on privilege
[6]
management in health is given by ISO 22600 (all parts) .
5.1.5 Secure audit records
Secure audit records, in accordance with ISO 27799:2016, 12.4.1, shall be created each time personal
health information is read, created, updated, or archived. The audit records shall be maintained by
secure records management.
5.2 Uses of audit data
5.2.1 Governance and supervision
The audit trails shall provide data to enable responsible authorities to assess conformity with the
organization’s policy and to evaluate its effectiveness.
This implies
— detecting unauthorized access to health records,
— evaluating emergency access, and
— detecting abuse of privileges.
and support for:
— documenting access across domains, and
— evaluation of access policies.
NOTE Full assessment of conformity with the organization’s policy can require additional data that is not
contained in the audit record, such as user information, permission tables or records on physical entry to secured
rooms. See Annex B for audit log services.
The audit trails shall provide sufficient data to determine all access within a defined time period to the
records of subjects of care, by a specified user.
The audit trails shall provide sufficient data to determine all access within a defined time period to the
records of subjects of care, that are marked to be at elevated risk of privacy breaches.
5.2.2 Subjects of care exercising their rights
The audit trails shall provide sufficient data to subjects of care to enable
— assessing which authorized user(s) have accessed his/her health record and when,
— assessing accountability for the content of the record,
— determination of conformity with the subject of care's consent directives on access to or disclosure
of the subject of care's data, and
— determination of emergency access (if any) granted by a user to the subject of care's record, including
the identification of the user, time of access and location where accessed from.
5.2.3 Evidence and retention requirements
The audit trails shall hold data [(that care providers can use as documentary evidence)] to determine
which actions were taken (create, look-up, read, correct, update, extract, output, archive, etc.) in relation
to the information as well as when and by whom.
Audit records shall be retained in accordance with the retention policy as specified in 9.3.
The following documents provides guidance and further information:
— ISO/TS 21089;
[20]
— ISO/HL7 10781.
6 Trigger events
6.1 General
The audit events (trigger events) that cause the audit system to generate audit records are defined
according to each health information system’s scale, purpose, and the contents of privacy and security
policies. As the scope of this document is limited to personal health information, only trigger events
relating to access and query of such information are specified here.
In order to generate the audit records that satisfy the requirement derived from Clause 5, i.e. “when”,
“who”, “whose”, audit records shall be generated for the following two events:
— Access events to personal health information;
— Query events about personal health information.
Examples of out-of-scope events are:
a) Start and stop events of the application program;
b) Authentication events involving authentication of users;
c) Input and output events from/to the external environment;
d) Access events to information other than personal health information;
e) Security alert events related to the application programs;
f) Access events to the audit log preserved in the application programs;
g) Events generated by the operating system, middleware and so on;
h) Access events generated by using system utilities;
i) Physical connection/disconnection events of equipment to the network;
j) Start/stop events of the protection systems such as anti-virus protection systems;
k) Software update events involving software modification or patch programs.
6.2 Details of the event types and their contents
6.2.1 Access events to the personal health information
In this document, the access to the personal health information is regarded as an audit event. Here
“Access” means the creation, reading, update, deletion of data. The contents of the audit log provide
the information about the access “when”, “who” and “access to whose” data to be protected. Table 1
describes the contents in access events.
Table 1 — Access events
Event Contents
When,
Access events to the personal health
Who,
information
Access to whose
6.2.2 Query events to the personal health information
Querying an EHR database in order to obtain personal health information is regarded as an auditable
event. The query event is the query action itself, the reference to the personal health information
resulting from the query is regarded as the access event. The contents of the audit record provide the
information about the query “when”, “who” and “what condition for querying”. Table 2 describes the
contents in query events.
Table 2 — Query events
Event Contents
When,
Query events to the personal health infor-
Who,
mation
What condition for querying
7 Audit record details
7.1 The general record format
Table 3 describes the general format of the audit records. Regarding to the record contents of each
[13] [1]
event, see Clause 8. The record format is defined after RFC 3881 and ISO 12052(DICOM PS3.15) ,
with addition of the optional fields PurposeOfUse and ParticipantObjectPolicySet.
Table 3 — General format of the audit records
Type Field name Option Description Additional info.
Event relat- EventID M ID for the audited event
ed
Type of action per-
EventActionCode M formed during the audit-
(1)
ed event
Date/time of the audited
EventDateTime M See 7.2
event occurrence
Success or failure of the
EventOutcomeIndicator U
event
The category of the
EventTypeCode U
event
User related ID for the person or
UserID M
process
(1.2)
Alternative ID for
AlternateUserID U
user or process
UserName U Name of user or process
Indicator that the user is
See 7.3
UserIsRequestor U
or is not the requestor
Specification of the role
RoleIDCode U the user plays when per-
forming the event
Code for the purpose of
PurposeOfUse U
use of the data accessed
Type of
NetworkAccessPointTypeCode U
network access point
See 7.4
ID for network
NetworkAccessPointID U
access point
Audit sys- Site ID of
AuditEnterpriseSiteID U
tem related
audit enterprise
(1)
Unique ID
See 7.5
AuditSourceID M
of audit source
Type code of audit
AuditSourceTypeCode U
source
Participant Code for the participant
object re- object type
ParticipantObjectTypeCode M
lated
(0.N)
Multiplicity:
(1) :Only 1 exists,
(0.1) :0 or 1 exists,
(1.2) :1 or 2 exist(s)
(0.N) :0 to N exist(s)
Optionality:
M :Mandatory
MC :Conditional Mandatory
U :Optional
M/U :Mandatory or Optional related to events
Table 3 (continued)
Type Field name Option Description Additional info.
ParticipantObjectTypeCodeRole M Object type code of role
Identifier for the data
ParticipantObjectDataLifeCycle U life-cycle stage for the
participant object
Type code of Participant
ParticipantObjectIDTypeCode M
Object ID
Permission PolicySet for
ParticipantObjectPolicySet U
ParticipantObjectID
Sensitivity defined by
ParticipantObjectSensitivity U the policy for Partici-
pantObjectID
Identifies a specific in-
ParticipantObjectID M stance of the participant See 7.6
object
Object name
ParticipantObjectName U
of participant, such as a
person’s name
Contents of query for
ParticipantObjectQuery M/U
the participant object
Detail of
ParticipantObjectDetail U
participant object
Description of
ParticipantObjectDescription U
participant object
Multiplicity:
(1) :Only 1 exists,
(0.1) :0 or 1 exists,
(1.2) :1 or 2 exist(s)
(0.N) :0 to N exist(s)
Optionality:
M :Mandatory
MC :Conditional Mandatory
U :Optional
M/U :Mandatory or Optional related to events
7.2 Trigger event identification
7.2.1 Event ID
Description: Unique identifier for a specific audited event, e.g. a menu item, program, rule, policy,
function code, application name, or URL. It identifies the performed function.
Optionality: Mandatory
Format/Values: Coded value, either defined by the system implementers or as a reference to a standard
vocabulary. The “code” attribute shall be unambiguous and unique, at least within Audit Source ID (see
7.5). Examples of Event IDs are program name, method name, or function name.
[12]
NOTE The coding is modelled after IHE ITI TF-1 and TF-2 and ISO 12052(DICOM PS3.15).
For implementation-defined coded values or references to standards, the XML schema in RFC 3881
defines the optional attributes as shown in Table 4.
Table 4 — Event ID reference attributes
Attribute Value
CodeSystem OID reference
CodeSystemName Name of the coding system; strongly recommended to be valued for locally-de-
fined code-sets.
CodeValue The specific code within the coding system
DisplayName The value to be used in displays and reports
OriginalText Input value that was translated to the code
To support the requirement for unambiguous event identification, multiple values may not be specified.
Rationale: This identifies the audited function. For “Execute” Event Action Code audit records, this
identifies the application function performed.
At least one of CodeSystem (OID) or CodeSystemName is mandatory.
7.2.2 Event action code
Description: Indicator for type of action performed in the audit event.
Optionality: Mandatory
Format/Values: Enumeration as shown in Table 5.
Table 5 — Event action codes
Value Meaning Examples
C Create Create a new database object, such as Placing an Order
R Read /Query Read or query data, such as a diagnosis
U Update Update data, such as Revise Personal Health Information
D Delete Make items inaccessible
E Execute Perform a system or application function such as search,
extract, or use of an object's method
Rationale: This broadly indicates what kind of action was done on the Participant Object.
NOTE 1 Actions that are not enumerated above are considered an Execute of a specific function or object
interface method or treated two or more distinct events. An application action, such as an authorization or digital
signing, is a function Execute, and the Event ID would identify the function.
NOTE 2 For some applications, such as radiological imaging, a Query action can only determine the presence
of data but not access the data itself. Auditing need not always make as fine a distinction.
NOTE 3 Compound actions, such as “Move”, “Archive” or “Copy”, would be logged by creating audit data for
each operation - read, create, delete - or as an Execute of a function or method.
7.2.3 Event date and time
Description: A date/time specification that is unambiguous as to local time zones.
Optionality: Mandatory
Format/Values: A date/time representation that is unambiguous in conveying universal coordinated
time (UTC). The time shall be in a UTC format as per ISO 8601-1 and shall be within a tolerance of no
more than 250 ms of UTC.
Rationale: This ties an event to a specific date and time. Security audits typically require a consistent
time base to eliminate time-zone issues arising from geographical distribution.
[22]
NOTE In a distributed system, some sort of common time base, e.g. an NTP [RFC 1305] server, is a good
implementation tactic.
7.2.4 Event outcome indicator
Description: Indicates whether the event succeeded or failed
Optionality: Optional
Format/Values: Coded value. A code zero (0) indicates success. Values for failure of an event are not
meaningful within the scope of this document.
Rationale: This field is specified to conserve compatibility with audit trails as defined in IETF
[13]
RFC 3881 .
7.2.5 Event type code
Description: Identifier for the category of event.
Optionality: Optional
Format/Values: Coded value enumeration, either defined by the system implementers or as a reference
to a standard vocabulary. For implemen
...
NORME ISO
INTERNATIONALE 27789
Deuxième édition
2021-10
Informatique de santé — Historique
d'expertise des dossiers de santé
informatisés
Health informatics — Audit trails for electronic health records
Numéro de référence
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2021
Droits de reproduction réservés. Sauf indication contraire, 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, l’affichage sur l’internet
ou sur un Intranet, sans autorisation écrite préalable. Les demandes d’autorisation peuvent être adressées à 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
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
ii
Sommaire Page
Avant-propos .v
Introduction . vi
1 Domaine d'application .1
2 Références normatives .1
3 Termes et définitions . 1
4 Abréviations . 5
5 Exigences et usages des données d'audit . 5
5.1 Exigences éthiques et formelles . 5
5.1.1 Généralités . 5
5.1.2 Politique d'accès . 6
5.1.3 Identification sans équivoque des utilisateurs du système informatique . 6
5.1.4 Rôles des utilisateurs . 6
5.1.5 Enregistrements d'audit sécurisés . 6
5.2 Usages des données d'audit . 6
5.2.1 Gouvernance et supervision . 6
5.2.2 Sujets de soins exerçant leurs droits . 7
5.2.3 Exigences de preuve et de conservation . 7
6 Événements déclencheurs .7
6.1 Généralités . 7
6.2 Détails des types d'événements et de leur contenu . 8
6.2.1 Événements d'accès aux informations personnelles de santé . 8
6.2.2 Requêtes concernant les informations personnelles de santé . 8
7 Détails des enregistrements d'audit . 9
7.1 Format d'enregistrement général . 9
7.2 Identification de l'événement déclencheur . 11
7.2.1 ID de l'événement . 11
7.2.2 Code d'action de l'événement.12
7.2.3 Date et heure de l'événement.12
7.2.4 Indicateur de résultat d'événement . 13
7.2.5 Code du type d'événement . 13
7.3 Identification de l'utilisateur . 13
7.3.1 ID d'utilisateur .13
7.3.2 Autre ID d'utilisateur. 14
7.3.3 Nom d'utilisateur . 14
7.3.4 L'utilisateur est demandeur . . 14
7.3.5 Code d'ID de rôle . 14
7.3.6 But de l'utilisation . 16
7.4 Identification de point d'accès . 17
7.4.1 Code du type de point d'accès réseau . 17
7.4.2 ID du point d'accès réseau . 18
7.5 Identification de la source d'audit . 18
7.5.1 Vue d'ensemble. 18
7.5.2 ID de site de l'établissement audité . 19
7.5.3 ID de source d'audit. 19
7.5.4 Code du type de source d'audit . 19
7.6 Identification de l'objet participant . 20
7.6.1 Vue d'ensemble. 20
7.6.2 Code du type de l'objet participant . 20
7.6.3 Code du type de rôle de l'objet participant . 21
7.6.4 Cycle de vie des données de l'objet participant et événements du cycle de
vie de l'entrée d'enregistrement . 22
7.6.5 Code du type d'ID de l'objet participant . 24
iii
7.6.6 Politique établie de permission de l'objet participant . 25
7.6.7 Sensibilité de l'objet participant . 26
7.6.8 ID de l'objet participant . 26
7.6.9 Nom de l'objet participant . 26
7.6.10 Requête de l'objet participant. 26
7.6.11 Détails de l'objet participant, description de l'objet participant .26
8 Enregistrements d'audit des événements individuels .27
8.1 Événements d'accès . 27
8.2 Événements de requêtes . 29
9 Gestion sécurisée des données d'audit .31
9.1 Considérations de sécurité . 31
9.2 Sécuriser la disponibilité du système d'audit . 31
9.3 Exigences de conservation . 31
9.4 Sécuriser la confidentialité et l'intégrité des pistes d'audit . 32
9.5 Accès aux données d'audit . 32
Annexe A (informative) Scénarios d'audit .33
Annexe B (informative) Services de journal d'audit .40
Bibliographie .49
iv
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 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 27789:2013), qui a fait l'objet d'une
révision technique.
Les principales modifications sont les suivantes:
— harmonisation du format des enregistrements d'audit avec le format DICOM;
— révision du contenu de l'Annexe A;
— révision du graphique de l'Annexe B;
— mise à jour de la Bibliographie.
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.
v
Introduction
0.1 Généralités
Parmi tous les types d'informations personnelles, les informations personnelles de santé sont
considérées comme étant les plus confidentielles et la protection de leur confidentialité est essentielle
pour préserver la vie privée des sujets de soins. Afin de protéger la qualité des informations en matière
de santé, il est également important que leur cycle de vie complet soit entièrement auditable. Il convient
de créer, de traiter et de gérer les dossiers de santé de façon à garantir l'intégrité et la confidentialité de
leur contenu et à permettre aux sujets de soins de contrôler de manière tout à fait légitime la façon dont
les dossiers sont créés, utilisés et conservés.
La confiance dans les dossiers de santé informatisés nécessite des éléments de sécurité physiques et
techniques ainsi que des éléments d'intégrité des données. Parmi les exigences de sécurité les plus
importantes pour protéger les informations personnelles de santé et l'intégrité des dossiers figurent
celles qui concernent l'audit et le contrôle d'accès. Elles permettent de respecter les obligations
envers les sujets de soins confiant leurs informations aux systèmes de dossiers de santé informatisés
(DSI). Elles contribuent également à protéger l'intégrité des dossiers, car elles incitent fortement les
utilisateurs à se conformer aux politiques organisationnelles appliquées à l'utilisation de ces systèmes.
Un audit et un contrôle d'accès efficaces peuvent favoriser la détection des utilisations abusives des
systèmes de DSI ou des données de DSI et peuvent aider les organisations et les sujets de soins à obtenir
réparation face à des utilisateurs ayant abusé de leurs privilèges d'accès. Afin que l'audit soit efficace,
il est nécessaire que les pistes d'audit contiennent suffisamment d'informations pour permettre le
traitement de situations très diverses (voir Annexe A).
Les journaux d'audit constituent un complément aux contrôles d'accès. Les journaux d'audit fournissent
un moyen d'évaluer la conformité aux politiques organisationnelles en matière d'accès et peuvent
contribuer à améliorer et à affiner la politique en elle-même. Mais, comme une telle politique a besoin
d'anticiper l'apparition de cas imprévus ou d'urgence, l'analyse des journaux d'audit devient, dans ces
cas-là, le meilleur moyen d'assurer le contrôle des accès.
Le domaine d'application du présent document est strictement limité à la consignation des événements.
Les modifications apportées aux valeurs des champs d'un DSI sont supposées être enregistrées dans
le système de base de données des DSI, et non, dans le journal d'audit. Le système de DSI est supposé
contenir les valeurs de chaque champ, avant et après leur mise à jour, ce qui répond aux architectures
de base de données actuelles. Le journal d'audit en soi n'est supposé contenir aucune information
personnelle de santé autre que les identifiants et les liens pointant vers le dossier.
Le dossier de santé informatisé propre à un certain individu peut appartenir à plusieurs systèmes
d'informations différents, situés à l'intérieur ou au-delà des frontières organisationnelles, voire même
juridictionnelles. Afin de garder la trace de toutes les actions impliquant les dossiers relatifs à un sujet
de soins particulier, il est indispensable de disposer d'un cadre commun. Le présent document fournit
un tel cadre. Pour prendre en charge des pistes d'audit couvrant des domaines distincts, il est essentiel
que ce cadre inclue des références aux politiques qui spécifient les exigences propres à chaque domaine,
telles que les règles de contrôle d'accès et les durées de conservation. Les politiques régissant les
domaines peuvent être référencées implicitement par l'identification de la source du journal d'audit.
0.2 Avantages de l'utilisation du présent document
La normalisation des pistes d'audit concernant l'accès aux dossiers de santé informatisés a deux
objectifs:
— assurer que l'information contenue dans le journal d'audit est suffisante pour reconstruire
clairement la chronologie détaillée des événements ayant conduit au contenu d'un dossier de santé
informatisé;
— assurer que la piste d'audit des actions relatives au dossier d'un sujet de soins puisse être suivie de
façon fiable, même si elle couvre différents domaines organisationnels.
vi
Le présent document est destiné aux responsables de la supervision de la sécurité ou de la confidentialité
des informations de santé, aux organismes de santé et aux autres dépositaires d'informations de santé
qui sont à la recherche de recommandations concernant les pistes d'audit, ainsi qu'à leurs conseillers en
matière de sécurité, consultants, auditeurs, fournisseurs et prestataires de service externes.
0.3 Normes relatives aux pistes d'audit des dossiers de santé informatisés
Le présent document est élaboré sur la base du travail débuté dans le document RFC 3881 concernant
l'accès aux DSI et s'y conforme. Le présent document repose également sur le contenu de l'ISO/
TS 21089:2018 et s'y conforme.
vii
NORME INTERNATIONALE ISO 27789:2021(F)
Informatique de santé — Historique d'expertise des
dossiers de santé informatisés
1 Domaine d'application
Le présent document définit un cadre commun pour les pistes d'audit des dossiers de santé
informatisés (DSI), en termes d'événements déclencheurs d'audit et de données d'audit, afin de
conserver l'ensemble complet des informations personnelles de santé auditables, quels que soient les
systèmes et les domaines d'information.
Le présent document s'applique aux systèmes de traitement des informations personnelles de santé
qui créent un enregistrement d'audit sécurisé chaque fois qu'un utilisateur crée des informations
personnelles de santé, qu'il les lit, qu'il les met à jour ou qu'il les archive par le biais du système.
NOTE Au minimum, ces enregistrements d'audit identifient de manière unique l'utilisateur, identifient de
manière unique le sujet de soins, identifient la fonction exécutée par l'utilisateur (création d'un dossier, lecture
d'un dossier, mise à jour d'un dossier, etc.) et enregistrent la date et l'heure auxquelles la fonction a été exécutée.
Le présent document ne couvre que les actions effectuées sur le dossier de santé informatisé, qui sont
régies par une politique d'accès propre au domaine dans lequel s'inscrit le dossier de santé informatisé.
Il ne traite d'aucune information personnelle de santé issue de dossiers de santé informatisés, à
l'exception des identifiants, les enregistrements d'audit ne contenant que des liens pointant vers des
segments du DSI, tels que définis par la politique d'accès applicable.
Le présent document ne couvre pas non plus la spécification et l'utilisation des journaux d'audit à des
fins de gestion et de sécurité du système, par exemple, la détection des problèmes de performance, des
failles au niveau des applications, ou le support de reconstruction des données, qui sont traités par les
[9]
normes de sécurité informatique générales, telles que l'ISO/IEC 15408 (toutes les parties) .
L'Annexe A donne des exemples de scénarios d'audit. L'Annexe B donne un aperçu des services de journal
d'audit.
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu’ils constituent, pour tout ou partie de leur
contenu, des exigences du présent document. Pour les références datées, seule l’édition citée s’applique.
Pour les références non datées, la dernière édition du document de référence s'applique (y compris les
éventuels amendements).
ISO 27799:2016, Informatique de santé — Management de la sécurité de l'information relative à la santé
en utilisant l'ISO/IEC 27002
ISO 8601-1, Date et heure — Représentations pour l'échange d'information — Partie 1: Règles de base
ISO/TS 21089:2018, Informatique de santé — Flux d'informations "trusted end-to-end"
3 Termes et définitions
Pour les besoins du présent document, les termes et les définitions de l'ISO/TS 21089:2018 ainsi que les
suivants s'appliquent.
L’ISO et l’IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en
normalisation, consultables aux adresses suivantes:
— ISO Online browsing platform: disponible à l’adresse https:// www .iso .org/ obp
— IEC Electropedia: disponible à l’adresse http:// www .electropedia .org/
3.1
contrôle d'accès
moyens mis en œuvre pour assurer que l'accès aux actifs est autorisé et limité selon les exigences
propres à la sécurité et à l'activité métier
[SOURCE: ISO/IEC 27000:2018, 3.1]
3.2
politique d'accès
définition des obligations concernant l'autorisation d'accès à une ressource
3.3
responsabilité
obligation d'un individu ou d'une organisation de rendre compte de ses activités, de l'exécution d'un
livrable ou d'une tâche, d'assumer la responsabilité de ces activités, livrables ou tâches, et d'en divulguer
les résultats de façon transparente
[SOURCE: ISO/TS 21089:2018, 3.3.1]
3.4
agent
entité, telle qu'un logiciel ou un dispositif, qui entreprend des actions programmées
[SOURCE: ISO/TS 21089:2018, 3.6.4]
3.5
alerte
ce qui est envoyé lorsque le service de surveillance remarque une série d'événements correspondant à
un modèle
3.6
audit
revue et examen indépendants de dossiers et d'activités, menés dans le but d'évaluer l'adéquation
des contrôles du système pour garantir la conformité aux politiques et procédures opérationnelles
établies, et de recommander les modifications nécessaires à introduire dans les contrôles, politiques ou
procédures
[SOURCE: ISO/TS 21089:2018, 3.20]
3.7
archive d'audit
archive créée à partir de la collecte d'un ou de plusieurs journaux d'audit
3.8
données d'audit
données obtenues à partir d'un ou de plusieurs enregistrements d'audit
3.9
journal d'audit
séquence chronologique d'enregistrements d'audit, chacun contenant des données sur un événement
spécifique
3.10
enregistrement d'audit
enregistrement d'un événement unique particulier ayant eu lieu au cours du cycle de vie du dossier de
santé informatisé
3.11
système d'audit
système de traitement de l'information permettant de tenir à jour un ou plusieurs journaux d'audit
3.12
piste d'audit
enregistrement chronologique des activités d'un système, suffisant pour permettre la reconstruction,
la vérification et l'examen de la séquence des environnements et des activités qui encadrent, ou
conduisent à, une opération, une procédure ou un événement dans une transaction, de ses débuts
jusqu'à ses résultats finaux
[SOURCE: GCST]
3.13
authentification
moyen pour une entité d'assurer la légitimité d'une caractéristique revendiquée
[SOURCE: ISO/IEC 27000:2018, 3.5]
3.14
autorisation
attribution de droits, comprenant la permission d'accès sur la base de droits d'accès
[SOURCE: ISO/IEC 2382:2015, 2126256, modifiée — Les Notes à l'article ont été supprimées.]
3.15
disponibilité
propriété d'être accessible et utilisable à la demande par une entité autorisée
[SOURCE: ISO/IEC 27000:2018, 3.7]
3.16
confidentialité
propriété selon laquelle l'information n'est pas rendue disponible ou divulguée à des personnes, des
entités ou des processus non autorisés
[SOURCE: ISO/IEC 27000:2018, 3.10]
3.17
temps universel coordonné
UTC
échelle de temps qui constitue la base d'une diffusion radioélectrique coordonnée des fréquences étalon
et des signaux horaires
Note 1 à l'article: Le temps universel coordonné a la même marche que le temps atomique international, mais en
diffère d'un nombre entier de secondes.
[SOURCE: IEC 60050-713:1998, 05-20]
3.18
intégrité des données
propriété assurant que l'exactitude et la cohérence des données sont préservées quels que soient les
changements effectués
[SOURCE: ISO/IEC 2382:2015, 2126247, modifiée — Les Notes à l'article ont été supprimées.]
3.19
dossier de santé informatisé
DSI
dépôt (d'ensembles organisés) d'informations relatives à la santé d'un sujet de soins, sous une forme
pouvant être informatisée
[SOURCE: ISO/TR 20514:2005, 2.11, modifiée — Le texte entre parenthèses a été ajouté.]
3.20
segment de dossier de santé informatisé
segment de DSI
partie d'un dossier de santé informatisé constituant une ressource distincte pour la politique d'accès
3.21
identification
processus de reconnaissance des attributs qui identifient l'objet
[SOURCE: ISO 16678:2014, 2.1.7]
3.22
identifiant
mot ou groupe de mots servant à identifier ou nommer un élément de données et en préciser parfois
certaines propriétés
[SOURCE: ISO/IEC 2382:2015, 2121623]
3.23
sécurité de l'information
protection de la confidentialité, de l'intégrité et de la disponibilité de l'information
[SOURCE: ISO/IEC 27000:2018, 3.28]
3.24
intégrité
propriété d'exactitude et de complétude
[SOURCE: ISO/IEC 27000:2018, 3.36]
3.25
identifiant d'objet
OID
identifiant unique à l'échelle planétaire d'un objet d'information
Note 1 à l'article: Les identifiants d'objet utilisés dans le présent document correspondent à des systèmes de
code. Ces systèmes de code peuvent être définis dans une norme ou peuvent être définis localement par une
implémentation. L'identifiant d'objet est spécifié en utilisant la notation de syntaxe abstraite numéro 1 (ASN.1)
définie dans l'ISO/IEC 8824-1 et dans l'ISO/IEC 8824-2.
3.26
politique
ensemble de règles relatives à un objectif particulier
Note 1 à l'article: Une règle peut s'exprimer sous forme d'obligation, d'autorisation, de permission ou
d'interdiction.
[SOURCE: ISO 19101-2:2018, modifiée — La Note 1 à l'article a été ajoutée.]
3.27
privilège
capacité assignée à une entité par une autorité
3.28
gestion des documents d'activité
champ de l'organisation et de la gestion en charge d'un contrôle de la création, de la réception, de la
conservation, de l'utilisation et du sort final des documents d'activité, y compris des processus de
capture et de préservation de la preuve et de l'information liées aux activités et aux opérations sous la
forme de documents d'activité
[SOURCE: ISO 15489-1:2016, 3.15, modifiée]
3.29
rôle
ensemble de compétences et/ou de performances, associé à une tâche
3.30
politique de sécurité
plan ou programme d'action adopté pour assurer la sécurité informatique
[SOURCE: ISO/IEC 2382:2015, 2126246, modifiée — Les Notes à l'article ont été supprimées.]
3.31
sensibilité
mesure du risque ou du risque perçu qu'un sujet subisse un préjudice associé à ces données ou que
celles-ci soient utilisées de manière abusive ou soient mal utilisées
3.32
sujet de soins
personne ou groupe défini de personnes qui reçoit, qui est habilité à recevoir ou qui a reçu des services
de soins
Note 1 à l'article: Par exemple, un patient, un client ou un membre d'un régime de santé.
[SOURCE: ISO/TS 17975:2015, modifiée — La Note à l'article a été ajoutée.]
3.33
utilisateur
personne ou autre entité autorisée par un fournisseur à utiliser tout ou partie des services proposés
par le fournisseur
Note 1 à l'article: Ce terme désigne également un être humain qui utilise un système pour adresser des demandes
à des objets afin qu'ils exécutent des fonctions sur le système en son nom.
[SOURCE: COACH; OMG]
4 Abréviations
HL7® Health Level Seven (organisme de normalisation des échanges informatiques dans le domaine
de la santé)
EV Valeur énumérée (Enumerated Value)
5 Exigences et usages des données d'audit
5.1 Exigences éthiques et formelles
5.1.1 Généralités
Les prestataires de soins de santé ont certaines responsabilités professionnelles et éthiques à assumer,
comme entre autres, la protection de la vie privée des sujets de soins ainsi que la documentation des
conclusions et des activités de soins. Restreindre l'accès aux dossiers de santé et garantir leur utilisation
appropriée sont deux exigences essentielles dans le domaine des soins de santé et, dans de nombreuses
juridictions, ces exigences sont fixées par la loi.
Les pistes d'audit sécurisées concernant les accès aux dossiers de santé informatisés peuvent appuyer
la conformité avec l'éthique professionnelle, les politiques organisationnelles et la législation, mais elles
ne sont pas suffisantes en elles-mêmes pour évaluer la complétude d'un dossier de santé informatisé.
5.1.2 Politique d'accès
L'accès à la piste d'audit doit être régi par une politique d'accès. Il convient que cette politique soit
définie par l'organisation responsable de la tenue du journal d'audit.
La politique d'accès doit être conforme à l'ISO 27799:2016, 9.1.1.
NOTE 1 La politique d'accès est censée définir la structure d'un segment de DSI.
NOTE 2 Dans l'enregistrement d'audit, la politique d'accès est identifiée par la source du journal d'audit.
Des recommandations sur la spécification et l'implémentation des politiques d'accès peuvent être
[6]
consultées dans l'ISO 22600 (toutes les parties). Un champ «Ensemble de politiques d'autorisation
de l'objet participant» est défini en 7.6.6 afin de prendre en charge les références aux politiques réelles
dans l'enregistrement d'audit.
5.1.3 Identification sans équivoque des utilisateurs du système informatique
Les pistes d'audit doivent fournir suffisamment de données pour identifier sans équivoque tous les
utilisateurs autorisés du système d'informations de santé. Les utilisateurs du système d'informations
peuvent aussi bien être des personnes que d'autres entités.
Les pistes d'audit doivent fournir suffisamment de données pour déterminer quels utilisateurs et
systèmes externes autorisés ont accédé à ou ont reçu des données de dossier de santé de la part du
système.
5.1.4 Rôles des utilisateurs
La piste d'audit doit présenter le rôle de l'utilisateur ayant appliqué l'action enregistrée aux informations
personnelles de santé.
Il convient que les systèmes d'informations traitant des informations personnelles de santé soient
pourvus d'un contrôle d'accès en fonction du rôle, qui soit en mesure de mettre en correspondance
chaque utilisateur avec un ou plusieurs rôles et chaque rôle avec une ou plusieurs fonctions du système,
comme recommandé dans l'ISO 27799:2016, 9.2.3.
[4]
Les rôles fonctionnels et structurels sont documentés dans l'ISO 21298. Des recommandations
supplémentaires sur la gestion des privilèges dans le domaine de la santé sont données dans
[6]
l'ISO 22600 (toutes les parties) .
5.1.5 Enregistrements d'audit sécurisés
Des enregistrements d'audit sécurisés conformes à l'ISO 27799:2016, 12.4.1 doivent être créés à
chaque fois que des informations personnelles de santé sont lues, créées, mises à jour ou archivées. Les
enregistrements d'audit doivent être conservés par le biais d'une gestion sécurisée des enregistrements.
5.2 Usages des données d'audit
5.2.1 Gouvernance et supervision
Les pistes d'audit doivent fournir des données permettant aux autorités responsables d'évaluer la
conformité à la politique organisationnelle et son efficacité.
Cela implique:
— la détection des accès non autorisés aux dossiers de santé;
— l'évaluation des accès d'urgence; et
— la détection des abus de privilèges;
et le support de:
— la documentation des accès entre les domaines; et
— l'évaluation des politiques d'accès.
NOTE Une évaluation complète de la conformité à la politique organisationnelle peut nécessiter des données
complémentaires qui ne sont pas contenues dans l'enregistrement d'audit, telles que des informations relatives à
l'utilisateur, des tableaux ou des enregistrements de permission concernant une entrée physique dans des salles
sécurisées. Voir Annexe B en ce qui concerne les services de journal d'audit.
Les pistes d'audit doivent fournir suffisamment de données pour déterminer tous les accès aux dossiers
de sujets de soins, ayant eu lieu au cours d'une période déterminée et effectués par un utilisateur donné.
Les pistes d'audit doivent fournir suffisamment de données pour déterminer tous les accès aux dossiers
de sujets de soins ayant eu lieu au cours d'une période déterminée et considérés comme représentant
un risque élevé de violation de la vie privée.
5.2.2 Sujets de soins exerçant leurs droits
Les pistes d'audit doivent fournir suffisamment de données pour permettre aux sujets de soins:
— d'évaluer le ou les utilisateurs qui ont eu accès à leur dossier de santé et à quel moment;
— d'évaluer la responsabilité concernant le contenu du dossier;
— de déterminer si les directives traitant du consentement du sujet de soins, eu égard à l'accès aux
données le concernant ou la divulgation de celles-ci, sont respectées; et
— de déterminer les accès d'urgence au dossier de santé du sujet de soins (le cas échéant) octroyés par
un utilisateur, y compris l'identification de l'utilisateur, l'heure d'accès et l'endroit à partir duquel a
eu lieu l'accès.
5.2.3 Exigences de preuve et de conservation
Les pistes d'audit doivent conserver des données (que les prestataires de soins de santé peuvent utiliser
comme preuves documentées) afin d'identifier les actions qui ont été entreprises (création, recherche,
lecture, correction, mise à jour, extraction, exportation, archivage, etc.) en lien avec ces informations,
quand et par qui.
Les enregistrements d'audit doivent être conservés conformément à la politique de conservation décrite
en 9.3.
Les documents suivants fournissent des recommandations et des informations supplémentaires:
— ISO/TS 21089;
[20]
— ISO/HL7 10781 .
6 Événements déclencheurs
6.1 Généralités
Les événements d'audit (événements déclencheurs) qui sont à l'origine de la génération
d'enregistrements d'audit par le système d'audit sont définis en fonction de l'échelle, de l'objectif et du
contenu des politiques de confidentialité et de sécurité de chaque système d'informations de santé. Le
domaine d'application du présent document étant limité aux informations personnelles de santé, seuls
les événements déclencheurs relatifs à l'accès et à la recherche de telles informations sont spécifiés
dans cet article.
Afin de produire les enregistrements d'audit qui satisfont à l'exigence dérivée de l'Article 5,
à savoir «quand», «qui» et «de qui», des enregistrements d'audit doivent être créés lors des deux
événements suivants:
— les événements d'accès aux informations personnelles de santé;
— les événements de requête concernant les informations personnelles de santé.
Parmi les événements non couverts, on peut citer:
a) les événements de démarrage et d'arrêt des programmes d'application;
b) les événements d'authentification impliquant l'authentification d'utilisateurs;
c) les événements d'entrée et de sortie en provenance/en direction d'un environnement extérieur;
d) les événements d'accès aux informations autres que les informations personnelles de santé;
e) les événements concernant les alertes de sécurité impactant les programmes d'application;
f) les événements d'accès au journal d'audit dépendant des programmes d'application;
g) les événements générés par le système d'exploitation, un logiciel intermédiaire, etc.;
h) les événements d'accès générés par l'utilisation d'utilitaires du système;
i) les événements de connexion/déconnexion physique des équipements raccordés au réseau;
j) les événements de démarrage/d'arrêt des systèmes de protection tels que les antivirus;
k) les événements de mise à jour logicielle impliquant la modification ou la correction de programmes.
6.2 Détails des types d'événements et de leur contenu
6.2.1 Événements d'accès aux informations personnelles de santé
Dans le présent document, l'accès aux informations personnelles de santé est considéré comme un
événement d'audit. Ici, le terme «accès» signifie la création, la lecture, la mise à jour et la suppression de
données. Le journal d'audit contient des informations sur les données d'accès de type «quand», «qui» et
«de qui», qui doivent être protégées. Le Tableau 1 décrit le contenu des événements d'accès.
Tableau 1 — Événements d'accès
Événement Contenu
Quand,
Événements d'accès aux informations
Qui,
personnelles de santé
De qui
6.2.2 Requêtes concernant les informations personnelles de santé
Une requête envoyée à une base de données DSI dans le but d'obtenir des informations personnelles de
santé est vue comme un événement auditable. L'événement de requête constitue l'action de requête en
elle-même et la référence aux informations personnelles de santé qui en résulte est considérée comme
un événement d'accès. L'enregistrement d'audit contient les informations de type «quand», «qui»
et «sous quelles conditions» concernant la requête. Le Tableau 2 décrit le contenu des événements de
requêtes.
Tableau 2 — Événements de requêtes
Événement Contenu
Quand,
Requêtes concernant les informations
Qui,
personnelles de santé
Sous quelles conditions
7 Détails des enregistrements d'audit
7.1 Format d'enregistrement général
Le Tableau 3 décrit le format général des enregistrements d'audit. Pour le contenu des enregistrements
de chaque événement, voir Article 8. Le format d'enregistrement est défini d'après le document
[13] [1]
RFC 3881 et la norme ISO 12052 (DICOM PS3.15) avec ajout des champs facultatifs PurposeOfUse
et ParticipantObjectPolicySet.
Tableau 3 — Format général des enregistrements d'audit
Information supplé-
Type Nom du champ Nécessité Description
mentaire
Relatif à EventID O ID de l'événement audité
l'événement
Type d'action effectuée
EventActionCode O lors de l'événement
(1)
audité
Date/heure de l'occur-
Voir 7.2
EventDateTime O rence de l'événement
audité
Succès ou échec de l'évé-
EventOutcomeIndicator F
nement
EventTypeCode F Catégorie de l'événement
Multiplicité:
(1) : 1 seul existe
(0.1) : 0 ou 1 existe
(1.2) : 1 ou 2 existent
(0.N) : 0 à N existent
Nécessité:
O : Obligatoire
OC : Obligatoire avec condition
F : Facultatif
O/F : Obligatoire ou Facultatif selon l'événement
Tableau 3 (suite)
Information supplé-
Type Nom du champ Nécessité Description
mentaire
Relatif à ID de la personne ou du
UserID O
l'utilisateur processus
Autre ID pour l'utilisa-
(1.2)
AlternateUserID F
teur ou le processus
Nom de l'utilisateur ou
UserName F
du processus
Indicateur précisant si
UserIsRequestor F l'utilisateur est (ou non)
Voir 7.3
le demandeur
Spécification du rôle
affecté à l'utilisateur
RoleIDCode F
lors de la réalisation de
l'événement
Code indiquant la finalité
PurposeOfUse F de l'utilisation des don-
nées consultées
Type de point d'accès
NetworkAccessPointTypeCode F
réseau
Voir 7.4
ID du point d'accès
NetworkAccessPointID F
réseau
Relatif au ID du site au sein de
AuditEnterpriseSiteID F
système l'établissement audité
d'audit
ID unique de la source
AuditSourceID O Voir 7.5
d'audit
(1)
Code de type de la
AuditSourceTypeCode F
source d'audit
Relatif à Code du type de l'objet
l'objet parti- participant
ParticipantObjectTypeCode O
cipant
(0.N)
Code du type de rôle de
ParticipantObjectTypeCodeRole O
l'objet
Identifiant du stade de
cycle de vie des données
ParticipantObjectDataLifeCycle F
propres à l'objet parti-
cipant
Code du type de l'ID de
ParticipantObjectIDTypeCode O
l'objet participant
Multiplicité:
(1) : 1 seul existe
(0.1) : 0 ou 1 exist
...
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...