Ebook: Data Security for Health Care

The SEISMED project was initiated in 1992 as the result of the fusion of two attractive security proposals to the Advanced Informatics in Medicine [AIM] secretariat, SEISMIC and PIMEDIS. It has proved to be a very successful project bringing together a number of partners from the Medical Informatics and the IT Security fields. The project developed an extensive series of Guidelines covering different aspects of security from the point of view of Health Information Systems.

The material presented here comprises the key security Guidelines developed by the project and tested in its four Reference Centres. For ease of reading and simplicity much of the detailed contextual material that accompanied their development over the four years that the project lasted has not been included. However it is believed that this publication comprises the concentrated guidance that can help to ensure that appropriate security is injected into European Health Information Systems. The full copies of all the publically available SEISMED deliverables are available from either the NHS Information Management Centre or from the original main author should anyone wish to have the full set of explanatory material.

The SEISMED Co-ordinating Partner would like to take this opportunity of thanking the members of the consortium for their work which made this book possible and in particular the first co-ordinating partner who set the consortium on track during the initial phases of the project. In addition, all members of the consortium would like to express their thanks for the support that they received from the AIM project officers, Gottfried Dietzel and Jens Christensen, and the encouragement received from the former Head of the AIM office, Niels Rossing, at all phases of the project development. In addition, they would like to express their thanks to Brian Molteno of the NHS Information Management Centre, David Preston of the NHS Executive and Brian Jones of the Department of Trade and Industry who assisted in the successful negotiations that led to the successful transfer of the prime contractor role during the summer of 1994.

The SEISMED Consortium takes responsibility as a whole for the material presented and all members of the consortium participated to a greater or lesser degree in the preparation, examination, development and quality assurance of the SEISMED deliverables. However, the Workpackage leaders, under whose names the various Guidelines are listed, took the key responsibility for preparing and presenting the material and revising it in the light of consortium discussions. In addition, Kees Louwerse and Sokratis Katsikas took extra responsibility for editing the text in the context of the presentation of these Guidelines within a single book and Alison Treacher undertook the difficult task of extracting the key issues in each of the deliverables and synthesising them into a readable whole.

The consortium would, also, like to express their gratitude to Sue Riddlesdin for her help in organising the process of preparing and formatting the electronic version of the text in preparation for printing.

Barry Barber

The efficiency of modem health care relies more and more upon a computerised infrastructure. Open distributed information systems have started to bring professionals together from all over the world. On the one hand easy processing and communication of images, sounds and texts will help to represent and treat illnesses and diseases efficiently, on the other hand the very ease of access and use can threaten patient privacy, accountability and health care professional secrecy. The European Union (EU) initiated a multi-disciplinary project to come up with practical guidelines detailing how to achieve a Secure Environment for Information Systems in MEDicine (SEISMED). The project has taken into account the traditional and proven principles of health care data processing, the various legislative environments within the EU, the enormous and subtle risks to the security of health care information systems, and the cost of changing existing technology. The guidelines have been validated by the SEISMED reference centres.

One main objective of SEISMED (Secure Environment for Information Systems in Medicine) is to develop a consistent, harmonised and transferable framework which can be used to efficiently implement security and data protection in computerised information systems throughout Europe. In order to provide guidelines for professional conduct and to promote international cooperation, it would be useful to have an international deontology code for the protection of medical data. The purpose of such a code would be to provide general guidelines as a foundation for national codes that may be developed within individual countries.

A deontology code has no formal legal force, which means that it cannot be used in litigation as a legal base for a decision. However, the code can be used as a reference document to strengthen the line of argument. In addition, the code can be used as a reference document by medical profession for questions of ethical behaviour. The code provides answers allowing the physicians to use these rules to solve individual cases. The salience of a code is in direct relationship to the difficulty and frequency of ethical problems in a profession. People in the health-care sector are continually confronted with ethical problems that a code would help to clarify. So the code could definitely be used. Moreover, the code is needed because the golden rule “doing unto others as you would like others to do unto you” can be a poor approach to a professional- patient relationship and because the patients' view may be different from the professionals' view. The code could actually help to prevent the passage of restrictive laws by making them appear less necessary. Codes also help to eliminate unethical practices that lead to lawsuits; they clarify standards of practice and leave fewer issues to be settled in court. Other arguments in favour of a deontology code are that a code would protect present and future patients from harm, would influence public policy and would improve the image of the profession. This last argument should however be a side effect rather than the main intention of the code.

It is worthwhile to mention that a deontology code has to exist within the legal framework. This goes also for the following health informatics deontology code which fits into the data protection legislations of the different European countries.

Sometimes the deontology code will appear rigid, but this is unavoidable if it is to meet the legal provisions of the different European countries regarding medical data protection. However, there is always the possibility of changing those strict legislations by harmonisation. Therefore, this code could bring legislator and practitioners together to change rules if necessary.

Finally, all problems with regard to medical data protection could not be entirely covered by the code. For example, the communication of medical data by the physician to an insurance company or to an employer, which are both no part of the health care sector, is submitted to the relevant existing national legislation.

End-users have a very real contribution to make towards the evaluation of risks to the automated information systems which they use. Their knowledge and understanding of what might happen and how people may respond in reaction to a security breach is vital to the proper understanding of risk.

The objective of SEISMED (a \underbar{S}ecure \underbar{E}nvironment for \underbar{I}nformation \underbar{S}ystems in \underline{MED}icine) was to develop a consistent, harmonised framework for the security of medical data throughout Europe. The specific technical proposals of SEISMED are supported by a high level security policy which describes the underlying principles.

Part of the overall SEISMED process was the development of a relatively fast and simple method for understanding the risks faced by IT systems in a health care environment and the measures which could be taken to counter those risks. The relevant risks were identified from the results of risk analysis exercises carried out as part of the SEISMED project at a number of health care establishments across Europe. The risk analysis method proposed in this guideline has evolved from that work and is described in detail in the accompanying guideline “Guidelines on IT Security Risk Analysis for IT and Security Personnel”. A separate guideline is available for management.

All staff carry some measure of responsibility for security. With the assistance of this guideline, users will be able to examine their own environment and make an initial assessment of the risks involved with the operation of the information system they use. This could contribute directly to an improvement in the level of protection afforded to the system or may initiate further action by those with a more technical appreciation of the issues involved.

These guidelines explain the basic theory of risk analysis in terms of the consequences of failures in security combined with the likelihood of events which could bring about such failures. No one can afford to be complacent about the risks faced by their IT systems and the consequences for the organisation as a whole. Nor should they react blindly to possible problems of which they have an imperfect understanding. Risk analysis provides that proper understanding and improves the quality of decisions on what constitutes appropriate security.

A specific approach to risk analysis is described. The results will be a profile of risks across a range of issues and a package of countermeasures to meet those risks. Where there are insufficient resources to apply all those measures, at least in the first instance, users will need to discuss with management and other Health Care Professionals which risks should be met and to what extent, and which risks should be accepted. A detailed description of how users can contribute is given in this guideline.

High Level Security Policies (HLSPs) are management instructions indicating how an organisation is to be run. They are the primary building blocks for any information security effort. In order to successfully install security in Information Systems operating in European Health Care Establishments (HCEs), a set of principles and guidelines must exist, which establishes both direction and management support.

A HLSP should be used as a reference for a wide variety of information security and privacy activities which include establishment of user access privileges, performing risk analyses, conducting investigation of security and privacy threats, etc. It should also be considered as an essential part of the overall information policy of every HCE, which helps integrating the procedural aspects within the administrative organisation in the HCE.

A HLSP refers primarily to two main actors, namely the acting subjects (patients, physicians, health informaticians, administrators, health care authorities, insurance companies, etc.) and the data objects that should be protected (medical records, communication data, etc.).

The High Level Security Policy proposed herein should be fully adopted in order to be effective; moreover, conformance to its provisions should be made mandatory for all members of staff; special approval should be required when a HCE staff member wishes to take a course of action divergent from policy rules.

It is worth noticing that even when a High Level Security Policy already exists, it is advisable to the management of the Health Care Establishment to periodically revisit it to see whether it should be modified or augmented.

Security in Health Care Automated Information Systems can be conceptually viewed at four distinct levels of abstraction, namely generic principles (society and culture dependent); principles (administration dependent); guidelines (technology dependent) and measures (installation dependent).

HLSPs address the two middle levels of abstraction, namely principles and guidelines. Hence, HLSPs depend on generic principles and must be complemented by measures.

The HLSP, as it stands, defines the general approach that a Health Care Establishment should have towards implementing security. In other words, it states what should be done in order to implement security efficiently; it does not provide technical details on how to do this. These details can be found in the specialised technical guidelines developed within SEISMED.

No formalised security levels have been considered in this document. Rather, the High Level Security Policy herein provides a set of mandatory conditions to ensure adequate security of personal information processed by Health Information Systems.

The HLSP proposed herein was developed by a top-down approach. Specifically, principles were first derived as a result of:

✓ consulting, analysing and adapting relevant similar efforts of international bodies, including - inter alia - the CEC (Directives 287 and 288), the Council of Europe, the Organisation of Economical Co-operation and Development (OECD), the US Department of Health Automated Information Systems Security Program Handbook, etc.

✓ considering what the functional model of a “secure” HCE should be.

Secondly, guidelines were developed, by detailing principles. The end result is a set of nine principles and eighty seven guidelines.

The HLSP was developed in three phases. The first phase aimed at providing the reference centres with an initial draft of the HLSP, based on:

✓ the results of an attitude survey among Health Care professionals in Europe;

✓ the results of Risk Analysis exercises conducted at the four hospitals acting as reference centres;

✓ the results of the analysis of existing and emerging data protection legislation throughout Europe;

✓ relevant international literature.

The second phase consisted of the evaluation of the draft HLSP produced by the first phase by Health Care professionals, Health Informaticians and management.

The third phase consisted of the evaluation of the draft HLSP by all SEISMED partners and resulted in the current document.

The end result is a compromise between several different (but mostly fundamentally convergent) opinions expressed by project participants or external experts; nevertheless it is felt that this has not led into major internal inconsistencies or contradictions.

It is also felt that the HLSP should undergo a further, lengthy period of implementation in several HCEs across Europe, so it can be verified, amended, or modified according to everyday practice.

The overall objective of the SEISMED (a Secure Environment for Information Systems in MEDicine) project was to develop a consistent, harmonised framework for the protection of medical data throughout Europe. This document presents guidelines for the security of existing European health care systems based upon work conducted by SEISMED workpackage SP07 (Security in Existing Systems).

Information technology has had a significant impact upon Health care Establishments (HCEs) in Europe, with information systems now affecting most aspects of their operation. As a result, health care professionals are becoming increasingly dependent upon the availability and the correctness of systems and data. Unfortunately, many existing systems current operate without security having been properly addressed, making them vulnerable to a variety of accidental and deliberate threats. As a result there is a requirement to add or enhance protection in many cases.

In many ways the security requirements in health care environments are fundamentally different from other domains and hence many aspects of existing standards were considered inappropriate. The problem has been addressed by the development of information security guidelines specifically targeting the health care community.

A comprehensive set of baseline security recommendations have been developed for use by all HCEs within Europe, representing a minimal acceptable standard for the security of operational health information systems and their associated environments. The guidelines are intended to provide a straightforward means of identifying security weaknesses and validating existing systems to ensure compliance. The guidelines were developed in close consultation with the medical community, with input from both the SEISMED Reference Centres and other independent health care professionals.

The guidelines are grouped under ten key principles of protection, which are considered to represent the main areas that must be considered in securing existing systems. Coverage includes policy and administration issues, physical and environmental protection, personnel security procedures and logical I system security controls.

The guidelines are relevant to and will affect all categories of HCE personnel. However, certain issues are not appropriate to all staff and, therefore, three separate sets of guidelines are available, each focusing on different classes of HCE personnel.

• General guidelines are available for day-to-day reference by the majority of HCE staff (including clinicians, administrators and general system users).

• Management guidelines target those responsible for determining HCE security policy and also serve to explain the need for a number of more technically based measures.

• IT & Security Personnel guidelines present the most detailed information relating to the implementation and validation of security and address personnel such as IT staff and system administrators.

These documents provide extensive information on what aspects of security should be considered, with appropriate guidelines in each case, as well as general suggestions on implementation. It is envisaged that the guidelines may be used as either a detailed source of reference during the introduction of security or, alternatively, as a simple means of validating existing arrangements.

This document includes two parts. The scope of Part I is to accomplish the final set of Network Security guidelines that aim at providing a secure environment in European Health Care networking information systems. These guidelines will be used by Reference Centres to implement security mechanisms and protocols for the provision of network security in Health Care Establishments in EC member countries.

Section 1 outlines the approaches followed in establishing Network Security guidelines; the conceptual approach and the technical approach.

Section 2 describes the method used in producing these guidelines, and includes the inputs used, the objectives of the work carried out, the technical approach applied, and the outputs derived from that work.

Section 3 provides descriptions of the principles that group the Network Security guidelines and detailed descriptions of the latter that pertain to each principle.

Section 4 provides a roadmap for the Network Security Guidelines usage and establishment.

The scope of Part II is to provide the final list of Health Care requirements for Network Security, the final list of security services, the final list of the security mechanisms, and to produce lists of policies and procedures for day-to-day secure network operations, as well as to expand on the entries of the above lists in detail, for the provision of network security in Health Care Environments in EC member countries.

The technical approach of the above objectives has been based upon the fact that data being transmitted across a network in HCEs are subject to several different types of attack. Those attacks have a number of impacts over the whole environment and security services are defined to ensure adequate security against the mentioned attacks. Security mechanisms are used to provide those services.

Section 1 introduces the list of potential methods of attack that could be used and the list of threats that a networking HCE faces when an attack occurs.

Section 2 describes the final lists of Network Security requirements, HC Personnel User requirements, and HC requirements for Network Security.

Section 3 lists and examines the security services that protect the data being transmitted across a link - either a HCE internal domain link or an inter-domain HCE line - from the above mentioned methods of attack and consequently from the specific threats.

Section 4 lists those security mechanisms that could be used for the implementation of one or more of the specified security services.

Section 5 lists policies and procedures for day-to-day secure network operations. Those policies and procedures will allow network managers in HCEs to create a helpful, practical handbook of procedures that they can refer to daily in relation to their network activities.

Section 6 presents the requirements - guidelines coverage map.

Section 7 lists references used for the production of this document.

The comprehensive objective of SEISMED (a \underbar{S}ecure \underbar{E}nvironment for \underbar{I}nformation \underbar{S}ystems in \underline{MED}icine) was to elaborate a consistent, harmonized framework for medical data protection throughout Europe. The specific technical proposals of SEISMED are thus accompanied by a high level security policy which presents the underlying principles. This approach is consistent with the forthcoming European ITSEC activity.

SEISMED proposes a suite of cryptographic mechanisms in order to provide sufficient flexibility to meet the characteristic challenges of health care data processing:

• A long tradition of decentralized processing of health care data with multilateral and legitimate interests.

• Ultra high sensitivity of personal medical data whose disclosure might not be repairable by, e.g. smart-money.

• Long periods of time (up to 30 years) over which health care data must be archived in its original state.

A 20 man-month workpackage evaluated the pertinent cryptographic literature, other relevant EC-projects (RACE Integrity Primitives Evaluation project RIPE), and renowned conferences (IACR Crypto, IACR Eurocrypt, ACM Symposium on Theory of Computing, Symposium on the Foundations of Computer Science, IEEE Symposium on Research in Security and Privacy, etc.). The result is a cryptographic guideline which is presented by separate documents to three different target audiences.