Ever heard of MUMPS? Both programming language and database, it was developed in the 1960s for the Massachusetts General Hospital. The goal was to streamline the increasingly enormous timesink that information and records management had become, a problem that was certain to grow unless something was done. Far from being some historical footnote, MUMPS (Massachusetts General Hospital Utility Multi-Programming System) grew to be used by a wide variety of healthcare facilities and still runs today. If you’ve never heard of it, you’re in luck because [Asianometry] has a documentary video that’ll tell you everything.
MUMPS had rough beginnings but ultimately found widespread support and use that continues to this day. As a programming language, MUMPS (also known simply as “M”) has the unusual feature of very tight integration with the database end of things. That makes sense in light of the fact that it was created to streamline the gathering, processing, and updating of medical data in a busy, multi-user healthcare environment that churned along twenty-four hours per day.
It may show its age (the term “archaic” — among others — gets used when it’s brought up) but it is extremely good at what it does and has a proven track record in the health care industry. This, combined with the fact that efforts to move to newer electronic record systems always seem to find the job harder than expected, have helped keep it relevant. Have you ever used MUMPS? Let us know in the comments!
And hey, if vintage programming languages just aren’t unusual enough for you, we have some truly strange ones for you to check out.
Yep. VA clinic management used it.
Open source if memory serves.
Technically, public domain, but that’s effectively the same thing. VistA is the name of the system. Very fun history there.
It’s public domain. I created a PD release of all of the available code (minus encryption) back in 1993. Still have a few CDs and just uploaded to Internet Archive.
https://archive.org/details/vacd-1193
To make the obvious joke…
I’ve never encountered MUMPS, but then, I had my MMR vaccine when very young.
(did they choose that acronym with a whimsical glint in their eyes or is it entirely coincidental?)
I’m old enough to have had mumps, but have never used MUMPS. I also had measles, and my younger brother had rubella. No MMR for us back then, but we did get smallpox vaccines and – surprise, surprise – it worked.
Yup! Ten years at a healthcare IT startup that used MUMPS. It wasn’t my day to day, but had to dabke in the code from time to time. Very fun and odd language. “Oops, all globals!”
Every time there is this word “management”, there will be all kinds of clueless so-called “managers” attaching/wedging themselves to/in the processes that mostly have nothing to do with them – or their careers for that matter.
Data Management, one of the ongoing victims, has long been mistaken for the career ladder that never existed, and requires things other than (the mostly superficial and hardly usable) theoretical skill how to arrange 7-12 table into a database with few views/functions. Most such “managers” end up exhausting the budget with their ever-telescoping careers/salaries and firing all of their programmers/workers and installing themselves in the middle of the disaster they’ve just created. Hiring H1B high school graduates from overseas can only last few months (before they find better place to jolt into), so most projects are just left out there hoping they won’t just crush and burn – just like the mentioned legacy MUMPS thingiemabob, which, surprisingly, didn’t.
I’ve long lost the total count of such fleas riding my back while I am attending the required data Integrity tasks. Half of them had the mentality of kindergartner who got his first cell phone, one recent moron went on a limb teaching me the wonders of filtering the data. I am not kidding.
I’ve also seen huge “success stories” ending up with firing everyone, but the managers and being basically stuck in a permanent cliff next to a chasm it can fall into at any moment. I am actually witnessing one of such disasters being forced “into retirement” due to zero programmers left (only “data managers” and “project managers” together with “business analysis” – the mentioned data filtering specialist is the “project manager” I work with – one out of three). The legacy data stretches into mid-1990s – and has some earlier records it inherited from another system it replaced – earlier fossil records date 1979. That’s 1979, the date the mainframe (that runs in parallel) went online, and this system supposed to replace mainframe, and it never did (???), so the two behemoths had been running in parallel since then, some data is unique to one system, other data – to the other, and they were never merged into one.
So, translation – what they will probably do is take entire MUMPS and feed it to AI to generate something even more cumbersome and even more unmanageable. God help their souls, because the data integrity (mistakenly called “data management”) is something that cannot be taught in cram-crash summer semesters. Basics can be covered, but the rest is learned by doing. Diagramming, yes, I’ve done that, keeping it in synch, yes, that, too. Auto-generating, yes, all kinds of good stuffs, UML (keep in mind, two sides, infrastructure and function – and data flow as well, so you can at least figure out how/why data comes in and where it ends up and what happens next).
Exercise to the reader for those who think I am making this all up – you have a reference table, say, list of US area codes, and suddenly one changed, WHAT do you do with the old data? Flip it all to the new area code? What happens to all the records that were attached to the old data? How about the data that was indirectly related, all the printed documents that had THAT old area code? You gonna re-print and re-send them? Now, imagine the two area codes were merged into one. Now imagine the new one now uses the retired area code from the first example. Run a report and bam, suddenly there is phantom data that wasn’t there before the last update. Good luck figuring out the solution : – ] (or coming up with a good plan to work with these data integrity issues – BTW this was a SIMPLE CHALLENGE, only one reference table, and not even a cluster, ie, self-contained reference tables with reference-data tables matching the actual data tables directly or indirectly connecting to other similar clusters).
Thanks for giving the example. While reading, I realized how little I understand about this subject.
Indexed tables in a relational database suppose to fix SOME of these error with the parent-child keys that automagically rearrange themselves – update, etc.
another way of handling is setting up lookup indexes/keys, ie, for that key in that table there are those keys in those tables, so the records can be cross-referenced from a query.
The usual solutions I’ve seen are a hybrid of the two approaches, keys and lookup keys, and for the old school flat file tables usually there are multiple indexes key lookups using which one can fetch records. You can guess that the moment one starts going out of synch (and they all eventually do) with the records it indexes, things start go haywire at ever-increasing speed. Eventually it is just simpler to set up a new keys-cross-reference table and ditch the old one.
Legacy databases usually come with their own rats’/wasps’ nests of internal data integrity issues. sometimes setting up external database helps, sometimes it makes matters worse, but the usual approach is “let’s now touch any of those records and let them be”. I’ve also witnessed “data managers” sheepishly think they can stuff that data into the new database, fixed/upgraded/revised/retwisted-anew, ie, forcing a triangular peg into a square hole – they only LOOK similar, but they never truly are (except for the cases where the data was simple to start with).
Every data migration makes these four textbook errors – missing records, orphan records, duplicate records, incomplete/partial records (usually because some data wouldn’t fit and was rejected, or was backed out, but only partially – some data ended up stored permanently, while some was rejected). Every data migration goes through more than one wave of migration, and each wave can potentially generate these errors, hopefully, increasingly less with each iteration.
And then there are all kinds of self-appointed “specialists” scoring the rare opportunity to shove away the actual workers and claim that it was them who did all the work. They usually arrive on the scene late in the game and declare “I came to find this thing hopelessly broken and I was the only one who knew how to fix it, so I did”. I worked with these, too, and their results were even less, they usually end up jumping the ship they sunk.
Something like that.
Oh, another thing hated by managers is “data planning”. They think they can plan all those things AND can plan the work-arounds in case something goes wrong. I don’t even know where to start describing the mess they usually create with their “planning” – most end up hiring another manager to do their work instead of them. Yes. That’s how it usually ends up having three managers managing one worker (me).
Epic Systems’ electronic health record system is Mumps based. As an Epic Analyst, I use it every day.
That’s epic ;-)
I could have sworn it was renamed to Cache at some point ~ 20 years ago, but then, I’ve heard about the horror story that is programming for that system. (mostly from the Daily WTF article “A case of the MUMPS”)
I am very thankful that the only programming I need to deal with for work is the occasional powershell or command line script, although I do dabble in MicroPython as a hobby.
You are correct. The Modern incarnation of “MUMPs” is called “Cache'” and it is more of a branding and ownership thing. It is the same language. I, too, am an Epic Analyst and work with a MUMPS based system all the time. Sunquest is another EMR based on MUMPS and there are others. Healthcare seems to be where old tech goes to never actually die…
A little known fact is that Epic runs on database technology provided by InterSystems, which was indeed called Cache at one point but is now called IRIS. InterSystems started off in MUMPS but have developed technology significantly, IRIS is a very high performance database albeit quirky but is used in health and also in other high performance industries such as logistics and finance
I’ve talked about the early days of MUMPS at Epic Systems Corp on my blog here:
https://acorntalks.com/blog/the-code-parser/
Fascinating. Thank you. I remember hearing about MUMPS for the first time while working at Data General in the 70s.
MUMPS grows on you (or at least it grew on me). I read probably thousands of lines of it a week. The dialect we use typically uses fully abbreviated commands (so a slew of single letter I(F), F(OR), D(O), K(ILL)), which you get used to. It’s beautiful in its simplicity, and luckily we’ve mostly ignored the object-oriented junk that intersystems shoved in there back in the OO craze. I only wish it had more room for static analysis
Not just used in health care but it was also used in some credit unions. Steinbeck Federal Credit Union in Monterey County (California) used it. A buddy of mine was their IT guy many years ago and he loved it.
Interesting. We used to stock books about this language at 2021 K St. NW WDC. I read the wikipedia article on it after this article and was astonished to see “a language with no datatypes”. I wonder about the whole brevity thing, I for If, etc. Is the juice worth the squeeze? What do you do with the time and space you save?
This thing dates from a time when 16K of RAM was positively decadent. :-)
“I understand that” said 1966. And the BASIC Fortran COBOL choir chimed in “Tru dat!” I understand that’s the standard thing to say and enjoy the good humor but Granny doesn’t need egg-science lessons. The questions remain: juice v. squeeze, time & space. It’s a simple question. From the little I now know I feel kindly toward the language but am also a big fan of legibility without the mental overhead. Similarly, there’s completely legible Perl, and there’s inscrutable Perl.
yes I have heard of it, Intersystems are the world’s largest supplier of PAS systems iirc.
of course they don’t call it MUMPS any ore because naming your database after a disease is poor form, it used to be called Cachè which was always fun because often you want to cache the data you just loaded from Cachè due to its rubbish performance at anything not based on the key such as say finding out how many people are currently admitted with Mumps, so it’s now called Iris no doubt this causes amusement in Opthalmology but thankfully I don’t work there.
The Daily WTF has a good article from the back in the day (2007) :
https://thedailywtf.com/articles/a_case_of_the_mumps