Cookbook for the Security Section of IHE Profiles - for public comment

Ccarr

Informations

• Publié par: Unne
• Nombre de lectures: 18
• Langue: English

Extrait

       

 

        HIMSS, RSNA, and ACC Integrating the Healthcare Enterprise  

    Cookbook for the Security Section of IHE Profiles (Risk Management in Healthcare IT Whitepaper)       For public comment August 30, 2006

 

Copyright © 2006, ACC/HIMSS/RSNA

Cookbook for the Security Section of IHE Profiles ______________________________________________________________________________    

Contents   Note to the IHE Profile Writer........................................................................................................ 1 1. Introduction............................................................................................................................. 2 Identifying Risk in Healthcare Information Technology............................................................ 2 1.1. The problem: ................................................................................................................... 2 1.2. Defining and Managing Risk .......................................................................................... 3 1.3. Developing a Risk Management Framework ................................................................. 4 1.4. Scope............................................................................................................................... 5 1.4.1. Scope of Risk Management in the IHE [ITI].......................................................... 5 1.4.2. Value Statement......................................................................................................6  1.5. Objectives ....................................................................................................................... 6 2. Section 2: Tools and methodologies ....................................................................................... 7 2.1. Identify............................................................................................................................7  2.2. Analyze ........................................................................................................................... 8 2.3. Prioritize.......................................................................................................................... 9 2.4. Plan (strategize) ............................................................................................................ 10 2.5. Execute.......................................................................................................................... 15 2.6. Monitor and Review ..................................................................................................... 15 2.7. Document ...................................................................................................................... 17 Conclusion .................................................................................................................................... 18 White Paper Drafting Team..........................................................................................................19  Acknowledgements....................................................................................................................... 19    

_____________________________________________________________________________________   - ii - Public Comment August, 2006 Copyright © 2006, ACC/HIMSS/RSNA

5 10 15 20 25 30

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.

Public Comment August 30, 2006

  - 1 -     

Copyright © 2006, ACC/HIMSS/RSNA

35 40 45 50 55 60 65 70

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.

  2 - - Public Comment August 30, 2006 Copyright © 2006, ACC/HIMSS/RSNA

75 80 85 90 95 100 105 110

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.

Public Comment August 30, 2006

  - 3 -  Copyright © 2006, ACC/HIMSS/RSNA

115 120 125 130 135 140 145 150 155

Hazard / Environmental

Safety

O a r t g io a Technology - Hu Reso

  Figure 1 - 1  Sample Risk Catogory Wheel Source : SSHA

Cookbook for the Security Section of IHE Profiles ______________________________________________________________________________                                                   Effective risk management enables senior management, middle management, and technical and operational staff to:   •   Improve business performance by informing and improving decision making and planning; •   Promote a more innovative, less risk adverse culture in which the taking of calculated risks in pursuit of opportunities is encouraged; •   Provide a sound basis for integrated risk management and internal control as components of good corporate governance; •   Assist in meeting healthcare requirements and objectives; •   Facilitate partnerships with other healthcare organizations to address the issues inherent in interoperable systems and data sharing; and •   Benefit patients who are often shared among unrelated healthcare providers both in terms of the handling of their information as well as improving the safety of healthcare services. 1.4. Developing a Risk Management Framework A risk management framework consists of risk management and prioritization tools that facilitate problem analysis and prioritization work throughout the risk management assessment lifecycle. This whitepaper will provide examples of some popular tools used. The objective is to illustrate   - 4 -   Public Comment August 30, 2006 Copyright © 2006, ACC/HIMSS/RSNA

160 165 170 175 180 185 190 195

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.  

Public Comment August 30, 2006

  - 5 -  Copyright © 2006, ACC/HIMSS/RSNA

200   205

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 .

Public Comment August 30, 2006

  - 6 -    

Copyright © 2006, ACC/HIMSS/RSNA

210 215 220

Cookbook for the Security Section of IHE Profiles ______________________________________________________________________________    

2. Section 2: Tools and methodologies

  Figure 2 - 1 Risk Management Lifecycle Source : SSHA   The risk management lifecycle consists of seven well-defined stages. The following sections describe the activities conducted at each stage and offer advice and tools for accomplishing them. (Note that the examples in this whitepaper focus on risks associated with healthcare information technology, but clinical risks, human fatigue, and risks such as those introduced by poorly designed user interfaces must also be addressed in a complete risk management program.) 2.1. Identify Prior to planning any security solutions, the entire gamut of risks pertinent to a new technology or architecture must be identified. The identification process usually includes leading facilitated brainstorming sessions with subject matter experts and summarizing the findings. It may also be helpful to consult published checklists from different types risk assessment standardization groups (e.g. ISO, HIROC, FMEA, CRAMM).   An important hint to the identification process is that the information often exists in the minds of the subject matter experts. Asking pertinent questions such as:   - 7 - Public Comment August 30, 2006 Copyright © 2006, ACC/HIMSS/RSNA

225 230 235 240 245 250

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.

 

  - 8 -   Public Comment August 30, 2006

Copyright © 2006, ACC/HIMSS/RSNA

255

260 265 270

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)

2.3. Prioritize Once risks are assigned impact and likelihood values they can be compared, using a tool such as a risk map (Table 2.3.1). In brief, the red, orange and yellow areas are where the organization must focus their mitigation efforts first. Items in the green and blue areas still qualify as risks, but are of lower priority until all greater risks are mitigated. Organizations must determine their own risk tolerance line, ie: when to accept risks and when risk mitigations cannot be delayed.   Take for example the risk of flooding to an IT data centre. While the potential impact of this risk could be huge, the likelihood of an actual occurrence of this risk in a dry climate (e.g. Arizona, USA) is very low. In addition, many data centres designed to include some precautions (e.g. such as putting actual server rooms on well reinforced floors or well above ground level), so the impact of a flood would be reduced from “truly catastrophic failure to deliver” to “low impact on infrastructure”. As a result the final risk rating of the “flooding to the IT data centre of the well  constructed Arizona data centre” falls in the “blue” category and does not needto be addressed at   9 - - Public Comment August 30, 2006 Copyright © 2006, ACC/HIMSS/RSNA