Slashdot Mirror
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.
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.
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.
O M G
"Everybody's naked underneath" -- The Doctor
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.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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*
MUMPS is only used in healthcare/financial systems because those institutions developed applications in the 1970s and are still maintaining them. There is zero interest in MUMPS for any new development. At the time (the 1970s), MUMPS offered a lot of features that other languages didn't. It is basically a hierarchical key/value datastore (like the windows registry, or a filesystem), coupled with a minimalist programming language (it still doesn't support 'while' loops, switch statements or variable scoping). There is no concept of relationships (except between layers of the hierarchy), no way to enforce datatypes, no way to sort an array, no way to search the hierarchy for anything, no way to create discrete objects or associate methods with data.
It does contain some advanced features (for the 1970s); multi-threading, distributed data, and the ability to abbreviate all language commands down to 1-2 letters so your program can fit into 4k of RAM.
EPIC, the medical records product used by many hospitals in the US, is built on top of Intersystems Caché. Caché adds relational features to the MUMPS database, object-ish features to the MUMPS language and supports SQL queries. Internally, it converts all queries to MUMPS, and you could totally bypass the API and write anything you like directly to the database (violating any constraints the API would have imposed on you).
If you are interested in schema-less/noSQL databases, I would suggest you have a look at MongoDB. It has all the features MUMPS does, but without the ancient programming language attached to it. It also has powerful searching capabilities, can store terabytes of data and supports transparent replication and distributed storage.
If you are interested in a schema-less database for a MEDICAL ENVIRONMENT, where accuracy matters and the difference between having a '12' in the dosage column vs. "123 any street, anytown, usa" (silently converted to 123 when treated as a number) could kill somebody, then please consider an alternate profession.
/. comments seem to be a contest to see who can demonstrate the least knowledge of the subject. While Mumps is largely unknown to many, it is widely used in health care and finance. Epic Systems controls about 40% of the US market (http://medicaleconomics.modernmedicine.com/medical-economics/content/tags/electronic-health-records/why-epics-market-dominance-could-stifle-ehr?page=full) and is written in Mumps as is the world's largest clinical information system, VISTA (http://worldvista.org/AboutVistA).
Mumps is a simple, string oriented scripting language for a builtin multi-dimensional and hierarchical database (http://www.cs.uni.edu/~okane/source/MUMPS-MDH/stonehill.pdf). It is especially well suited for applications such as medicine where knowledge is often as varying depth hierarchies that are not well suited for relational systems.
The commercial vendors are Intersystems (http://www.intersystems.com - their version is called Cache') and GT.M (http://www.fisglobal.com/products-technologyplatforms-gtm) whose version is open source / GPL. My own version (http://www.cs.uni.edu/~okane/) is also open source / GPL and can map the Mumps global arrays (the sparse array trees) to PostgreSQL.
Kevin O'Kane http://www.cs.uni.edu/~okane/
I used MUMPS (and MIIS) extensively while working in healthcare in the 80s and 90s. It was an efficient programming and database environment for mini-computers which combined a hierarchical database and interpreted language with sparse arrays and extensive pattern-matching capabilities baked in. It was widely used in hospitals for clinical operations and that legacy is still present in healthcare. The language itself would scare the shit out of anybody using modern technologies (self-modifying code, anyone?), but used with discipline it ran many applications that were literally a matter of life or death for patients. Some variants (MIIS, DEC) were also stand-alone operating systems running on the bare metal. It gave you lots of bang for the buck, even if the code itself looked like a printer test. There used to be a small but active community of vendors and users. Today, there is one large player, Epic Systems, which dominates the applications market, especially in the electronic medical records area. They use Intersystems MUMPS (now known as M) as the underlying language; it has an extensive application building environment on top of the basic language to provide relational, Web and object-oriented abstractions. You can build applications in this environment without ever touching MUMPS code, though commercial applications will generally drop down into MUMPS for special purpose routines.