MUMPS, the Programming Language For Healthcare

citadrianne writes: An ICU patient is monitored and assessed according to 12 different variables. These include such measurements as body temperature, heart rate, blood oxygenation, blood pH, and others. Together, they're used to formulate a quantitative answer to the question, "How bad is it, doc?" Many of these physiological signs are measured in real-time via electrodes and like a billion different varieties of catheter. Add to it barrages of lab tests done multiple times per day per patient and the need for 20 or so clinicians (per patient) to have access to all of this data, and the result is very a deep data problem. Multiply that data problem by hundreds of thousands of patients.

This is the fundamental problem that the programming language MUMPS (sometimes called just "M"), or the Massachusetts General Hospital Utility Multi-Programming System, aims to solve. To its proponents, MUMPS allows for a one of a kind synthesis of programming and database management, while to to its detractors, it's a bizarre anachronism with little connection to the evolution and innovation taking place elsewhere in programming. Probably to most people that do things with computers, MUMPS/M is poorly understood, at best, and more likely to be completely unknown.

Comments

MUMPS, ancient and rarely used

[Sez Zero]

I have a doctor friend who, before becoming a doctor, was a CS grad. He's in his 50's now. When I told him we hired someone from Epic Systems that knew MUMPS, he exclaimed, "They still use that?! MUMPS was going out of style back when I was an undergrad!"

I believe it is also still used in older banking/financial tools.

Re:MUMPS, ancient and rarely used

[Registered Coward v2]

I have a doctor friend who, before becoming a doctor, was a CS grad. He's in his 50's now. When I told him we hired someone from Epic Systems that knew MUMPS, he exclaimed, "They still use that?! MUMPS was going out of style back when I was an undergrad!" I believe it is also still used in older banking/financial tools.

While MMR vaccine has pretty much eradicated MUMPS the anti-VAX crowd is big enough so that it still crops up in isolated populations.

MUMPS: are you kidding?

[iTrawl]

O M G

Why?

[drinkypoo]

Maybe it made sense once. But reading TFA, what convinced me that MUMPS is really BOLLOCKS was this quote:

For one thing, as a programmer, I can take an item stored in one of those globals and give it "children," which might be some additional properties of that item. So, we wind up with lists of different things that can be described and added to in different ways on the fly.

Hmm. That sounds almost like you're tracking relationships. Maybe you should use... (wait for it) A RELATIONAL DATABASE. Seriously, we often store object databases in relational databases. It's easy to add more properties to objects in your database with a relational db because of its very nature. You just create a new relationship, appropriately keyed. And there are lots of examples of systems backed by relational databases which permit you to add arbitrary new properties to objects. Take Drupal, for example; you can always either add a new module which will add new properties to old node types, or just add more data types to old node types. You could add, for example, a parent-child relationship. In fact, modules exist to do this already.

Maybe there is something about MUMPS which makes sense, but if there is, it wasn't articulated in this article. I tunneled down to the MUMPS/II page and found this:

1. Hierarchical database facility. Mumps data sets are not only organized along traditional sequential and direct access methods, but also as trees whose data nodes can addressed as path descriptions in a manner which is easy for a novice programmer to master in a relatively short time;
2. Flexible and powerful string manipulation facilities. Mumps built-in string manipulation operators and functions provide programmers with access to efficient means to accomplish complex string manipulation and pattern matching operations.

So basically, nothing you can't have in perl today, with a relational database, and a table or two to track relationships between objects. But instead, it's a whole new opportunity to create problems! MUMPS is a great name for it.

Oh the pain...

[aethelrick]

I was unlucky enough to have to advise how best to integrate a cobbled-together creaking MUMPS system into a more modern healthcare environment where the business wanted to "use SQL" to write reports against the data in the MUMPS system... of course the ancients who wrote the MUMPS system had done so with a complete disregard for maintenance and extensibility. NOTHING in the system was well thought out... in fact it looked a lot like a bunch of programming novices had just added a crap-ton of data in attribute/value pairs in no particular structure over a period spanning many years with each individual change being in complete isolation because the authors did not understand what had gone on before. It was also sadly really easy to copy/paste vast tracts of code along with the persistent storage bit so guess what the novices I mentioned earlier did? Yup, they copied and pasted a bunch. Now while this distasteful in any language, consider how much this hurts when it's in effect your actual data storage you're copying and pasting along with the code Furthermore... the authors had used every shorthand short-cut in the book because they hated typing (and the reader apparently). I can honestly say I'd rather debug befunge in my head than work with anything remotely related to MUMPS, M or Cache every again. From what I saw, the system was a write-once/read-never data soup that had no place in the GP practice management software that had been written in it. The system held fairly small amounts of data in bloody idiotic structures that were impossible to read without writing more MUMPS. All the business was trying to do with it was print a few letters and government forms... something ANY SQL database along with a report writer would have handled in a much simpler, cheaper and more maintainable manner. *shudder*