Cookbook for Security Considerations

Healthcare today has some of the most diverse needs with regard to sharing of data and the need to securely move patient information among systems. Within Health Level Seven (HL7) there are multiple verticals that consider messaging, structures, data models, coding and the like. Security is the common thread that connects all of them. 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. Unfortunately, key decision makers often have difficulty understanding the relevance of the risks identified, and often overlook them when writing standards.

The Goal

This Security Risk Assessment Cookbook is intended to enable HL7 domain committees and working groups to publish standards that have taken privacy and security considerations into account. This guide introduces security risk assessments and a process to facilitate completing a security risk assessment for a specific standard. Using this process will facilitate the identification of gaps in a standard’s baseline security and privacy, allowing the working group to either update the standard on their own or to send a request to the Security Working Group for assistance in filling the gap. This will lead to standards that include privacy and security as part of their base, reducing the need to “bolt” security on later. As a result, the HL7 standards will better support patient safety and improved patient outcomes.

The Process

The formal cookbook is documented and training is available in the Resources section below. This text comes from section 2 of the cookbook document

When considering security and privacy issues associated with a standard, one must:

1. Identify (See section 2.2)
   1. And clearly define the scope of the standard, including the baseline assumptions
   2. New threat scenarios and describe the type of impact that scenario implies
2. Analyze (See section 2.3)
   1. The level of impact and likelihood of occurrence for each threat scenario to determine risk
   2. Prioritize these risks in order to focus on the most important ones
3. Plan (See section 2.4)
   1. Determine mitigation strategies that should be implemented for all medium to high risk threat scenarios
4. Track (See section 2.5)
   1. Assess the effect of the application of the mitigation strategies
   2. Reassess the risks by going through steps 2 and 3 until all medium and high risk threat scenarios have been addressed
5. Document all security considerations (See section 2.6)
   1. State your security assumptions in a way that makes them clear to the reader why they are assumed
   2. State the security controls your standard has put in place and generally what risks they mitigate
   3. State any residual risks that the implementer of your standard will need to address

Resources

• HL7 gForge folder with resources http://gforge.hl7.org/gf/project/security/docman/?subdir=144
  • Tutorial Presentation on the Security Risk Assessment Cookbook Version 7.7 - September 2011
  • Tutorial Presentation on the Security Risk Assessment Cookbook Version 7.6 - November 2010
  • Formal Security Cookbook Paper Version 2.41
  • Template Spreadsheet for Risk Assessment Version 3

• IHE Equivalent Process

Do NOT use this tool :-)

Mitigation Tools

HL7 has the following Security and Privacy standards published to be used to mitigate identified risks:

• HL7 Value Sets using Code System Confidentiality (2.16.840.1.113883.5.25) -- This vocabulary is used in the confidentialityCode metadata attribute to identify the data object sensitivity and confidentiality classification. This enables both segmentation of especially sensitive topics and also Role-Based-Access-Control that protects objects for both security and privacy
• HL7 Version 3; Composite Privacy Consent Directive (CDA), DSTU Release 2 - This CDA document object captures the patient privacy preferences, authorizations, and consents. This document is used as evidence of a patient consent ceremony as well as triggers privacy policy engines to enforce the patient privacy.
• Role-Based Access Control Permission Catalog (RBAC), Release 2 - This vocabulary enables communication of users permissions in an interoperable way. This vocabulary can be used at a multitude of points in the Privacy and Security system.
• SAIF - Privacy, Access and Security Services (PASS)
  • Access Control Service – This is a service being defined for support of access control decisions and enforcement
  • Healthcare Audit Services Release 1.0 -- This service specification is available and enables security audit log recording. There are also service endpoints to enable different security and privacy audit analysis use-cases, including the creation of an accounting of disclosure.
• EHR Functional Model, Release 1 -- The EHR functional model includes a comprehensive set of security and privacy functions. This catalog includes detailed system level requirements that are actionable and testable. Profiles of this functional model are available for many functional systems including an EMR and PHR.
• HL7 Version 3 Standard: Transport Specification, MLLP, R2 -- The HL7 transport specifications include transport security (e.g. TLS)

Examples of Risk Assessment Spreadsheets

• SAML use in CCOW -- spreadsheet not yet published
  • The risk assessment was done informally and not recorded
  • The result was a statement in the formal specification that there is an unmitigated risk that the "Authenticating" application could misbehave as it is fully trusted to set the user identity correctly.
• CDA-Consent
  • First Draft 2010, July 27th
  • Second Draft 2010, Aug 3
  • Third Draft 2010, Aug 10
  • Fourth Draft 2010, Aug 31
  • Excerpt from the formal specification of the Security Considerations section
• PASS - Accounting of Disclosures Service
  • First Draft 2010, Aug 2
  • Second Draft 2010, Aug 9
  • Third Draft 2010, Aug 16
  • Excerpt from the formal specifications of part of the Security Considerations section