In November, a month after joining ONC’s Query Health Technical Workgroup (TWG), I introduced our first prototype for Query Health. It consists of a pair of desktop spreadsheet-based programs (apps) that enable a requestor (the entity who wants certain patient data from providers’ EHRs) to create an SQL database query (a specialized language for updating, deleting, and requesting information from databases). This disruptive innovation is then able send that query, via a Direct Project e-mail attachment, to recipients who use a corresponding app behind their firewall to extract the data the requestor wants (i.e., the data “payload”) from the EHR (i.e., the “source database”). The recipients then send the payload, via Direct Project e-mail, back to the requestor. Although the prototype works, it was rejected by TWG members because it required that the requestor app know the schema (i.e., structure) of the source database before the SQL query could be run.
To address that issue, we began working on a second prototype a few months later, which was completed in March 2012. This new prototype is very different from the first because it uses Excel PowerPivot software to consume standardized CCR/CCD XML files (CCR defined, CCD defined that are generated by EHRs. This disruptive technology then calculates the results. In a typical query, these results consist of a few numbers (which could be a challenge to compute):
- The denominator indicating the target population, i.e., the total number of patients in the EHR database meeting certain criteria (e.g., patients in a certain age range with a diabetes diagnosis, who take medication for it, and have been hospitalized in at least one time in an acute inpatient hospital or ED within a certain time period OR had at least two outpatient or non-acute inpatient encounters during that time period)
- The numerator indicating the number of patients in the target population for whom a specific event occurred during a certain period of time (e.g., having an hemoglobin A1c lab result greater than 9 percent)
- And possibly exemptions and exclusions indicating the number of patients in the target population that have not been included due to certain predefined reasons.
Our solution performs the query, calculates the numbers, and is able to return the results to the requestor via Direct e-mail.
We wrote about our prototypes on the Query Health wiki at this link and included videos and links to downloads.
During a subsequent TWG meeting, I then requested permission to present our second prototype to the group. Despite being the only implementation that actually works, I was not allowed to inform others about it because we did not comply with the Query Health approach (standards and specifications).
The TWG leaders would not change their approach even though, months earlier:
- We posted to the group’s wiki a page detailing the changes to their approach we require in order to qualify as a viable Query Health solution and
- I objected to the approach during the consensus voting then dropped my objection after being convinced via an offline conversation with group leaders that the approach is flexible enough to allow novel “overlay” implementations.
Without diving deep into the technical details, here’s the situation today: Not a single query has been done by the TWG using their current approach, nor will any be done in the foreseeable future. A half year ago, however, our successful disruptive solution completed one of the most demanding queries—the NQF 0059 clinical quality measure for diabetes control—yet it remains forbidden to be seen or discussed by the TWG!
So, what has the workgroup been doing all this time?
Well, several TWG members have been working for months to develop three complex XML translators. As best as I can understand, these translators are required by two web-based tools—i2B2 and hQuery—that have been developed with Federal monies and that have relationships with certain TWG members. The decision to use these tools, along with the PopMedNet Portal for data transport (also developed with gov’t grants), was made at a face-to-face meeting in Washington DC in Nov 2011 (I did not attend; I was informed of their decision via a private follow-up phone call). These tools are supposed to work in conjunction with the translators to change various forms of XML code into other forms of (XML) code.
The first translator is called the “intermediate translator.” It was conceived because the Health Quality Measures Format (HQMF) XML code was just too complex to be transformed into procedural code (like SQL) for executing a query. This translator is supposed to reduce the complexity of HQMF XML; they’re still working on it. The second translator is supposed to transform the XML from the first translator into the procedural code; I do not believe much has been done with this yet. And the third is supposed to translate the query payload into Quality Reporting Document Architecture (QRDA) XML code; still waiting for its construction. And all of this is supposed to conform to the Health Level Seven (HL7) Clinical Document Architecture Release 2.0 (CDA). Oh, forgot to mention one more thing, also needed is a “Query Envelope” to facilitate the secure exchange of queries and results.
Now that’s what I call COMPLEX!
A few other things to consider:
- It appears that the organization responding to a Query Health request must do all sorts of complex mapping before the query can be run.
- I'm not yet convinced that, if & when all this work is done, the current TWG approach will be successful since there are still difficult mathematical computations that must be done to complete the Query Health process.
- Several people in the workgroup, including myself, gave a NO vote to the HQMF consensus round 1 and here’s a link to my critique of HQMF XML, which explains why XML is not right data model for Query Health.
- The TWG is not focusing on using Direct Project protocols for transmitting queries and results.
- There are several Query Health pilot projects underway, even though the primary tools necessary for a compliant implementation have not yet been developed.
I contend that disruptive innovation is required to bring about meaningful change!
Our disruptive Query Health solution has NONE of the complexities I discussed above, and it works! To implement our approach, all that’s needed on the requestor and responder ends is a desktop or laptop computer loaded with MS Excel and the free Excel PowerPivot add-in. To make our solution Direct Project compliant, just add MS Outlook that operates in conjunction with our partner HISP. Best of all, IT WORKS!
Addendum: Here's an article from 4/22/13 that confirms what I said above.
My next post (within a few weeks), will examine a disruptive innovation business strategy we’re about implement that is consistent with our vision of how to reform healthcare sensibly and sustainably