ISO 27789:2013
(Main)Health informatics - Audit trails for electronic health records
Health informatics - Audit trails for electronic health records
ISO 27789:2013 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 which, complying with ISO 27799, create a secure audit record each time a user accesses, creates, updates or archives personal health information via the system. ISO 27789:2013 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-2.
Informatique de santé — Historique d'expertise des dossiers de santé informatisés
L'ISO 27789:2013 spécifie une structure commune pour les historiques d'expertise des dossiers informatisés de santé (DIS), en termes d'événements déclencheurs d'expertise et de données d'expertise, afin de conserver l'ensemble des informations personnelles de santé pouvant être expertisées sur tous les systèmes et domaines d'information. Elle s'applique aux systèmes de traitement des informations personnelles de santé qui, conformément à l'ISO 27799, créent un enregistrement d'expertise sûr chaque fois qu'un utilisateur crée des informations personnelles de santé, qu'il y accède, qu'il les met à jour ou qu'il les archive par le biais du système. L'ISO 27789:2013 ne couvre que les actions effectuées sur le dossier informatisé de santé, qui sont régies par une politique d'accès propre au domaine dans lequel s'inscrit le dossier informatisé de santé. Elle ne traite pas des informations personnelles de santé issues de dossier informatisé de santé mais uniquement des identifiants, l'enregistrement d'expertise ne contenant que les liens menant aux segments du dossier informatisé de santé, tel qu'établi par la politique d'accès en vigueur. Elle ne couvre pas non plus la spécification et l'utilisation des rapports d'expertise dans un but de gestion et de sécurité du système, par exemple pour la détection des problèmes de performance, des failles au niveau des applications, ou en tant que support pour la reconstruction des données, qui sont traitées par les normes de sécurité informatique générales telles que l'ISO/CEI 15408.
General Information
Relations
Frequently Asked Questions
ISO 27789:2013 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: ISO 27789:2013 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 which, complying with ISO 27799, create a secure audit record each time a user accesses, creates, updates or archives personal health information via the system. ISO 27789:2013 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-2.
ISO 27789:2013 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 which, complying with ISO 27799, create a secure audit record each time a user accesses, creates, updates or archives personal health information via the system. ISO 27789:2013 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-2.
ISO 27789:2013 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:2013 has the following relationships with other standards: It is inter standard links to ISO 15531-1:2004, ISO 27789:2021. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO 27789:2013 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
First edition
2013-03-01
Health informatics — Audit trails for
electronic health records
Informatique de santé — Historique d’expertise des dossiers de
santé informatisés
Reference number
©
ISO 2013
© ISO 2013
All rights reserved. Unless otherwise specified, 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
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2013 – All rights reserved
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 4
5 Requirements and uses of audit data . 5
5.1 Ethical and formal requirements . 5
5.2 Uses of audit data . 6
6 Trigger events . 7
6.1 General . 7
6.2 Details of the event types and their contents . 7
7 Audit record details . 8
7.1 The general record format . 8
7.2 Trigger event identification . 9
7.3 User identification . .11
7.4 Access point identification .14
7.5 Audit source identification .15
7.6 Participant object identification .17
8 Audit records for individual events .23
8.1 Access events .23
8.2 Query events .24
9 Secure management of audit data .26
9.1 Security considerations .26
9.2 Securing the availability of the audit system .27
9.3 Retention requirements .27
9.4 Securing the confidentiality and integrity of audit trails .27
9.5 Access to audit data .27
Annex A (informative) Audit scenarios .28
Annex B (informative) Audit log services .35
Bibliography .44
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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International
Standards adopted by the technical committees are circulated to the member bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the member bodies
casting a vote.
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.
ISO 27789 was prepared by Technical Committee ISO/TC 215, Health informatics.
iv © ISO 2013 – All rights reserved
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 if the privacy of subjects of care is to be
maintained. 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
organizations 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 compliance
with organizational access policy and can contribute to improving and refining the policy itself. But as
such a policy has 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 International Standard 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 may reside in many different information systems
within and across organizational 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 International
Standard 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 International Standard
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, and
— ensuring that an audit trail of actions relating to a subject of care’s record can be reliably followed,
even across organizational domains.
This International Standard 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 Comparision with related standards on electronic health record audit trails
This International Standard conforms to the requirements of ISO 27799:2008, insofar as they relate to
auditing and audit trails.
Some readers may be familiar with Internet Engineering Task Force (IETF) Request for Comment
[13]
(RFC) 3881. (Readers not already familiar with IETF RFC 3881 need not refer to that document, as
familiarity with it is not required to understand this International Standard.) Informational RFC 3881,
dated 2004-09 and no longer listed as active in the IETF database, was an early and useful attempt at
specifying the content of audit logs for healthcare. To the extent possible, this International Standard
builds upon, and is consistent with, the work begun in RFC 3881 with respect to access to the EHR.
0.4 A note on terminology
Several closely related terms are defined in Clause 3. An audit log is a chronological sequence of audit
records; each audit record contains evidence of directly pertaining to and resulting from the execution of a
process or system function. As EHR systems can be complex aggregations of systems and databases, there
may be more than one audit log containing information on system events that have altered a subject of
care’s EHR. Although the terms audit trail and audit log are often used interchangeably, in this International
Standard the term audit trail refers to the collection of all audit records from one or more audit logs that
refer to a specific subject of care or specific electronic health record or specific user. An audit system
provides all the information processing functions necessary to maintain one or more audit logs.
vi © ISO 2013 – All rights reserved
INTERNATIONAL STANDARD ISO 27789:2013(E)
Health informatics — Audit trails for electronic health
records
1 Scope
This International Standard 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 which, complying with ISO 27799,
create a secure audit record each time a user accesses, 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, access, update, etc.), and record the date and time at
which the function was performed.
This International Standard 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
[9]
of data, which are dealt with by general computer security standards such as ISO/IEC 15408-2.
Annex A gives examples of audit scenarios. Annex B gives an overview of audit log services.
2 Normative references
The following referenced documents are indispensable for the application 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 8601:2004, Data elements and interchange formats — Information interchange — Representation of
dates and times
ISO 27799:2008, Health informatics — Information security management in health using ISO/IEC 27002
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
access control
means to ensure that access to assets is authorized and restricted based on business and security
requirements
[ISO/IEC 27000:2012, definition 2.1]
3.2
access policy
definition of the obligations for authorizing access to a resource
3.3
accountability
principle that individuals, organizations and the community are responsible for their actions and may
be required to explain them to others
[ISO 15489-1:2001, definition 3.2]
3.4
audit
systematic and independent examination of accesses, additions or alterations to electronic health
records to determine whether the activities were conducted, and the data were collected, used, retained
or disclosed according to organizational standard operating procedures, policies, good clinical practice,
and applicable regulatory requirement(s)
3.5
audit archive
archival collection of one or more audit logs
3.6
audit data
data obtained from one or more audit records
3.7
audit log
chronological sequence of audit records, each of which contains data about a specific event
3.8
audit record
record of a single specific event in the life cycle of an electronic health record
3.9
audit system
information processing system that maintains one or more audit logs
3.10
audit trail
collection of audit records from one or more audit logs relating to a specific subject of care or a specific
electronic health record
3.11
authentication
provision of assurance that a claimed characteristic of an entity is correct
[ISO/IEC 27000:2012, definition 2.8]
3.12
authorization
granting of privileges, which includes the granting of privileges to access data and functions
Note 1 to entry: Derived from ISO 7498-2: the granting of rights, which includes the granting of access based on
access rights.
3.13
authority
entity responsible for issuing certificates
3.14
availability
property of being accessible and useable upon demand by an authorized entity
[ISO/IEC 27000:2012, definition 2.10]
2 © ISO 2013 – All rights reserved
3.15
confidentiality
property that information is not made available or disclosed to unauthorized individuals, entities or processes
[ISO/IEC 27000:2012, definition 2.13]
3.16
Coordinated Universal Time
UTC
time scale which forms the basis of a coordinated radio dissemination of standard frequencies and time
signals; it corresponds exactly in rate with international atomic time, but differs from it by an integral
number of seconds
[IEC 60050-713:1998]
3.17
data integrity
property that data have not been altered or destroyed in an unauthorized manner
[ISO 7498-2:1989, definition 3.3.21]
3.18
electronic health record
EHR
comprehensive, structured set of clinical, demographic, environmental, social and financial data in
electronic form, documenting the health care given to a single individual
[ASTM E1769:1995]
3.19
EHR segment
part of an EHR that constitutes a distinct resource for the access policy
3.20
identification
performance of tests to enable a data processing system to recognize entities
[ISO/IEC 2382-8:1998, definition 08.04.12 (as identitiy authentication, identity validation)]
3.21
identifier
piece of information used to claim an identity, before a potential corroboration by a corresponding
authenticator
3.22
information security
preservation of confidentiality, integrity and availability of information
[ISO/IEC 27000:2012, definition 2.30]
3.23
integrity
property of protecting the accuracy and completeness of assets
[ISO/IEC 27000:2012, definition 2.36]
3.24
object identifier
OID
globally unique identifier for an information object
Note 1 to entry: The object identifiers used in this International Standard refer to code systems. These code
systems may 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.25
policy
set of legal, political, organizational, functional and technical obligations for communication and cooperation
[ISO/TS 22600]
3.26
privilege
capacity assigned to an entity by an authority
3.27
records management
field of management responsible for the efficient and systematic control of the 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
[ISO 15489-1, definition 3.16]
3.28
role
set of competences and/or performances associated with a task
3.29
sensitivity
measure of the potential or perceived potential to create harm to a data subject, or to be abused, or misused
3.30
security policy
plan or course of action adopted for providing computer security
[ISO/IEC 2382-8:1998, definition 08.01.06]
3.31
subject of care
person scheduled to receive, receiving or having received a health service
[ISO 18308:2011, definition 3.47]
3.32
user
person, device or program that uses an EHR system for data processing or health information exchange
4 Symbols and abbreviated terms
EHR Electronic Health Record
HL7 Health Level Seven International
OID Object Identifier
UTC Coordinated Universal Time
4 © ISO 2013 – All rights reserved
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 health care and in
many jurisdictions these requirements are set down in law.
Secure audit trails of access to electronic health records may support compliance 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
An organization responsible for maintaining an audit log shall identify the access policy governing all
accesses logged.
The access policy shall be in accordance with ISO 27799:2008, 7.8.1.2, Access control policy.
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/TS 22600. 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:2008, 7.8.2.2, Privilege management.
[4]
Functional and structural roles are documented in ISO/TS 21298. Additional guidance on privilege
[6]
management in health is given by ISO/TS 22600, (all parts).
5.1.5 Secure audit records
Secure audit records shall be created each time personal health information is accessed, created,
updated or archived, in accordance with ISO 27799:2008, 7.7.10.2, Audit logging. 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 compliance with the
organization’s policy and to evaluate its effectiveness.
This implies
— detecting unauthorized access to health records,
— evaluating emergency access,
— detecting abuse of privileges,
and support for:
— documenting access across domains, and
— evaluation of access policies.
NOTE Full assessment of compliance with the organization’s policy can require additional data which are 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 subects 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 compliance 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 Healthcare provider’s ethical or legal proof of action
The audit trails shall provide data to provide to care providers documented evidence of what information
was viewed and which actions were taken (create, look-up, read, correct, update, extract, output, archive,
etc.) in relation to the information when and by whom.
Retention of the audit records should be aligned with the legal terms of accountability within the
jurisdiction.
Refer to HL7 EHR Records Management and Evidentiary Support (RM-ES).
6 © ISO 2013 – All rights reserved
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. The scope of this International Standard being limited to access to personal health information,
only trigger events relating to accesss are specified here.
In order to generate the audit records which satisfy the requirement derived from Clause 5 (Requirements
and uses of audit data), i.e. “when”, “who”, “whose”, the following two events are mandatory:
a) Access events to personal health information,
b) Query events about personal health information.
Examples of out-of-scope events are:
— start-and-stop events of the application program;
— authentication events involving authentication of users;
— input and output events from/to the external environment;
— access events to information other than personal health information;
— security alert events related to the application programs;
— access events to the audit log preserved in the application programs;
— events generated by the operating system, middleware and so on;
— access events generated by using system utilities;
— physical connection/disconnection events of equipments to the network;
— start/stop events of the protection systems such as anti-virus protection systems;
— 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 International Standard, the access to the personal health information is regarded as the 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. See Table 1.
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”. See Table 2.
Table 2 — Query events
Event Contents
When,
Query events to the personal
Who,
health information
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 event,
[13] [11]
see Clause 8. The record format is defined after RFC 3881 and DICOM, 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 related EventID M ID for the audited event
(1)
Type of action performed during
EventActionCode M
the audited event
Date/time of the audited event Refer to 7.2
EventDateTime M
occurrence
EventOutcomeIndicator U Success or failure of the event
EventTypeCode U The category of the event
User related UserID M ID for the person or process
(1.2)
AlternateUserID U Alternative ID for user or process
UserName U Name of user or process
Indicator that the user is or is not
UserIsRequestor U
Refer to 7.3
the requestor
Specification of the role the user
RoleIDCode U
plays when performing the event
Code for the purpose of use of the
PurposeOfUse U
data accessed
NetworkAccessPointTypeCode U Type of network access point
Refer to 7.4
NetworkAccessPointID U ID for network access point
Audit system AuditEnterpriseSiteID U Site ID of audit enterprise
related
AuditSourceID M Unique ID of audit source Refer to 7.5
(1)
AuditSourceTypeCode U Type code of audit source
8 © ISO 2013 – All rights reserved
Table 3 (continued)
Type Field name Option Description Additional info.
Participant Code for the participant object
ParticipantObjectTypeCode M
object related type
(0.N) ParticipantObjectTypeCodeRole M Object type code of role
Identifier for the data life-cycle
ParticipantObjectDataLifeCycle U
stage for the participant object
ParticipantObjectIDTypeCode M Type code of Participant Object ID
Permission PolicySet for Partici-
ParticipantObjectPolicySet U
pantObjectID
Refer to 7.6
Sensitivity defined by the policy
ParticipantObjectSensitivity U
for ParticipantObjectID
Identifies a specific instance of the
ParticipantObjectID M
participant object
Object name of participant, such
ParticipantObjectName U
as a person’s name
Contents of query for the partici-
ParticipantObjectQuery M/U
pant object
ParticipantObjectDetail U Detail of participant object
Multiplicity: Optionality:
(1) M Mandatory
(0.1) 0 or 1 exists, MC Conditional Mandatory
(1.2) 1 or 2 exist(s) U Optional
(0.N) 0 to N exist(s) 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] [1] [11]
NOTE The coding is modelled after IHE ITI TF-1 and TF-2 and ISO 12052, DICOM supplement 95 .
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-defined
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/View/Print/Query Display or print data, such as a diagnosis
U Update Update data, such as Revise Personal Health Information
D Delete Make items unaccessible
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 themselves. Auditing need not always make as fine a distinction.
NOTE 3 Compound actions, such as “Move,” “Archive” or “Copy”, would be audited 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 in ISO 8601:2004 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.
NOTE In a distributed system, some sort of common time base, e.g. an NTP [RFC1305] server, is a good
implementation tactic.
7.2.4 Event outcome indicator
Description: Indicates whether the event succeeded or failed
Optionality: Optional
10 © ISO 2013 – All rights reserved
Format/Values: Coded value. A code zero (0) indicates success. Values for failure of an event are not
meaningful within the scope of this International Standard.
[13]
Rationale: This field is specified to conserve compatibility with audit trails as defined in IETF 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 implementation-defined codes or references to standards, the XML schema
in RFC3881 defines the optional attributes as shown in Table 6.
Table 6 — Event type code reference attributes
Attribute Value
CodeSystem OID reference
CodeSystemName Name of the coding system; strongly recommended to be valued for locally-defined
code-sets
DisplayName The value to be used in displays and reports
OriginalText Input value that was translated to the code
Since events may be categorized in more than one way, there may be multiple values specified.
Rationale: This field enables queries of audit records by implementation-defined event categories.
7.3 User identification
7.3.1 User ID
Description: Unique identifier for the user actively participating in the event
Optionality: Mandatory
Format/Values: User identifier text string from the authentication system. It is a unique value within
the Audit Source ID (see 7.4).
Rationale: This field ties an audit event to a specific user. In this context, a user may be a person, group,
team, server, process, or task thread.
NOTE 1 For cross-system audits, especially with long retention, this user identifier is meant to permanently
tie an audit event to a specific user via a unique key that retains its uniqueness over the entire lifetime of the
archiving of the audit trail.
NOTE 2 For node-based authentication – where only the system hardware or process, but not a human user, is
identified – User ID would be the node name.
NOTE 3 If the audit trail is to be used for clinical audit, or to provide evidence, where needed, of misuse, the audit
trail might need to record sufficient information to unambiguously associate a unique identifier with an actual user.
7.3.2 Alternative user ID
Description: Alternative unique identifier for the user
Optionality: Optional
Format/Values: User identifier text string from authentication system. This identifier would be one
known to a common authentication system, if available.
Rationale: In some situations a user may authenticate with one identity but, to access a specific
application system, may use a synonymous identify. The alternative identifier would then be the original
identify used for authentication, and the User ID is the one known to and used by the application.
7.3.3 User name
Description: The human-meaningful name for the user
Optionality: Optional
Format/Values: Text string
Rationale: The User ID and Alternative User ID may be internal or otherwise obscure values. This field
assists the auditor in identifying the actual user.
7.3.4 User is requestor
Description: Indicator that the user is or is not the requestor or initiator, for the event being audited.
Optionality: Optional
Format/Values: Boolean, default/assumed value is “true”
Rationale: This value is used to distinguish between requestor-users and recipient-users. For example,
a report can be retrieved by a user (the requestor). Or a user (the requestor) may initiate a report-output
to be sent to another user (who is the recipient of the report but not the requestor).
7.3.5 Role ID code
Description: Specification of the role(s) the user exercises when performing the event, as assigned in
role-based access control security. Such role-based access control systems map each user to one or more
roles, and each role to one or more system functions.
Optionality: Optional; multi-valued
Format/Values: Coded value, with attribute “code” valued with the role code or text from authorization
system. More than one value may be specified, because more than one role-based access control system
and/or taxonomy may be in use. Note that both ISO 27799:2008, 7.8.2.2 (Privilege management),
[6]
and ISO/TS 22600 specify that the user of a health information system containing personal health
information accesses its services in a single role (i.e. users who have been registered with more than one
role then designates a single role during each health information system access session).
[4]
It is recommended to use a coding system compatible with the functional roles defined in ISO/TS 21298
and listed in Table 7.
The vocabulary identification for this list of coded values can be referenced by the following OID, specified
[7] [8]
using the Abstract Syntax Notation One (ASN.1) defined in ISO/IEC 8824-1 and ISO/IEC 8824-2:
Vocabulary Identification: ISO (1) standard (0) functional and structural roles (21298) functional role
vocabulary (4)
12 © ISO 2013 – All rights reserved
Table 7 — Functional role ID codes
role_identi- role_name Description
fier
01 Subject of care principal data subject of the electronic health record
02 Subject of care agent e.g. parent, guardian, carer or other legal representative
03 Personal healthcare healthcare professional or professionals with the closest relationship
professional to the patient, often the patient’s family doctor
04 Privileged healthcare nominated by the subject of care
professional
OR
nominated by the healthcare facility of care (if there is a nomination
by regulation, practice, etc. such as an emergency over-ride)
05 Healthcare profes- party involved in providing direct healthcare to the patient
sional
06 Health-related profes- party indirectly involved in patient care, teaching, research, etc.
sional
07 Administrator any other parties supporting service provision to the patient
This identifies a high-level list of functional roles to enable interoperable exchanges across jurisdictional
or domain boundaries. This can be applied to manage the creation, access, processing and communication
of health information. More granular functional roles may be asserted within a domain or jurisdiction or
may be agreed upon for communications between such domains or jurisdictions.
The codes may be implementation-defined or reference a standard vocabulary enumeration. For
implementation-defined codes or references to standards, the XML schema in RFC 3881 defines the
optional attributes as shown in Table 8.
Table 8 — Role ID code reference attributes
Attribute Value description
CodeSystem OID reference
CodeSystemName Name of the coding system; strongly recommended to be valued for locally-defined
code-sets
Display Name The value to be used in displays and reports
OriginalText Input value that was translated to the code
Rationale: This value ties an audited event to a user’s role. This role is a key element in policies for
control of access to personal health information
[6] [4]
Additional guidance can be found in ISO/TS 22600 and ISO/TS 21298.
7.3.6 Purpose of use
Description: Indicates the purpose for which the accessed personal health information will be used
Optionality: Optional
Format/Values: Coded value enumeration, either defined by the system implementers or as a reference
to a standard vocabulary.
It is recommended to use a coding system compatible with the scheme for classification of purposes for
[2]
processing of personal health information defined in ISO/TS 14265 and listed in Table 9.
The vocabulary identification for this list of coded values can be referenced by the following OID, specified
[7] [8]
using the Abstract Syntax Notation One (ASN.1) defined in ISO/IEC 8824-1 and ISO/IEC 8824-2:
Vocabulary Identification: iso (1) standard (0) Classification of Purposes for processing personal health
information (14265) Terminology for classifying purposes for processing personal health information (1)
Table 9 — Purpose classification
Code Classification Term Description (Informative)
1 Clinical care provision to To inform persons or processes responsible for providing healthcare
an individual subject of services to the subject of care
care
2 Emergency care provision To inform persons needing t
...
NORME ISO
INTERNATIONALE 27789
Première édition
2013-03-01
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
©
ISO 2013
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2013
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 56 • CH-1211 Geneva 20
Tel. + 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 2013 – Tous droits réservés
Sommaire Page
Avant-propos .iv
0 Introduction .v
1 Domaine d’application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Symboles et abréviations . 5
5 Exigences et usages des données d’expertise . 5
5.1 Exigences éthiques et formelles . 5
5.2 Usages des données d’expertise . 6
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 . 7
7 Détails des enregistrements d’expertise . 8
7.1 Format d’enregistrement général . 8
7.2 Identification de l’événement déclencheur . 9
7.3 Identification de l’utilisateur .12
7.4 Identification de point d’accès.15
7.5 Identification de la source d’expertise .16
7.6 Identification de l’objet participant .18
8 Enregistrements d’expertise des événements individuels .24
8.1 Événements d’accès .24
8.2 Événements de requêtes .25
9 Gestion sécurisée des données d’expertise .27
9.1 Considérations de sécurité .27
9.2 Sécuriser la disponibilité du système d’expertise .27
9.3 Exigences de conservation .27
9.4 Sécuriser la confidentialité et l’intégrité des historiques d’expertise .27
9.5 Accès aux données d’expertise .28
Annexe A (informative) Scénarios d’expertise .29
Annexe B (informative) Services de rapport d’expertise .36
Bibliographie .46
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 (CEI) en ce qui concerne
la normalisation électrotechnique.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives
ISO/CEI, Partie 2.
La tâche principale des comités techniques est d’élaborer les Normes internationales. Les projets de
Normes internationales adoptés par les comités techniques sont soumis aux comités membres pour vote.
Leur publication comme Normes internationales requiert l’approbation de 75 % au moins des comités
membres votants.
L’attention est appelé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.
L’ISO 27789 a été élaborée par le comité technique ISO/TC 215, Informatique de santé.
iv © ISO 2013 – Tous droits réservés
0 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 au respect de
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 entier puisse être entièrement expertisé. 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.
Se reposer sur des dossiers informatisés de santé nécessite des éléments de sécurité physiques et
techniques ainsi que des éléments d’intégrité des données. Les exigences en matière d’expertise et
de contrôle d’accès comptent parmi les plus importantes exigences de sécurité pour la protection des
informations personnelles propres à la santé et l’intégrité des dossiers. Elles permettent de respecter les
obligations envers les sujets de soins confiant leurs informations aux systèmes de dossiers informatisés
de santé (DIS). Elles permettent également de protéger l’intégrité du dossier, car elles incitent fortement
les utilisateurs à se conformer aux politiques organisationnelles appliquées à l’usage de ces systèmes.
Une expertise et un contrôle d’accès efficaces peuvent favoriser la découverte d’abus perpétrés sur des
systèmes de DIS ou des données de DIS et peuvent aider les organisations et les sujets de soins à obtenir
réparation des utilisateurs ayant abusé de leurs privilèges d’accès. Afin que l’expertise soit efficace, il est
nécessaire que les historiques d’expertise contiennent suffisamment d’informations pour permettre le
traitement de situations très diverses (voir Annexe A).
Les rapports d’expertise et les contrôles d’accès sont complémentaires. Les rapports d’expertise
fournissent un moyen d’évaluer la conformité avec les politiques organisationnelles en matière d’accès
et peuvent contribuer à l’amélioration et à l’épuration de la politique en elle-même. Mais étant donné
que ces politiques doivent anticiper les cas imprévus et les cas d’urgence, l’analyse de ces rapports
d’expertise devient dans ces cas-là le meilleur moyen d’assurer le contrôle des accès.
La présente Norme internationale est strictement limitée au contrôle de l’accès aux événements. Les
modifications de valeurs effectuées sur les champs d’un DIS sont supposées être enregistrées dans la
base de données de DIS et non dans le rapport d’expertise. Le système de DIS est supposé contenir les
valeurs de chaque champ, avant et après leur mise à jour. Cela est conforme aux architectures de base de
données actuelles. Le rapport d’expertise en soi n’est supposé contenir aucune information personnelle
autre que les identifiants et les liens visant les dossiers.
Le dossier informatisé de santé propre à un certain individu peut appartenir à plusieurs systèmes
d’informations 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 en particulier, l’existence d’une structure commune est nécessaire. La présente Norme
internationale fournit cette structure. Afin de permettre l’obtention d’historiques d’expertise à
travers divers domaines distincts, il est essentiel d’inclure des références au sein de cette structure se
rapportant aux politiques spécifiant les exigences du domaine, telles que les règles de contrôle d’accès et
les périodes de validité. Les politiques propres au domaine peuvent être référencées implicitement par
l’identification de la source du rapport d’expertise.
0.2 Avantages propres à l’utilisation de la présente Norme internationale
La normalisation des historiques d’expertise concernant l’accès aux dossiers informatisés de santé a
deux objectifs:
— assurer que l’information contenue dans le rapport d’expertise est suffisante pour reconstruire
clairement la chronologie détaillée des événements ayant conduit au contenu d’un dossier
informatisé de santé, et
— assurer que l’historique d’expertise des actions relatives au dossier d’un sujet de soins puisse être
suivi de façon fiable, même si elles sont réparties sur différents domaines organisationnels.
La présente Norme internationale est destinée 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 personnelles de santé, qui sont à la recherche de lignes directrices concernant les
historique d’expertise, ainsi qu’à leurs conseillers en matière de sécurité, consultants, vérificateurs,
vendeurs et prestataires externes de service.
0.3 Comparaison avec les normes relatives aux historiques d’expertise des dossiers
informatisés de santé
La présente Norme internationale est conforme aux exigences de l’ISO 27799:2008, dans la mesure où
elles font référence à l’expertise et à l’historique d’expertise.
[13]
Certains lecteurs peuvent être familiarisés avec le document RFC 3881 [Request For Comment
(demande de commentaires)] de l’Internet Engineering Task Force (IETF). (Les lecteurs n’étant pas
encore familiarisés avec le document RFC 3881 de l’IETF n’ont pas besoin de consulter ce document, car
la méconnaissance de ce dernier ne gênera pas la compréhension de la présente Norme internationale).
Le document RFC 3881 informatif, daté du mois de septembre 2004 et répertorié comme n’étant plus
d’actualité dans la base de données de l’IETF, fut une première tentative utile de spécification du
contenu des rapports d’expertise en matière de santé. Dans la mesure du possible, la présente Norme
internationale est élaborée sur la base du travail débuté dans le document RFC 3881 concernant l’accès
aux DIS et lui est conforme.
0.4 Note concernant la terminologie
Plusieurs termes connexes sont définis dans l’Article 3. Un rapport d’expertise est une séquence
chronologique d’enregistrements d’expertise, chaque enregistrement d’expertise contenant la preuve de
son appartenance directe à l’exécution d’un processus ou d’une fonction du système. Dans la mesure
où les systèmes de DIS peuvent être des agrégations complexes de systèmes et de bases de données,
il peut y avoir plusieurs rapports d’expertise contenant les informations relatives aux événements du
système ayant modifié le dossier informatisé de santé d’un sujet de soins. Même si les termes historique
d’expertise et rapport d’expertise sont souvent utilisés de façon interchangeable, dans la présente Norme
internationale, le terme historique d’expertise fait référence à l’ensemble de tous les enregistrements
d’expertise d’un ou de plusieurs rapports d’expertise faisant référence à un sujet de soins, à un dossier
informatisé de santé ou à un utilisateur particulier. Un système d’expertise fournit toutes les fonctions de
traitement de l’information nécessaires à la mise à jour d’un ou de plusieurs rapports d’expertise.
vi © ISO 2013 – Tous droits réservés
NORME INTERNATIONALE ISO 27789:2013(F)
Informatique de santé — Historique d’expertise des
dossiers de santé informatisés
1 Domaine d’application
La présente Norme internationale spécifie une structure commune pour les historiques d’expertise
des dossiers informatisés de santé (DIS), en termes d’événements déclencheurs d’expertise et de
données d’expertise, afin de conserver l’ensemble des informations personnelles de santé pouvant être
expertisées sur tous les systèmes et domaines d’information.
Elle s’applique aux systèmes de traitement des informations personnelles de santé qui, conformément à
l’ISO 27799, créent un enregistrement d’expertise sûr chaque fois qu’un utilisateur crée des informations
personnelles de santé, qu’il y accède, qu’il les met à jour ou qu’il les archive par le biais du système.
NOTE Au minimum, ces enregistrement d’expertise 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, accès à un
dossier, mise à jour d’un dossier, etc.) et enregistrent la date et l’heure auxquelles la fonction a été exécutée.
La présente Norme internationale ne couvre que les actions effectuées sur le dossier informatisé de santé,
qui sont régies par une politique d’accès propre au domaine dans lequel s’inscrit le dossier informatisé
de santé. Elle ne traite pas des informations personnelles de santé issues de dossier informatisé de santé
mais uniquement des identifiants, l’enregistrement d’expertise ne contenant que les liens menant aux
segments du dossier informatisé de santé, tel qu’établi par la politique d’accès en vigueur.
Elle ne couvre pas non plus la spécification et l’utilisation des rapports d’expertise dans un but de gestion
et de sécurité du système, par exemple pour la détection des problèmes de performance, des failles au
niveau des applications, ou en tant que support pour la reconstruction des données, qui sont traitées par
[9]
les normes de sécurité informatique générales telles que l’ISO/CEI 15408 .
L’Annexe A donne des exemples de scénarios d’expertise. L’Annexe B donne un aperçu des services de
rapport d’expertise.
2 Références normatives
Les documents de référence suivants sont indispensables à l’application 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 8601:2004, Éléments de données et formats d’échange — Échange d’information — Représentation de
la date et de l’heure
ISO 27799:2008, Informatique de santé — Management de la sécurité de l’information relative à la santé en
utilisant l’ISO/CEI 27002
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s’appliquent.
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
à l’activité métier et à la sécurité
[ISO/CEI 27000:2009, définition 2.1]
3.2
politique d’accès
définition des obligations concernant l’autorisation de l’accès à une ressource
3.3
responsabilité
principe selon lequel les personnes physiques et morales, ainsi que la collectivité, sont responsables de
leurs actions et peuvent être tenues d’en rendre compte
[ISO 15489-1:2001, définition 3.2]
3.4
expertise
examen systématique et indépendant des accès, ajouts ou modifications appliqués aux dossiers
informatisés de santé afin de déterminer si les activités ont été effectuées et si les données ont été
recueillies, utilisées, conservées ou divulguées conformément aux normes organisationnelles en
termes de procédures de fonctionnement, de politiques, de bonnes pratiques cliniques et d’exigences
réglementaires applicables
3.5
archive d’expertise
ensemble d’archive d’un ou de plusieurs rapports d’expertise
3.6
données d’expertise
données obtenues à partir d’un ou de plusieurs enregistrements d’expertise
3.7
rapport d’expertise
séquence chronologique des enregistrements d’expertise, chacun contenant les données concernant un
événement spécifique
3.8
enregistrement d’expertise
enregistrement d’un événement unique particulier ayant eu lieu au cours du cycle de vie du dossier
informatisé de santé
3.9
système d’expertise
système de traitement de l’information permettant de mettre à jour un ou plusieurs rapports d’expertise
3.10
historique d’expertise
ensemble d’enregistrements d’expertise, provenant d’un ou de plusieurs rapports d’expertise, relatifs à
un sujet de soins spécifique ou à un dossier informatisé de santé en particulier
3.11
authentification
moyen pour une entité d’assurer la légitimité d’une caractéristique revendiquée
[ISO/CEI 27000:2009, définition 2.5]
3.12
autorisation
attribution de privilèges, comprenant la permission d’accès aux données et fonctions
Note 1 à l’article: Adapté de l’ISO 7498-2: l’attribution de droits, comprenant la permission d’accès sur la base de
droits d’accès.
2 © ISO 2013 – Tous droits réservés
3.13
autorité
entité responsable de l’octroi des certificats
3.14
disponibilité
propriété d’être accessible et utilisable à la demande par une entité autorisée
[ISO/CEI 27000:2009, définition 2.7]
3.15
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
[ISO/CEI 27000:2009, définition 2.9]
3.16
temps universel coordonné
UTC
échelle de temps qui constitue la base d’une diffusion radioélectrique coordonnée des fréquences étalons
et des signaux horaires, qui a la même marche que le temps atomique international, mais qui en diffère
d’un nombre entier de secondes
[CEI 60050-713:1998]
3.17
intégrité des données
propriété assurant que des données n’ont pas été modifiées ou détruites de façon non autorisée
[ISO 7498-2:1989, définition 3.3.21]
3.18
dossier informatisé de santé
DIS
ensemble structuré et complet d’informations cliniques, démographiques, environnementales, sociales et
financières inclues dans un formulaire électronique et concernant les soins de santé procurés à un individu
3.19
segment de DIS
partie d’un DIS constituant une ressource distincte pour la politique d’accès
3.20
identification
exécution de tests permettant à un système informatique de reconnaître des entités
[ISO/CEI 2382-8:1998, définition 08.04.12 (validation d’identité)]
3.21
identifiant
élément d’informations utilisé pour déclarer une identité, avant une éventuelle corroboration, par un
authentifiant correspondant
3.22
sécurité de l’information
protection de la confidentialité, de l’intégrité et de la disponibilité de l’information
[ISO/CEI 27000:2009, définition 2.19]
3.23
intégrité
propriété de protection de l’exactitude et de l’exhaustivité des actifs
[ISO/CEI 27000:2009, définition 2.25]
3.24
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 la présente Norme internationale 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/CEI 8824-1 et dans l’ISO/ CEI 8824-2.
3.25
politique
ensemble d’obligations légales, politiques, organisationnelles, fonctionnelles et techniques destinées à la
communication et à la coopération
[ISO/TS 22600]
3.26
privilège
capacité assignée à une entité par une autorité
3.27
gestion des enregistrements
champ de gestion en charge du contrôle efficace et systématique de la création, de la réception, de la
conservation, de l’utilisation et du sort final des documents, y compris des processus de recueil et de
conservation des preuves et des informations concernant les opérations et les transactions sous forme
d’enregistrements
[ISO 15489-1:2001, définition 3.16]
3.28
rôle
ensemble de compétences et/ou de performances, associé à une tâche
3.29
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.30
politique de sécurité
plan ou programme d’action adopté pour assurer la sécurité informatique
[ISO/CEI 2382-8:1998, définition 08.01.06]
3.31
sujet de soins
personne dont il est prévu qu’elle reçoive, recevant ou ayant reçu des soins de santé
[ISO 18308:2011, définition 3.47]
3.32
utilisateur
personne, dispositif ou programme utilisant un système de DIS pour traiter des données ou échanger
des informations de santé
4 © ISO 2013 – Tous droits réservés
4 Symboles et abréviations
EHR Electronic Health Record (Dossier informatisé de santé, DIS)
HL7 Health Level Seven International (Niveau international de santé sept)
OID Object Identifier (Identifiant d’objet)
UTC Coordinated Universal Time (Temps universel coordonné)
5 Exigences et usages des données d’expertise
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. Limiter l’accès aux dossiers de santé et assurer leur utilisation
appropriée sont deux conditions essentielles en ce qui concerne les soins de santé et sont imposées par
la loi dans de nombreuses juridictions.
Les historiques d’expertise sécurisés concernant les accès aux dossiers informatisés de santé peuvent
appuyer la conformité avec l’éthique professionnelle, les politiques organisationnelles et la législation,
mais ils ne sont pas suffisants en eux-mêmes pour évaluer la totalité d’un dossier informatisé de santé.
5.1.2 Politique d’accès
Une organisation responsable de la mise à jour d’un rapport d’expertise doit identifier la politique d’accès
régissant tous les accès enregistrés.
La politique d’accès doit être conforme à l’ISO 27799:2008, 7.8.1.2.
NOTE 1 La politique d’accès est censée définir la structure d’un segment de DIS.
NOTE 2 Dans l’enregistrement d’expertise, la politique d’accès est identifiée par la source du rapport d’expertise.
5.1.3 Identification sans équivoque des utilisateurs du système informatique
Les historiques d’expertise 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 tout aussi bien être des personnes ou d’autres entités.
Les historiques d’expertise doivent fournir suffisamment de données pour déterminer quel utilisateur
autorisé ou système externe a accédé à ou a reçu des dossiers de santé de la part du système.
5.1.4 Rôles des utilisateurs
L’historique d’expertise doit présenter le rôle de l’utilisateur ayant effectué l’action enregistrée sur les
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 spécifique selon le rôle qui soit en mesure de mettre en correspondance
chaque utilisateur à un ou plusieurs rôles et chaque rôle à une ou plusieurs fonctions du système, comme
recommandé dans l’ISO 27799:2008, 7.8.2.2.
[4]
Les rôles fonctionnels et structurels sont documentés dans l’ISO/TS 21298 . Des lignes directrices
supplémentaires sur la gestion des privilèges dans le domaine de la santé sont données dans
[6]
l’ISO/TS 22600 (toutes les parties) .
5.1.5 Enregistrements d’expertise sécurisés
Des enregistrements d’expertise sécurisés doivent être créés à chaque fois que des informations
personnelles de santé sont consultées, créées, mises à jour ou archivées, conformément à l’ISO 27799:2008,
7.7.10.2. Les enregistrements d’expertise doivent être conservés par le biais d’une gestion sécurisée des
enregistrements.
5.2 Usages des données d’expertise
5.2.1 Gouvernance et supervision
Les historiques d’expertise doivent fournir des données permettant aux autorités responsables d’évaluer
la conformité avec la politique de l’organisation et son efficacité.
Ceci implique
— la détection des accès non autorisés aux dossiers de santé,
— l’évaluation des accès d’urgence,
— la détection d’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é avec la politique organisationnelle peut nécessiter des
données complémetaires qui ne sont pas contenues dans l’enregistrement d’expertise, telles que des informations
relatives à l’utilisateur, des tableaux ou des enregistrements de permission sur une entrée physique dans des
salles sécurisées. Voir Annexe B en ce qui concerne les services de rapport d’expertise.
Les historiques d’expertise 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 historiques d’expertise doivent fournir suffisamment de données pour déterminer tous les accès aux
dossiers 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 historiques d’expertise doivent fournir suffisamment de données pour permettre aux sujets de soins
— d’évaluer quel ou quels utilisateurs ont eu accès à leur dossier de santé et quand,
— d’évaluer la responsabilité concernant le contenu du dossier,
— de déterminer la conformité avec les directives de consentement du sujet de soins concernant l’accès
aux données le concernant ou leur divulgation, 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.
6 © ISO 2013 – Tous droits réservés
5.2.3 Preuve d’action éthique ou légale du prestataire de soins de santé
Les historiques d’expertise doivent fournir des données permettant de fournir aux prestataires de soins
de santé des preuves documentées concernant quelles informations ont été consultées et quelles actions
ont été effectuées (création, consultation, lecture, correction, mise à jour, extraction, exportation,
archivage, etc.) sur ces informations, quand et par qui.
Il convient d’aligner la conservation des enregistrements d’expertise sur les conditions légales de
responsabilité en vigueur au sein de la juridiction.
Voir HL7 EHR Records Management and Evidentiary Support (RM-ES) (Gestion des enregistrements et
preuves venant à l’appui).
6 Événements déclencheurs
6.1 Généralités
Les événements d’expertise (événements déclencheurs) qui sont à l’origine de la génération par le système
d’expertise d’enregistrements d’expertise sont définis conformément à chaque envergure et objectif
des systèmes d’informations de santé et au contenu des politiques de confidentialité et de sécurité.
Le domaine d’application de la présente Norme internationale étant limité à l’accès aux informations
personnelles de santé, seuls les événements déclencheurs relatifs à l’accès y sont spécifiés.
Afin de générer les enregistrements d’expertise qui satisfont aux exigences de l’Article 5, c’est-à-dire
«quand», «qui», «de qui», les deux événements suivants sont obligatoires:
a) les accès aux informations personnelles de santé,
b) les requêtes concernant les informations personnelles de santé.
Des exemples d’événements non couverts sont les suivants:
— démarrage et arrêt de programmes d’application;
— événements d’authentification impliquant l’authentification d’utilisateurs;
— entrée et sortie en provenance/en direction d’un environnement extérieur;
— accès aux informations autres que les informations personnelles de santé;
— alertes de sécurité relatives aux programmes d’application;
— accès au rapport d’expertise contenu dans les programmes d’application;
— événements générés par le système d’exploitation, un logiciel intermédiaire, etc.;
— accès générés par l’utilisation de systèmes utilitaires;
— connexion/déconnexion physique des équipements au réseau;
— démarrage/arrêt des systèmes de protection tels que les systèmes de protection anti-virus;
— mises à jour logicielles impliquant la modification ou la mise à jour 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 la présente Norme internationale, l’accès aux informations personnelles de santé est considéré
comme l’événement d’expertise. Ici «Accès» signifie la création, la lecture, la mise à jour et la suppression
des données. Le rapport d’expertise contient les informations concernant le «quand», «qui» et «de qui»
propres à l’accès vers les données à protéger.
Tableau 1 — Événements d’accès
Événement Contenu
Quand,
Accès aux informations personnelles de santé Qui,
De qui
6.2.2 Requêtes concernant les informations personnelles de santé
La requête au niveau de la base de données de DIS formulée dans le but d’obtenir des informations
personnelles de santé est considérée comme un événement pouvant être expertisé. La requête représente
l’action de requête en elle-même et le référencement aux informations personnelles de santé qui résulte
de la requête est considéré comme un événement d’accès. L’enregistrement d’expertise contient les
informations concernant la requête «quand», «qui» et «quelles conditions de requête», voir Tableau 2.
Tableau 2 — Requêtes
Événement Contenu
Quand,
Requêtes concernant les informations person-
Qui,
nelles de santé
Quelles conditions de requête
7 Détails des enregistrements d’expertise
7.1 Format d’enregistrement général
Le Tableau 3 décrit le format général des enregistrements d’expertise. Pour le contenu de chaque
[13]
événement, voir Article 8. Le format d’enregistrement est défini d’après le document RFC3881 et
[11]
le document DICOM , avec ajout des champs facultatifs PurposeOfUse et ParticipantObjectPolicySet.
8 © ISO 2013 – Tous droits réservés
Tableau 3 — Format général des enregistrements d’expertise
Néces- Info. supplé-
Type Nom du champ Description
sité mentaire
Relatif à EventID O ID de l’événement d’expertise
l’événe-
Type de l’opération effectuée lors
EventActionCode O
ment
de l’événement d’expertise
(1)
Date/heure à laquelle s’est pro- Voir 7.2
EventDateTime O
duit l’événement
EventOutcomeIndicator F Succès ou échec de l’événement
EventTypeCode F Catégorie de l’événement
Relatif à ID de la personne ou du proces-
UserID O
l’utilisa- sus
teur
Autre ID pour
AlternateUserID F
(1.2)
l’utilisateur ou le processus
Nom d’utilisateur ou de proces-
UserName F
sus
Voir 7.3
Indicateur précisant si l’utilisa-
UserIsRequestor F
teur est le demandeur ou non
Spécification du rôle que l’utilisa-
RoleIDCode F
teur possède lors de l’événement
Code stipulant l’objectif de l’utili-
PurposeOfUse F
sation des données consultées
NetworkAccessPointType- Type de
F
Code point d’accès réseau
Voir 7.4
ID du point
NetworkAccessPointID F
d’accès réseau
Relatif au ID du site
AuditEnterpriseSiteID F
système au sein de l’organisme expertisé
d’expertise
ID unique
AuditSourceID O Voir 7.5
(1)
de la source d’expertise
Code de type de la source
AuditSourceTypeCode F
d’expertise
7.2 Identification de l’événement déclencheur
7.2.1 ID de l’événement
Description: Identifiant unique propre à un événement expertisé particulier, par exemple un élément
de menu, un programme, une règle, une politique, un code de fonction, un nom d’application ou une
adresse URL. Il permet l’identification de la fonction effectuée.
Nécessité: Obligatoire
Format/Valeurs: Valeur codée, définie soit par les implémenteurs du système, soit par référence à un
vocabulaire standard. L’attribut «code» doit être sans équivoque et unique, au moins au sein de l’ID
de la source d’expertise (voir 7.5). Exemples d’identifiants d’événements: nom de programme, nom de
méthode ou nom de fonction.
[12] [1]
NOTE Le codage est modélisé selon l’IHE ITI TF-1 et TF-2 et l’ISO 12052 , supplément DICOM 95.
Pour les valeurs codées définies par l’implémentation ou les références à des normes, le schéma XML de
RFC 3881 définit les attributs facultatifs donnés dans le Tableau 4.
Tableau 4 — Attributs de référence d’identifiant d’événement
Attribut Valeur
CodeSystem Référence OID
CodeSystemName Nom du système de codage, fortement recommandé pour les ensembles de
codes définis au niveau local.
CodeValue Le code spécifique au sein du système de codage
DisplayName La valeur à utiliser à l’affichage et dans les rapports
OriginalText Valeur d’entrée traduite vers le code
Afin de satisfaire à l’exigence d’identification d’événement sans équivoque, il est impossible de spécifier
plusieurs valeurs.
Justificatif: Ceci identifie la fonction expertisée. Pour les enregistrements d’expertise dont le code
d’action de l’événement est «Exécuter», cela identifie la fonction d’application effectuée.
Au moins un CodeSystem (OID) ou CodeSystemName est obligatoire.
7.2.2 Code d’action de l’événement
Description: Identifiant du type de l’action effectuée lors de l’événement.
Nécessité: Obligatoire
Format/Valeurs: Énumération telle que donnée dans le Tableau 5.
Tableau 5 — Codes d’action de l’événement
Valeur Signification Exemples
C Créer Créer un nouvel objet de base de données, tel que
Passer une Commande
R Lire/Consulter/Imprimer/Deman- Afficher ou imprimer des données, par exemple un
der diagnostic
U Mettre à jour Mettre à jour des données, telle que la révision des
informations personnelles de santé
D Supprimer Rendre des éléments inaccessibles
E Exécuter Effectuer une fonction de système ou d’application
telle qu’une recherche, une extraction ou l’utilisation
de la méthode d’un objet
Justificatif: Ceci indique d’une façon générale quel genre d’action a été effectué sur l’objet participant.
NOTE 1 Les opérations qui ne sont pas énumérées ci-dessus sont considérées comme étant de type «Exécuter»
pour une fonction spécifique ou une méthode d’interface d’objet ou comme traitant deux événements distincts ou
plus. Une action d’application, telle que l’autorisation ou la signature numérique, est une fonction «Exécuter» et
l’ID de l’événement identifierait la fonction.
NOTE 2 Pour certaines applications, telles que l’imagerie radiologique, une action de requête ne peut que
déterminer la présence de données sans pouvoir accéder aux données elles-mêmes. Il n’est pas nécessaire que
l’expertise établisse de distinctions précises.
10 © ISO 2013 – Tous droits réservés
NOTE 3 Les actions composées, telles que «Déplacer», «Archiver» ou «Copier», seraient expertisées en créant
des données d’expertise pour chaque opération - lire, créer, supprimer - ou en les considérant comme une action
«Exécuter» d’une fonction ou d’une méthode.
7.2.3 Date et heure de l’événement
Description: la date et l’heure exprimées sans ambiguïté quel que soit le fuseau horaire.
Nécessité: Obligatoire
Format/Valeurs: Représentation de la date et de l’heure exprimées sans équivoque en temps universel
coordonné (UTC). L’heure doit être exprimée au format UTC conformément à l’ISO 8601:2004et doit
respecter une limite de tolérance de 250 ms UTC au maximum.
Justificatif: Ceci lie un événement à une date et à une heure spécifiques. Les expertises de sécurité
nécessitent en général une base de temps cohérente, afin d’éliminer tout problème de fuseau horaire
pouvant survenir en raison de l’emplacement géographique.
NOTE Dans un système réparti, un certain type de base de temps commune, par exemple un serveur NTP
[RFC1305], est une bonne tactique d’implémentation.
7.2.4 Indicateur de résultat d’événement
Description: Indique si l’évément a réussi ou a échoué.
Nécessité: Facultatif
Format/Valeurs: Valeur codée. Le code zéro (0) indique un succès. Les valeurs d’échec d’un événement
ne sont pas significatives dans le cadre du domaine d’application de la présente Norme internationale.
Justificatif: Ce champ est spécifié pour conserver un compatibilité avec les historiques d’expertise
[13]
définis dans le document IETF RFC 3881 .
7.2.5 Code du type de l’événement
Description: Identifiant de la catégorie de l’événement.
Nécessité: Facultatif
Format/Valeurs: Énumération de valeur codée, définie soit par les implémenteurs du système, soit par
référence à un vocabulaire standard. Pour les valeurs codées définies par l’implémentation ou les références
aux normes, le schéma XML de RFC 3881 définit les attributs facultatifs donnés dans le Tableau 6.
Tableau 6 — Attributs de référence de code de type de l’événement
Attribut Valeur
CodeSystem Référence OID
CodeSystemName Nom du système de codage, fortement recommandé pour les ensembles de
codes définis au niveau local
DisplayName La valeur à utiliser à l’affichage et dans les rapports
OriginalText Valeur d’entrée traduite vers le code
Dans la mesure où les événements peuvent être catégorisés de plusieurs façons, il peut y avoir plusieurs
valeurs spécifiées.
Justificatif: Ce champ permet les requêtes d’enregistrements d’expertise par catégorie d’événement
définie par l’implémentation.
7.3 Identification de l’utilisateur
7.3.1 ID d’utilisateur
Description: Identifiant unique de l’utilisateur participant activement à l’événement.
Nécessité: Obligatoire
Format/Valeurs: Chaîne de caractères fournie par le système d’authentification. Il s’agit d’une valeur
unique au sein de l’ID de la source d’expertise (voir 7.4).
Justificatif: Ce champ lie un événement d’expertise à un utilisateur spécifique. Dans ce contexte, un
utilisateur peut être une personne, un groupe, une équipe, un serveur, un processus ou une tâche.
NOTE 1 Pour les expertises sur plusieurs systèmes, en particulier pour une longue conservation des
informations, cet identifiant d’utilisateur est censé lier de façon permanente un événement d’expertise à un
utilisateur spécifique via une clé unique qui conserve son unicité tout au long de la durée de vie de l’archivage de
l’historique d’expertise.
NOTE 2 Pour l’authentification fondée sur un nœud – où seul le système matériel ou un processus, mais pas un
utilisateur humain, est identifié – L’identifiant de l’utilisateur correspondrait au nom du nœud.
NOTE 3 Si l’historique d’expertise doit être utilisé pour une expertise clinique ou afin de fournir une preuve
d’abus, lorsque cela est nécessaire, il peut devoir enregistrer suffisamment d’informations pour pouvoir associer
sans équivoque un identifiant unique à un utilisateur réel.
7.3.2 Autre ID d’utilisateur
Description: Autre identifiant unique de l’utilisateur
Nécessité: Facultatif
Format/Valeurs: Chaîne de caractères fournie par le système d’authentification. Cet identifiant serait
celui connu par le système d’authentification commun, si disponible.
Justificatif: Dans certaines situations, un utilisateur peut s’authentifier avec une identité mais, pour
accéder à un système d’application spécifique, peut utiliser une identité synonyme. L’autre identifiant
deviendrait alors l’identité d’origine utilisée pour l’authentification et l’ID d’utilisateur celui connu et
utilisé par l’application.
7.3.3 Nom d’utilisateur
Description: Patronyme de l’utilisateur
Nécessité: Facultatif
Format/Valeurs: Chaîne de caractères
Justificatif: L’ID d’utilisateur et l’autre ID d’utilisateur peuvent être des valeurs internes ou alors des
valeurs cryptées. Ce champ permet au vérificateur d’identifier l’utilisateur réel.
7.3.4 L’utilisateur est demandeur
Description: Indicateur permettant de savoir si l’utilisateur est ou non le demandeur ou l’initiateur de
l’événement d’expertise.
Nécessité: Facultatif
Format/Valeurs: Booléen, valeu
...
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...