December 19, 2016

Toward Digital Health Biographies

Robert Graboyes

Senior Research Fellow

Darcy N. Bryan, MD

Health Sciences Associate Clinical Professor at University of California, Riverside
Summary

We hope and expect that Digital Health Biographies (DHBs), or some similar concept, will help foster an era in which technological innovation can flourish. 

Many technology enthusiasts believe electronic health records (EHRs) have the potential to substantially improve health and reduce the cost of care. A broad swath of physicians believe EHRs are costly, burdensome monstrosities, draining the pleasure out of practicing medicine and profoundly disrupting the interaction between doctor and patient.

Both the technologists and physicians are correct—primarily because the EHRs physicians encounter today are not the EHRs the technologists envision. Present-day reality and future ideal are so far removed from one another that we prefer to draw a distinction between EHRs (today's technology) and the ideal concept, which we dub digital health biographies (DHBs).

One of us is a physician and the other is an economist who writes on technology. Both of us believe DHBs will be an essential component of 21st century health care. We also believe these DHBs will bear little resemblance to today's EHRs, which are needlessly souring doctors on the whole idea of digital health care tools.

But what’s wrong with today's EHRs? How would DHBs differ from EHRs? And how can public policy bridge the gap from EHRs to DHBs?

The reasons doctors hate EHRs are legion: During a typical primary care patient visit, a doctor spends half the time or more facing a computer rather than examining, conversing with, or empathizing with the patient. At the end of the day, the doctor must spend time checking over the EHR to ensure compliance with meaningful use mandates. Visually, EHRs often feature unpleasant color schemes, unattractive fonts, and tedious drop-down boxes that must be checked and acknowledged; while these complaints may seem petty, there are good reasons why software companies devote substantial resources to stylistic features. The very structure of EHRs disrupts the natural flow of a physician’s thought and analysis. And staring at an unattractive screen for half a day takes its toll on a physician, even if the content is worthwhile.

But doctors actually find the content to be anything but worthwhile. EHRs are designed more for financial and regulatory compliance than for clinical purposes. Many doctors believe EHRs are more about inputs than outputs; doctors enter the data, but prime beneficiaries, they believe, are primarily financial stakeholders, such as insurance companies and healthcare administrators. For patients, EHRs are remote and unseen.

We can enumerate a dozen principles that ought to characterize DHBs:

  • Patients, not doctors, should own the DHB and the data contained within it.
  • Each patient should have precisely one DHB.
  • A patient's DHB should incorporate data from multiple providers—primary care physicians, specialists, nurse practitioners, emergency rooms, pharmacists, therapists, etc.
  • The DHB should also incorporate data from wearable telemetry such as FitBits, insulin pumps, and heart monitors.
  • The DHB should incorporate data entered by patients, including family history, childhood illness recollections, fears, and feelings.
  • To the greatest extent possible, data entry should use natural language (ordinary spoken or written sentences) rather than structured queries (such as drop-down boxes).
  • Machine learning capabilities should extract and organize output for specific users, limiting the output as much as possible to the needs of each specific provider or the patient herself.
  • Input and output software should be recognized as very different functions, with vendors competing separately on functionality and aesthetics at the two ends of the process.
  • A common protocol or protocols should minimize the cost and difficulty of shifting from one input or output vendor to another.
  • To maximize competition among vendors, the government should not mandate or subsidize any particular vendors or data requirements.
  • DHB usage should be voluntary on the part of health care providers so the systems must continually prove their worth.
  • Clinical applications must not be subservient to reimbursement functions.

Others, such as the Standard Health Record initiative and The National Institutes of Health (NIH) have also laid out their own versions of this idea. The vision we outline here purposely mimics the development of the Internet. In the early 1990s, the federal government relinquished much control over the Internet it created in ARPANET. The government offered a standard protocol for data interchange—universally available and entirely voluntary.

A decentralized army of software developers created a vast menagerie of applications, all of which had to fight their way to success. ALIWEB, the first search engine (1993) was a stunning technological achievement, but its developers could not compete for long with AltaVista, Yahoo, and Google, which subsequently broke new ground and successively lured web-surfers away from their prior preferences.

We hope and expect that DHBs, or some similar concept, will help foster an era in which technological innovation can flourish. For this to occur, DHBs will have to compete fiercely to win the hearts and minds of physicians.