Server-side. Security-enabled. Symmetric-Read-Write.

The VISTA Data Project is a new data-centric approach to comprehensively exposing, representing, and managing the thirty-five years of patient data and institutional know-how currently in the VA's 131 nationally deployed health information systems (VISTA) using a modern web-standard machine-processable data model; and by enriching and operationalizing this model, make all relevant VISTA data securely accessible and computable in real-time across all VISTA systems as one national, standard Master VISTA system.

The VISTA Data Project is a new data-centric approach to VISTA data access and management. This is in contrast to the current code-centric approach to interfacing with VISTA's data which relies on a byzantine array of thousands hard-coded interfaces that have accumulated over three decades, none of which are vaidated, documented nor maintained. In a data-centric approach one instead comprehensively exposes all the data in the system revealing the native data model, and then manage the data using a model-driven, data-centric approach.

This master data model - the roadmap to all of VA's institutional know-how and data - has evolved organically over the past 35 years, but has not been surfaced or leveraged. Now, for the first time, this data model will be comprehensively exposed and fully taken advantage of.

An operationalized Master VISTA Data Model (MVDM) provides VA with four key transformational capabilities:

VISTA Data	Details
Access	A single, universal, industry-standard mechanism for reading and writing all VISTA data. This mechanism is unified through a read model and write write model that are integrated into one single, symmetric-read-write data model (VDM; See diagram above). This overcomes the well understood shortcoming with VISTA Data Read and Write, which uses completely unique, distinct code, models, and mechanisms for reading data from writing data. The 20+ year old CPRS-specific RPC Broker and the associated 3300+ MUMPS routines which encapsulate all these idiosyncratic approaches - none of which are documented or maintained - simply cannot be relied on going forward, particularly for non-CPRS clients.
Integrity	Comprehensive, automated, standardized, strict data integrity enforcement for all VISTA data. This is a major improvement over the hodgepodge of legacy, ad-hoc methods that have accumulated over the past 35 years (HL7, RPCs, MUMPS, procedural code), none of which are documented, and all of which are inconsistent, unpredictable, and highly permissive. See also: Master Data Management
Security	Comprehensive, industry-standard, fine-grained, data-centric security for all VISTA data. Currently VISTA provides security for only a small fraction of its data, and does this through highly nonstandard, complex, opaque, and unmaintainable methods. Data-centric, attribute-based security is the foundation for all other security levels and technologies, because without knowledge of the data and its attributes, it will not be possible to provide the appropriate security measures on the data. Through metadata enrichment of the VISTA Data Model, VISTA will know what categories of data it is managing and thus allow, for the first time, comprehensive, data-centric, attribute-based security "on-the-data" for all VISTA data, permitting the secure exchange of data. See Data-Centric Security, Logical Security, Semantic Security and Attribute-Based Access Control (ABAC)

Note: As a side-effect of establishing a single comprehensive mechanism for data management for VISTA data, a large portion of VISTA's legacy code (its thousands of data interfacing routines) may be retired.

What?

The VA Information Systems Technology Architecture (VISTA) is VA's an integrated EHR and resource management system which provides all adminstrative, financial, and clinical information management to efficiently run over 1200 hospitals and clinics throughout the U.S., and thus provide veterans the highest quality of care, everywhere.

There are over 131 instances of VISTA deployed nationwide, and each has evolved independently over the past thirty-five years. The result is that each VISTA system has its own distinct database and distinct data model. There is no single "VA system". There are 131. As a result, VA cannot share any computable data across or between any of the other VISTA systems.

Why?

The mission of the Veterans Health Administration (VHA) is to provide comprehensive lifelong healthcare services to veterans everywhere. To support this, VA must have a seamless, comprehensive, nationally integrated healthcare information system to provide all relevant VISTA data in real-time in computable form at the bedside at all 1200 facilities. In addition, in order to support the needs of veterans in today's mobile web-oriented world, VA needs to create new web-based clients and services to VISTA data to provide all necessary information to providers and veterans at the point of care using mobile, tablet, and web browser based interfaces to support truly ubiquitous access to healthcare services.

VA thus needs a single, consistent, web-standard mechanism for real-time read-write transactions to all of the 131 local, unique VISTA systems as one, national master VISTA system. This reduces the complexity of development, deployment, and maintenance for any new nationwide data service from any of the 131 distinct local VISTA systems to that of only one standardized computable Master VISTA system.

How?

All sources of available metadata and models (internal to VISTA as well as external) will be transformed to a single integrated web-standard machine-processable data model which is then annotated, normalized, and enriched. This enhanced model is in turn is embedded back in VISTA as a server-side, security-enabled, symmetric read/write (i.e. transactional) Master Data Model.

Where?

All artifacts and deliverables shall be developed, version-controlled, stored, and delivered on an industry-standard public Github repository (“Project Repository”). ... The Project Repository shall contain the one and only authoritative version of all artifacts produced ... The government, all necessary stakeholders, and the public shall have full read and download access of all artifacts on the Project Repository at all times --- See PWS Section 1.6.15.1

The VISTA Data Project is based on the following Web Technologies and Web Standards:

• Detailed review of these and other foundation technologies is contained in the Background section.
• The current baseline VISTA and Client functionality and capability is described here.

Technical decisions by the VA and in mainstream software industry that framed the approach taken here

1. By virtue of VA's technical review and approval of Node.js in the VA Technical Reference Model (TRM), VA endorses the use of server-side Javascript/Node in the VA enterprise architecture. See TRM-Node.
2. By virtue of VA's Enterprise Health Management Platform being rewritten almost entirely in Javascript and Node.js, the VA has decided that Node.js is essential for the success of enterprise projects. The backdrop to this decision was the conspicuous failure of numerous mid-tier Java wrappers for VISTA, starting with MyHealtheVet and the others since then. See reference.
3. By virtue of VA's large, multi-year contract (and see) for Node.js, the VA has decided that Node-enabled Javascript on MUMPs is productive and practical.
4. By virtue of inclusion of the Node in all official releases of Cache, Intersystems views in-process Javascript coding on Cache as practical, maintainable, and essential for their commercial customers, particularly VA. See Intersystems documentation on Cache/Node and PDF.
5. Node.js adoption continues to grow for mainstream production projects, including Netflix, New York Times, PayPal, LinkedIn, Walmart, Yahoo, and Uber.
6. Javascript is the most popular coding language in the world, as measured by number of projects, coders, and new code on Github, and by the number of companies developing and deploying enterprise software for consumption on the web.
7. By virtue of VA's technical review and approval in the VA Technical Reference Model of the Resource Description Framework (RDF), VA endorses the RDF data model for use in the VA enterprise architecture. See TRM-RDF.
8. JSON-LD is the most commonly used form of RDF deployed in production settings. It is used by Google, Yahoo, and Microsoft as a common mechanism to structure and index all the data on the web by their search engines, and by the U.S. National Library of Congress and U.S. National Library of Medicine to structure and search all published books and medical journals, respectively. See JSON-LD.

The Project organizes deliverables in five “tracks” each backed by one or more Gits in the Project Repository.

From PWS 8.2 ...

The forms and licenses are in keeping with the requirement that All artifacts and deliverables shall be developed, version-controlled, stored, and delivered on an industry-standard public Github repository (“Project Repository”).

27 Technical Deliverables involve:

• 8 MetaData Definitions/System Configurations
• 18 Software
• 6 Documents

More artifacts may be identified as work proceeds.

1. | dd.jsonld | JSON-LD | Formal, portable definition of the contents of a VISTA data dictionary | 8
2. | rpc.jsonld | JSON-LD | Formal definition of the model implicit in RPCs, captured in JSON-LD | E1
3. | vpr.jsonld | JSON-LD | Formal definition of the VPR RPC's patient data model in JSON-LD | Part of 10.1
4. | vdm.jsonld | JSON-LD | Formal definition of Native VISTA data model based on one or more dd.jsonld's and rpc.jsonld | 7.1, 7.2
5. | mvdm.jsonld | JSON-LD | Formal definition of the MVDM subset of VDM that supports full CRUD | 10.1, 10.2
6. | piks.jsonld | JSON-LD | Formal annotation of vdm.jsonld that distinguishes Patient, Institution, Knowledge and System (PIKS) classes and properties | 18
7. | nodeVISTA Scenarios | GT.M and Cache Databases | VISTA databases for testing and demonstrations | Part of E2.2 Development
8. | MVDM Linkage Rules | Rules Format | Linkage rules (MVDM out) | Part of 39

1. | DDJLD Maker | Python/ Javascript | Caches FileMan Data Dictionary (dd) from a VISTA and creates a dd.jsonld | 8
2. | RPCJLD Maker | Python/ Javascript | Caches RPC definitions from a VISTA and creates an rpc.jsonld | E1
3. | nodeVISTA | VISTA, node.js | A test VISTA based on OSEHRA's VISTA and a simple node.js front end | E3
4. | nodeVISTA Commands | Javascript (node.js) | invocations of mainly write-back functions in VISTA to prepare for the write-back support of VDM Package | Part 7.2, E2.2
5. | VDM Maker | Python/ Javascript | Creates a VISTA Data Model (VDM), vdm.jsonld, from a VISTA's dd.jsonld and rpc.jsonld | 7.1, 7.2
6. | VDM Package | Javascript (node.js module), MUMPS | Implements VDM inside Fileman. The first version will support querying ("Read-only"). The full version will support Create-Read-Update-Delete and transactions. | E2.1, E2.2
7. | MVDM Maker | Python/ Javascript | Creates a Master VISTA Data Model (MVDM), mvdm.jsonld, from one or more vdm.jsonld's and vpr.jsonld | 10.1, 10.2
8. | MVDM Module | Javascript (node.js module) | Implements MVDM inside Fileman over the VDM Package. The first version will support querying ("Read-only"). The full version will support Create-Read-Update-Delete and transactions. | 11.1, 11.2
9. | MVDM Test Suite | Javascript | A series of tests focused on write-back support of the MVDM Module. Tests VDM write-back as MVDM relies on VDM. | 35
10. | PIKS Generator | Python | Generates Patient, Institution, Knowledge and System (PIKS) annotations in piks.jsonld for a vdm.jsonld | 19
11. | Patient Security Prototype | Javascript (node.js) | An illustration of PIKS-enabled Patient level security. This involves an example client and an addition to FQS | 28
12. | FQS | Javascript (node.js) | Fileman Query Service (FQS) based on embedded VDM model (REST service; read only) | 25
13. | Example Query Clients | Python, Javascript | Example command line clients that show how to use the FQS | 25
14. | FQS Web Client | Javascript, HTML | Browser based client for using the FQS | 33
15. | Metadata Cacher | Javascript | queries (VISTA Application) metadata using VDM Package | 15
16. | MVDM Linker | Javascript, Linking rules | prototypes showing linking of VISTA through MVDM | 39
17. | Web-based Rules Hub | Javascript, HTML | host for Translation rules | 32
18. | Document Generators | Various | Generators of documentation leveraging common packages such as Sphinx and JSDoc and translators from Markdown to PDF and HTML | E4

Note that VDM Package and MVDM Module are the key software artifacts of the Project. Other software either helps in their development or configuration or illustrates their use.

Per the PWS, all non PM documentation will be delivered on the Project Gits in the Markdown format.

# | Name | Deliverable :---: | :--- | --- | :---:

1. | Website | 13
2. | (Document) Approach to “Live VDM” Maintenance of Current State | 9
3. | [MVDM] Normalization Reports | 12
4. | Report on [MVDM] Exposure of older models | 14
5. | Prototype Patient-centric Data Security [Document] | 28 (Document)
6. | Document VISTA-ese linkability | 40

In addition, programmer documentation will be generated for VDM Package, MVDM Module and FQS.

In addition to the deliverables listed in the Program Management Plan submitted to the government (Section 8.2), additional deliverables were identified for planning purposes. Such deliverables have been identified with a prefix of “E”. Deliverables 7, 10, and 11 were divided and designated .1 and .2 for VDM and MVDM, respectively.

• Enumerated above are 27 technical deliverables within four tracks ( VDM, MVDM, MVDMlink, and Infrastructure).
• Deliverables E1-4 are required but not explicitly enumerated in the PWS.
• Deliverable #’s have gaps. The following PWS deliverables were retired as redundant or out of scope per government determination: 6, 16, 17, 20-24, 26, 27, 29-31, 34, 37, 38
• There is a substantial difference in complexity between read-only and read-write models and implementations. To write anything demands knowledge of rules that go beyond the demands of reading. As a result, both VDM and MVDM models and packages will be delivered in two phases, with read coming first.
  • VDM "Read" and its package (#7.1 and #E1.1) are due in Q1; Deliverables #8, #15, #18, #19, #25, #33 only require such read-only functionality and are due in Q2
  • MVDM "Read" and its module (#10.1 and #11.1) are due in Q2: Deliverables #28, #36 and all of track D rely only on MVDM ("Read").
  • Read-only VDM and by extension MVDM will expand on open source FMQL