Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Wednesday, December 7, 2011

Some principles for creating an HQMF

One of the things mentioned at the Query Health face to face last week was that we were going to need some implementation guidance on how to create an HQMF that works with Query Health.  These are some of the issues that I have to wrestle with right now:
  1. Most queries will need to identify patients in a particular age group, what is the best way to represent that in the HQMF?  There are at least four different "technically accurate" options for representing this:
    1. Assume that the age of a patient will be represented as a (computed) observation in the system performing the query.  This seems to be the simplest, as it allows the age groups to be defined in criteria in a fairly easily readable manner.
    2. Represent birth as an observation, with the effective time of the observation giving the DOB, and representing the age range as a pause quantity between the time of the measure period and the birth observation.  This is challenging because it requires comparison of two separate observations, the measure period and the birth observation, using a variety of HL7 Vocabulary terms to reflect the difference (as a pause quantity).
    3. Represent date of birth (as opposed to birth) as an observation, with the value of the observation being the date of birth, and representing the age range as a pause quantity between the time of the measure period and the value of the date of birth observation.
    4. Represent the age range as a Date of Birth range, and specify that range an interval on the subject's birthdate in the query critieria.  This is very awkward, especially given that the Person class in HL7 V3 is not designed to be "queried by example" using the critieria indicator.  That is to say, you cannot specify an interval on birth date or date of death. 
  2. Other demographics may also be of interest, including gender, race, ethnicity, marital status, religious affiliation, place of birth and place of residence.  There are at least two options for many of these:
    1. Representing demographic criteria as observations.  This allows the typical things to be done on the observation, and supports specification of value ranges for geographic criteria.  We can certainly find LOINC and SNOMED codes to represent the various concepts found on Person  to address the kinds of queries that need to be made.
    2. Representation on the appropriate model elements for the subject, again, with a similar challenges as date of birth/death in that PERSON is not designed to support query by example in the V3 model.  For the coded critieria, it can easily bend this way, but in dealing with geographic designations (postal code, city, state, country and county), it also gets challenging.
  3. Time dependency.  All of the "expressions" I've dealt with have to do with relationship of different acts in time.  There are a couple of ways to handle these expressions:
    1. Using expressions in effectiveTime, activityTime or other act time intervals.  While the XML is simpler to read, the resulting expressions are difficult to interpret and transform to an implementation technology.
    2. Using pause quantity and the HL7 specific value set TemporallyPertains which relates acts by their temporal relationships.  While the pause quantity is clear on the time spent between two acts, what isn't clear is to what this applies.  Is it the clinically effective time (effectiveTime), or the activity time (activityTime), or some other time.  This also leads to complex XML expressions.
  4. Model Relationships.  There needs to be some way to relate data criteria to a stratospheric view of a data model.  
    1. I used the instance of (INST) relationship and very bare details to represent that an act was an instance of a certain type in my prototypes.
    2. The NQF Measures adopt the LOINC codes for information categories used in the CCD and similar guides to identify what elements are being considered, and the detailed act was represented using the Component of (COMP) relationship.
  5. Data Criteria or Data Elements.  While it's described as the data criteria section in the HQMF specification, some implementations have simply used it to identify the data elements, and applied further criteria in the Patient Population Section.  This is reflected in the NQF Measure 59 where the Encounter data element is used in two different places in the patient population section to represent two different things.
    1. I like fully specified criteria in the data criteria section.  That way I can distinguish between different data elements of interest.
    2. Other measure implementations have simply identified data elements.
  6. Counting things.  The MAT generated NQF measures use a rather complex way to express the idea that there have been two encounters for a patient in the measure period.  There are at least three ways to express this:
    1. Use summary criteria to count the number of events meeting a particular criterion.  See this post for details.
    2. Use repeatNumber in the encounter criteria to indicate the specific encounter.  This is a simplification of the previous method.
    3. Use temporal criteria to relate an event to another event.  To identify the second event, you could ask for an event meeting particular criteria within the measurement period that starts after the start of another event that meets that same criteria.  This is OK for second, not great for third, and uglier and uglier after that.  It's a unary counting method.
    4. Use specific subset codes to identify FIRST, SECOND, et cetera.  In this case, you could simply ask for the "SECOND" encounter meeting particular criteria.  I don't like this at all because it isn't generalizable beyond the values provided in the vocabulary, and it's pretty clear that there are an infinite number of ordinal positions.
So far, my preferred solutions are the first option of each of the alternatives listed above, but I haven't considered all the details. Somewhere, these sorts of details will need to be addressed.  IHE QRPH is working on some guidance for population measures, and I will be bringing these issues up there as well as in other places.

Dec-9-2011: Updated the title and added content about Counting Things


  1. Great post Ketih. I would agree with you in most cases. However, not in others.

    For example:
    Age is not a global calculation for all measures. In other words, dependent upon the measure, age may need to be expressed differently. Some measures may want to cosider age based on an encounter, while other measures may want to consider age based on the time of a procedure or an intervention.

    Regarding Data Criteria, I feel that following your preferred approach would weigh data criteria down immeasureably dependent upon the measure (no pun intended). Can give you examples if you want them.

    With regards to Counts, some measures have a need to be able to set a quantified Count (e.g., Count >= 2) while some measures need the ability to require a Count (e.g., give me the count of Encounters that happened within a specified time frame). Though your recommendations handle the first scenario, they do not handle the second scenario. Count should be something that is consistently handled regardless of the scenario.

  2. Anonymous:
    Agree on your age issue. In fact, given that most computations (including age) are based on time comparisons, I'm reconsidering how to deal with time-based relationships.

    I'd love to see your examples on where my preferred approach would weigh the criteria down. In the three different implementations I've done, I've found it easiest to find records matching the data criteria, and then perform the set operations on them in a second stage. I haven't seen a case where this would be problematic, so your examples would certainly help.

    On the counting piece: Summary criteria can be used to a) select using a quantified count (e.g., Count >= 2), or simply ensure that the count is present (by using the summary without restricting based on count).