Aaron Berdofe, MHI – Health Informatics

Reposted from HISTalk Practice.

Let’s assume for a moment that the current craze surrounding EHRs is completely effective and every physician in America is meaningfully utilizing one in the near future (hurray for blind optimism!). There are two purposes for doing this, despite the numerous reasons that have been thrown out there.

One is the public health motivation, where we can query all healthcare providers and come up with aggregated metrics to better understand the health status of those who seek care. This would probably be as close to real-time analysis that we can get to for a while. Post-analysis, we can provide better recommendations for best practices and get those implemented a lot faster than the current glacial pace. This is in fact why most other industries made the move to digital: to measure, analyze, and make improvements based on the analysis.

The other PH motivation is for record portability. This one gets all the press, probably because journalists can tie it to the ‘P’ in HIPAA and it is one of those things the general public is generally confused about why this is not already possible in the first place.

Given these two purposes — aggregated counts and whole (or at least CCD) record portability — how are we going to achieve both at the same time? Three options have been knocked around for quite a few years and we’re finally getting to a point where they may be realizable. Needless to say, this is a very exciting time, but what are we getting ourselves into?

In this three-part series, I’ll be taking a look at the top contenders, but I will warn you that the answer/the solution is always a combination of the options available.

 

Option 1: The Centralized Repository

All data gets sent to a single local database which then gets passed up to a larger database and so on and so forth. Honestly, I think this is the model that a large number of people assume will be put in place when we talk about “information” or “data.” Yet keep in mind this is not how the Internet works.

This more replicates the mainframe days of yore or a wagon wheel metaphor, where the information all flows to the central axle. Visually it is clean, but perhaps not in line with today’s infrastructure reality.The big positive of this model is that it would be insanely easy to analyze the data out of the database and to send aggregated numbers up the chain.

Public health departments generally work from disparate registries that are nothing more than centralized repositories specific to their concentration (i.e. cancer, vaccinations, STDs, etc.) This is why you send your vaccination data to the state vaccination registry and not just to the public health department’s main office.

So why not just have a big ol’ relational database that everything gets sent to and pull what you need from there? The allure of easy analysis is probably why the ONC has started a number of Beacon Programs across the nation. The negative is that… well, no one really trusts the government to do these sorts of things.

Additionally, record sharing between these centralized repositories is still a bit of a hang-up. The Beacon Program in SE Minnesota, for example, connects various healthcare organizations through an HIE and the NwHIN to pass records throughout the area in addition to dumping everything into a centralized repository.

In the end this, model embodies a Bon Jovi song, only putting us halfway there. Analysis: yes. Record portability: no.

 

Option 2 — The Federated Model

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.

 

Option 3 — Health Record Banks

Think Google Health or Microsoft HealthVault with an actual business plan. The patient controls access to their data and pushes it or allows it to be pulled at their request. Admittedly, I hadn’t heard of this concept until the founder of the Health Record Bank Alliance told me about it, so I can’t say this model is just around the proverbial corner.

When we philosophize from our arm chairs about how healthcare should be, one particular theme always bubbles up: the patient should control their health and their health information. But have we accomplished that, even with the concept of a Patient-Centered Medical Home?

Right now, our healthcare system is centralized. This means that if we go to a well-organized institution, our information and services will center around us as long as we don’t leave. But if the industry follows the disruptive innovation pathway laid out by Clayton Christensen in The Innovator’s Prescription, we will eventually arrive at a decentralized model of healthcare. That means the hospital-centered healthcare will become passé. It also means we need to find a way to deliver patient health information to the practitioner on demand. As in, it is stored with the patient, not the provider.

Personal Health Records (PHRs) would seem to be the obvious solution to this. Due to a lack of record portability and motivation, they have turned out to be duds even to data geeks like myself. I once logged every time I picked at my fingernails and what I was thinking about at the time in order to figure out how to break the habit (willingly), but I logged into my Google Health account (RIP) exactly twice.

The portability issue will be resolved, and thank Meaningful Use for that. Motivation, though? Most of us don’t actively track our health status. We wake up, we subconsciously determine whether we have it in us to survive the day, and then we get moving. A Health Record Bank could potentially provide motivation in the form of payment opportunities.

Let’s say you received a micropayment every time an organization queried your health record for research, public health assessment, or even marketing information. Not enough revenue to generate a career, but it could buy you coffee every now and then. All you’d have to do is maintain your record like you do your checking account. Would that be something you’d be interested in?

Record portability? Yes. Public Health assessment? Yes, with payment. Consider it an incentive payment going to the right people.

Given these three models — the centralized repository, the federated query, and the health record bank — which is the one that will be used moving forward? Even though the proponents of these models act like they are competing models, are they not complimentary in some fashion? Centralized repositories are great for in-depth analysis once the data is actually gathered. Federated queries are good for a small network to share data. Health record banks motivate the originator of information (the patient) to give up the data and spread it in addition to establishing ownership.

An EHR in the hands of the majority is the first step to setting down this path, where these models can interact. But make no mistake, it is not the last. Eventually, EHRs will become the processing tools to send information for expert analysis, not from which to extract information.