VistA Innovation?

VistA cannot evolve if its MUMPS code is viewed as the unfortunately obsolete back-end for Node.js applications.

If we buy into the current prevailing wisdom that we should essentially leave VistA’s MUMPS code in maintenance mode, enshrining its current structure and shortcomings, we are implicitly asking for it to be slowly phased out, and replaced with something else.

Adding blobs of red and mouse support to ScreenMan forms is not VistA innovation.

Building hundreds of new RPC broker calls for consumption by Javascript code is not VistA innovation.

Building tools to paper over the cracks in KIDS and DIFROM is not VistA innovation.

Writing web frameworks that expose MUMPS globals and VistA RPCs is not VistA innovation.

Even if you use every DevOps tool and agile methodology that is trending on Reddit while you’re doing these things, it’s not VistA innovation.

We can wax eloquent at great length saying that lab and scheduling are the keys to the kingdom, but the very best lab and scheduling packages really aren’t VistA innovation.

We are at this point essentially putting lipstick on a pig. The pig may be a tremendously powerful and intelligent wild boar that can do thousands of things normal pigs can’t do, but wrestling with it will still leave a bruise.

That’s not to say that DevOps tools, web frameworks, packaging ideas, or any of these projects and ideas aren’t innovative. They are, and everyone who does that work deserves praise and appreciation for it. But these are accessories. Nice, useful, pretty, and even essential accessories. But are they VistA? No. VistA is 30,000+ MUMPS routines, written in a style that was in vogue during the Reagan administration.

VistA’s entire MUMPS codebase needs to be refactored. Not replaced, but refactored in a way that reflects all the great and useful techniques that computer science has taught us since the underground railroad went mainstream. And yes, I mean APIs. I mean separation of concerns. I mean (perhaps controversially) that the SAC needs to quit forbidding mnemonically useful identifiers, and instead start forbidding us to leak data through local variables. Well-defined interfaces, that cannot speak to any component of the software that is more than one layer of abstraction away from it. Interfaces forming a strong contract between the software and the developers who develop against it.

MUMPS is more than up for the task. We have scoped variables with NEW. We have call by value and call by reference. We can pass complex objects to and return complex objects from well-defined methods in the form of MUMPS extrinsic functions and the glorious dot operator. Every modern implementation of the MUMPS language supports at least 31-character identifiers and large routines, so that routine names like ZZTQPRL3 are now not only unnecessary, but indefensible.

VistA cannot survive if we have the hubris to maintain that its design is sacrosanct, and superior by definition to new technologies. Along with this, we can no longer pretend that medical software is any different from other complex software, nor can we lie to ourselves and say that MUMPS–or hierarchical database technology in general–is inherently superior to other database technologies in our domain, and finally, we cannot continue insisting that advances made in programming methodology and software architecture don’t apply to us.

It’s been asserted–but not once effectively proven or even rationalized–that these computer science concepts (layers of abstraction, interface contracts, APIs, and separation of concerns) somehow don’t apply to medical software, or to VistA. I’ve personally heard arguments ranging from “APIs are an attack vector” to “VistA is a living organism, unlike any other software.”

Poppycock. Absolute rubbish. So completely wrong as to be comical.

First, VistA is utterly loaded with APIs. Every time someone calls into Kernel or FileMan, that’s an API. Every time someone writes a new RPC, that’s an API. And every one of them is as much an “attack vector” as it is in modern software. The only real difference is that ours aren’t well-architected, ours don’t separate concerns, ours are poorly documented, ours require way too many arguments, and ours have horrible names that nobody can remember.

Second, software is software is software. The things that make an operating system unmaintainable make an EHR unmaintainable. The things that make a word processor maintainable make an EHR maintainable. Even the argument that hierarchical databases are somehow inherently better-suited to medical data than relational databases (or network databases, or any other database) is specious and silly. Perhaps this was arguably true in the 1970s, but it is not true today. Every data structure that you can represent in FileMan, you can represent in Oracle or MySQL or DB2, with minimal fuss. Look at Practice Fusion. Look at Amazing Charts. The hip, new EHRs are all based on modern databases. It can be done.

It’s been argued that MUMPS’ lack of schema makes it easier to change the database to match the evolution of medical data without re-writing the software. Again, rubbish. Once FileMan is in the picture, we are right back to employing a schema that requires UI modifications once we change it. FileMan enforces its own schema on data organization. True though it is that external modules like ScreenMan make it relatively easy to propagate schema changes into the user interface, this same sort of ease exists in relational databases with technologies like ORM, LINQ, and others. And today, there are methodologies that make it even easier to propagate schema changes all the way up to the UI. If software developers employs proper separation of concerns and strong interface contracts, changes to the schema are transparent to the UI.

VistA admits of no such discipline.

In VistA, user interface, business logic, schema definition, and data storage are tangled together like Christmas lights in the box in Grandma’s attic. You can’t even programatically define a new FileMan file; it’s all done through interactive green-screen UIs, and distributed in KIDS builds, the installation of which are notoriously error-prone.

MUMPS has the facilities to make all of these nightmares disappear, and where it shines is in throughput, robustness, and scalability. It has great facilities for indirection, data hiding, abstraction, and all the other tools we need to make VistA even more awesome than it is. Just takes some time and dedication. It’s also fast. Extremely fast. Like, bullet train fast.

And VistA is awesome. The developers in its community are awesome and have tons of enthusiasm. But today, its core infrastructure needs some serious attention. MUMPS and VistA are kind of like a gorgeous Tudor mansion: scores of beautiful, ornate, and useful rooms, but all the pipes leak, the wallpaper is peeling, and the light in that one downstairs bathroom is always flickering for some reason. And we’ve lost the blueprints.

The VA wants to bulldoze the house and put up a shopping mall, a Best Buy, and a McDonald’s. In the meantime, they’ll throw some glue behind the wallpaper and set up buckets underneath the leaky pipes.

But the house is free for public consumption and improvement! So instead of doing what they’ve been doing, let’s fix the plumbing, put in some new wallpaper, and fix the electrical system. And while we’re at it, we can add central heating and a gourmet kitchen.

That is VistA innovation.

4 thoughts on “VistA Innovation?

  1. All very well, John, but who’s going to do this re-factoring and why? Where are the skilled Mumps developers, proficient at writing modern business-critical Mumps code and integrating with the 2016 IT mainstream, to re-factor 30,000+ routines?

    1. A valid point, Rob. Though I’ve long felt that the community profits more from a small group of highly dedicated MUMPS developers over an army of the same. I think it could be done with the current community if some funding source could be found.

      It’s kind of one of those chicken-and-egg scenarios. Ugly VistA code is often used to demonstrate the “inferiority” of MUMPS, thus scaring new developers away, and I do feel that if VistA code was improved to be the best MUMPS it can be, it _could_ assuage some new dev’s fears, if they’re level-headed in approaching it.

      I should stress that I’m not saying that JS front-ends are a bad idea. Far from it; I think they’re wonderful. Only that shoring up the foundation would make the experience of developing such front-ends much more pleasant.

      I’ll use Linux distributions by way of analogy. Your user-facing application developer can choose from Python, Node.js, bash scripts, etc. to develop great front-end applications. People proficient in using these technologies are legion, and many of them have neither the inclination nor the skill to write C code for applications, much less for the kernel.

      But the kernel itself is foundational, and its developers are a tiny subset of the Linux ecosystem. They enable the application developers to work without worrying about (or knowing) the kernel code.

      The Linux kernel is substantially larger and more complex than the entire corpus of VistA’s MUMPS code.

      So, I think a small community of MUMPS developers (who would, by the way, have to be free of arcane VA procedures and requirements) can reasonably be expected to refactor, improve, and maintain VistA’s MUMPS code, leaving front-end development to the much larger community of Javascript developers (or, indeed, developers in whatever front-end language best fits the requirements of the day).

  2. I can really see why front-end improvements are given such a priority: they are all the decision-makers see when considering whether to replace (say) RPMS with (say) Cerner. It *is* a zero-sum game, and time spent on the foundation doesn’t go to the Bauhaus-style window treatments – and yes, real features – that make sales. I work in government, and the things our clients care about most are quick turnaround on new reports, which has driven us to SSRS for now (though we spent the last three days finding an obscure limit in an class that blocked saving vax records).

    What is to be done? By all means, shore up the foundations where necessary. But be mindful of the feature lists that the decision makers are considering. By your own arguments (which I think are spot on), an EHR that is designed (or at least sold) by people who understand the real concerns of health professionals and administrators could almost be based on SQLite. The person-centuries of experience that have gone into VistA and its ilk are an advantage, but one that is depreciating.

  3. In theory your arguments are sound, though I’d suggest that if you were to re-factor VistA’s code-base, why not take the opportunity to use the same language as the front-end, which gives you a lot more chance of building a community of people large and capable enough of onwardly maintaining and extending it, and having it accepted in the mainstream of IT?

    That aside, the real show-stopper is who would fund such work, particularly using Mumps code? In particular, what would be in it for anyone to do so (other than the VA, who won’t, for all the wrong reasons)?

    Sorry, great ideas in theory, but I don’t see it happening any time soon.

    Much better walls to bang your head against out there, in my opinion…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s