Cookbook for the Security Section of IHE Profiles ______________________________________________________________________________
Note to the IHE Profile Writer All new IHE Profiles are required to have a Security Considerations section that communicates security concerns that the implementers need to be aware of, as well as the assumptions about security pre-conditions that have been made. Historically, IHE Profiles have not addressed the security considerations and thus Profile implementers have no direction. This document will help the IHE Profile writer address the Security Considerations section of their IHE Profile. The Security Considerations section should include direction on proper security implementation regarding the Actors and Transactions. This should not be considered a full system assessment. IHE Profiles are restricted to the Actors and Transactions defined and do not include system design criteria beyond those needed to ensure interoperability. This new section typically contains Profile grouping requirements (e.g. required grouping with ATNA Profile, optional grouping with EUA Profile). Along with these grouping requirements are special considerations when the profiles are grouped. Example of this is the security audit schema attributes and coding. There is no prescription that all IHE Profiles can follow. An important factor for the IHE Profile writers is Patient Safety. The best way to design security is to utilize a risk assessment and mitigation plan. This same risk assessment should consider the patient safety risks as well as the risks to privacy. The rest of this document will describe how to run a risk assessment for your new IHE Profile. The result of this risk assessment is a mitigation plan. Part of the mitigation plan will be Profile grouping requirements and direct Actor and Transaction requirements. This document is written by the IHE IT Infrastructure Planning committee. While this paper is primarily intended for the profile writer, section II has been geared to be useful to any development activity such as strategic planning, and project planning risk areas as well. Future iterations of this document will delve deeper into the strategic and planning levels of risk assessment that need to be done in order to have a safe and coherent environment.
Cookbook for the Security Section of IHE Profiles ______________________________________________________________________________
1. Introduction 1.1. Identifying Risk in Healthcare Information Technology The risks associated with personal health information are greater than identity theft and privacy violation. Other critical risks that need to be addressed include: • legal compliance; safe provision of healthcare services; • patient safety; • • avoiding prescribing errors. Increasingly, healthcare organizations and technology vendors are performing assessments (threat risk assessments, privacy impact assessments, business impact assessments, etc.) to ensure installed healthcare technology will have a positive impact on healthcare delivery. These assessments, often called risk assessments, are even mandated for healthcare delivery organizations in some countries. However,key decision makers have difficulty understanding the relevance of the risks identified, and discussions such as how much risk is acceptable, what types of risk may arise from new technologies, and how much to spend on mitigating risk are often overlooked. As a result, risk is not properly considered when determining technology strategy. This whitepaper is intended to educate healthcare organizations and technology vendors about the concept of risk management, specifically with regard to healthcare information technology, so that they can use risk management successfully in developing and implementing their technology strategy. It will present some tried and tested risk management tools to identify and address the risks inherent in healthcare technology in a coordinated manner. 1.2. The problem “Why the current endless list of security risks isn t getting us anywhere, and why ’ we need to advance into a new paradigm. As healthcare technology grows more complex, the need for a unified approach to managing the risks inherent in new technologies grows with it. These risks include many different types of risks including: IT security, privacy, safety, corporate risks and human factor. A holistic analysis is necessary to weight the cost of preventative measures. Risk management is about more than keeping hackers from stealing personal health information. It is critical to address such issues as: • legal compliance; • safe provision of healthcare services; • patient safety; • avoiding prescribing errors, etc.
Cookbook for the Security Section of IHE Profiles ______________________________________________________________________________ Diligent healthcare organizations as well as technology vendors have been working since the inception of healthcare technology to assess their own risk levels as best they can by performing threat risk assessments, privacy impact assessments, business impact assessments, security posture assessments, ad infinitum. While a number of countries mandate risk management, these risk assessments are still often left to gather dust due to their confusing nature. Key decision makers have difficulty understanding the relevance of the risks identified, and often overlook them when determining technology strategy. As a result, discussions such as how much risk is acceptable, what types of risk may arise from new technologies, and how much to spend on mitigating risk are often overlooked. Security, privacy or other expensive technologies are invested in as a result of popular demand rather than cohesive vision, an important motivation for the creation of this whitepaper. This whitepaper will present some tried and tested risk management tools to identify and address the risks inherent in healthcare technology in a coordinated manner. 1.3. Defining and Managing Risk Risk is defined as the chance of an event or activity that will have an impact on business or technology objectives. The majority of risks reported mention negative impacts (such as those listed in Figure 1-2), however it is important to note that a risk can have an impact that is positive: an opportunity to reduce wait times, provide patients with access to their health data, reduce medication conflicts through automated checks against a database. The risk level is measured in terms of a combinations of the likelihood (probability) and impact (positive or negative) of an anticipated event. While traditional healthcare risks have always necessitated management: such as errors in prescribing, errors in treatment, or patients’ falling or wandering off; new sources of risk associated with information technology have been introduced: IT security and privacy, safety and availability of information when needed, corporate management of technology systems, and even human factor risks such as fatigue and difficult to read application interfaces (see Figure 1). As healthcare technology grows more complex, the need for a unified approach to managing the risks inherent in new technologies grows with it. Risk Management is a combination of all the processes involved in realizing existing as well as newly identified opportunities in a manner consistent with public interest, human safety and the law while managing adverse effects caused by the complexity of healthcare systems. It involves identifying, assessing and judging risks, assigning ownership, taking action to mitigate or anticipate them, and monitoring and reviewing progress. The outcome is a holistic analysis that weighs the cost of preventative measures and establishes a continuous process to manage them.
Cookbook for the Security Section of IHE Profiles ______________________________________________________________________________ both how to do a risk assessment, as well as the fact that not all risk assessments can be applied to all implementations. As with all assessment exercises, once a risk management framework is agreed upon, the real work must begin. Healthcare IT exists in an environment which is constantly identifying new issues and risks (primarily in but not limited to the security domain). An ad-hoc approach to addressing these is dangerous and creates many new risks, such as technology conflicts, obsolescence, and inadequate focus on prioritizing solutions according to greatest value. A prime example of this phenomenon is leveraging biometric technology for uses for which they were not intended. Instead, there must be a corporate-wide commitment to applying the risk management framework on a continuous basis. This is the proven method of benefiting from risk management activities. 1.5. Scope This document is primarily concerned with laying out some straight forward risk management and prioritization tools to facilitate problem analysis and prioritization work. 1.5.1. Scope of Risk Management in the IHE [ITI] The scope of the Risk Management whitepaper is the universe of risk associated with information technology. Examples of risks that may pertain to the IHE are: • Integrity and confidentiality of personal health information while it is within an XDS environment; • Patient safety that may be affected by risks to information within an integrated environment; • Technology risks (conflict, interoperability, availability); • Obsolescence risks; • Inappropriate or premature choices of technology solutions that jeopardize adoption, funding, and future initiatives; • Trust between organizations (and their handling of information security); and Authorization/Identification risks • • Identification of risks that can not be addressed within an IHE system and must be communicated. Most clinical risks are outside the scope of this purview, and discussions of human fatigue and risks such as those introduced by poorly designed user interfaces should be scope out for the purpose of the initial paper but may be necessary to define at a later time. The task of the IHE risk assessment is to ensure that each profile enables the services that are needed to support the results of the risk assessments of the products that implement the profile. This whitepaper will attempt to provide examples of risk assessments (in section 3) that illustrate both how to do a risk assessment as well as the fact that not all risk assessments can be applied to all implementations.
Cookbook for the Security Section of IHE Profiles ______________________________________________________________________________ 1.5.2. Value Statement All healthcare organizations are faced with the difficult task of delivering timely and comprehensive healthcare while juggling the risks associated with that healthcare. This should not be thought of as a conflict but an opportunity to identify potential problems and solve or at least minimize them before they occur.
1.6. Objectives Once risk management tools and methodologies are agreed upon, there must be some work done at the planning level to apply these tools across the board .
Cookbook for the Security Section of IHE Profiles ______________________________________________________________________________ • What are the assets that we are trying to protect? o What are possible threats and threat scenarios to those assets? o What are the vulnerabilities of the systems in place around these assets? • What are the categories of risk that we are concerned with? o Technical o Strategic/commercial o Organizational o Human (user / patient / administrator) o Political o Financial/economic o Environmental After the initial creation of a catch-all list of possible risks, vulnerabilities and threats by brainstorm or checklist method, the refinement process is simply to narrow down the list by removing out-of-scope, redundant, and non-critical elements. 2.2. Analyze After a comprehensive list of risks is prepared and brief descriptions are recorded, the next step is to assign quantitative values of the business impact of each risk so that they can be compared. A value from very low to very high (i.e. vl-l-m-h-vh ) must be assigned in each of two traditional areas: likelihood and impact. In order to that stakeholders understand the context of the evaluation, likelihood and impact tables should be developed that specify the definitions of each value. (For example, Tables 2.1 and 2.2 are used by Ontario’s Smart Systems for Health Agency (SSHA), a large non-profit, IT service provider). Each organization must determine their own impact categories and create a hierarchy of severity to illustrate them such as in table 2.2. Table 2.1: Sample likelihood Categories Source: SSHA Probability Likelihood Description Very High > 80% This event will probably occu in the near future. High 51% to 80% This event is likely to occur i the near future. Medium 21% to 50% This event may occur in the near future. Low This event is possible but 6% to 20% highly unlikely to occur in the near future. Very Low 0% to 5% This event is not expected to occur in the near future.
Cookbook for the Security Section of IHE Profiles ______________________________________________________________________________
Table 2.2: Sample impact Categories Source: SSHA Cost Reputation Safety Delivery Very High Capital Cost of Potential for Potential for Six months o May not be abl > $100 M reduction in multiple more to deliver on SSHA mandate fatalities / most critical serious requirements injuries High Capital Cost of Serious advers Potential for Between two Major shortfalls $10M to $100 attention from single fatalit and six in one or more media, medical / serious months critical establishment injury requirements and / or public Medium Capital Cost of Minor adverse Potential for Between two Minor shortfalls $1M to $10 M attention from minor injury weeks and in one or more media, medical two months key establishment requirements and / or public Low Capital Cost of Loss of Potential to Less than tw A few shortfalls $100,000 to $1 reputation reduce weeks in desired among clients / quality of functionality partners health care Very Low Capital Cost of Internal loss of Impact does Less than two System should < $100,000 reputation not affect days still fully meet delivery of mandatory health care requirements
This whitepaper will not prescribe likelihood and impact categories for IHE profile development but encourages those undertaking risk assessments to consider the categories of impact that affect them most and to outline lowest to highest impact examples (vl l m h vh)