Harmonizing HL7 HealtheDecisions and HQMF for MeaningfulUse Stage 3 : Expressions

One of the challenges with spawning multiple projects with multiple consensus groups is Rishel's law: When you change the consensus group, you change the consensus.  This is especially challenging when different parts of the projects make up different components of an ultra-large scale system.

The case in point is the different approaches taken by HQMF and Health eDecisions.  It started off this morning with a discussion of harmonizing the expression language syntax used in Health eDecisions and the QDM Implementation Guide of HQMF Release 2.  But the underlying problem is even more challenging than dealing with different expression syntax (each of which have their own value propositions).

You can transform a statement of how the process should be executed or what an outcome should be into a quality measure, as I mentioned previously.  Developing the transformations between Health eDecisions and HQMF is feasible.  It's made a lot easier if the two systems share a common information and representational model, because it makes a map between the two easier to understand.

Where HQMF and Health eDecisions don't align today is that HQMF followed HL7's modeling structures to come up with a representational model, which was then transformed into a XML representation through a predefined, automated process.  The existing Health eDecisions work went straight to an XML representation which eliminated much implementation complexity presented by that predefined, automated process. But it doesn't have traceability back to a higher level representation model (although one or more such models exist).  I've looked at Health eDecisions and HQMF closely enough to see the similarities between the two models that would help expose the common model.

We didn't execute on the project I mentioned, and that in part has to do with resource constraints and in part due to lack of incentives to do so.

So now we have this concern that Health eDecisions, and HQMF aren't aligned, and we'd like to see that happen for Stage 3, and we have "six months" to make that happen.

Let's start with expression languages.  HQMF Release 2 doesn't specify one.  Health eDecisions does.  The QDM Implementation guide will define an expression languange that MAY be used, but need not be.
I'd argue that we have two different requirements for expressions in HQMF:

1. Expressions must be easily created, edited and validated by measure developing organizations, ideally using automated tools like MAT.
2. Expressions must be efficiently executed in high volume enviroments in order to compute quality measures.
3. Implementing the expressions should not result in extensive investment in software crafted to evaluate them.

The first requirement is addressed pretty well by HED's language, because it is stored as a parse tree and can easily be manipulated by web based tools that allow expression construction through creation of a visual representation of the parse tree.  It is not addressed well by JavaScript because the parse tree has to be created to represent the expression.

The middle requirement is not addressed well by HED's language because it requires interpretation of the expression language, and the newness of the language means either using or creating code that does so.  It won't be nearly as fast as a premium grade JavaScript interpreter.  That's not a ding.  You don't get to that level of quality without time, and HED implementations haven't had that luxury.  There are some platforms that WILL be challenging to use this in.  You couldn't step out to HED's langauge easily from SQL, for example, and interpreting it in Perl wouldn't be my first choice for execution speed either.  However, it is addressed well by commercial and open source JavaScript interpreters.  These are quite efficient, and have been around well and have a high level of quality, and work in numerous programming environments.

The last requirement is also arguably difficult for HED to compete against JavaScript.  I cannot think of a platform combination I've encountered in my career that doesn't support JavaScript except for my Arduino.  I'd have to write code for most others, or use the code provided by the HED pilot project.

The first requirement and latter two requirements address the needs of different groups.  I'm not a measure developer, and never will be, nor would I ever be involved in software development of products for that group.  However, I do deal with products that are the execution environment in which these expressions need to execute.  So, JavaScript meets my needs readily.  In fact, I'd say it beats HED's language hand's down.  No, it's NOT platform independent, but it is ubiquitous, available on my platform choices, and I don't have to teach it to my developers.

If we had to pick just one, there'd be no solution to this problem in HQMF, but fortunately, we don't have to.  I assert that there's a transformation that can be defined from the platform independent HED syntax to the "limited" JavaScript syntax which will be provided in the QDM-Based HQMF guide.

Fortunately, Data Types release 2 (which HQMF Release 2 uses) allows multiple expression representations to be provided in an element expressing an expression.  The execution environment is permitted to choose which of the expressions to use, based on its preference.  Thus, both expressions can be provided in HQMF measures.  The former meets the needs of one group, and the latter meets the needs of another, and there's an automated way to go from A to B, so that once measure developers are satisfied with a measure and the expressions that go along with it, those expressions can be turned into an execution script.

I knew an engineer that wrote something called a Kalman Filter in Fortran.  If you read about it, you learn that this is used in guidance systems.  He sat in the control room at NASA while his software took an Apallo mission to the moon.  I would never attempt to write a Kalman Filter in an expression language like HED.  It doesn't address at all my needs for being able to easily write and express a complex matrix mathematical algorithm.  In fact, I'd prefer Fortran to just about any other language choices that I could use (C++ would come first, Fortran is second, and Java third).

On the other hand, HED is well suited to handle Event Condition Action rules that are graphically created (don't expect me to write the XML by hand though) and manipulated.  It meets a different need.

So, how would I harmonize these?  Provide an incentive for someone to create an open source transformation from a decent enough subset of HED expressions (see Section 5.12 of the HED spec) to meet the needs for quality measures to a subset of the language that has been specified using JavaScript, and put it into the MAT to enable translation of HED XML to JavaScript.  When a measure is published, autogenerate the Java Script version of the expression and publish with BOTH expressions.

I've only addressed ONE issue here.  There are several more to go, and plenty of time later to write more blog posts.

The Model is the Standard

In HL7 Version 3, with one significant exception, the information model derived from the RIM is the normative expression of the standard.  The significant exception is of course CDA, which has the normative requirement that a CDA instance must validate according to the XML Schema produced from the model (once all extension elements and attributes are removed).

In HeD and HQMF, we want the overlapping concepts (the data to be used, and the operations that can be performed over them) to be drawn from the same model.  The model thus provides consistent semantics, and we can trace from clinical guidance to both the measures of implementation and the clinical decision support that implements it.

We had a long discussion today between myself, and members of the HeD development team to figure out how to move forward.  We have, as a result a proposal that stems from the fact that the V3 schemas are not normative.  Here is a quick summary of the proposal from my perspective:

1. The current HeD guide is treated as an implementation guide of a to be developed standard model, and is altered somewhat, but not substantially so, to be published by HL7 as an informative document or DSTU.  The alterations to be made stem from current ballot comments, and include harmonization with the HQMF header structure, metadata, and outline.  This does not include changes to its use of VMR, representations of logic or expressions.
2. A new HeD standard model will be produced subsequently that is compatible with this implementation guide.  It will use the same model elements as HQMF where there is overlap.  The VMR/QDM data access layers and the logic/expression evaluation will be separate components.
3. In that standard, the necessary logic and expression evaluation capabilities will be described functionally based on the capabilities of the existing HeD expression language.  These will be aligned with the simple expression language (based on simple math) that the SD and CDS workgroups agreed to in our joint session as being an implementation feature of the QDM-based HQMF guides.  Thus, you could map from something like simple math to the HeD XML expression representation if you wanted.  The capabilities would be the same (or very nearly so).
4. Adjuncts can be produced which transform from the HL7 V3 schemas generated automatically by our existing tooling, into the language specified in the HeD implementation guide.
5. We can also look at alternative ITS representations that allow the separation of models (e.g., VMR/QDM) from schema representations, to better support implementation flexibility.

This proposal keeps existing HeD pilots on their existing timelines as if my major ballot comments had not been made, aligns the current guide with the HQMF header and outline, allows HQMF to move forward on roughly the expected timelines we expect, and still harmonizes the efforts of both groups.

This was an exercise in making things possible, not in making them perfect, but I think we have a perfectly possible solution.

Reverse Engineering the Quality Measurement Process

This week has been very productive thus far.  Yesterday, I described one of the reasons why I felt that HeD needed to be aligned with HQMF in a bit more detail.  If you look at an event condition action (ECA) rule, the basic structure is:

on (event) if (condition)
then { action }

Let's transform the structure a bit:

action(p) and condition(p)
-------------------------------
         condition(p)

It should be obvious that this is a transformation that can be automated.

In this transformation, the numerator is patients for which the predicate action is true and for which the predicate condition is true.  The denominator is patients for which the predicate condition is true.  This is the definition of a measure.  It just so happens that I have a perfect example to play with: an ECA rule developed from NQF Measure 68 that appeared in the HeD Ballot.

I restructured that rule to use an HQMF-like declaration.  Now I want to build a transformation that reverses the process of creating a rule from a measure, to creating a measure from a rule.

Data Criteria

In the data criteria section, there is:

• an observation criterion of AMI_Diagnosis
  <observationCriteria>
     <id root="0" extension="AMI_Diagnosis"/>
     <statusCode code="completed"/>
     <value xsi:type="CD" valueSet="2.16.840.1.113883.3.464.1003.104.12.1001"/>
     <definition>...</definition>
  </observationCriteria>
• an observation criterion of IVD_Diagnosis that looks very much like the above, save that the id is AMI_Diagnosis and the value set is different.
• a procedure criterion for CABG_Procedures
  <procedureCriteria>
    <id root="0" extension="CABG_Procedures"/>
    <title>Coronary artery bypass graft procedures</title>
    <code valueSet="2.16.840.1.113883.3.464.1003.104.12.1002"/>
    <definition>...</definition>
  </procedureCriteria>
• a procedure criterion for PCI_Procedures that looks very much like the above, save that it is related percutaneous coronary interventions, rather than CABG.
• an observation criterion for age18andOlder
  <observationCriteria>
    <id root="0" extension="age18AndOlder"/>
    <code code="424144002" codeSystem="2.16.840.1.113883.6.96" displayName="Age"/>
    <value xsi:type="IVL_PQ"><low value="18" unit="a"/></value>
    <definition>...</definition>
  </observationCriteria>
• a substance administration criterion representing a prescription for antithrombotic in the past year.
  <substanceAdministrationCriteria>  <id root="0" extension="onAntiThrombotic"/>  <title>Prescribed antithrombotic w/in the past year</title>  <effectiveTime><low><expression>date(now,-1,"a")</expression></low>  </effectiveTime>  <participant typeCode="CSM">    <roleParticipant classCode="THER">      <code valueSet="2.16.840.1.113883.3.464.1003.196.12.1211"/>    </roleParticipant>  </participant>  <definition>...</definition></substanceAdministrationCriteria>
• an observation criterion representing a reason not to prescribe an antithrombotic.
  <observationCriteria>  <id root="0" extension="antithromboticNotPrescribedForDocumentedReason"/>  <title>Patient or other Reason for not prescribing an antithrombotic</title>  <code code="G8697" codeSystem="2.16.840.1.113883.6.12" codeSystemName="CPT-4"/>  <definition>...</definition></observationCriteria>

These will not be transformed because they are the same for both.

Condition Action Section

In the condition action section, there are a condition criteria that are anded together:

The patient must be older than 18.

<precondition>

  <observationReference>

    <id root="0" extension="age18AndOlder"/>

  </observationReference>

</precondition>

The patient must not be on an antithrombotic, nor have a documented reason for not being on one.

<precondition>

  <allFalse>

    <precondition>

      <observationReference>

        <id root="0" extension="onAntiThrombotic"/>

      </observationReference>

    </precondition>

    <precondition>

      <observationReference>

        <id root="0" extension="antithromboticNotPrescribedForDocumentedReason"/>

      </observationReference>

    </precondition>

  </allFalse>

</precondition>

The patient must have a diagnosis of AMI or IVD, or be scheduled for CABG or PCI.

<precondition>

  <atLeastOneTrue>

    <precondition>

      <observationReference>

        <id root="0" extension="AMI_Diagnosis"/>

      </observationReference>

    </precondition>

    <precondition>

      <observationReference>

        <id root="0" extension="IVD_Diagnosis"/>

      </observationReference>

    </precondition>

    <precondition>

      <procedureReference>

        <id root="0" extension="CABG_Procedures"/>

      </procedureReference>

    </precondition>

    <precondition>

      <procedureReference>

        <id root="0" extension="PCI_Procedures"/>

      </procedureReference>

    </precondition>

  </atLeastOneTrue>

</precondition>

This represents the condition in the ECA rule.  In the measure, I'd like to ensure that the denominator matches all of these preconditions.  I can simply move all the preconditions to be inside the demoninatorCriteria in HQMF.  Here's a snipped of XSLT which would do that:

<xsl:template match="hed:conditionCriteria">
  <entry>
  <denominatorCriteria>
    <id root="c75181d0-73eb-11de-8a39-0800200c9a66" extension="DENOM"/>
    <xsl:copy-of select="hed:precondition"/>
   </denominatorCriteria>
  </entry>
</xsl:template>

There are three choices presented to the provider for things to do in the ECA rule in a Choose One Action:

<ChooseOneAction>
  <title>Treatment and documentation options</title>
  <text>Treatment or documentation a clinician may order or 
    perform for an IVD patient with no prescribed antithrombotic
    in the patient record
  </text>
  <option>...</option>...
</ChoseOneAction>
The action itself needs to be turned into a numerator criterion.  Note: There's also a Choose At Least One Action too that I proposed.  The ChooseOne action would map to the OnlyOneTrue construction in HQMF, and the Choose At Least One Action would map to the AtLeastOneTrue construction. Here's an XSLT snippet that would perform that transformation:
<xsl:template match="ChooseOneAction">
  <OnlyOneTrue>
    <xsl:copy-of select="hed:title|hed:text"/>
    <xsl:apply-templates select="hed:option/*" mode="numerator"/>
</xsl:template>


Each of the options appears as follows and needs transformation as well:
1. Prescribe an antithrombotic

<option>
  <substanceAdministrationProposal>
    <participant typeCode="CSM">
      <roleParticipant classCode="THER">
        <code valueSet="2.16.840.1.113883.3.464.1003.196.12.1211"/>
      </roleParticipant>
    </participant>
  </substanceAdministrationProposal>
</option>
2. Document an antithrombotic that already existed.


<option>
  <SubstanceAdministrationIntent>
    <title>Document antithrombotic prescription in the patient's active med list</title>
    <participant typeCode="CSM">
      <roleParticipant classCode="THER">
        <code valueSet="2.16.840.1.113883.3.464.1003.196.12.1211"/>
      </roleParticipant>
    </participant>
  </SubstanceAdministrationIntent>
</option>
3. Document the reason for not prescribing an antithrombotic

<option>
  <observationProposal>
    <title>Document reason for not prescribing aspirin or other antithrombotic</title>
    <text/>
    <code code="G8697" codeSystem="2.16.840.1.113883.6.12" codeSystemName="CPT-4"/>
    <value/>
  </observationProposal>
</option>

Proposals don't exist in HQMF since it looks back at what was done, so we need to look for orders or events that happened.  These need to be turned into criteria that show up in the data criteria section.  The substance administration proposal describes what needs to be done.  We just change the name from substanceAdministrationProposal to substanceAdministrationCriteria and we obtain a criteria that matches the proposal.  Changing the name of an element is trivial in XSLT.  The pattern in the template for this:
<newName>
  <xsl:copy-of select='node()'/>
</newName>

At this point, we now have a measure, but we need to specify a measure period.  We'll leave that choice up to the measure developer.

There are a couple of things this measure doesn't have:

1. It doesn't distinguish between initial patient population and denominator criteria.  We could add a marker in the rule to help distinguish those.
2. It doesn't distinguish criteria that are present because they represent exceptions or exclusions. Again, we could add markers in the rule to help distinguish those.
3. It doesn't address dynamically created proposals.  You might propose for some rule, a specific medication, but also a dose that is related to the patient's weight or age.  Having dynamic criteria is a subject of another post, but this is also related to the next issue.
4. A proposal can be overridden and/or changed or customized by the provider.  The rule will often provided suggested values.  There are essential (with respect to measurement) components (e.g., the medication), and not-essential components (e.g., a text description of the reason why a medication wasn't given).  If we just turn the proposal into a criteria, we haven't addressed the essential vs. non-essential distinctions in the proposal.

This last case can be addressed in the rule, using a structure similar to how I dealt with offering choices for different medication dosing regimens.  In this case, the first part of the proposal offered the essential detail (the medication), and the options within the proposal offered suggestions for non-essential details that can be altered by the provider acting on the proposals.

Over the next week, I'll be writing this transformation, and addressing some of these issues.  What I've also demonstrated here is a very strong reason for keeping HeD and HQMF aligned as we develop both of these ballots.  HeD was asked to align itself with HQMF in my ballot comment, but at the same time, HQMF must also align itself with HeD.  I'm hoping that there is a ballot comment we can hang that on in HQMF, but if necessary, I'll take it through channels to get what we need in HL7 to keep these two ballots aligned.

-- Keith

HQMF, CDS and Health Registries for HealtheDecisions in response to @Farzad_ONC

This tweet crossed my stream yesterday...

#hitpolicy can #HITstandards for unambiguously expressing quality measures be re-used for decision support and registry? #healthedecisions
— Farzad Mostashari (@Farzad_ONC) November 7, 2012

---

I promised a followup this morning, and here it is...

At the end of Gozinta and Gozouta, I briefly identify an IHE profile that takes advantage of clinical content found in guidelines to communicate to a clinical decision support solution.  The Care Management profile used a infrequently-implemented (especially in the US) HL7 Version 3 standard for communicating and querying care information to exchange clinical data to a clinical decision support system.

One of the key features of this profile was the way that it allowed an interface to be automatically generated from data contained within a machine-readable clinical guideline. The challenge for this profile was two-fold.  One was the scarcity of implementations of the underlying HL7 Version 3 standard, and the other was the dearth of machine-readable clinical guidelines.  IHE briefly considered rewriting the profile this year to see if using different standards would enable more uptake.  IHE chose not too, mainly because of overlaps with other projects.  We felt that it would be better to engage with projects like Health eDecisions and the HL7 ballots resulting from that effort, rather than starting an uncoordinated third effort on clinical decision support.

I've been quite behind on tracking and providing feedback on the Healthy Decisions projects.  In part this is because it's calls overlap with other regularly scheduled activities, and in part, it is because I have two or three other rather consuming projects going on in various places.  In developing HQMF Release 1, I insisted that HQMF needed a place to describe the data of interest for a quality measure.  This was a direct outcome of some of the struggles I had  trying to find good ways to describe data elements that needed to be communicated in the Care Management profile.  In HQMF Release 2, this became further refined as a result of the Query Health initiative.

The data criteria section in HQMF is a way to unambiguously defining data of interest for a quality measure.  That same section structure can also be used to unambiguously defining data of interest to a clinical decision support solution, or for a registry of clinical data.  Today, systems are being developed which will read the HQMF, and will generate QRDA documents supporting quality measures.  It's equally feasible to develop similar solutions that generate other kinds of CDA documents (QRDA is  an implementation guide on CDA) which could be used to support CDS or a registry.

In developing a solution using HQMF for Query Health, one of the things that I added to the HQMF Release 2 model was the ability to reference the definition of the information model into the Data criteria section.  This, combined with the existing capabilities of the data criteria section to unambiguously define the data of interest, allows you to automatically generate a specification for a CDA Document that would include the data of interest.  The intent of the care management profile was to automate the generation of the data from the EHR to the Care Manager.  Such a system could support Clinical Decision Support, a clinical data registry, or a host of other HealthIT solutions.

A properly constructed Data Criteria section, with references to applicable CDA templates (e.g., from the Consolidated CDA specification), could easily be used to automate the construction of a document that could be sent to a patient registry.  The same document could be used, for example, as input into a Clinical Decision Support solution.  Partners Healthcare and the Clinical Decision Support Consortium (members of the Health eDecisions Workgroup) are already developing CDS solutions that accept a CCD document, and generates as a result, a response describing care activities that should occur for the patient.

Interestingly enough, the definition of both the Gozinta (the CCD Document) and the Gozouta of that CDS solution could be described using the Data Criteria Section of HQMF.  So, the answer to Farzad's question, which he asked on behalf of the HIT Policy FACA, is a resounding yes.

While I may have been late in getting feedback to the Health eDecisions Workgroup, I won't be late in providing this as ballot feedback to the HL7 CDS Implementation Guide Project that came out of the Health eDecisions activity.