Is MUMPS Infecting EHRs?

EHR Language Series MUMPS

CareCloud’s Ahmed Mori questions the effectiveness of the MUMPS EHR programming language in healthcare.

The word ‘mumps’ has two meanings in the healthcare industry. Most popularly, mumps is a virus characterized by a painful swelling of the salivary glands, and is rather contagious.

Its other usage is an acronym for Massachusetts General Hospital Utility Multi-Programming System, a programming language that is almost equally contagious among healthcare IT companies.

However, not every health IT professional understands why so many electronic health records are still written using the language. Below we question the effectiveness of the MUMPS programming language.

Why Has MUMPS Survived This Long?
MUMPS was created in the late 1960s, which represents centuries in terms of technology. The language was adopted during the next two decades in healthcare and financial information databases. Even in the 2000s, a number of commercial EHR vendors are pushing systems written in MUMPS.

In 2011, the Axial Project wondered why MUMPS has been so effective in the healthcare field, attributing its success to the reliability of legacy applications. This makes for an innovation drought in the industry.

In other words, it may not be a question of why MUMPS has survived. We should instead address why innovation is so stagnated in healthcare IT.

Is MUMPS Valuable?
At first glance, enough commercial electronic health record companies are using MUMPS to justify its value. However, a huge portion of these promote client-server EHRs, which a number of industry professionals predict will fade in light of cloud-based systems.

MUMPS proponents often cite the B-Tree data structure as a testament to the language, admiring its elegance, quickness and scalability. Still, the International Data Corporation (IDC) estimated the amount of worldwide storage data will reach 2502 exabytes (or 1 million terabytes) by the end of this year.

Can MUMPS handle the issues related to the heavy access log and data storage and searching issues resulting from this enormous amount of data?

If MUMPS is stagnating innovation, it’s important to find an alternative. Many industry professionals believe NoSQL could work well as a viable substitute, and an increasing number of more lightweight and inventive EHR systems are being carved out using Ruby.

MUMPS and Interoperability
A number of industry professionals believe MUMPS will be weeded out as doctors and hospitals continue to implement electronic health records, namely because MUMPS-based systems don’t play nice with EHRs written in other languages. There is a reason why the Silicon Valley folks aren’t too fond of the language.

If MUMPS truncates communication between systems, then it hinders interoperability, a cornerstone of EHR adoption. One of the goals of health IT is to avoid insularity, so unless your practice or hospital’s goal is to adopt a client-server enterprise system with limited scalability – and you don’t care much for interoperability – MUMPS may be an option for you.

But it doesn’t have a place in the future of healthcare.

Image credit: nyuhuhuu via cc

Article first appeared on CareCloud’s Power Your Practice blog. CareCloud is a leading provider of cloud-based practice management, electronic health record and medical billing software and services. 

Is MUMPS Infecting EHRs? by

Get in-depth healthcare technology analysis and commentary delivered straight to your email weekly

  • http://twitter.com/Ziegenpeterchen/status/329094145643798529/ @Ziegenpeterchen

    Is MUMPS Infecting EHRs? http://t.co/VGbNmpP0Sf

  • http://twitter.com/HospitalTech/status/329104243904622592/ Hospital Tech (@HospitalTech)

    Is MUMPS Infecting EHRs? http://t.co/R9ZxSNAa8G

  • http://twitter.com/ahier/status/329232150358544384/ @ahier

    Thought provoking post >> Is MUMPS Infecting EHRs? http://t.co/x1Hz6yaWDo

  • http://twitter.com/fbazzoli/status/329246619499384832/ @fbazzoli

    Is MUMPS Infecting EHRs? Interesting thoughts from one consultant on MUMPS as a programming language. http://t.co/sndcOwKMBD

  • http://twitter.com/HDirections/status/329251026676875264/ @HDirections

    Is MUMPS Infecting EHRs? http://t.co/7oR8Dv9PVg via @@hitconsultant

  • http://twitter.com/jefflittlejohn/status/329263894386327552/ @jefflittlejohn

    RT @ahier: Thought provoking post >> Is MUMPS Infecting EHRs? http://t.co/x1Hz6yaWDo

  • http://twitter.com/rtweed Rob Tweed

    I suspect what you are, in fact, confusing is the lack of communication capabilities in a well-known commercial Mumps-based EHR with some inherent limitations of Mumps. If its vendor has chosen to limit their product’s communication capabilities, then I cas assure you as someone with nearly 30 years experience of Mumps technologies that it is as a result of a commercial decision by that vendor and not a limitation of Mumps per se. In fact I have yet to come across any form of intercommunication requirements in the modern networked world that Mumps can’t handle quite straightforwardly.

    Sure, the language is pretty antiquated, but you can use any modern language instead to make use of its exceptionally powerful database that is every bit as capable as any of the in-vogue NoSQL databases today. Indeed much of the ongoing success and longevity of Mumps in healthcare is actually down to the unique capabilities of the database.

    Your article warrants a strong rebuttal as, I’m afraid to say, it is built on an entirely misleading and erroneous technical premise.

  • Mike Ginsburg

    This article is wrong on so many levels…

    First, MUMPS is popular for use in EHR’s because it was purpose built for managing health care data.

    Second, MUMPS based EHR’s are popular because they work. Witness VistA and EPIC to name a couple.

    Third, as the author states, MUMPS is admired for its scalability and additionally, there are no inherent limits on how big a MUMPS system can get. The 1 million terabyte number doesn’t even apply!

    Fourth, please explain how MUMPS is stagnating innovation?

    Fifth, any interoperability issues are business issues, i.e. the choice of the vendor, not a limit to the technology.

    Sixth, client server is only one way to use MUMPS. My company (iCare) is using MUMPS in the cloud.

    A very sophomoric article.

    A very sophmoric article.

  • http://twitter.com/rtweed/status/329305104543010817/ @rtweed

    http://t.co/tFxzN3xwHH is wrong on so many levels – see Mike Ginsburg’s comment #HealthIT

  • http://twitter.com/Perficient_HC/status/329311944903385089/ Perficient Health IT (@Perficient_HC)

    Thanks @IT_Practice! RT @Perficient_HC: Is MUMPS Infecting #EHR’s? http://t.co/No8oWUVZGB #hitsm #healthIT via @hitconsultant

  • http://twitter.com/DGTarHeel/status/329324748981022722/ @DGTarHeel

    RT @HealthcareIS: Is MUMPS Infecting EHRs? http://t.co/bN6wSYkjRT via @@hitconsultant

  • Michael Zacharias

    I hope no-one actually tries to form an opinion of Mumps based on this article. As far as I can tell it is based on conjecture, misinformation and lies. The author provides no hard facts to back any of his opinions.

    A simple web search would find that there is nothing but innovation going on with Mumps (ewd, nodem, etc).

    I am not sure why he references that quote from the IDC, but he concludes that thought with a question on if Mumps can handle large amounts of data. Well yes, it can handle large amounts of data. The Department of Defense’s use of VistA EHR and Krung Thai Bank’s use of the Profile banking system are cases of extremely large amounts of data being handled quite well by Mumps.

    It also appears that the author represents a company that makes an EHR product which I am guessing is not built with Mumps.

    MZ

  • Chris Casey

    MUMPS has survived so long because it works, unlike many of the fashionable today gone tomorrow systems. It would be such a shame if you had bothered to spoil an article based totally on conjecture with any facts.

  • Barry Schechter

    VistA an interoperable and scalable EMR used by the Veteran’s administration is a MUMPS based EMR, implemented and working very well. MUMPS has a built-in database so you’re not concerned about the updates changing your structure, indices, or replication. As others have said, hope that this article isn’t a deal breaker.

  • Pingback: Is MUMPS Infecting EHRs? | سليمان العمران

  • Roy Gaber

    Some people have nothing better to do than to poke holes in things they have knowledge of. Oh well

  • Roy Gaber

    Sorry, have NO knowledge of.

  • Arthur Vandelay

    Mr. Tweed – do you have personal experience with the “lack of communication capabilities in a well-known commercial Mumps-based EHR?” If you do, I’d venture to say you must not understand how to use simple mapping tools to bring data into and out from said unnamed application. The functionality provided by the vendor is quite impressive, doesn’t rely on a third party as many other vendors do, and is remarkably scalable. The others who go about stating said vendor has no interoperability capabilities should understand the root of the problem before making ‘qually misleading and erroneous’ comments. Those who know, understand the lack of semantic standards and the somewhat mature yet still evolving syntactical standards are the root of the problem. Further, each vendor of any worth, provides the tools to extend the application with user-defined fields and values. This further complicates the matter. If someone wants to define and maintain the all-encompassing semantic model, have at it. It is not simple or easy, especially in a problem space with as many variables as health care.

  • kwkeirstead

    I like the phrase “(Mumps) was purpose built for managing health care data”.

    Most EHRs we see are bloated billing systems, so in a way, some of the systems that have been around for decades and happen to be based on MUMPS may well be better.

    But, clinical needs have changed – buggy whips were purpose built for speeding up transportation but we don’t see them being used in today’s automobiles.

    We can all better spend our time by focusing on the needs of patients.

    The facts are relational database technology is good for some computing, hierarchical database technology is good for other computing and hybrid databases are good for yet other types of computing.

    All of this should be transparent to end users.