- The data criteria section describes data of interest.
- The population criteria selects items to compute with.
- The measure observations section defines the computations.
In any case, I realized tonight that the solution to the challenge for computations involving two or more acts is to provide a mechanism that defines a set of tuples. Each item in tuple is associated with a "measure population criteria" which describes whether or not the item should be considered on its own merits alone, and zero or more constraints between two or more items of the tuple that must be true for the items to be considered.
This is essentially a "INNER JOIN" between the sets of results matched by the measure population criteria for each item. Imagine the case where, in an ED encounter, you want to measure the time between the creation of an order to admit a patient, and the discharge of that patient from the ED encounter. You have two acts: The ED encounter itself (call it EDEncounter), and the order to admit (call it OrderToAdmit). In the current HQMF model, these could both be represented as measure population criteria, and you could have a measure observation definition based on those criteria (e.g., EDEncounter.effectiveTime.high - OrderToAdmit.effectiveTime), and it would nearly work. But let's assume that you have a patient who has had two ED encounters in the measure period. For those patients, the definition of the computation would have to decide which EDEncounter to associate with which OrderToAdmit. The only way to resolve the issue is to tell the system how the two are related.
So, with two or more variables, there needs to be at least one more criteria which specifies the relationships between the acts. It could go a number of different places, but because this criteria is critical to the computation, I'd put it in the measure observation definition as a precondition. The precondition would reference a relevant act from the measure population criteria, and that reference would then be related (through an act relationships) with one or more other acts through the same kinds of relationships allowed for other criteria. Multiple precondition relationships could be specified, all of which must be true for the criteria to succeed. These precondition relationships are like the ON clauses associated with the joins.
One thing I don't like about this is the way that references need to be used. The challenge is that the content of the precondition is an act reference. I've seen how having to remember the components of an identifier of an act can make things challenging for people reading specifications. In OASIS ebXML specifications, identifers are UUIDs or names. Names are locally unique within the message, and can later be given globally unique identifiers assigned by the system. We don't have a similar capability in HL7, but I just realized something about the long forgotten RUID type. The HL7 II data type is made up of two components, the root (of type UID), and the extension. The root typically identifies the namespace from which the identifier comes from, and the identifier itself is stored in the extension component. The root attribute is often a UUID or OID, but it can also be of the RUID type. That's simply a type reserved by HL7 in balloted specifications.
What I'd like to do in HQMF is say that the RUID that is represented by the string "local" represents a namespace defined by the message or document in which the content appears. Then, rather than having to remember an OID or UUID for each act that is referenced, we could just identify it by saying "local", and giving it some sort of locally unique identifier (such as a name) in the extension portion. We could further define this namespace as being the same as the namespace used by the <localVariableName> element found in act relationship elements.
The ED Encounter example above would appear as follows:
EDEncounter.effectiveTime.high - OrderToAdmit.effectiveTime
<id root='local' extension='EDEncounter'/>
<id root='local' extension='OrderToAdmit'/>
Arguably, the XML should include derivation relationship from the measureObservationDefinition to the criteria which defines the variables EDEncounter and OrderToAdmit. However, these acts are already defined and named in the context of the HQMF Document, and I see no need to provide additonal XML just for the sake of "completeness".
Translated, it means
- For the measure populations defined by the variable names in the derivation expression (EDEncounter and OrderToAdmit),
- for each EDEncounter, OrderToAdmit pair
- if an OrderToAdmit is related to EDEncounter by the "component" relationship (which is to say that the order occured in the encounter)
- compute the derivation expression
- and report the sum and count over all terms.
SUM(EDEncounter.effectiveTime.high - OrderToAdmit.effectiveTime),
COUNT(EDEncounter.effectiveTime.high - OrderToAdmit.effectiveTime)
ON OrderToAdmit.EncounterID = EDEncounter.ID
It is too late to make this correction for the content that went out to ballot, but this is a ballot comment that I will make. After all the purpose of balloting is to detect and correct for stuff like this.
Now that inspiration has been satisfied, I need to get back to what I should have been doing...