Healthcare Informatics 6/22/12

Healthcare Infrastructure Data Models
Option 2 — The Federated Model 

Option 1: The Centralized Repository is described in my previous post.

While this may evoke images of the United Federation of Planets for Star Trek fans, there is unfortunately no Starfleet here. Instead of pushing all the data to a single repository (option 1), this model lets the data sit wherever it is recorded. With this option, the desire by some institutions to keep patient health record data within their own walls is fulfilled. 

Although the data isn’t legally the property of healthcare providers, patients have entrusted them to maintain the data, mainly because we really wouldn’t know what to do with it anyway. Secondarily, we secretly hope they can do some cool visualization with it much like those that have been done for Facebook or make us all amateur epidemiologists much like Google has done. They haven’t yet, but here’s to hoping.

Given that all of the data is locked over a multitude of institutions, we need a sneaky way of coaxing it out. Therefore, to access the data, a query or request is sent to multiple locations asking if they have any patients that meet certain criteria. The system (i.e. an EHR at your local healthcare organization) then performs a subquery on its own system to find what the original query wants. For those that are SQL-minded, this is the same concept as a nested query. For those that are not SQL-minded, this is what children commonly refer to as a scavenger hunt. The end result is that each location responds with an aggregated number or numerator / denominator and all that is left is to total them up.  

On paper, this looks very fancy and is being carried out in some form on a limited basis with the HMO Research Network and potentially on a large-scale basis with Query Health. While this process is the modus operandi  of an actual bureaucratic federation ("You’ll have to fill out form 156B, then take it to the first floor department to get a stamp, then take it up to room 237 to copy it to form 198-2C…"), a computer scientist would tell you that messing about with subqueries is not the most efficient way of doing things.

In terms of record portability, this surely isn’t the most efficient process either. Sending out a mass query hoping to find information about one patient? That leads to the other looming problem: the issue of duplication and/or incomplete data. How can we be sure we aren’t counting some patients twice or missing some of their data if they travel around? We would need some unique identifier for every person in America (don’t say national patient identifier; 1% of the population will scream.)

We are also left with a struggle to analyze population data. The HMO Research Network has shown that this can be done, but each time a query goes out, there is an actual person at each location that manually looks over the query result and modifies it because “They know their data best.” 

On top of all of this, if the Query Health initiative takes hold (they want it part of Meaningful Use Stage 3) every healthcare provider will need to not only have an EHR, but have a secondary database used for querying and possibly someone manually taking a look at all of the results. Job creation and economic stimulus? Check. While this clearly isn’t the most efficient solution, it does get around some of the political problems that come along with acquiring and storing health information. However, what neither of the options so far has addressed is actually letting the patient get in on the action. 

Aaron Berdofe is an independent health information technology contractor specializing in Meditech’s’s Medical and Practice Management Suite and EHR design and development.