VistA Analytics

VistA Analytics is the process of analyzing VistA with data taken from live VistAs using FMQL. Where VistA lacks information, we fall back on offline VA Artifacts - release notes and specifications.

Extended Schema

VistA's schema grew organically over decades. FMQL exposes this schema as VistA sees it (FileMan Schema) but more definition is needed for comprehensive VistA data-management. The following reports analyze the FileMan schema and how it is used in real systems to identify a fuller Extended VistA Schema.

File importance and subschemas:

  1. All files - page ranked - file importance based on linkage
  2. Concept Subscheme
  3. New Person Subscheme
  4. Patient Subscheme

The following reports break down data queried from "Lulu", a fully patched VA test system with data of 1600 de-identified and training patients. Such usage-analysis is key to defining a fuller schema. These reports do not expose any patient particulars - they only report on the shape of patient data and the configuration of the system itself. Note that Lulu is not ideal as a source of schema-use. De-identification garbled dates and some relationships. A fuller, ungarbled system would give more representative results.

  1. VS Basics: patient schema filled in
  2. Concepts: medical concepts used including 1362 enumerations
  3. Patient Resource Types: file types used in patient records and their counts

There is no one FileMan schema. Different VistA versions enhance. The following highlight a common core and the files and fields particular to one or other VistA release ...

  1. FOIA vs OpenVistA
  2. FOIA vs WorldVistA
  3. FOIA vs Lulu

Cross References add schema logic and isolate key field combinations ...

  1. FOIA vs OpenVistA
  2. FOIA vs WorldVistA
  3. FOIA vs Lulu

VistA HL7 exports and changes FileMan data. Isolating what is exposed and changed and in what groupings further defines VistA's schema ...

  1. OpenVistA HL7 by Package - older analysis.

Know-how

The following reports expose different aspects of VistA's know-how to help in repurposing it ...

Different concept schemes in VistA ...

  1. VA Drug Schemes: VANDF vs NDFRT [K3]
  2. VA Lexicon
  3. VistA Lab Concepts
  4. Cataracts: Lexicon, ICD9, SNOMED [K3]

Concepts used in Lulu patient data:

  1. Lulu Disorders: specific class of concept
  2. Lulu Drugs: specific class of concept (mapping drug schemes)

Note: [K3] means a report was generated from VistA-concept data hosted in K3.

FOIA - the discrepancies

FOIA VistA, the publicly available version of the VA's internal master, is the nearest thing to an official VistA but it has discrepancies. Many are due to the way the VA removes proprietary function before releasing it to the world. Others reflect how VistA built up over decades.

  1. FOIA VA Lexicon
  2. FOIA Routine Discrepancies

One VistA

OSEHRA, the VA's official open-source VistA custodian, has a Code Convergence effort to establish one "best of breed" VistA code base. The following reports help identify such a One VistA, a baseline version of VistA, which fixes FOIA's problems and contains the best of other VistA variations including RPMS.

Every VistA instance documents much of its own configuration and FMQL exposes this self-knowledge, its Packages (9.4), Builds (9.6), Installs (9.7). This information is the foundation for the following One VistA reports.

Fork'n'Age reports:

  1. FOIA vs WorldVistA
  2. FOIA vs OpenVistA
  3. FOIA vs RPMS
  4. FOIA vs Lulu

Basic reports (packages, builds ...):

  1. FOIA vs OpenVistA: packages, build details, builds w/o packages
  2. FOIA vs WorldVistA: packages, build details, builds w/o packages
  3. FOIA vs Lulu: packages, build details, builds w/o packages

Manual analysis based on the Fork'n'Age reports ...

  1. WorldVistA Registration Forks
  2. WorldVistA Kernel Forks
  3. WorkVistA MPI Forks
  4. WorldVistA Forks (Various)

VistA Timeline

How VistA has evolved over time ...

  1. VistA Evolution (cross package)