Analysis of MUMPS in Healthcare & EMR

Just the other day I was at a local Vegas Tech event and happened to run into a government contractor that worked in IT. As we got talking I told him about my work with EMR and EHR. Once he heard those terms he started to recount his experience evaluating a contract position where he was to work at connecting the VA system with another government entity. He then said, did you know that the VA software runs on something called MUMPS?

Of course I’ve heard all about MUMPS and so I told him how a huge portion of healthcare IT is run on the back of MUMPS (My understanding is that Epic uses MUMPS as well). Obviously, MUMPS has its benefits since it’s gotten us this far. I even remember some past threads where people have argued some of the advantages of MUMPS over newer database technology. However, I still stand in the camp that wonders how we’re going to get off MUMPS so we can enjoy the benefits of some newer, more innovative technology.

Something called the Axial Project basically asked this same question back in March 2011 when they posted about how to Architect Vista for 2011 (which is possible since Vista is open source). They provided a really insightful look into why MUMPS has done well in healthcare and what current technologies could replace it. Here’s that section:

So if I were starting a Healthcare IT company would I invest in building on Mumps/M? No. There might be some business in supporting legacy applications, but very little innovation. I am not attacking Mumps/M from a technical perspective, I am trying to be pragmatic as a business person. So we need find an alternative. So you probably think I am going to say MS SQL Server or Oracle thinking I want that 100/hr price tag. Thanks, but no thanks. So I am not in it for the money, I must go the other way. PostgreSQL or MySQL. Intriguing, but still a no go. I have learned over the past 18 months that Healthcare data has very little integrity. One of the reasons I believe Mumps/M has excelled. Storing objects vs Storing relationships in normalized structures is not valuable to this market. Too many views of the data are required depending on your role you play in the system. I would try to use a NoSQL database like MongoDB, Cassandra, or CouchDB. My preference would be MongoDB because there are drivers for Ruby, Java, .NET, and Python. Also, these systems are truly data entry/reporting tools at their core. I need strong query support which MongoDB has through it’s BSON data structures without a ton of map/reduce requirements. So let’s go back to finding some resources that can help.

The part that struck me was when it said, “I have learned over the past 18 months that Healthcare data has very little integrity.” That makes a lot of sense and explains why a NoSQL solution could work well.

Turns out, Axial Exchange has brought on the previous COO of RedHat, Joanne Rohde, to work on the project. Check out Axial Exchange’s presentation at Mogenthaler’s DC to VC 2011:

Looks like Axial has shifted from redesigning Vista, but they’re working on some interesting stuff.

What do you see as the future of MUMPS in healthcare?

About the author

John Lynn

John Lynn

John Lynn is the Founder of, a network of leading Healthcare IT resources. The flagship blog, Healthcare IT Today, contains over 13,000 articles with over half of the articles written by John. These EMR and Healthcare IT related articles have been viewed over 20 million times.

John manages Healthcare IT Central, the leading career Health IT job board. He also organizes the first of its kind conference and community focused on healthcare marketing, Healthcare and IT Marketing Conference, and a healthcare IT conference,, focused on practical healthcare IT innovation. John is an advisor to multiple healthcare IT companies. John is highly involved in social media, and in addition to his blogs can be found on Twitter: @techguy.


  • The core of the EHR system I work on is considered a legacy product, which few are familiar with.

    The funny thing is, I also work in a lot of newer tech (.NET, PHP, SQL Server, NoSQL – CouchDB to name a few), and I feel qualified to say with certainty that older tech often has less interoperability options out of the box, but that doesn’t mean it’s impossible to be interoperable, just harder.

    For example, I can automate a simple data file extraction using graphical tools in SQL Server (using SSIS) in a heartbeat. For comparison, in a legacy product, a programmer may have to write all the code and build automation manually to accomplish the task. It’s still doable. Even things like web service calls are doable in the legacy world. They require some capability in the legacy product itself, to support the necessary functionality of interconnectivity, and someone remotely knowledgeable in the legacy product to support it.

    When you go out as a vendor and the customer asks “what’s the tech behind your system?”, and you don’t respond with a buzzword or a current tech that people are familiar with, you tend to hit a mental wall/blockade with many people.

    The age of MUMPs and how it was adapted to the interconnected modern world were/are challenges, but the politics and opinions that surround these legacy products and related decisions is the larger difficulty.

    In the end, the choice of tool does not depend solely on whether or not the tool is capable of doing the job.

  • […] I don’t see why it would be a problem. Actually, I’d say the largest part of healthcare IT runs on a NoSQL solution called MUMPS. You’d just have to be careful how it was implemented, but the argument for using a NoSQL solution actually makes a lot of sense in healthcare. You can read more about MUMPS and it possibly being replaced by the above NoSQL solutions you mention: […]

Click here to post a comment