Beware an impending e-records train wreck

I have some experience in health care information technology systems, having built an early stage telehealth system called Teleprovider in 1996. That system managed patient records, enabled videoconferencing for tele-consultations, facilitated collaborative whiteboarding and handled images compliant with the Digital Imaging and Communications in Medicine standard.

I learned a lot from that experience and enjoyed working with the doctors at Stanford University and Samsung Medical Center. Seeing the doctors use my nascent Java whiteboarding application — remember this was 1996 — for a tele-consultation between the university and a Korean hospital was especially rewarding.

Thus, given my interest, I recently joined the Healthcare Information and Management Systems Society and have been trying to untangle the convoluted web of health care data standards. My attempt to understand this mess has been unsuccessful so far. And if someone like me — someone with years of experience in IT and a small amount of experience in health care — can’t figure it out, where does that leave the average person?

For now, even from my limited vantage point, I see two trends that concern me: use of outdated technologies and limited transparency.

First, let’s examine the issues around outdated technology. On July 28, the Health and Human Services Department posted its final rule on the initial set of standards for electronic health records (EHRs). Two points in the rule stood out: First, in response to comments, they removed the adoption of Simple Object Access Protocol (SOAP) and Representational State Transfer (REST). So, whereas the majority of industry and government is moving as fast as possible to adopt those Web-based technologies, our so-called modernized health care system will need to stick with its hodgepodge of protocols.

Second, there was the selection of many Health Level 7 standards, including some based on Electronic Data Interchange. EDI is binary-formatted — newer versions are text-based — pre-Internet, pre-XML, 1970s technology. Given that Extensible Markup Language has been a standard since 1998, this is outdated technology.

Before you say, “But it works,” remember that “working” from a user perspective does not mean there are not serious negative ramifications for continued use of an outdated technology. For example, I can still send messages using paper and postal mail, but it is much more efficient to use e-mail. And as the years pass and improvements in technology continue to pile up, the performance gap between old and new technology grows exponentially. Welcome to Moore’s law.

An even more egregious example is the Veterans Affairs Department’s Veterans Health Information System and Technology Architecture for EHR. VA is pushing this as the future of EHRs, but it is built upon a prerelational database, pre-object-oriented, 1960s-era programming language called the Massachusetts General Hospital Utility Multi-Programming System. If you examine the Wikipedia page on MUMPS, you will see a sample program that is in violation of almost every modern best practice for programming. I am flabbergasted — a 1960s programming language as the future of health care. Wow.

And let’s briefly examine the issues around transparency. Why are HHS datasets on the department’s own website instead of Data.gov? That defeats the purpose of having Data.gov. And HHS has selected a set of standards that the public does not have access to because HL7 charges to view its standards. Why not select a standard such as openEHR that is free to the public? HL7 also has been criticized by Barry Smith, whom I have worked with and respect. Data standards for something that will affect every recipient of medical care should be available for public review.

Frankly, I think an EHR train wreck is possible unless HHS gets serious about tackling these issues. I readily admit that I am still a novice in this domain and am happy to be proven wrong on these issues. Of course, there is really only one way to find out — let’s see the road map to replace outdated technologies — and, more important, show us the data standards.

inside gcn

Reader Comments

Thu, Sep 30, 2010
augiet

M is natively NOSQL, but if you want SQL it's there, if you want objects that's there too. EHR's are a mess in general, the VA's is very good and has improved healthcare for our vets immensely. We have the stats to prove it. Medicine and EHRs need more sophisticated software there has not been an adequate blend of comp sci and medicine. EHR's can tell you what happened, but we need better predictive technology and population stats built in to really improve treatments. This is the frontier, but you have to walk before you run.

Fri, Sep 24, 2010
K.S. Bhaskar
On the Surface of Planet Earth

So the author likes his favorite buzz-phrase technology, and doesn't like other technology. To him, whether or not a system works is back seat to whether or not it is made with his favorite technology. Yes, of course, the world is on his bandwagon!

Fri, Sep 24, 2010
Rob

Yes, Mumps includes a language (it's primarily a database though, and one the NoSQL guys are rapidly and accidently reinventing!). The example in Wikipedia shouldn't be thought of as an example of how a modern programmer would write Mumps code. At the time that code was written, it was optimised to run faster than anything else at the time on PDP processors that had less processing power than the chip in your toaster in your kitchen.
Since that time, the Mumps language has actually included for many years everything needed to support modern programming practices and, when written and used properly, bears an uncanny resemblence to Python and can be just as well-behaved, understandable and maintainable.
So please don't judge a language (that you really don't know much about) by a 30-year old example of code. There's plenty of examples around of dreadful coding in even the most modern of languages.
There's no reason why ongoing modernisation of the VistA code in Mumps shouldn't be extremely effective, and it's a damned sight less risky than trying to rip and replace the whole lot to a "more modern" language.
Rob

Thu, Sep 16, 2010
CJ

I suspect HHR isn't required by law to do so, but their program managers and the folks writing their system development contracts should seriously review CJCSI 6212.01(latest) on interoperability requirements. It's not an easy instruction, but there are additional resources to help interpret. It's not an easy approach either - but it's easier and cheaper than cleaning up a train wreck. Time to pull up the big boy briefs and get to work.

Wed, Sep 15, 2010
SW
California

Excellent analysis. HL7 shouldn't be singled out. ASC X12 the home of most EDI standards is just as obsolete. What's even more appalling is the resistance the volunteers and most consultants whom develop these obsolete standards put up to block the development, use, and implementtion of true open standards that can be used nationally and internationally.