November 9, 2010 CBCC Conference Call

Community-Based Collaborative Care Working Group Meeting

Back to CBCC Main Page

Attendees

• Bill Braithwaite, MD
• Mike Davis Security Co-chair
• Jon Farmer
• Suzanne Gonzales-Webb CBCC Co-chair
• Mary Ann Juurlink Scribe
• John Moehrke Security Co-chair
• Milan Petkovic
• Ioana Singureanu
• Richard Thoreson CBCC Co-chair
• Serafina Versaggi
• Tony Weida
• Craig Winter

Agenda

1. (05 min) Roll call, approve minutes November 2nd, call for additional agenda items & accept agenda
2. (55 min) Continue new project proposal discussion - Semantic Health Information Performance Standards, revised draft 11/1/2010

Minutes

1. Action Items

Scope Statement to present to attendees

3. Updates/Discussion

Back to CBCC Main Page

The CBCC call November 09, 2010 started by defining data segmentation and different levels of segmentation. The information provided on this call will be used to draft a project scope statement and will be presented at the November 16, 2010 call.

The term ‘segmentation’ is thrown around a lot. The term seemingly has come out of no-where but the delineation or separating data is not new. Walter Suarez notes that National Committee on Vital and Health Statistics (NCVHS) is currently defining the meaning of segmentation and how to promote security in the sharing of information from electronic health record systems. The Security and CBCC work groups have an opportunity to define the technical parameters / standards necessary to support the concept of data segmentation.

Data Segmentation Considerations

• There is a need to embargo specific protected data based on certain privacy policy.
• Currently there is no technical specification for what the segmented data could look like.
• What are the prerequisite for data segmentation?
• We need to identify data element as protected / unprotected, embargo / un-embargo.
• What properties should the information have?

First Level considerations:

• Data level quality. Privacy policy could have clever business rules, however if all the data is unstructured there is little that can be done with it to delineate into protected / unprotected data.

Second level considerations:

• Privacy policies and data. Privacy policies are often in English but not encoded. Therefore specific elements of privacy policies could be carefully crafted to describe how business rules apply to the data? We’ve discussed this previously but have never put it on paper. We could further elaborate business rules as part of this project.

• What are the characteristics of a security object? ISO attempts to define additional properties of the data that makes it computable in the context of a privacy security policy.
• If the data lacks a certain quality (narrative in nature only) the whole health record will need to be embargoed. If the data is structured content that is encoded using standards, the data can be parsed identifying data segmentations.
• Security attributes in the sense of a security submission with request for data, based on authorization, authentication and data segmentation - some properties will have to identify specific elements of the medical record that will disclose or be requested for disclosure
• Each one element is some kind of security object? Yes in the sense that security objects are used to control real data objects. The question is what do the data elements have to carry and in such a way that data can be operated on automatically? Automation is the trick
• Connecting the dots; data needs to tie into the data segmentation concept with other security privacy best practices. We need to look at how this relates to security objects, to privacy policies, information reference properties.
• Emphasize a broader social economic policy, quality improvement policy context
• Once the data is defined as a certain type, the application of security policy can decide what information to disclose or not disclose due to certain scenarios based on security attributes.