#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.
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.
Keith,
ReplyDeleteYour post touches upon the two use cases that Health eDecisions is pursuing.
So far, we have worked on Use Case 1, which is the sharing of CDS "artifacts" that can be imported or integrated into a CDS, CPOE, or Clinical Documentation system. We are defining a schema that can be used to construct rules, order sets, or documentation templates. The Health eDecisions schema (HeDS) is following a similar approach to what you have described: it defines an explicit data criteria section for the CDS artifacts. While the schema itself doesn't constrain which data model is being referenced, the Implementation Guide will specify the VMR as the data model. There now is an ongoing conversation to harmonize the different data models (VMR, QDM, and such) that are being used in the complementary domains of eMeasures and CDS. I look forward to contributing to that effort.
We will start work on the second Health eDecision use case soon - likely next month. This use case is for a CDS service that will take patient data as input and return care recommendations as output. It makes perfect sense in that case to use the document types you mention to transport patient data.
Aziz
I'm aware of the two use cases. Data Criteria is pertinent to both, and it would be great if the XML was the same as is used elsewhere to describe data of interest.
Delete