The Problem with VistA: "Its the Platform, Stupid"

The Problem with VistA: "Its the Platform, Stupid"

Platform (plăt’fôrm) n.

    1. A formal declaration of the principles on which a group, such as a political party, makes its appeal to the public.
    2. The basic technology of a computer system’s hardware and software that defines how a computer is operated and determines what other kinds of software can be used.

    I read with interest a recent article by my favorite health care reporter, Joe Conn, who has long time interest in the commercial success of the VistA Electronic Health Record system developed by the VA.

    VistA has an incredible, well described impact on the clinical and system peformance of the VA. Given its availability through the Freedom of Information Act, it can and should seriously be considered as a potential solution for government-based health care information technology. I mean, why not? The several billion dollars already invested, and the several billion dollars already wasted on alternatives, would hopefully help the new administration come to their senses to realize the development of a common platform for all government related health IT would make good business sense.

    In the past, this notion has been fought by the other departments who have “special” needs (NASA needs their own system, Indian Health Services has a different focus, DoD needs increased mobility, etc). Whatever the “smoke screen” reason is, the fact of the matter is that these departments are protecting their turf and their budget. However, all of these entities have some basic functionality that is required of any basic system (Patient Information Management, Laboratory, Pharmacy, Radiology, Notes, etc) that are shared across the departments. This “basic system” should be conceived of as the core platform from which the modular functionality can be built. Everyone develops to the common core and creates “apps” (modules) that tie into the generic platform but serve specialized needs.

    I don’t think anyone would argue with the success of the Facebook platform, nor the various app extensions that have been automonomously developed by its users? Would anyone argue against the Apples iPhone platform and App store framework? Well, it seems that VistA has the potential, certainly within the Federal Health care space*, to become the defacto platform from which to build.

    But what about the private sector? Does VistA have a similar opportunity.  Among many issues that prevent the widespread adoption of VistA in the commercial sector, one unfortunately persistent problem is what “version” of the platform should we use (WorldVistA, OpenVista, vxVistA, or flavorofthemonthVistA). While this is irritating and groups like World VistA and the VistA Software Alliance have been wrangling with this issue since 2002, it belies a more fundamental problem with the widespread adopting VistA  – it actually isn’t (or as currently constructed) a viable platform.

    What? Heresy? What say you?

    The inestimable foundational system from which VistA is based is MUMPS. MUMPS is both a programming language and a database all conjoined into one ugly mess that only a mother could love.
    The story of MUMPS, and its use within the VA is quite fascinating, and the religious fervor of its faithful and its detractors is epic. However, then nature of MUMPS makes it actually quite hard to “modularize” VistA. You can’t really cleanly delineate between parts and subparts, from routines and runtimes, and most importantly demarcate between the notion of a “platform” and the specialized apps.

    This has led to commercial challenges in extending the system, having to swallow the software “whole” without the inability to easily integrate other IT investments, or the limited ability of third party development shops to rally around the platform by creating supporting apps that meet critical market feature/functionality needs. Until this problem is solved – until we get to some layers of abstraction within the technology stack – VistA will continue to bump along in its adoption, we will continue to be mired in forking conversations, and bogged in difficult licensing issues to work out that prevent true collaboration.

    I am hoping someone, anyone, who is interested in VistA’s commercial success will be able to create the platform/app separation that I would argue is required for VistA’s long term commercial success.

    * There are specific reasons why VistA can and should become the defacto standard within the Federal Health System:

    1. The VA is the largest health care system in our country with over 160 medical centers and 1,300 clinics all utilizing essentially the same software.
    2. All the current information technology systems are derived from it (Both the DoD and IHS use a variation of VistA) and therefore share significant architectural similiarities.
    3. VA has been by far the most successful historical in achieving clinical transformation through the use of information technology; although IHS is by far the most innovative now health care IT branch of the Federal Health System thanks to the vision of CIO Terry Cullen, MD.
    21 Comments
    • Sales Objection #2: MUMPS is Dead (No, its actually EPIC) « Crossover Healthcare
      Posted at 06:41h, 13 January Reply

      […] definitions The Problem with VistA: “Its the Platform, Stupid” […]

    • Rob
      Posted at 07:12h, 13 January Reply

      Interesting article, but I’d take issue with your statement: “However, the nature of MUMPS makes it actually quite hard to “modularize” VistA. You can’t really cleanly delineate between parts and subparts, from routines and runtimes, and most importantly demarcate between the notion of a “platform” and the specialized apps.” Please be clear: this is most definitely NOT a feature or inherent problem in Mumps per se. It CAN be a problem with old legacy Mumps code that was not originally written with such capabilities in mind, but I am sure there are many legacy systems written in other “mainstream” languages that suffer the same limitations, simply due to the way the language was used at the time.

      In fact I’m aware of a number of people involved in grafting new and modern web interfaces onto VistA modules, demonstrating the complete opposite to what you purport to be an intrinsic problem. I really don’t see any reason why, given the desire and incentive to do so, core VistA code couldn’t be modernised, converted to web services, web applications etc.

      • Scott Shreeve, MD
        Posted at 07:57h, 13 January Reply

        Rob,

        Thanks for the note. I hope you are right. In fact, I know you are right about the possibility. I would love to see someone really abstract it out because that is the KEY to the actual modernization of the entire platform. VistA is one of those “legacy systems” that could use a little superchargin’ with some of the modern concepts (the system was originally optimized for the PD11 for goodness sakes!).

        Do you have any specific companies, or specific projects, or specific examples to back up your interesting claims. Shine some sunlight and lets highlight these groups seeking to liberate the spirit of VistA that has become entrapped in some of the legacy challenges of a still promising system.

    • Christian Hergert
      Posted at 10:13h, 13 January Reply

      I would love to see a medical framework built upon the ideals of Jabber. Decentralized and designed around future growth changes. We know that we will never get it right the first time; lets build with that as a requirement.

      With the jabber model, I could own and control my medical data. However, it would simultaneously create an ecosystem of medical data providers that could host that information for you. This is where HealthVault completely FAILED. Microsoft controls the data, and you can only authenticate/login OVER THE WEB! I don’t know about you, but I desire a system where applications can do continual data processing on my stats; not just when I’m at a computer browsing the web.

      Requirements for Success,

      * Decentralized
      * Open Framework
      * Framework does just that, be a framework and framework alone
      * Allow users to delegate control to their health provider (this way, all medical groups share the platform and its data, if authorized)

      $0.02

      — Christian

      • Scott Shreeve, MD
        Posted at 16:19h, 13 January Reply

        C-town,

        Great to hear from you. When did your migrate from VWdude to Audidude? What an upgrade. Let me know when you are rolling in your new S5 or R8.

        Your comments are excellent. Clearly Microsoft, with their legacy approach to data ownership, is going to miss the boat by virtue of their philosophical and technical approach. I am wondering about your assessment of Google – how much do they approach your ideal? If not Google, are there any other health care information aggregators that people see are moving in the direction you propose? More succinctly who or what type of entity would you feel comfortable with as the trusted third party to hold you information (in the cloud?).

        Interested in your thoughts?

    • Brian Lord
      Posted at 14:32h, 13 January Reply

      Sequence Managers has had several successes with integrating new technologies into VistA on several levels. The latest is using REST web services to connect VistA to a rural hospital billing system. Currently we are building a framework so that all of the Core VistA system which you so correctly pointed out are the key can be connected to not just the database but the business logic itself. In addition Kevin Toppenberg has successfully linked CPRS itself to the patient registration system. This gives the majority of Clinical users no need to use a separate interface to perform their normal jobs.

      I agree with you the current state of the VistA code is a mishmash that was built to save space and speed in a time where code was more advanced than the computers it ran on. Now however it is not the language that is the issue since I see GT.M and Cache as both being very viable large scale DB plateforms, but rather the standards of coding, and legacy code that must be fixed. It is hoped that Sequence Managers will at least do some of the work this year and that work will be made available to the community.

    • Rob
      Posted at 16:07h, 13 January Reply

      I’m hoping some of the people concerned will provide some relevant information about VistA initiatives themselves, but let me give a few non-VistA examples that I hope demonstrate that Mumps has no practical limitations in today’s modern IT environment and is right up there with the best of them:

      – our EWD product (http://www.mgateway.com/ewd.htm) is pure Mumps code, and is being used to create bang up-to-date Ajax front ends on a number of legacy applications around the world. Fast, agile team-based modern development is possible, as we showcased at AjaxWorld last year. Yes, another big name in healthcare here: http://www.slideshare.net/george.james/missioncritical-ajaxmaking-test-ordering-easier-and-faster-at-quest-diagnostics?type=powerpoint

      – Our M/DB database product (http://www.mgateway.com/mdb.html): a 100% API-compatible alternative to Amazon’s SimpleDB. Again pure Mumps, but this time a “black box” that is accessed via REST. One of the SimpleDB exploration utilities, Bolso (http://www.cafesilencio.net/bolso/), now supports M/DB too, and the interesting thing is that they neither knew nor cared that M/DB was Mumps-based. They just needed to know the SimpleDB APIs to do the integration. Now consider the equivalent kind of wrappering done to VistA…..

      So what we’re actively demonstrating is that not only is it quite straightforward to put the most modern Ajax user interfaces on Mumps applications, they can be made available as web service-based “black boxes” so that integrators don’t need to know anything about Mumps to use them. But if they care to take a look inside they’ll find a language and database that can be used just as effectively as anything else out there.

      • Scott Shreeve, MD
        Posted at 16:25h, 13 January Reply

        Rob,

        Bang! Thanks for your insightful comments and the excellent examples your provided of what mgateway is doing. I am not debating the value or virtues of MUMPS itself, as I have learned over the years its performance, reliability, scalability, and speed are second to none within health care (which is why the whole MUMPS “performance” sales objection in my mind). However, MUMPS has always been thought of as this legacy language without the flexibility (let alone the programmers) to continue to extend it into the future.

        My point in the blog was that for VistA to become “all that it can be” will require the exact type of approaches you are demonstrating . . . the ability to modernize on the front end, separate it out its “platform” features from its “app” features, and add the “latest and greatest” UI’s to the front end. If this can be done – not only with MUMPS be around for a very long time but MUMPS based systems with new UI’s should continue to rule the day!

        Thanks again for your comments and the examples that you shared. I hope everyone else gets the message.

    • Martin Mendelson
      Posted at 18:16h, 13 January Reply

      After 27 years of using MUMPS, I feel I can confidently say that it is the best and fastest database system I’ve encountered. As for modularity, VistA is a perfect example of modularity: at Western State Hospital in Tacoma, Washington, we have been using VistA and its predecessor, DHCP, since the early ’90s, adding modules over time. We recently added the VistA dietary module and were able to easily integrate it into a database spanning 15+ years of patient data. I am currently in the process of adding the radiology module, and here too the power of the MUMPS database enables facile integration of new capability into the existing system.
      For years the real issue for users has been their desire for a graphical UI, and the modern MUMPS implementations, Caché and GT.M, both can host apps written in languages such as Delphi and Java and VB to provide that capability. At Western State we are currently supplying web-based interfaces to our staff as well as installing CPRS – the V.A.’s GUI for use by providers. And this is being done by in-house staff at ridiculously low cost compared to commercial installations.
      For as long as I can remember, sellers of commercial products have denigrated MUMPS in various ways: “outdated”, “not object-oriented”, “optimized for the PDP-11”, and more. All wrong, all misleading: MUMPS as a language has changed and developed over the years, and MUMPS as a database has certainly been constantly upgraded to run on the latest generations of hardware and OS. I expect that MUMPS will be around and working longer that I.

      • Scott Shreeve, MD
        Posted at 18:33h, 13 January Reply

        Martin,

        Thanks for your comments regarding MUMPS. My point about modularity is not about modularity within the platform, but modularity with third party applications that can tie in from outside the platform. Adding on additional modules that are already built out in MUMPS specifically for the VistA platform is easy – dietetics, radiology, and the other 120+ modules. However, my point was to highlight that when a comprehensive system like VistA gets plopped into a complex hospital environment, there are typically between 15-25 other systems that must be tied into the centralized VistA health information system because that functionality does not exist native within VistA (ICU monitoring, financial functionality, monitoring devices, etc). This is challenging work given the current construct of VistA.

        In terms of objections to MUMPS, I agree that they are “wrong, all misleading” and soon are going to be quite outdated. I also agree that its unique properties make it an exceptional tool from which to build a health information system. Given what I am learning about some the evolution of MUMPS and its ability to interact with newer UI technology I am more convinced than ever that MUMPS based EHR’s have a very bright future.

    • Gregory Woodhouse
      Posted at 20:56h, 13 January Reply

      This is a significant issue. One of the biggest difficulties we encounter with maintaining and extending MUMPS based systems like VistA is the lack of a module system in the underlying language. To be sure, there are various ad hoc mechanisms for encapsulation, and vendors have introduced their own extensions, but the community has resisted (some would say stubbornly resisted) updating the language to better address current needs.

      It is perhaps worthwhile to compare MUMPS to another “legacy” language that has remained very popular, Scheme. Scheme was first introduced in 1975, but is part of the Lisp family of languages which goes back further, at least to 1960. The language has been very popular due, in large measure, to extensions that have been introduced by vendors and open source projects. My preferred implementation, PLT Scheme, has a robust module system and good support for objects. Interestingly, in the most recent “official” version of Scheme, R6RS, has finally introduced modules under the name library.

      We’re not there yet with MUMPS, but without suitable language level support, there will always be significant obstacles to working extending and adapting existing systems. This translates to higher costs and lost opportunities.

    • Steve Owen
      Posted at 00:56h, 14 January Reply

      Changing the face of VistA in 2009 – with a RIA engineered using M/Gateway’s Enterprise Web Developer and the Ext JS JavaScript library is the path were taking at VOE Solutions.

      A web desktop that will make wonder, “is it my desktop, or my browser?” Ext JS provides the flash and web presentation while EWD gives you the tools to integrate the browser, Ext JS, and VistA data. We can leverage the existing RPC broker framework and DBS call functionality. EWD custom tags give us the ability create re-usable, configurable, VistA data aware components that can be passed off to the web designer.

      And if you want to get revved-up about Ext JS design, take a look at the very soon to be released Ext 3.0 Designer:

      http://extjs.com/forum/showthread.php?t=52258

      The platform is fine, you just gota jump in and get wet

      • Scott Shreeve, MD
        Posted at 07:29h, 14 January Reply

        Steve,

        I am a HUGE fan of RIA and to be honest, given the strength of the VistA backend, I was hoping that someone would arrive at this same conclusion at the front end. JSON and Ext JS are compellling tool sets to bring the data alive. My favorite RIA development shope is Cynergy Systems based in SD. I was blown away by some of the concepts they developed.

        I would love to see what you are thinking in terms of some front end extensions. Please advise.

    • Rob
      Posted at 10:13h, 14 January Reply

      I’m hoping Steve will post some examples – I think you’ll really love what he’s been doing with ExtJS and VistA. Unfortunately I don’t have any live running examples of stuff I’ve been helping customers with that I can make publicly available right now, but to get an idea of what’s possible, take a look at this document: http://gradvs1.mgateway.com/download/extjs4.0.746.pdf Ignore all the technical stuf – just check out the screen-shots. In particular take a quick look at the screen shots from page 71 onwards which show how the ExtJS “web desktop” can be developed (Steve: that’s what you’ve been using, right?). The examples are based around Cache, but will work just as well calling back to Mumps functions that wrapper VistA code.

      For even more pizazz, throw in something like Emprise Javascript Charts (see http://gradvs1.mgateway.com/download/ejsc4.0.682.pdf – again just look at the pictures) and now you’re visualising Mumps data (results, diagnostic tests etc) as graphs and charts, all done in Javascript (ie no plugins), and capable of being implemented literally in minutes.

      Sorry Gregory, IMHO the time for purist navel-gazing is over. As Steve is demonstrating all this kind of stuff really *can* be done today using the existing VistA code base, and rapid, fast and loose development techniques and third-party Ajax tools are there to make it all quick and easy. Now JFDI guys! 🙂

    • Wally Cash
      Posted at 00:32h, 22 January Reply

      I am certainly not qualified to speak to VistA platform issues per se, but I can offer some screenshots (see http://wallycash.com/screenshots.html) which attest to the power of the “fast and loose development techniques” described by Rob. The screenshots were produced by connecting the OpenLaszlo RIA platform to OpenVista via M2Web as described in this thread on the Hardhats mailing list http://groups.google.com/group/Hardhats/browse_thread/thread/64a4377fbc536b1d/ee4bfb0b9b07380b?lnk=raot#ee4bfb0b9b07380b. What is remarkable is not the screenshots, but the almost ridiculous ease with which the demo which produced them was created. Platforms such as OpenLaszlo and EWD might well be the keys which unlock the disruptive potential of VistA.

    • Ten Fold (10X): Is There Really an Order of Magnitude Difference? « Crossover Healthcare
      Posted at 01:46h, 31 January Reply

      […] recent news items caught my attention. They follow on the heels of some of my recent writings on VistA EHR, MUMPS based systems, and the idea of collvirtuous cycle investments as a true stimulus in helping […]

    • Richard
      Posted at 12:37h, 17 May Reply

      Scott,

      I am a programmer with 10+ years of developing enterprise web technologies (.Net, Java, XML, Relational SQL Databases, etc). I started looking into VistA for a Doctor friend of mine for use in his office. I has never heard of MUMPS before last week, but I can say, after looking at Cache, VistA, etc for one week, that it will not be an issue developing any external apps against the VistA platform that leverage web 2.0 technologies. Many already exist. In fact, the WorldVistA project has code that allows you to reference VistA data with XPath, which is the standard method of accessing data in XML format using //node syntax. I will say that understanding VistA is not for the faint of heart,nor is it for neophyte programmers/system admins/IT guys. It is a complex system, but the complexity is out of necessity because it is a complex problem.

      Let me close by telling you an old programmer’s adage: There is a function for everything.

    • VistA – Its Now or Never « Crossover Healthcare
      Posted at 04:35h, 02 June Reply

      […] I have to think that an excellent public investment would be to extend and build upon VistA as a platform for a specific subsegment of public, state, and federal related facilities. These efforts would be […]

    • Butch
      Posted at 20:45h, 16 August Reply

      Being a member of WorldVistA and being a Solaris admin, I can attest to some of the problems, and complexities that we have run into. The “problem ;)” in our case, is that we intend to use VistA in small family practices. It was never designed for that, and introduces it’s own set of complications and problems.

      It’s worthwhile, as far as I can tell, to get the little guy into a position of being able to better care for there patients, by using and getting used to the “process” that is also VistA. That’s the portion that so many people seem to overlook. It’s not only software, it’s a different way of doing things, that works remarkably well.

      Yes, a lot of people complain, and gripe about not having gui frontends. Understandable. The people who know the systems inside and out, also know that a gui isn’t all that it’s cracked up to be.

      Fine for some things, horrible for others.

      I’ve seen first hand, some of the things that have been done, by the EWD guys, and what has been done with OVID. OVID is the new Java interface provided by Medsphere, and it also holds a great deal of promise.

      The biggest problem with VistA, is that it was never designed with Java, and web interfaces, or even modularity in mind. (I’m referring specifcally to VistA not M). It was also never designed to be put into a small medical practice. However, the EWD, OVID, and the cadre of people who are making it all work anyway, prove that anything is possible.

      I know of a small group that is considering re-writing the VistA core, to make it more friendly to the small practice, and to make it more modular. This project isn’t meant to take the place of World VistA or any of the other VistA’s, but meant to fill in one of the largest gaps in health care today.

      DHCP, VistA, and the process that has evolved from these software packages, are the most significant changes in the health care industry, since family practice came into being. It got people talking, and taking notice of what was happening.

      Let’s hope that whether VistA lives on, or dies off, that the trend of communication continues.

    • Eric Santerre
      Posted at 22:41h, 29 September Reply

      One of the big problems with VistA is, in the private sector, that its ancillary submodules are serverly crippled and antequated. There are standard features missing in the Pharmacy, Lab and Radiology packages that other intergrated HIS-software systems have had for decades, and it appears little has been done to modernize, by anyone, any of these modules.

    • We don’t know anything, really « JPowers.IN3.ORG
      Posted at 04:48h, 16 January Reply

      […] legacy apps. Reality similarly intrudes in Scott Shreeve’s Crossover Healthcare essay The Problem with VistA: “Its the Platform, Stupid” and the good comment thread about the VA’s pioneering electronic medical […]

    Post A Reply to Scott Shreeve, MD Cancel Reply