Saturday, October 1, 2011

The Overall task of OntoVistA

I have been thinking about things related to the OntoVistA project, and it is hard to plan the different aspects of it
so that my time is effectively used. My new position allows me to put time into OntoVistA, especially where it impacts configuration and implementation of VistA, and where it supports clinical decision support.


On the one hand, there is a LOT of information in VistA. On the other hand, there is a LOT of information in the various ontologies that are extant, such as SUMO and in Cyc. Unfortunately, VistA and the various public ontologies don't represent the same information in the same way. VistA is organized as a dynamic database system, with object oriented references and a multi-dimensional datastore. Ontologies by their nature, express things in terms of axioms, or always true statements. What might be stored in a procedural way in a Hospital Information System will probably be stored in a declarative fashion in a Knowledgebase. I think I might have a way to mechanically convert some of the information from the database-centric fashion of FileMan or a network database into the predicate logic form used by a KB. But with a mechanical conversion, there is the potential loss of meaning. The large size of VistA (tens of thousands of programs and tens of thousands of rows and columns) almost requires a mechanical process, or the encoder will be spending hundreds of hours making the same decision repeatedly. There is no requirement that a mechanical process must be a simplistic one. It is better to spend the human hours on the task reviewing the mechanical process and making it a more robust one that reflects the decisions made by untold analysts and designers in the past.



Since a lot of the meaning in VistA is established by the programs which use the data,

if a reasoning system is going to be able to use the same data, there is a need to make

some facts and information about those facts (sometimes called metadata) explicit.

Humans have a great ability to extrapolate a lot of information from a few facts.



Beyond that, to truly support decision making, the reasoning processes used by people need to become explicit as well. The way the information is used needs to be captured in addition to the way information is stored. I think the infinite regress potential here is rather daunting. It is easy to describe data, then data about data, then data about the data about the data, endlessly.


The most daunting aspect to this recursive process is the idea that we still are just describing what needs to be done, and haven't actually started doing it yet. I don't like the idea of not being effective.


But poorly planned activities many times yield poor results or even wasted results. So putting time in at the beginning of a process can have a lot of impact on the entire process.


I know some folks might feel this is just reviewing what is already known, but I think it is worthwhile to look over things and understand what general decisions need to be made before you spend your time focusing on specific details.

Tuesday, September 27, 2011

Business Rules in OpenVistA

For those interested, I have created a page on VistApedia with the Business Rules which were in a release of Medsphere's OpenVistA.

http://vistapedia.net/index.php?title=OpenVistA_Business_Rules

I expect these rules were originally released by the VA in the FOIA release that the OpenVistA release was based upon. I will continue to research this.

New Job, New Opportunities

I recently changed jobs to work at the Central Regional Hospital in Butner, North Carolina.

With the responsibilities to provide resources for the State of North Carolina to implement a VistA system include using VistA for Clinical Decision Support.

Clinical Decision Support depends on an explicit ontology to support reasoning, deduction, and expert rules. I intend to use this blog to explore these ideas publically, and provide guidance for those who are interested in this work, especially as it positively affects the practice of medical care.

Wednesday, June 24, 2009

FAQ: Is this just an Intellectual Pursuit?

While there is an intellectual basis for the effort of merging computer ontologies with the electronic health records in VistA, the OntoVistA effort is not about trying to create an ivory tower or free floating "mind" that knows about VistA. There are many tools that have been developed over the years, some before FileMan was created in the 1970s, and others that have only been developed in the past few years.

It is more important to use the tools to create a practical system that can meet the goals of the OntoVistA project than to create an compendium of white papers, documents, and standards. Information in such a compendium is useful and valuable, but the efforts of the OntoVistA project must be focused, so any intellectual pursuits must be harnessed to the greater goals.

The effort to create an explicit ontology for VistA can be seen as an engineering effort more than just an intellectual pursuit. The technologies of the semantic web and inference engines, as well as code and data analysis, can help us in creating partially and fully automated mechanisms to make OntoVistA into a reality. It is important that we have concrete goals to reach rather than vague formulations, as this can drive our work far more than mere speculations.

Saturday, May 30, 2009

WHY: OntoVistA as a Medical Support System

The nature of medicine is that it has a incredibly broad base of information that is relevant to its practice. There are medical conditions which are influenced by almost every aspect of life. Not only does there exist conditions that are caused by the presence of environmental factors, genetic factors, and behavioral factors, there are also conditions that are caused by the ABSENCE of the same kinds of factors.

Generally when one looks for some part of human life to computerize, it is useful to limit the area being covered to the bare minimum in that endeavor so that you can slowly scale up the computer coverage from a small working base to a more capable system that covers the day-to-day aspects. This is difficult when the subject area is medicine, because almost any interesting subset of medicine is as complex as the set of medicine as a whole. So you find that bringing in a computer to help a small area quickly means that you are using the computer to handle a huge area. It is as if the only type of problems are toy problems, and life-critical practical systems. This also means that it is usually easier to teach someone who already knows medicine how to get the computer to work for them, than to take someone who is a computer specialist and try to explain to them all the intricate interactions which come about because of a particular medical specialty. VistA, by the nature of its unique history, did that far more than a lot of other systems of comparable size.

VistA started as an effort within the VA hospitals to bring in computers to enhance the provision of care to a largely stable population. The explosion of new veterans after the Vietnam war meant the methods of healthcare delivery developed after World War II simply could not keep up with the demands.

In non-veteran healthcare systems, a constantly changing patient population only come to the doctors or hospitals when an acute care need arises. The medical situation for the non-veterans are at the end of a disease process, when preventative care is no longer very effective, and some acute distress forces them to seek care. The nature of their visits means that they are more willing to spend money to get "fixed", but it also means that the only time the care system receives money is during the crisis. When one reviews the impact on the computer systems, they primarily track billing expenses, and itemize care given, with an underlying assumption that there is no need to keep long term records because when that person is seen again, their needs will be drastically different than this time, because it will be some other acute distress as this one will go away after they leave the hospital or clinic.

In contrast to this scenario, within the VA, the large number of veterans who are seen are seeking care because of an incident that occured when they were in active military service, and this service-connected problem has a continuing impact on their lives. Also, because the patients have already "invested" in their care by serving in the armed forces, the cost of their care is covered by allocations from the U.S. Congress, which usually come in the form of a fixed amount of money per patient per year. The VA, as stewards of tax money, wisely takes a longer view of healthcare, and deems preventative care as a way of dealing with disease processes before they reach a critical acute incident. Since there is a long term commitment to these particular veteran patients, the computer systems also reflect the chronic nature of this reality. Once a patient record is established, it will be available for years to guide healthcare providers. Long term trends as well as cumulative analysis is possible due to the wealth of data kept about a patient. Security and privacy of records is built into the design of the computer system at a deeper level, because there is more information to safeguard. Since many VA facilities are affiliated with a medical school, computer decision support is part of VistA to remind new practitioners of interactions between the various drugs, tests and pre-existing conditions. Since students and residents by the very nature of their activities are transient, checks and balances are built in to allow the established providers to review their work, and reflect the local standards of practice within the customized behavior of the computer and healthcare system.

Since VistA is tracking both healthy and ill patients, it has to track a wider range of human behaviour. The system has to model why particular activities are in the patient record, rather than just recording what occurred in a limited acute incident. The VA has been at the forefront of standardizing medical vocabularies in numerous areas, such as the National Drug File, LOINC coding for lab tests, the HL7 data transmission protocol, describing diagnoses and procedures with specialized nomenclature and coding systems such as the UMLS, ICD-9, CPT, DSM-IV or the SNOMED CT systems. Each of these systems has a lot in common with modern ontologies used in knowledge engineering and the semantic web. The actual syntax or methodology may take a different form than a typical expert system, but many of the basic operations of classification using generalization and specialization, analysis of processes of data collection and deductive processes are in common. And as has been said before, the subset of the world that has to be considered to be described or axiomatized is very broad. The area of overlap between ontologizing the world at large and ontologizing the medical world is large enough that almost all of the same issues come up in both efforts.

An explicit ontology of the medical aspects of VistA would involve developing methods of exposing a lot of the medical knowledge in the system in a form that external reasoning systems could then be leveraged to enhance the support of medical practice already provided by VistA.

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.

Wednesday, May 20, 2009

FAQ: Why did you choose VistA as the basis for this work?

VistA has several specific advantages:

1) It is easily available, in the public domain, and can run
on common, inexpensive hardware. This means that a personal
instance of VistA can run by participants, if desired.

2) It is extensive. VistA supports the full gamut of healthcare
for adults (veterans) in the United States, using modern and
standardized terminology sets, and covering all aspects of
a hospital. There are a huge number of Fields (over 70K) in a
recent count, with over 20K programs using that data. This
should provide a fertile field to develop knowledge, and recogize
patterns of usage. Since the system is actively in use in over
170 hospitals, there are many documents on the meaning of
the data, and the practice of using it, so less guesswork will
be needed in determining how ambiguities should be interpreted.

3) The resulting artifact/ontology will have value beyond
its use to learn and experiment with ontology modeling.
As there is already a community based around VistA, in both
the private and the public sectors, the artifact, once created, will
be able to be maintained past the modeling phase, and will serve
as a source of information about the usefulness of an ontology
on a long term basis.