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

Difference between revisions of "November 30, 2010 CBCC Conference Call"

From HL7Wiki
Jump to navigation Jump to search
 
(7 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 Hamil the Director of the Porject Management Office HL7.Inc
+
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, Structure Documents, Security, Floyd Eisenberg and the National Quality Forum, Walter S Floyd Eisenberg, and the EHR WG  
+
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'''
*Clift Thompson (implementation experience with privacy, worked with HITSBY)  
+
*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 KP
+
*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 Document
+
*Structured Documents WG
  
 
'''Demo of Project Insight (Project Milestones)'''
 
'''Demo of Project Insight (Project Milestones)'''
*Project management Tool
+
*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''']
http://wiki.hl7.org/index.php?title=Input_for_Policy_Advisory_Committee
 
  
'''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
  
http://forums.infoway-inforoute.ca/PSCWG/Discussion%20Forum/?14@440.0YIGan4CErL.22@
 
 
===3. Discussions===
 
===3. Discussions===
 
'''Target attribute'''
 
'''Target attribute'''
*Sensitive related data based (infoType)
+
*Sensitive related data based (ConfidentialityByInfoType)
*Role based (accessKind)
+
*Role based (ConfidentialityByAccessKind)
 
'''Deprecation, points of discussion'''
 
'''Deprecation, points of discussion'''
*Confidentially by infoType is a candidate for deprecation and confidentially by accessKind could be deprecated if you are using RBAC
+
*ConfidentialityByInfoTypeis a candidate for deprecation and ConfidentialityByAccessKind could be deprecated if you are using RBAC
*Does confidentially by accessKind make sense with role base access control (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 confidentiality by infoType be deprecated and confidentiality by accessKind be reviewed.  CBCC will take the lead at looking at the access type value sets.   
+
*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
+
*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.
+
*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'''
 
'''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  
 
*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  
*Confidentially by access 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.   
+
*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 this confidentiality by access type code anymore because it does not resolve to any known permissions
+
*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 – ASTM, SNOMED codes defines the role of nurse
+
*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.   
 
*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
 
*Confidentiality code is only a tag on some information – it is the policy that actually that determines whether the nurse has access
Line 91: Line 89:
 
*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
 
*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'''
 
'''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 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 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 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 is a series privacy risks /implications with tagging records, and the policy would have to be considered carefully before using it
+
*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
 
*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

Back to CBCC Main Page

Meeting Information

Attendees

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)

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