Loren Data's SAM Daily™

FBO DAILY - FEDBIZOPPS ISSUE OF APRIL 14, 2017 FBO #5621
DOCUMENT

R -- Veterans Information Systems and Technology Architecture (VistA) Commercialization - Attachment

Notice Date

4/12/2017
 

Notice Type

Attachment
 

NAICS

541519 — Other Computer Related Services
 

Contracting Office

Department of Veterans Affairs;Technology Acquisition Center;23 Christopher Way;Eatontown NJ 07724
 

ZIP Code

07724
 

Solicitation Number

VA11817R2022
 

Archive Date

6/11/2017
 

Point of Contact

Joseph Pignataro, Joseph.Pignataro@va.gov
 

E-Mail Address

Monahan,
 

Small Business Set-Aside

N/A
 

Description

Page 1 of 8 Department of Veterans Affairs (VA) Veterans Information Systems and Technology Architecture (VistA) Commercialization Request for Information (RFI) 1.0 RFI Instructions: This is a Request for Information (RFI) only. Do not submit a proposal. 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. It is requested that all companies interested in participating in this effort please note their interest and submit a capability statement demonstrating their ability to meet this requirement by providing technical details on how their company would provide these services, specifically addressing the questions outlined in Section 3.0 below. The page limit for RFI responses is 15 pages. Please note the business size for North American Industry Classification System (NAICS) Code and indicate if you are a Service-Disabled Veteran-Owned Small Business (SDVOSB) or a Veteran-Owned Small Business (VOSB). 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. The information provided may be used by the VA in developing its acquisition strategy. 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. Please provide the following information specific to your company: Company Name POC Information CAGE/DUNS Socioeconomic Type For SDVOSB/VOSB firms, indicate whether at least 50% of the cost of performance incurred is planned to be expended for employees of your concern or employees of other eligible SDVOSB/VOSB firms.   *Please Note: VA may elect to contact individual companies based upon the content of their RFI submission. VA may engage these companies to gather further information through email correspondence, telephone calls, virtual or physically located meetings, or other means. All proprietary/company confidential material shall be clearly marked on every page that contains such. Main POCs: Joe Pignataro, Contract Specialist Joseph.Pignataro@va.gov, 732-795-1115, Kevin Monahan, Contracting Officer- Kevin.Monahan@va.gov, 732-440-9695. Please submit your responses through email to the Contract Specialist and Contracting Officer at Joseph.Pignataro@va.gov and Kevin.Monahan@va.gov. Responses must be received by 12:00PM, NOON, EST on April 26, 2017. 2.0 Background/Requirements: This is an RFI for a Commercial off the Shelf (COTS) version of the Veterans Information Systems and Technology Architecture (VistA) provided in a Software as a Service (SaaS) model, as an alternative to VA continuing to operate its VistAs which are not fully modernized. VA is also separately exploring COTS non-VistA EHR alternatives. VA s 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. VA is conducting market research across industry to identify solutions and services to: Provide a standardized Commercialized VistA and/or as a Service (VaaS) as a single instance for VA-wide use (Application Layer). FileMan Application Programming Interface (API) or alternative to correctly address all Applications data, allowing Applications to read/write data through a standardized VistA Data Dictionary (Data Layer). 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), into a single VaaS instance. Consolidate the current legacy VistA data from 130 VistA instances at 5 Data Centers to a commercial VaaS, as a single VistA instance in a commercial cloud environment, or provide a Commercialized VistA. The VistA cloud shall support FEDRAMP / FISMA HIGH with sufficient load balancing and disaster recovery (at multiple sites) to support at least 99.9%, and 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) that VA could use to co-locate other infrastructure that VA may need to reside next to the VaaS for performance, security, or other purposes. The cloud environment shall also support VistA development, test, and pre-production environment(s) for the single, standardized VistA instance (Infrastructure Layer). Provide intrusion monitoring and auditing of VistA and demonstrate your detailed application level security and your method of removing/reducing/eliminating/mitigating vulnerabilities to VistA data (Security Layer). VistA s current presentation layer is the Computerized Patient Record System (CPRS). CPRS is deployed as a thick client-server based system, but for the VaaS should not require a thick application for day-to-day operations. The VaaS web based CPRS should integrate the current Joint Legacy Viewer (JLV) web based application to maintain current workflows similar as they are today. Today VA has a way of placing a button on the top of the current CPRS Toolbar for quick access. The proposed VaaS web based CPRS should also have this capability available. The JLV applications is a joint DOD/VA developed system operated independently by each agency to display the DOD, VA, and Virtual Lifetime Electronic Record third party longitudinal health record for all active duty and Veterans Service members. The VaaS web based CPRS should also integrate the VA s other applications to include VistA Imaging Viewer. This can also be proposed in different ways (e.g. Integration, replacement, etc). VA has also developed a new web-based Graphical User Interface (GUI), called the electronic Health Management Platform (eHMP). VaaS will need to provide two options for incorporating eHMP. Use eHMP as the primary GUI for VaaS. Incorporate eHMP functionality into the VaaS enhanced CPRS. Although VistA is currently an integrated administrative, financial, business, and clinical system supporting VA s operations, the primary purpose of this RFI is to focus on the clinical component of VistA, which is analogous to its Electronic Health Record (EHR) functionality, to include Lab and Pharmacy. Note: Lab and Pharmacy can be an enhanced version of VistA application, or a seamlessly integrated separate product. Additionally, even though this RFI is focused on the EHR portion of VistA, include options for the VistA integrated administrative, financial, business, and other supporting operations so VA can evaluate those for possible use in a transition. Current Environment VA currently runs 130 separate VistA Instances. Each one is unique in that there are variations of the routines and data dictionaries for each instance. They are hosted at 5 data centers across the US and support 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 and the current environment is further described at a multi-tier architecture layer level. Additionally, there is a separate DR, Test, and VistA Read Only instance that matches each of the 130 operational VistAs, meaning each VistA instances has four copies currently. 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. Application Layer VistA is a fully integrated system comprising 181 clinical, financial, and administrative applications integrated within its database(s). There is one authoritative version of VistA 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. Other 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. Many Class III applications 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 integration with VaaS. If they can t be integrated then suitable alternatives will need to be proposed. 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 VistA data to write back properly with the new VaaS, which will require some form of normalization between 130 legacy data dictionaries and VaaS data dictionary and its integration with the Fileman API or alternative to Fileman. 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 VaaS. However, much of VA s business logic is specific to VA and may not be readily represented or operationalized by any external business platform. Thus, VA 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, so the new VaaS platform will have a single business logic that migrates old to new. Infrastructure Layer VA has consolidated hosting of its 130 instances of VistA at five data centers (RDCs), one 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 requires the VaaS transition to a single, FISMA HIGH vendor-provided cloud solution with disaster recovery (DR) and continuity of operations (COOP) solution. VA s goal is to reduce the cost of operation, maintenance, and technology refresh while retaining, and improving the performance and functionality of VistA, but as VaaS. Security Layer Interoperability and exchange of VistA data with DoD and Community Care partners requires a very high level of security on the data exchanged. Therefore, VaaS security must have enhanced to accommodate these requirements. VA s current VistA security is dependent on Kernel access control and authentication, which is further wrapped by layers of Application logic of RPC logic. 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 VaaS required to be state will include (1) an enterprise-based authentication approach for all VaaS system access that links/integrates with VA s identity and access management (IAM) system and potentially other VaaS IAM services that integrates with VA), (2) better access control, as a patient-centric and/or data-centric approach, and (3) better auditing than VA has today with current VistA. External or remote applications integrated to VaaS (aka extended VaaS ) allow remote access to VaaS. VaaS will need to effectively implement established security criteria such as screen time-outs, PIV entry for timed out and/or screen lock reentry, prohibition of generic user accounts, etc.   These aspects of the service must be audited to enforce application level security and compliance of the external applications and middleware that interface to VistA. In addition, the VaaS vendor must show how the service does not have RPC Broker calls with vulnerabilities which could threaten the security of information in the VistA database. VaaS must provide user log-on auditing (logging) for all Patient Access Log (SPAL).   This should be a real-time, industry standard vulnerability and intrusion detection monitoring utilities for VaaS and logging that can be pulled by patient so VA can provide such reports to the Veteran or their representative as may be required. 3.0 Questions for Industry: Please provide a summary of your commercial approach to a Commercialized VistA and/or VaaS to meet the requirements outlined in Section 2.0 above. Your technical approach and capability statement shall include an anticipated deployment timeline, and key interdependency considerations that VA must consider to effectively support this requirement. Your technical approach and capability statement shall specifically address the following requirements: Application Layer Describe your approach to: Standardized VistA with a single instance, hosted in a cloud environment. Normalize all VA s historical data (e.g., code, data dictionaries, and configuration) for the single instance. Provide an automated, Freedom of Information Act service so VA can comply with request in a seamless and rapid fashion. Provide options to replace and/or integrate with VA s existing and future Class III applications. How your company will ensure that the Commercial VistA or VaaS will be completely standardized with Logical Observation Identifiers Names and Codes, RX Norm, Systematized Nomenclature of Medicine -- Clinical Terms, and others in perpetuity. Data Layer Describe your approach to: Identify how your Commercialized Vista or VaaS will read and write data using FileMan APIs, Cache, etc., and have fully defined and normalized data dictionaries for legacy VA data and new VA VaaS data. Identify how your Commercialized Vista or VaaS will read data from other data sources, to include other VA data, DOD data, third party external healthcare data, and how that will or will not be normalized with VA s legacy data and new VA Commercialized Vista or VaaS data. Business Rule/Logic Layer Describe your approach to: Segmenting and isolating the business logic layer that is currently spread throughout all layers of VA s current VistA environment, while preserving the current business functionality. Integrate VA s legacy VistA data with an external business rules management system. If it s a 3rd party system, provide a FHIR integration option for it. Infrastructure Layer - Describe your approach to: Provide the VaaS as a single instance, from a FISMA High cloud environment that also meets VA s security and privacy requirements. Establish cloud scaling 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 Service / Operational Level Agreement (SLA/OLA) model. Provide for Disaster Recovery (DR) Infrastructure in at least two ways. Include but not limited to two or more separate, geographically diverse cloud environments, and Geographically diverse, dual, high capacity (10Gbps or greater) WAN connections between the VaaS and the VA s four Trusted Internet Connections (TICs). DR/ No Communications service at the VAMCs, CBOCs, and Vets Centers. Security Layer Describe your approach to: VistA application level security (authentication, access control, and auditing). Intrusion detection monitoring of VistA and its data stores. Demonstrate that there are no unpatched and/or unmitigated vulnerabilities in RPC Broker calls. Provide modern, standards-based, granular access control for all VistA data. The proposed method and associated, estimated cost to execute the transfer and normalization of VA s VistA data from the current 130 VistA systems to one, single, integrated, VaaS instance while preserving and/or enhancing all current VistA functionality. The critical path dependency considerations, sequencing, and timeline (represented as months) to address the VistA data transfer and the stand-up and provisioning of VaaS to VA s Pilot, IOC, and then enterprise wide deployment. Testing of Commercialized Vista or VaaS cloud DR and local no communications DR should also be part of the critical path schedule at the Pilot, IOC, and enterprise wide deployment. Risks and mitigation strategies relative to data transfer and service provisioning. Identify and detail any projects you have performed for Government or commercial clients to provide a standardized and/or consolidated VistA Electronic Health Record (EHR) as a Service, and identify scope, goals, and outcomes of those projects. Also include corporate experience or expertise in performing these services with specific examples or references (agency, point of contact, dollar value, and contract number). Provide a brief summary describing your company s success in commercialization of a product of similar scope, complexity and user-base to Vista including: Name of Products (include description, technology, commercialization approach, client base (initial and current), revenue generated (initial and current), etc. How did your company address Intellectual Property rights, licensing, etc., as it may apply. What are your company s processes to satisfy the requirements for adherence to schedule, agility, flexibility, responsiveness, scalable and reliability, service quality and consistency, and continuous improvement, all deemed critical aspects of this effort? Provide a Rough Order of Magnitude for your proposed technical approach to meet the full scope of requirements outlined in this RFI. Include preferred Government pricing models for licensing, maintenance, and enhancements, addressing required scalability. Provide any additional information not specifically requested above, which would provide value and insight to the Government regarding this effort.
 

Web Link

FBO.gov Permalink
(https://www.fbo.gov/notices/6422e3ba7d555f5553f1dad6809f9119)
 

Document(s)

Attachment
 

File Name: VA118-17-R-2022 VA118-17-N-2022.docx (https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=3409959&FileName=VA118-17-R-2022-000.docx)

Link: https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=3409959&FileName=VA118-17-R-2022-000.docx

 

Note: If links are broken, refer to Point of Contact above or contact the FBO Help Desk at 877-472-3779.
 

Record

SN04470480-W 20170414/170412235207-6422e3ba7d555f5553f1dad6809f9119 (fbodaily.com)
 

Source

FedBizOpps Link to This Notice
(may not be valid after Archive Date)

---

| FSG Index  |  This Issue's Index  |  Today's FBO Daily Index Page |