VistA, AHLTA, CHCS: An Evolving Alternative Roadmap to the Future

This article was authored by Uri Schor, CTO, CAV Systems Ltd, and Alex Hill, VP of Corporate Development.

The obstacles to continue moving U.S. Department of Defense (DoD) and Department of Veterans Affairs (VA) in a common direction with regard to their clinical IT systems are fairly well-known. Having made that statement, it may therefore seem strange that this blog suggests that a conceptually simple technical approach may have the potential to untie the Gordian knot that has defeated many previous efforts.

The proposed approach is not some yet-to-be-developed technology that exists only on Powerpoint slides. In fact, the proposed approach is based on technology that has already been validated by the-powers-that-be – at taxpayer expense – and the official conclusion in the official report on file at the DoD(1) states unambiguously and explicitly that the technology works as claimed is scalable, and can handle very large M/Caché systems.

In fact, MD Anderson Cancer Center, a world-renowned healthcare research organization(2) right here in the U.S. performed its own independent validation of the same technology and, based on the results of that validation, selected the technology as part of its own “roadmap to the future”.

The answer is truly simple: 

Replace the M/Caché database with a brand name relational database – Oracle, SQL Server, MySQL, DB2, PostgreSQL – while still retaining the ability to maintain and enhance all existing application software written in the MUMPS computer programming language, also known as 'M'.

The proposed solution is relatively simple and easy-to-comprehend. It consists of the following key steps:

  • Existing 'M' and/or Caché development teams remain intact.  All existing programs can still be maintained and enhanced as if they are still 'M' and/orCaché programs. Indeed, even the debugging of the programs proceeds “as if” the debugging process is occurring in a MUMPS environment.
  • User Experience remains “as is” for as long as the powers-that-be decide.  All source code is retained in the original 'M' computer language, thus ensuring that it functions identically to the way it functions with the M/Caché database.
  • Data is accessible directly as relational data – in realtime. The database that contains the production data for the clinical systems will be a brand name relational database, e.g. Oracle, MySQL, PostgreSQL.
  • Enhancements to M/Caché core applications are programmed using M/Caché – and ….  Enhancements to core applications can still be made using the 'M' programming language; other selected software modules can be programmed in any of the other prevailing programming languages, e.g. Java, C++, Ruby on Rails.
  • Future programs can be designed and developed using a variety of more modern languages and Integrated Development Environments (IDE). Bottom line - All programs, old and new, will be able to access the same database.

If you accept this explanation, the obvious next question is “How can entire MUMPS systems – programs and data – be transformed in such a way that the MUMPS database is replaced by a relational database while the programs still appear to be in the MUMPS programming languages and continue to function identically so that the User Experience is the same?”.

The concept is simple. Implementing it, however, requires some “out-of-the-box” thinking but once you “get it” and the light bulbs switch on, even this is simple to understand. When we bring together 3 ideas that are inter-related, the pieces of the puzzle all start to fall into place:

  • Design and build a runtime engine written in Java code that emulates the functioning of all MUMPS statements with one exception: leave the M/Caché data access statements alone and let them be handled by a “smart” database module that accesses relational databases via SQL instead of accessing M/Caché data structures.
  • Build a compiler, Integrated Development Environment (IDE) and debugger that takes MUMPS statements and generates Java code that performs the exact same functions as the MUMPS statements via the runtime engine.
  • Build software tools that facilitate the generation of a mapping from M/Caché data structures to relational database structures for every data element in the M/Caché system.

These are the 3 inter-related pieces that are both necessary and sufficient to deliver all the capabilities – and related benefits – itemized above.

  • The compiler/IDE/debugger ensures that the source code remains as MUMPS code so that the existing teams of developers remain on board and continue to support the system.
  • The runtime engine, combined with the “smart” database module, ensures that the compiled code functions identically when using the relational database instead of the M/Caché database.
  • The mapping tools are the critical piece of the puzzle without which the entire approach collapses. It is the mapping that enables the runtime engine, together with the “smart” database module, to generate optimized SQL statements dynamically during execution that can deliver the correct functionality and adequate performance.

Fortunately in the case of the VA VistA and DoD CHCS systems, the generation of the mapping is simplified enormously by the fact that both of these systems use the FileMan subsystem to define and manage all the data elements used by these systems – and, since FileMan is itself written in MUMPS, the mapping can be generated automatically simply by passing it through the compiler.

What we have here may be a potential ‘Win-Win-Win-Win’ situation for the VA and DoD.

  • Win #1: the in-house teams of MUMPS developers remain as the primary source of ongoing maintenance and enhancement of the production systems during the various phases of “roadmap to the future”;
  • Win #2: the same holds true for contractors, both individual and corporate, working on the existing systems at the VA and DoD;
  • Win #3: the fact that the database can now be moved from MUMPS into a brand name relational database opens these clinical systems to the larger IT community thereby encouraging entrepreneurial activity from the health IT community at large;
  • Win #4: the U.S. taxpayer ultimately benefits as these taxpayer-funded systems are transformed from legacy technologies that today are proprietary and require hard-to-find manpower into mainstream technologies supported by a vast pool of IT professionals thereby creating a much more competitive business environment.

Why is this approach a “roadmap to the future”? All past attempts to address the ongoing problems that have plagued efforts to merge the clinical IT systems at DoD and VA – AHLTA, CHCS, and VistA – have not been successful. In addition, all attempts to gain much wider acceptance of VistA-based systems outside of the VA – have also faced major challenges.  All past approaches were either based on a total re-engineering of the system from the ground up (i.e. AHLTA) or retained the database as a MUMPS/Caché database.

Every IT professional knows that the key factor in the success or failure of large complex IT systems is the design and choice of database. If you get that right, the subsequent choice of programming language – while important – is not critical and can be changed without the type of disruption that occurs if the database is changed.

The proposed approach laid out in this blog enables a gradual transition into the future with very low risk to either the VA or DoD. The solution exists today. It simply requires innovation and  leadership to move forward with this approach.

Footnotes

(1) CAV (Jumps) conversion of CHCS to Java/Oracle, Final Report By SAIC and CAV Systems For TATRC Ltc. Hon Pak, Chief TATRC AITG And Mr. Marc Wine, TATRC AITG, April 2008

(2) MD Anderson Cancer Clinic Selects Israeli Software for Data Migration Phase of Clinical Trials Project. See Press Release May 22, 2012 and Case Study.


CAV Systems is an international software company engaged in development and deployment of enterprise applications. Throughout the years, their 'core' data processing applications were developed using MUMPS, and deployed on all major MUMPS implementations, e.g. Caché, GT.M.  Learn more about their Evolve suite of mapping and data migration tools.