DRAFT_PWS_HT003824R0006.pdf

CUI

SECTION C – DESCRIPTION/SPECS/WORK STATEMENT

SPECIFICATIONS/STATEMENT OF WORK/PERFORMANCE WORK STATEMENT

Work under this performance-based contract will be performed in accordance with the following description/ specifications/ statement of work (SOW) which herein will be referred to as Performance Work Statement (PWS):

SHORT TITLE: LEGACY DATA CONSOLIDATION SOLUTION – HEALTH INFORMATION

ARCHIVE (HIA)

1.0 PURPOSE

1.1 SCOPE

The Legacy Data Consolidation Solution (LDCS) project is a multi-disciplinary project that integrates critical clinical legacy data as part of the MHS Genesis deployment (Essentris, Armed Forces Health Longitudinal Technology Application (AHLTA), Composite Health Care System (CHCS), Anesthesia Reporting Monitoring Devices (ARMD) & Enterprise Blood Management System Transfusion (EBMS- T) and develop a front-end user interface to extract and view legacy data. Make available a records management application Health Information Archive (HIA) to be used for clinical, analytical, or research need.

Enterprise Intelligence and Data Solutions (EIDS) requires the contractor to finalize development and deployment of a LDCS-HIA solution hosted in the US govCloud that will provide a secure and active health data repository for DHA’s legacy clinical systems. The LDCS-HIA solution will provide clinicians with direct access to a single source of a patient’s longitudinal historical medical records.

2.0 PLACE(S) OF PERFORMANCE

The contractor shall provide support at the following location:

a. Contractor facility

2.1 GOVERNMENT FACILITIES

No Government facilities (i.e., office space or lab space) are provided on this contract. The contractor shall perform work at the contractor facility and/or at temporary duty locations specified under travel.

2.2 CONTRACTOR FACILITIES

The contractor can have its facility location anywhere as long as the location does not present a hardship to complete work required on task. The contractor shall have real-time communication between the contractor personnel supporting the efforts and Government personnel available at time of award.

2.3 ALTERNATE WORK LOCATIONS

The ability to provide support from an alternate location (includes working from an employee’s residence or other non-Government facility) is dependent on the type of support required, the contractor employee’s ability and trustworthiness, and the company’s employment policy. Allowing work to be performed at an alternate location is not an option for all positions and personnel. The ultimate decision to allow work performed at an alternate work location will be determined by the COR. If alternate work locations are allowed, the company shall have defined criteria addressing the minimum requirement to have continuous, secure internet connectivity. Each applicable contractor employee shall have an established signed telework agreement between the company and employee. For each contractor employee proposed to work at an alternate location, the contractor shall submit a written request and justification to the COR with a copy of the applicable employee’s signed telework agreement which becomes part of the COR files. If the requirements for teleworking and/or alternate work locations are not outlined/specified in the employee agreement documentation, the contractor shall include a copy of those requirements with the signed employee agreement. Working at an alternative location shall not adversely affect the response time required in support of the contract/order. The Government reserves the right to disallow any billable hours by contractor employees working at an alternative work location without obtaining prior Government approval. The Government reserves the right to discontinue the ability to work from an alternate location at any time without cause. The inability of a contractor to respond to the requirements of the contract/order due to telework conditions will be negatively reflected in the Contractor Performance Assessment Reporting System (CPARS). The contractor shall utilize the Government site or Client site (vice contractor site) overhead labor rate for personnel working from their residence unless their Accounting System requires a different billing structure.

For purposes of estimation, the following alternate work location support is projected:

PWS Task Paragraph Alternate work location Allowed 3.1-3.4 Yes

3.0 PERFORMANCE REQUIREMENTS

The following paragraphs list non-personal services tasks that will be required throughout the contract.

The contractor shall provide necessary resources with knowledge and experience as cited in the personnel qualification requirement to support the listed tasks. The contractor shall perform requirements in accordance with Federal Acquisition Regulation (FAR) and/or Defense Federal Acquisition Regulation Supplement (DFARS) that do not include performance of inherently Government functions.

The contractor shall develop software, integrate, rationalize legacy data, and deploy the Health Information Archive (HIA) solution into the MIP Enterprise Infrastructure. The contractor shall provide MIP ATO package updates for HIA systems, ingest, map, and load legacy data driven by the MHS GENESIS Wave plan or as specified by EIDS, and describe in interface control document in accordance with the open standard Fast Healthcare Interoperability Resources (FHIR) specification to the HIA.

The contractor shall perform system operations and sustainment of the HIA application. The MIP Systems in scope for inclusion of legacy data in the MIP include:

1. Composite Health Care System (CHCS)

2. Clinical Information System CIS-Essentris

3. Anesthesia Reporting Monitoring Devices (ARMD)

4. Enterprise Blood Management System – Transfusion (EBMS-T)

5. Armed Forces Health Longitudinal Technology Application (AHLTA) Central Data Repository

(CDR)

The contractor shall complete all required tasks while controlling and tracking performance and goals in terms of costs, schedules, and resources.

3.1 PROGRAM MANAGEMENT

The contractor shall provide Program Management to ensure efficient execution of the contract implementation of procedures, and to ensure responsiveness to requirements, assignment of technically qualified personnel, financial planning, and reporting, tracking of project progress against contract requirements. The contractor shall develop a Project Management Plan identifying how they intend to meet the requirements in the contract and the timeline for delivery of the expected performance objectives. The contractor shall prepare a Monthly Status Report (MSR) for performance progress and financial tracking and a Production Order Closeout report.

The contractor shall provide a monthly Contract Funds Status Report and technical Contract Status Report to provide a comprehensive summary of expenditures, progress and significant accomplishments achieved and challenges encountered during the period of performance. At the completion of any single major system installation, contractor shall submit a final technical and financial report providing a comprehensive summary of system configuration / design, expenditures, and progress.

Deliverable: A00# Contract Funds Status Report (CFSR)

A00# SDP (in place of the PMP) A00# Contract Work Breakdown Structure (CWBS)

A00# Contract Status Report (CSR) A00# Cost and Milestones Schedule Plan

3.2 ENGINEERING SUPPORT

3.2.1 Systems Engineering and Architecture

The contractor shall provide System Engineering and support to develop and maintain system engineering process, produce, and update technical deliverables for the solution that become part of the Enterprise technical baseline, and federate models into the Enterprise Architecture.

Deliverable: A00# System Requirements Specification (SRS)

A00# Requirements Trace Matrix (RTM) A00# System architecture and topology diagrams A00# Data flow diagrams A00# System View 2 (SV-2) and Interconnect Diagram

A00# Source Code To include but not limited to:

Data mapping SQL code FHIR development code FHIR Application Interface

3.2.2 Environment

The contractor shall conduct all activities necessary to create and maintain the HIA Development, Staging, Testing, and Production environments within the MIP including Routine Maintenance, and Monitoring

3.2.3 Database Management

The contractor shall conduct database management activities for the Oracle and MS SQL Servers necessary to support all development, testing, and production activities for HIA. This includes all activities needed to ensure the database servers are patched and cyber compliant. The contractor will ensure that the database servers are configured to meet performance and availability requirements. The contractor will conduct all needed activities to ensure that databases are backed up and that needed Continuity of Operations Procedures (COOP) features are enabled.

3.2.4 Mapping/Loading

The contractor shall map and load the data from the following legacy systems:

• AHLTA CDR

• Essentris

• CHCS

• ARMD

• EBMS-T

3.2.5 Interfaces

The contractor shall provide an interface control description (ICD) for the following interfaces from the HIA data using the open FHIR standard for the following legacy systems:

• DMIX-DES AHLTA FHIR Web Services

• DMIX-DES CHCS FHIR Web Services

• DMIX-DES Essentris FHIR Web Services

Deliverable: A00# FHIR Interface Control Document (ICD)

A00# DES FHIR Application Interface A00# ACS DAL FHIR Application Interface

3.2.2 Testing

The contractor shall provide Testing support to:

3.2.2.1 Develop and update a Test and Evaluation Master Plan (TEMP) to coordinate the different levels and types of tests, plan test events and milestones, and ensure entry criteria are met at appropriate integration levels.

Deliverable: A00# Test and Evaluation Master Plan (TEMP)

3.2.2.2 Develop, baseline, and update Test Plans (TPs), Test Cases (TCs), Test Data (TD), Test Execution Logs (TELs), Test Evaluation Reports (TER) or Data Quality System Reports (DQSR), and test environments.

Deliverable: A00# System Test Plans (STP)/Test Evaluation Plan (TEP)

A00# Test Execution Log (TEL) A00# Test Evaluation Reports (TER) or DQSR A00# Test Readiness Review documentation (TRR)

A00# Hardware/Software list

3.2.2.3 Coordinate with EIDS to federate the TEP into the Enterprise Test Program and mitigate schedule discrepancies and conflicts with shared resources.

3.2.2.4 Develop a pre-production environment consistent with Agile SAFE methodologies of Continuous Integration/Continuous Delivery within the AWS GovCloud that supports the pre-production evaluation of HIA updates including but not limited to:

3.2.2.4.1 Development and preparation of operationally representative test data

3.2.2.4.2 System Test of updated systems using ephemeral resources

3.2.2.4.3 Pre-Production Environment contains cloned stacks or VPCs from the production environment to ensure operationally representative nature.

3.2.2.4.4 Pre-Production Environment is trusted and contributes to a continuous ATO.

3.2.2.4.5 Pre-Production Environment is afforded access to shared services, data, and tools typical of development including linting, testing frameworks, and SDKs that facilitate development.

3.2.2.4.6 Pre-Production Environment is described by an AWS well architected onboarding document described in the deliverables.

Deliverable: A00# Test and Evaluation Plan

A00# Test Report A00# Requirements and Verification Trace Matrix

3.2.3 Certification

The contractor shall provide objective evidence to support Records Management Certification of the technical solution facilitated by Joint Interoperability Test Command (JITC).

Deliverable: A00# Objective Evidence to support Records Management Certification

3.3 OPERATIONS AND SUSTAINMENT SUPPORT

The contractor shall provide support for the current production environment. In addition, the contractor shall support the preparation for project transition from system design and development including data extract transform, and load, to sustainment under the program management office. Execution of the Transition Readiness Review process and completion of the Transition Readiness Review Checklist.

Deliverable: A00# Product Support Strategy (PSS)

A00# Tech Refresh Plan A00# Life Cycle Management Plan (LCMP) or Service Management Plan (SMP)

3.3.1 Life-Cycle Sustainment Management

3.3.1.1 Product Support Management

3.3.1.1.1 The contractor shall provide Product Support Management, to include:

• Product Support Strategy

• Configuration Management

• Portfolio Transfer Planning and Transfer Execution

• Logistics Trade Studies

• Supportability Test and Evaluation

• Logistics Policy Implementation

• Product Support Business Case Analysis

• Product Support Business Model

• Affordability (should-cost and Key System Attributes [KSAs])

• Product Support Strategy Process Model implementation

• Alternative Sourcing

3.3.1.1.2 The contractor shall provide Supply Support, to include:

• Forecasting

• BOM management and maintenance

3.3.1.1.3 The contractor shall provide Maintenance Planning and Management support, to include:

• Reliability Centered Maintenance

• Maintenance Concept Design

• Maintenance Execution

• Operational Tempo (OPTEMPO) variance management

• Built-in and Manual Testability Management

3.3.1.2 Technical Management

3.3.1.2.1 The contractor shall provide Design Interface support, to include:

• Logistics Modeling & Simulation

• Reliability KSA

• Contractor-off-the-shelf (COTS) Integration

• Supportability Analysis

• Design Trades

• Net-centric capability management

• Standardization and interoperability

• Engineering data analysis, reliability, availability, maintainability design, deployability management, survivability and vulnerability management

• Affordability design

• Modular Open Systems Approach

• Sustainability

3.3.1.2.2 The contractor shall provide Sustaining Engineering support, to include:

• Continuous modernization

• Post-deployment operational data analysis

• Failure reporting analysis and corrective action system

• Service life extension program

• Modification management

• Time compliance technical orders engineering dispositions

• Retirement planning

• Deficiency reporting

• Engineering considerations

• Diminishing Manufacturing Sources and Material Shortages (DMSMS)

• Tech manuals and updates

• Tech Refresh planning

• Upgrade vs retire

3.3.1.2.3 The contractor shall provide Technical Data support, to include:

• Data Item Description management

• Data rights and IP strategy

• Data storage and backup

• Data verification and validation

• Proprietary data management

• Data delivery

• Engineering drawings management

• Technical manuals and standards management

• Specification determination

3.3.1.2.4 The contractor shall provide Computer Resources support, to include:

• Cyber, Electronic Data interchange management

• Service Level Agreement management

3.3.1.3 Infrastructure Management

3.3.1.3.1 The contractor shall provide Manpower and Personnel support, to include:

• Manpower for support at various tiers

• Manpower for Maintenance

• Manpower for Operation

• Strategic planning for personnel

3.3.1.3.2 The contractor shall provide Equipment Support, to include:

• Common Support Equipment required for sustainment such as Snowballs, or Out of band nonpersistent administration machines

• Tooling

• Test Program Set

• Automatic Test Systems

• Automatic Test equipment

• Maintenance concept integration

3.3.1.3.3 The contractor shall provide Training Support, to include:

• New Equipment Training

• Operator and maintenance training

• Train the trainer

• Training equipment

• Computer based training (CBT)

• Embedded training insertion

• Institutional training

• Sustainment training

3.4 TECHNICAL CAPABILITY

As a system, provide legacy data copy, data storage and the capability to make the data available for retrieval for the following systems:

• Composite Health Care System (CHCS)

• Clinical Information System (CIS aka Essentris – GDR and Non-GDR data)

• Anesthesia Reporting Monitoring Device (ARMD)

• Enterprise Blood Management System-Transfusion (EBMS-T)

• Armed Forces Health Longitudinal Technology Application (AHLTA)

In addition to the below high-level functional requirements (in section 4.4), requirements have been derived for AHLTA, EBMS-T and ARMD at the functional level and the lower implementation level.

Refer to Annex 1 RTM for details.

The contractor shall provide a solution that provides the following capabilities:

3.4.1 Retain all legacy data from source systems as well as storing the original healthcare data (within the MIP location) for long-term purposes of archival and retrieval as/when needed.

3.4.2 Ability to query legacy healthcare/Medical data for Business Intelligence, Research purposes, Analytics and Reporting, and Continuity of Care.

3.4.3 Ability to interface with existing Defense Health Activity (DHA) tools/systems for point of patient care (i.e., JLV, DMIX DES, Carepoint, Qlik, Tableau, Talend).

3.4.4 Allow for extraction of data from the proposed solution to be able to transfer as required externally with other systems and or organizations (i.e., the VA, Cerner), to include data governance for normalizing, cleansing, and standardizing the legacy data for retrieval and viewing purposes.

3.4.5 Integrate with and support MHS Cerner HealthEIntent capabilities using FHIR.

3.4.6 Define, develop, implement, and sustain the pre-production environment that enables:

3.4.6.1 The integrated team to: collaborate on the development of the legacy data solution within the

AWSgov Cloud

3.4.6.2 The integrated team to limit the blast radius of development affects on production

3.4.6.3 The integrated team to evolve the development pipeline towards a continuous integration/continuous delivery capable DEVSECOPS environment.

3.4.6.4 Future development teams to reuse the environment whether by cloning or direct reuse.

3.4.7 Data Copy

3.4.7.1 As a system, provide the capability to copy all data from MIP ODS data sources and transfer it to the vendor solution.

3.4.7.2 As a system, provide the capability to identify all the tables from MIP ODS data sources (internal

MIP or local military treatment facility [MTF]) that need to be copied and transferred to the vendor solution.

3.4.7.3 As a system, provide the capability to identify those tables from MIP ODS data sources that have been copied and transferred to the vendor solution.

3.4.7.4 As a system, provide the capability to identify those tables MIP ODS data sources that have not been copied and transferred to the vendor solution.

3.4.7.5 As a system, during the transfer process when an interruption occurs provide the capability to restart the process of copying and transferring data to the target from the point of the interruption.

3.4.7.6 As a system, provide the capability to seamlessly add legacy data to the initial set of legacy data stored in the vendor solution.

3.4.7.7 As a system, provide the capability to ingest legacy dental data from locations once the legacy systems are identified and evaluated.

3.4.8 Data Quality Engineering

3.4.8.1 As a system, provide the capability to verify that all the legacy data has been copied from all the required legacy data sources and transferred to the vendor solution with 100% accuracy.

3.4.8.2 As a system, provide the capability to VERIFY that the structure of the data copied and transferred to the vendor solution has remained unchanged from the structure of the data in all the legacy data sources.

3.4.8.3 As a system, provide tools that automate the comparative analysis of the source data to what is copied and transferred to the vendor solution.

3.4.8.4 As a system, provide the capability to log receiving, adding, updating, or deleting type errors encountered when copying and transferring data from all the legacy data sources to the vendor solution.

3.4.8.5 As a system, provide the capability to log when the copying and transferring of data from a legacy data source to the target has been completed for all legacy data sources.

3.4.8.6 As a system, provide the capability to log the number of records in each table contained in all the legacy data sources.

3.4.8.7 As a system, provide the capability to log the number of records copied from each table contained in all the legacy data sources and transferred to the vendor solution.

3.4.8.8 As a system, provide the capability to archive the various log records generated when copying data from all the required legacy data sources and transferring that data to the vendor solution?

3.4.8.9 As a system, provide the capability to periodically add more archived log records to the initial log record archive.

3.4.8.10 As a system, provide the capability to store archived log records indefinitely.

3.4.9 Data Copy Quality Analysis and Reporting

3.4.9.1 As a system, provide the capability to generate a report that displays the number of matching records ingested from MIP ODS.

3.4.9.2 As a system, provide the capability to generate a report that displays the errors encountered when copying and transferring data from all the legacy data sources to the vendor solution.

3.4.9.3 As a system, provide capability to perform quality checking of data transformed when copied to modernized ODS.

3.4.9.4 As a system, provide the capability to generate a report that displays all changes made to the to the source legacy data since the last time it was copied and transferred into the vendor solution.

3.4.10 Legacy Data Storage

3.4.10.1 As a system, provide a legacy data store with the capability for retention and disposition of the data based on the National Archives and Records Administration (NARA) schedule.

3.4.10.2 As a system, provide the capability to store all the legacy data that was copied and transferred from all the legacy data sources in a single relational database.

3.4.10.3 As a system, provide the capability to configure the Legacy Data Store to retain data that will not be accessed or retrieved on a regular basis in long term cold storage.

3.4.10.4 As a system, provide the capability to map data from a variety of data sources to a common data model. (Additional detail to be identified during requirement decomposition)

3.4.10.5 As a system, provide the capability to leverage tools that automatically map data from a variety of data sources to a common data model.

3.4.11 Stored Legacy Data Retrievability

3.4.11.1 As a system, provide the capability for analysis of the data using the original source system coded values to support the ‘Research, Analytics, and Reporting' Use Case.

3.4.11.2 As a system, provide the capability for analysis of the data using normalized terminology for coded values (i.e., SNOMED CT, ICD10, CPT, CCS, etc.) to support the ‘Research, Analytics, and Reporting' Use Case.

3.4.11.3 As a system, meet the existing site level performance metrics for the 'Research, Analytics, and Reporting' Use Case.

3.4.11.4 As a system, provide a DoD compliant User Interface (UI) capability to satisfy the 'Clinical Point of Care' Use Case.

3.4.11.5 As a system, provide the capability to consolidate data into a single longitudinal patient health record to support the 'Clinical Point of Care' Use Case.

3.4.11.6 As a system, provide the DoD compliant User Interface (UI) capabilities to satisfy the 'Legal

Medical Record and Regulatory Requirements' Use Case.

3.4.11.7 As a system, provide the capability within the data store to perform a strikethrough type function to data that has been officially deemed inaccurate instead of deleting it. Data Ark must have integration to upstream, downstream, and lateral MIP systems (ODS, JLV, ENT schema).

3.4.11.8 As a system, provide the capability for only those users authorized to freeze/lock patient records for legal purposes when required.

3.4.11.9 As a system, provide the capability to consolidate data into a complete legal medical record, to include all associated documents and images, so that it can be displayed as one single contiguous printable .pdf document to support the 'Legal Medical Record and Regulatory Requirements ' Use Case.

3.4.11.10 As a system, provide the capability to display the modifications that have been made to patient records when patient data is accessed from the legacy data store for both the 'Clinical Point of Care' and 'Legal Medical Record and Regulatory Requirements' Use Cases.

3.4.11.11 As a system, provide the capability to support the governance policies of the DHA/EIDS Organization for the management of legacy data.

3.4.11.12 As a system, there will be a data store based on a normalized relational data model.

3.4.11.13 As a system, the data model will have the appropriate constraints, either in the Relational Database Management System (RDBMS) or in the software, to ensure data integrity is preserved.

3.4.11.14 As a system, there will be a data store built on a standard healthcare/clinical data model.

3.4.11.15 As a system, the data model will be based on open standards/specifications.

3.4.11.16 As a system, provide a relational data model that allows for the ability to query the system using SQL and standard SQL database developer tools against all tables and associated data.

3.4.11.17 As a system, provide a relational data model that allows for the ability to query the system using data analytics tools (i.e., Tableau, Qlik, etc.) against all tables and associated data.

3.4.11.18 As a system, provide the capability for users with the appropriate permissions within the

EIDS organization to create stored procedures against the relational database.

3.4.11.19 As a system, provide the capability for systems within the MIP to access and execute stored procedures associated with the relational database.

3.4.11.20 As a system, provide the capability for the legacy data store to communicate data changes to upstream/downstream/lateral systems internal to the MIP.

3.4.12 Data Made Available to Other Systems (FHIR Services)

3.4.12.1 As a system, support the functionality to send data to other systems.

3.4.12.2 As a system, provide the capability to implement a web-based Application Programming

Interface (API) utilizing the Health Level Seven International (HL7) FHIR standard to integrate with the DMIX-DES.

3.4.12.3 Provide a FHIR based API solution that leverages and integrates with existing MHS

Information Platform (MIP) systems (e.g., Agile Core Services Data Access Layer (ACS-DAL), Enterprise Data Virtualization (EDV).

3.4.12.4 Provide an insensible FHIR based API framework that can be extended by other MHS

Information Platform (MIP) systems/programs as a MIP capability.

3.4.12.5 As a system, provide the capability to replace the GET_PATIENT_IMMUNIZATIONS stored procedure with a FHIR service.

3.4.12.6 As a system, provide the capability to replace the GET_PATIENT_NOTES_CDA (O) stored procedure with a FHIR service.

3.4.12.7 As a system, provide the capability to replace the GET_PATIENT_NOTES_CDA (C) stored procedure with a FHIR service.

3.4.12.8 As a system, provide the capability to replace the GET_PATIENT_NOTES_CDA (D) stored procedure with a FHIR service.

3.4.12.9 As a system, provide the capability to replace the GET_PATIENT_NOTES_CDA (P) stored procedure with a FHIR service.

3.4.12.10 As a system, provide the capability to replace the GET_LABORDER_LIST stored procedure with a FHIR service.

3.4.12.11 As a system, provide the capability to replace the GetRadClinicalImpression stored procedure with a FHIR service.

3.4.12.12 As a system, provide the capability to replace the

GET_RADIOLOGY_EXAM_LIST_RAD_NEW stored procedure with a FHIR service.

3.4.12.13 As a system, provide the capability to replace the GET_SNOMEDCODES stored procedure with a FHIR services.

3.4.12.14 As a system, provide the capability to replace the GET_SPECIMENS stored procedure with a FHIR service.

3.4.12.15 As a system, provide the capability to replace the GET_PDTS_ALLERGY_PROFILE stored procedure with a FHIR service.

3.4.12.16 As a system, provide the capability to replace the GET_PDTS_ALLERGY_PROFILE stored procedure with a FHIR service.

3.4.12.17 As a system, provide the capability to replace the GET_PAT_PRESCRIPTIONS stored procedure with a FHIR service.

3.4.12.18 As a system, provide the capability to replace the GetPrescriptionFills stored procedure with a FHIR service.

3.4.12.19 As a system, provide the capability to replace the

GET_PATIENT_PROBLEM_LIST_BYDATE stored procedure with a FHIR service.

3.4.12.20 As a system, provide the capability to replace the GET_PATIENT_PROCEDURES stored procedure with a FHIR service.

3.4.12.21 As a system, provide the capability to replace the GET_RAD_AMENDMENTS stored procedure with a FHIR service.

3.4.12.22 As a system, provide the capability to replace the GET_RAD_RESULTS stored procedure with a FHIR service.

3.4.12.23 As a system, provide the capability to replace the GET_SITE stored procedure with a FHIR service.

3.4.12.24 As a system, provide the capability to replace the GET_LABMICROBIOLOGY_RESULT stored procedure with a FHIR service.

3.4.12.25 As a system, provide the capability to replace the GET_LABMICRO_ORGSENSITIVITY stored procedure with a FHIR service.

3.4.12.26 As a system, provide the capability to replace the GET_LABMICRO_ORGANISMS stored procedure with a FHIR service.

3.4.12.27 As a system, provide the capability to replace the GET_LABCHEMISTRY_RESULT stored procedure with a FHIR service.

3.4.12.28 As a system, provide the capability to replace the GET_LAB_PATHOLOGY_RESULT stored procedure with a FHIR service.

3.4.12.29 As a system, provide the capability to replace the Essentris web service output with FHIR services.

3.4.12.30 As a system, meet the existing site level performance metrics with DMIX-DES interface access for the 'Clinical Point of Care' Use Case.

3.4.12.31 As a system, provide the capability to implement a web-based API utilizing the HL7 FHIR standard to integrate with the HealtheIntent system through the ACS-DAL of the MIP.

3.4.12.32 As a system, provide a FHIR based API solution that leverages/integrates with existing

MHS Information Platform (MIP) layers (P/L/D) as identified in the DHA Risk Management Framework (RMF) packages that support the MIP.

3.4.12.33 As a system, support the integration of the MIP with HealtheIntent to exchange near real time payloads via open standards and open specifications, using existing interfaces and exchange mediums to the greatest extent possible.

3.4.13 Patient Identity

3.4.13.1 As a system, leverage the Master Patient Index (MPI) contained in the Medical Information

Platform (MIP).

3.4.13.2 As a system, use master patient index when data ingested (IE: CHCS pt. with IEN that is already mapped).

3.4.13.3 As a system, receive updates from master patient index of identity changes and merges.

3.4.14 HIPAA and Privacy Act of 1976 Compliant

3.4.14.1 As a system, satisfy all applicable requirements as defined by Health Information Portability and Accountability Act of 1996 (HIPAA Act of 1996).

3.4.14.2 As a system, require users to be assigned roles to control access to functionality and data.

3.4.14.3 As a system, require users to log in to the DoD MHS IAS with their DoD CAC, VA PIV or

ECA certificate prior to accessing the vendor User Interface (UI).

3.4.14.4 As a system, provide the capability for only those users authorized, to make amendments or modifications to records for legal purposes as required.

3.4.14.5 As a system, when the Joint Legacy Viewer (JLV) is used to access legacy data for the

'Clinical Point of Care' Use Case, provide an audit log that displays, at a minimum, the PII/PHI data that was accessed, when it was accessed, the amount of time lapse for access, and who accessed it from the relational database.

3.4.14.6 As a system, when the vendor UI is used to access legacy data for the 'Legal Medical Record and Regulatory Requirements' Use Case, provide an audit log that displays, at a minimum, the PII/PHI data that was accessed, when it was accessed, the length of time the data was exposed / accessed, and who accessed it from the relational database.

3.4.14.7 As a system, when the vendor UI is used to modify legacy data for 'Legal Medical Record and Regulatory Requirements' Use Case, provide an audit log that displays the patient data that was modified, how it was modified, when it was modified, and who modified it in the relational database.

3.4.14.8 As a system, when data is accessed by a DBA, provide an audit log that displays, at a minimum, the PII/PHI data that was accessed, when it was accessed, the length of time the data was exposed / accessed, and who accessed it from the relational database.

3.4.14.9 As a system, when data is modified by a DBA, provide an audit log that displays the patient data that was modified, how it was modified, when it was modified, and who modified it in the relational database.

3.4.14.10 As a system, when changes to patient data occur due to system level processing or system to system interactions, provide an audit log that displays the data that was modified, how it was modified, when it was modified, and which system modified it in the relational database.

3.4.14.11 As a system, provide the capability to generate reports from user audit logs.

3.4.14.12 As a system, when the JLV is used for the 'Clinical Point of Care' Use Case, provide the

RBAC necessary to support the JLV's "Deny List" capability of granting access for VIP patient records to only those users authorized.

3.4.14.13 As a system, when the JLV is used for the 'Clinical Point of Care' Use Case, supply the information used to indicate SENSITIVE data, only as recorded in the source data, necessary for the JLV to prompt the user for acknowledgement and reason for access entries.

3.4.14.14 As a system, when the JLV is used to access SENSITIVE legacy data for the 'Clinical Point of Care' Use Case, provide an audit log that displays, at a minimum, the SENSITIVE data that was accessed, when it was accessed, the amount of time lapse for access, who accessed it, the user's acknowledgement of access, and the user's entered reason for access from the relational

3.4.14.15 As a system, when the vendor UI is used for the 'Legal Medical Record and Regulatory

Requirements' Use Case, provide the RBAC necessary to support a "Deny List" capability of granting access for VIP patient records to only those users authorized.

3.4.14.16 As a system, when the vendor UI is used for the 'Legal Medical Record and Regulatory

Requirements' Use Case, supply the information used to indicate SENSITIVE data, only as recorded in the source data, necessary for the UI to prompt the user for acknowledgement and reason for access entries.

3.4.14.17 As a system, when the vendor UI is used for the 'Legal Medical Record and Regulatory

Requirements' Use Case, provide an audit log that displays, at a minimum, the SENSITIVE data that was accessed, when it was accessed, the amount of time lapse for access, who accessed it, the user's acknowledgement of access, and the user's entered reason for access from the relational

3.4.15 Cyber Security

Cyber security efforts will require some personnel to be cleared at a Secret clearance level. A limited amount of personnel will be required to obtain and maintain a secret clearance.

3.4.15.1 As a system, satisfy ALL the integration requirements necessary for the Medical Information

Platform (MIP) to receive an ATO accreditation.

3.4.15.2 The contractor shall access The Secret Internet Protocol Router Network (SIPRNet) for cyber security incident response.

3.4.16 Data Conversion

3.4.16.1 The contractor shall support the conversion of paper files to digital records (i.e., Searchable

PDFs) as required by the government. The overall digitization of paper records and migration effort of that data shall ensure the accuracy and usability of patient data are preserved throughout the process. Data Conversion, Metadata Tagging, and Migration/Upload are key elements with Quality Assurance practices embedded end-to-end.

3.4.16.2 The contractor shall follow a phased process to execute sub-tasks of Retrieval, Preparation, Scanning, Quality Assurance, Data Validation, and Record Reconstruction & Return.

3.4.16.3 The contractor shall not assume that the paper records are static. As a result, the contractor shall ensure it captures any amendments to the paper record following its initial digitization.

3.4.16.4 The contractor shall conduct scanning of paper records in a manner that will not impact patient encounters or the updates of the relevant paper patient records.

3.4.16.5 The contractor shall ensure that the output of the scanning process is a Searchable PDF of

300DPI and meets all legacy data system data entry requirements.

3.4.16.6 The contractor shall ensure that Problems, Allergies, Medications, Procedures, and

Immunizations (PAMPI) data and NARA/legacy data system required metadata is captured utilizing OCR and Intelligent Document Processing tools and techniques. This data and metadata shall be validated to ensure 99% accuracy.

3.4.17 MIP Data Catalog

3.4.17.1 As a system, connect and ingest data using Talend Studio. By using Talend Studio, the connections to establish the LDCS section of the MIP Data Catalog will be stood up.

3.4.17.2 Provide metadata to the LDCS Data Sources and Data Elements. This could be in the form of a data dictionary. The following information should be included: data element description, refresh rate, format, etc.

3.4.18 Use Cases and Functionality

3.4.18.1 As a system, provide the functionality to support the following Use Cases:

• Research, Analytics, and Reporting

• Clinical Point of Care

• Legal Medical Record

• UI Access to/from other systems

3.4.18.2 Research, Analytics, and Reporting

MIP analytic capability should be fully leverage if possible. The expectation is for integration utilizing existing MIP business intelligence, analytics, and reporting tool set.

3.4.18.3 As a system, provide the integration to support the querying of all the required source data that has been copied, transferred, and consolidated into a relational database for research and analytics.

3.4.18.4 As a system, provide the integration to store data using native source element content for audit purposes and make it available for normalization purposes for population health, research, and other analytics needs using various methods.

3.4.19 Clinical Point Care

3.4.19.1 As a system, provide an intuitive vendor User Interface (UI), requiring minimal training for end users, to support the 'Clinical Point of Care' Use Case.

3.4.19.2 As a system, provide the capability to support RBAC limiting vendor UI functionality and access to data, as appropriate to the level of the authorized user, to include limitations to SENSITIVE data or records.

3.4.19.3 As a UI, provide the capability for a user to select and display the desired patient legacy data necessary for use when making medical treatment decisions in a clinical setting, all in one view regardless of source legacy system.

3.4.19.4 As a UI, provide a common look and feel for all pages.

3.4.19.5 As a UI, provide the capability to display the name of the source legacy system and site from which the data records being viewed were obtained.

3.4.19.6 As a UI, provide the capability for users to view both structured and unstructured data.

3.4.19.7 As a UI, provide the capability to retrieve the desired patient legacy data for viewing in five seconds or less.

3.4.20 Legal Medical Record

3.4.20.1 As a system, provide an intuitive vendor User Interface (UI), requiring minimal training for end users, to support the 'Legal Medical Record' Use Case.

3.4.20.2 As a system, provide the capability to support RBAC limiting vendor UI functionality and access to data, as appropriate to the level of the authorized user, to include limitations to SENSITIVE / VIP data or records.

3.4.20.3 As a system, provide the capability to grant temporary, limited vendor UI access for a specified user and to a specific patient record. i.e., Auditor.

3.4.20.4 As a vendor UI, provide the capability to produce a complete legal medical record using original content, in context, with no changes to data element values and to support an audit/compliance request from a state, federal, and/or legal perspective.

3.4.20.5 As a vendor UI, provide the capability to include all associated documents and images, as well as exclude information based on the specific release of information request.

3.4.20.6 As a vendor UI, provide the capability to consolidate the data content into one printable, .pdf document, regardless of data source and type, for a release of information request.

3.4.20.7 As a vendor UI, provide that capability to provide users various search parameters and filters to locate patient records.

3.4.20.8 As a vendor UI, provide the capability to lock patient records to prevent changes - AKA

“legal hold.”

3.4.20.9 As a vendor UI, provide the capability for authorized end users to add notes, addendums and perform strike through corrections - but in no case totally modify or delete patient record information.

3.4.20.10 As a vendor UI, provide the capability to generate information required in response to an audit.

3.4.20.11 As a vendor UI, provide the capability to send a completed Release of Information document electronically and via eFax.

3.4.20.12 As a vendor UI, provide the capability to track all request details and maintain a Release of

Information Audit log.

3.4.20.13 As a vendor UI, provide the capability to support purge requirements with required tracking and audits.

3.4.21 Access To/From Other Systems

3.4.21.1 As a vendor UI, provide the capability to access other existing DHA tools and systems, including MHS GENESIS, JLV, CarPoint, and other applications using a single sign-on method (Additional detail to be identified during requirement decomposition).

3.4.21.2 As a system, provide the capability for other existing DHA tools and systems, including

MHS GENESIS, JLV, CarePoint, and other applications to access the vendor UI using a single sign-on method. (additional detail to be identified during requirement decomposition).

3.4.21.3 As a vendor UI, provide the capability to access patient legacy data from MHS GENESIS using single sign-on and patient context methods. (additional detail to be identified during requirement decomposition).

3.4.22 Automated System Monitoring and Metrics Generation

3.4.22.1 System Monitoring

3.4.22.1.1 As a system, enable and support the integration of enterprise tools to integrate with enterprise monitoring and troubleshooting tools (i.e., SDD Topaz APM, App Dynamics integration, Splunk logging monitoring, Cloud Watch).

3.4.22.1.2 Support generation of metrics and statistics to support leadership decision making.

System Usage metrics based on configurable settings.

3.5 COMPLIANCE

The contractor shall conduct all activities needed to obtain and maintain the needed Authorization to Operate (ATO) for the HIA Production, Staging, Testing, and Development environments.

3.5.1 Compliance Requirements

3.5.1.1 The contractor shall implement security scans and remediations in accordance with the

National Institute of Standards and Technology (NIST) 800-53 by using the 18 security control families that address baselines for controls and safeguards for federal information systems and organizations.

3.5.1.2 Participate in the cybersecurity activities, review findings, and perform remediation actions from developmental, operational, and cybersecurity point of view throughout the system lifecycle.

3.5.1.3 Manage, maintain, and mitigate risks throughout the system lifecycle in accordance with cybersecurity operational requirements.

3.5.1.4 Use DHA approved tools to scan LDCS-HIA source code and analyze vulnerabilities of open-source libraries.

3.5.1.5 Remediate and fix any issues identified by the DHA approved tools.

3.5.1.6 Develop and issue Information Assurance (IA) reports that detail static analysis issues and LDCS-HIA library issues.

3.5.1.7 Attend RMF ATO schedule events, including the DHA Cybersecurity Independent Verification and Validation (IV&V) site visits, preparation for the self-assessment, Annual Review, and any post IV&V inquiries

3.5.1.8 Maintain an inventory of documentation of the applicable RMF controls, Security Requirements Guides (SRG), and Security Technical Implementation Guides (STIGs) that are required to achieve a full RMF ATO.

3.5.1.9 Perform AppSecDev assessment activities in a timely manner, ensure complaint, and provide evidence to the ISSO.

Deliverable: A00# ACAS Scans

A00# STIG checklist A00# Interconnection agreement template

4.0 INFORMATION TECHNOLOGY (IT) SERVICES REQUIREMENTS

4.1 INFORMATION TECHNOLOGY (IT) GENERAL REQUIREMENTS

The contractor shall adhere to the following requirements when the IT support services and/or supplies are applicable to the requirement:

4.1.1 Ensure that no production systems are operational on any research, development, test and evaluation (RDT&E) network.

4.1.2 Follow DoDI 8510.01 when deploying, integrating, and implementing IT capabilities.

4.1.3 Follow SECNAVINST 5239.3C and DoDI 8510.01 prior to integration and implementation of IT solutions or systems.

4.1.4 Register any contractor-owned or contractor-maintained IT systems utilized on contract in the Department of Defense IT Portfolio Registry (DITPR)-DON.

4.1.5 Ensure all IT products and services recommended, procured, and/or developed is compliant with Section 508 of the Rehabilitation Act of 1973, Title 36 Code of Federal Regulations Part 1194 – Electronic and Information Technology Accessibility Standards unless otherwise exempt in accordance with the latest regulation.

4.1.6 Only perform work specified within the limitations of the basic contract and task order, if applicable.

4.2 ACQUISITION OF COMMERCIAL SOFTWARE PRODUCTS, HARDWARE, AND

RELATED SERVICES

Contractors recommending or purchasing commercial software products, hardware, and related services that support DoD programs and projects shall ensure they recommend or procure items from approved sources in accordance with the latest DoD policies.

4.2.1 Enterprise Licensing Agreement/DoD Enterprise Software Initiative Program Contractors shall utilize DoD Enterprise Software Initiative (ESI) program as prescribed in DFARS Subpart 208.74 and Government-wide SmartBuy program (see DoD memo dtd 22 Dec 05). The contractor shall ensure any items purchased outside these programs have the required approved waivers as applicable to the program. The contractor shall purchase the following software and/or software license(s):

[delete table, if not applicable or if SW is specified in section 3.0]

Item # Description Unit/Issue Quantity L47232 Oracle Advanced Compression EA 4 L47232-S Oracle Advanced Compression - SULS EA 4

L101635 Oracle Secure Backup EA 4

L101634-S Oracle Secure Backup - SULS EA 4

NOTE: SW and/or SW licenses should be included in the IGE material list NOT the CAP list in Para 10.2.

Contractor-provided hardware is either CAP or CFP and not included in this table.

4.2.2 DoD Cybersecurity/Computer Security Requirements

The contractor shall ensure that all products recommended and/or procured that impact cybersecurity shall be selected from the National Information Assurance Partnership (NIAP) Validated Products List.

The contractor shall ensure the products chosen are based on the appropriate NIAP-approved Protection Profile (PP) for the network involved, and are utilized in accordance with latest Defense Information Systems Agency (DISA) policy. The contractor shall store all product information and have it available for Government review at any time.

4.3 CYBERSECURITY SUPPORT

Cybersecurity is the prevention of damage to, protection of, and restoration of computers, electronic communications systems, electronic communications services, wire communication, and electronic communication, including information contained therein, to ensure its availability, integrity, authentication, confidentiality, and nonrepudiation. Contractor personnel shall perform tasks to ensure applications, systems, and networks satisfy Federal/DoD/DHA cybersecurity requirements.

4.3.1 Cyber IT and Cybersecurity Personnel

4.3.1.1 The Cyberspace workforce elements addressed include contractors performing functions in designated Cyber IT positions and Cybersecurity positions. In accordance with DFARS 252.239-7001, DoDD 8140.01, SECNAVINST 5239.20A, and SECNAV M-5239.2, contractor personnel performing cybersecurity functions shall meet all cybersecurity training, certification, and tracking requirements as cited in DoD 8570.01-M and its subsequent replacement manual DoDM 8140 prior to accessing DoD information systems. Proposed contractor Cyber IT and cybersecurity personnel shall be appropriately qualified prior to the start of the contract performance period or before assignment to the contract during the course of the performance period.

4.3.1.2 Contractors that access DHA IT shall complete a System Authorization Access Request (SAAR) form as documented in Para 8.2.2.4(b).

4.3.1.3 Contractor personnel with privileged access shall have a favorably adjudicated Tier 5 (or DoD equivalent) background investigation in accordance with SECNAVINST 5510.30C and acknowledge special responsibilities with a Privileged Access Agreement (PAA) in accordance with

SECNAVINST 5239.20A.

4.3.2 Design, Integration, Configuration or Installation of Hardware and Software The contractor shall ensure any equipment/system installed or integrated into DHA platform will meet the cybersecurity requirements as specified under DoDI 8500.01. The contractor shall ensure that any design change, integration change, configuration change, or installation of hardware and software is in accordance with established DoD/DON/DHA cyber directives and does not violate the terms and conditions of the accreditation/authorization issued by the appropriate Accreditation/ Authorization official. Use of blacklisted software is specifically prohibited and only software that is registered in DOD Information Technology Portfolio Repository (DITPR) and is Functional Area Manager (FAM) approved can be used as documented in Para 4.2 when applicable.

4.3.3 Cybersecurity Workforce (CSWF) Report

Pursuant to DFARS 252.239-7001, the contractor shall identify cybersecurity personnel, also known as CSWF and Cyber IT workforce…