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.
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.
Keith,
ReplyDeleteThanks for sharing your thoughts and ideas.
Wanted to clarify one of the key issues about HeD. HeD is not intended to be interpreted as-is, though one could do so. An important design requirement for HeD is that HeD artifacts be translated into the native artifact format of the target CDS system. This approach, we believe, would not require investment in a new CDS system or enhancements to the existing CDS system. There is an investment required to translate the artifacts. That work is being done already in an inefficient way; either by building many-to-many translators from several knowledge suppliers to several EHR systems, or the artifacts are being translated manually. Also, because the execution is occurring in the native CDS system, the performance efficiency is not dependent on the HeD schema, but rather on the host CDS system.
A difference in the two approaches seems to be that HQMF requires or recommends a specific implementation engine (based on javascript) and HeD assumes that the implementation engine exists and will not have to be changed to support an HeD artifact.
The QDM guide for HQMF suggests an expression language for implementation, it does not require its use.
ReplyDeleteAs an expression language, I was talking about the use of HeD's language in the context of use for quality measurement.
HeD's assumption of an implementation engine in its context implies assumptions about the implementation capabilities that may differ in the quality measurement evironment (which could be less demanding that the CDS environment).
For effective translation in either place, we must, as I said above, provide NEW code that performs the translation to the implementation environment. The engine may not have to change (assuming it has the necessary capabilities assumed by HeD), but that doesn't mean the development work need not be done.
I agree with the comment above. But I cannot reconcile that with the assessment of HeD along the three dimensions in the post. If you are translating it to the implementation environment, then the performance is (much more) dependent on that implementation environment, not on the source artifact's format.
DeleteAnd if one executes the measure or the CDS in the native implementation environment, then the ubiquitous availability of javascript engines does not seem to matter, and should not impact costs. I think I might have missed something here.
Hi Keith,
ReplyDeleteGreat post, and I agree with much of what you've said here. As far as a way forward for harmonization, I wanted to comment on the proposed approach. I think a key difficulty in discussing harmonization of HQMF and HeD is the use of the term "expression language." In an HeD context, the expression language is used to express all the decision support logic, and the artifact format is just a container for delivering that logic. So this includes all the external data criteria, the applicable scenario, as well as any relevant computation, arithmetic or otherwise, that must be performed as part of that logic.
By contrast, in HQMF, the term "expression language" seems to be used to refer only to those aspects of the logic that involve scalar computation such as arithmetic expressions. However, in an HQMF artifact, the data criteria and the applicable scenario are also part of the measure logic, but instead of being expressed in the same language as other computations within the artifact, they are expressed as part of the container definition. This means that any implementation of HQMF must deal with both the logic "language" as represented in the data and criteria sections, as well as the expression language used to deal with scalar computation.
I think one of the key aspects to the approach that HeD takes is that it uses the same representation for all logic within the artifact, instead of trying to break the criteria out into a separate component. This results in much simpler implementation, whether that implementation is a native evaluation engine, or a translation to another target format for actual execution. In HQMF, why not use the same expression language to represent both aspects of the measure?
Thoughts?
Oh yes. Definitely. But that will have to be a longer post, rather than just comments.
ReplyDelete