November 30, 2010 CBCC Conference Call

Community-Based Collaborative Care Working Group Meeting

Back to CBCC Main Page

Attendees

• Chirag Bhatt
• Mike Davis Security Co-chair
• Suzanne Gonzales-Webb CBCC Co-chair
• Michelle Johnston
• Mary Ann Juurlink
• Pat Pyette
• Richard Thoreson CBCC Co-chair
• Ioana Singureanu
• Cliff Thompson
• Serafina Versaggi

Agenda

1. (05 min) Roll call, approve minutes November 23th, call for additional agenda items & accept agenda
2. (15 min) Input requested from ONC Policy Advisory Committee (PAC) regarding PHRs and Confidentiality Codes related to NCVHS November 10 Letter to Secretary of Health and Human Services
3. (40 min) Report out
   • SHIPPS Project Status
   • CDA R2 Implementation Guide for Consent Directives - submit to TSC for DSTU publication
   • Project Insight

Minutes

1. Action Items

• Confirm DSTU publishing process with Dave Hamil e.g. TSC approval, co-Chair makes request (Ioana)
• Link Project Insight to CBCC page (Mary Ann)
• Draft response to the ONC on PHRs, the Policy Advisory Committee (PAC) (Ioana)
• Confirm implementation of Data Consent Version 1.0 in Canada (Mary Ann)

SHIPPS Project Update Status

New CBCC Work Group Project Scope Statement has been added to Project Insight, with an assigned Project #724 by David Hamil the Director of the Porject Management Office HL7.Inc

The following were contacted as part of seeking interested parties and co-sponsors. Emails were sent out to each work group that was identified in the work statement, which included Public Health and Emergency, Structure Documents, Security, Floyd Eisenberg and the National Quality Forum, Walter S Floyd Eisenberg, and the EHR WG

Interest shown from

• Clift Thompson (implementation experience with privacy, worked with HITSBY)
• Walter Suarez will be participating and be on the CBCC call as permits, he will be representing KP
• Floyd Eisenberg is interested
• Structured Document

Demo of Project Insight (Project Milestones)

• Project management Tool
• Provide Project updates
• Track milestones
• Add link to main CBCC wiki page

CDA R2 Implementation Update for Consent Directives

It is complete it is ready to go for publication. Ioana to check with Dave Hamill to see if we have to have TSC approval before publishing the DSTU. Confirm if Co Chair to make request to TSC.

ONC Policy Committee Response

As part of a response to the ONC on PHRs, the Policy Advisory Committee (PAC) Karen Van Hentenryck is seeking input on the HL7 confidentiality code set.

Draft response to email will explain what CBCC and Security have done with respect to HL7 confidential codes – explain how this supports segmentation

Input for Policy Advisory Committee - on Behalf of Community-Based Collaborative Care Work Group http://wiki.hl7.org/index.php?title=Input_for_Policy_Advisory_Committee

Confirm implementation of Data Consent Version 1.0 in Canada Posted on the Canada Health Infoway Standards Collaborative Forum

http://forums.infoway-inforoute.ca/PSCWG/Discussion%20Forum/?14@440.0YIGan4CErL.22@

3. Discussions

Target attribute

• Sensitive related data based (infoType)
• Role based (accessKind)

Deprecation, points of discussion

• Confidentially by infoType is a candidate for deprecation and confidentially by accessKind could be deprecated if you are using RBAC
• Does confidentially by accessKind make sense with role base access control (RBAC)
• Reach out to implementers using these value sets to learn more, but right now our plan is to propose confidentiality by infoType be deprecated and confidentiality by accessKind be reviewed. CBCC will take the lead at looking at the access type value sets.
• From the perspective of Security the notion of access is an appropriate one within the security context and is different than RBAC. How to pick a value set is something security is interested in from the perspective of the use within the access control system and this might help with the ontology work we are doing
• More appropriate than deprecation is to add in guidance in implementation guide that indicate there will be privacy issues if confidentiality codes exist on the outer most wrapper of a piece of information. There may be legitimate use for them elsewhere.

Relationship between sensitive based data / access according to role and policies, points of discussion

• Policy that surrounds management and workflow having to do with an access attribute is distinguished from roles in ISO 10180-3. We have existing standards for access control for example, what you say is distinguished from RBAC which has to do with user permissions
• Confidentially by access there is a code that says a nurse may access – the RBAC policy refers to the role of nurse having certain permissions – then you may have a problem. Can’t resolve this confidentiality by access type code anymore because it does not resolve to any known permissions
• There are no permissions in RBAC, a domain has to define the role of nurse – ASTM, SNOMED codes defines the role of nurse
• Differences of opinion whether we are declaring the roles e.g. does the role of nurse have specific authorization associated with it.
• Confidentiality code is only a tag on some information – it is the policy that actually that determines whether the nurse has access

Examples

• A piece of data that is tagged with a confidentiality code that says clinician – it doesn’t say you must be a clinician - the policy could be any data that is tagged with clinician can be accessed by a nurse, physician or maintenance man - that’s the policy that determines whether the maintenance man will have access to the data it’s not the tag itself
• A nurse may have to play a physician role in northern communities where physicians are not available. The category would have to be a broader definition allowing a nurse to play the role required. Which is why we write a policy – we don’t hard code these things into the role name – we have ontology of roles that describe the relationship between the roles and pick different levels as concepts

Recommendations

• We provide implementers the needed guidance regarding implications of the value sets especially on the outer envelope e.g. using confidentiality by infoType. Regarding confidentiality by accessKind the code refers to broader category of user type
• We provide guidance on what the implications are for a large range of values for confidentiality codes. What are the issues of using other codes such as HIV, substance abuse etc.
• We provide recommendation on how these value sets are to be used. In the case of confidentiality by infoType any data element would have to be deemed protected because it already tells a lot about sensitive information
• We provide a statement that there is a series privacy risks /implications with tagging records, and the policy would have to be considered carefully before using it
• We provide recommendation to distinguish between code and policy