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:
- Expressions must be easily created, edited and validated by measure developing organizations, ideally using automated tools like MAT.
- Expressions must be efficiently executed in high volume enviroments in order to compute quality measures.
- Implementing the expressions should not result in extensive investment in software crafted to evaluate them.
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.
I've only addressed ONE issue here. There are several more to go, and plenty of time later to write more blog posts.