ISO/TS 13606-4:2009
(Main)Health informatics — Electronic health record communication — Part 4: Security
Health informatics — Electronic health record communication — Part 4: Security
ISO/TS 13606-4:2009 describes a methodology for specifying the privileges necessary to access EHR data. This methodology forms part of the overall EHR communications architecture defined in ISO 13606‑1. ISO/TS 13606-4:2009 seeks to address those requirements uniquely pertaining to EHR communications and to represent and communicate EHR-specific information that will inform an access decision. It also refers to general security requirements that apply to EHR communications and points at technical solutions and standards that specify details on services meeting these security needs.
Informatique de santé — Communication du dossier de santé informatisé — Partie 4: Sécurité
General Information
Relations
Standards Content (Sample)
TECHNICAL ISO/TS
SPECIFICATION 13606-4
First edition
2009-10-01
Health informatics — Electronic health
record communication —
Part 4:
Security
Informatique de santé — Communication du dossier de santé
informatisé —
Partie 4: Sécurité
Reference number
ISO/TS 13606-4:2009(E)
©
ISO 2009
---------------------- Page: 1 ----------------------
ISO/TS 13606-4:2009(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
COPYRIGHT PROTECTED DOCUMENT
© ISO 2009
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing 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 2009 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/TS 13606-4:2009(E)
Contents Page
Foreword. iv
0 Introduction . v
0.1 Challenge addressed by this part of ISO 13606 . v
0.2 Communication scenarios. vii
0.3 Requirements and technical approach. x
0.4 Generic EHR access policy model. xiii
0.5 Audit log interoperability . xviii
0.6 Relationship to ENV 13606-3 . xix
1 Scope . 1
2 Conformance. 1
3 Terms and definitions. 2
4 Abbreviations . 4
5 Record component sensitivity and functional roles . 4
5.1 RECORD_COMPONENT sensitivity .4
5.2 Functional roles . 5
5.3 Mapping of functional role to RECORD_COMPONENT sensitivity . 5
6 Representing access policy information within an EHR_EXTRACT . 6
6.1 General. 6
6.2 Archetype of the Access policy COMPOSITION. 8
6.3 ADL representation of the archetype of the access policy COMPOSITION . 10
6.4 UML representation of the archetype of the access policy COMPOSITION. 15
7 Representation of audit log information —EHR_AUDIT_LOG_EXTRACT model . 17
Annex A (informative) Illustrative access control example . 19
Annex B (informative) Relationship of this part of ISO 13606 to ENV 13606-3:2000. 23
Bibliography . 29
© ISO 2009 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/TS 13606-4:2009(E)
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.
In other circumstances, particularly when there is an urgent market requirement for such documents, a
technical committee may decide to publish other types of document:
⎯ an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical experts in
an ISO working group and is accepted for publication if it is approved by more than 50 % of the members
of the parent committee casting a vote;
⎯ an ISO Technical Specification (ISO/TS) represents an agreement between the members of a technical
committee and is accepted for publication if it is approved by 2/3 of the members of the committee casting
a vote.
An ISO/PAS or ISO/TS is reviewed after three years in order to decide whether it will be confirmed for a
further three years, revised to become an International Standard, or withdrawn. If the ISO/PAS or ISO/TS is
confirmed, it is reviewed again after a further three years, at which time it must either be transformed into an
International Standard or be withdrawn.
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/TS 13606-4 was prepared by Technical Committee ISO/TC 215, Health informatics.
ISO 13606 consists of the following parts, under the general title Health informatics — Electronic health record
communication:
⎯ Part 1: Reference model
⎯ Part 2: Archetype interchange specification
⎯ Part 3: Reference archetypes and term lists
⎯ Part 4: Security [Technical Specification]
⎯ Part 5: Interface specification
iv © ISO 2009 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/TS 13606-4:2009(E)
0 Introduction
0.1 Challenge addressed by this part of ISO 13606
The communication of electronic health records (EHRs) in whole or in part, within and across organizational
boundaries, and sometimes across national borders, is challenging from a security perspective. Health
records should be created, processed and managed in ways that guarantee the confidentiality of their
contents and legitimate control by patients in how they are used. Around the globe these principles are
progressively becoming enshrined in national data protection legislation. These instruments declare that the
subject of care has the right to play a pivotal role in decisions on the content and distribution of his or her
electronic health record, as well as rights to be informed of its contents. The communication of health record
information to third parties should take place only with patient consent (which may be any freely given specific
and informed indication of his or her wishes by which the data subject signifies his or her agreement to
personal data relating to him or her being processed). For EHR communication across national borders
ISO 22857 provides guidance that may be used to define appropriate security policy specifications.
Ideally, each fine grained entry in a patient's record should only be accessed by those persons who have a
right to view that information, specified by or approved by the patient and reflecting the dynamic nature of the
set of persons with legitimate duty of care towards the patient through his or her lifetime. The access control
list will ideally also include those persons who have a right to access the data for reasons other than a duty of
care (such as health service management, epidemiology and public health, consented research) but exclude
any information that they do not need to see or which the patient feels is too personal for them to access. On
the opposite side, the labelling by patients or their representatives of information as personal or private should
ideally not hamper those who legitimately need to see the information in an emergency, nor accidentally result
in genuine healthcare providers having such a filtered perspective that they are misled into managing the
1)
patient inappropriately. Patients' views on the inherent sensitivity of entries in their health record may evolve
over time, as their personal health anxieties alter or as societal attitudes to health problems change. Patients
might wish to offer some heterogeneous levels of access to family, friends, carers and members of their
community. Families may wish to provide a means by which they are able to access parts of each other's
records (but not necessarily to equal extents) in order to monitor the progress of inherited conditions within a
family tree.
Such a set of requirements is arguably more extensive than that required of the data controllers in most other
industry sectors. It is in practice made extremely complex by:
⎯ numbers of health record entries made on a patient during the course of modern healthcare;
⎯ numbers of healthcare personnel, often rotating through posts, who might potentially come into
contact with a patient at any one time;
⎯ numbers of organizations with which a patient might come into contact during his or her lifetime;
⎯ difficulty (for a patient or for anyone else) of classifying, in a standardized way, how sensitive a
record entry might be;
⎯ difficulty of determining how important a single health record entry might be to the future care of a
patient and to which classes of user;
1) The term “sensitivity” is widely used in the security domain for a broad range of safeguards and controls, but in this
part of ISO 13606 the term refers only to access controls.
© ISO 2009 – All rights reserved v
---------------------- Page: 5 ----------------------
ISO/TS 13606-4:2009(E)
⎯ logically indelible nature of the EHR and the need for revisions to access permissions to be
rigorously managed in the same way as revisions to the EHR entries themselves;
⎯ need to determine appropriate access very rapidly, in real time, and potentially in a distributed
computing environment;
⎯ high level of concern expressed by a growing minority of patients to have their consent for disclosure
recorded and respected;
⎯ low level of concern the majority of patients have about these requirements, which has historically
limited the priority and investment committed to tackling this aspect of EHR communications.
To support interoperable EHRs, and seamless communication of EHR data between healthcare providers, the
negotiation required to determine if a given requester for EHR data should be permitted to receive the data
needs to be capable of automation. If this were not possible, the delays and workload of managing human
decisions for all or most record communications would obviate any value in striving for data interoperability.
The main principles of the approach to standards development in the area of EHR communications access
control are to match the characteristics and parameters of a request to the EHR provider's policies, and to any
access control or consent declarations within the specified EHR, to maintain appropriate evidence of the
disclosure, and to make this capable of automated processing.
In practice, efforts are in progress to develop International Standards for defining access control and privilege
management systems that would be capable of computer-to-computer negotiation. However, this kind of work
is predicated upon health services agreeing a mutually consistent framework for defining the privileges they
wish to assign to staff, and the spectrum of sensitivity they offer for patients to define within their EHRs.
This requires consistency in the way the relevant information is expressed, to make this sensibly scalable at
definition-time (when new EHR entries are being added), at run-time (when a whole EHR is being retrieved or
queried) and durable over a patient's lifetime. It is also important to recognise that, for the foreseeable future,
diversity will continue to exist between countries on the specific approaches to securing EHR communications,
including differing legislation, and that a highly prescriptive approach to standardization is not currently
possible.
This part of ISO 13606 therefore does not prescribe the access rules themselves (i.e. it does not specify who
should have access to what and by means of which security mechanisms); these need to be determined by
user communities, national guidelines and legislation. However it does define a basic framework that can be
used as a minimum specification of EHR access policy, and a richer generic representation for the
communication of more fine-grained detailed policy information. This framework complements the overall
architecture defined in ISO 13606-1, and defines specific information structures that are to be communicated
as part of an EHR_EXTRACT defined in ISO 13606-1.
The formalisms used to represent policy specifications in this part of ISO 13606 include Unified Modelling
Language (UML: please see http://www.omg.org/technology/documents/formal/uml.htm for more information)
and Archetype Definition Language (ADL: please see http://www.openehr.org/120-OE.html for more
information).
Some of the kinds of agreement necessary for the security of EHR communication are inevitably outside the
scope of this part of ISO 13606. The complete protection of EHR communication requires attention to a large
number of issues, many of which are not specific to health information.
NOTE This document is based on EN 13606-4:2007. The content of this part of ISO 13606 is identical to that of
EN 13606-4 with the following exceptions:
⎯ the wording of this Introduction has been revised to reflect its international rather than European jurisdiction;
⎯ references to a security standard in development have been updated if that standard has now been published;
⎯ relationships to new security standards in development have been added where appropriate;
⎯ the first entry in Table 2 (sensitivity level classification) has been changed from “personal care” to “personal”;
⎯ a small number of typographic errors and ambiguous expressions within this introduction have been corrected.
vi © ISO 2009 – All rights reserved
---------------------- Page: 6 ----------------------
ISO/TS 13606-4:2009(E)
0.2 Communication scenarios
0.2.1 Data flows
The interfaces and message models required to support EHR communication are the subject of ISO 13606-5.
The description here is an overview of the communications process in order to show the interactions for which
security features are needed. Figure 1 illustrates the key data flows and scenarios that need to be considered
by this part of ISO 13606. For each key data flow there will be an acknowledgement response, and optionally
a rejection may be returned instead of the requested data.
Audit
EHR
EHR EHR
log
provider
server
requester
Request EHR_EXTRACT
Create audit log entry
Acknowledge request
Make access decision,
EHR
filter EHR if necessary
recipient
Provide EHR_EXTRACT
Deny EHR_EXTRACT
Acknowledge data/denial
Create audit log entry
Audit log
reviewer
Request audit log view
Create audit log entry
Extract audit log, filter if necessary
Provide audit log view
Deny audit log view
Acknowledge data/denial
Create audit log entry
Figure 1 — Principal data flows and security-related business processes
covered by this part of ISO 13606
The EHR requester, EHR recipient and audit log reviewer might be healthcare professionals, the patient, a
legal representative or another party with sufficient authorization to access healthcare information. Both the
EHR_EXTRACT and the audit log, if provided, may need to be filtered to limit the disclosure to match the
privileges of the recipient. This aspect of access control is discussed later in this Introduction.
NOTE all parties shown here will need to maintain an audit log, not just the EHR provider. However, for readability
the other audit log processes are not shown or described here.
© ISO 2009 – All rights reserved vii
---------------------- Page: 7 ----------------------
ISO/TS 13606-4:2009(E)
0.2.2 Request EHR data
This interaction is not always required (for example, EHR data might be pushed from provider to recipient as
in the case of a discharge summary). The request interface needs to include a sufficient profile of the
requester to enable the EHR provider to be in a position to make an access decision, to populate an audit log,
and provide the appropriate data to the intended recipient. In some cases the EHR requester might not be the
same party as the EHR recipient – for example a software agent might trigger a notification containing EHR
data to be sent to a healthcare professional. In such cases it is the EHR recipient's credentials that will
principally determine the access decision to be made.
An EHR request may need to include or reference consents for access and mandates for care, e.g. by
providing some form of explicit consent from the patient, or a care mandate.
The negotiation between requester and provider of EHR data will increasingly be automated, and the
information included in this interaction is required to be sufficient to enable a fully computerized policy
negotiation.
The requirements for this interaction will be reflected in the EHR_Request interface model defined in
ISO 13606-5.
0.2.3 Generate EHR access log entry
This is assumed practice in any EHR system, but it is not specified as a normative interface because of the
diverse approaches and capabilities in present-day systems. The internal audit systems within any EHR
system are not required to be interoperable except in support of the model defined in Clause 7 and the
corresponding interface defined in ISO 13606-5.
0.2.4 Acknowledge receipt of EHR_Request
No healthcare-specific security considerations.
0.2.5 Make access decision, filter EHR data
When processing the EHR request, policies pertaining to the EHR provider and access policies in the EHR
itself all need to be taken into account in determining what data are extracted from the target EHR. This part of
ISO 13606 cannot dictate the overall set of policies that might influence the EHR provider, potentially deriving
from national, regional, organization-specific, professional and other legislation.
A decision to filter the EHR data on the basis of its sensitivity and the privileges of the EHR requester and
recipient will need to conform to relevant policies and may need to balance the clinical risks of denying access
to information with the medico-legal risks of releasing information.
This part of ISO 13606 however does define an overall framework for representing, in an interoperable way,
the access policies that might relate to any particular EHR, authored by the patient or representatives. These
might not be stored in the physical EHR system in this way; they might instead, for example, be integrated
within a policy server linked to the EHR server.
This access decision is discussed in more detail in Clause 5.
0.2.6 Deny EHR_EXTRACT
If the access decision is to decline, a coarse-grained set of reasons needs to be defined in order to frame a
suitable set of responses from the EHR provider. However, it is important that the denial and any reason given
does not imply to the recipient that the requested EHR data does exist – even the disclosure of its existence
could itself be damaging to a patient.
No healthcare-specific security considerations; the interface model is defined in ISO 13606-5.
viii © ISO 2009 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/TS 13606-4:2009(E)
0.2.7 Provide EHR_EXTRACT
Note that the EHR recipient need not be the same as an EHR requester, and indeed the provision of an EHR
need not have been triggered by a request. It might instead have been initiated by the provider as part of a
shared care pathway or to add new data to an existing EHR.
The EHR_EXTRACT is required to conform to the reference model defined in ISO 13606-1, and to the
interface model defined in ISO 13606-5.
The EHR_EXTRACT is required to include or to reference any relevant access policies, represented in
conformance with this part of ISO 13606, to govern any onward propagation of the EHR data being
communicated. Policies may only be referenced if the EHR recipient is known to have direct access to the
same information by another means.
0.2.8 Acknowledge receipt of EHR_EXTRACT
No healthcare-specific security considerations.
0.2.9 Generate EHR access log entry
(As 0.2.3)
0.2.10 Request EHR access log view
This is now considered to be desirable practice, to enable a patient to discover who has accessed part or all of
his/her EHR in a distributed computing environment. The scope of this interface, as defined in this part of
ISO 13606, is to request a view of the audit log that informs the recipient about who has accessed what parts
of a given EHR and when. This interface is not intended to support situations where a full inspection of an
audit log is required for legal purposes or for other investigations. This interface is discussed in Clause 5.
The interface model is defined in ISO 13606-5.
0.2.11 Generate EHR access log entry
(As 0.2.3)
0.2.12 Provide EHR access log view
This is desirable practice, and requires an interoperable representation of such an entry (or set of entries).
This interface is discussed in Clause 5.
Although a legal investigation will require that an audit log is provided in a complete and unmodified form, the
presentation of an audit log view to a patient or to a healthcare professional might require that some entries
are filtered out (e.g. those referring to EHR data to which the patient does not have access).
The interface model is defined in ISO 13606-5.
0.2.13 Deny EHR access log view
If the request is not to be met, a coarse-grained set of reasons needs to be defined. However, it is important
that the denial and any reason given does not imply to the recipient that the requested EHR data does exist –
even the disclosure of its existence could itself be damaging to a patient.
No healthcare-specific security considerations; the interface model is defined in ISO 13606-5.
© ISO 2009 – All rights reserved ix
---------------------- Page: 9 ----------------------
ISO/TS 13606-4:2009(E)
0.2.14 Acknowledge receipt of EHR access log view
No healthcare-specific security considerations.
0.2.15 Generate EHR access log entry
(As 0.2.3)
0.3 Requirements and technical approach
0.3.1 Research on the requirements
The vision of research, industry and previous standards on interoperable electronic health record
communication has been to enable diverse clinical systems to exchange whole or parts of a patent's EHR in a
standardized way that can rigorously and generically represent the data values, contextual organization and
medico-legal provenance of the information in any originating EHR system. Sensitive information, such as that
in EHR systems, has to be recorded, stored, processed and communicated in a secure, safe, and trustworthy
way. EHR communication has therefore also to meet security requirements such as:
⎯ authentication of entities (people, software, devices etc.) that might legitimately require or provide
EHR data;
⎯ authorization, privilege and access control management;
⎯ integrity of the EHR information that is stored, processed and communicated;
⎯ security classification of EHR information;
⎯ definition, negotiation and bridging of policies between the entities requiring and providing EHR data;
⎯ auditability and traceability of information accessed, processed and communicated;
⎯ overall safety and quality procedures.
The research and development (R&D) background work in these fields includes European projects such as
SEISMED, TrustHealth and HARP.
Most healthcare organization information systems already have security systems and services in place to
protect a wide range of health related data flows, of which EHR communications is only one example.
Furthermore, the field of health informatics security is actively developing generic approaches to specifying,
implementing, profiling and evaluating ever-enhanced security services. Many of the requirements that pertain
to EHR communications are therefore also applicable to healthcare communications in general.
0.3.2 Generic healthcare security requirements
The most widely accepted requirements for an overall security approach in domains handling sensitive and
personal data are published in ISO/IEC 27002. This specifies the kinds of measure that should be taken to
protect assets such as EHR data, and ways in which such data might safely be communicated as part of a
distributed computing environment. A health specific guide to this general standard has been published in
ISO 27799. This will facilitate the formulation of common security policies across healthcare, and should help
promote the adoption of interoperable security components and services.
For EHR communication across national borders ISO 22857 provides guidance that may be used to define
appropriate security policy specifications.
x © ISO 2009 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/TS 13606-4:2009(E)
The exact security requirements that are required to be met to permit any particular EHR communication
instance will be governed by a number of national and local policies at both the sending and receiving sites,
and at any intermediate links in the communications chain. Many of these policies will apply to healthcare
communications in general, and will vary between countries and clinical settings in ways that cannot and
should not be directed by this part of ISO 13606.
For example, any access to EHR data will require that the requesting party is appropriately authenticated, that
he, she or it is authorized to make the request and that, if met, the nominated recipient of EHR data (who
might not always be the requester) is authorized to receive it. All communications are required to take place
through secured communications channels, and an audit log is required to be kept of all EHR data flows. The
infrastructure to provide for these security services will be generic to many secure domains, not just for
healthcare, and this part of ISO 13606 assumes that these services will be in place and used for every EHR
communication.
The approach taken in drafting this part of ISO 13606 has therefore been to assume that generic security
policies, components and services will contribute to a negotiation phase (the access decision) prior to
sanctioning the communication of an EHR extract and will protect the actual EHR data flows.
This part of ISO 13606 therefore assumes that an overall security policy or set of policies conforming to
ISO 27799 is in place at all of the sites participating in an EHR communication, and also that these policies
conform to national or trans-border data protection legislation. Additional policies may be required to conform
to specific national, local, professional or organization regulations applicable to the communication or use of
EHR data. Defining such policies is beyond the scope of this part of ISO 13606.
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.