Tuesday, October 25, 2011

SIFramework Face to Face update on QueryHealth

I spent some time in the Query Health Clinical and Implementation workgroups at last week's S&I Framework face to face meetings.  There were a number of interesting discussions, and David Tao reports on some of them in his blog post today.  I'm a bit behind on my own report out, so here it is, with a few [side rambles] included.

One of the discussion points in the Clinical Workgroup was on the user stories.  We were looking at the various user stories and expanding upon what they do.  We quickly got bogged down into discussions on quality metrics.  But the key point in Query Health is not just quality reporting.  There are a lot of different things that it can report on:

  • Quality Measures (an obvious use case)
  • Population Stratification
    What does your population look like when stratified against a particular disease risk?
    e.g., Who should get a limited supply of a particular immunization?
  • What medications and adverse events are correlated (e.g., Heart Attack and Vioxx)?
  • What is the trend with respect to some particular condition over time?
So, we broke that log-jam and got focused on some other stories that might look a bit different.  One common feature of many of these user stories is the focus on "counting", so we are now talking more about counters, rather than numerators and demoninators (which are just specialized counters).

Another interesting discussion in the Implementation workgroup was on how we should proceed.  What kinds of technologies that we've seen thus far seem promising?  This was, as on person put it (not me, although it was attributed to me on the Query Health review call today because I said it again later in the meeting), a "Beauty Contest".  Three different systems stood out, but by far, the hQuery proposal backed by MITRE seemed to get the most support.  I had a hard time choosing because I've been behind on my summer concert listening (ONC recorded a dozen 90-minute presentations from invited guests who might have a solution to the problem).  But I did have some idea about what hQuery was, and thought it might be a good place to start.

One of the things that I don't like about hQuery right now is that it seems to be tied too much to JavaScript, and to a Map/Reduce based algorithm. While JavaScript is extremely available, and Map/Reduce is very scale-able, there are definite challenges to adapt it to a wide variety of implementations.  I'd much prefer a more declarative approach, using something like the Transitions of Care Clinical Information Model (CIM) as the basis for the declarations.

The TOC CIM is based on the HITSP C154/C83/C80 work (data elements, information models, and vocabulary) that goes into all HITSP Document specifications, including the C32.  One concern of the Implementation workgroup is the weak modeling of Encounters in the TOC CIM.  According to one participant, we needed to modify the TOC CIM to create our own model.  I like to think about that differently. We (the Query Health project) need to modify the S&I Framework CIM to meet our requirements.  Note how I changed the ownership of the work product from TOC to S&I Framework.  If S&I Framework is to survive, it needs to stop organizing itself solely in a project centric fashion.  

[One suggestion I made for the next S&I Face to Face meeting was to develop tracks:  Clinical, Implementation/Technical, and Operational/Business.  In that way, folks who have deep knowledge in one of those areas can contribute to more than one project.  Right now, we don't have that structure, and it means that I, and others like me, spend a lot of time communicating across and trying to follow different projects and workgroups within projects.  It's very difficult to follow more than one activity when everything is going on all at the same time.  If S&I Framework isn't careful, they'll have as many workgroups as HL7.]

I was in MITRE offices later in the week for a W3C Workshop on Data and Services Integration.  After the workshop, I was given a brief overview of hQuery by Marc Hadley, an organizer of that workshop and one of the designers of hQuery.  He showed me their "Query Builder", which describes what results a clinician might be looking for.  The JavaScript on the back end is actually produced from the content specified in the Query Builder.  I think there are some opportunities here to use some of the HL7 HQMF modeling (eMeasures) work do help declaratively define the results, along with the CIM model (based on C32 and other HL7 CDA documents), and the general framework of hQuery for distribution and reporting. 

[One of the complaints about eMeasures is that it "is new", but the fact of the matter is that a lot of Query Health is "new".  Sure, there is some existing work, but we are trying to put a lot of that together in ways that can be supported across the spectrum of Health IT and that hasn't been done before.  At the moment, it really is the only standard that declaratively specifies the structure of some sort of counter]

Among the benefits of using a declarative structure based on a reference model are:
  1. Queries can be defined based on what the user wants to see.
  2. EHR and Health IT systems can map the query to whatever framework they want to use.  It could be SQL, Map/Reduce, Extract/Transform/Load or any other approach.  It isn't tied to any specific architectural model.
The hQuery work already shows that they can transform against a "Green" C32 model into a Map/Reduce architecture using JavaScript.  Those details are all necessary to produce a working implementation.  But they aren't all necessary to produce the set of standards that defines how Query Health works.

An interesting side-note here is in a recent paper presented at AMIA by John D’Amore, Dean Sittig and Adam Wright titled: The Promise of the CCD: Challenges and Opportunity for Quality Improvement and Population Health.  In it the authors note that 12 of the 44 (a little more than one fourth) Meaningful Use Stage 1 Ambulatory quality measures could be extracted from the example CCDs containing problems, medications and allergies, and that 35 of the 44 (about 80%) could be extracted by adding procedures.  With the addition of other data, the authors note that they could extract all the ambulatory measures.

This is a pretty significant result for Query Health because it means, at least for one of the pilots, that there is evidence that they can succeed, as most of their data is coming from documents using the C32 specified content. 

Query Health is an interesting project.  I'm hoping that it will produce something useful without being to restricting on the technology that is used to implement it. So far, it seems to be headed in the right direction.

 --  Keith


4 comments:

  1. Keith, thanks for blogging about this, since I was only able to attend two of the QH sessions. I heard Sean Nolan talk about using C32 as an "80% solution" (or words to that effect) which correlates almost exactly to your 35/44 statistic. Some others in the room thought C32 was overly constrained in its vocabularies (though I didn't understand why that would be a bad thing for QH, it seemed to be a direction we need to go). For hospitals, Procedures are required in CCD, so Stage 1 MU EHs should already be there, and I presume that QH queries are more likely to go to big organizations (like hospitals) than to small practices. So that's promising. I wonder what other elements of CCD would expand that 80% up toward 100%? Might they be the other CIM core data elements that are being proposed in ToC, or at least elements required in some of the ToC information packets, like Discharge Summary?

    ReplyDelete
  2. David:

    According to the report (see page 6):
    The remaining data which would be required to calculate all quality metrics
    are vital signs, smoking status, patient communication and communication between providers.



    The first two are in the CIM, and so is much of the fourth. I'm not clear on what is needed from "patient communication" because the report didn't make that clear to me on my first pass through it.

    ReplyDelete
  3. Keith -

    Nice summary and great framing on some critical issues for the Query Health project. Would be interested in your thoughts on the differences between procedural and declarative approaches as outlined in the hQuery Summer Concert presentation (see charts 15 - 16 http://wiki.siframework.org/file/view/hQuery+Summer+Concert+Presentation.pdf).

    ReplyDelete
  4. Wouldn't the very concept of C32 as a document be antithetical to QueryHealth? I understand QueryHealth as a method of sending the query to the data because to change the various data repositories into a standard form would be too hard.

    Did IHE MPQ profile ever come up? It is specifically intended to be a Query across a population to result in a count.

    ReplyDelete