Fileman 22.2 Deployment by VA Achieves a Major Open Source Goal

Mike Henderson's picture

For the past several months we have been sharing the news of VA's integration of the OSEHRA-certified MSC Fileman 22.2 into their enterprise version of VistA. This integration has been a milestone in the agency's adoption of community-based open source enhancements, the development of which involved many dedicated community members over more than a decade.

Back in the Saddle

After a year of working to provide market research for VA's emerging Fileman Evolution projects - especially after OSEHRA's December sprint to upgrade MSC Fileman 22.2 in support of VA's test-plan contract with Leidos, and the January VISTA Community Meeting in Sacramento - my health finally collapsed for six weeks of February and March. I returned to the office just in time to watch VA's next Fileman 22.2E testing contract sail over the plate before I could respond to it, much to my dismay and disappointment.

MSC Fileman 22.2 Patches

One of the characteristics of the final stage of packaging a new version for a VISTA application is that we must paradoxically freeze development without freezing development.

We must freeze development because the distribution sent to the world has to be a specific, tested version of the software. Getting to that point requires constraining development toward satisfying the results of testing, not introducing new disruption late in the packaging process, when there won't be sufficient time to test it. In this pro-testing era, most people get this issue pretty well.

FLAP and Fileman's Architectural Role

To say that File Manager is VISTA's database management system is a gross understatement, so gross that it is more misleading than helpful.

Traditional database systems run side by side with the applications, offering data-related services (like creating, reading, updating, and deleting records - the services with the unattractive acronym CRUD - along with many, many other such services). In other words, most DBMSes have a peer-to-peer relationship with the applications that use them to manage their data.

FLAP and Fileman Code Convergence

One of the two top strategic goals for FLAP Phase One (which ran from October 2012 through March 2013) was code convergence, to create a shared, common Fileman codebase that all VISTA dialects could run, to maximize our ability to exchange data and software with one another, to ensure that innovations anywhere became innovations everywhere as quickly as possible, and to reduce the amount of reinventing the wheel we had to do.

The main VISTA dialects we aimed at converging for Phase One were:



3) WorldVistA EHR

4) vxVistA, and

Database Elements Problem 1: Standard or Local Data

So then which aspects of what VISTA is made of make this more complex than it seems?
Many things. Let's start with the data.
In some files, such as the State file (#5), the contents are shared. It's not like the number of U.S. states changes depending on whether your VISTA system is running at a VA hospital in Tampa, Florida or Cheyenne, Wyoming. This file is not yet optimized for use by other nations, so at present it's pretty much just a description of U.S. states, which means its contents should be the same for all VISTA systems.

Non-routine Software Elements Part 1: Data and Definitions

Yes, but what is VISTA made of?
So at the MUMPS level, VISTA is made of two kinds of software elements, routines and globals. Routines are readily version-controlled and managed (in theory) using industry-standard tools, but globals are not. Globals need to be flattened and exported in some way that focuses on the database files we are storing in those globals.
As we're going to see, this second "half" of the problem (globals, as opposed to routines) is really a lot more than half the problem.


Subscribe to RSS - Fileman