July 27th CBCC Conference Call

Community-Based Collaborative Care Working Group Meeting

Back to CBCC Main Page

Attendees

• Robert Horn
• Rob McClure
• John Moehrke Security Co-chair
• Milan Petkovic
• Kenneth Salyards
• Richard Thoreson CBCC Co-chair
• Serafina Versaggi scribe

Agenda

1. (05 min) Roll Call, Call for additional agenda items & Accept Agenda.
2. (55 min) Cookbook for Security Considerations
   • We will apply the Security Cookbook to the CDA R2 Implementation Guide for Consent Directives

• Ongoing Projects
• Privacy Policy Reference Catalog
  • Pat Pyette will provide a brief status update on the project on August 10th

Minutes

1. Action Items

• Team: Please review the Security Cookbook prior to today's meeting

3. Updates/Discussion

• Today’s call focused on using the HL7 Security Cookbook to conduct a security risk assessment for the CDA R2 Implementation Guide for Consent Directives.

Background

• The CBCC Work Group is one three work groups selected to pilot and help to refine the security risk assessment process using the CDA IG project.
  • These pilot projects will be used to provide other HL7 work group committees with examples that will aid in the development of their own security risk assessment
• The goal for the Security Cookbook is to ensure that every working group takes security and privacy considerations into account during the normal HL7 standards development process.
• On the Security Cookbook wiki page, there are a number of resources which provide background on the process:
  • Draft tutorial.
  • Security Cookbook – formal paper
  • template – used to conduct the risk analysis
• These resources are intended to provide any HL7 committee with materials to help them conduct their own security risk analysis without assistance from anyone involved in the development of the process (authors of the formal paper)
• The tutorial will be presented at the Plenary HL7 Working Group Meeting in October on Thursday morning.
  • Please encourage folks to sign up for this presentation if you think they may need some guidance.
  • The only other scheduled activity for this time slot is the HL7 Certification exams
• Dealing with security is an iterative process.
  • Security aspects that are built into early parts of the development cycle need to be known that they’re there for specific reasons when that standard is implemented or when it is being revised
• Often times in HL7 standards:
  • There is little recognition of the security required (security assumed to be handled somewhere else)
  • Security mechanisms are removed during revision of the standard because the risk that caused the security mechanism to be added in the first place was not documented (and the risk may still be present)
• The importance of using a risk model is to focus attention on issues most important to deal with and to spend less time on issues that have a lesser impact.
• There are two aspects to Risk:

1. What is the impact of a particular risk (harm that can be done)
2. What is the likelihood (probability) that the risk will occur
   • Probability X Impact = Risk

• The draft tutorial explains Risk as “The potential that a given threat will exploit vulnerabilities of an asset or group of assets and thereby cause harm to the organization”
  • Threat X Vulnerability = Risk (per the presentation)
• Richard questioned the use of some of the terms in the presentation:
  • Threat, probability and vulnerability - how do these terms relate to impact and probability?
  • John: The diagram in the presentation isn’t using the same terminology as the Security paper which uses impact and likelihood. Threat and vulnerability are terms extracted from ISO 13335-1 and we may have decided that we were not at liberty to re-label these terms.
    • Impact of a threat and the likelihood that that threat will be taken advantage of is the vulnerability
    • Vulnerability is equivalent to probability, whereas threat is equivalent to the impact
• Rob Horn suggested these terms be clarified for the Security Cookbook audience
  • People who are going to read the Security Cookbook and this tutorial more than likely have not read the ISO document, so as long as the terms are consistent across the documents, it really doesn’t matter
• John will update the presentation for the Boston tutorial to further clarify the difference between the definitions for Vulnerability, Threat and Exploit.
• John then went on to cover the Five Stages of the HL7 Risk Assessment Process (iterative).
  • These stages represent what can be done in the standard to address the identified risks that the standard presents
  • A security risk assessment can result in the need for a change to the standard. Those changes need to be tracked and documented.

1. Identify
   • Clearly define the scope of the standard, including baseline assumptions
   • New threat scenarios and describe the type of impact that scenario implies
2. Analyze
   • The level of impact and likelihood of occurrence for each threat scenario to determine risk
   • Prioritize these risks in order to focus on the most important ones
3. Plan (for mitigation)
   • Determine mitigation strategies that should be implemented for all medium to high risk threat scenarios.
   • It was pointed out that mitigation strategies themselves may introduce new risks which then need to be analyzed as well. The risks should be lesser than the original risks hopefully
4. Track
   • Assess the effect of the application of the mitigation strategies
   • 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. This includes updating the standard to address the risk(s)

• This is an experiment in taking a risk assessment methodology that is usually applied at an operational level and trying to make it fit into a standards development environment.
  • This is somewhat unnatural, but we’re going to try to see how we can make it work.

Process applied to this project (CDA Implementation Guide)

• We began walking through the risk assessment process filling in the template spreadsheet
• The template included on the Security Cookbook wiki page will be updated to include three worksheets:

1. Scope and Baseline (assumptions)
2. Risk Assessment
3. Parking Lot Risks

• Step #1: Define the scope and baseline assumptions using a brainstorming exercise:
  • Scope: This risk assessment covers the CDA R2 Implementation Guide for Consent Directives
    • Part of scoping the risk assessment is being explicit about documenting the assumptions that are made when identifying the scope
  • Assumptions:
    • The scope is bounded by how we’ve assembled the parts that are included in a CDA (Release 2) document that carries a Consent
    • This assessment will not identify or cover any generic risks inherent in CDA Release 2 (that applies to any implementation guide for CDA
    • We are not defining generic risks with RBAC vocabulary
    • We presume that the transport is any transport for any CDA document because we haven’t explicitly indicated any particular transport mechanism in this implementation guide
    • Other assumptions that can be included are: specific vocabularies, physical environment restriction, etc.
    • If something is called out in the standard undergoing risk assessment that poses potential risk, it should be identified in the assumptions (for example, electronic signatures cannot be captured in CDA R2 documents, but the CDA R2 Implementation Guide for Consent Directives supports the ability to include a reference to an external digital signature using RIM-based extensions).
• We then moved to the Risk Assessment worksheet to capture the risks identified in the brainstorming process:
  • How to identify the items that a consent specifies as important for differentiating access versus information that is readily available within the object that is being considered for access. This falls into two general categories:

1. Things that are knowable without any new work (e.g., who create it, when it was created, etc.) This makes it easy to say that I consent to give access to anyone that was generated by this hospital on this date, versus
2. Things that require some knowledge about the object - don’t share my HIV information with anyone
   • The first (things that are already knowable) is a relevant risk, but not specific to this CDA implementation guide
   • The HL7 confidentialityCode is used in two ways within the context of this CDA document (for Consent Directives)
     • The confidentialityCode that is used to identify the confidentiality of the CDA consent document instance itself.
     • This is a risk that is inherent in all CDA documents
   • The risk we need to capture in this risk assessment is that confidentialityCode is used to describe the concept of sensitivity but has not been well enough identified in the confidentialtyCode value set to support the data segmentation required to support “confidentiality/sensitivity” of the data being referred to by the Consent Directive
   • We will have to ask Ioana how this was encoded in the Consent Directive implementation guide. I’m not sure that we have a way in this revision to specify restriction at the level of something like HIV data.
   • There was a question as to whether we scoped this out of this version of the consent directive guide
   • John thought that we ended up with something close to BPPC with a few additional attributes that were deterministic
   • We will follow up next week on this issue when Ioana is on the call
   • The best way to summarize this issue:
     • Richard: We may not have done a good enough job of identifying the content of the record that we want to protect. This may be a risk.
     • Rob: Another way to say this is that we haven’t yet fleshed out how to align the level of detail of a consent with information that we can know about data objects
     • “The object that we want to protect may not be specifically identified well enough to be protected (templates for categorizing the other objects)”

• We continued to brainstorm ideas and captured them without getting bogged down in analyzing them. The identified risks will be discussed further during the analysis phase of the process
  • Some of the risks identified during this brainstorming session brought to light that under ideal conditions, the security risk assessment would be conducted during the initial draft of a standard.
    • Under those ideal conditions, the security risk analysis would take place prior to going to ballot.
    • Risks that are identified after a standard goes to ballot may require re-work of the standard
  • The expectation is that this process will eventually become part of the HL7 standards development process.
    • One of the major goals of the pilot security risk assessment exercises is to establish the criteria to help the HL7 Project Services folks build the security risk assessment process into the HL7 standards development process e.g., how long does the process take, etc.
    • This will be built into the ballot process time line
• There are a few ways that risks will flow from the assessment process:

1. Risks can introduce changes to the existing standard
2. Risks may be turfed to other work groups or areas that will handle the risk
3. Risks can lead to new projects or new work item requests to the Security Work Group

NextSteps:

• The spreadsheet updated during today’s brainstorming session will be posted on GForge and distributed to the work group members via the list serv along with these minutes.
• Team: Please familiarize yourself with the Security Cookbook resource materials, the CDA R2 Implementation Guide for Consent Directives and the updated Security Risk Assessment spreadsheet from today prior to next week’s call when we will continue the risk analysis process.
• We then will validate that these are truly problems and that the standard does not deal with the identified risks, for those that are risks, come up with the likelihood and impact for the risks, and go through the rest of the process steps in the cookbook.

---

Meeting was adjourned at 3:05 PM EDT No significant decisions or motions were made

---

Back to CBCC Main Page