Where should the Query Go?

I had a different plan for today's post, but Wes Rishel's post on sending questions to the data deserves some comments.

He rightly points out that one of the data aggregation challenges is the assumption of a common model (or data scheme) for representing healthcare information.  But that really isn't a hard problem to solve if you build from existing work (e.g., the HL7 CCD, the HITSP C32, the CDA Consolidation project, or work coming out of existing SIFramework projects).

The CCD/C32 data model to use is straight forward, and all certified EHRs to date can handle it for most of the important data elements needed by public health (immunizations is not included, but most others are).  In the future, that model as revised by the CDA Consolidation project should be used when it is ready.  HL7 has been working on a model of the "Virtual Medical Record" for more than a year now (this is about the fourth incarnation of this project).  It seems like it has legs, and part of the reason for that is they based their work on the CCD this time around.

Don't be surprised if the S&I Framework develops a project to deal with this one.  That project has been on the table for quite some time; Wes seems to be re-socializing it now for ONC.  If you recall back in December of 2010, ONC outlined a set of 12 Initiatives that it sought feedback on with respect to prioritization and on the initiatives themselves.

One of the 12 initiatives was something called "Population Health Query".  The slide is reproduced as an image below:

Ignore the deadlines and the policy issues.  Assume that both of those will be dealt with at some other pay scale than mine; not that I'll be quiet about it later.  You can be almost certain I'll be talking about crazy schedules later, and that a flurry of debate will occur on policy issues, just as has happened with respect to The Direct project and certificates.

There are a couple of use cases here:

• Public Health Situational Awareness -- making it possible for public health to be aware of what is going on around them.  Infection disease monitoring, food-born illnesses, et cetera.
• Clinical Decision Support -- So broad as to be not unclear what they are talking about.  I'm assuming dash boarding applications and big data stuff.
• Quality Monitoring -- Again, very broad because they don't talk about quality of what, and as we've learned from Meaningful Use, what you ask for with respect to measures of quality can be as much work to deal with as other functionality.  Here, they are likely talking about things like monthly rate of occurrences for hospital acquired infections, and similar stuff.  OK, these involve similar kinds of stuff as situational awareness, but different time frames.
• Prevention -- To prevent is to act appropriately, and to do so requires awareness of what is happening so that appropriate prevention measures can be taken, so that really falls under situational awareness above or under quality monitoring.

The pattern that Wes describes is this:

1. A system responsible for the care of a population (call it a care manager for now) sends a query to it's subscribers.
2. The subscribers, EHR systems, HIEs, other Health IT solutions (call them clinical data sources) receives the query.
3. Periodically (depending on how the query is structured and how often the data gets updated), the clinical data source sends back a response containing the "summarized" response.

Now let me share with you a picture of an Actor/Transaction diagram from an IHE profile called Care Management.

PCC-9 is the query from the Care management system, and PCC-10 and PCC-11 are the responses back.  This profile has had little uptake for one key reason:  A standardized representation of the data to gather needs to be readily available.  IHE used the Guideline construct from the HL7 Care Record DSTU to try to indicate what data needed to be gathered, but it doesn't quite work because the Guideline portion of that DSTU was not quite done yet.

So, the challenge won't be the model (although I almost certainly dread spending months in SIFramework meetings establishing "the model").  My hope they use the model developed by the Transfers of Care project and found in the standard selected for that project.  We'll see. ONC always seems to want to reestablish consensus around problems already solved once or twice rather than forcing a choice that will be unpopular with one minority or another.

Coding and agreeing to a model are certainly critical to success.  But even more critical is coding the queries  that public health is using and starting to provide the machine readable content that developers need to use to get the right outputs from the right inputs.  And when I say queries, what I really mean is that public health needs to go back and code the guidelines that those queries are being generated for.

The proposed solution that Wes wrote about is "already decided" and furthermore is assumed to be the right model, it just needs the details filled in (e.g., the standards to use).  I knew a guy who used to end his sentences about really cool ideas with "it's just a matter of writing the code."  OK, this might be a good idea, but the devil is definitely in the details, and it presumes the solution is the right one.  Engineers know how that sort of thinking really traps innovation and can back you into a corner.

I'm not totally convinced that pushing the mining of the data onto the provider systems is the right answer (See Taking cost out of the system).  It may be useful as a method of avoiding certain policy issues (by returning aggregated rather than patient identifiable data).  But, it pushes the cost of processing these queries onto the provider IT systems, with the concomitant issues of varying interpretations of how to compute the results.  Aggregating metrics from multiple systems which have different implementations for computing them could result in some pretty unreliable statistics.   

My favorite quality measure/public health kind of numerator or denominator definition goes something like this:  Patients who not been given DRUG within TIME of EVENT, except where DRUG is contraindicated over all patients seen for EVENT.  Fill in the details with your favorite guideline and/or quality measure.  Tell me how you computed "contraindicated".  Compare your results with those of others.  And please don't make contraindicated a data element just to solve your problem.  I watched the HITSP quality measures group do just that.  But providers don't capture contraindication for a medication in their EHR.  That's the whole point.  They shouldn't have to, because the contraindication is already computable in the EHR (it might be the patient's age, other medications, allergies, or other diagnoses).

I think a more cost effective way would be to enable public health to gather the raw data needed to generate the dashboard from providers.  That gets rapidly complicated due to policy, rather than technology.  And unlike some, who worry about the communication of PHI, it's not the need for consent to access the PHI that is the big issue for public health in these systems.  They are already exempted under HIPAA for that access (unless overridden by the state, which is a problem).  The real issue for them is the amount of security they have to put into place on their end when they have PHI.  So they don't want it in many cases.

A slight modification of ONC's proposal occurs to me.  That is to support a "registry" model, something like what is already supported by some for quality measurement.  This is where providers can send pseudonomized data to a trusted third party (maybe an HIE) that public health could then query against.  That enables an either/or situation.  A provider can choose to use the trusted third party to respond to public health queries on their behalf, or they can do it themselves.  And it enables public health to be the trusted third party if they choose to do so.

Think about it.  From a public health perspective, early warnings come NOT from the ED, where you often have patients in advanced stages of disease, but from the GP where patients are in early stages. It may be easier to collect data from the ED, but the reason for that is size and volume.  From the GP perspective, adding computation to manage queries from public health A) doesn't provide them with much value, and B) isn't something they would want to invest in without it that value.  Is public health going to pay them anything to send data?  Probably not, so we need to make it feasible for them to send data to a trusted third party who has the resources do to the aggregation and computation.  That's a lot simpler for those providers.

Some might say that the value would be in their meaningful use reimbursement. If ONC/CMS were to try to put that value into MU Stage 3 reimbursement, I might remind them that providers will already gotten the biggest share of value out of stage 1 and 2 already.  And don't even think about making this a Stage 2 requirement.  That train is on its way out of the station and this effort will not be ready by the time it has vanished into the distance.

So, send the query to the data might be right, but it may be different queries to different data sources to support providers large and small.  Aggregate queries to systems that can support it; finer grained queries for systems that cannot, but are happy to let you have (and secure) their data. 

With respect to standards, I sure hope we don't try to invent anything.  There are already some pretty good standards for aggregate queries.  I'll bet everyone reading this can think of at least one query language suitable for generating aggregate results, and NO, it's not GELLO.  HINT:  It's been around for three decades.