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