The Future of Healthcare Informatics: It Is Not What You Think

Abstract

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. One problem that seems particularly challenging is integration. Painfully missing are low-cost, easy to implement, plug-and-play, nonintrusive integration solutions—healthcare's “killer app.” Why is this?

We must stop confusing application integration with information integration. Our goal must be to communicate data (ie, integrate information), not to integrate application functionality via complex and expensive application program interfaces (APIs). Communicating data simply requires a loosely coupled flow of data, as occurs today via email. In contrast, integration is a chief information officer's nightmare. Integrating applications, when we just wanted a bit of information, is akin to killing a gnat with a brick.

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. One problem that seems particularly challenging is integration. Painfully missing are low-cost, easy to implement, plug-and-play, nonintrusive integration solutions—healthcare's “killer app.” Why is this?

We must stop confusing application integration with information integration. Our goal must be to communicate data (ie, integrate information), not to integrate application functionality via complex and expensive application program interfaces (APIs). Communicating data simply requires a loosely coupled flow of data, as occurs today via email. In contrast, integration is a chief information officer's nightmare. Integrating applications, when we just wanted a bit of information, is akin to killing a gnat with a brick.

Even worse, like a bad version of Groundhog Day, the healthcare information technology (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 the problem into a profitable application integration project that simply costs more money. This misdirection takes us down a maze of tightly coupled integrations that are costly, more complex, and not really based on loosely coupled data flows, which is the technology that allows the Internet to work so well.

The key to successful integration lies in simply communicating (or integrating) data flows between EHR silos. If we 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. This is good. When this happens, we know it will work quite 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 computerbased 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.¹

How much progress have we actually made in the 20 years since this was written? Our latest batch of EHR beauty-pageant winners share data no better than mainframe or client-server apps. They're simply more attractive, often HTML5 browser-based, even marketed as Software as a Service (SaaS). But they represent no real progress with respect to advancing patient health through EHR technology.

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 applications (ie, better silos) and start enabling communication between existing apps. 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 venture capitalists, and startups is to develop plug-and-play solutions that absorb the shock of hand-coded integrations—clearly the rate-limiting step in realizing widespread healthcare interoperability. My frustration with this community is its continued insistence on funding or developing only the more interesting elements of the ecosystem but forgetting the mandatory infrastructure on which it is all predicated—a problem similar to that of building an interstate freeway system but forgetting the on-ramps. There exist no easy on- or off-ramps that allow EHR silos to move data onto or off of an emerging data grid. Outside of very limited healthcare enterprises (eg, cancer treatment), it's premature to build evermore “me too” vertical apps. When it comes to data flows vs feature-rich applications, we need simple mechanisms for snippets of health information to move out of EHRs, onto the backbone, in a plug-and-play fashion: solutions so elegant that they shift our focus from plumbing to process (ie, from IT to health and wellness). In healthcare, there are still too many modern cities connected by dirt roads. Communication continues to be the search for the holy grail.

We could begin by 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 (PHRs). We know Google Health failed, some say in spectacular fashion. Why did this happen? Google was dependent on data liquidity and flow, which simply didn't exist. Data liquidity requires data flow and some sort of data currency. And just like in the capital markets, without these 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 ecosystem. And any postmortem of Google Health suggests that it would have made more sense if the endeavor had started in specific and focused disease categories.

For example, it could have started in cancer (cancercommons.org, where I serve as chief technology officer) or in ALS (amyotrophic lateral sclerosis, 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 enter data and comment on what's working (or not working) for my migraines. Once this happens, I am engaged. At this point, I am 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 or 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 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 profitable. Payer economics then shift away from the industry's current profit structure around procedures largely determined by autocratic reimbursement policies that don't reflect my health or wellness.

Anyone who doesn't believe that's exactly where we're headed is deluded. In short order, patients will control a PHR that holds a summary of their health history, much like LinkedIn holds a summary of their work history, Facebook their social history, and Equifax their financial history.

The PHR need not include every health detail ever recorded about me, just a snapshot. Let's begin with the data elements that satisfy Medicare and Medicaid's Electronic Health Record Incentive Program, Stage 2 (42 CFR Parts 412, 413, and 495): “Provide clinical summaries for patients for each office visit … within 24 hours … [including] current meds, problem list, vitals, labs, immunizations.” Such XML messages will make their way to my PHR, much the same way that email messages arrive in my inbox. In this model, it all just works. Websites and apps can then use these health profiles, helping patients diagnose chronic conditions that don't fit into easily diagnosable ICD-9, 10, or 11 classifications.

There are emerging apps that crowdsource, websites 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 encounters are finally documented in 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. This approach offers the possibility of providing rapid signals of effectiveness in much the same way as data from a randomized trial.

But this model also flies in the face of medicine's reductionist approach, which really only worked in the presence of strong relationships between cause and effect (eg, strep throat, fractures, human epidermal growth factor receptor 2). EHR silos are suited to only this precision medicine and are ideal for intra-institutional transactional needs and for diagnosable illnesses (top-right quadrant, well-characterized issues). The epidemic of chronic disease with multifactorial causes and individualized treatments (eg, migraine, obesity, chronic pain, allergies) illustrates that medicine is an art as well as a science. This shifts our need from transactional EHRs to more rapid diagnostic tools (both machines and humans).

EHR vendors and most healthcare institutions implement technology that is as impersonal as possible: not portable, not interoperable, no standard-format profile I can own, control, and share. Why is that? Economics. It's simply not in their interest to share with other providers in other systems to help them care for their patients. I'm left feeling that my data aren't used to keep me healthy but rather to keep me locked in their walled garden. This puts the system at direct odds with me. And the reality is that we'll never create a vibrant ecosystem without having the incentives correctly aligned. Like it or not, patients will eventually own some fashion of their health profiles. So while the industry isn't looking to share, people are. Some are literally dying to share their health information with any person, group, or even a machine that can help save their lives.

Integration is important to increase this machine-to-machine chatter, but it is simply a means to an end. Over time, we won't really care how it all integrates any more than we care about how email bounces around the web. Consumers want to share their health profiles. They want to talk about their health experiences, challenges, and healing strategies and share them. EHRs weren't built for this. Thankfully, social platforms point the way. 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 selfevident. 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.