Applications

Infrastructure Features

A giant VistA Overview provides a 50,000 ft view of the breadth of the VistA clinical apps. It quickly reveals the depth and coverage of the VistA clinical system.

For those with an eye for data details, Entity Relationship (ER) diagrams of the application databases are in PDF files at the VA's Internet site. The diagrams are grouped by application, so you need to know the namespace of an application to find the right PDF file. Use the listing of namespaces and applications to map to the appropriate folder.

Here is a summarize of the technical foundation of VistA, so all can learn some of the neat and not-so-neat things about its infrastructure.  Keep in mind much of this infrastructure was laid in the late 70s and early 80s. There is much to learn and appreciate.

1. VistA provides a common services framework, like background tasking of jobs, device selection, menus, Hl7 interfacing, database, etc. are defined in a library called the Kernel. It is very well documented and all apps are required to use them and not invent their own. So if you know how to select a device, pick a menu option or queue a task in one app, you know how to do it in any app. User training is greatly simplified and dependencies on underlying platforms is eliminated. The motto is to keep the user from seeing ANYTHING system specific in the underlying implementation. This makes migration issues invisible to them - they don't need to be trained. All they know is that on Monday, after the weekend conversion, it is suddenly a lot faster!
   
   
2. Any non-standard MUMPS code that must be performed (such as not echoing characters to avoid seeing a password) is done by calling an API in the Kernel that has been adapted to the current platform. A part of the Kernel therefore serves as an adapter to encapsulate the non-standard extensions that would corrupt portability if permitted to leak into the application code. This has been essential to permit VistA to migrate to several different platforms painlessly, typically over a weekend.
   
   
3. The File Manager (database manager) uses an active Data Dictionary to define files. It contains the validation code, cross-reference logic, etc. Most unfortunately, MUMPS programmers have bypassed this part of VistA all too often in the past and so it is not as tightly sealed at the database manager, as someone in charge of maintenance would like.
   
   
4. The Kernel contains an integrated SMTP-based Email module (Mailman) that can be used for human or computer-to-computer communication. Some apps use this to communicate information to a designated server that gathers information into a database. One use could be to automatically track rates of disk usage at all sites so that accurate budget projects can be made for equipment expenditures.
   
   
5. A powerful distribution mechanism (KIDS) permits picking up parts of an application, or all of it, and releasing it as an Email attachment or a file. A KIDS distribution can use Mailman to automatically report to a central server when an application or patch (see below) is installed at a site. This permits the VA to quickly see the version and patch level of applications at any facility across the country.
   
   
6. VistA has an effective system of patching, based on KIDS, that permits simple releases to fix problems or elaborate releases of new functionality. These patches can be distributed as Email messages or files.  Unfortunately, there is no 'undo' for patches, so backups are essential and patches should be thoroughly tested.
   
   
7. MUMPS code is not 'compiled and linked', so any code is open to anyone to call. The same is true for the data. This permits an incredible level of integration between applications, but it is 'too open' for some software architects' liking.  The VA has instituted Database Integration Agreements (DBIA) to enforce external policies and procedures to avoid unwanted dependencies. MUMPS should have a way to declare code and data public, private, protected, etc.
   
   
8. VistA applications provide tons of source code (15,000+ routines) and thousands of files to illustrate just about anything you might want to do. The hard part is separating good techniques from dangerous ones.