August 23, 2011 CBCC Conference Call

Community-Based Collaborative Care Working Group Meeting

Back to CBCC Main Page

Attendees

• Ed Coyne
• Mike Davis Security co-chair
• Kathleen Connor
• Jon Farmer
• Milan Petkovic
• Richard Thoreson CBCC co-chair
• Serafina Versaggi

Agenda

1. (5 min) Roll Call & Accept Agenda
2. (50 min) Re-Factor Confidentiality Code Project update
3. (5 min) Other Business

Announcements

• Mike notified the group that the Security Work Group call is in abeyance pending transition to a new team that will support the Security and Privacy ontology project going forward.
• There is no objection however, to using the Security hour to collaborate with CBCC on the Re-factor confidentiality code project. A notification will be sent to the Security list with agenda to invite them to participate in the expanded CBCC call for the time being.
• Mike indicates that an invitation including the new LiveMeeting link should have been sent to the Security listserv and will be posted to the Security wiki soon. Until then, the joint Security/CBCC meeting will use the CBCC GoToMeeting link for the webcast.

Minutes

The Security and CBCC work group meetings focused on the continuing work related to the Re-factor confidentiality code project.

• Kathleen presented the status of the project using the Re-factor Confidentiality presentation to guide the discussion.
  • Following some rework of the Project Scope Statement with the CBCC, Security and Vocabulary workgroups, it will be reviewed by the DESD steering division on Monday night during the upcoming September Working Group meeting. Once approved, it will be forwarded to the TSC for final approval.
  • During the review of the PSS it was noted that this work must go through Harmonization activities (November 2011 cycle) before subsequent artifacts from this project can be balloted.
  • The harmonization templates (forms) need to be completed and approved by our work groups and the harmonization package submitted to the committee by 16 October.
  • During the November Harmonization meeting, someone from the CBCC/Security team will need to be present to defend the proposal.

---

---

---

---

Discussion

---

---

Key goal for this effort is to disambiguate the concepts of Confidentiality and Sensitivity.

• We want to be able to distinguish between identifying that something is considered sensitive information for use internally (within an enterprise), e.g., tagging something as related to HIV or substance abuse; and being able to separate that use from interoperability metadata that says how this information should be handled without revealing the precise sensitive nature of the information.
• To date, the analysis for the re-factor confidentiality code project fits seamlessly into the Composite Security and Privacy Domain Analysis Model DSTU and into the CDA R2 Consent Directive Implementation Guide.
  • Proposed changes to the vocabulary include specifying sender responsibilities to ensure that protected information is handled per privacy policies; and receiver responsibilities for handling protected information that the sender is authorized to disclose.

---

Mike notes that metadata tagging has become synonymous with the way metadata tagging has been defined in the recent ANPRM on Metadata Standards to Support Nationwide Electronic Health Information Exchange (45 CFR Part 170 and the December PCAST report. People already have a notion of what metadata tagging is and it has become synonymous with what appears to be the privacy policy codes being referred to in this refactoring presentation. He suggests that we define the way we are using the term metadata to avoid confusion.

• Kathleen: We are talking about metadata tagging, and changing the current HL7 Confidentiality code system. What should be the value sets for codes related to metadata tagging? The impetus for this analysis is due to the different rules governing disclosure when it comes to disclosing information outside the policy domain.
  • Where is it appropriate to use the current confidentiality code value set that is indicative of privacy policies and useful within a policy domain (currently in ConfidentialityByInfoType: HIV, ETH, PSY, SDV)? These privacy policies guide the access control system on how end users in that policy domain are able to use information tagged in a particular way.
  • How should value sets for ConfidentialityModifiers and ConfidentialityByAccessKind be used?
• Mike: The use of the term metadata tagging has been applied to the information objects in the EHR and not to the wrapper that surrounds those data during transmission. Any tag of an information object can be called metadata. Any attribute of an information object is considered to be metadata. If you want to use these terms that are currently being used in other ways, you need to define the terms with this proposal, as the terms are overloaded. Metadata is a very general term and there will be pushback if you don’t define how you are using this term.
• Kathleen: you can have metadata tags on the wrapper (part of the ITI- XDS.b) and on the payload and on sections within the payload.
  • We will be sure to include a definition to clarify our use of the term metadata, and the term metadata will apply to wrappers, payload and more granular sections within a payload.
  • Current use of the term metadata in the ANPRM is bringing this issue to into particular light. (See ANPRM Metadata Standards Discussion)

---

The latest version of the Refactor Confidentiality Codes analysis was presented

• The proposal is to be able to label the outer wrapper (akin to an envelope) with a code that tells the receiver how to handle the information, but not what is in the envelope.
• Proposed changes to the DAM include:
  • Refactoring the current Confidentiality Code System due to multiple axes that blend internal Privacy Policies with Role-based and User-based Access and interoperable confidentiality codes
  • Defines new interoperable Confidentiality Codes
  • Relocates Sensitive Information Codes to ActPrivacyPolicyType value set
  • Adds Information Subject Authorization to Disclose
    • Consent Directives - ability to specify disclosures that are more restrictive than generally applicable Jurisdictional Health Privacy Policies
    • Disclosure Authorizations - ability to specify disclosures that are less restrictive than generally applicable Jurisdictional Health Privacy Policies

---

The current confidentiality codes and their relationships are explained in slide 6 titled Current HL7 Confidentiality Code Concept Domains (the slide numbers may change based on the current version of this evolving slide deck)

1. ConfidentialityByInfoType and ConfidentialityModifiers should not have been combined in the Confidentialty concept domain. It is modeling with vocabulary.
   • They should have used the model itself and then Confidentiality would have been a class. In a separate class, you say why the class you are making confidential should be made confidential.
     • Then you point to a policy that says why you want to safeguard it.
   • For example, you could put low or restricted on a particular piece of information that you want to safeguard.
   • Think of a static class model. Here is the information object. On that information object you have an attribute that says, handle with care. Then you have another class that points to that information object class and says using that code complies with a policy. In the policy you say what kind of policy it is, 42 CRF Part II, etc.)
2. Confidentiality is a security concept. It is concerned with how information is treated, who can know and what they can do with it, and it has no necessary bearing on social values
   • ISO 7498-2:1989 - Confidentiality is the property that information is not made available or disclosed to unauthorized individuals, entities, or processes
   • Sensitivity on the other hand, is a social perception concept. How that “social” perception and resulting reaction will impact the information subject and/or owner is what defines the sensitivity of an information object.
     • ISO7498-2:1989 - Sensitivity is the characteristic of a resource which implies its value or importance and may include its vulnerability
   • Richard questioned whether we had taken a big step in terms of the definitions we have come up with here
     • Jon applauded the clear distinction between the security mechanisms (confidentiality) and sensitivity as a reflection of social values
     • The ISO definitions are a reflection of what was originally proposed in the original vocabulary harmonization proposal in 2009, and so there are not really any new terms being introduced by this project, only a way of organizing the information analysis about a well known problem that is currently receiving a lot of attention
   • Richard suggested that we make reference to the fact that these definitions are solidly referencing ISO definitions.
     • Kathleen agreed that we will include definitions for what we mean by metadata tags and we will point to the ISO definitions for Confidentiality and Sensitivity.
3. With respect to slide 5 titled Confidentiality – Sensitivity Matrix
   • It depicts that the more sensitive the information is, the higher the level of confidentiality required to access it
   • For things that are deemed Very Restricted confidentiality, these are usually ad-hoc decisions that are made due to the context of the data rather than the inherent sensitivity of the data, e.g., the celebrity/VIP that wants all their information restricted except to only those authorized to view it; or taboo – the provider decides they need to speak with the patient before the information is disclosed to anyone
   • Richard expressed concern with the idea that the Y-Axis represents jurisdictional policies and the X-Axis is related to a provider or patient’s judgment.
     • Kathleen used the matrix to help define the terms and clarified that Normal confidentiality value was only an example of jurisdictional policy (HIPAA).
     • The source that contributes to where you land on the vertical axis can come from a jurisdiction, provider, and/or patient.
   • The thought is if we could generally agree that Normal means that within an exchange ecosystem, the sender and receiver are aware of the governing laws. This way you don’t have to pre-negotiate.
   • In the ecosystem where there are applicable laws and confidentiality is Restricted, they have to get the consent, evaluate the consent, and/or get some specific organizational policy that is more restrictive than the normal usual way in which information is generally handled
     • There is also a situation where the consumer may want to allow their information to be used that is less restrictive than the Normal law allows. This is where Disclosure Authorization comes into play.
     • When a disclosure authorization is allowed by a patient/consumer, the binding contract is now between the patient and the receiver. If you want to find out what the policy is, you have to find out what the authorization says the receiver can do with the information.
4. Proposed definitions for the interoperable confidentiality codes can be found on slide 12 titled Refactored Confidentiality Codes (second slide of that title)
   • Slide 13 titled Proposed Refactoring reflects the proposal to refactor the Confidentiality codes where one aspect of the refactoring is to put the sensitivity codes so that they can become part of the Policy Act
     • In HL7, there currently exists ActClassPolicy under the ActClass concept domain. ActClassPolicy has codes that describe the type of Policy, therefore, this part of the vocabulary tree already exists.
     • In addition, the ActPolicyType value set defines the types of policies that further specify the ActClassPolicy value set, exists under the ActCode concept domain.

---

---

ANPRM Metadata Standards Discussion

---

---

A number of HL7 work groups, including the Records Management & Evidentiary Support subgroup of EHR, have been discussing the ANPRM on Metadataand plan to submit their response to HL7 HQ for consideration as part of an official response on behalf of HL7. There are some concerns raised by the ANPRM which are discussed below (Comments responding to the ANPRM are due by 23 September. The CBCC WG will devote Tuesday Q4 during the WGM to draft their response .)

---

1. Questions posed in the ANPRM reveal confusion about how wrappers, payload and more granular sections of payload use metadata. This project is attempting to address this question.
2. The response to Question 5 pertaining to Privacy Metadata Standards in the ANPRM on Metadata included recommendations on a standard set of privacy metadata comprised of the following “data elements”: a policy pointer (URL pointing to a privacy policy governing the tagged information to be disclosed), and content metadata comprised of two components: Data Type (describing the underlying data from a clinical perspective) and Sensitivity.
   • One concern is the recommendation to use the HL7 vocabulary “to indicate at a more granular level the type of underlying data to which this metadata pertains...” for the Sensitivity component of Content Metadata due to the potential misuse of some of these codes. (See User-defined Table 0177 - Confidentiality code (from HL7 Version 2) below)
3. Question 11 referred to the V3 value set called ConfidentialityByInfoType to be used as a “starter set”.
   • The problem within the response to this question is that on the one hand, it suggests the use as a possible starter set, to use the HL7 ConfidentialityByInfoType value set while at the same time, included commentary that some members of the Standards Committee raised concern about the use of these codes because “a recipient of a summary care record tagged according to these sensitivity values could make direct inferences about the data to which the metadata pertain”.
   • However, the commentary created some confusion when they referenced HL7 Vocabulary usage documentation for ConfidentialityByInfoType and ConfidentialityByAccessKind when it said “HL7 also indicates that utilizing another value set, the ConfidentialityByAccessKind set which describes privacy policies at a higher level, requires careful consideration prior to use due to the fact that some items in the code set were not appropriate to use with actual patient data”. Reference to not using the codes with patient data is in the usage notes pertain to ConfidentialityByInfoType not ConfidentialityByAccessKind.

---

---

Current HL7 Confidentiality Value Sets (referred to in ANPRM)

---

---

1. V3 ConfidentialityByInfoType
   • Definition: By information type, only for service catalog entries (multiples allowed). Not to be used with actual patient data!
     • Concept Relationships:
       • Generalizes (derived): ETH HIV PSY SDV
2. V3 ConfidentialityByAccessKind
   • Definition: By accessing subject / role and relationship based rights (These concepts are mutually exclusive, one and only one is required for a valid confidentiality coding.)
     • Concept Relationships:
       • Generalizes (derived): B D I L N R V
3. V3 ConfidentialityModifiers
   • Definition: Modifiers of role based access rights (multiple allowed)
     • Concept Relationships:
       • Generalizes (derived): C S T
4. User-defined Table 0177 - Confidentiality code (from HL7 Version 2)

---

Value	Description
V	Very Restricted
R	Restricted
U	Usual control
EMP	Employee
UWM	Unwed mother
VIP	Veryimportant person or celebrity
PSY	Psychiatric patient
AIDS	AIDS patient
HIV	HIV(+) patient
ETH	Alcohol/drug treatment patient