The Corpus Callosum

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 apparent.

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 Firefox. 

The authors elaborate:

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 hospital 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 and forth.

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 minimal. 

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 longer around.

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.