Persistence of the MUMPS Programming Language in Healthcare Applications

One of the interesting and unique aspects of the EMR world is that some of the major vendors use a programming language, MUMPS, that is virtually unknown in other IT business sectors because it was developed so long ago. There is no other industry that worships "new and novel" more than IT. Hence, the question arises about why this language persists among some of the leading EMR software vendors. Mr. HIStalk recently posted a reader comment about MUMPS and responded in the following way:

From Limber Lob: “Re: MUMPS and Cache’. MUMPS takes hits because it’s still around after 30 years and many of the ancient MUMPSters are coding the way they did 30 years ago. Old COBOL, RPG, and Pascal programmers have all passed on instead.” 

Reply from Mr. HIStalk: I like that analysis and will extend it: companies like Epic and Meditech hire trainloads of noobs and train them on a language they’ve surely never heard of even if they majored in computer science. Since it’s more of an apprenticeship, they can also train them to follow their own internal programming standards and utilities, which are arguably more important than the choice of programming language anyway. It may be true that only in healthcare would a robust market still exist for applications written in something that quirky and old (or “industry-specific” and “time-tested” if you’re a glass-half-full type). Bottom line: it works, the vendors can support it, and customers shouldn’t (and apparently don’t) care about the invisible underpinnings.

I have posted a number of previous notes about both Epic and Meditech including comments about the similarity between the two companies (see: Some Additional Insights into the Epic Corporate Culture), Both have been run with a heavy hand by their founders, neither places any value on marketing, and neither permits any tinkering with the software by their hospital client sites. This enables a high installation success rate as well as relatively easy software updates. Innovation and change is hence controlled by the vendor and not by the clients. As noted above, this results in the happy circumstance that the vendors can support the software and the customers can't. This is enforced by both legal contracts and the continuing use of MUMPS for the product.

So the answer to the MUMPS/healthcare conundrum has been hiding in plain site from me all of these years. MUMPS continues to be a mainstay of healthcare computing for Epic and Meditech not in spite of the face that it's old and antiquated but because it's old and antiquated. As Mr. HIStalk opines above, the hospital CEOs don't have any particular inclination to look under the EMR hoods and continue to be happy with the products. Judith Faulkner, the CEO of Epic, is certainly happy with the success of her company. The only losers are the Epic programmers who may need to go on welfare if they loose their jobs.

Comments

[Brian M.]

As a physician in a hospital setting with a CompSci background I am sensing a need for a company to bridge the gap for where EPIC leaves off and the end user begins. EPIC and Meditech are great... to a point... but fail to tailor their globo software for Dr. X's office practice, etc... or for Dr bla's style of practice. If epic will not allow clients to "tinker" with their software... then clients need a software solution that seamlessly appears to do so without any backdoor knowledge or support. I am contemplating a start up company. Anyone with interest and skills in this area should contact me.

[Josh]

Old post I know, but this post ranks for MUMPS so I figured it wouldn't be wasted.

"is virtually unknown in other IT business sectors because it was developed so long ago"

Actually, MUMPS is fairly well known as being the quintessentially horrible language. http://thedailywtf.com/Articles/A_Case_of_the_MUMPS.aspx

[Scott R. Lauber]

Of course, this assumes that EPIC maintains excellence in keeping up with all the nuances of health care business and clinical process and particulary adaptive to the industry and client's new and ongoing needs. No flexibility on the client side, even given EPIC's current success, does not sound like a marketplace success model to me for the long term.

[Best PLM Software]

Your post is an inspiration for me to study more about this issue. I must concede your lucidity widened my views.

[volunteer in china]

Interesting post, I haven't come across your site and I am sure I will be back.