Difference between revisions of "RFI VA118-17-N-1781-001"

Latest revision as of 19:19, 14 December 2016

This RFI is for planning purposes only and shall not be considered an Invitation for Bid, Request for Task Execution Plan, Request for Quotation or a Request for Proposal. Additionally, there is no obligation on the part of the Government to acquire any products or services described in this RFI. Your response to this RFI will be treated only as information for the Government to consider. You will not be entitled to payment for direct or indirect costs that you incur in responding to this RFI. This request does not constitute a solicitation for proposals or the authority to enter into negotiations to award a contract. No funds have been authorized, appropriated or received for this effort. Interested parties are responsible for adequately marking proprietary, restricted or competition sensitive information contained in their response. The Government does not intend to pay for the information submitted in response to this RFI.

Your response must include the following:

a. Provide a summary of your technical approach to address the architecture layer issues addressed below and capability to meet the requirements outlined below (to either all OR only a subset of the services requested, which are indicated on an architecture layer basis). Your technical approach and capability statement shall address the following:

i. Proposed technical approach, anticipated deployment timeline, and key interdependency considerations for which VA must make decisions or take advance action to support this requirement. The Offeror shall address key features of its proposed approach and services relative to some or all of the architecture layers and dependencies by responding to questions within its scope of services. These include the following:

ii. Projects vendor has performed for government or commercial clients to standardize and/or consolidate an Electronic Health Record (EHR) identifying scope, goals, and outcomes of those projects.

iii. Application Layer – Address your approach to:

a) Capture, consolidate, and manage the configuration files that run a VistA system.

b) Get all VistA artifacts under source control, identify variances, facilitate VA determination of the superset of all artifacts, and conduct code and configuration convergence.

c) Provide an automated tooling capability that indicates variances in VistA systems (e.g., code, data dictionaries, and configuration).

d) Provide an automated, table-driven, non-destructive redaction system to enable the Freedom of Information Act (FOIA) version of VistA to retain its full functionality.

e) Automate the process of comparison and remediation of Class III and Class I applications.

f) Utilize automated tools to flag variances and audit systems for changes to assure consistency and maintenance of continuity of the standardization of the VistA baseline in perpetuity.

iv. Data Layer – Address your approach to:

a) Identify, through fully automated means, all locations in VistA where applications read and write directly to global storage. Address your approach to remediating all such occurrences such that the outcome enables that all applications read and write data exclusively through the FileMan API and have fully defined data dictionaries.

b) Isolating and refactoring, through fully automated means, all embedded data (such as hard-coded network addresses, etc.) out of the MUMPS procedural code and putting it into configuration files to isolate code from data, while retaining full functionality of the system.

v. Business Rule/Logic Layer – Address your approach to:

a) Segment and isolate the business logic layer that is currently spread throughout all layers of the VistA environment, while preserving the current business functionality.

b) Integrate VA VistA with an external business rules management system.

vi. Infrastructure Layer - Address your approach to:

a) Transition from the 6, physical RDCs to a single, virtualized FISMA High IaaS cloud.

b) Establishing cloud sizing parameters (e.g., what is your intake process for cloud capacity planning) and provide your preferred government pricing model for increments of memory, processing, and storage relative to the referenced IaaS cloud along with your corresponding Service / Operational Level Agreement (SLA/OLA) model.

vii. Security Layer – Address your approach to:

a) Improve VistA application level security (authentication, access control, and auditing).

b) Intrusion detection monitoring of VistA.

c) Identify and remediate vulnerabilities in RPC Broker calls.

d) Provide modern, standards-based, granular access control for all VistA data.

viii. The proposed method and associated cost to execute the logical consolidation of 130 VistA systems to one, single, integrated, transactional database instance while preserving all current VistA functionality.

ix. The critical path dependency considerations, sequencing, and timeline (represented as months) to address the VistA standardization, virtualization, consolidation, and security remediation effort.

x. Risks and mitigation strategies relative to this VistA standardization, virtualization, consolidation, and security remediation effort.

b. Provide any information regarding General Services Administration (GSA) contracts, other Government-Wide Acquisition Contract (GWAC) vehicle(s), and/or VA contract vehicles to which you have access in your response.

c. Corporate experience or expertise in performing these services and specific examples or references. Specific examples or references provided must include the agency, point of contact, dollar value, and contract number.

d. The intent and ability to meet set-aside requirements for performance of this effort must include information as to proposed team members and the PWS requirements planned to be subcontracted to them; and indicate whether at least 50% of the cost of labor is planned to be expended for prime employees or employees of other eligible SDVOSB/VOSB firms, which must include the prime planned percentage and if under 50%, the names of the potential team members that may be used to fulfill the 50% SDVOSB/VOSB requirement.

I. Scope of Work

The Department of Veterans Affairs (VA) is conducting market research across industry to identify solutions and services to:

1. Standardize disparate VistA application instances on a single code base for VA-wide use (Application Layer).

2. Update the FileMan Application Programming Interface (API) to correctly and fully describe all Applications data, allowing Applications to read/write data through a standardized VistA Data Dictionary (Data Layer).

3. Segment and isolate the business logic layer that is currently spread throughout all layers of the VistA environment, while preserving the current business functionality (Business Rule/Logic Layer).

4. Consolidate the six Regional Data Centers in which VistA is hosted into a single, Infrastructure as a Service (IaaS) VistA production cloud instance. The VistA cloud shall support FEDRAMP / FISMA HIGH with sufficient load balancing and disaster recovery of VistA components to support 99.9% to up to 99.999% reliability, depending on the VistA component. The cloud environment shall also support Platform and Software as a Service (PaaS and SaaS). The cloud environment shall also support VistA development, test, and pre-production environment(s) for the single, standardized VistA instance (Infrastructure Layer).

5. Improve intrusion monitoring and auditing of VistA while closing gaps in application level security and vulnerabilities to VistA data (Security Layer).

VistA is the integrated administrative, financial, business, and clinical system supporting VA’s operations. However, for the purposes of this RFI, the focus is the clinical component of VistA, which is analogous to its Electronic Health Record (EHR) functionality.

VistA Evolution (VE) is a joint Veterans Health Administration (VHA) and VA Office of Information & Technology (OI&T) program to improve the efficiency and quality of Veterans’ health care by modernizing VA’s health information systems. Under the leadership of the VE Program, planning is underway to address the requirements relative to the scope of work addressed above. There may be more than one contract solicited for the required scope of work to achieve VA’s standardization, virtualization, consolidation, and security remediation objectives.

Current Environment

There are 130 VistA systems in production across the U.S. supporting over 1,200 VHA hospitals and clinics. Each VistA instance is composed of over 2,700 files, 64,000 data fields, 1,300 print templates, 9,100 options structured across 1,700 menus, 3,300 remote procedure calls, 38,000 routines, and 4.7 million lines of code. Each system has some local variation of all of these artifacts. The current environment is further described at a multi-tier architecture layer level.

Presentation Layer

VistA’s current presentation layer is the Computerized Patient Record System (CPRS). CPRS is deployed as a thick client-server based system. CPRS is supplemented by the Joint Legacy Viewer (JLV) web application, which is a joint DOD/VA developed system operated independently by each agency to display the longitudinal health record for all active duty and Veterans Service members. The VE Program is also developing a new, thin client (web-based) and mobile end-user graphical user interface (GUI) to VistA to expand its ubiquitous access via various types of end user devices. Initially, the web-based GUI, the electronic Health Management Platform (eHMP), will introduce new clinical capabilities then begin to incorporate and enhance CPRS functionalities. At present, it is anticipated that a complete migration from CPRS to eHMP cannot fully occur until 2020 or later. To make a full transition from CPRS to eHMP, or any potential future COTS software integration, the VA needs a standardized VistA system with a cleaner separation of its architecture layers and interfacing of VistA to new thin clients and external systems with all business logic preserved, which will accelerate the transition.

Application Layer

VistA is a fully integrated system comprising 181 clinical, financial, and administrative applications integrated within a single database, such that there is only one single authoritative version of any data that all applications use. The VistA database is the Congressionally-mandated single source of truth for Veteran information, and is required to be accessible and usable for the lifetime of the Veteran. The clinical component of VistA (analogous to an EHR) represents only 50% of VistA’s functionality.

VistA is based on MUMPS (the Massachusetts General Hospital Utility Multi-Programming System, abbreviated as “M”), the industry-standard database technology in healthcare. All Federal healthcare systems are based on M (Indian Health Service (IHS), Defense Health Agency (DHA), Veterans Health Administration (VHA)); in the private sector more than 50% of all U.S. hospitals are based on M. The virtue of M is that all the data and code are tightly Integrated in a single environment, making highly reliable, highly performant, tightly integrated transactional systems. However, this tight integration of code and data can also create challenges if not properly managed. VistA began over thirty years ago as the Decentralized Hospital Care Program (DHCP) and was developed in the field by clinician-programmer teams at VA Medical Centers (VAMCs). Because DHCP was designed at the outset to provide data and code portability independent of the hardware or operating system environment, DHCP has successfully evolved and migrated from many different hardware platforms and operating system platforms over the past thirty years. However, despite the consolidation of these applications to a national standard (“Class I application”), there remains much locally-developed code at each VAMC (“Class III applications”). Many of these field-developed products are extensions or enhancements to existing VistA applications. VA has a process to evaluate and migrate selected Class III applications that provide enhanced functionality and that offer value to VA by addressing the enterprise-wide business goals of its health care operations. However, there are other Class III applications that remain custom to a VAMC location and are not designated for evaluation to transition to nationally-distributed (Class I) status. All of these Class III applications must be evaluated for use within the VistA consolidated national version. This process is currently manual and not sustainable. Therefore, a fully automated means of continuously monitoring all VistA systems for code and configuration changes relative to a national standard is required, and thus allow for field innovations, while at the same time providing a continuous, automated process of reconciliation going forward.

Data Layer

VistA is MUMPS, an integrated application-database environment. Any discussion about VistA must thus clearly distinguish whether one is managing MUMPS code or MUMPS data. The architecture of VistA separates application code from application data using the Database Application Programming Interface (Fileman API), which allows applications to read and write their data to MUMPS global storage in defined, structured form through a Data Dictionary. However many applications do not use the Fileman API to write data to the database, and instead write directly to the MUMPS storage, leaving the definitions in the Data Dictionary inaccurate (and thus leaving the data inaccessible). VA requires an automated method to identify the locations in the system where this occurs and to remediate the data dictionaries and FileMan API such that all data within the system is fully defined and accessible through the Fileman API.

Business Rule/Logic Layer

VistA’s business logic is spread across many layers and technologies – in the application M code, in the thick client code, in remote procedure call (RPC) logic, and other locations. VA desires to isolate and consolidate this business logic and expose it to external business platforms to provide additional business logic and functionality to VistA. However, much of VA’s business logic is specific to VA and cannot be represented or operationalized by any external business platform. VA thus requires a standardized approach to segment and isolate VistA’s business logic that is currently throughout all layers of the VistA environment while preserving its current business functionality.

Infrastructure Layer

VA has consolidated hosting of its 130 instances of VistA at six (6) regional data centers (RDCs), two (2) of which are hosted at Defense Information Systems Agency (DISA) Defense Enterprise Computing Centers (DECCs). In addition, it has established read-only, mirrored instances at each local VA Medical Center (VAMC). VA anticipates continuing the consolidation effort to transition to a single, FISMA HIGH IaaS, vendor-provided cloud solution with disaster recovery (DR) and continuity of operations (COOP). VA’s goal in this infrastructure consolidation is to reduce the cost of operation, maintenance, and technology refresh while retaining/improving the performance of VistA

Security Layer

Interoperability and exchange of VistA data with DoD and Community partners requires the highest level of security on the data exchanged. Therefore, VistA’s security stack must be enhanced to accommodate these requirements. Current VistA security is dependent on Kernel access control and authentication, which is further wrapped by layers of Application logic of RPC logic. The VA Office of Information Security (OIS) has traditionally been focused on external network and “enterprise boundary” security, rather than VistA security per se – which include such as vulnerabilities of the VistA Kernel (authentication and access control) or RPC Broker (remote access security).

The desired “to be” state will include (1) better authentication (FROM the kernel-managed local VistA process TO an enterprise-based authentication approach across all VistA systems that links to the identity and access management (IAM) system and other services), (2) better access control (FROM over 9000 menu options of Kernel) TO a patient-centric and/or data-centric approach, and (3) better auditing (TO apply better utilization of FileMan’s audit functions to enforce auditing on all transactions).

External or remote applications integrated to VistA (aka “extended VistA”) allow remote access to VistA yet commonly fail to implement established VistA security criteria such as screen time-outs, password refresh, prohibition of generic user accounts, etc. These aspects of the design must be audited to enforce ‘application level’ security and compliance of the external applications and middleware that interface to VistA. In addition, many RPC Broker calls have vulnerabilities which threaten the security of information in the VistA database. These RPC Broker vulnerabilities must be remediated in order to have secure, yet remotely accessible VistA data.

VistA provides user log-on auditing (logging) and the Sensitive Patient Access Log (SPAL), however the volume of data in the Kernel log-on log and the incomplete nature of the SPAL makes human review of these activity logs challenging to detect intrusion in a timely fashion. This indicates a need for real-time, industry standard vulnerability and intrusion detection monitoring utilities for VistA that improves upon today’s Kernel-based security approach.

III. Technical Challenges

This is not a RFI to solicit Commercial off the Shelf (COTS) alternatives to VistA. VA is exploring COTS EHR alternatives but anticipates that for any such alternative and transition to be successful, the VistA Standardization, Consolidation, and Security Remediation effort must be executed to have a standard VistA baseline from which to integrate and later migrate. It remains a requirement whether a COTS alternative is selected or not.

As previously stated, VistA continues to be enhanced to address the current, evolutionary roadmap to yield VistA 4. VistA has many interfaces to other VA systems, Department of Defense (DoD) systems, and to private sector partners, which must be maintained and transitioned so that services are not degraded to the veteran. Any services to be provided for this effort, which may span multiple contracts, will create interdependencies which must be managed to achieve the ultimate goals described herein on an aggressive timeline.

VI. Replies

Responses are due to Jason King, Contract Specialist – Jason.King6@va.gov no later than 11 AM EST on November 30, 2016. Electronic submission via email is requested. Response shall include company information, including socio-economic size, and DUNS number and CAGE code.