MUMPS, the Programming Language For Healthcare 166
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.
MUMPS, ancient and rarely used (Score:5, Interesting)
I believe it is also still used in older banking/financial tools.
Re: (Score:3)
Re:MUMPS, ancient and rarely used (Score:5, Informative)
That is not really correct. Cache is an objecy oriented database, Mumps is a programming language/programming system which happens to use Cache.
https://en.wikipedia.org/wiki/... [wikipedia.org]é ... I wonder if that link works :)
Re:MUMPS, ancient and rarely used (Score:4, Funny)
Actually, it's kind of the other way around in reverse. MUMPS is the database backend. Cache exists as an object oriented datastore that uses MUMPS. Cache also has a VB-ish scripting language that can be used for those that don't feel like parsing stuff that looks like
N X S X="^DIC(",X=$QS(@X)
Many (but not all) of my personality problems derive from supporting software written in MUMPS for the last 15 or so years.
GT.M (Score:2)
Fidelity Systems also has a MUMPS-based database called GT.M. It's open source (licensing is GPL+fuck up) and it's the main competitor to Intersystems Caché
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
Re:MUMPS, ancient and rarely used (Score:5, Funny)
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.
Re: (Score:2)
The Digital Equipment Corporation's VAX line was entirely compatible with MUMPS (https://en.wikipedia.org/wiki/MUMPS). I guess you could say that VAX did nothing to destroy MUMPS, and in fact, was instrumental in its spread, seeing how integral DEC computers were to the greater Boston-area industries in the 80s.
People who think VMS was a pain (Score:2)
At least @david415 [twitter.com] and @adr [twitter.com] are anti-VMS. @willrad [twitter.com] explains the joke.
Re: (Score:2)
VistA still going strong, and a number of successful businesses are based on it.
MUMPS (or M if you prefer) is a terrible language, but it's heartening to know that all the effort that went into VistA didn't
Re: (Score:2)
They said that about COBOL too. It's still very probably the most-used language for business applications - for very good reasons.
Re:MUMPS, ancient and rarely used (Score:4, Insightful)
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!"
Yep, and MUMPS is still used at Epic, though they call it M and claim to have made customizations and improvements to it. I was offered a job there a few years ago and they go to great expense to attract recent graduates with high starting pay (more than $84,000 in Wisconsin), unbeatable benefits including the most amazing health care plan I've seen, and a pretty cool campus.
Unfortunately it wasn't enough for me to overcome moving to Madison, working long hours, and (most importantly) becoming an expert in an all-but-dead language. When I investigated career paths at the time, the only path MUMPS offers appeared to be (1) work at Epic for a couple of years and then (2) consult for Epic's products for the rest of your career.
If you want to see the very worst 1966 has to offer today:
A Case of the MUMPS [thedailywtf.com]
MUMPS Madness [thedailywtf.com]
Revenge of MUMPS Madness! [thedailywtf.com]
MUMPS [wikipedia.org]
It's kind of like the worst parts of COBOL, Javascript and PHP were all mixed together and then baked at 400* until charred and smoking.
Re: (Score:2)
https://medium.com/backchannel... [medium.com] This, as well, is a story about health care computer systems, which means it's 60% likely they're talking about MUMPS.
Re: (Score:2)
Absolutely the best description of the most dreaded PDP/11 infection ever., but I think there was some evil Perl miasma there too - hence the Zombie like undeadness.
Re: (Score:2)
Epic drives their staff into the ground but they are a pretty cool place to work. They have been moving to a web platform for their front end and use C# so unless you were going to be working as a Technical Services rep you probably would have had an opportunity to do cool stuff on their core developer team rather than work with M (the Tech Services folks do a lot of M programming)
Re: (Score:2)
I do not know about the rarely used part but MUMPS has been around for a very long time.
https://en.wikipedia.org/wiki/... [wikipedia.org] VistA can use MUMPS for the backend so it is probably still in pretty wide use.
Re: (Score:2)
Re: (Score:2)
I have seen 5 line Perl programs that could be re written into 30 line programs that are easier to follow than most of the older M code I have seen.
Re: (Score:2)
It is used for SunQuest, Soft and a number of other medical software platforms. Cache Systems is actually a pretty good platform.
MUMPS: are you kidding? (Score:5, Informative)
O [thedailywtf.com] M [thedailywtf.com] G [thedailywtf.com]
Re: (Score:2)
The instant I saw MUMPS, I was thinking, "Haven't I seen that before?"
Yes. Yes, I have.
Re:MUMPS: are you kidding? (Score:4, Interesting)
Re:MUMPS: are you kidding? (Score:5, Informative)
I'm used to anti-{language,tool,method} screeds being ignorant braying in lieu of effort, but this . . . This isn't even remotely the worst of it, it's only that it's soundbite-able. That first link deserves the word "mindboggling". The list here starts out slow, easing you in to it gently. No, seriously..
Re: (Score:3)
A variant of the XECUTE command exists in most languages.
Declarations exist as there is still the concept of "stack level", but are optional. Dynamically created variables are scoped to the current stack level.
Lines
Many of the others are presented with a tone of "can you BELIEVE this shit??
Re: (Score:2)
Why? (Score:5, Insightful)
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 [uni.edu] 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.
Re: (Score:3)
Hmm. That sounds almost like you're tracking relationships. Maybe you should use... (wait for it) A RELATIONAL DATABASE.
Keep in mind that MUMPS [wikiwand.com] first appeared in 1966, so it isn't exactly new.
Re: (Score:3)
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 [uni.edu] 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.
The challenge isn't that you can't do the same thing with a newer type of database but converting all that data into the new one. That is expensive, time consuming and invariably winds up with the loss of 20% or so of the data. My general rule is 2-2-20 Costs twice as much as planned, takes twice as long as planned and you lose or screw up 20% of the data.
Re:Why? (Score:4, Interesting)
Re:Why? (Score:4, Interesting)
Epic crushed a lot of competition by marketing a "fully integrated suite". All of the applications (there could be dozens) for a customer run off a single M database. Why wasn't the competition stronger? Many reasons, but one was because most competitors were using SQL and couldn't compete on performance.
The big limitation of M is reporting. Epic solved that by running extracts to a SQL "reporting database" and hooking up off the shelf reporting tools.
Re: (Score:2)
So, basically, a NoSQL database.
Re: (Score:3, Informative)
MUMPS originally had a sort of in-memory database layer (map > >). They then abstracted that so it could load chunks of the database on the fly from disk. Later, that became a separate product (forked?) known as Intersystems Caché, which billed itself as a post-relational database (read: pre-relational, hierarchical database). Caché at least added SQL-like language to the product so it could pretend to be an RDBMS... so it's not necessarily no-SQL, because they added SQL later, but it is no
Re: (Score:2)
You should have stopped reading the summary when it got to this:
and like a billion different varieties of catheter.
And like I love, like, when a 16 year old, like, writes articles about stuff, like, they don't fully understand, like now. like dude.
Re: (Score:2)
"And like I love, like, when a 16 year old, like, writes articles about stuff, like, they don't fully understand, like now. like dude".
That's rather funny, in view of some of the comments here about MUMPS' technical features. Criticizing a programming language and database management system based on a few lines of remarks made by someone who may not know much about it either... doesn't make a lot of sense.
What cuts a bit more ice with me is that MUMPS is still being used - by the people who are responsible
Re: (Score:2)
So basically, nothing you can't have in perl today, with a relational database, and a table or two ...
MUMPS was an ancient joke of a language back in the '70's when I started programming (40 years ago). But now you've managed to sell me on its benefits.
Hierarchical database (Score:2)
Maybe you should use... (wait for it) A RELATIONAL DATABASE.
The advantage of a hierarchical versus relational database model is that the former is much faster storing large amounts of data that fits in the hierarchy (which healthcare data does). Foreign keys and hierarchical joins are built into the data. The disadvantage is that doing anything the doesn't fit the hierarchy is difficult compared to the flexibility of a relational model. This is why systems written in MUMPS have great transaction throughput and the UIs are usually responsive, but running reports is a
Re: (Score:2)
Fast, simple and hierarchical : is that a bit like an LDAP? Out of curiosity, do people sometimes build a database application on LDAP? Then if you need to do some desktop or other LDAP-enabled software, for more traditional purpose of not having to log in again and manage permissions etc. you already know how to do it.
Re: (Score:2)
Re: (Score:2)
People use the engine behind LDAP servers as a database.
LMDB [symas.com]
Re: (Score:2)
good luck making complex queries without having to scan all the records, this is precisely why SQL is better, it can optimize queries so you don't have to scan every record
Re: (Score:2)
Indexing FTW!
Re: (Score:2)
This is why systems written in MUMPS have great transaction throughput and the UIs are usually responsive, but running reports is a nightmare.
It's not necessarily a nightmare; it depends on the flexibility of the reporting tool. I've pretty well given up on using the built-in reporting tool at work for the reports I'm asked to produce because the tool doesn't allow for making the sort of complex links between globals that the report needs (i.e., patients with a given diagnosis who are also on a given medication, and their most recent result from a specified lab test), while producing the data with a MUMPS routine is straightforward because of the
Re: (Score:3)
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 S
Re: (Score:3)
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)
Re: (Score:2)
so you write a data extract process and send the reportable data over to it in a daily batch...now you get your monthly reports like a pro using BO and Crystal :-)
Re: (Score:2)
Sure, and there have been written entire books and essays and algorithms [stackoverflow.com] on how to get your relational database to store and return a hierarchy. It reminds me of those highschool programming challenges where you implement a binary tree in a single array because why the fuck not?
Every language invented in the 60's was a whole
Re:Why? (Score:4, Interesting)
Except that MUMPS did it 30-40 years before such features were available in relational databases.
And see Henry Baker on "Relational Databases", Comm. of the ACM 35,4 (April 1992), 16,18.:
Re: (Score:2)
Re: (Score:2)
Hierarchical databases are more efficient for healthcare....and most applications that have lots of real time I/O
Re: (Score:3)
"nosql databases that can do the same
Except NoSQL databases are not guaranteed ACID compliant. Meaning you may lose critical medical information. The relational model is built around ACID compliance. I hope by now so is MUMPS.
Re: (Score:2)
Except NoSQL databases are not guaranteed ACID compliant.
Except when they are:
https://en.wikipedia.org/wiki/Berkeley_DB
"Despite having a simple architecture, Berkeley DB supports many advanced database features such as ACID transactions, fine-grained locking, hot backups and replication."
Re: (Score:2)
Except NoSQL databases are not guaranteed ACID compliant.
Except when they are:
https://en.wikipedia.org/wiki/Berkeley_DB
"Despite having a simple architecture, Berkeley DB supports many advanced database features such as ACID transactions, fine-grained locking, hot backups and replication."
Except that Berkeley DB predates NoSQL by a few years/decades. Its more of a DB library than a DB and really intended to be used when writing a DB. And no, there isn't currently a NoSQL DB that is ACID compliant.
Re: (Score:2)
BerkeleyDB IS a NoSQL database
Just because it existed before the word NoSQL doesn't mean it isn't one
BerkeleyDB is most certainly a database, it comes with an executable program that can be used as a full-featured database.
And no, there isn't currently a NoSQL DB that is ACID compliant.
Isn't that funny? The very product mentioned in this article (Intersystems Caché) is a NoSQL DB that is ACID compliant.
Re: (Score:2)
OK, context check. I meant modern "NoSQL" database engines. The older ones have survived because they got better. The new ones I was actually referring to are proud of the fact they are eventually consistent, meaning they are not ACID compliant. Though over time they will be, or will be discarded.
Re: (Score:2)
I meant modern "NoSQL" database engines.
a useless impractical distinction if I ever saw one
BerkeleyDB is thoroughly "modern", could you please list a single attribute that keeps it from being "modern"
a hilarious attempt to back out of your "no true scotsman" statement you ignorantly walked into
Microsoft got 'em beat already (Score:2)
Microsoft is about to release their RAD for healthcare, called Visual AIDS. MUMPS has got nothing on them.
Oh the pain... (Score:5, Interesting)
Re: (Score:2)
I've never worked with MUMPS, but your aggravation is quite familiar. It's what happens when you try to take apart a schema that is designed as an object store, without using the object accessing framework.
I'm not defending MUMPS in any way, but you should be aware of this if you ever attempt data conversion in the future. Often (not alw
Re: (Score:2)
IDL (Score:2)
It's what happens when you try to take apart a schema that is designed as an object store, without using the object accessing framework.
Shouldn't object stores be describable in some IDL [wikipedia.org]? At least then you could add means to import and export objects with JSON or something like that.
Re: (Score:2)
At least then you could add means to import and export objects with JSON or something like that.
since when do you need an IDL to work with JSON?
Re: (Score:2)
Hahaha, that wasn't IDX (AKA GE Healthcare) was it? I interviewed with them back in the early 90's. They were the most arrogant dorks you can possibly imagine, and their product frankly stank. They had a very good grasp of the business side of things, but their actual software engineering practice was execrable and MUMPS couldn't have helped.
MUMPS predates UNIX (Score:3)
See, legacy systems aren't dead! (Score:2)
I do systems integration work, and most of the companies I work with are airlines or somehow connected with air transportation. Besides banks, airlines were the first companies to computerize, and a lot of that legacy is still baked into modern systems.
I've read about MUMPS, never programmed in it, but I see huge parallels in my work. The language was written back when every single byte of memory was expensive, hence the need for single character keywords. Airline systems were built out at a time when every
Re: (Score:2)
I've read about MUMPS, never programmed in it,
you could have stopped right there, everything after it is nonsense
MUMPS is nothing special (Score:4, Interesting)
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.
Re: (Score:2)
For example, you can write while loops, it has a different implementation of variable scoping (things down the call stack can access anything declared by any level above but not vice versa), of course you can sort an array (in fact, it's sorted as it's built), of course you can search the hierarchy (extremely quickly, too) and of course you can create and use discrete objects.
While Epic is built on Intersystems Cache, it does not u
Re: (Score:2)
In safety-critical systems where invalid data could kill someone, using a typeless, schema-less system with nonstandard language conventions as a starting point seems irresponsible. Why not start with a normalized relational database and a language designed to encapsulate and protect data from inadvertent data-entry or programming errors?
Because performance. Yes, Epic had to put extra work in to essentially build their own version of the SQL server black box, but now they are very difficult to compete with.
Epic doesn't use the Cache SQL API. Instead, they built an API on top of objectscript that stores fields safely. They have a staggering amount of code written in objectscript, and while it's true that "nothing will stop you" from writing directly to the underlying data oddly enough that doesn't seem to be an issue because developers c
Re: (Score:2)
Why not start with a normalized relational database and a language designed to encapsulate and protect data from inadvertent data-entry or programming errors?
nobody actually does this in production systems, if you put in code to detect all possible data input errors, you will not meet any sort of performance goals
you can put in indexes and referential integrity constraints to your heart's content, but then you will find that your INSERT operations are just outrageously slow
it's better in all cases to constrain user input at the application level
Web scale? (Score:2)
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.
But then you have to contend with rejected villagers from Animal Crossing arguing over [youtube.com] whether it's "web scale" or like "piping your data to /dev/null".
Re: (Score:2)
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.
MongoDB is not ACID compliant. Makes it a non-starter for something in the medical field.
Mumps usage (Score:4, Informative)
/. 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.
Re: (Score:3)
"/. comments seem to be a contest to see who can demonstrate the least knowledge of the subject".
Exactly. And the competition is white hot.
MUMPS was designed for a different world (Score:2)
MUMPS was initially developed for the 18-bit DEC PDP-7 in the late 1960's, where memory and disk constraints were severe, and processor speeds were a tiny fraction of today's slowest devices. Earl
Re: (Score:2)
As a computer scientist, I was appalled by certain features of the language, particularly the ability to change a running program by executing a variable. That's a security nightmare, since you could effectively read a string (stored as a global or input from the console) and then execute it as MUMPS code.
Do you spend a lot of time being appalled? Many languages have this capability, including SQL and the C variants.
MUMPS is a capable platform (Score:2)
I've heard about MUMPS from it being used in Vista, the records system of the Veterans Affairs Administration, a large public domain corpus of software which was released from a FOIA request to the VA.
MUMPS is not a bad language. As with many languages, the source code readability depends on the programmers mostly, there isnt anything about MUMPS that makes it particularly hard to read. Intersystems Cache is one of the commercial implementations though it tends to downplay its MUMPS foundation, because of t
Insurance Claims Systems (Score:2)
There are several Insurance Claims systems are built onto of MUMPS. If they are still active they almost certainly have Intersystems Caché running onto so that the data can be exposed to more modern stuff.
HP/MPE had a hierarchical database, too (Score:2)
HP/MPE had a hierarchical database, too. That OS and database have been dead for many years.
There is a good reason for that.
While I applaud the original poster's learning a bit about the bowels of computing history, the fact that they did so doesn't mean new systems should be developed with archaic tools like MUMPS. There is nothing a hierarchical database can do that relational databases don't do better. And as long as you're using one with ACID compliance, even a NoSQL database is better than a hi
Re: (Score:2)
There is nothing a hierarchical database can do that relational databases don't do better.
That's rather absolute. It seems performance is an area that hierarchical can be better, at least in certain use cases:
http://www.intersystems.com/assets/datamart_wp-ee478edf530b40311ef506615c0da74d.pdf [intersystems.com]
Conclusion
In tests simulating a data analysis application typical for a telecommunications software firm, Caché was 41% faster than Oracle when creating a data mart of mobile phone information. When the resulting data mart was queried using SQL, Caché’s response times ranged from 1.8 to
Re: (Score:2)
MUMPS does not let you deploy a clustered database server as Oracle does, nor any of the other major RDBMS vendors, so it's scalability is limited to how big a single node can be. Also, shoehorning Oracle onto a 4GB node is kind of a joke. I use as much memory for a laptop.
I also see no mention of client-server deployment, with separate application servers. That is another implied limitations of MUMPS -- not only are you restricted to one database server, your applications have to run on that same ser
Re: (Score:2)
For Kaiser, they set up logical geographic nodes and built their own sync system to update the network of nodes on demand.
Re: (Score:2)
perhaps you might want to actually read the documentation for the current shipping product before you make indefensible statements
Comments from a former MUMPS programmer (Score:5, Informative)
MUMPS (Score:2)
As a former MUMPS programmer, yeah; it is bs. Modern languages do a better job in data management. However, certain health care systems do an EPIC job in pushing for obscure languages and technologies - like a message queuing database with a VB middle-ware layer to make it talk like a mainframe. Probably has something to do with lock-in and consulting... Yet, we have to push data into a relational data warehouse to do anything useful with it. SSIS and relational for the win.
old news (Score:2)
how is this News?
many other healthcare systems are built on mumps, not just VA and EPIC. Notably Meditech is also mumps based, having rolled out of MGH the founders of MT took mumps with them. Judy Faulkner (from epic) then rolled it from MT created epic and drug around mumps with her. IDX (now GE) is also heavily into mumps. its everywhere. here she is talking about using mumps http://www.modernhealthcare.com/article/20150314/MAGAZINE/303149952
the new bread of healthcare apps have pretty much moved aw
Integration of data and language (Score:2)
dBASE (AKA "xBase") also integrated the programming language with the database, and I was super-productive under that language for a good many tasks. The bloated database API's used now are just eye and finger clutter and wasted busy-work and causes of Carpel Tunnel.
xBASE was not suited for formal "enterprise" applications or if you wanted fine control over the UI, but for smaller projects I could crank out apps in a snap. True, it was not always the easiest to maintain if not written carefully, but that's
Accreted Horror (Score:2)
I thought it was fairly well known just as a horror story about what happens when you don't design a language, you just accrete it (charitably, when the language is extended so far beyond the initial design that it completely escapes it). Like bash or perl or PHO but oh so much worse because everything's worse in health care and govt.
From Wiki, this is considered good MUMPS code:
GREPTHIS()
NEW SET,NEW,THEN,IF,KILL,QUIT SET IF="KILL",SET="11",KILL="l1",QUIT="R
Re: (Score:2)
PHO? Obviously that was the version before PHP.
Holding things back... (Score:3)
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.
'Some MUMPS I wrote for fun' :) (Score:2)
I work with M at work (Score:2)
At first I thought it was a ridiculous anachronistic language developed by a bunch of IT guys in the 60's that had a poor understanding of even most contemporary ideas of programming languages. now? I think it has it's place. It is very focused on mutli-dimensional arrays and makes manipulating hierarchical data structures very efficient. Another person's Perl code is easier to read but it is efficient for what it does.
Re:This MUMPS? (Score:4, Funny)
Yeah, you would think Vax would get rid of MUMPS.
Must be those damn Anti-Vaxers.
How I searched for MUMPS and R (Score:2)
because anything with a single letter name is pretty much impossible to google (R anyone ?)
I just tried two searches on Google (with queries r language and mumps language), and the top 10 results of both were relevant. What query was giving you trouble?
Re: (Score:2)
I've never had trouble googling for help on R. I just google "r topic i need help with" and it's pretty much always relevant.
Re: (Score:2)
there are no significant opportunities for educating younger professionals except through other than "real life" - using live/production systems and actual persons' medical information.
the nonsense is STRONG in this one
Re: (Score:2)
It's been called MUMPS for at least the last 20 years...
Re: (Score:2)
Comments like this make me giggle. I could say that same thing about most attempts at making a middleware engine out of Java (ICAN, JCAPS) that moves data around in Healthcare requiring more hand-holding and debugging than is worth it - but that too is just an opinion...
Then again, any badly created system in any language can share the same root "turdiness" - it depends upon how it's built and maintained. I've seen some awesome Perl code that is elegant and readable, as well as some that looks like it was c
Re: (Score:2)
Yes.
Re: (Score:2)
but it was invented in the 1970s, before the concept of OOP had even been invented.
If it really was the 1970s, then it came some years after SIMULA-67, aka "ALGOL with objects". (I.e., SIMULA-67 was to ALGOL more or less as early C++ was to C.)
Everything in CS is (probably) older than you think. Including many of its practitioners ;-)
Re: (Score:2)