VistA as an EHR System Core for DoD

Roger A. MaduroHere is a copy of the full text of the proposal submitted by the US Department of Veterans Affairs (VA) to the Department of Defense in response to the Request for Information for an electronic health record (EHR) solution that can replace the existing DoD EHR system. This is the approach that makes the most sense as the current core EHR that the Department of Defense (DoD) uses is based on a 30-year-old version of VistA. The current EHR crisis facing DoD stems from the inability to upgrade this older version of VistA. What the VA is proposing is basically an upgrade to DoD's existing core EHR. Roger A. Maduro, Publisher and Editor-in-Chief, Open Health News.

 

 

--------------------------------------------------------------------------------------------------

VistA as an EHR System Core
A White Paper
Prepared in Response
to the
Department of Defense
Medical Electronic DoD Integrated Core System (MEDICS)
Request for Information (HT0012-RFI-0008)
February 27, 2013VA

 

Introduction

The Department of Veterans Affairs (VA) is responsible for the development and maintenance of the Veterans Health Information Systems and Technology Architecture (VistA), VA’s Electronic Health Record (EHR).

Designed by clinicians for clinicians, VistA is patient-centric and embodies the clinical workflow processes that support VA’s models of care. It has enabled measurable improvements in health outcomes and is central to our ability to deliver high quality lifetime care to a large and varied Veteran population.

As the foundation of our collaboration with the Department of Defense (DoD) to build a seamless system for health records for service members and Veterans, VA selected VistA, providing a core EHR System (EHR) and an open, modular architecture supporting integration of best-of-breed applications.

VistA’s capabilities evolved over the many years that it has been in successful production, beginning with a central set of functions defined by its user base and extended along a customer-driven roadmap. Its roots are in the 1980s, when a first wave of twenty-five sites deployed eleven applications that addressed Admissions, Discharge, and Transfer (ADT), scheduling, and outpatient pharmacy. By 1985, the full DHCP (Decentralized Hospital Computer Program, as the system was referred to at the time) ‘core’ of applications (including clinical lab, inpatient pharmacy, and base radiology functions) was installed at all one hundred sixty-nine VA Medical Centers nationwide.  And in 1989 eight additional applications (dietetics, fiscal/supply, medical center management, medical records tracking, mental health, nursing, radiology, and surgery) were nationally deployed.

In 1996, VistA was significantly enhanced with a new graphical user interface (GUI) called CPRS (Computerized Patient Record System). Foreshadowing an approach that VA employs today, CPRS did not replace VistA but interacted with the VistA kernel via reusable interfaces and extended its capabilities. In addition to providing a presentation layer in step with the needs of its users, CPRS served as an umbrella program that integrates numerous existing programs for the clinical user. Its tabbed chart metaphor organizes notes, order entry, problem lists, pharmacy data, lab results, progress notes, vital signs, radiology results, transcribed documents, and reports from various studies such as echocardiograms in a clinically relevant manner. Its installation was mandated nationally in 1999 and virtually all clinicians in VA now use it for all review, documentation and ordering functions nationwide.

VistA CPRS is internationally recognized as one of the leading electronic health record systems in the world.  It supports over 80,000 users, is widely acclaimed for its use and utility, is three-nines reliable, and is on a sustainable modernization path to continuous improvement and scalability at all levels of its open architecture.

VA’s Enterprise VistA Deployment

VistA supports the daily operations of one of the world’s largest health care enterprises, encompassing:

  • Over 6 million patients, with 75 million outpatient visits and 680,000 inpatient admissions
  • More than 1,500 sites of care, including 152 hospitals, 965 outpatient clinics, 133 community living centers, and 293 Vet Centers
  • 244,000 employees including more than 20,000 physicians and 53,000 nurses
  • Affiliations with more than 1,200 educational institutions with more than 100,000 health care students receiving clinical training from VA each year

Every clinical encounter is tracked and supported by the VistA EHR. Large VA Medical Centers (such as those in Buffalo, Kansas City, Gainesville, etc.) each maintain databases of more than 80 million orders and handle approximately 25,000 new orders each weekday. VA facilities across the U.S. and in the Phillipines, Guam, and Puerto Rico implement VistA; for Veterans who receive care at multiple VA facilities, medical data can be aggregated and reviewed. VistA supports this scalability without modifications to its code base.

VA is the nation’s largest provider of graduate medical education and a major contributor to medical and scientific research. VA medical centers are affiliated with more than 152 medical and dental schools, training more than 80,000 health-related students and residents each year. More than half of the U.S. practicing physicians received training in VA hospitals and know VistA. Through its internal research and its academic affiliations, VA supports significant clinical and scientific research. And VA provides more public data about quality and safety than any other health care system (see, for example, www.hospitalcompare.va.gov). The data that VistA captures and organizes is the platform that supports this broad spectrum of work.

The IT infrastructure upon which VA deploys the VistA EHR supports scalability from a single-user laptop VistA “instance” to large medical centers with thousands of users. VA’s high availability platform achieves 99.95% availability using commodity hardware and industry standard enterprise software for system monitoring, backups, load balancing, and failover; this technology stack also delivers fast response time as evidenced by a “cover sheet” response time under 0.5 seconds. High speed, highly reliable networks support connectivity for data sharing and disconnected operations. Both the scaling up of individual VistA instances and the addition to the network of a new VistA installation are accomplished without modification of the VistA software itself.

VistA Beyond VA

Outside of VA, VistA has been implemented by dozens of health care providers (see http://www.hardhats.org/adopters/vista_adopters.html) and is supported by multiple companies and organizations.

Within government, the Indian Health Service supports a version of VistA (RPMS, or Resource and Patient Management System) throughout its entire Indian Health system. DoD’s current EHR is built on a VistA-based platform (CHCS, or Composite Health Care System) that provides a scalable distributed system without the performance constraints sometimes associated with a central transaction database.

Commercial companies such as Medsphere and DSS, Inc. support open source versions of VistA for their customers. Non-profit organizations such as WorldVistA and the VistA Expertise Network provide VistA expertise to new adopters. And new companies, such as iCare and its cloud-based VistA, continue to emerge.

OSEHRA serves as an open source custodial agent and convenes the community of VistA users and developers in order support ongoing innovation.

A Platform for Continued Innovation

VistA’s organization as a kernel of common functions with integrated applications and a clinician-facing GUI allows it to evolve as computing and networking technology advances, and enables the development and integration of  new capabilities as the needs and requirements of the clinical community changed over time. VA continues to enhance VistA , evolving clinical functions, building auxiliary applications, and improving internal architecture. For example:

The Health Management Platform (HMP) is built on a new extensible service oriented architecture that allows new systems to interface with legacy systems at multiple levels.  HMP provides user interface modularity and flexibility, reusable services such as ordering services, data extraction, and search across all patient records.  This modularity and service-based approach will allow for gradual replacement or reengineering of legacy components without affecting the entire system, and without impact to users.

Connected for Health provides an API and developer toolkit for web and mobile access to health information, for capturing patient-recorded data, and for enabling mobile applications that increase the engagement of both patients and their at-home care givers in health and wellness management.


3.2 EHRS Solution

(a.i) Describe EHRS functionality in terms of meeting the core definition and in terms of capability beyond the core definition

VistA is a highly configurable, fully integrate Electronic Health Record System that meets all elements of the core definition, as outlined below. As implemented by VA, VistA and its related software and system elements go beyond this core definition. VistA provides support for numerous clinical workflows; integrates auxiliary systems (such as imaging and dental); supports analytics, data warehouses, and patient registries; and provides programming interfaces supporting extensions and integration of new applications.

System Management

Security and Identity Managment

VistA system management provides safe, controlled access for authorized users while providing for fine-grained protection against unauthorized access or usage. A robust Identity and Access Management (IAM) architecture, an integrate Master Veteran Index (MVI), and well-designed network security supports the high degree of security and privacy found in VA’s VistA implementation. Unauthorized system access is prevented, and modern policy-based authorization selectively enables or prevents from  access to individual records or data fields, as well as disallowed behaviors (such as a doctor attempting to self-prescribe medication).

VA’s IAM architecture separates identity authentication from role management. User identity is established through multiple two-factor authentication methods, including methods supported by DoD: PIV, CAC, and DS Logon, for example. Role management, including provisioning, attribute query, and enforcement, are implemented via open standards such as LDAP, SAML, XACML, and SPML enabling integration with new applications (including and especially COTS applications) and supporting federation (including specifically VA-DoD federation).

VA’s MVI provides for a single unique patient identifier that unambiguously identifies patient records within the enterprise-wide VistA network. In addition, the MVI is compliant with HL7 standard protocols for patient record management, allowing for integration with custom and COTS applications both inside and outside the agency. VA has integrated its MVI with our My HealtheVet patient portal and Blue Button personal health record, with the Defense Manpower Data Center (DMDC) Personal Data Repository, and with the eHealth exchange (also known as NwHIN). Significantly, DMDC integration achieves interoperability with DoD’s Electronic Data Interchange Personal Identifier (EDIPI).

VistA integrates seamlessly with network security measures implemented by the deploying enterprise. VA, for example, segregates VistA-related network traffic using industry-standard MPLS services to implement regional VPNs with inter-regional routing. Network boundary protection and monitoring occurs at Trusted Internet Connections (per Department of Homeland Security policy) and a tightly controlled business process governs network access. No changes are required to VistA software in order to gain the benefit of robust network security practices.

Disaster Recovery and Business Continuity

The ability to recover from disaster events while maintaining continuity of operations is closely tied to the ability to maintain the integrity of and access to the VistA database. High availability and recoverable servers, data centers, and robust network design limit the impacts of serious disruptions and enable local operations to quickly re-established.

VA’s regional data centers are located hundreds of miles apart and hundreds of miles from end users and are interconnected with redundant, independent network links. Even multiple or geographically broad events are highly unlikely to affect all data centers, allowing for rapid transfer of operations to alternate facilities.

Using features built in to VistA’s implementation environment (Intersystems Cache), VistA databases are asynchronously replicated and synchronized at regular intervals such that a recovery point of seconds, and at most two minutes, is achieved.

Linux-based clusters and applications servers are mirrored between primary and designated disaster recovery sites. Should a failover occur, the reconfiguration to control files (such as VistA Caché configuration) and network parameters (such as DNS tables) are updated and operation continues from the recovery site.

Interoperability

Delivering a full spectrum of care to a large and varied patient population requires coordinated access to a range of data, devices, and applications, necessitating a high degree of intra- and inter-system interoperability to assemble an integrated patient profile. VistA supports the ability to communicate and interact with other systems at multiple levels: applications may be tightly integrated with open source VistA code or loosely integrated via application programming interfaces (API), medical devices may be connected, and patient data may be shared between providers. VistA supports multiple standard data formats and protocols to facilitate these interactions.

For custom or commercial applications that require tight integration with the VistA database or business logic, the interface of each VistA package is documented (see www.architecture.osehra.org), identifying both the code routines and the data fields owned by the package. VistA source code is freely available (see, for example, https://github.com/OSEHRA) and programmers have full an open access to internal programming interfaces.

However, many applications can be developed using standardized interfaces that remove the requirement to access internal VistA code. There are several methods available to today’s programmers who seek to develop new applications – in particular, web-based and mobile applications - in a variety of programming languages.

VistA supports a library of published Remote Procedure Calls (RPC) that provide access to VistA data and logic for a wide variety of functions. CPRS, for example, interacts with VistA largely through the RPC interface. While the RPC interface provides excellent separation between the mainline VistA applications and the clinician-facing GUI (like CPRS, and now JANUS), enabling easy integration of different presentation layers, it is not restricted to tightly integrated components. Web-based applications easily interface with VistA via the RPC library, as evidenced by the open web application developer toolkit EWD (see www.mgateway.com), which allows JavaScript-based development of VistA-based web applications.

Because services-based architectures predominate current software development, VA has developed open web services interfaces to VistA that fully empower today’s programmers to develop applications that meet the varied needs of clinicians and patients using familiar, standards-based software constructs. MDWS (Medical Domain Web Services) is a fully open source collection of web services providing access to VistA data and common services via industry standard SOAP and REST protocols. Major applications such as VA’s My HealtheVet patient portal, the Blue Button personal health record, and the rapidly-emerging mobile Connected for Health platform provide patient-facing and clinician facing applications on both web and mobile platforms, accessing VistA via MDWS web services. All of VA’s innovation pilot projects, administered by the VA Center for Innovation and providing a structured path for evaluating new health care technology, also work with VistA via MDWS. VA is actively expanding the VistA-based open source web services.

For example, the aforementioned Health Management Platform has  a single service call that extracts a complete Virtual Patient Record, significantly simplifying application access to patient data. We consider this multi-tiered, services-based architecture to be critical to the the maintenance and enhancement of VistA for years to come.

In addition to internal programming interfaces and outward-facing web services interfaces, many VistA applications communicate via standard HL7 messaging protocols. HL7 messages provide for application-to-application communication as well as enabling data exchange with external data repositories.

HL7 messaging also provides the fundamental mechanism for medical devices to interact with VistA. The Clinical Procedures package provides an interface between medical devices and VistA. Devices communicate with the package via HL7 messages sent via a standard TCP/IP session. Both unidirectional and bidirectional device communication is supported. Data from the device is saved according to the particular application; VistA supports both a data repository for clinical device data and a report viewer to format the data for clinical review. A full range of devices, from PACS imaging to ICU equipment, are interfaced with VistA in this manner.

The ability to export data from an EHR and to exchange health information with other providers is increasingly important in providing the complete patient profile necessary for the delivery of accurate, timely, and safe care. Indeed, it is one of the foundational principles of both the Virtual Lifetime Electronic Record (VLER) and the iEHR programs. VA has developed VistA-based support for the eHealth Exchange (Nationwide Health Information Network, or NwHIN), with common services for the extraction of health data from VistA, the formatting of exchangeable documents, and, via MVI integration with VA’s NwHIN gateway, for the management of patient and provider identities. VistA is well positioned for interoperability in a connected health care world.

While the eHealth Exchange enables provider-to-provider communication of EHR data, Blue Button provides simple patient access to personal health information. Blue Button makes the complete patient record securely available to patients (except for radiological images, which will be available this Spring) in a standard electronically exchangeable format called “the C32 Continuity of Care document”. Designed, developed, and delivered by VA via the My HealtheVet patient portal and soon to be broadly implemented by DoD, Blue Button provides simple, convenient interoperability and exchange of patient health information. VA’s Blue Button support is built upon web services that perform the extraction of Blue Button information from VistA, the composition of Continuity of Care Documents, and the system management required to provide on-demand patient access to current Blue Button information. These web services are openly available and provide an easy integration point for the sharing of health record data between VA and DoD, and the source code to Blue Button and My HealtheVet are available at OSEHRA

Data Model

VistA’s data store is implemented in MUMPS, an application environment that integrates both program logic and data storage. MUMPS excels in multi-user database-driven applications, such as health information systems and financial systems. The database and central services of EHRs such as VistA and Epic’s EpicCare are implemented in MUMPS, as are financial services systems such as the US’s largest online trading system, operated by Ameritrade.

As described in the preceding section, data stored in VistA’s database can be accessed by a variety of methods, from tightly integrated custom code to loosely coupled standard web services to network-spanning exchange mechanisms such as eHealth Exchange.

The lifetime of the data stored in a VistA database is not limited by VistA or the underlying MUMPS implementation; it is limited only by the underlying IT support to keep the VistA instance in operation. VA does not delete patient data and maintains the operation of all VistA databases indefinitely, even those that have been consolidated in regional data center consolidations.

Given that VistA is not locked to a proprietary, vendor-specific hardware, operating system, or middleware platform, VistA instances may be kept running, migrating to new platforms as required, for the indefinite future, providing data accessibility and security that meets all regulatory requirements. Should it become necessary at some future date to export the data from VistA to another data store for long-term retention, VA has developed data extraction and normalization tools, currently used to build our data warehouse for analytics applications, that can perform an archiving of the required data.

Clinical Workflow

Designed by clinicians for clinicians, VistA is patient-centric and embodies the clinical workflow processes that support VA’s models of care. Adherence to standardized workflow, while recognizing that medical care is a cognitive, responsive process, enables measurable improvements in the quality of care we provide.

VistA and CPRS support clinical workflow through implementation of clinical decision support rules tightly integrated into the display of patient data. The efficiency of entering orders, progress notes, encounter data, and other clinical information is improved, providing complete and consistent data that assists in chronic disease management, identifies potential medication errors, reduces unwanted deviations, ensures compliance with legislative mandates and regulations, and improves both patient safety, quality of outcomes, and efficiency of care.

VA continues to advance VistA’s workflow capabilities via the Health Informatics Initiative (hi2) Health Management Platform – also available at OSEHRA – that adds patient management support for models of care including multi-patient team boards, condition-based actionable worksheets, team communication through instant messaging and team tasking. Support for tracking of medical goals and the linking of medical goals to specific interventions and measure in a comprehensive medical plan is under development, as is the addition of a separable rules engine to support rapid development and maintenance of workflows and clinical and administrative processes.

Clinical Documentation

VistA supports the efficient capture, storage, and review of a full compliment of clinical documentation, including patient assessment, progress notes, admission and discharge summaries, care plans, etc. CPRS workflows and templates guide clinicians through the capture of appropriate data at the point of care and ensure that complete and consistent data is captured.

Via VistA Imaging, VistA supports the capture, display, manipulation, and management and viewing of multimedia documents, including a wide variety of medical images, video clips, graphics, scanned documents, and audio files.

Clinical Display/Dashboard

CPRS provides highly integrated data display and retrieval for VistA users and has extensive capabilities to display and graph data over customizable time intervals.

CPRS improves the efficiency and provider productivity of order entry, progress notes, encounter data, and other clinical information in the patient chart and helps clinicians comply with legislative mandates and clinical practice guidelines.

VistA’s support for clinical dashboards allows customization of displays for specific applications and workflows; for example, a web-based dashboard view for Emergency Departments facilitates management of the flow of patient care. Patient data is posted to a display board where it is editable; patients may be added and removed and their dispositions updated as conditions change. Administrative reports are created directly from the display board.

VistA’s customizable views allow site-specific customization of data displays and dashboards. VistA implementations outside of VA (for example, RPMS from Indian Health Service or OpenVistA from Medsphere) have developed tailored displays using the flexibility of the VistA system.

Extending VistA’s display capability and integrating provider actions, VA’s Health Management Platform program is creating condition-based worksheets that present all pertinent data for a patient to the provider (medications, test results, abnormal findings, actions that are due, trending graphs, and more).  Providers will be able to take actions right in the worksheet, for example, discontinuation of a medication, order lab test) while documentation is being captured in the background.

Clinical Decision Support (CDS)

VistA has extensive capabilities to provide highly integrated clinical decision support at the point of care that is demonstrated to enhance care quality, safety, and efficiency, as documented in more than 100 studies and publications. CPRS-based decision support is highly integrated into clinical work flow at all stages of EHR use, including patient selection, patient cover sheet review, clinical document review, document creation, order entry, and results review. Use of VistA’s clinical decision support is pervasive at VA, assisting many thousands of VA providers at hundreds of VA sites around the clock, yielding more than a million support events each day. CPRS’ clinical decision support function is a major contributor to the overwhelmingly positive opinion that VA clinicians have of the system and its ability to help them be more effective.

The VistA clinical decision support capability applies rules and interacts with clinicians in two modalities: Clinical Reminders and Alerts.

Clinical Reminders are a general-purpose technology for notifying clinicians of patient-specific situations that require attention. They assist with clinical decision making, identify timely clinical interventions, and improve documentation and follow-up. Reminders can target patients with particular diagnoses and procedures, assist in compliance with disease prevention guidelines, or direct clinicians to perform tests or provide treatments appropriate for specific populations. Clinical Reminders are also a mechanism that VA uses to enforce adherence to clinical practice guidelines, often reflecting performance or exclusion of specific procedures for specific diseases or population groups, in order to achieve high quality outcomes. VA has developed clinical guidelines for diagnoses such as stroke rehabilitation, amputation rehabilitation, diabetes mellitus, hypertension, COPD, major depressive disorder, and psychoses.

Alerts are generated according to rules that evaluate patient data and current CPRS user actions. Medication order checks apply rules to govern the safe ordering of medications. The VistA Pharmacy package integrates a commercial knowledge base to provide advanced interaction checking capabilities, screening for drug-drug interaction, drug-allergy interaction, and therapeutic duplication. Non-pharmacy order checks evaluate patient data and ordering scenarios and apply rules that verify that orders are appropriate for patient condition and that all required information is captured. Alert notifications flag unsigned orders or documents, critical lab results, abnormal radiation results, and many other customizable critical events.

Both reminders and alerts are highly configurable and one of the most powerful features of VistA, enabling the EHR to be an integral part of site-specific and network-wide efforts to improve quality and safety, and to establish uniform practices that tailor such practices to sites, patients, populations, or conditions as required.

Under the hi2 Health Management Platform program, VA is extending VistA’s capability to work with multiple rules engines for clinical decision support, including the ability to use patient and enterprise data to predict future conditions and outcomes.

Order Management (including CPOE)

CPRS, the clinical interface component of VistA, has long been recognized as the best and most tightly integrated CPOE component in the marketplace.  This is a direct result of the clinician involvement in the development of VistA and its order management system.

Beyond providing the basic, critical functions to reduce medical errors and improve patient safety, CPOE in VistA provides an intuitive interface for the ordering process, supports clinicians in the order workflow, and facilitates documentation that improves follow-up.

As discussed in the Clinical Decision Support section, VistA tightly integrates rule-based decision support, clinical reminders, and clinical alerts to assist clinicians in ordering scenarios, improving quality of care and patient safety while supporting VA’s clinicians with powerful data analysis and workflow guidance.

(a.ii) VistA Module Content, Pricing, and Configurability

VistA comprises more than 150 software packages, fully inventoried in the attached VistA Monograph. VistA software is open source and available without charge at www.osehra.org. VistA documentation is also available via the OSEHRA web site (http://osehra.org/page/documentation). For technical details on VistA package interconnectivity and the data and routines owned by each package, see the VistA Architecture Reference at architecture.osehra.org.

VistA is an integrated EHR System, with application packages that share a common data store and common internal services. It is also highly configurable and customizable; everything from data views and reports to clinical reminders and workflows may be adapted to the needs of the deploying organization.

VistA functions that are non-essential to the deploying organization do not interfere with the operation of the rest of the system. Depending on the non-essential function, configuration may remove the function from user consideration, the package may remain uninstalled, may remain present but uninvoked, or it may be replaced by an external application.

As described in the Interoperability section, VistA supports the integration of best-of-breed applications at multiple levels:

  •     MUMPS API
  •     Remote Procedure Call (RPC)
  •     MDWS/Web Services
  •     HL7
  •     Data exchange via Blue Button or eHealth Exchange

The flexibility afforded by the range of VistA integration points allows the reliable and efficient integration of custom software, COTS products, and web and mobile applications.

(b) CPR Generation Level

VistA is a Generation 5 (Mentor) computer-based patient record (CPR) system, according to the 2007 Gartner framework. VistA captures VA’s evidenced-based medicine workflows, guiding clinicians based on clinical best practices captured in VistA’s workflows and rules-based recommendations.

3.3 Test

VistA is a flexible system that supports multiple test methodologies. VA implements a complete spectrum of test methodologies that support development and maintenance of a complex EHR system, including developer unit test, functional system test, interoperability testing, performance testing, 508 accessibility testing, and system stress testing. Test environments range from individual developer environments to small, medium, and large medical centers to multi-medical center networks.

(a) Provide empirical test evidence that VistA performs as expected in the intended user environment and describe its scalability.

The production implementation of VistA at VA’s scale, across more than 1500 facilities and more than 6 million patients, achieving high quality health care outcomes and exceptional system reliability, demonstrates the ability of VistA to perform in DoD’s intended user environment.

(b) Describe ability to support an Agile test process.

Most VA software development, as well as contracted software development, is performed according to Agile processes. Core VistA development and significant new programs such as the hi2 Health Management Platform, My HealtheVet, and the Connected in Health platform are all developed using sprint-based Agile processes, including test at the developer and system level.

Agile development requires flexible test tools that can be rapidly configured for the tasks in each sprint. VA has developed two such tools for use in VistA development and deployment: an automated system test platform and a tool for system data analysis.

A platform for automated system-level functional test allows developers and testers to rapidly script functional tests that focus on the features under test provides a powerful tool for Agile test practices. Test scripts can be written in a simple scripting language or they can be automatically generated by recording user actions during test scenarios. All test scripts, custom and auto-generated, may be run as fully automated regression tests.

Analyzing and testing the VistA EHRS involves more than the checking of code; much of the power of VistA is captured in system data: templates, menu options, data dictionaries, file structures, etc. VA engaged the open source community to develop a tool that analyzes system data and compares two VistA instances (for example, a “gold” version vs. a unit under test), allowing developers to rapidly verify that any changes to system data are appropriate.

Both test tools are available via OSEHRA.

3.4 Integration

Describe approach to integrating VistA into the DoD environment.

Our approach to integrating the VA EHRS with the DoD environment has included collaboration with facility/site SMEs to coordinate requirements and develop user awareness and acceptance of new processes to include the identification and resourcing of additional staff.  This included developing inter-agency processes and coordination activities, identifying and defining areas of business process synergy and differences, and common data elements and translations in the applicable data models.  We identified/designed infrastructure (incl. network and hardware) and security boundary integration and implementation points to ensure enterprise architecture framework and security protective protocols/approvals were in place.  We also defined data interchange mechanism/protocols and then coordinated the development (while considering performance and scalability of the solution), testing, and solution deployment with both agencies and facility staff. Integration included the design, development and implementation of a Single Registration Service, Orders Portability Services for Radiology – Laboratory – Consults, Financial Reconciliation and Billing Service, Terminology Service, Identity Management Service, Exception Management Service and associated Common Services required to implement an SOA(Service Oriented Architecture) and ESB(Enterprise Service Bus) at the James A Lovell Federal Health Care Center.

3.5 Transition

Describe approach to transition from DoD legacy EHR to VistA.

DoD can transition from its legacy EHR to VistA on a facility-by-facility basis, given sufficient network-wide planning is first put in place.

Data centers, hardware and software platforms, and network connectivity should be planned on an enterprise-wide basis. VA can share its experience and its current implementation (which is very briefly described in this paper) to assist DoD’s planning effort.

Clinical workflow, business processes, and administrative processes should be reviewed and mapped to VistA’s workflow. Configuration and customization changes can be captured for replication across sites.

The Janus viewer should be interfaced to the CDR and configured to display new patient data from VistA and legacy patient data from the CDR.

VistA site installations should be undertaken according to an enterprise-wide rollout plan.

Legacy systems should be shut down on a facility-by-facility basis as each facility reaches proficiency with VistA.

Describe typical VistA deployment project.

The process for deploying a new VA VistA instance is outline below. While DoD’s implementation process will be specific to DoD’s IT and clinical requirements, reviewing the project flow for a new VA VistA installation may be helpful.

  • Establish a cutover date (providing 6 – 9 months working time).
  • Perform system planning to establish hardware needs. Project system growth by evaluating SAGG (Statistical Analysis of Global Growth; analyzes the database, code, and file information for a given VistA instance to help determine resource requirements) extracts from similar systems.  Determine equipment needs.  Establish personnel responsible for equipment.  Place order for computer equipment, operating system, and Cache licenses. Implement new computer room configuration: hardware, network, and wiring. Install system software.
  • Establish additional systems and equipment; for example, VistA Imaging system, Dental, BCMA Backup systems. 
  • Test interfaces for the Clinical Procedures, Radiology and Imaging packages.
  • Prepare VistA applications to be implemented starting at the day one files.
  • Establish the setup for application parameters, including the business practices for facility and clinics.  Decide how remote will be viewed (via VistA Remote Data View or VistA Web, or in this case, Janus).
  • Once hardware is setup and stable, load VistA production account and begin the initialization of system with new station number, address Kernel parameters, Mailman, Broker, VistaLink and HL7 set-up.
  • Begin population of New Person file.  Develop menu structures and key assignments.
  • Begin application set-up of core applications.  Day-one setup of Patient Information Management systems, which includes divisions, clinics, wards, room/beds.  Begin process of entering appointments (manual or automated via software utility).
  • Concurrently perform set-up of clinical and financial applications.  Establish order for set-up.   For example, foundation applications such as Pharmacy, Laboratory, Radiology, and Dietetics would need to be set up prior to starting the set-up of CPRS ordering. 
  • Begin patient seeding from existing systems.
  • Begin having users sign-on and verify their menus.
  • Develop and run test scripts for the various applications.
  • Begin admission of inpatients.

Describe change management.

VA’s approach to managing change management during implementation of an EHRS solution is to establish a Change Control Board (CCB) process, membership, and standing meeting schedule to consider all requests for changes to the system baseline and defined requirements.  To identify the system baseline, we capture and document core business processes and then review them for potential business process reengineering (BPR) improvements when implementing a new EHRS.   It is also important to capture and document core terminologies and translations to selected standards where applicable to ensure consistent representation of data in the new system.  In addition, we document existing architecture, capacity, and performance metrics to use as a baseline comparison of existing and new systems.  Finally, we document change requests (part of the CB process) and implementation details (deployment process) as they occur to maintain a lifecycle record of the new solution.

For the management of clinical process, a Clinical Change Management Board is established. The activities and responsibilities of the CCMB include:

  • Review, prioritize and determine the disposition of clinical new service requests submitted by stakeholders;
  • Ensure applicable VA policy is in place to support and define proposed technical solutions;
  • Ensure proposed technical solutions serve a business or health care need that cannot be achieved through changes to policy, process or training;
  • Coordinate communication with stakeholder groups;
  • Approve content for future versions of CPRS/VistA.

Membership of the CCMB is comprises both health care and IT subject matter experts.  For VA, membership includes representatives from:

  •     Field Health Informatics Leadership Group
  •     Health Informatics
  •     Health Informatics Initiative
  •     OIT – CPRS Programmer
  •     National Nursing Informatics Council
  •     Pharmacy Benefits Management
  •     Health Information Governance
  •     CPRS Work Group
  •     Office of Analytics and Business Intelligence
  •     Health Systems
  •     National Center for Patient Safety
  •     Facility CHIO
  •     Health Systems
  •     Informatics Patient Safety


3.6 Network and Security Architecture

Describe network and security approach. How similar is VA’s deployment to a DISN-based deployment.

VistA integrates seamlessly with network security measures implemented by the deploying enterprise. VA, for example, segregates VistA-related network traffic using industry-standard MPLS services to implement regional VPNs with inter-regional routing. Network boundary protection and monitoring occurs at Trusted Internet Connections (per Department of Homeland Security policy) and a tightly controlled business process governs network access. No changes are required to VistA software in order to gain the benefit of robust network security practices.

Describe approach to disconnected operations.

VistA supports disconnected operations in two scenarios: temporary loss of connectivity and intentional operation is non-connected environments.

Continuity of operations during a network disconnect is provided by means of a local read-only database at each point of care.  This database is housed in a secure computer room at the site and updated using a proprietary InterSystems Caché shadowing technology that asynchronously replicates database changes to the local site copy.  Read-only access to the database is given to clinicians and care providers via a web-based application thereby allowing them to review clinical data and make ongoing patient treatment decisions.  Once the network outage is resolved, clinicians must update records in the production database.

Mobile Electronic Documentation (MED) provides staff in non-connected environments the ability to view a medical record, document, and place orders when connectivity is not possible; data is synchronized when connectivity is restored.  Both VistA and Master Veteran Index (MVI) support this capability; if the enterprise MVI is not available, local identifiers are created and used at the disconnected VistA site until the centralized system is available.  When the MVI is again reachable, all identities and identifiers are reconciled and any anomalies are resolved.

Describe approach to access control: role-based, attribute-based, both?

Access to the VistA system and to the data it contains is controlled by both attribute-based and role-based security.

User identity is established through attribute-based methods, including methods supported by DoD: PIV, CAC, and DS Logon, for example. Role-based security controls access to individual records or data fields; role management, including provisioning, attribute query, and enforcement, are implemented via open standards such as LDAP, SAML, XACML, and SPML.

3.7 Architecture/Systems Engineering

Describe approach to languages, software, hardware, systems architecture and how this supports integration into DoD environment.

The high availability (HA) platform that VA uses for VistA operations is completely industry standard and would integrate easily into DoD’s operating environment.

VA uses commodity x86-64 systems running enterprise Linux and VMware.  A combination of operating system (OS), open source and custom utilities written in Perl and Bash provide normal operational features including system monitoring and alerts, backups, HA failover, and user load balancing.  A client/server topology supports the applications.  User workload is distributed across multiple application clients running on virtual machines (VM).  This strategy allows zero-downtime migration of failed guests to alternate hosts via proprietary technologies.   The database back end is an HA Linux cluster in an N+1 configuration.  One site database is hosted per back end system although systems are sized to accommodate two sites in case of extreme failure conditions.  The OS monitors critical resource availability and provides seamless database service failover to other cluster members should a resource become compromised.   Each cluster member uses three pairs of bonded, 1 Gbps NICs accessing redundant switches to accommodate segregated VLAN (public, cluster and client) network traffic.

VistA is implemented in MUMPS, and CPRS is implemented in Delphi. However, most new application development is done in other languages, such as Java and JavaScript. It is not necessary to write applications in MUMPS in order to access VistA data or integrate with the VistA EHRS.

Describe any hardware and software requirements (databases, servers, bandwidth, etc.)

VistA’s database is an integral feature of the MUMPS language in which the VistA kernel is implemented. VA uses the InterSystems Caché MUMPS environment; an open source version (GT.M) is also available and used by many non-VA VistA users.

Each application client and active database server runs a Caché configuration for each site served.  Application clients use a highly efficient, proprietary InterSystems Caché Protocol (ECP) to access data on the back end.  ECP is designed to accommodate non-interruption of user sessions during database failover scenarios.

VistA operates on Windows, Linux, and OpenVMS platforms, and is scalable from a laptop (single user) to many thousands of users in a large facility.  VA is currently installing large-scale VistA systems in DISA DECCs.  These systems are Linux based x86 industry standard platforms, configured as a cluster depending on the scale of the facility the system supports.  VA also recommends the installation of a parallel "hot" spare operating in a geographically remote data center to enable maximum availability.  VA currently streams live data to this "shadow" system to ensure no data loss in the event of a fail-over to the shadow.  VA can readily provide a recommended configuration based on the size of facility to be supported.

Describe data storage approach.

VistA’s data store is implemented in MUMPS, an application environment that integrates both program logic and data storage. MUMPS excels in multi-user database-driven applications, such as health information systems and financial systems. The database and central services of EHRs such as VistA and Epic’s EpicCare are implemented in MUMPS, as are financial services systems such as the US’s largest online trading system, operated by Ameritrade.

The MUMPS database resides on mirrored logical volumes with each mirror located on separate storage arrays.  The storage arrays are part of a high performance, highly redundant 4 Gbps fiber-channel storage area network (SAN).  Nightly database backups are performed using operating system snapshots and custom scripts while leveraging storage features such as snapclones and data deduplication.

The lifetime of the data stored in a VistA database is not limited by VistA or the underlying MUMPS implementation; it is limited only by the underlying IT support to keep the VistA instance in operation. VA does not delete patient data and maintains the operation of all VistA databases indefinitely, even those that have been consolidated in regional data center consolidations.

Given that VistA is not locked to a proprietary, vendor-specific hardware, operating system, or middleware platform, VistA instances may be kept running, migrating to new platforms as required, for the indefinite future, providing data accessibility to meet regulatory requirements. Should it become necessary at some future date to export the data from VistA to another data store for long-term retention, VA has developed data extraction and normalization tools, currently used to build our data warehouse for analytics applications, that can perform an archiving of the required data.

Describe disaster recovery approach.

The ability to recover from disaster events while maintaining continuity of operations is closely tied to the ability to maintain the integrity of and access to the VistA database. Couple with a high availability and recoverable server, data center, and network design, the impacts of serious disruptions are localized and local operations may be quickly re-established.

VA’s regional data centers are located hundreds of miles apart and hundreds of miles from end users and are interconnected with redundant, independent network links. Even multiple or geographically broad events are highly unlikely to affect all data centers, allowing for rapid transfer of operations to alternate facilities.

VistA databases are shadowed using technology that is integral to the InterSystems Caché database management system upon which VistA is built. Databases are asynchronously replicated and synchronized at regular intervals such that a recovery point of seconds, and at most two minutes, is achieved.

Linux clusters and applications servers are mirrored between primary and designated disaster recovery sites. Should a failover occur, the reconfiguration to control files (such as VistA Caché configuration) and network parameters (such as DNS tables) are updated and operation continues from the recovery site.

3.8 Identity Management

Describe identity management approach. How does this compare to using DMDC and EDIPI?

VA uses a Master Veteran Index (MVI) as the patient identity management portion of its VistA identity management solution. It creates an index of each patient, providing the “gold copy” of patient identity and records the location of each VA site where the patient is receiving care. MVI is a federated identity solution that allows the use of multiple identifiers and enables VistA applications to exchange information using any identifier, including the EDIPI. Further, many applications outside of VistA, including COTS packages, have been integrated with MVI, such as Cerner Lab, GE Centricity Surgery Quality Workflow Manager, Computer Associates Security, the VistA Pharmacy, Spinal Cord, and Home Telehealth packages, VA’s MyHealtheVet/Blue Button, DMDC’s Person Data Repository, and eHealth Way. All of these applications can use any MVI-supported identifier, including the EDIPI.

MVI’s approach to federation supports interoperability with both centralized and decentralized applications.  VA’s MVI implementation is integrated with all 133 VistA sites and can easily be expanded to include all Military Treatment Facilities. In addition, MVI also provides a robust correlation service that allows for record location throughout the enterprise (correlation-aware identity management solution). It is aligned with healthcare industry standards and is compliant with HL7 standard interface protocols including 2.4 (Minimal Lower Level Protocol (MLLP) and 3.0 (Simple Object Access Protocol (SOAP) Web Services) established for an Electronic Master Patient Index and electronic health records.  In particular,  MVI complies with HL7 messaging for add, update, merge, link, unlink and also has a comprehensive IdM Toolkit that uses HL7 messaging to resolve duplicates, overlaps and overlays to ensure the integrity of the patient identity and identifiers and linkages.

Describe approach to identity management and access control for individuals who have more than one role (patient, provider, dependent, etc.)

VA’s Identity Access Management services separate the user identity, established through various electronic measures (PIV, CAC, and Federation Partners - including DS Logon), from management of roles.  When a user authenticates, the user’s credentials are mapped to their roles. In this manner, VA provides support for both coarse and fine grain access controls enforceable from various points in the architecture.  Services for Role Provisioning, Role Attribute Query, and Role Enforcement are designed with open standards such as LDAP, SAML, XACML, SPML and others to meet the highest interoperability goals.  For example, AcS Specialized Access Control (SAC) service can provide fine-grained access control for applications and services like a doctor’s attempt to self-prescribe medication.

For individuals who have multiple roles, the role or personal selection is tied to the authenticated session or queried through the distributed system by the application being accessed. User menus, keys, and file access are assigned and enforced on an individual user and role basis.

Describe approach to single sign-on capability and the ability to extend it to products that might be added in the future.

The current approach for the VA IAM internal Single Sign-On is a desktop client and server components that support both legacy and new application development efforts.  Legacy applications can be SSO-enabled through the use of the VA Identity Access Management (IAM) Single Sign-On Internal (SSOi) service.   The key to the VA IAM SSOi solution is the flexibility to support both existing and new applications with varying degrees of integration to support the specific business need.   The VA IAM SSOi service supports certificate-based authentication including VA PIV and DOD CAC and is partnered with the VA Specialized Access Control (SAC) service to provide an end-to-end security solution.

Describe context management capability.

VA’s current approach for patient context management uses a context manager (Sentillion) in a centralized and/or decentralized manner.  Applications are integrated with the context manager in order to set the patient context; on the backend, the context manager integrates with the MVI to verify and validate the identity of the patient context and set all other relative identifiers (i.e. EDIPI, ICN, VistA IEN, CHCS IEN) in context.

VA’s future approach to Context Management includes session management and the development of SOA based services that will streamline integration with new COTS products.

3.9 Data

Describe data strategy, including storage, persistence, data model, architecture, security, distribution, transformation, and presentation; and how you will provide standardized and normalized data sharing between the DoD and VA using with the 3M HDD.

VistA’s data storage and persistence strategies are described in the Data Model section above.

The VistA data model is open and in the open source community. The Data Architecture Repository allows searching of data fields and allows developers to maintain data integrity; honoring parent/child relationships, for example.

Descriptions of the VistA data model can be found under the Architecture link at http://architecture.osehra.org.

VA uses ICD-9 (with work underway to move to ICD-10), CPT, DRG, DSM, HCPCS, CDT, NDC, LOINC and other terminologies for the coding of medical records and data fields.  SNOMED for problem list is currently in beta testing with CPRS 29; full deployment will occur in 2013. This accelerates our ability to meet Meaningful Use Stage 2 standards.

VA is committed to making VistA compatible with the HDD.  This will allow VistA systems to access clinical data stored in the DoD CDR, and to provide data in that format for use by the CDR.  Note that VA has migrated data from VistA many times, for use in products like Blind Rehabilitation, Spinal Cord Injury & Disorder Outcomes, and the Central Data Warehouse (CDW) .

VistA/CPRS is fully compliant with HIPAA Privacy and Security standards.  Patient records can be designated as sensitive; access to such records triggers a warning message alerting the user that they are about to access a sensitive record, if the user proceeds with the access, the system creates an audit record that records puts the requesting user on a list to be checked by the facility ISO.  Access via VistA is via role-based menu trees with sensitive options locked with security keys to grant permissions to personnel by minimum necessary standards.

The hi2 program has adopted the Virtual Patient Record (VPR) approach to create temporary data caches that are highly indexed, standardized, and optimized for a defined need.  To support the Health Management Platform, the VPR is a JSON store that meets HITSP standards for C83 document format and is indexed to optimally support the Solr search engine.  The VPR is populated from all VistA databases and can accept data from multiple other sources.

VA’s CDW supports enterprise-wide analytics. Individual VistA instances update regional data warehouses; the regional data stores are aggregated in the CDW. Data is normalized in the CDW and the warehouse is optimized for analytic use; this database design facilitates the development and support of multiple data marts that can be developed quickly to meet the needs of the end users.

Should DoD adopt VistA as its core EHRS, data sharing between VA and DoD medical facilities can be easily accomplished via the enterprise architecture employed by VA. Each MTF/VAMC has rapid access to patient data in its local data store; patient data stored at non-local facilities can be located via the MVI. While patient data can be shared via electronic exchange of Blue Button or continuity of care documents, perhaps via eHealth Exchange, a database-level sharing of data is far superior. Sharing of data for analytics can be accomplished by federating VA’s CDW and DoD data stores such as the CDR and the Air Force Health Services Data Warehouse.

Describe your data management approach to address scale, data format (structured, unstructured, multi-media, and extensibility), consistency, quality and quality management, redundancy, availability, patient safety, and operational performance objectives.

VistA handles a wide range of document types. In addition to storing and managing radiology images, MRIs, and other clinical images, the VistA Imaging system handles video, graphics, audio, and scanned images.

All scanned documents and images have a required Document/Image Type when stored in VistA.  Examples of “types” include: Advance Directive, Consent, Discharge Summary, Image, Procedure/Record Report, etc.  These Document/Image Types are then associated with specific classes of images, such as Clinical, Clinical/Administrative, and Administrative.  Uses can be given specific roles and Security Keys so that they will only see ADMINISTRATIVE “types” and/or CLINICAL “types”. The User can then create Image List ‘Filters’ to access scanned documents and images specific to Document/Index Type, Specialty, Procedure/Event, Class, Date/time etc.

VistA/CPRS systems are configured for enterprise-wide quality monitoring and improvement that align with our agency’s health care mission.  Current VA activities that address data architecture and storage (e.g., the Corporate Data Warehouse) and the requirements of Meaningful Use (e.g., electronic Clinical Quality Measures), as well as the future presentation layer for clinicians (e.g., Health Management Platform) will build upon that solid foundation to expand VistA/CPRS’ capability to improvement clinical management in real time.

As VA works towards Meaningful Use certification for VistA, we are developing the ability to report Clinical Quality Measures. The hi2 program is developing tools to support specific CQMs (Congestive Health Failure and Antibiotic Stewardship) and will expand to other Quality Measures as the tools mature. Also, we plan to integrate existing open source tools (such as Pop Health) with VistA, CDW and other VA data sources to facilitate clinical quality reporting.

Describe your data management approach to include the use of legacy data and data stores, and how data will be managed across system components (e.g., Pharmacy, Lab, etc.).

VistA’s data model makes all system and patient data available to VistA’s applications. No export, import, or explicit exchange of data between system components such as Pharmacy, Lab, etc. is required. This level of integration allows workflow, orders, and decision support to operate with a complete view of patient data, decreasing opportunities for errors that may impact quality of care and patient safety.

Handling legacy data, specifically integrating CDR data with new DoD VistA instances, is handled in two phases. In the first phase, legacy data resides in CDR and is extracted and displayed with VistA data using the Janus user interface. Note that in this scenario, all VA data and all new (post-DoD deployment of VistA) is handled in VistA; only legacy DoD data in CDR requires integration in the clinical display.

In the second phase, CDR data is extracted and loaded into one or more VistA databases. Once loaded, the legacy data is available to any interconnected VistA system and is thus available throughout the DoD network and the VA network (providing appropriate network connectivity and MVI integration is implemented).

Describe the ability of your EHRS to support data operations offline (if appropriate), to include data availability, replication of data between servers, resynchronization of data, automatic conflict resolution for concurrency issues, and modification of the data.

Mobile Electronic Documentation (MED) provides staff in non-connected environments the ability to view a medical record, document, and place orders when connectivity is not possible; data is synchronized when connectivity is restored.  Both VistA and Master Veteran Index (MVI) support this capability; if the enterprise MVI is not available, local identifiers are created and used at the disconnected VistA site until the centralized system is available.  When the MVI is again reachable, all identities and identifiers are reconciled and any anomalies are resolved.

Describe how your EHRS would support data federation across repositories external to the boundaries of your EHRS, and how you would approach data migration from the Clinical Data Repository (CDR) to your EHRS data store, and federation of your EHRS data store with VA and other systems. How would you account for data volume and performance requirements?

It is worth noting that VA’s enterprise-wide VistA implementation is, in effect, a federation of individual VistA instances, each with its own local data store. Patient data that is stored in multiple locations, or patient data that must be accessed from a remote location, can be located via the MVI, which has a record of the sites at which patients receive care.

Should DoD adopt VistA as its core EHRS, all post-VistA-deployment patient data would be in a common system and both VA and DoD data could be accessed in the same way that VA accesses data today.

Legacy CDR data can be handled in two phases.

First, while the legacy data resides in the CDR, the Janus GUI is used to retrieve data from the CDR and from VistA and present it together. It is transparent to the clinician whether the patient data is coming solely from VistA, solely from the CDR, or some combination of the two. Unlike the current deployment in joint VA-DoD sites such as North Chicago, where clinicians must use either VistA or AHLTA to enter orders, notes and other clinical encounter interactions, clinicians would use VistA as the sole EHR system for all patients.

Second, data from the CDR is extracted and loaded into one or more VistA databases. It is possible and desirable to load patient data into VistA instances where patients actually receive care. When this data migration is completed, all data is stored in VistA systems and VistA can be used as the sole clinician-facing system.

Describe your approach to addressing continued support of legacy systems during the migration of data.

Once DoD facilities are up and running with VistA, it is not necessary to maintain support of legacy systems. Since VistA can be brought up at each site independently, each legacy system can be shut down independently when the local facility is comfortable that the VistA instance is fully operational and that staff are ready. There is no need to coordinate a network-wide switchover.

Describe either the use of a federated data model that serves as the single authority for patient data, or a single physical data repository that provides global access, and the expected performance of your recommended EHRS.

The VistA database serves as the single authority for patient data. Because patient data can be accessed remotely, and the MVI maintains the local of patient data, it is not necessary to build a single, central data repository in order to provide global access. The performance of the EHRS is, for the vast majority of interactions, determined by the performance of the local VistA instance and not a clinician concern, even at VA’s largest installations.

Describe your approach to using the eHealth Exchange from the Office of the National Coordinator (ONC), Health and Human Services (HHS), and the Connect protocol and the Direct protocol to exchange data with the private sector.

VA is an active participant in the eHealth Exchange effort and has developed VA connectors to enable exchange of VA data via Direct and Connect.

VA has developed code to handle the extraction of patient data from VistA and the formatting of exchangeable health summary documents. This code has been wrapped as a web service (as part of the MDWS suite) and is used by the MyHealtheVet platform to build a C32 Continuity of Care Document version of the Blue Button personal health record.

VA also has a pilot project that has implemented the transmission of medical images (from VistA imaging) to external providers using Direct protocols. We expect that the ability to exchange Blue Button files, including images, via Direct to be launched in production later this year.

3.12 User Interface

Describe user interface approach including ability to support 3rd party UI and interface configuration & customization.

VistA supports a number of User Interfaces, each of which is available publically through OSEHRA: the award-winning CPRS system, VistA Web, and the joint VA-DoD JANUS viewer.  As open source software, each of these interfaces may be fully modified to meet DoD requirements, either by VA, DoD, or any contractor.

CPRS is the primary interface used at VA facilities. It enables clinicians to enter, review, and continuously update information connected with any patient. Orders, medications, diets, radiology tests and procedures, allergies, adverse medication reactions, consult requests, progress notes, diagnoses, treatments, and discharge summaries are all accessible via CPRS. Integrated clinical reminders and alerts assist with compliance with clinical guidelines and documentation requirements. CPRS is customizable and runs on workstations, laptops, tablets, iPads, and smart phones.

VA’s hi2 program is developing a next generation user interface, the Health Management Platform, which integrates data from multiple data sources including DoD sources (CHDR, FHIE, and BHIE), private healthcare systems (via eHealth Exchange), and patient generated data and contains a modular, user configurable interface.

All of these user interfaces connect with VistA via Remote Procedure Calls and web services, making possible integration of other 3rd party GUIs. The interface software for CPRS, VistA Web, and Janus are all available as open source software (and the HMP source will be available, when ready, as well), offering developers an opportunity to understand the APIs available to support the integration of new GUIs.

3.13 Workflow

Describe approach to configurability of workflow, to create reports, and to operate offline.

Designed by clinicians for clinicians, VistA is patient-centric and embodies the clinical workflow processes that support VA’s models of care. Adherence to standardized workflow, while recognizing that medical care is a cognitive, responsive process, enables measurable improvements in the quality of care we provide.

VistA and CPRS support clinical workflow through implementation of clinical decision support rules tightly integrated into the display of patient data. The efficiency of entering orders, progress notes, encounter data, and other clinical information is improved, providing complete and consistent data that assists in chronic disease management, identifies potential medication errors, reduces unwanted deviations, ensures compliance with legislative mandates and regulations, and improves both patient safety, quality of outcomes, and efficiency of care.

VA continues to advance VistA’s workflow capabilities via the Health Informatics Initiative (hi2) Health Management Platform, which is adding patient management support for models of care including multi-patient team boards, condition-based actionable worksheets, team communication through instant messaging and team tasking. Support for tracking of medical goals and the linking of medical goals to specific interventions and measure in a comprehensive medical plan is under development, as is the addition of a separable rules engine to support rapid development and maintenance of workflows and clinical and administrative processes.

Unlike a patient-chart model, the HMP model consolidates relevant actions and information in role-based worksheets. The application's modular architecture makes worksheet views inherently flexible.  A given healthcare professional can perform several roles. For example, a clinician can function as one patient's primary-care provider and as a consultant on another patient's care team. Each of these roles has its own distinctive workflow. Likewise, each condition imposes its own unique workflow. For example, diabetes workflows include checks for foot sores and blood-sugar levels

The HMP-based system will leverage context containers and clinical modules to support a virtually limitless number of role- and condition-driven workflows. Based on local and national business rules, VA facilities will identify users' roles (including specialty roles) and create worksheets that contain the views, menus, choices, and inputs that support the tasks associated with these roles. Conditions-based workflows will leverage national best practices. Facilities also will have the ability to configure worksheets based on local and national business rules, enabling the system to understand clinicians' current roles; these roles will determine the views, menus, choices, and inputs the system presents. By enabling facilities to redefine workflows, the system can continue to support role-based workflows as they evolve

The HMP-based system will be nonlinear so that it can work the way clinicians do. Its views will be definable and flexible to support numerous workflows. Workflow-driven views will offer all of the information and services that healthcare professionals need to efficiently perform associated tasks and, depending upon the nature of the specific workflow, will even offer useful templates that clinicians can modify and save for repeated use.

Although physicians often treat one patient at a time, they sometimes treat groups of patients. And although patients usually have only one primary-care physician, they often see a multitude of specialists. The HMP will provide configurable, role-based single-patient and multi-patient views for individual healthcare providers and care teams.  In addition to team-based multi-patient views, the system will include management and communications tools that support inter- and intra-team messaging, team tasking, and coverage tools such as handoff notes.


Appendices:

VistA Monograph


Detailed Objectives
For reference, these are the detailed objectives listed as an attachment to the RFI document.

1. General Objectives

  1. Replace the current DoD systems with an EHRS that is at least a Generation 3 EHRS, or later generation, as defined in Gartner's “Criteria for the Enterprise CPR”, Published: 29 June 2007
  2. Provide better performance than existing DoD EHRs
  3. Provide longitudinal medical record for each beneficiary that is globally available across all time zones (24/7/365) and full range of military operations
  4. Improve electronic exchange of medical and patient data between the DoD and their external partners

2. Clinical Objectives

  1. Provide ability to view legacy and external data
  2. Provide a configurable user interface to enable tailoring of the clinician workflow
  3. Provide patient facing view of record, supporting data entry and secure messaging
  4. Provide team management tools to improve efficiency and collaboration
  5. Provide the clinician workforce with innovative and advanced tools, i.e., clinical decision support, highly integrated orders services, and cognitive analytic capabilities
  6. Provide capability to implement automated clinical practice guidelines (condition based reminders and suggested formatting behaviors) that can be configured to Military Health System (MHS) standards and adapt to changing healthcare environments
  7. Provide clinician and commander workforce with the ability to control access to segmented, privileged, very important person (VIP) and sensitive / masked data
  8. Provide a capability that operates with autonomous, self-contained medical devices
  9. Provide standards-based data export to an auxiliary data warehouse / analytics-like capability to enable data mining for identification of trends and support for medical research
  10. Provide patient safety through delivery of current, complete, and appropriate patient information and evidence-based decision support to providers to make quality decisions
  11. Improve patient safety through use of analysis and monitoring of data for early detection, identification, and investigation of hazards
  12. Provide a reporting functionality for visibility and transparency of safety events throughout the system for improved patient outcomes
  13. Provide / identify ancillary care processes that contribute to patient safety
  14. Provide historical patient safety information to consumers / patients to build trust through a transparent system
  15. Provide the capture of structured and unstructured data in a way that enables easy customization, consistent with usability standards, of ad hoc reports and generation of template reports
  16. Support Patient Centered Medical Home

3. Business Objectives

  1. Support 70,000 total clinicians and a maximum of 20,000 concurrent clinicians
  2. Dramatically reduce overall costs incurred by the DoD healthcare environment
  3. Provide an upgrade strategy with minimal cost and disruption to user community
  4. Provide capabilities for aggregate analysis to include export of standard data elements for use by peripheral business systems
  5. Provide predictable costs and performance measures such that the DoD can analyze the cost of treatment to evaluate existing and future costs of operations

4. Program Management Objectives

  1. Ensure the program has a well-defined risk management approach
  2. Plan and execute a user acceptance and adoption strategy that mitigates identified adoption risks and is responsive to the changing needs of DoD’s clinician workforce
  3. Provide a transition strategy that minimizes disruption to operations
  4. Provide and eventually move all inter-related components of the EHRS to the appropriate DoD sustainment activity
  5. Provide a program approach that utilizes the Agile Scrum methodology to include product configuration, development, integration, and clinical, technical, and management engagements

5. Technical Objectives

  1. Configure the EHRS to interface with medical devices and respective data
  2. Deploy an EHRS that has the ability to exchange data in non-proprietary formats, using federally approved health data exchange standards
  3. Deploy an EHRS that uses an open and standards-based information / data model
  4. Deploy an EHRS that has standardized and open Application Program Interfaces (APIs)
  5. Deploy an EHRS whose underlying and supporting technologies are designed to support extensibility, and supports interoperability with separately developed capabilities
  6. Deploy an EHRS that supports a federated data architecture and includes federation with VA data sources and other external data sources
  7. Deploy an EHRS that maintains, and supports enhancements to, ongoing data exchange between DoD and VA, and all external partners
  8. Deploy an EHRS which is end-user platform independent, and supports use by credentialed users (clinicians and patients) independent of location and device (e.g., mobile devices)
  9. Deploy an EHRS that maintains patient context across all user-facing components
  10. Deploy an EHRS that enables 100% compliance with the Health Insurance Portability and Accountability Act of 1996 (HIPAA) and with the Privacy Act of 1974 as amended
  11. Deploy an EHRS that securely controls data at rest and during transmission
  12. Deploy an EHRS with attribute-based access controls and an authorization mechanism to differentially protect data (e.g., by type or level of sensitivity)
  13. Deploy an EHRS with the ability to customize and manage workflow and associated business rules
  14. Deploy an EHRS that utilizes a Government-operated Identity Management service
  15. Deploy an EHRS with a Single Sign-On approach using a DoD Common Access Card (CAC)
  16. Deploy an EHRS that meets DoD Information Assurance requirements to include obtaining Authorization to Operate (ATO) and Authority to Connect (ATC)
  17. Deploy an EHRS that allows continued operations with no data loss when disconnected from the network or in low or no bandwidth environments and allows for efficient disaster recovery
  18. Deploy an EHRS that utilizes industry best practice for configuration management, system updates, and deployment change management on an enterprise scale
  19. Deploy an EHRS designed to operate in a multi-network environment (e.g., .mil, .gov)
  20. Deploy an EHRS that supports data exchange with systems to be identified (e.g., Defense Medical Logistics Standard Support (DMLSS), Blood Donor Management System (BDMS), Healthcare Artifact and Image Management Solution (HAIMS), Coding and Compliance Editor (CCE), and Theatre Medical Data Store (TMDS))
  21. Deploy an EHRS using a regional data center approach to deliver capability to medical facilities and end users
  22. Deploy an EHRS using a scalable, regional hub construct and infrastructure that allow the EHRS to meet non-functional performance requirements (e.g., user experience, system availability, disaster recovery, data read / write response time, etc.)
  23. Employ a repeatable, scalable change management and training approach to deliver technical and functional end-user training while continuously optimizing user experience
  24. Deploy an instance of the system (including all integration efforts) as a “Training Environment” that supports users in pre-deployment training, future new, and refresher training enabling end-users to practice in a non-production environment
  25. Deploy an EHRS that includes a support and sustainment strategy to address maintenance and updates for the system
  26. Ensure that the proposed regional hub design for EHRS is consistent with the Medical Community of Interest (Med-COI) strategy
  27. Deploy an EHRS that supports remote system performance monitoring and modern techniques for preemptive failure prediction and adjudication

 

Changelog

5/14/2017 Introduction to article updated.

Comments

New info: iCare Webinar New VistA CPRS GUI

We showed our new HTML5 web interface for VistA CPRS yesterday to a large VA audience. Here's a link if you are interested in seeing it.

http://www.youtube.com/watch?feature=player_detailpage&v=YC_I5w6sxH0