Difference between revisions of "November 30, 2010 CBCC Conference Call"
Finaversaggi (talk | contribs) m (→Attendees) |
|||
(9 intermediate revisions by 2 users not shown) | |||
Line 12: | Line 12: | ||
* [mailto:gonzaleswebs@saic.com Suzanne Gonzales-Webb] CBCC Co-chair | * [mailto:gonzaleswebs@saic.com Suzanne Gonzales-Webb] CBCC Co-chair | ||
* [mailto:Michelle.Johnston2@va.gov Michelle Johnston] | * [mailto:Michelle.Johnston2@va.gov Michelle Johnston] | ||
− | * [mailto:MaryAnn@eversolve.com Mary Ann Juurlink] | + | * [mailto:MaryAnn@eversolve.com Mary Ann Juurlink] Scribe |
* [mailto:ppyette@perimind.com Pat Pyette] | * [mailto:ppyette@perimind.com Pat Pyette] | ||
* [mailto:richard.thoreson@samhsa.hhs.gov Richard Thoreson] '''CBCC Co-chair''' | * [mailto:richard.thoreson@samhsa.hhs.gov Richard Thoreson] '''CBCC Co-chair''' | ||
Line 38: | Line 38: | ||
== SHIPPS Project Update Status == | == SHIPPS Project Update Status == | ||
− | New CBCC Work Group Project Scope Statement has been added to Project Insight, with an assigned Project #724 by David | + | New CBCC Work Group Project Scope Statement has been added to Project Insight, with an assigned Project #724 by David Hamill the Director of the Project 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, | + | 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, Structured Documents, Security, Floyd Eisenberg and the National Quality Forum, Walter Suarez and the EHR WG |
'''Interest shown from''' | '''Interest shown from''' | ||
− | * | + | *Cliff Thompson (implementation experience with privacy, worked with HITSP) |
− | *Walter Suarez will be participating and be on the CBCC call as permits, he will be representing | + | *Walter Suarez will be participating and be on the CBCC call as permits, he will be representing Kaiser Permanente |
*Floyd Eisenberg is interested | *Floyd Eisenberg is interested | ||
− | *Structured | + | *Structured Documents WG |
'''Demo of Project Insight (Project Milestones)''' | '''Demo of Project Insight (Project Milestones)''' | ||
− | *Project | + | *Project Management Tool |
*Provide Project updates | *Provide Project updates | ||
*Track milestones | *Track milestones | ||
Line 62: | Line 62: | ||
Draft response to email will explain what CBCC and Security have done with respect to HL7 confidential codes – explain how this supports segmentation | 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 '''Input for Policy Advisory Committee - on Behalf of Community-Based Collaborative Care Work Group'''] |
− | |||
− | '''Confirm implementation of Data Consent Version 1.0 in Canada''' | + | [http://forums.infoway-inforoute.ca/PSCWG/Discussion%20Forum/?14@440.0YIGan4CErL.22@ '''Confirm implementation of Data Consent Version 1.0 in Canada''' ] |
− | Posted on the Canada Health Infoway Standards Collaborative Forum | + | *Posted on the Canada Health Infoway Standards Collaborative Forum |
− | |||
===3. Discussions=== | ===3. Discussions=== | ||
+ | '''Target attribute''' | ||
+ | *Sensitive related data based (ConfidentialityByInfoType) | ||
+ | *Role based (ConfidentialityByAccessKind) | ||
+ | '''Deprecation, points of discussion''' | ||
+ | *ConfidentialityByInfoTypeis a candidate for deprecation and ConfidentialityByAccessKind could be deprecated if you are using RBAC | ||
+ | *Does ConfidentialityByAccessKind 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 ConfidentialityByInfoType be deprecated and ConfidentialityByAccessKind 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 guidance in implementation guide that indicates 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, which is distinguished from RBAC and has to do with user permissions | ||
+ | *ConfidentialityByAccessKind: there is a code that says a nurse may access – and if the RBAC policy refers to the role of nurse having certain permissions – then we may have a problem. | ||
+ | *A concerned raised is that we can’t resolve ConfidentialityByAccessKind 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 – ASTM1986 (SNOMED-CT) codes define 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 ConfidentialityByInfoType. Regarding ConfidentialityByAccessKind the code refers to broader category of user types | ||
+ | *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 ConfidentialityByInfoType any data element would have to be deemed protected because it already tells a lot about sensitive information | ||
+ | *We provide a statement that there are serious privacy risks /implications associated with tagging records, and the policy would have to be considered carefully before using it | ||
+ | *We provide recommendation to distinguish between code and policy | ||
+ | |||
+ | |||
+ | Meeting was adjourned at 2:57 PM Eastern |
Latest revision as of 16:22, 7 December 2010
Community-Based Collaborative Care Working Group Meeting
Meeting Information
Attendees
- Chirag Bhatt
- Mike Davis Security Co-chair
- Suzanne Gonzales-Webb CBCC Co-chair
- Michelle Johnston
- Mary Ann Juurlink Scribe
- Pat Pyette
- Richard Thoreson CBCC Co-chair
- Ioana Singureanu
- Cliff Thompson
- Serafina Versaggi
Agenda
- (05 min) Roll call, approve minutes November 23th, call for additional agenda items & accept agenda
- (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
- (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)
2. Updates
SHIPPS Project Update Status
New CBCC Work Group Project Scope Statement has been added to Project Insight, with an assigned Project #724 by David Hamill the Director of the Project 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, Structured Documents, Security, Floyd Eisenberg and the National Quality Forum, Walter Suarez and the EHR WG
Interest shown from
- Cliff Thompson (implementation experience with privacy, worked with HITSP)
- Walter Suarez will be participating and be on the CBCC call as permits, he will be representing Kaiser Permanente
- Floyd Eisenberg is interested
- Structured Documents WG
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
Confirm implementation of Data Consent Version 1.0 in Canada
- Posted on the Canada Health Infoway Standards Collaborative Forum
3. Discussions
Target attribute
- Sensitive related data based (ConfidentialityByInfoType)
- Role based (ConfidentialityByAccessKind)
Deprecation, points of discussion
- ConfidentialityByInfoTypeis a candidate for deprecation and ConfidentialityByAccessKind could be deprecated if you are using RBAC
- Does ConfidentialityByAccessKind 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 ConfidentialityByInfoType be deprecated and ConfidentialityByAccessKind 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 guidance in implementation guide that indicates 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, which is distinguished from RBAC and has to do with user permissions
- ConfidentialityByAccessKind: there is a code that says a nurse may access – and if the RBAC policy refers to the role of nurse having certain permissions – then we may have a problem.
- A concerned raised is that we can’t resolve ConfidentialityByAccessKind 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 – ASTM1986 (SNOMED-CT) codes define 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 ConfidentialityByInfoType. Regarding ConfidentialityByAccessKind the code refers to broader category of user types
- 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 ConfidentialityByInfoType any data element would have to be deemed protected because it already tells a lot about sensitive information
- We provide a statement that there are serious privacy risks /implications associated with tagging records, and the policy would have to be considered carefully before using it
- We provide recommendation to distinguish between code and policy
Meeting was adjourned at 2:57 PM Eastern