Loren Data's SAM Daily™

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

D -- TAC-17-43819_RFI for VistA MUMPS Analysis Tooling Extension and additional POC - 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

VA11817N2018
 

Response Due

4/19/2017
 

Archive Date

7/27/2017
 

Point of Contact

Joshua Cohen
 

E-Mail Address

0-9696<br
 

Small Business Set-Aside

N/A
 

Description

Page 9 of 9 Request for Information: VistA MUMPS Analysis Tooling VA Office of Information & Technology (OI&T) Enterprise Program Management Office (EPMO) Department of Veterans Affairs April 3, 2017 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. I. Scope of Work The Department of Veterans Affairs (VA) is conducting market research across industry to identify existing product solutions and/or services to: Perform VistA Data Dictionary Analysis & Remediation. Conduct VistA M code analysis / convergence. Identify and report VistA M code security vulnerabilities. VistA is the integrated administrative, financial, business, and clinical system supporting VA s operations. Current Environment There are 130 VistA systems in production across the U.S. supporting over 1,200 Veterans Health Administration 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 Electronic Health Record (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 tool to assist in analyzing, segmenting and isolating VistA s business logic that is currently spread throughout all layers of the VistA environment. 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. II. Technical Background VA requires a commercial off the shelf (COTS) tool or tools to assist in: 1. Performing VistA Data Dictionary Analysis & Remediation, 2. Conducting VistA M code analysis / convergence, and 3. Identifying and reporting VistA M code security vulnerabilities. This/these tool(s) is/are necessary to progress VA s VistA Standardization and Virtualization (VSV) and VistA Security Remediation (VSR) projects. Industry feedback is requested to assist VA to identify COTS tooling to achieve the desired objectives as indicated by the referenced requirements. III. Technical Challenges The VSV and VSR projects are top priorities for VA, whose outcomes may influence the ongoing use of VistA as VA s EHR platform. COTS tools are required to facilitate the analysis and remediation of variances across VAMC VistA instances. 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 VSV and VSR efforts must be executed to have a standard VistA baseline from which to integrate and later migrate. It remains a requirement whether a COTS EHR alternative is selected or not. IV. RFI Response Your response must include the following: Provide a completed spreadsheet indicating whether your product fully meets, partially meets, or does not meet some or all of the stated VistA MUMPS tool requirements relative to (I) Data Dictionary Analysis & Remediation, (II) Code Analysis / Convergence, and (III) Security described below. Please use the spreadsheet included in this RFI release for capture of your product s alignment to the stated requirements. No other method for this mapping will be accepted. Data Dictionary (DD) Analysis & Remediation: 1.1 Identify where there is embedded code in the FileMan data dictionary.   1.1.1 Verify that these embedded code are in compliance with the M code Standards and Conventions (SACC) standards 1.2 Verify that all DD definitions are the same as the national standards 1.3 Identify and make sure all the security levels for all DD were not deleted or modified based on the national standard: 1.3.1 DD ACCESS: @ 1.3.2 WR ACCESS: l 1.3.3 DEL ACCESS: @ 1.3.4 LAYGO ACCESS: @ 1.3.5 AUDIT ACCESS: 1.4 Identify hidden security levels are still the same as the national standard 1.5 Identify all the executable code 1.6 Cross-reference definitions are all the same and not modified 1.7 Verify that Triggers are not modified 1.8 Verify that Data Global locations are not modified 1.9 Identify pointers, VARIABLE POINTERS, DINUM 1.10 Identify that all DD has a corresponding DIC 1.11 Identify the DD that uses ^DIC as their global location 1.12 Identify globals that are non Fileman compatible 1.13 Identify bad cross-ref definitions 1.15 Identify field that has been modified or not defined properly 1.16 Identify that all date fields are defined properly 1.17 Identify that none of the fields are modified 1.18 Identify that the set of codes are the same across the VistA systems 1.20 Identify all DD embedded code that requires DBIAs are documented properly 1.21 Identify M code that bypasses FileMan without going through the FileMan API 1.22 Identify Global sets and kills 1.23 Display results of analysis via a Web UI reporting interface 1.24 Web UI requires neither connection to nor access privileges on the VistA instance 1.25 Reverse engineer: 1.25.1 the major interfaces (HL7 and RPC) 1.25.2 user interface control (VistA Menus) 1.25.3 M coded up and down stream dependencies 1.25.4 Global usage 1.25.5 the FileMan Data Dictionary 1.26 Reconcile information across VistA instances Code analysis/convergence: 2.1 Perform fine-grained M code analysis to find M code differences/variances 2.2 Indicate variances to VistA Platinum code base (Class 1) 2.3 Indicate compliance assessment to VistA Standards and Conventions (SAC) and clearly denotes variances to the SAC 2.4 Identify which VistA system is variant or out of compliance 2.5 Provide checksum analysis   to identify if and what user is associated with code base changes causing the variance/non-compliance. 2.6 Display results of analysis via a Web UI reporting interface   2.8 Execute a static code analysis and modeling of VistA code packages and dependencies. 2.9 Compare two versions of a VistA model in order to show differences between the two models, (e.g., Test/QA/Prod environments). 2.10 Identify changes that may result in operational degradation and/or failure 2.11 Visually represent the associations between and among VistA entity types, with Packages => Routines = > Method dependency relationships. 2.12 identify impact of a planned or unplanned change on an existing entity (package, routine etc.) 2.13 Apply change management components which can create a planned change and automatically determine the impacted entities (packages, routines etc.) and provide a risk score (security) assessment based on those changes. 2.14 Identify matches between the entities in the environments. 2.15 Identify dependencies to enterprise artifacts which are available within the source code 2.16 Provide the capability to extract unused VistA packages and do no harm. 2.17 Identify all routines that requires DBIAs are documented properly 2.18 Compare routine checksums between VistA systems 2.19 Identify any Class III routines 2.20 Identify routines are properly written based on SACC 2.21 Identify code that is setting to a non Fileman globals 2.22 All language features and constructs in Intersystem Cache 2014.1 must be supported in the new tool. These include but are not limited to: 2.22.1 Use of Cache Object Script functions, features, objects and classes are permitted. Rationale it will produce better more readable code with modern features that new programmers can readily understand. 2.22.2 Use Mixed Case in variables names is permitted and may exceed 8 characters 2.22.3 Use of Mixed Case in Global Names is permitted and may exceed 8 characters 2.22.4 Use of $Z functions is permitted Security: 3.1 Identify IP addresses and patterns 3.2 Identify WWW references and patterns 3.3 Identify HTTP references and patterns 3.4 Identify HTTPS references and patterns 3.5 Identify port opening and closing references and patterns 3.6 Identify Social Security Number references and patterns 3.7 Identify copyrights 3.8 Identify all OPEN commands 3.9 Identify all CLOSE commands 3.1 Identify direct SET of the DUZ variable array 3.11 Identify direct calls to the Linux or Windows operating system 3.12 Identify embedded keys 3.13 Provide the capability to retrieve additional patterns to be discovered within the code by means of an externally managed file. 3.14 Provide Vulnerability ID s (V-Key) that are correlated with the most recent Federal security mandates, policies and guidances (NIST, FISMA, Hipaa..etc). 3.15 Provide Timely updates to ensure the accuracy of the V-Key correlation 3.16 Provide a reporting capability and outputs in configurable XML, CSV and other common ingestible formats. 3.17 Store findings, logs and metadata utilizing current FIPS 140-2 approved cryptographic methods 3.18 Assess Security implications while handling errors (error handling response) For the following questions 1 6, please provide a response that is no more than 5 pages: Provide a product description that describes HOW your product (fully or partially) meets the stated requirements, and which aligns to the completed spreadsheet. Please include: a description of the VA environment that would be required to host this product and/or if the product is available in a cloud environment. Whether the product is 508-compliant. Whether the product is VA Technical Reference Model (TRM)-approved. Provide product pricing with consideration for 2 alternative variables: A purchase of the software source code (tool) with all rights to VA to own/modify/maintain the product in perpetuity. An annual subscription license, and any peripheral maintenance/enhancement services related to it. Provide product pricing for peripheral services, which may include installation, system administration, and/or training, if applicable. Provide any information regarding product access, whether via direct purchase or through a reseller, via General Services Administration (GSA) contracts, System for Enterprise Wide Procurement (SEWP), other Government-Wide Acquisition Contract (GWAC) vehicle(s), and/or VA contract vehicles to which you have access in your response. Identify current clients who have procured the product and/or are using the product in a limited demonstration mode. Specific examples or references provided must include the agency, point of contact, dollar value, and contract number, as applicable. Identify whether your product is accessible via SDVOSB/VOSB firms. Responses are due to Joshua Cohen Joshua.cohen2@va.gov and Candice Mazzetta Candice.Mazzetta@va.gov no later than 12 PM EST on Wednesday 4/19/2017. Electronic submission via email is requested. Response shall include company information, including socio-economic size, and DUNS number and CAGE code.
 

Web Link

FBO.gov Permalink
(https://www.fbo.gov/notices/1f0f3a17cd0ece4a2cda7774395a3461)
 

Document(s)

Attachment
 

File Name: VA118-17-N-2018 VA118-17-N-2018_2.docx (https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=3412309&FileName=VA118-17-N-2018-003.docx)

Link: https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=3412309&FileName=VA118-17-N-2018-003.docx

 

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

Record

SN04469580-W 20170414/170412234423-1f0f3a17cd0ece4a2cda7774395a3461 (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 |