EN 13606-4:2007

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Health Informatics - Electronic health record communication - Part 4: SecuritySRGURþMXInformatique de la santé - Communication des dossiers informatisés de santé - Partie 4 : SécuritéMedizinische Informatik - Kommunikation von Patientendaten in elektronischer Form - Teil 4: SicherheitTa slovenski standard je istoveten z:EN 13606-4:2007SIST EN 13606-4:2008en35.240.80ICS:SIST ENV 13606-4:20031DGRPHãþDSLOVENSKI
STANDARDSIST EN 13606-4:200801-maj-2008

EUROPEAN STANDARDNORME EUROPÉENNEEUROPÄISCHE NORMEN 13606-4March 2007ICS 35.240.80Supersedes ENV 13606-4:2000
English VersionHealth informatics - Electronic health record communication -Part 4: SecurityInformatique de santé - Dossiers de santé informatiséscommunicants - Partie 4 : Exigences de sécurité et règlesde distributionMedizinische Informatik - Kommunikation vonPatientendaten in elektronischer Form - Teil 4: SicherheitThis European Standard was approved by CEN on 10 February 2007.CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this EuropeanStandard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such nationalstandards may be obtained on application to the CEN Management Centre or to any CEN member.This European Standard exists in three official versions (English, French, German). A version in any other language made by translationunder the responsibility of a CEN member into its own language and notified to the CEN Management Centre has the same status as theofficial versions.CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Cyprus, Czech Republic, Denmark, Estonia, Finland,France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal,Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.EUROPEAN COMMITTEE FOR STANDARDIZATIONCOMITÉ EUROPÉEN DE NORMALISATIONEUROPÄISCHES KOMITEE FÜR NORMUNGManagement Centre: rue de Stassart, 36
B-1050 Brussels© 2007 CENAll rights of exploitation in any form and by any means reservedworldwide for CEN national Members.Ref. No. EN 13606-4:2007: E

Illustrative access control example.38 Annex B (informative)
Relationship of this part standard to the Distribution Rules: ENV 13606-3:2000.42 Bibliography.47

Some of the kinds of agreement necessary for the security of EHR communication are inevitably outside the scope of this standard. The complete protection of EHR communication requires attention to a large number of issues, many of which are not specific to health information. CEN/TC 251/WG III has been developing a series of standards related to health care security services and management, which should be applied when building EHR systems. Much of this work is now being done in co-operation between CEN and ISO/TC 215/WG 4 Health informatics/Security. There are a number of ongoing work items that have not been published at the time of writing this draft version of standard but which should become available before this standard is published, and will prove useful for the implementers of EHR systems. Some of these are: • Joint CEN-ISO Work Item: ISO/TS 22600 Privilege Management and Access Control (PMAC), • ISO Work Item: ISO/TS 21298 on Functional and Structural roles.

Figure 1 — Principal data flows and security-related business processes coved by this part-standard 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. 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

The requirements for this interaction will be reflected in the EHR_Request interface model defined in Part 5 of this standard. Acknowledge receipt of EHR_Request
No unique security considerations. 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 standard cannot dictate the overall set of policies that might influence the EHR Provider, potentially deriving from national, regional, organisation-specific, professional and other legislation. This part standard 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 6 of this part standard. 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 unique security considerations – the interface model will be defined in Part 5 of this standard. Provide EHR_EXTRACT
It must be noted that the EHR Recipient need not be the same as an EHR Requester, and indeed the provision of an EHR need not have been triggered by a request. It might instead have been initiated by the provider as part of shared care pathway or to add new data to an existing EHR. The EHR_EXTRACT is required to conform to the Reference Model defined in Part 1 of this standard, and to the interface model defined in Part 5. The EHR_EXTRACT must include or reference any relevant access policies, represented in conformance with this part standard, 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. Acknowledge receipt of EHR_EXTRACT
No unique security considerations.

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 interfaces below. 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 standard, 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 6 of this part standard. The interface model will be defined in Part 5 of this standard. Provide EHR access log view
This is desirable practice, and requires an interoperable representation of such an entry (or set of entries). This interface is discussed in clause 6 of this part standard. 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 will be defined in Part 5 of this standard. 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 unique security considerations – the interface model will be defined in Part 5 of this standard. Acknowledge receipt of EHR access log view No unique security considerations.

Requirements and technical approach The vision of research, industry and previous European 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 European R&D background work in these fields includes 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. 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 17799. This specifies the kinds of measures that should be taken to protect assets such as EHR data, and ways in which such data might safely be communicated as part of a distributed computing environment. A health specific guide to this general standard has been developed by ISO in co-operation with CEN (ISO/DIS 27799) Health informatics – Security management in health using ISO/IEC 17799. This will facilitate the formulation of common security polices across healthcare, and should help promote the adoption of interoperable security components and services.
For EHR communication across borders also to countries outside the European Union, guidance and security policy specifications are found in EN 14484 (Health informatics - International transfer of personal health data covered by the EU data protection directive - High level security policy) and EN 14485 (Health informatics - Guidance for handling personal health data in international applications in the context of the EU data protection directive). ISO 22857 provides similar information when an EU country is not involved. The exact security requirements that must 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 standard.
For example, any access to EHR data will require that the requesting party is appropriately authenticated,

The approach taken in drafting this part standard 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 standard therefore assumes that an overall security policy or set of policies conforming to ISO/IEC 17799 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 satisfying the provisions of EU Directive 94/95. Additional polices 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 standard.

Generic healthcare access control architecture Legitimate access to EHR data will be determined by a wide range of policies, some of which might exist as documents, some will be encoded within applications, and some within formal authorization system components. It is recognized that vendors and organizations differ in how they have implemented access control policies and services, and the extent to which these are presently computerized. The ISO Privilege Management and Access Control (PMAC) standard, ISO/TS 22600, being developed in WG 4 of ISO TC/215, defines a generic logical model for the representation of the privileges of principals (entities), of access control policies that pertain to potential target objects, and of the negotiation process that is required to arrive at an access decision. The standard specifies a generic approach to tasks such as the assignment of roles to entities and the passing of roles between entities. Figure 2 depicts the key concepts of Role Based Access Control, as defined by PMAC.
Figure 2 — Main concepts and policy types defined in Role Based Access Control Principals (persons, agents etc) are mapped to one or more Functional Roles, which will be influenced by the Structural Roles that they are permitted to hold. For example, a person who is medically qualified and a specialist in child health may hold one or more Structural Roles (such as Consultant Paediatrician at a hospital, Head of Child Screening for the region). Those Structural Roles may permit him at times to act with the Functional Role of Personal Clinician to a patient. The Functional Role might be persistent, or limited to a single user session. Functional Roles are mapped to permissions to perform particular operations (such as writing new entries in an EHR) and to particular objects (e.g. the EHR data which that role-holder is permitted to view). For the purposes of this standard, the Target_Component class shown in Figure 2 is the EHR data held by the EHR Provider. The Target_Policy class contains information that defines rules to permit or deny access to part or all of the EHR. If an EHR_EXTRACT is created and communicated with these EHR data, the pertinent Target_Policies need also to be communicated to the EHR Recipient. This requires an interoperable representation of a Target_Policy that can be included within an EHR_EXTRACT. Because individual vendors and organizations may differ in their engineering and technology implementations to achieve this infrastructure, the PMAC standard defines these processes and models at the information and computational viewpoint levels. Its specifications are therefore open, platform-independent, portable, and scalable to support a wide range of clinical settings and use in different countries where national and professional regulations may be different.
This part-standard assumes that the PMAC approach is logically applied to govern access decisions in response to an EHR request. However, it is not in its scope to define the actual policy models, attributes or attribute values that are needed to represent individual policy instances, or the way in which the PMAC logical approach is technically implemented in any organization or region. PrincipalSR_PolicyStructural_RoleRole_Hierarchy1.*1FR_PolicyFunctional_Role0.*0.*0.*0.*User_Assignment1.*1Process_PolicySession1.*0.*1.*0.*User_Session11.*11.*Session_Role1.*1Target_PolicyTarget_Component0.*0.*0.*0.*Permission_Assignment1.*11.*111.*1.*111.*

As a complement to that emerging standard, a new Work Item within ISO proposes to define sets of Structural Roles and Functional Roles that can be used internationally to support policy negotiation and policy bridging (e.g. during the negotiation phase of an access decision). This standard recognizes that these and other standardized vocabularies will increasingly support rich interoperability of access policies, but cannot at this stage mandate the use of any particular controlled vocabulary since none exists in a standardized form. Security requirements specific to EHR Communications A large number of EHR-specific medico-legal and ethical requirements are expressed within ISO/TS 18308, although compliance with these is primarily met through specific classes and attributes of the EHR Reference Model (published in Part 1 of this standard). The following table lists those requirements that apply most specifically to this part standard. Table 1 — List of requirements published in ISO/TS 18308 that relate to the security of EHR communications COC1.2 EHRA shall support consumers’ right of access to all EHR information subject to jurisdictional constraints. COC1.3 EHRA shall support consumers being able to incorporate self-care information, their point of view on personal healthcare issues, levels of satisfaction, expectations and comments they wish to record in EHRs. COM2.4 EHRA shall provide an audit trail of exchange processes, including authentication, to enable identification of points of EHR extract transmittal and receipt. This needs to account for merging processes.
PRS1.2 EHRA shall support the labelling of the whole and/or sections of the EHR as restricted to authorized users and/or purposes. This should include restrictions at the level of reading, writing, amendment, verification, and transmission/disclosure of data and records. PRS1.3 EHRA shall support privacy and confidentiality restrictions at the level of both data sets and discrete data attributes. PRS2.2 EHRA shall support obtaining, recording and tracking the status of informed consent to access the whole and/or sections of the EHR, for defined purposes. PRS2.4 EHRA shall support recording of the time frames attached to each consent. PRS3.1 The EHRA shall support measures to define, attach, modify and remove access rights to the whole and/or sections of the EHR. PRS3.3 EHRA shall support measures to enable and restrict access to the whole and/or sections of the EHR in accordance with prevailing consent and access rules. PRS3.4 EHRA shall support measures to separately control authorities to add to and/or modify the EHR from authorities to access the EHR. PRS5.1 EHRA shall support recording of an audit trail of access to and modifications of data within the whole or sections of the EHR. PRS5.2 EHRA shall support recording of the nature of each access and/or modification. STR2.10 EHRA shall allow for comprehensive information storage and retrieval regarding patient care. The EHRA shall at a minimum allow for the recording of all structured and unstructured data on:
- [others]
- Disclosures and consent
Generic EHR Access Policy model In addressing these requirements within this standard, it is recognized that most clinical and EHR systems deployed today incorporate relatively simple access control measures, usually to support needs within a single

access policies to be specified, but in order to support a distributed EHR scenario these will need to be interoperably specified and interoperable computationally. Most vendors, health services and healthcare networks are likely to adopt an incremental approach to enriching the sophistication of access control policies that can be supported.
There may be a range of high-level policies that will govern EHR disclosures within any regional healthcare network. Today these will exist primarily on paper or as hard-coded permissions within applications and servers, but in future these will be represented as interoperable access policies in accordance with the PMAC architecture. Some example factors that might be specified within such policies, and taken into account when making an EHR access decision, are listed below. National, Professional, Organizational policies might be based upon, for example:
a) User characteristics:
name and identification
profession, speciality, qualifications
functional role
department or clinical speciality of which he/she is acting as a member
organization of which he/she is acting as a member
b) Access characteristics:
date and time
location
physical device
network or other communications mechanism
mechanisms and extent of encryption in place
method of authentication used
c) Organizational policies might also confirm permissions about:
the patient whose record is being accessed
the archetypes being accessed
the operation proposed (read, write, modify, communicate, query etc.)
EHR-specific policies might provide or deny consent for:
a) named/identified parties
to access the EHR as a whole to adopt particular functional or structural roles (e.g. to specify a responsible personal healthcare agent)
b) specific clinical settings (e.g. departments, specialities)
c) specific functional roles
to access particular archetypes
to access particular Record Components
to access data of specific sensitivity
to undertake specific EHR functions (e.g. read, write, modify, communicate, query)
d) specific purposes for the access
e.g. direct care provision, support of care provision, teaching, research
justification or evidence required (e.g. if a formal signed consent must be provided)
The whole spectrum of access policies in place at an organization is beyond the scope of this standard, but this part standard does define a generic specification for representing and communicating those parts of access policies that relate directly to the data within any given EHR (Target Policies). These will often be representations of the disclosure wishes of the patient.

EHR Access Policies: a minimum specification for interoperability The information model in clause 7 for representing and communicating access policy information has been deliberately kept very generic, to allow for the diversity of policy criteria that will be stipulated in different countries and regional healthcare networks. Standardized vocabularies for many of the likely characteristics are not presently defined. The policy model in clause 7 is therefore only a partial aid to policy interoperability.
A number of existing and legacy systems might not be able to incorporate richly-defined policy specifications, and many healthcare regions might not be in a position to define such policies for some years. Therefore, as a complement to the overall policy model in clause 7, this part standard defines two vocabularies that can provide a minimum basis for making an access policy decision, and ensure a basic level access policy interoperability, albeit at a coarse-grained level.
These two vocabularies are: 1. sensitivity classification of EHR data (RECORD_COMPONENTS). 2. high-level classification of EHR Requesters and Recipients, through a set of Functional Roles.
Defining the sensitivity of EHR data Within a clinical care environment (i.e. within and between collaborating healthcare teams involved in the direct provision of care to patients) the norm is to share health record information openly. It is indeed the wish of the vast majority of patients that teams do this, and many patients are actually surprised at how little of their health record is shared today when it should be, for safety and for good continuity of care. Few contemporary healthcare systems (on paper or electronically) define complex internal access control partitions to the health records that they hold. Even if it were considered useful to define numerous fine-grained access policies, in practice it might take health care systems, national health services and millions of patients quite a long time to specify suitable access control policies for all of their EHR data, and to implement software components that can perform many complex policy-bridging computations in real time.
Maintenance of these policies as the clinical care requirements of each patient evolve would also be a complex process.

Key A Private entries shared with GP C Entries accessible to
administrative staff E Entries accessible to direct
care teams B Entries restricted to sexual
health team D Entries accessible to clinical
support staff F Private entries shared with
several named parties G Entries restricted to prison
health services
Figure 3 — Illustration of access domains within an example EHR
In this illustration, it is assumed that the patient has complete access to his or her EHR. The majority of this patient’s EHR is accessible to any party providing direct clinical care. However, the EHR does contain several private entries; some are restricted to the patient’s general (family) practitioner and some to a separate list of named parties. The EHR also contains some entries created by and restricted to a sexual health clinic, and others restricted to the prison health service – both can only be accessed by parties with relevant additional
...