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.” [1]
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.
REFERENCE
[1] 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
Categories: Uncategorized
Agree with the inherent logic. Economics underlies the natural tendency of EHRs to create walled gardens. Enabling information liquidity in turn enables EHR substitution (i.e. you can take your data to a competing EHR) which goes against the survival instinct of EHR vendors.
There is an Achilles heel of making patient in charge, though. Unless one has had the health-related “teachable moment” (i.e. something that makes you truly realize the value of health), most people remain in a comfortably-numb state about health. As human beings, we are not wired towards a disciplined approach to healthy lifestyle, let alone collecting and analyzing data about our health. Look at the struggle fitbit, zeo, etc. have in getting mass adoption.
Undoubtedly, it’s the patient who will be in charge finally. But it will mostly be the 20% who have had the ‘teachable moment’ regarding health. Don’t count on the rest 80% ‘healthy-right-now’ individuals initiating or requesting their data. For them, it’s an additional effort which will never reach priority enough.
EHRs were the one of the first massive viable life forms on the harsh planet of Healthcare IT. They are expected to, and have and have complied with the unreasonable expectation to handle every darn workflow that exists in a healthcare organization. Not the best way to achieve excellence, obviously, which is why all of them pretty much do an average job across the functional spectrum. HIMSS stage 7 is a farce.
My prediction – EHRs will face spectacular failure scenarios at domains like analytics, decision support, care collaboration, transition of care, PHRs etc. Once we are over the woes of standards based interop, and it starts getting commoditized, information will flow, regardless of what EHR you have (Exhibit A- Direct Project, Exhibit B – CCDA, Exhibit C – IHE profiles, etc.) The EHR vendors will restrain their megalomania to focus on local workflows like order entry, documentation, med adminstration, inventory management (pharmacy, OR, etc.), ED, etc. Vendor ecosystem will emerge around other aspects, excelling at niche value propositions. Look at what happened to PACS market – pretty cookie-cutter now.
Will happen in my lifetime… 🙂
Great post! In my opinion, you nailed the underlying problem plaguing HIT today, which is data liquidity. Unfortunately, as you note, this is not out of malevolence, but rather a natural reaction to the competitive market dynamics, and little has happened to change this…
Whether PHRs are the answer, is a different question which hinges on two leap of faith assumptions:
1) Will patients have the will-power to create and maintain PHRs, even before they need them?
2) Will data liquidity improve sufficiently to allow this?
While I do not have the answer, I think companies like Simplee and Cake Health are a strong indication of what the future holds… With technology to login to your health plan and crawl and collect data from your account, with or without the explicit consent of the health, data liquidity may just be a matter of time…
Regardless of the actual electronic health record software being used, the VA’s Blue Button initiative is the right way to go. A single button, on a webpage, that downloads most (if not all) of the important snapshot health data on the patient. Not unlike like downloading a standard file of your bank record information to the desktop of your computer. Blue Button points us in the right direction. My health information, held in one of 1100+ health record systems, downloaded as a machine readable file, at the push of a button.
Now, I’m in charge. I can upload my health snapshot to a website, into an iPhone app, or some Mint-like software, from any vendor app I choose to aggregate my health info. The Blue Button points the way towards the CMS/ONC Stage 2 requirements for clinical summaries to be made available as machine-readable exports from TBD electronic health records system providers choose to use. I suggest, that it’s not Epic vs Cerner vs VistA. All of them are just as good (and just as bad), based on the user’s experience. The important take-away is that a discharge or clinical summary be made available to me (the patient) in a machine-readable form. So that I can move this currency around the web, securely, and under my control. Now, we have liquidity in the system, and hopefully everyone benefits–foremost the patient’s health.
Q: let me ask this question: what are the fundamental assumptions the industry is making that lead very bright people to make the same mistakes over and over again?
A: There is a misalignment of incentives. The “very bright people” are all on one side, somewhat opposing the patients’ interest. These are, in no particular order: payers, institutions, and providers. There are no bad actors in this play. However, they are in business. Their business is the monetization of procedures. The host for this procedural currency happens to be the patient, positioned “someplace over there…” But the reality is that patients are only interested in their personal health and wellness, whereas other players are not comp’d on health outcomes, but rather treatments. IMHO this is a fundamental impedance mismatch. That said, once patients/consumers are dialed-in, a natural balance of power will flow back to the patient, creating a much healthier ecosystem, for all.
Yes, and incompatibility locks people into their expensive vendor.
God forbid we should use a system (VistA) built around clinical needs and not enrich a ton of private corporations forever.
Why is this? Call it “free market medicine!” It could easily be solved by adopting the VA’s (free) VistA system, but there’s more money in it if everyone does their own thing.
Even worse, like a bad version of Groundhog Day, the healthcare IT industry keeps repeating the same mistakes, and we keep working with them
let me ask this question: what are the fundamental assumptions the industry is making that lead very bright people to make the same mistakes over and over again?
Can’t take yourself too seriously 🙂
Truly excellent article, I wish everyone in HIT would read this.
Also easily the best profile picture up on THCB…
Whether the ONC has wisely or accidentally left wiggle room for innovation, flexibility, and confusion, this will all play out in the marketplace. I, like you, suggest that in our $2 trillion healthcare industry, there’s plenty of multilateral approaches for producing data “liquidity.” With 70 million boomers approaching retirement starting next year, plus chronic diseases on the rise, and some sort of healthcare reform continuously marching forward…can it be far behind that a PHR-based approach is at least a natural and inclusionary component to (finally) bringing the patient into health and wellness game, instead of the disease treatment industry? Like yourself, I vote YES. Ans, I’m looking forward to seeing what vendors come up with in response to ONC guidelines.
Not immediately, but in short order, patients WILL have access to some form of longitudinal health summary, hopefully online. And once I, as a typical patient, decide to share my health profile with my physician, there’s going to be a natural interaction between physician & patient. I won’t have to demand a behavior change from the physician, I think most of them are more than willing to participate with the patient, in treating, and hopefully healing, a patient’s ailment. We are certainly heading in this direction, and I fully expect to see it happen in my lifetime.
This is the current lynchpin or ground zero of the entire HIT-borne infrastructure of true healthcare reform, as you have described. You have described the approach we need to take. The challenge is, ONC has (possibly wisely, to allow more innovation before defining the rules of the healthcare Internet just yet) decided to defer outright regulating the HIE process. Thus, the stage is set for a continued process of multilateral development of the emerging liquidity process for data. I, like you present here, hope it is PHR-based; and that the patient will drive it (I would clarify: the patient and her chosen PCP).
There are a lot of reasons why this is the case, but I think you’re right that the demand is growing for patients to be able to (1) access their own health information in a meaningful way, and (2) have all their clinicians (physicians and others as well) collaborate on their care, even if they are in different parts of the country. I was just at the 2012 Consumer Health IT Summit where Automate Blue Button Initiative was discussed – and I think that everyone was pretty excited about the possibilities this is opens up for consumers and all kinds of healthcare providers.