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

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.

Data Quality

• The same sort of structured data may be used to determine the quality of care if all data is encoded and structured.
• Underlying data quality will give you both privacy and the ability to measure outcomes.
• Standard held up to assess quality of care for diabetes, clinical data model of sorts, consensus of attributes of care that are necessary to make a standardized assessment of the quality of care
• More inclined to talk about the cost effectiveness of care. The idea is we are looking at the quality semantic health information performance standards. Do we have the information we need?
• The measurement of interest has to be encoded in a coherent and aggregately big and as small as possible list of attributes. Each attribute has one or more vocabularies you can put on it.
• Policy for privacy security could say you can use my information to study diabetes not genomics which would be automated.
• What other data is required to determine quality – look at this at a domain by domain basis e.g. behavioral health
• Scope statement based on particular conditions e.g. diabetes. Process, structure for analysis.
• Domain specific elements, core to all data health conditions.
• Challenge is Providers / vendors being asked to provide segmentation in the absence of context missing e.g. what information in which category, not immediately available. Expected end result questions
  • What data attributes are required?
  • What business rules are required?
  • What EHR functions are required?
• Disconnect in segmentation – no support for the entire stack e.g. consent infrastructure function -no way- for someone to enter consent directive there is not way to enter patient directive from a patient, no supportative to collect the data. Collection manually using a form but not required. People are supposed to support segmentation but the entire stack is not supported. Intermediary steps missing.
• SOA call – looking for the next project – proposed end-to-end workflow view that would provide a handle to put all those things together – consent managed, approved, instantiated into a system that is enforced in a system.
• Defining properties of data so that we can understand a relationship between
  • Content
  • Purpose of use
  • Context
• Vocabulary has not been done to fill all these dimensions
• Detailed Clinical Models (DCM) – need to define primary and secondary coding systems for all coded data elements
• Mapping to well understood security privacy practices e.g. compartmentalization
• This is HL7 International standards organization and we need to understand that segmentation is a US realm construct and we haven’t established that there are no existing security privacy standards that address the concept of segmentation. There probably are. Segmentation may be another word for data classification, confidentially code, ‘talking about the same thing’. We need to find out is there a gap that needs to be addressed?
• There will be granularity differences e.g. different dimensions make up quality of the data. Currently different properties of the data are collapsed into a single attribute which is inadequate and does not represent true meaning.
• Data segmentation is required from everyone, Bring in clarity, not trying to invent something new, build on what Walter Suarez is doing with NCVHS and bring in the standards that apply
• Leverage what we have done to identify what are the properties required for segmentation and sequestering data based on specific policies:
• Data has to be ready for processing – leads to better outcomes
• Need to have policies expressed in such that we don’t have to maintain unwieldy relationship between SNOMED codes and specific data elements but we can compute the rules by which certain data elements can be forever sequestered because they are not to be shared with anyone vs data that may be shared in certain situations.
• We have an opportunity to standardized functional requirement as well.

• We could move beyond the implementation for privacy security protection move to a higher level e.g. we have 2 competing objectives – how to balance individual and community or improving quality of care for greater public good. By waiving privacy will allow the means to share information for public health.
• Information driven by policy goals e.g. controlling cost for treatment of chronic diabetes e.g. need access control to certain pieces of information within the record in order to be able to draw conclusion about the quality of care of cost effectiveness of care. Segmentation is a key part to decide what the policies are.

Process for Risk Assessment

• Risk assessment cookbook is a process that we expect all HL7 domains to use when they are planning to define data to do a risk assessment, intended to be inclusive of privacy and security risks. The process can be used here and the catalogue of risks could be enhanced.
• Risk assessment cookbook intended to assess all kinds of risks including security
• Quality measures ‘is the use case’ you analyze, and Richard is raising risks that a use case introduces which is suppose to be recorded in the risk assessment and is supposed to be analyzed regarding the impact and the likelihood mitigated and reanalyzed impact etc..
• We have not discussed risk and risk assessment process yet when get there we will require more guidance
• We are talking about data attributes for quality measures is not the same in the information model required for enforcing security privacy policy
• Business line of health care vertical looking at quality of care not looking at risk issues associated with quality of care.

EHR Functional Model

• The need for a standardized way in capturing consent directives – the EHR functional model is loud about enforcing consent directives but no mechanism on how to capture the information. We expect patients to enter this in a PHR but in an EHR it has to be entered on patient’s behalf as they have no account. It was pointed out that the EHR functional model is relatively new and a mechanism on how to capture consent directive needs to be added. We can add value.
• How does a mechanism for capturing a consent directive get into a product? It was pointed out that there are applications with a sole purpose of capturing consent, and are capable of getting a consent registered. The EHR only needs to enforce it.
• A mechanism for capturing consent needs to be standardized for HL7 purposes. It was pointed out that we have completed a CDA consent ballot, and we do have consent directives.

Data Segmentation Definition

• Walter Suarez definition / categories of segmentation / sequestration
• Definition of segmentation as it applies to security privacy policies and how that would be enforced e.g. attributes of data objects.
• Security clearly has the notion of segmentation typically security policy provide for data compartmentalization and groupings that are to be protected and handled in the same way. The policies that provide / define the protections to be applied to each segment / compartment of information.

Scope Statement Considerations

• Clarification of terms e.g. segmentation
• How is data encoded and structured
• We need to know a lot about the data
• What do the rules look like
• Expand extend standards to provide clear coding system information
• Quality of data (not unstructured data)
• Policy ontology
• Policy have to specified access control to some data
• Focus on specific conditions

Deliverable Concepts

• Quality data
• Value checklist
• Different stakeholders groups
• Integrated relationships of all levels
• Process or structure for analysis
• Core data for all health condition
• Quality measures
• Catalogue of risk