In the last few years, the VistA version control topic came out regularly on top of my daily thoughts. It started with reading the Source KIDS white paper published by OSEHRA. I have been checking on the project progress regularly. Unfortunately, the project had very little or no progress. At the same time, a VistA version control solution already existed. It is an integral part of VA VistA Imaging (VI). VI is an FDA regulated medical device and so, the software development has to follow strict regulatory guidelines. One of the guidelines is a software version control.
The Solution
The solution is to have all VistA components (data dictionary, remote procedure call, security key, routines, etc.) that are part of the KIDS distribution exported individually, each in a KIDS distribution. KIDS distribution is a text file in a specific format. In this way, all VistA components can be stored and maintained in a modern version control system. Once we have the VistA source code outside the MUMPS environment, we need a “compiler” to create the KIDS distribution applicable to a patch. The same way you need a Delphi, C#, or Java compiler to create an executable file – exe, jar, etc.
The Implementation
The original KIDS “compiler”, which is a C++ application, was named MakeKID. It takes KIDS files, parses them and creates a single KIDS file. It was used for many years in all VI patches. Developers have to submit all their modifications and new components in the version control system, MS Visual Source Safe. Then the MakeKID is executed as a part of an automated build process. After serving well for many years, MakeKID was rewritten from the ground up as a Java console application renamed KIDSAssembler. A build manifest and runtime options were added making the tool flexible enough to accommodate not only VI needs, but other VistA projects too. Along with the KIDSAssembler, the KIDSBundler was created. The KIDSBundler is a Java console application that takes multiple KIDS distributions and creates one combined KIDS distribution. It is driven by a build manifest and command line parameters in the same way as the KIDSAssembler.
The Splitter
The solution described works perfectly using only the standard VistA Kernel KIDS build options – create a build, edit a build, transport a distribution. However, if you have to develop a patch with a few hundred VistA components, it will take too much time to maintain all of the individual KIDS builds. To streamline the process, an M utility was created. Its role is to take a “major” KIDS build and split each VistA component in a build (“mini” KIDS build) and export it as a KIDS file. Using the splitter provides a standard file naming convention for all different types of the exported VistA components. In its core, the splitter leveraged the existing Kernel code to export and create builds. Where it was possible, the Kernel APIs were used.
The Next Step
The solution and implementation were presented during the weekly call of OSEHRA’s Code Convergence group. The feedback was encouraging. The KIDSAssembler code can be found on OSEHRA Github. The splitter and the bundler are expected to be released soon. The splitter functionality is seen as part of Kernel build options along with create, edit, and transport a distribution.
IT TAKES ONLY 