Counting other things in QueryHealth and HQMF

In Query Health, we've been focused on counting patients who meet particular criteria.  But just as we are counting patients, we could also be counting encounters, providers, organizations, or just about anything else that you wanted to count to compute a quality measure.  The key to determining what you are counting depends upon your data model.

We bind what gets counted through the use of definition elements and reference elements in the dataCriteriaSection.  Each criteria element references something that is defined in a definition element.  But we don't really say a thing about how the data model itself is structured in the HQMF representation in the HQMF.

In the Query Health model, we start with a patient.  A patient has demographics (which is often how we select them for the initial patient population).  They can also have problems, medications, allergies, immunizations, diagnostic results, vital signs, procedures and encounters.  We might tie the record of a problem, medication, allergy, immunization, diagnostic result, vital sign or procedure back to an encounter.  And we might tie an encounter back to a provider.  So in that model, when you start from patient, you analyze the HQMF from that perspective, and that is what you wind up counting.

But, if you wanted to count encounters, you'd organize your data model differently.  Instead of starting with a patient, you'd start from the encounter.  Your "IPP" would not longer be a collection of patients, but instead, would be a collection of encounters.  You might select them based on what was recorded during that encounter (e.g., diagnosis), or what was done during that encounter (e.g., a specific procedure), or details about the encounter such as the type of setting (e.g., ambulatory, ED, inpatient). An encounter would have a set of problems, medications, immunizations, allergies, diagnostic results, vital signs, procedures and patients associated with it.

How you organize the model influences greatly how you wind up counting, but it doesn't require many changes to HQMF.  It may have been written with a particular model (the patient-centric one) in mind, but HQMF in practice doesn't assume any particular data model.  So what would we need to change?


To clarify things, we'd want to change the "Initial Patient Population" entry to become the "Initial Population" entry.  This is simply a clarification that what we are counting could be something other than patients.  The other thing we would want to do is add a classifier to the measure heading to indicate what it is we are counting.  The classifier serves two purposes:

1. It identifies to the user what is actually being counted. 
2. It indicates what is being counted so that the implementer can use the correct data model.

To add this classifier, we simply need a code to represent it, and a value set for the different kinds of things that could be counted.  What we are counting could be patients, providers, encounters, procedures, immunizations, lab tests, locations, organizations or just about any other kind of entity or event.  For most cases, I think we would readily use patients, and might use encounters, treatments (procedures and medications) or diagnostics (test results).  There might be cases where it might be interesting to compute quality measures that count providers, organizations, locations, or even devices.

The XML to express this would be pretty simple:

<QualityMeasureDocument>

    ...

  <subjectOf>

    <measureAttribute>

      <code code='COUNTS' codeSystem='2.16.840.1.113883.5.5'

                codeSystemName='HL7 Act Code'/>

      <value code='...' codeSystem='...'/>

    </measureAttribute>

  </subjectOf>

It's pretty easy to imagine a quality measure for an encounter or procedure (and this example could be written either way):  Encounter population = all surgical encounters.  Denominator all surgical encounters on a patient older that 70.  Numerator, all surgical encounters where the patient was given a flu vaccination in the 3 months during or prior to the encounter.

You'll note that I didn't fill in the details for the <value> element.  That's because I don't know what they should be.  We could come up with a value set from SNOMED CT, or from HL7 Vocabularies (we might need to use several, because patients are roles, but encounters and procedures are acts).

With respect to quality measures for those other things, I could imagine cases where what you might want to count the number of times a certain test is used, compared to the number of times that test is positive.  That could tell you some interesting things about the utilization of that test, and it could be compared against other tests, or other uses of the test at other locations or regions.  It too could have a different model that it was executed against.  But this example is also amenable for computation using a patient- or encounter-based model.  In the encounter based model, the denominator would be encounters where that test was ordered.  The numerator would be the number of cases where the result of the test ordered came back positive.  So maybe we don't need a large vocabulary to express what we are counting.

There is another approach to this problem as well, which I'll go into more detail upon tomorrow.  If we expand on our use of measure observation, so that rather than just counting things that match, we accumulate the values of expressions in a <measureObservation> element, we could support a number of additional capabilities.  If you look at the SQL prototype I discussed back in November, you can see where the final output relies on the COUNT  function in the query.  Other aggregated statistics functions could also be used.