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.'"
Yeah, you would think Vax would get rid of MUMPS.
Must be those damn Anti-Vaxers.
I'm a good cook. I'm a fantastic eater. - Steven Brust
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*
When I joined DEC as a trainee programmer in 1976, MUMPS-11 was one of the OS choices on the PDP-11. One of the guys still Product Managing high end systems at HP UK was a MUMPs support guy in Software Services at the time. Last saw it in the flesh as VAX DSM (Digital Standard MUMPS) back in the late 1980's. A lot of the revolutionary stuff like NoSQL and JSON type databases are just reincarnated from DEC way back when.
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.
Not quite. In COS (Cache Objectscript) just a superset of M really, the whole point of the language is to manipulate the data. You have the best of both worlds - the ability to store data hierarchically as well as relationally at the same time. Just figure out what you want to do and add in the appropriate indexes and write reports off of that. Like anything else you have to PLAN what the Hell you want to build before you go off and build it.
I have coded in MUMPS since it was on a PDP 11/84 called Digital Standard MUMPS (DSM), though the VAX years and up through the PC and now highly scaled systems. Coded, managed and maintained systems on AIX, Linux, Windows and HPUX, so I kind of have at least a modicum of understanding of its abilities. It's no slouch. It handles transactions - FAST. But then again, understand it was a system designed in the day when there wasn't a lot of money put into healthcare IT. It had to do stuff on little PC's (Micronetics MUMPS and DataTree MUMPS) when a small PC had to run an entire clinical laboratory - instrument interfaces and all. Try that back then with an early version of Oracle in the late 90's and a little computer would bawl its eyes out. I seem to recall Oracle at one point needing THREE CD's just for the ODBC driver? Yeah. That would have never flown in the "M" community. There wouldn't have been enough money to put out the three CD's :-)
No - it's not magical. It's not the Hammer to Make All Problems Look Like a Nail. Though it is one of the most flexible, competent languages I have used - but like ANY language, it can be abhorrently abused and butchered. You can make structured code in M be simple enough that an 8 year old can understand it, or you can make it look like your computer just took a core dump on your screen. It's totally up to you if you want to avoid making "wicked" or "readable" code. It's the same in Perl, PHP or anything else...
You pick the toolset appropriate for your industry, company, product, need, etc. you have and code into its strengths. It can be a very capable back-end transactional server that would pound a comparable Oracle box into the sand and make it its bitch, but that is also dependent on having capable programmers to make it happen. You certainly won't need as many "handlers" in the way of FTE's to administer a Cache installation that you do with Oracle - but again, that too comes from experience working on both sides of the fence. You can have processes that support insanity or not. Totally up to the corporate culture everyone embraces.
Personally I love working with the toolset, but then again I'm biased. I've had to interface it to .NET framework stuff, external Java calls, etc., and that's fun too - and I would always move the logic of what needs to get done out to the appropriate locale or "tier"... But I wouldn't knock it saying any one tool is better overall than any other when it comes to a platform as large as Cache/MUMPS. That just shows how myopic one can be when looking at solutions to problems.
Never have a philosophy which supports a lack of courage
This is why in Epic they extract to an SQL reporting database and you write your reports off that.
Kind of interesting, because for analyses we turn to data warehousing techniques, wherein you flatten your relational database into a star schema so you can quickly aggregate millions of rows. So you can go
MUMPS (for transactional throughput) -> normalized SQL (for custom reporting) -> denormalized SQL (for analysis)
We don't have a state-run media we have a media-run state.
The main problem with the environment is that between Epic Systems and VistA (the VA system), MUMPS holds back some real innovation. Sure, you'll hear tons of success stories about the VA or from EPIC, but the fact is that this vendor lock has huge costs. A major hospital chain I worked with spent a billion+ on a EPIC implementation. Did it improve interoperability with other hospital systems? Nope. Even two EPIC implementations will have a very hard time sharing records.
And that's the whole point of a EMR, to have a consistent version of a patient's history throughout their life. And these systems can't support that model in our current system. If every doctor had to use one system (like in some national health care systems), it'd be better, but that's not what we have. Sadly, the other attempt to standardize healthcare systems and interoperability (HL7) is an equally convoluted mess.
What is needed (but we won't get because of the players) is a standards driven process that is focused on building up a workable ecosystem for exchanging information.
It'd be hard to create a standard that would allow for healthcare professionals to: provide proof that they are a provider and to provide electronic evidence that they have a patient (via a secure exchange) to create a unique identifier for that patient/provider, but it is doable. Solve that, then move on to exchanging of information between providers and allowing providers to mark information as not shareable to the patient or other providers. All of this could be done, and it would provide a real basis for a proper EMR system.