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.
- 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!
- 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.
- 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
- 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.
- 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.
- 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.
- 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.
- 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