It means that the work I've been doing demonstrating implementation of HQMF for the last few weeks has been largely successful. There are now four major coding tasks. One involves the PopMedNet policy framework, another involves the hQuery back-end, and the other the I2B2 back-end. The fourth piece, which Sean Nolan labeled the "Keith Stream" of work (and which I heard as "Keith's Dream", which is a pretty good interpretation), is transformation of HQMF queries into hQuery or I2B2 implementations which can then be run against either back end.
The intention is that HQMF be the standardized, model based query specification, with an option for use of I2B2 or hQuery when something really convoluted might be needed. Both hQuery and I2B2 have query builder interfaces (whose output might be transformable to HQMF), and NQF is working on some sort of HQMF Editor (called the Measure Authoring Tool) the as well. I may build some front-end transformations so that users familiar with the existing tools could generate an HQMF in those interfaces that could run against either back-end.
I also have some hope of designing (and maybe even building) an XQuery based implementation, but that would require more resources that I currently have at this point in time.
After lunch, we started talking about the plugin model. It was then that I became very thankful that I no longer code up web user interfaces.
This afternoon, we will be discussing some details about information models and standards mapping to code components. One of the most fun conversations we had on models this morning was how we needed to look at an I2B2 *-schema, the hQuery GreenC32 Javascript object model, and the S&I Framework CIM through hazy glass to see what silhouette emerges. That's exactly what I was talking about in Models for Query Health. Given the way that CDA, CCD, and C32 have permeated throughout healthcare IT in the US, I'm pretty sure what I'll see (it's gotten to the point that I can map to C32 in my sleep or sniff out a C32-based data model blind-folded).
Updated to reflect correction on the Measure Authoring Tool.
FYI: The link in the last paragraph points to a non-existent post: "That's exactly what I was talking about in Models for Query Health."
ReplyDeleteThe initial emphasis with greenCDA appeared to be facilitating *generation* of CDA documents -- thus the inclusion with the implementation guide of an XSLT 2.0 transform for converting greenCDA to standard CDA, but not for transforming CDA documents to greenCDA documents.
ReplyDeleteI am specifically interested at this stage in *querying* CCD documents to pre-populate data needed in a CDS application, and a greenCDA representation of the data would make this easier -- and easier to explain to others. The current context is "per-patient", but aside from that my problem is broadly similar to that of Query Health.
What about this? Are tools for transforming CCD instances to greenCDA instances already available? Is this receiving greater attention in connection with Query Health?
Anon: Somehow that got put back in draft, it's back up now.
ReplyDeleteChris: You might have a look at some of the work Robert Warden has done.
As to the query capability, you could take what I've done with XQuery and CCD and use it with Green CDA just as easily, it's just another implementation.
I'm definitely thinking about a different approach.
Incidentally, see this policy perspective from an Oracle Healthcare VP (via NHINWatch).
ReplyDelete