Drat... that pesky feature in Netscape that sends mail when I do something wrong
while trying to cut and paste a chunk of text sent this prematurely. (I KNOW I
don't accidentally type Ctrl-Enter, so I can't figure out what I am doing...).
We leave number six to permit others to contribute the features I left out...
;-)
Greg Kreis wrote:
>
> 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.
--
--------------------------------------------------------------
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.
