This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

August 23, 2011 CBCC Conference Call

From HL7Wiki
Jump to navigation Jump to search

Community-Based Collaborative Care Working Group Meeting

Back to CBCC Main Page

Attendees

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.

Action Items/Next Steps:

  • The next vocabulary harmonization meeting will is take place between Nov 15 and Nov 18
    • Change proposal submission due Oct 16
  • Next steps:
    • Complete harmonization templates for change proposals
    • Send to the group for discussion
    • Include current and proposed definitions
    • Gain consensus on definitions and proposed changes
    • Submit to Harmonization

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.
  • 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
  1. The current confidentiality codes and their relationships are explained in slide 6 (Current HL7 Confidentiality Code Concept Domains) slide numbers may change based on the version of this evolving slide deck
  2. ConfidentialityByInfoType and ConfidentialityModifiers should not have been combined in the Confidentialty concept domain. It is modeling with vocabulary.
    • Instead, use the model itself, and leave Confidentiality as an attribute on an Act or a Role class. In a separate Act Policy class, you say why the class you are designating as confidential should be handled confidentially.
      • That is point to a policy that says why you want to safeguard it. The level of confidentiality "complies with" the policy.
      • 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 an information object. On that information object you have an attribute that says, handle with care.
      • Another class points to that information object class using that code comply with a policy. In the policy you say what kind of policy it is, (e.g., 42 CRF Part II, etc.)
  3. 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.
  4. With respect to slide 5 (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.
  5. Slide 12 (Refactored Confidentiality Codes, slide 2 with that title) presents the proposed values and definitions for the new Confidentially value set
    • This presentation is supporting material for the Vocabulary Harmonization proposal and will be updated to include the current definition for the Confidentiality (Values that control disclosure of information) along with the new proposed definition for Confidentiality:
      • Defintion: The property that information is not made available or disclosed to unauthorized individuals, entities, or processes [ISO 7498-2:1989]
      • Description: The codes in the Confidentiality code system are values that control the availability and disclosure of information.
      • The confidentiality code assigned by an information sender (per policies intended by the custodian) that convey receiver obligation to ensure that the information is not made available or re-disclosure to unauthorized individuals, entities, or processes (security principals).
      • The receiver may on grant authorized principals access to the minimum necessary for the purpose of use intended by the sender. The receiver must grant principals permission to perform approved operations on the information object.
      • Very Restricted: What is it that makes this different from Restricted?
        • It is something about the context that makes it different. If it weren’t for this context, it would have a different Confidentiality code
          • These use cases don’t happen often
    • Milan: referring to the proposed new Confidentiality Code definitions, if the information is being sent Restricted, it appears this implies that the receiver has to check the consent or organizational policy.
      • Is a pointer to the policy(ies) included in the wrapper with the document? How does the receiver find the policy governing the information?
      • This was a pleasant segue to the next level of discussion. A pointer to the policy could be handled as follows:
        • The attribute Act.confidentialityCode is the CE data type Coded with Equivalents – a specialization of the Concept Descriptor CD data type.
        • CD Concept model
          • Coded with Equivalents allows you to include a code from a particular code system (e.g., value R from codeSystem Confidentiality). An additional property called translation allows you to include a local translation of that value.
          • The translation property is defined as “A set of other concept descriptors that translate this concept descriptor into other code systems”
          • Using the translation property, you could send a code system that includes the root OID of all the consent directives or privacy policy URIs in your jurisdiction as the code system.
          • That way you send both Restricted Confidentiality code and include a pointer to the consent directive that governed or said what additional restrictions had to be used to handle this information.
        • There is a danger related to this however, if the governing policy or consent directive reveals sensitive information, these have to be protected as well
          • For example, you could send a CDA within a wrapper containing Confidentiality code ‘R’ and the URI to a consent directive. If it is exchanged through an intermediary, the intermediary should not be authorized to access the Consent Directive Management System (CDMS) where the URI points, while the authorized receiver is able to access the CDMS. So you must ensure there are mechanisms to ensure privacy protection for the enclosed policies/consent directives.
          • We will check the Security & Privacy DAM to ensure the CDMS description indicates that access control isn’t open to just anyone, that you must be authorized to access a consent directive.
          • Richard noted that SAMHSA is receiving a number of questions as to how HIEs can/should handle 42 CRF Part II data
    • Mike noted that all of the proposed values for Confidentiality included on slide #12 have some sort of restriction category and wondered whether it would be useful to have a category that means no restrictions? E.g. this information is being sent without any caveat.
      • It was agreed that an additional value called Public meaning no restrictions will be added to the Confidentiality codes proposal. (interoperable)
  6. Slide 13 (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 and we use it in Consent Directive models and other places already where we want to say this Consent Directive complies with this privacy law or this privacy policy
    • The major change being proposed to the Confidentiality code system is to the value sets that refer to Sensitivity concepts
      • We suggest relocating the Sensitivity codes currently contained in the ConfidentialityByInfoType and ConfidentialityModifiers value sets to a new value set called Sensitivity which would go under ActPrivacyPolicyType, and to add ActPrivacyLaw vocabulary to reference specific privacy laws (user defined vocabulary)
      • The current Confidentiality codes can be used as an attribute on Acts or on Roles. Within the Confidentiality value sets are values that only make sense when applied to a Role versus an Act.
        • These were teased out into RoleSensitivity and ActSensitivity value sets.
        • The representative Sensitivity value set could apply to either an Act or a Role
      • These changes have no impact on earlier models which will reference current Confidentiality Code System
      • These changes have no impact on CDA which only uses Normal, Restricted, and Very Restricted
      • Future models that use ActPrivacyPolicyCodes can target classes with a Comply relationship to an ActClassPolicy
    • Note: ActPrivacyLaw enumerations are only examples. They are not intended to be representative.
      • Sensitivity enumerations are representative, but they are not required
      • The Sensitivity enumerations are not necessarily complete, but are included to show that these Confidentiality values sets have a home
  7. Mike: I'm looking at how a security system would be able to implement this in an automated way.
    • A lot has to do with the messages themselves, but this should be applicable within the organization as well as across organization. This should apply internally equally, so that the requester is an employee or even a patient. The concepts should be usable between the receiver and the owner of the information in any exchange whether internal or external.
      • The approach that we’ve taken, the ActPrivacyPolicy codes are the ones that are much like the policies that feed into the composite policies of the current DAM.
        • The privacy policies are the other side of the security policies. The composite policy of the security system is reflecting what is in the privacy policy management system.
          • It pulls in not only the privacy policies of the organization which have been reconciled with applicable jurisdiction policies (which there could be more than one), but it’s also bringing in the consent directive which represents constraints on policy, and all roll up to a composite policy which is used by an access control system to control access and use within the organization.
          • Those policies are then mapped to the interoperable Confidentiality codes so that when the information is being disclosed outside of the policy domain, that is the way the organizational policies are conveyed without saying why the information is sensitive.
          • The composite policy (only Dr. Bob can see Mary’s HIV information) is very revealing of the sensitivity of that information
          • The internal system knows about that and is able to restrict access based on that information.
          • When that information goes out the door, it will have an R – Restricted Confidentiality code on it indicating that only authorized receivers of this information can access it, and they have to comply with the subject’s Consent Directive, or they have to comply with the request not to further disclose without the subject’s Consent.
            • When you send that code, then how do you achieve and agreement that the receiver will enforce or comply with the marking on the wrapper?
              • There are a number of mechanisms being discussed to do this (Use control, Direct project - downstream recipient has to get a key to access).
          • To what extent can you avoid having privacy revealing codes traveling across the interoperability ecosystem?
    • Mike: I’d like to explore the case where the Requester – when you send the information to them, before you send it to them you must agree to follow the policy rules. You would send the information only if they agree to the policy.
      • Unsolicited receiver: receiver didn’t ask for this, but the sender wants to push information. The sender has to guess, based on maybe querying a provider directory for credentials, allowing the sender’s access control system to determine whether or not the unsolicited receiver can agre that they handle the responsibilities.
        • Included in our use case is the potential for the unsolicited receiver to decline receipt of the information
      • Mike: In HIPAA, we’re enforcing a policy that says a patient is able to say, I don’t want to share my psychiatric notes with my dermatologist.
        • What happens if the clerk is actually making the request on the part of the dermatologist?
        • Assuming that the information was Restricted, the receiving system would have to pull in the coded Consent Directive. The coded Consent Directive would tell the ACS the information to keep the dermatologist from viewing the information according to the consent directive.
        • Do any of the codes speak to the re-disclosure of information that Richard is concerned about?
          • The Confidentiality code does not dictate the re-disclosure of information. The Confidentiality code indicates whether it was restricted, and if restricted, you would have to get the consent directive, the default consent rule or the more stringent organizational policy. When you get that, it tells you what the re-disclosure rules are.
            • If you cannot get the policy associated with the Restricted information, you may not re-disclose.

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
Retrieved from "https://wiki.hl7.org/w/index.php?title=August_23,_2011_CBCC_Conference_Call&oldid=53825"