A somewhat recurring theme in life seems to be where its still OK to write software in M/MUMPS.

Discussion here in an open LinkedIn group: http://tinyurl.com/7ew8aje

Maybe this is really for my technical journal, but its really about bad questions and business decisions.

Lyle Schofield • The original article, like much of the criticism of M/MUMPS, is the usual apples and oranges comparison. M/MUMPS is being compared with a database management system like Oracle or MySQL. MUMPS is a source code for logic expression that creates the illusion of a database management system because of its persistence of data, but does not have the features associated with DBMS of meta-data and relationship structure. So, a comparison of MUMPS to a database as in the original article is like a comparison of Spanish to the Dictionary; they are serving different purposes and aren’t directly comparable (but maybe seem that way because they both have “words”).

The original post here then takes this to the “should we replace MUMPS in EHRs”. I would answer this with “who cares”? Does anyone ask what the source code for Microsoft Word? Quicken? Halo? We’re purchasing applications with functional points, and the important question is whether the product has those functional points.

I suppose the reason we ask these things of healthcare apps (and maybe more generically enterprise apps) is because they don’t satisfy all our functional points, and we know we’re going to need to hire some systems integrators and database people to abstract and convert data, and now we care about the underlying database technology. Back to the linked article, this now gets into the more interesting (to me) place of the business drivers for this. As a builder of IT products, I’ve learned that the most important consideration in the technology choice is what technologies do I or my company know? Trying to turn a Microsoft programmer into a Linux developer is a huge productivity hit. As a former manager of purchased applications I need to find people that can get me the data I need from a limited enterprise product. If the only choices are a small number of boutique shops I’d be worried.

Resource availability is a really important thing to consider, but its pretty far removed from “can you build an EHR in M/MUMPS”. Epic and others seem to have done a fine job building successful products in this technology, so there’s the answer. The fact that some perceive the platforms for some products as limited is more of a sign that the vendor strategy doesn’t include local customization, someone didn’t do a complete job aligning their needs with their purchase, or maybe someone needs more experience in the technology. You can write anything in anything if you want to I suppose. We used to all program in assembler at some point, didn’t we?

And, my opinion doesn’t matter, the market will decide which technologies are viable. I think a lot of the MUMPS criticism is based on old versions of the standard, InterSystems and others have done a fine job adding functionality past the standard into current needs BASIC is hardly the same thing it was in 1980, too. The VA is big, but not big enough to keep MUMPS afloat on its own; the fed was pushing ADA at one point – remember that one? The market controls all.

(background – used to develop in MUMPS a lot, but not in many years at this point.)

Be Sociable, Share!

Tags: , ,

Leave a Reply