Electronic medical records

  • October 2, 2014
  • Say what you want about the big software vendors like Oracle, Microsoft, SAP, and others but if you want to peek into an alternative universe of walled gardens look no further than this article in the New York Times about how hard it is to share medical records despite billions spent on electronic medical records (EMR) systems that was strongly encouraged by the Affordable Care Act.

    The impetus for EMR was a common sense initiative to help shrink costs by significantly reducing the need for repeat medical testing. For instance, it has been common for doctors to order repeat testing when patients consult for a second or third opinion. This could mean an X-ray, lab tests, MRI or any of hundreds of medical tests and procedures.

    The reasons are simple — it’s often easier to run a repeat test in your lab than it is to get the same results from a different practice using a different EMR system. Instead of spending pennies to transmit the record, we spend hundreds or thousands of dollars in repeat testing.

    The reasons for the bottlenecks are several. According to the Times article, some EMR vendors actually have written into their contracts provisions for fees when records are produced and transmitted. But that’s just a bad business model. More fundamentally, the EMRs and many of the other software systems designed to capture patient data from analyzers for blood tests, blood banks, tissue pathology labs, scheduling operating rooms, managing outpatient clinics, and other services are all written in software technology that has evolved separately from mainstream database oriented business software over decades beginning in the 1960s.

    Back in the day, many large hospitals developed their own software for their idiosyncratic processes because few vendors were available with competent products. It’s really no surprise, because back then lots of businesses did the same. The business world settled on Cobol and mainframe computers from IBM and medicine clustered around mini-computers from Digital Equipment Corporation and Data General and a combined language, database, and operating system called Mumps which stood for Massachusetts General Hospital’s Utility Multi-programming System. Although Mumps became an ANSI standard like C, Cobol, Fortran, SQL, and a few other languages, it began falling out of the mainstream almost immediately.

    At the same time though, the Mumps community organized itself by default into a powerful walled garden as developers left their jobs in hospitals and started companies dedicated to using and implementing the technology.

    One of the big issues with Mumps is the operating system aspect. Though some vendors host Mumps under a commercially available OS like Unix, many simply run Mumps on the naked hardware. The feeling in the community is that without having a general purpose OS to push around, the applications can run leaner and faster thus optimizing the number of users able to be supported. This idea has its roots in the mini-computer era when all technology was expensive — computer memory was purchased in quarter megabyte increments, and hospitals had to squeeze every bit of performance out of their computers because budgets were tight. There were no PCs, no Internet, and not even Windows back then.

    So Mumps evolved separately from mainstream data processing producing the walled gardens we have today. One of the most insidious aspects of the walled garden is that it is self-perpetuating. The medical industry today is awash in Mumps-based systems that talk to themselves and that put up roadblocks to broader information transmission. As the Times article shows, it’s hard for two EMR systems from different vendors to share records and the result is the continued practice of over-testing or re-testing patients.

    Fixing the self-inflicted problem of Mumps will be difficult but there are approaches that can be tried. While the technical aspects of opening up Mumps can be mastered they probably will not even be attempted unless or until there is government intervention. I am not a lawyer but it seems to me that the Mumps community has, through omission more than commission, acted to keep out competition from more mainstream technologies.

    Solving the Mumps problem will likely need to start with a Justice Department inquiry and probably a lawsuit to get the industry to open up. In this regard we can probably look to century old initiatives against monopoly businesses once called Trusts that resulted in agencies like the FDA and the breakup of entities like Standard Oil into its component Seven Sisters.

    However, timing is everything and fixing this aspect of the Affordable Care Act may be slow in coming. Expect nothing in the remainder of the Obama administration, there isn’t enough time — the president likely does not have this issue in his sights, and the Justice Department is about to get a new Attorney General who will only have two years to act. Then add to this the possibility of a GOP candidate winning the presidency and the odds of action will fall precipitously. The Times article mentions how one leading EMR vendor, Epic Systems, is hiring lobbyists to improve its image on Capital Hill, which may be a preview of the fight ahead.

    Some modern vendors such as Salesforce.com have begun dabbling in EMR solutions but developing that market would be a heavy lift. Building an EMR is not rocket science, in fact it is rather simple involving a fair amount of HIPPA mandated security but the core application is essentially an imaging/PDF workhorse. However, the critical issue for any insurgent vendor would be the need to interface with the rest of the Mumps application constellation, which is sizeable.

    Perhaps the only avenue open to changing the status quo will be the marketplace. When hospital and medical providers reach a breaking point perhaps they will use their market power to influence change but that approach could soon look like a long road to a small house.


    Published: 9 years ago