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

Difference between revisions of "February 01, 2011 CBCC Conference Call"

From HL7Wiki
Jump to navigation Jump to search
Line 66: Line 66:
== EHR working call at 4 p.m. EST.  Richard to present SHIPPS ==
== EHR working call at 4 p.m. EST.  Richard to present SHIPPS ==
'''Maturity of Health Information and President’s Council of Advisors on Science and Technology (PCAST)'''
'''Maturity of Health Information and President’s Council of Advisors on Science and Technology (PCAST)'''
* PCAST Health IT report calls for Meta data tagged information.  This fits in the continuum of a higher level of maturity of Health data and would enable secondary uses of information including automating privacy and security policy and quality measure  
* PCAST Health IT report calls for Meta data tagged information.  This fits in the continuum of a higher level of maturity of Health data and would enable secondary uses of information including automating privacy and security policy and quality measure  

Revision as of 19:29, 7 February 2011

Community-Based Collaborative Care Working Group Meeting

Back to CBCC Main Page

Meeting Information


Back to CBCC Main Page



  1. (05 min) Roll call, approve minutes January 25th, call for additional agenda items & accept agenda
  2. (45 min) Review of Action Items and other business
  3. (1 hour) Discussion -


1. Action items:

Action 1: Review action items from 20010118


Action 2: Provide location of the draft EHR profiles on the wiki page. (Serafina)


Action 3: Provides SHIIPS Project Overviw presentation to Structured Documents (Serafina)


2. Resolutions

Motion approved for minutes 20110125

3. Update and Discussions

Status Update on Steering Committee approval:

  • Note from Austin: DESD electronic vote for the SHIPS was sent out on Sunday (Jan 23, 2011). The vote will run until quorum is reached or 3 weeks have passed, whichever comes first. About all that can done to speed up the process is to encourage work groups in DESD to submit a vote so the Steering Committee can achieve quorum quickly.

EHR working call at 4 p.m. EST. Richard to present SHIPPS

Maturity of Health Information and President’s Council of Advisors on Science and Technology (PCAST)

  • PCAST Health IT report calls for Meta data tagged information. This fits in the continuum of a higher level of maturity of Health data and would enable secondary uses of information including automating privacy and security policy and quality measure
  • Segmentation will be universal, e.g. anyone sharing records for any purpose will have to deal with segmentation
  • The EHR WGs are talking about the PCAST report and the recommendation for this universal exchange language
    • Data Element Access Service (DEAS) the services that will access the tagged Meta data and the language is called the universal exchange language

EHRS Functional analysis

  • We have identified gaps in the Supporting functions of the EHRS
  • *Supported functions are all non-direct care e.g. records management, administration, privacy e.g. privacy preferences
    • Supporting functions deal with secondary use of data and the administrative functions
  • Infrastructure functions have to do with framework and interoperability
    • Most of the Privacy functions are listed in the Infrastructure
    • It says thou shall enforce consent it does not say how the consent is to be managed or recorded, or whether it has to be managed or recorded. It has to be enforced but this is not described. It is an entity of Infrastructure along with authentication, authorization etc.

PCAST information does not distinguish between the business purposes or with the access of information. PCAST will say information has Meta data and you can go look for it and find it. From a functional perspective PCAST information would be in Infrastructure e.g. you find information automatically through data element access services. It is not explicit clinical functions or an explicit business supportive function. Richard: So the Meta data is applied in the supportive functions? Ioana: The Meta are applied everywhere. Richard: So what is supportive in this case? You started by saying that infrastructure will enforce privacy consents. Ioana: Infrastructure says that you will support privacy consents. What I expect to see in the supportive functions is a function allowing the clerk/patient to enter privacy preferences that relate to the use and disclosure of information. I expect to see the ability of the EHR to take in the preferences of the patient. Right now there is no explanation on how that consent comes to exist and how it is used or taken in by the infrastructure. Richard: Or to take in my preferences from a consent registry/repository Ioana: it is completely silent whether a clerk enters the information on your behalf from a signed consent form, or if the patient enters it into a PHR etc. An easy way to distinguish infrastructure from supportive functions: the infrastructure functions are not accessible to end users, while the supportive and direct functions are directly accessible to end users. The infrastructure is out there and you indirectly make use of it, it sort of happens automatically and magically. Supportive functions are functions that end users can exercise. Jon: It’s helpful to think about infrastructure functions as a layer higher than platform and lower than the application. It is a set of components that sometimes have logical functions to perform, and applications can call on them. Infrastructure can be kind of arbitrary because the infrastructure for a particular concern is whatever supports that concern, its relative not objective. But we a can talk about things that are higher than platform and lower than applications it’s a layer of supporting services. Ioana: Supporting functions are things like billing, public health reporting, while infrastructure is completely business neutral, authorization, authentication, information exchange things that are non-business specific but framework specific. Ioana: The EHR is talking about reconciliation of privacy and consent and this has an element of interaction with the end user e.g. if a patient has a preference that is not supported by a policy in an organization, this information will to have be presented to you somehow. If the EHR WG is interested we already documented use cases in our Domain analysis so we could reuse this analysis to document the functions and conformance criteria that go along with them. Serafina: This is an area where we will see some overlap of PHR functionality and EHR functionality e.g. one of the methods by which an individual might manage their privacy e.g. consents, is through their PHR. Ioana: For the next generation of the EHR functional model there is an attempt to consolidate the extensions that have been identified in the profiles and therefore will become part of the models. Serafina: They do have a draft of these new profiles and Gary pointed me to the EHR wiki page. This has not been published / balloted yet. Ioana: I think in this next version of EHR functional model (R2) we will see PHR functions Serafina: John Ritter sent out something related to the next PHR WG meeting, in the minutes there is an ISO new work item proposal (NWIP). I think the intent is to make the PHR a subset of the EHR Ioana: The first ballot is a draft for comment, which will allow them to gage what people are looking for. SHIPPS ScopeIn terms of information analysis we have 2 sources of Meta data one identified in the composite privacy consent model. The second source comes from the identified NQF retooled measures. Information Class associations through current billing system There are associations between the data elements that are required to support the way the data is reported today e.g. payment and billing data. So we have these associations from patient to visit encounter to procedure that has to go through an encounter or visit because of the billing for services. Presumably in the future we could identify the procedure as an association between a person and their procedure list. There is a need for domains to create content data models as well as tie it to the functionality in the EHRS functional model Richard: There is an assumption for a choice relapsing disorder e.g. substance abuse, I think you have to have integrated set of records from multiple providers otherwise you don’t know what is going on. Retooling business from just one provider won’t work because people who have problems tend to go multiple places Serafina – The current performance measures are specific to an organization or a set of providers Richard: A set is fine e.g. Safety Net context. It will be very difficult when a person will be diagnosed with an alcohol problem that has not been diagnosed before maybe 5 times and everybody will get credit for it. Ioana: I don’t think NQF has authority over how the measures will be applied. I think CMS may be the right authority to provide guidance. Richard: They could potentially do it if all people were billing the same place and this is where the Safety Net comes in. Serafina: In order to do this kind of measure across organizations you would have to have a central data repository. The claims data is the source of information for most of these measures and currently there is an effort put forth by the federal government for all federally reimbursed programs to collect centrally, e.g. claims data from across organizations. Ioana: It seems like CMS is looking at being the aggregator of the data and then applying the measures to the aggregated data. Serafina: The CMS is not doing it right now e.g. big brother idea. They may have the ability in their own CMS system e.g. the Medicare data. Richard: It’s the Medicaid side you can do this and this is where it is State based not CMS based. Ioana: The Medicaid will probably have to do the same thing e.g. aggregate the data and then apply the measures. Richard: I don’t know if we build this into the definitions…. Ioana: When we start to describe what we expect to be the flow of information from the various health information systems to the place where it is aggregated and computed. We can in our model include these assumptions. I don’t think the NQF folks care if we are applying the measures to a single provider or a group of providers or a state or … Richard: I don’t think they do because the contract was simply to retool. The larger context was ignored. Maturity Model Ioana: In terms of the data analysis itself it will not matter if we describe what the flow of information would be from the source or where the data is created during the clinical workflow. However we might have an opportunity to say a few things there with respect to maturity level.

  • Different levels of data maturity dealing with aggregate data vs local data
  • If a person is receiving care from different places, the different places may have different levels of data maturity
  • This is a concern; are we even able to do this kind of eMeasure analysis at a broader level
  • With a chronic relapsing disorder we need to acknowledge that there may be people coming in with just having another episode - there is some part of this modeling effort that needs to acknowledge this otherwise it won’t pass the ‘laugh test’
  • Depending on the level of the maturity bar, everyone has to be at the same level in order to support aggregation. People need to understand this in order to plan ahead.
  • Most people will use interfaces (e.g. transforming / translating to the standards); in most cases it will not be natively encoded according to the standard it may not even have standard Meta data but may have good quality Meta data that can be mapped to the standard Meta data. The point is to look at the readiness of the industry; e.g. the landscape today is where most people have structured data with local codes. If everyone is at the 2nd level of maturity map to standards the data can be aggregated. If the data is still unstructured to somewhat structured this is a problem and may be a big hurdle. There will need to be some cleaning up before we can have meaningful exchange of information.
  • Systems are going to be collecting different levels of data in the within structured data. When you have data that has been captured for different purposes e.g. creating a claim vs clinical documentation that is going into a problem list format. The granularity / precision of the data will be different and perhaps we will be able to do remedial work and at other times this will not be unsuitable.
  • If I am trying to qualify as a meaningful user e.g. receiving meaningful use incentives, this may be the motivation. If you don’t have structured data you don’t quality. If I want to qualify you will need to meet meaningful use quality measures, e.g. the precondition will be to have structured data.
  • If you are going from having completely unstructured data you don’t want to go through an intermediate step you want to go to the highest level of quality structured data. If you are somewhere in the 2nd tier you may be dealing with billing information and that could be one of the reason you are not compatible with the latest and greatest Meta data and terminology.
  • Mapping out the landscape and bringing out these topics for discussion jurisdictional y.
  • We will raise these issues and explain them so that people implementing can plan accordingly.
  • The NQF quality measure will potentially come back to a provider. The question is do multiple providers get credit, how do we qualify truly new cases. Maybe 5 providers will count you as having provided the right level of counseling. Is this in the spirit of things is this ok? This is not in the spirit of these measures.

Meeting adjourned 2.58 EST