Electronic health records (EHRs) offer many valuable benefits for patient safety, but it becomes apparent that the effective application of healthcare informatics creates problems and unintended consequences. As many turn their attention to solving the seemingly intractable problems of healthcare IT, one element remains particularly challenging–integration–healthcare’s “killer app.” Painfully missing are low-cost, easy to implement, plug-and-play, nonintrusive integration solutions. But why is this?
Even worse, like a bad version of Groundhog Day, the healthcare IT industry keeps repeating the same mistakes, and we keep working with these mistakes. Consultants and vendors from whom we request simple data communication solutions offer their sleight of hand, which usually recasts our problem into a profitable application integration project that simply costs us more money. This misdirection takes us down a maze of tightly coupled integrations that are costly, fragile and brittle, and not really based on loosely-coupled data exchanges, a simpler approach that allows the Internet to perform so well.
The key to unlocking the potential of EHRs lies in securely communicating (a.k.a. exchanging) data between EHR silos. If we simply begin by streaming data from EHR systems onto a common backbone, using a common currency like XML (eXtensible Markup Language), we will have solved healthcare integration in a way that works the way much of the Internet works. And this is good. When this happens, we know interoperability will work, robustly.
Clem McDonald, MD, the father of the EHR, noted in 1992 in Aspects of the Computer-based Patient Record that
“the hard part about maintaining a bank account is obtaining the money. The easy part is spending it. Similarly, it is easy to develop ways to use the information in a medical record system, much more difficult to obtain it. Yet, groups . . . spend most of their time deciding how to use the data within a computer-based patient record, and almost no time in how to obtain it in the first place. Our experience and that of others is that all the barriers to the development of medical record systems are on the input side and none on the output side. The focus [of IT] on how to use the medical record content will be moot if we do not concentrate most of our efforts on how to obtain the data in the first place.” 
Really? How much progress have we actually made in the 20 years since this was written? Our latest batch of EHR beauty-pageant contestants share data no better than mainframe or client-server apps. Clearly they’re more attractive, smartly HTML5 browser-based, progressively marketed as Software-as-a-Service (SaaS). But this represent no meaningful progress with respect to advancing patient health by leveraging EHR technology. And theres the rub. We wonder why physician adoption of records systems has been so slow?
If the mantra in real estate is “location, location, location,” then the mantra in healthcare needs to be “share, share, share.” We must stop developing vertical solutions (me-too productivity apps) and start enabling basic communication between existing systems (improve connectivity). Dr McDonald stressed the importance of first generating data currency, and only then dreaming up how to spend it. My challenge to the healthcare IT community, its VCs and startups is to fund and develop plug-and-play solutions that absorb the shock of expensive hand-coded integrations—clearly the rate-limiting step in healthcare interoperability.
Lets begin by logically placing the patient at the center—a novel concept! And let’s continue to throw caution to the wind and dive into patient control of personal health records (yikes, do I really want to bring up PHRs?). We know Google Health failed, some say in spectacular fashion. Why did this happen? Simply stated, Google was dependent on data liquidity. Liquidity which still doesn’t exist today. Data liquidity requires at least a minimal exchange of some sort of data currency. And just like in the capital markets, without these health data as currency, there can be no flow, no liquidity. Google’s legacy should have been to create standardized ways to capture and move data around the health IT ecosystem. And, any postmortem of Google Health suggests that it might have made more sense if the endeavor had started in specific and focused disease categories.
For example, Google could have started in cancer (cancercommons.org, where I serve as Chief Technology Officer), or in ALS (patientslikeme.com). Such rapid learning communities (RLCs) plus disease forums incentivize patients to participate. Personally, I have used RLCs that offer incentives for me to self-enter data and comment on what’s working (or not working) for my migraines. On migraines, I’m truly engaged. I’m completing my health profile with the same enthusiasm as I do my LinkedIn profile and my Facebook profile, so that I can share it with others, including my physicians.
In this brave new world of personal PHRs, we have a new player, a player more powerful than institutions and physicians: the patient. My records are called personal health records because I decide with whom to share my summary health profile. This really begins to sound a lot like a (useful) social health platform, where patient-controlled health summaries are no longer the strategic asset of institutions. And institutional control of my data isn’t any longer their profit center. Payer economics also shifts away from the industry’s current profit structure, around procedures, largely determined by autocratic reimbursement policies that don’t reflect either my health or wellness.
Anyone who doesn’t believe this is exactly where we’re headed is deluded. In short order, patients will control a PHR that holds a longitudinal snapshot of their health history, much like LinkedIn holds a longitudinal summary of their work history, Facebook their social history, and Equifax a financial history.
There’ll be an explosion of such apps that crowdsource, web-sites that recommend, and algorithms that shotgun your profile against data from RLCs, all in near real-time, along with repositories that support Andy Grove’s “e-trials.” True collaborations toward a patient’s health will occur when patient-provider visits are finally documented in encounter-summarized Case Reports, and integrated with machine learning, around population comparisons. These types of comparisons provide rapid and valuable insights into the factors that determine real-life drug and treatment efficacy, in preference of more evidence-based medicine. This approach offers the possibility of providing early, less expensive, and rapid signals of effectiveness in much the same way as data from a randomized trial. (que the music Boom Boom, Boom Boom from “Jaws”)
Health information exchange will undoubtedly increase machine-to-machine chatter, but this is simply a means to an end. Over time, patients won’t really care how it all integrates any more than we care about how email bounces around the web. Consumers want, nay, they need to share their health profiles. They need to talk about their health experiences, challenges, and healing strategies; to share them. EHRs weren’t built for this. Thankfully, social platforms point the way. Personally, I want an online health profile that I can share (at least in part) and crowdsource among migraine sufferers, migraine websites, mobile apps, algorithmic engines, all working in ways that inform me and my doctors about how to heal me (as opposed to how to treat me).
The advantage of incentivizing humans to resolve their own illnesses or those of their loved ones is self-evident. As in real life, it is our ability to connect that will advance patient health. And in the not too distant future, human brains and computing machines will partner to think as no human brain has ever thought, and compute in ways not approached by the machines we know today.
 Ball MJ, Collen MF, eds. Aspects of the computer-based patient record. New York: Springer-Verlag; 1992
Anil Seth is a serial entrepreneur who founded and successfully exited multiple startups in healthcare IT, specifically around electronic medical records. He’s currently incubating two startups in Palo Alto. One is a biotech: fast-tracking a prescription pill for the reduction of belly-fat in middle-aged men and women. The other is a healthcare IT startup, an interoperability device, currently in stealth mode. View him on LinkedIn