Gunther Schadow wrote:
>
> Question: Is there any comprehensive library of documents describing
> the design of the VistA system. I'd like to know what it is that makes
> is such a superior system as I have heard so often on this list. I
> would guess there is a lot of writing about VistA to explain these
> great ideas, concepts, and designs?
The Monograph I mentioned in an earlier message gives a brief overview of the
breadth of the VistA clinical apps.
http://www.va.gov/vista/98mono.htm
I just remembered there are ER diagrams of the VistA database in PDF files at
the following location. The diagrams are by app. [You can use this page -
http://www.va.gov/vista/Software/Formal%20Packages%20%26%20parents.txt - to
associate a namespace/prefix with the app's name.]
http://www.va.gov/vista/Software/ERdiagrams/
As far as the design of the system goes, I'll attempt to summarize so all can
learn some of the neat and not-so-neat things about VistA's infrastructure.
Keep in mind much of this infrastructure was laid in the late 70s and early
80s. There is much to learn...
1. VistA provides a common services framework, like background tasking of
jobs, device selection, menus, Hl7 interfacing, datbase, 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. Try to keep the user from seeing ANYTHING system
specific in the underlieing implementation. This makes migration issues
invisible to them - they don't need to be trained. All they know is that on
Monday 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 apps. This has been essential
to permit the code to migrate to several different platforms painlessly 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 as one would like. This
must be avoided in a future system.
4. The Kernel contains an integrated SMTP 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 it 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 you pick up parts of an
application or all of it and release it as an Email attachment or a file. A
KIDS distribution can use Mailman to 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 apps at any facility across the
country.
6.
7. An effective system of patching, based on KIDS, 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
them. This should be addressed in a new system.
8. MUMPS code is not 'compiled and linked', so any code is open to anyone to
call. The same is true for the data. This is 'too open', so you have to
enforce external policies and procedures to avoid unwanted dependencies. There
should be a way to declare code and data public, private, protected, etc.
9. There is TONS of source code (15,000+ routines) and thousands of files in
the apps to illustrate just about anything you might want to do. The hard part
is separating good techniques from dangerous ones.
--
--------------------------------------------------------------
Greg Kreis Pioneer Data Systems, Inc.
[EMAIL PROTECTED] http://www.PioneerDataSys.com
http://www.Hardhats.org/ <-- worldwide VISTA/DHCP users
If Bill Gates had a nickel for every time Windows crashed...
..oh wait, he does.
