Thursday, May 28, 2009

WHY: OntoVistA as a Software Engineering artifact

Solely as a software artifact, VistA is a monumental work. The software necessary to provide support for an entire hospital, yet capable of being configured to handle rather small organizations of only a few hundred employees up to several thousand employees, must have a high degree of configurability and flexibility. Couple that flexibility with the limited hardware resources typically available in tax-funded enterprises, as well as the life-saving nature of the work that VistA supports, and you can see that the traditional values of small size and quick response time are still valued in the codebase and database.

The dynamic, sparse persistent data of a MUMPS-based system in VistA supports a table-driven approach with multiple parameters in the database used for configuration. Storage of program code fragments in the database also leverages the late-binding execution ability of MUMPS to keep a lot of the design uniform, yet able to handle the complexities of a modern healthcare system.

To give an idea of the scope of VistA, there are about 2500 Files (similar to SQL Tables) in a standard installation, each of which may have entries and fields, as well as sub-files with their corresponding sub-entries and sub-fields. Across all the Files, there are over 50,000 fields and subfields (database columns). There are more than 25,000 individual programs, each of them providing some capability related to supporting patient care.

As an artifact, VistA is simply too large for any one person to understand fully. Within the Department of Veterans Affairs, there are multiple people who specialize in developing new code, maintaining existing code, configuring existing and new functionality, supporting quality assessment, testing capabilities, as well as the myriad people who can customize the system to their particular way of practicing medicine.

An explicit ontology of the software and computational aspects of VistA would involve developing methods of describing a lot of the procedural and declarative knowledge in the system in a form that external reasoning systems could then be leveraged to enhance the support of the software artifact that is VistA.

No comments:

Post a Comment