Can we get a little bit more coordination please?

There is both too much and too little going with the SI Framework Query Health that I'm tempted to submit an IHE Profile proposal that overlaps with the use case and an HL7 Project Scope Statement on the same topic just to ensure that some coordination happens. It would be so simple for ONC to use these mechanisms to encourage engagement, but I don't think that would ever occur to them.
I will probably bring the topic up for the HL7 Coordination with Other SDO's panel session in September to see if there is something that could be done to improve the situation.

Several people this week were frustrated over ONC's scheduling of the Summer Concert Series, especially as it overlaps with the Public Health Informatics Conference in Atlanta, where most of the people that Query Health is supposed to serve are. There are no sessions here on what Query Health is. And the Finale of the Query Health summer concert series is being held when an important member of the desired audience is out of town for most of the week.

---

OK, now that I have that off my chest, I did have an interesting discussion about Query Health over a fantastic Omikase style dinner at MF Sushibar.

There are a couple of challenges with "sending the query to the data" which Query Health will need to address. The first challenge is scalability. The second is coordination. The third is overlap with reporting.

With regard to scalability, I can imagine the number of queries getting quite large. I don't think that it will be feasible to process a large number of queries if they aren't designed to be very efficient. There are some techniques that can be used to enable the system to operate linearly in the size of the records being queried, rather than on the number of queries being performed. But that means that the queries need to be aggregable, so that multiple queries can be run at the same time, sort of the way that the Unix egrep tool can very efficiently search for a number of strings. But that does mean that the queries need to be pretty simple to support the aggregation of them.

The second piece that needs to be addressed is coordinating results in a timely way. I don't see query health being used effectively for a national outbreak of H1N1. But I do see it being used in other ways. Even so, unless the query is truly computed the same way, there could be some challenges in interpreting the results. I'll give an example. In one case, HEDIS measures for one region in a state were way off. It appeared that Women weren't getting routine laboratory tests done that should have been. The problem was traced back to the fact that when test A was ordered, test B and C were done reflexively (automatically). But the measures were computed based on what was ordered, not on what was reported on. That variance in interpretation caused the results for one region to be so badly off that it was readily identified. But I suspect more subtle implementation decisions could wind up introducing other variances that are not so easily detectable. It needs to be looked out for. The key here is to ensure that the queries are simple enough that there can be no real differences in the results introduced by differences in implementation. Aggregation is one of those spaces where it could be challenging to produce results that don't exhibit that problem.

Finally, there is the overlap with Public Health Reporting. Ideally, I'd like to the same specification used to describe computable representation of the data needed for a report as for a query. In the first case, that representation describes the data outputs of a system. In the second case, it describes the inputs to a computation. I can use the gozouta of one as the gozinta to the other. That will be extremely powerful for not just "public health query", but as a way to define interfaces in general.

That would enable interfaces for all kinds of <a href='http://wiki.siframework.org/Public+Health+Reporting+Initiative'>public health reports</a> to be generated automatically in software. That might put a lot of interface engineers out of a job, but I'm certain that in the current environment, there will still be plenty of call on their skills for other projects.  Because as soon as you turn around, there'll be another initiative.  I'm having trouble keeping up, and unlike many other standards geeks, that IS my day job.