The New England Journal of Medicine has four open-access articles of
the topic of electronic medical records (EMR). One article
reports on a survey of the characteristics of EMR in use, and the
extent to which they have been adopted within US hospitals. The
second discussed the barriers to the more widespread adoption of
EMR. The third compares and contrasts the two models of EMR:
stand-alone personal systems, and integrated systems. The fourth
addresses the question of how to make the best use of the money
devoted, in Obama’s economic stimulus plan, to the promotion of EMR.
Use of Electronic Health Records in U.S. Hospitals
the Adoption of Health Information Technology
Doctor’s Office or the Internet? Two Paths to Personal Health Records
Change for the Health Information Economy
The New York Times has an article based upon the Journal articles:
Now that the federal government plans to spend $19 billion
to spur the use of computerized patient records, the challenge of
adopting the technology widely and wisely is becoming increasingly
Two articles, to be published on Thursday in the New England Journal of
Medicine, point to the formidable obstacles to achieving the policy
goal of not only installing electronic health records, but also using
them to improve care and curb costs…
Readers who are interested to a great extent should read the NEJM
articles. Others should just read the NYT piece, or perhaps move
on to a more interesting blog.
There is just one point that I want to focus on here, from the NYT:
…In the article [the fourth in the list at the top of
this post], identified as a “perspective,” Dr. Kenneth D. Mandl and Dr.
Isaac S. Kohane portray the current health record suppliers as offering
pre-Internet era software — costly and wedded to proprietary
technology standards that make it difficult for customers to switch
vendors and for outside programmers to make upgrades and improvements.
Instead of stimulating use of such software, they say, the government
should be a rule-setting referee to encourage the development of an
open software platform on which innovators could write electronic
health record applications. As analogies, they point to other such
software platforms — whether the Web or Apple’s iPhone software, which
the company has opened to outside developers.
In the Mandl-Kohane model, a software developer with a new idea for
health record features like drug allergy alerts or care guidelines
could write an application, and those could be added or substituted for
a similar feature…
What they are talking about, of course, is a variety of open
software. The code itself need not be open, but the application
programming interface could be. That is what it would take to
allow the kind of extensibility that they are talking about. It
would be much like the way that anyone could write extensions for
The platform separates the system from the functionality
provided by the applications. And the applications are substitutable: a
consumer can download a calendar reminder system, reject it, and then
download another one. The consumer is committed to the platform, but
the applications compete on value and cost. The Facebook social
networking site is another example: it allows users to connect their
core accounts to applications that add value for them, from family-tree
builders to programs that track flulike symptoms or encourage blood
donation. And of course, there is the Web itself, which supports myriad
applications — some proprietary, some not — many of which interoperate.
For example, users with a personalized Google home page can populate it
with widgets from Yahoo. Again, all these programs compete with each
other and can be substituted for one another, entirely and modularly.
I’ve been wanting this for years. Because of the fact that I blog
a lot, and read a lot of blogs, I make extensive use of RSS
feeds. There is no reason why the physician interface for
EMR could not be set up like a feed reader…or even be a feed
reader. I could set it up to slice and mash the data any way I
wanted, in the way that most suited the task at hand.
Rather than look up each patient’s labs individually, I could subscribe
to a feed that shows me the labs for that day for each of my
patients. I would use that in the morning. But when I am
with an individual patients, I do not want to wade through all that
stuff. Rather, I want to look at all the the data pertaining to
that patient, that have been published since I wrote my last progress
note for that patient. I would have a different feed for that.
The limitation of the feed reader approach is that it is one-way: you
can get data out, but you can’t put it in. You would need a
separate interface for that purpose. Ideally, it would be
different for different job functions. Nurses input one kind of
data, techs another, and so forth.
There is a downside to having different interfaces for data input and
data extraction. It is more complicated, for one, and for those
using a small screen, it would be difficult to go back and forth.
But a well-designed system would minimize any potential need to go back
I believe that the best way forward is exactly this approach. One
of the barriers to the widespread adoption of EMR is the training that
is needed. But most people already know how to use a browser, and
anyone you would want to have working in a hospital, is capable of
learning. Plus, when they use the Internet, they will be
practicing their EMR skills. Training costs would be
Obviously, it would be platform independent. People could use
macs, palm pilots, whatever. People who like the latest quad-core
gear, dual-monitor setups, whatever, could adapt the software to their
machines. People would are stuck with the old Pentium-III boxes
could still use them. You could use netbooks, iphones,
practically any Internet-capable machine made in the past decade or
so. And of course, individual stations could run Kubuntu or
whatever free operating system is desired. The OS would not
matter a bit, so long as it could run a browser. The days of
forced upgrades and planned obsolescence for hardware and operating
systems would be over. You would just need enough RAM, and a
decent video card, and some sort of bootable drive.
If your desktop machine crashed, it would not matter. Any
Internet-capable device could be swapped in with minimal loss of
productivity. In my view, this is a very important feature.
The second article listed at the top of this post mentions that cost is
a huge barrier to the adoption of EMR. One of the reasons for that, is
that no one wants to spent tens of thousands of dollars and get stuck
with a a proprietary system, using a proprietary data format, that ends
up being useless in a few years. Obviously, the way around that
is to not allow proprietary data formats or closed APIs. It would
not completely eliminate the risk of a system becoming obsolete, but it
would mean that any system could be kept operable for a while, with
outside support, even if the company that originally produced it is no
Of course, you cannot prevent someone from producing and marketing a
closed system, or from buying such a system. But you can limit
the kinds of systems that would be eligible for support under the
economic stimulus plan.