Putting together pieces for QueryHealth

In Query Health, mostly, we are counting things, summing them, averaging them, computing a standard deviation, correlating them, et cetera.  These are aggregate statistical functions.  After we’ve counted things, we can do other sorts of statistical measurements on them.

What are the things we counting:

• Patients
• Orders for Interventions or Diagnostic Tests
• Encounters/Visits
• Findings
• History
• Diagnoses/Problems/Symptoms
• Measurements (Lab Results, Vital Signs)
• Interventions
• Medications
• Immunizations
• Procedures

The S&I Framework CIM provides one mechanism to access to these various components, but doesn’t specify a query language, and doesn’t have a formalism (yet) that defines it, or allows EHR system access based on it.  The HL7 HQMF provides a mechanism to query a model, but its base model is the HL7 RIM.  That model is very broad, and means that there are a number of different possible ways to reference different components.  A restricted and simpler model would be much better, especially in the context of Query Health.  If there were some way to put the two of these components together, it could make real world implementations much easier, and would allow QH to take advantage existing work.

The CIM can be represented by a set of HL7 acts, associations, and entities from the RIM, described in definition mood and identified with CIM model component names.  Such a representation could be used for Query Health based queries.  For completeness, we could create acts in definition mood that define the components of the S&I Framework CIM.

One of the things that I like about the HQMF specification is the Data Criteria section.  But I don’t like the way the data criteria is referenced (by ID) in the document.  That’s because the ID is computer friendly, not human friendly.  One way to make that a little better is to use OID+extension, and have one OID that references a particular model, and an extension that references a component in that model.  That way, you’d only have to remember one OID, and could use the model names to access different parts.

Then, to create a data criterion (and presuming the model was available at a URL), we would do the following:

<xi:include href='http://wiki.siframework.org/file/view/QHM.xml'
  xmlns:xi='http://www.w3.org/2001/XInclude' />
<act… moodCode='EVN.CRT'>
  <id root='criteria-oid'
    extension='criteria-descriptive-name'/>
   … query details …
  <sourceOf typeCode='INST'>
    <id root='…' extension='name-of-component-in-CIM'/>
  </sourceOf>
</act>

You can see where I put in an <xi:include> element that referenced a QH/CIM model that contained the appropriate model definitions in XML (See the W3C XInclude standard). The point of that is that each HQMF document doesn’t need to duplicate that effort, but can simply reference it.  It becomes a “standard model” for QH queries, and systems which understand that model can readily understand the data criteria and transform it into a way to access the information.

That last item (and we should require it to be either first or last in the list of act relationships just to make it easy to find) would indicate which CIM model element was being constrained.

Note: If you have an existing HQMF Measure definition, provided you’ve followed some best practices, “fixing it up” to work with Query Health can be done in a couple of easy steps.  At the top of the Data Criteria section, add that <xml:include> element.  Within each element in Data Criteria, add the reference to the model instance that is being queried (that last <sourceOf> element).  So long as you’ve followed the best practices in creating a measure definition this shouldn’t require a great deal of work.  That is of course, true only when we’ve figured out what those best practices are.

What’s next is defining what is to be measured.  HQMF specifies how to define the Initial Patient Population, the Numerator, the Denominator, Denominator Exclusions, and a Measure Population.  If you are computing a normal quality measure, you would define the Initial Patient Population, the Numerator and Denominator, and possibly Denominator Exclusions.  What would typically be reported for the measure would be the Numerator and the Denominator counts, but you could also include the Exclusions and Initial Patient Population counts.

If you are defining some other sort of measurement, you’d define the Initial Patient Population and the Measure Population.  What would typically be reported would be the Measure Population, but again, you could also include the Initial Patient Population count.

HQMF doesn't actually say how the measure is reported.  We'd have to establish some best practices around this.  I think it's pretty clear that Numerator, Denominator and Measure Populations need to be reported.  I would also assume that if you define a Denominator Exception, that those values would also be reported.  The real question is whether the Initial Patient Population needs to be reported or not.  Given that anything specified in all the other defined sections is reported, I'd just go with saying that the Initial Patient Population must also be reported in the output.

The next step in the process is to take the HQMF query and turn it into something that a system could execute.  This involves a few steps, and is something I’m still working out…

What I already know is that mapping data criteria and measures back to the EHR data model will be needed.  If you know how to map your EHR data model to the S&I Framework CIM, this can be accomplished.  Since that CIM is built on CCD and similar encounter documentation models, and certified EHRs can already map their data models to the CCD, I’m pretty sure this is feasible.  Another important step that is mapping from EHR used vocabulary to the CIM and/or Measure specific vocabulary.  Ideally, we’d like to avoid things like multiple vocabularies for the same data elements (e.g., ICD-9, ICD-10 and SNOMED CT for problems), but that’s not something Query Health can control (although it could influence things).