Turning VistA into a "real" open source project

Interesting that there is an ANSI standard for MUMPS. It was the third ANSI standard after FORTRAN and Cobol. The Standards committee was active and making positive enhancements to the language up until 2000 when the VA stopped supporting the Standards Committee. It is interesting that MUMPS has been running the VA, hospitals for over 30 years and continues to do so. The early MUMPS software was written to the limitations of the hardware of the time and the more primitive early ANSI Standards of 1977 and 1984.

MUMPS is very powerful and requires very little computer to accomplish some very powerful tasks. MUMPS is all run-time assignment so there is no preallocation of database space. The databases are no larger than they have to be.

There is a reason that VistA is written in MUMPS. The VistA system was developed by VA doctors, nurses, lab techs, pharmacists, and other subject matter experts (SMEs). It has been so useful that it has been used by the VA, Indian Health Service, and the Department of Defense (search on CHCS-I for more details). VistA is a tool kit for solving problems. Frequently the end user is the best expert in how they need to practice medicine. MUMPS is almost all source code. Those who work with VistA for only a short time can learn the basics in a very short time. The supportability is very good in that the MUMPS interpreter keeps track of the last command that executed and failed. The symbol table is still intact and can be examined and modified. A lot of times the run-time stack is maintained and the problem can be trapped and repaired at run-time and the execution can continue. VistA is a tool kit and an enterprise-wide database environment. VistA is a collection of no less than 160 application areas of the hospital and they all share the same databases. VistA is Open Source. You get all of the source code. It is complex, but it is also easy to add new functionality onto the existing framework. Rather than having to start from scratch each time there is a new application, the new application has 70 to 90 percent of the supporting architecture already in place. New application are built and tested in hours or days, not months and years. VistA support was done in hours and days when the VA personnel were separated from developing their own solutions after the Clinger-Cohen Act in the mid 1990s. With third party vendors, the development time expanded to 18 to 24 months for fixes and new functionality. So we got solutions to two year old problems rather than the day or less turn-around that the VA user community was able to accomplish for a whole lot less money. The time to fix problems is one of the biggest tragedies. Fast turn around has always been the case with VistA. The loss of the VistA support community was another huge issue. The user community is replaced by vendor support which does not understand the application as well as the people that wrote it or work under the people who wrote the code.

For a case in point, look up "Core-FLS" a vendor's efforts to replace a system called IFCAP, part of VistA that we owned. This little experiment cost us over 300 million dollars to replace something that we owned, and worked better than the replacement Core-FLS. When they went live at Bay Pines VA Medical Center in St. Petersburg, Florida, they had to close elective surgery and then migrate back to IFCAP. This situation is not unique. Various other parts of VistA have been attempted to be replaced with third party vendors and it has been a major expense and hallmarked by major expensive failures. To the vendors, failure is not defeat. They can always get their support contracts renewed. Success and delivery of the new application means that the paychecks stop or the team that developed the code is disbanded to work on other projects. When the VA budget was slashed after Katrina and the recovery of New Orleans, it was the Vendor Brain Trust that was released. Support of the Vendor written system literally disappeared.

To Roger Bakers credit, the PMAS effort to make the vendors come up to snuff (meet their mile-stones or they are out after 6 months) has been a success when it has been allowed to work as it has been intended. Unfortunately there seem to be Zombie Projects out there that keep getting extended regardless of the shortcomings.

You will find that most of the successful hospitals in the country (and a lot of other countries), are being run by MUMPS. Even Epic, the vendor attempting to replace VistA is written in MUMPS. Oddly enough, MUMPS is out there and running in a lot of places that you would not expect, banks, credit unions, libraries, law offices, travel industries, containerized freight and shipping. MUMPS is a powerful tool that runs very well on a really wide spectrum of hardware and virtual environments. It is the earliest and most venerable of the "N0-SQL" movement (look that one up as well). Fun reading.