In a previous post, I briefly mentioned how the U.S. Department of Health and Human Services has started developing regional networks of electronic health information. Eventually, these networks will merge into a “network of networks,” thus working toward a nationwide, compatible system of electronic health records by 2014.
Unfortunately this “network of networks” approach of regional heath information organizations (RHIOs) has some serious faults. And the alternative system currently favored by many, health record data banks, still poses a lot of unanswered questions.
According to an October report from the Information Technology and Innovation Foundation (ITIF), the major problem with RHIOs is coordination: “multiple, heterogeneous databases” require “the extensive use of middleware—that is, software used to interface between incompatible databases and data formats.” Otherwise it’s like trying to run Mac software on a PC. Other coordination challenges include accurate patient identification (is John Smith in the Bronx the same as John Q. Smith in Cleveland?) and ensuring comparable service quality—each network needs to be as fast and secure as its peers.
With all of these inefficiencies, the ITIF study notes that RHIOs don’t make a very compelling business case to the health care providers who are expected to implement and operate the networks. Most of the system’s savings go to patients (because they can expect better care) and insurers (because mistakes can be avoided) rather than hospitals and doctors, who incur all the costs of transitioning to a new IT platform—a fact of which they’re well aware. A 2006 JAMA study showed that health care providers are worried about IT transitions primarily because of start-up costs (installation, consultation, training, etc), ongoing costs (such as compliance with privacy laws—no small matter, given the ambiguity of HIPPA) and the potential loss of productivity as employees learn the new system.
In lieu of RHIOs, ITIF recommends health record data banks (HRDBs), a model that has gotten a lot of buzz over recent months—including its own bill in Congress last year.
The simplest way to explain HRDBs is via analogy: think of how you engage with a commercial bank account, and you’re on the right track. Just as you choose a bank from a competitive marketplace of financial institutions, so would you pick an HRDB provider from many vying for your business; just as you open a bank account, so would you start a medical record account; and just as you log in to access financial information, make transactions, and monitor your activity with a bank, so would the HRDB service let you sign in online to access to your medical history, test results, and so on.
The HRDB model has some upsides. First, it solves the coordination
problem by having a single repository for a patient’s health
information (the data provider you choose). Secondly, the data bank
provider is the host; your health care provider doesn’t have to set up
the system. Doctors and hospitals would deposit information in a data
bank provider the same way an employer direct deposits a paycheck into
an employee’s account—no muss, no fuss.
Data bank providers are capable of taking on this burden because they’d
be self-sufficient entities, using a variety of methods to keep
financial solvency. First, patients would be charged an access fee to
register and use the service. But HRDB companies would also be able to
generate other revenue streams. An IBM briefing from this year
notes that HRDB providers could charge patients for disaster-recovery
plans (i.e. pay to have your health records backed up), for services to
expedite the translation of paper-based records into digital data, and
most importantly for “the leasing of de-identified data for reuse by
commercial and research enterprises.”
The idea behind this information leasing is that a patient chooses to
sell his or her data to some data exchange, and if a pharmaceutical
company, insurance company, or research institution uses the data, the
HRDB splits the revenue with the patient.
For all intents and purposes, the HRDB model is based on commoditizing
health care records—it envisions electronic medical records as
something to be bought, traded, and sold through the union of competing
service providers and consumers. As you might imagine, for
consumer-driven health care reformers, HRDBs are pretty attractive. But
the case is far from closed.
We tend to assume that competition and consumerism equal efficiency—but
they also produce waste. Administrative overhead, mostly from the
private sector, accounts for a quarter of our health care spending,
often because businesses have to take into account operations that the
public sector doesn’t, e.g. two-thirds of insurance costs are
advertising and underwriting (choosing who to insure, for what, and how
much to charge them).
It’s worth considering whether the creation of a HRDB market would
replicate these problems. What will be the aggregate costs of rolling
over records between data providers? What will the price tag be for
HRDB advertising? For market research trying to attract those people
with medical histories that can be translated into revenue streams? How
much will competition translate into amenities that “improve the
consumer experience” but aren’t cost-effective? Advocates envisage
HRDBs as having a fiduciary duty to act for the benefit of their
participants, but there is still the market logic at work here—and
markets tend toward excess.
In some proposals the actual deployment and management of HRDB accounts
is done through non-profits, seemingly pre-empting the profit motive
issue. But these non-profits still contract with for-profit HRDB
providers who push their services and get a cut of the non-profit’s
revenue. In other words, a key party still wants to make as much money
as possible. Worse, this blueprint has multiple administrative levels
(non-profit and consumer, non-profit and HRDB, HRDB and consumer) that,
multiplied over and over across HRDB systems, could add to the
administrative costs of health care.
A focus on consumers can also cause some sticky situations. In the HRDB
model, the patient has ownership over his records. As the IBM report
tells us, “write access always requires two access codes (the
consumer’s and the provider’s), verification of current authorization,
and identity authentication.” But if the doctor can’t change my file—or
in fact, even read it—without my permission, what happens in an
emergency? How do I authorize record changes when I’m unconscious in
the emergency room?
A consumer-focus also doesn’t fix the RHIO problem of low take-up
rates—in fact it just expands it. Since HRDBs are voluntary
electronic health records won’t be universal. That in itself is a
problem, but is all the more worrying because of who’s likely to miss
out: those who need efficient health care the most. The poor, the
poorly educated, the very sick, and the old—all of those not familiar
with computers, without the capacity to use them, or unable to pay for
HRDB services—are the least likely to embrace the HRDB model.
Even if the federal government subsidized HRDB fees for Medicaid and
Medicare patients, it’s not at all clear that this would represent a
good return on investment. There would have to be widespread training
of the elderly; the establishment of health record community centers
and training courses in low-income neighborhoods; and so on. Training
millions of patients seems a far more daunting endeavor than training
professional health care providers.
There is a third alternative beyond RHIOs and HRDBs: a single, federal
information system aimed at health care providers. This model ensures
nation-wide compatibility, would mandate electronic health records for
everyone, and avoids many of the problems of HRDB. But it does have its
own issues—namely heavy initial costs, on the part of both the
government and health care providers taking on the data system.
Is a single system the answer? I don’t know. But we should be asking
tough questions about HRDBs, and considering alternatives, as we would
of any other major proposal. We shouldn’t let the starry-eyed language
of the market—choice, competition, innovation, and the other ostensible
cure-alls—blind us to the issues at hand. The reality is that health
care IT in the U.S. is not a done deal, even conceptually. There’s a
lot more thinking to do.