December 7, 2010 CBCC Conference Call

Community-Based Collaborative Care Working Group Meeting

Back to CBCC Main Page

Attendees

• Mike Davis Security Co-chair
• Jon Farmer
• Suzanne Gonzales-Webb CBCC Co-chair
• Michelle Johnston
• Mary Ann Juurlink scribe
• Jim Kretz
• Rob McClure
• John Moehrke Security Co-chair
• Milan Petkovic
• Diana Proud-Madruga
• Pat Pyette
• Richard Thoreson CBCC Co-chair
• Ioana Singureanu
• Serafina Versaggi
• Tony Weida
• Craig Winter

Agenda

1. (05 min) Roll call, approve minutes November 30th, call for additional agenda items & accept agenda
2. (55 min) Report out
   • CBCC WG Input for Policy Advisory Committee - forwarded to HL7 HQ for submission by December 10th deadline
   • CDA R2 Implementation Guide for Consent Directives - submit to TSC for DSTU publication
   • SHIPPS Project Status
     • December 9th Structure Documents Work Group Meeting
     • Project Insight - milestones added to project plan

Minutes

1. Action Items

Action item: Milestones laid out in Project Insight (Mary Ann)

Action item: Email regarding new HIT Policy Quality Measures workgroup to be sent to list (Serafina)

Action item: Review Mike’s mapping specifically the DAM attributes that relate to privacy (Pat)

Action item: Provide link to standards document as sample for privacy analysis (Suzanne)

ONC Policy Committee Response

• Ioana created a response for Karen Van Hentenryck regarding the HL7 confidentiality code set. This was posted on GForge CBCC as well notification sent to appropriate lists for comments. Comments were received and the response updated with an official CBCC copy sent to Karen on Monday 06, 2010. The CBCC response is to become part of the submission to the ONC Policy Advisory Committee.

• Question regarding Canadian implementation of the ‘Data Consent Version 1.0’ was posted by Mary Ann on the Infoway Standards Collaborative Privacy and Security Forum. Pat provided a link to the DSQ pilot implementation in Quebec which has implemented a combination of Data Consent V1.0 and custom messages. Consent Directives Management System Quebec approach October 2008 [ http://forums.infoway-inforoute.ca/webx?293@@.eefb19c] Basically;
  • The genesis of consent directives stem from the original work with the pharmacy CeRx standard
  • Implementation of consent is rudimentary e.g. mostly has to do with confidentiality, which is not a complete solution for consent within the Canadian jurisdictions
  • Consent process in Quebec – I want to restrict access
  • The pharmacy CeRx solution does not meet jurisdictional consent requirements fully.

CDA R2 Implementation Update for Consent Directives

Last week’s discussion has an Action item for security – having to do with leading work on the confidentialitybyaccessKind value set. This was dropped by the end of last week’s meeting as it was decided to provide guidance with respect to the confidentiality code set in the implementation guides.

A comment was made that there is a dislike for the value set as it is inconsistent e.g. seems to be 2 different value sets crunched together. Tackled before but gave up on it.

SHIPPS Project

eMeasures to be presented at the Structured Documents meeting December 09, 2010. This is being co-sponsored by Structured Documents, NQF and Clinical Decision Support. As well on the agenda the SHIPPS Scope Statement, which will be presented by Richard. This is an opportunity to see the relationship between the 2 projects, eMeasures and SHIPPS. Seemingly the SHIPPS project is the Foundation for a meaningful implementation of eMeasures.

• All projects will have to segment records, e.g. there is a lot of reason to segment records (privacy, enabling security, quality reporting) in order to automate the ability to perform reporting from EHR data.
• The purpose of the upcoming meeting is to understand the potential for collaboration with the Structure Document folks and to see if they are interested to sign on as an interested party or a co-sponsor for the SHIPPS project.
• 2 Specifications based on document architecture both DSTU
  • HQFM eMeasures - encoding measures (pending changes to be made to the RIM)
  • QRDF – reporting quality (currently only patient centric reporting capacity vs population centric)
• SHIPPS will be taking eMeasures further than current DSTU

• Action item: Project Insight: milestones laid out in Project Insight in order to demonstrate the approach we are taking with analyzing the current behavioral health quality measures from HEDIS and NQF initially.

• Email regarding new HIT Policy Quality Measures workgroup that has been formed looking for input for quality measures for stage 1 and 2 meaningful use by 23rd Sept. Measure concept list we can track for our analysis and perhaps provide input as well. Serafina to send out link to list.

Continuing from the Security Call – Glossary Definitions

In order to create consistency and accomplish precision around the terms that security is using for the DAM, Mike conducted a gap analysis. This is not considered authoritative; it also includes gaps that exist. Gap analysis:

• The security ontology class attributes (security policy indicated in ISO 15816) and
• Security DAM class attributes

The outcome of the analysis is an Information Reference Document

• Definitions
• Security and Privacy Policy Ontology Class Attributes

For this call Mike is only presenting the definitions. The genesis of definitions is generally from ISO or ITU standards. His analysis looked at security ontology class attributes and the aspects of a security policy that are indicated in ISO 15816 and how it relates to; information objects, information object classes, object fields in the DAM Class.Attribute. We don’t have to reinvent the wheel these standard definitions address core things e.g. when we talk about an information model – what is a security information object, what are the fields / attributes etc. The purpose is to nail down definitions related to the information model that are not in the DAM itself.

Examples of the 11 core Security Policy Attribute Elements mapped to DAM Class.Attribute analysis:

• Level of protection assigned to the data stored on a system equivalent to the Sensitivity.SensitivityByInfoType or Sensitivity.SensitivityModifier

• Regarding methods of authenticating entities; we don’t really have a class in the information model. It is listed as a precondition without much discussion. Specific methods include one, two or three factor type methods or possibility could be considered as part of AuthorizationPolicy.levelOfAssurance. In terms of a SAML type authentication assertion it would typically be information about a method that was used to authenticate an entity, and a policy for access might require that information. It might say that you have to authenticate with PKI or biometrics. Access would be denied if you couldn’t do it. This might be a gap, we said it was a precondition but it might be a policy attribute.

• Whether preventing repudiation of receipt of an object by recipients is required was not addressed. This is a gap in the Security DAM.

These definitios are pretty good in meeting the core policy contexts, might be a couple of gaps that the next version of the DAM might want to address. We might want to address vocabulary for attributes that we called out that we have a class but we don’t have what the policy attributes should be.

Mike is working on a project that is identifying ISO standards attributes and class definitions and reminded CBCC people that he has a request that we review the privacy classes in particular. CBCC is to look at the DAM privacy objects and identify the ISO standards – either define the class or provide further information or attributes that would belong to that class or a note that nothing exists that is might be a domain specific thing e.g. we wouldn’t expect to find an ISO standard for it.

Once CBCC has reviewed the privacy classes, Security can further the ontology work at the concept level using ISO standards or how it is being done for RBAC e.g. using the HL7 definitions. It is perfectly legal to put in a HL7 standard here e.g. confidentially code by access type.

Pat took action item to do review on behalf of CBCC

CBCC approach should be user friendly linking classes. Provide an enumerated list based on attributes and standards together basically a listing on privacy class and the object of the exercise is to identify an ISO or HL7 standards that clarifies the class or provides definition for class attributes. Mike is not looking for a value set that is domain specific he wants it at a higher level. We are not looking for a realm specific value sets, instead keep it general – specific codes sets are up to realms to define we are looking at classes. The set of concepts would be universal even if they are coded on realm specific bases. Also if nothing exists this is also good information.

Suzanne to provide link to standards document as sample

This is the first good step by establishing a sound foundation for class attributes based on standards than we in the US can define codes sets that we would need for segmentation purposes. There are 2 ISO standards 29100 and 29101 that identify a privacy framework out of SC27 which is generalized privacy framework and privacy architectures. It was agreed that these are good sources to start with even though not balloted.

Meeting was adjourned at 3:00 PM Eastern