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.

Thursday, May 9, 2013

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.