1、 g49g50g3g38g50g51g60g44g49g42g3g58g44g55g43g50g56g55g3g37g54g44g3g51g40g53g48g44g54g54g44g50g49g3g40g59g38g40g51g55g3g36g54g3g51g40g53g48g44g55g55g40g39g3g37g60g3g38g50g51g60g53g44g42g43g55g3g47g36g58communication Part 4: SecurityThe European Standard EN 13606-4:2007 has the status of a British Sta
2、ndardICS 35.240.80Health informatics Electronic health record BRITISH STANDARDBS EN 13606-4:2007BS EN 13606-4:2007This British Standard was published under the authority of the Standards Policy and Strategy Committee on 30 April 2007 BSI 2007ISBN 978 0 580 50579 9Amendments issued since publicationA
3、md. No. Date Commentscontract. Users are responsible for its correct application.Compliance with a British Standard cannot confer immunity from legal obligations. National forewordThis British Standard was published by BSI. It is the UK implementation of EN 13606-4:2007. It supersedes DD ENV 13606-4
4、:2000 which is withdrawn.The UK participation in its preparation was entrusted to Technical Committee IST/35, Health informatics.A list of organizations represented on this committee can be obtained on request to its secretary.This publication does not purport to include all the necessary provisions
5、 of a EUROPEAN STANDARDNORME EUROPENNEEUROPISCHE NORMEN 13606-4March 2007ICS 35.240.80 Supersedes ENV 13606-4:2000 English VersionHealth informatics - Electronic health record communication -Part 4: SecurityInformatique de sant - Dossiers de sant informatisscommunicants - Partie 4 : Exigences de scu
6、rit et rglesde 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
7、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 ve
8、rsions (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,
9、 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 STANDA
10、RDIZATIONCOMIT EUROPEN DE NORMALISATIONEUROPISCHES KOMITEE FR NORMUNGManagement Centre: rue de Stassart, 36 B-1050 Brussels 2007 CEN All rights of exploitation in any form and by any means reservedworldwide for CEN national Members.Ref. No. EN 13606-4:2007: EEN 13606-4:2007 (E) 2 Contents Page Forew
11、ord3 Introduction .4 1 Scope 19 2 Normative references 19 3 Terms and definitions .19 4 Symbols and abbreviations 21 5 Conformance22 6 Record Component Sensitivity and Functional Roles (Normative)23 6.1 RECORD_COMPONENT sensitivity .23 6.2 Functional Roles23 6.3 Mapping of Functional Role to RECORD_
12、COMPONENT Sensitivity24 7 Representing access policy information within an EHR_EXTRACT25 7.1 General25 7.2 Archetype of the Access policy COMPOSITION.26 7.3 ADL representation of the archetype of the access policy COMPOSITION 28 7.4 UML representation of the archetype of the access policy COMPOSITIO
13、N33 8 Representation of audit log information .35 8.1 EHR_AUDIT_LOG_EXTRACT model35 Annex A (informative) Illustrative access control example 38 Annex B (informative) Relationship of this part standard to the Distribution Rules: ENV 13606-3:200042 Bibliography 47 EN 13606-4:2007 (E) 3 Foreword This
14、document (EN 13606-4:2007) has been prepared by Technical Committee CEN/TC 251 “Health informatics”, the secretariat of which is held by NEN. This European Standard shall be given the status of a national standard, either by publication of an identical text or by endorsement, at the latest by Septem
15、ber 2007, and conflicting national standards shall be withdrawn at the latest by September 2007. This document supersedes ENV 13606-4:2000. According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following countries are bound to implement this European Standard
16、: 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. EN 1360
17、6-4:2007 (E) 4 Introduction Challenge addressed by this Part Standard The communication of electronic health records (EHRs) in whole or in part, within and across organisational boundaries, and sometimes across national borders, is challenging from a security perspective. Health records should be cr
18、eated, 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. The EU Data Protection Directive 95/46/EC
19、 and the Council of Europe Recommendation on the Protection of Medical Data R(97)5 provide an important legal basis for the requirements for security services as described in this standard. These instruments declare that the subject of care has the right to play a pivotal role in decisions on the co
20、ntent 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 wishes
21、by which the data subject signifies his agreement to personal data relating to him being processed“). For international health record transfers EN 14484 (Health informatics - International transfer of personal health data covered by the EU data protection directive - High level security policy) and
22、EN 14485 (Health informatics - Guidance for handling personal health data in international applications in the context of the EU data protection directive) provide policy guidance on how this may lawfully and safely be carried out. Ideally, each fine grained entry in a patients record should be capa
23、ble of being associated with an access control list of persons who have rights to view that information, which has been generated or at least approved by the patient and that reflects the dynamic nature of the set of persons with legitimate duty of care towards the patient through his or her lifetim
24、e. The access control list will ideally also include those persons who have rights 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 pa
25、tient feels is too personal for them to access. On the opposite side, the labelling by patients or their representatives of information as personal or private should ideally not hamper those who legitimately need to see the information in an emergency, nor accidentally result in genuine health care
26、providers having such a filtered perspective that they are misled into managing the 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.
27、 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 others records (but not necessarily to equal extents) in order to monitor the progress of i
28、nherited 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 healt
29、h care; numbers of health care 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 lifetime; difficulty (for a patient or for anyone else) of classifying in a
30、 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; EN 13606-4:2007 (E) 5 logically indelible nature of the EHR and the need for revisions to access permi
31、ssions 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
32、 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 da
33、ta between health care 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 wo
34、uld 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 providers policies, and to any access control or consent
35、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 c
36、omputer-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 consist
37、ency 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 patients lifetime. It is also important to recognize that, for the foresee
38、able future, diversity will continue to exist across Europe on the specific approaches to securing EHR communications, including differing legislation, and that a highly prescriptive approach to standardization is not presently possible. This European standard therefore does not prescribe the access
39、 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 acc
40、ess policy, and a richer generic representation for the communication of more fine-grained detailed policy information. This framework complements the overall architecture defined in Part 1 of this multipart standard, and defines specific information structures that are to be communicated as part of
41、 an EHR_EXTRACT defined in Part 1. NOTE 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 hea
42、lth 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. Th
43、ere 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
44、 22600 Privilege Management and Access Control (PMAC), ISO Work Item: ISO/TS 21298 on Functional and Structural roles. EN 13606-4:2007 (E) 6 Communication scenarios The interfaces and message models required to support EHR communication are the subject of Part 5 of this multipart standard. The descr
45、iption here is an overview of the communications process in order to show the interactions for which security features are needed. The diagram below illustrates the key data flows and scenarios that need to be considered by this standard. For each key data flow there will be an acknowledgement respo
46、nse, and optionally a rejection may be returned instead of the requested data. 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 representat
47、ive 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. R
48、equest 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 acc
49、ess 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 EN 13606-4:2007 (E) 7 EHR data to be sent to a healthcare professional. In such cases it is the EHR Recipients credentials that will principally determine the access decision to be made. An EHR request may need to include or reference consents for access a
