IHSC eHR Modernization DRAFT RFI PWS July 2025.docx

Department of Homeland Security (DHS) – U.S. Immigration and Customs Enforcement (USICE) - EHR Modernization

U.S. Immigration and Customs Enforcement (ICE)

ICE Electronic Health Records (EHR)

DRAFT

Performance Work Statement (PWS)

Office of the Chief Information Officer (OCIO)

July 2025 Washington, DC

Procurement Sensitive. This document is confidential and intended solely for the use and information of the company to whom it is addressed.

Requirements Document 1.0 i

Contents

Department of Homeland Security (DHS) – U.S. Immigration and Customs Enforcement (USICE) - EHR Modernization i

1.0 General

1.1 Background

The Department of Homeland Security (DHS) Immigration and Customs Enforcement (ICE) Office of Enforcement and Removal Operations (ERO) enforces the nation’s immigration laws. ERO identifies and apprehends removable aliens, detains those individuals when necessary and removes aliens from the United States. In fulfilling this mission, ERO is concerned with the wellbeing of the thousands of Undocumented aliens who are processed through its detention facilities each year.

ICE Health Service Corps (IHSC) serves as the health authority for ICE/ERO on all matters related to alien health care. ICE/ERO/IHSC healthcare includes several distinct activities and services required by DHS to support the enforcement of immigration law and maintain national security. In fiscal year 2024, IHSC administered and managed a health care system that provided direct care to more than 131,000 aliens housed at 18 IHSC-staffed facilities across the nation. The health care provided by U.S Public Health Service officers, General Schedule Civil Servants, and contracted medical professional includes medical, dental, mental health care, as well as public health and disease prevention programs. In fiscal year 2023, IHSC also oversaw compliance with ICE detention standards related to health care for more than 191,500 detained aliens housed in 128 non-IHSC-staffed facilities, totaling more than 41,500 beds.

IHSC utilizes an electronic health record (EHR) to increase operational efficiency, enhance reporting capabilities, and improve the quality of alien health care. The ICE Office of the Chief Information Officer (OCIO) leads the program management and execution for the IHSC information technology (IT) suite of products. The current EHR suite of products is comprised of eClinicalWorks (eCW), Fusion Health KALOS CIPS™ Correctional Institution Pharmacy Software, Fusion Health sMARt Medication Administration Record Technology software, eCW Dental Software (for charting), ICE Radiology Software and Repository (for imaging) and Medical Payment Authorization Request (MedPAR2) software (approximately 800 users).

This PWS includes a request for an integrated, multi-module correctional EHR, pharmacy, medication administration record, dental, and referral management, utilization management, claims management, medical payment software also known as the EHR system. The vendor must assess if the proposed system will be able to provide a holistic integrated solution encompassing all the functionality of the current EHR subsystems. If it is assessed that the proposed system will not be able to provide the functionality of any of the current individual EHR subsystems, the vendor’s EHR must interface with those current and future versions of the individual subsystems to maintain the desired functionality. The vendor’s proposed solution will be certified by the Office of the National Coordinator for Health Information Technology (ONC-HIT). If it is not ONC-HIT certified, the vendor shall obtain certification within one year of implementation.

1.2 Scope of Work

The scope of this PWS is to acquire, customize, implement, and deploy an integrated, multi-modal correctional EHR that shall interface with required ICE component interfaces. The vendor’s proposed solution shall include the following EHR functionalities, support, and services below and those detailed in Section 3 of the PWS:

· Pharmacy capability that shall support pharmacists, providers, and pharmacy staff members to process prescriptions in-house and remotely for IHSC patients,

· Medication administration record,

· Dental capabilities, including radiology technology that shall support the scope of practice for dentists, dental hygienists, and dental assistants,

· Referral management/medical payment software, and

· Reporting capabilities.

If the vendor must develop or maintain custom software for IHSC then the vendor shall follow the ICE Agile Software Development framework. The vendor shall provide Tier II/III Software Support Services to provide the full range of software development, technical and project management services required to develop, implement, integrate, deploy, train IHSC, as well as support and sustain the correctional multi-module system.

1.3 Objective

The objective of this effort includes acquisition, customization, implementation, integration, and deployment of an EHR system; the supplying of associated software licenses; conducting EHR end-user training, and perform the necessary Tier II/III support, and Operations and Maintenance support for the contractor’s proposed EHR solution to include pharmacy, medication administration record, dental, referral management utilization management, claims management/medical payment software, and reporting capabilities. The contractor’s system must support the correctional medical health care environment to meet the needs of IHSC and to ensure high quality health care for detained aliens. The contractor shall comply with IHSC, ICE, and DHS directives and policies as written, and national correctional accreditation directives and polices, where applicable to the EHR, to ensure it conforms to the appropriate standards and requirements.

2.0 Applicable Policies and Standards

2.1 ICE Policies and Standards

The Contractor shall comply with the latest version of all technology standards and architecture policies, processes, and procedures applicable to the ICE IT environment. These publications are available on request and include, but are not limited to, the following:

· 21st Century Cures Act, 34 H.R. § Section 4001; 4002(a); 4003(b); 4003(e); 4004.

· Sensitive Systems Directive 4300A version 13.3, Feb 13, 2023

· DHS National Security Systems Policy Directive 4300B, Version 10.1, November 21, 2018

· DHS MD 4010.2 (DRAFT), Section 508 Program Management Office & Electronic and Information Technology Accessibility

· DHS Management Directive (MD) 4300, IT Systems Security Publication

· DHS MD 4010.2, Section 508 Program Management Office & Electronic and Information Technology Accessibility.

· DHS Policy Statement 103-04 – Adoption of the National Information Exchange Model within the Department of Homeland Security dated May 3, 2019.

· DHS Systems Engineering Life Cycle Guidebook

· Federal Information Processing Standards Publication 199

· ICE Technical Reference Model

· ICE Application Security Cyber Security Standard (CSS)

· ICE Architecture Test and Evaluation Plan

· ICE Cybersecurity Standards

· ICE Enterprise Systems Assurance Plan

· ICE System Lifecycle Management (SLM) Handbook

· ICE AGILE DEVELOPMENT FRAMEWORK

· DHS Agile Guidebook (Draft 20201231)

· DHS Instruction Number:102-01-004, “Agile Development and Delivery for Information Technology”

· ICE Web Standards and Guidelines

· National Institute of Standards and Technology (NIST) Computer Security Resources Center (CSRC) standards, guidelines, and special publications

· Privacy Act of 1974

· Rehabilitation Act, 29 U.S.C. 794d, Section 508 1194.2.

· The ICE Agile Development Framework: for planning and implementing solutions using Agile best practices.

· FAR 52.224-3 Privacy Training – Alternate I (see FAR Class Deviation 17-03, Revision 1)

· HSAR 3052.204-71 Contractor Employee Access (July 2023)

· HSAR 3052.204-71 Contractor Employee Access Alt I (July 2023)

· HSAR 3052.204-71 Contractor Employee Access Alt II (July 2023)

· HSAR 3052.204-72 Safeguarding of Controlled Unclassified Information (July 2023)

· HSAR 3052.204-72 Safeguarding of Controlled Unclassified Information Alt I (July 2023)

· HSAR 3052.204-73 Notification and Credit Monitoring Requirements for Personally Identifiable Information Incidents

· Special Clause Information Technology Security Awareness Training (see HSAR Class Deviation 15-01, Revision 1) Further, the Contractor shall comply with the following Homeland Security Enterprise and ICE Architecture requirements:

· All IT hardware or software shall be complaint with the Homeland Security Enterprise Architecture (HLSEA) and ICE Technical Reference Model (TRM) Standards and Products Profile.

· All encryptions shall be FIPS 197 Advanced Encryption Standard (AES) that has been Federal Information Processing Standards (FIPS) 140-2 certified.

· All data assets, information exchanges, and data standards, whether adopted or developed, shall be submitted to the DHS Enterprise Data Management Office (EDMO) for review and insertion into the DHS Data Reference Model.

· In compliance with Office of Management and Budget (OMB) mandate, all network hardware shall be Internet Protocol version 6 (IPv6) compatible without modification, upgrade, or replacement.

The Contractor shall not deviate from the SLM process without express approval granted by the Contracting Officer’s Representative (COR).

2.2 DHS Enterprise Architecture Compliance

All solutions and services shall meet DHS Enterprise Architecture (EA) policies, standards, and procedures. Specifically, the contractor shall comply with the following Homeland Security (HLS) EA requirements:

· All developed solutions and requirements shall be compliant with the HLS EA.

· All IT hardware and software shall be compliant with the HLS EA Technical Reference Model (TRM) Standards and Products Profile.

· Description information for all data assets, information exchanges and data standards, whether adopted or developed, shall be submitted to the Enterprise Data Management Office (EDMO) for review, approval and insertion into the DHS Data Reference Model and Enterprise Architecture Information Repository.

· Development of data assets, information exchanges and data standards shall comply with the DHS Enterprise Data Management Policy Directive 103-01 and all data-related artifacts shall be developed and validated according to DHS data management architectural guidelines.

· Applicability of Internet Protocol Version 6 (IPv6) to DHS-related components (networks, infrastructure, and applications) specific to individual acquisitions shall be in accordance with the DHS Enterprise Architecture (per OMB Memorandum M-05-22, August 2, 2005) regardless of whether the acquisition is for modification, upgrade, or replacement. All EA-related component acquisitions shall be IPv6 compliant as defined in the U.S. Government Version 6 (USGv6) Profile (National Institute of Standards and Technology (NIST) Special Publication 500-267) and the corresponding declarations of conformance defined in the USGv6 Test Program.

2.3 ICE Application Architecture Compliance

The Contractor shall ensure that the application is designed and developed for browser independence, i.e., the application shall generally work with any of the major browsers. ICE browsers are configured with numerous Group Policy Objects (GPOs) and centrally managed security policies. Web Applications should be designed utilizing a responsive web design (RWD) approach, to provide an optimal viewing and interaction experience, independent of the particular platform capabilities the end user is utilizing. If ICE OCIO upgrades to a newer browser version, the contractor shall ensure the application is compatible with the future version.

2.4 Open-Source Compliance

· The Contractor shall follow the ICE Open-Source Manifesto when evaluating any technologies, tools, software, and/or application programmable interfaces (API’s) to support a system.

· The Contractor shall prioritize the adoption of, and migration to, Open-Source technologies over proprietary or “closed” technologies.

2.5 Lean-Agile-DevOpsSec Compliance

· All systems development and maintenance projects shall be compliant with ICE OCIO Management Instruction (MI) 001 “Applying Lean-Agile-DevOpsSec Principles at ICE.”

· The Contractor shall store and manage all system configuration settings and documentation in the ICE Approved Software Configuration Management (SCM) system, currently GitHub Enterprise.

· The Contractor shall document operational tasks and Standard Operating Procedures (SOPs) in an ICE Approved knowledge management portal, currently ELMS and/or Confluence.

· The Contractor shall leverage an ICE provided automation toolchain (currently CloudBees Jenkins based) to reduce, if not outright eliminate, the number of manual tasks performed during operations. This includes recurring tasks, scheduled jobs, monitoring, updates, patching, user maintenance, and other operational tasks.

· The Contractor shall perform sufficient[footnoteRef:2] static code analysis in the areas of reliability, security, maintainability, test coverage, and duplication has been performed and is available for review in the ICE Approved Quality Assurance Dashboard (currently SonarQube). [2: “Sufficient” is a moving metric that is expected to improve with time.]

· The Contractor shall leverage automation tools to reduce the number of manual tasks performed during the development lifecycle. This includes the test automation (Unit, Functional, Integration, Performance, and Security), build automation, continuous integration, and continuous development.

2.5.1 Associated Deliverables

· The contractor shall adhere to the ICE Agile System Lifecycle Management (SLM) Process and complete the activities and deliverables identified in the Project Tailoring Plan as the EHR is a DHS Level III Acquisition Program with oversight from the Component Acquisition Executive(CAE),

· The Contractor shall participate in an Agile Maturity Assessment facilitated each fiscal quarter by an ICE assigned Agile Coach. A self-assessment may be performed in lieu of a facilitated assessment following the establishment of a high maturity level and approval of the government program manager.

2.6 Medical and Detention Policy and Standards

The Contractor shall comply with the latest version of all medical and detention standards, policies, processes, procedures, and communication protocols for clinical and administrative health data, applicable to IHSC and the immigration detention environment.

These publications include, but are not limited to, the following:

· American Corrections Association (ACA)

· National Commission on Correctional Health Care (NCCHC)

· Performance Based National Detention Standards (PBNDS)

· Health Level Seven (HL7)

· Clinical Document Architecture (CDA)

· Fast healthcare Interoperability Resources (FHIR)

· United States Core Data for Interoperability (USCDI)

· Digital Imaging and Communications (DICOM)

3.0 Specific Product Description and tasks

3.1 EHR Functionalities

The Contractor shall deliver an integrated multi-module correctional EHR, pharmacy, medication administration record, dental, referral management, utilization management, claims management, and medical payment software, enabled to interface with existing and future systems, and provides all mandatory functionality as identified in this PWS and attachments. If any IHSC mandatory functionality is not currently implemented in the EHR product(s), the Contractor shall modify their EHR product(s) or propose a solution to meet the mandatory requirement.

The Contractor shall deliver an EHR system which provides the desired functionality that is required in the EHR product(s) as identified in Attachments 1, 2, and 3 to this PWS; EHR Required Functionality. The contractor’s EHR software must have required functionalities to meet the needs of the unique environment of immigration detention. The following lists a brief synopsis of high-level functional requirements from IHSC for the EHR.

3.1.1 Administrative Category

3.1.1.1 Data and Quality Analytics: The system will provide the functionality to customize fields and create field constraints when appropriate facilitating the capture of clean, streamlined data. All data fields captured in the EHR and data field logs must be exportable for reporting purposes to allow tracking for all of IHSC’s key indicator metrics (e.g., population, diagnoses, encounters, chronic conditions) including metrics specific to an institutional setting. The system must allow near-real time data retrievability at minimum, and ability to create customized reports. A list of current reports is available in Attachment 4. In addition, IHSC anticipates on average 22 new reports and 72 revised reports per year. Full access to the database, database relational diagrams (Deliverable 31) and data dictionary (Deliverable 32) must be provided to IHSC database administrators to ensure full access to export data and interface with IHSC-specified visualization and analytical software. The system shall allow the ability to customize and view real-time, consolidated IHSC patient care performance measure data and metrics within the EHR system.

3.1.1.2 Health Information Management: The system shall acquire, analyze, and protect digital and traditional medical information and records vital to providing quality patient care to the IHSC patient population and supports: Freedom of Information Act (FOIA), Health Insurance Portability and Accountability (HIPAA), Privacy Act, and Systems of Record Notices (SORN).

3.1.1.3 Managed Care: The system shall support the collaboration between IHSC providers, in-house specialists, nursing, behavioral health, and dental in assessment, planning, facilitation and advocacy for options and services to meet a patient’s health needs through communication and available processes, tools, and applications to provide care. The system will support IHSC by providing a referral management system for patients held at IHSC and non-IHSC facilities, to manage authorizations, billing, payments, and transfer of care. The system must interface with Veteran’s Affairs Financial Service Center (VAFSC) billing services, VA Adjudication System, and clinical guidelines (currently, MCG CareWeb QI).

3.1.1.4 Medical Coding and Billing: The system will support reimbursement processes including, but not limited to, transmission of authorizations to the VA Adjudication System, providing end-to-end care.

3.1.1.5 Scheduling: The system shall support the planning and booking of all necessary resources associated with the diagnosis, treatment and care management of the patient to include, but not limited to appointment scheduling, auto scheduling based off selected criteria, ability to access entire clinic schedule by IHSC selected criteria, and support of accountability for patient location in clinic.

3.1.2 Clinical Category

3.1.2.1 All: The system shall support documentation of patient visits and in-office procedures, the reviewing of test results, modification of patient problem lists, medication lists, special needs, care coordination, scheduling of patient appointments, and other clinical requirements that encompass aspects of clinical care that may pertain to all disciplines and roles.

3.1.2.2 APPs/MDs/Medical Assistants: The system shall support the scope of medical practice including Medical Doctors (MD), Doctors of Osteopath (DO), Advanced Practice Provider (APP), and medical assistants as applicable to their licensure and IHSC policy.

3.1.2.3 Consultants or Telehealth: The system shall support communication, visualization, and documentation of specialty services beyond the on-site medical, behavioral health, and dental care provided for detainees, to include out of facility specialty services and consultations. The system shall support IHSC Clinical Specialty Care utilizing telehealth technologies to perform assessment, diagnosis, treatment, consultation, and continuity of care.

3.1.2.4 Decision Support: The system shall support the use of algorithms and artificial intelligence while charting that help generate treatments, alerts, and diagnoses.

3.1.2.5 Dental: The system shall support the scope of practice of individuals in dental practice, including dentist, hygienist, and dental assistants as applicable to their licensure and IHSC policy. This includes radiology technology unique to dental services.

3.1.2.6 Discharge: The system shall support the action to transfer the patient from one facility to another or completely release a patient from ICE custody. The system shall support the actions of cancelling future appointments, orders, labs, procedures, and medications with one process and/or convert appointments to transfer location for continuity of care.

3.1.2.7 Encounters: The system shall support any patient care interaction that requires documentation.

3.1.2.8 Intake: The system shall support the process of ensuring patients are inputted into the IHSC EHR, screened, and processed per PBNDS standards and IHSC policy and directives.

3.1.2.9 Medical Housing Unit: The system shall support the documentation of patient acuity, patient location, policies, managerial standpoint, 24-hour care (24-hour chart review, daily updates of orders, nursing rounds, and continuous monitoring of vital signs), and IHSC’s infirmary requirements.

3.1.2.10 Mental/Behavioral Health: The system shall support work within the scope of practice of behavioral health providers (BHP) including LCSW, PsyD, MS, PhD, applicable to their licensure and IHSC policy to include suicide risk assessment, chronic/significantly mentally ill follow-ups, AIMs testing, and other psychological test per BHP discipline standards and IHSC behavioral health guidelines.

3.1.2.11 Mobile Care/Remote: The system shall support any patient care provided outside of the main facility clinic, typically not at a stationary desk to include IHSC’s special operations, care in dormitories, special housing unit care, sally port, intake, and discharge areas. The system shall support the use of the EHR outside of the clinic or facility to include VPN, WPaaS, and SASE access frameworks.

3.1.2.12 Nursing: The system shall support work within the scope of practice of medical assistants and nursing staff as applicable to their licensure and IHSC policy to include IHSC nursing guidelines, nursing procedures, screenings, and nursing specialty encounters.

3.1.2.13 Orders: The system shall support instructions (orders) from an APP/MD/BHP/Dentist delegated to nursing/dental hygienist/dental assistants/medical assistants to provide care to patients to include MHU admission/updates/discharge orders, chronic care diagnoses order sets, labs, radiology, procedures, medications, verbal, and telephone orders, standing orders for protocols, and special need orders. The nursing staff shall have the ability to submit specified orders under the direct order of a provider or nursing guidelines. The system shall support electronic transmission of controlled and non-controlled substance medication orders as prescribed by licensed prescriber (Physician/APP/Dentist/Clinical Pharmacist).

3.1.2.14 Pharmacy: The system shall support pharmacists, providers, and staff members to process electronically prescribed controlled and non-controlled substances in-house and remotely for IHSC patients to include prescription filling, interaction alerts, and verification capabilities.

3.1.2.15 Pill Line Management: The system shall support processes and actions to administer medication to patients in custody to include medication verification, identification of patient and medication, administration documentation, assignment of location of patient and medication storage, and ability to interact with pharmacy software and orders in a patient medical record.

3.1.2.16 Radiology: The system shall support medical imaging to diagnose diseases and guide their treatment. The EHR software shall interface to vendor’s in-house equipment and remote software for the ability of radiologists outside of the IHSC network to interpret radiographic images. The EHR and external vendor radiology software shall allow in-house viewing of radiography information and images by IHSC providers.

3.1.3 Technical Category

3.1.3.1 Database Requirement and Integration: The system shall support IHSC’s database requirements to include scalability, storage capability, sort ability, translate interoperability, SQL Criteria, HL7, export and import, and reoccurring or batch data. The system shall support the seamless integration of medical records to be accessed across electronic software solutions to include Cloud based services which includes the IHSC incident reporting systems, Enforcement Integrated Database, Tableau, documentation integrity, and off-site database. The vendor shall conduct, and the new EHR system shall support comprehensive data migration which will allow essential patient health record information and supporting patient data to be transferred from the legacy system(s) to the new EHR system in structured data fields when required.

3.1.3.2 Devices and Hardware: The system shall support the use of tablets, laptops, cameras and other telehealth equipment, digital stethoscopes, cardiac monitor, printer, docking station, PIV card readers, and other equipment as indicated by IHSC.

3.1.3.3 Electronic Health Record General: The system shall support the use of barcode scanning for patient identification and medication administration. E-signatures, e-documents, and completion of forms via signature pads or electronic screens.

3.1.3.4 General System Requirements: The system shall support IHSC software components and be aligned with DHS and ICE system architecture and policies as appropriate for system deployment, system interconnectivity, and hardware connectivity.

3.1.3.5 Interfacing, Interoperability, and Standards Compliance: The system shall support the interface of devices or software that allow interaction with the EHR, interoperability of systems and software to exchange data.

3.1.3.6 Performance/Reliability: Refer to the Quality Assurance Surveillance Plan.

3.1.3.7 Remote and Offline Capability: The system shall support the use of the EHR outside of the clinic or facility to include VPN, WPaaS, and SASE access frameworks. The system shall permit documentation offline and sync to appropriate medical record(s) when connectivity is restored. The system shall also support the use of the EHR when there is no or slow internet connection. The system shall allow immediate synchronization of offline information to the central storage upon establishment of secure internet connectivity as well as ensure the offline capability adheres to all security controls while in offline mode.

3.1.3.8 Roles and Access Management: The system shall support the management of access rights of individuals utilizing the EHR by granting and preventing access, specific administrative privileges, credentialing, level of access granted, and termination of access.

3.1.3.9 Security: The system shall support security measures to include system authentication user details (person accessing data) (Personal Identity Verification), purpose of use (why they are using), secure communication (provider-to-server and server-to-server), and breach of data reporting and procedure.

3.1.3.10 Systems Upgrades and Enhancements: The system shall provide upgrades, including patches, and enhancements as necessary for IHSC to utilize the system and/or address technological issues, to include those associated with patient safety.

3.2 EHR Customization and Integration of Multi-Module EHR

The contractor shall provide customization of the EHR software module to meet the functional and business requirements of IHSC’s correctional environment ensuring Performance Based National Detention Standards (PBNDS) are met prior to deployment of the software. When the contractor assesses the list of customizations requested by IHSC based off IHSC’s submitted RTM (see Attachments 1, 2, and 3) during the initial development, the contractor shall provide an estimated time when all specific items shall be deployed. Modifications requested by IHSC to meet the functional and business requirements, shall not be considered a customization due to the Contractor failing to meet the requested requirements.

3.3 EHR Enterprise Software Licenses

The contractor shall provide all applicable software licenses, for approximately 1,600 users, 500 concurrent users, in accordance with all clauses, identifications and assertions, terms, and conditions related to commercial and non-commercial technical data, computer software, and computer software documentation to support the configuration, integration, custom development, test, software management, training, deployment, and end-user usage of the contractor’s EHR solution.

If identified in an applicable Task Order, the Government shall receive Unlimited Rights to intellectual property first produced and delivered in the performance of this contract IAW FAR 52.227-14, Rights in Data-General (DEC 2007). This includes all rights to source code and all documentation created in support thereof. For sake of clarity, this does not include minor modifications made to Contractor’s Commercial Computer Software.

3.4 Interfaces and Data Sources Support

The Contractor shall support the ability of the integrated multi-module EHR system to connect and exchange data with all interfaces that feed into and out of the EHR components. The contractor shall provide ability to securely and reliably transmit health records and related data in near real time to the Office of Health Security (OHS) Medical Information eXchange (MIX) systems, using techniques and technologies acceptable to OHS, such as, for example, SFTP servers, RESTful APIs, HL7 vs messaging, and/or FHIR messaging.

The term “interface” also includes communication between EHR and other sources using web services. The Contractor shall provide on-going support, and provide enhancements as appropriate, for all interfaces that provide data to various EHR component and reports.

While eCW Dental is listed as a current dental module, the Contractor shall propose an alternative dental solution since eCW Dental will not be sustained.

See Table 1 below for current interfaces and data sources:

Table 1: EHR Current Interface & Data Exchange Information

Appointment date is passed back to MedPARv2 to notify the end-user of the MedPAR status. Cancellations in EHR or MedPARv2 send automated cancellation notification to end-user. Status changes in EHR should also occur in MedPARv2 and vice versa.

3.5 Applications Maintenance

The contractor shall provide application maintenance which includes the following:

· Perform user account set-up and management.

· Develop templates and enhance/modify workflows.

· Produce and develop reports.

· Plan and install product upgrades.

· Maintain and develop application system documentation (including SELC documents), as necessary.

· Manage application change request and problem resolution process.

· Develop and maintain a configuration management process, while adhering to ICE configuration management policies and procedures

· Provide end-user training, updates to end-user training material including, but not limited to end-user manual and job-aids and 508 compliant computer based trainings.

· Perform quality assurance testing.

· Perform application code testing.

· Track performance and provide end-to-end application and transaction monitoring of IHSC applications.

3.6 Software Tools

The Contractor shall use the Government-provided virtual environment including development workstations, development integration, testing and production. The Contractor shall support the Government in the stand-up of the environments including application specific software components, as well as application specific infrastructure implementations, such as load balancing. The Contractor shall be responsible for shake-out and validation of each environment.

The Contractor shall use the Government-provided Product Backlog Repository and defect management tool, currently JIRA, to track user story and task progress.

The Contractor shall use the Government-provided help desk ticketing system, currently ServiceNow, to track help desk tickets.

The Contractor shall use the Government-provided Source Code Version Management tool, currently GitHub, for version control of the code base.

The Contractor shall use the Government-provided Continuous Integration (CI) toolset, currently CloudBees, for automated builds and deployments to all environments.

The Contractor shall use a government approved industry standard unit testing library, currently JUnit, to execute all unit tests. The Contractor shall use the Government-provided code coverage toolset to report on unit testing code coverage. The unit testing and code coverage toolset is integrated with the CI toolset to provide reports on unit testing. The Contractor shall ensure that required integration points with the developed code base shall be supported in order to enable the reports in the CI toolset.

The Contractor shall use the Government-provided static code analysis tools, currently SonarQube, and integrate the execution of the analysis with the CI toolset for automated execution and reporting of results.

The Contractor shall perform code peer reviews and document the results via an electronic medium, such as a Confluence, JIRA, or using a Government-provided tool if available.

The Contractor shall develop automated test cases using an industry standard automated functional testing toolset, currently Selenium. An automated test case suite shall be maintained and executed on a regular basis, at least weekly. The automated testing toolset shall be integrated with the CI toolset to allow for automated scheduled execution and results reporting.

The Contractor shall support the full lifecycle of integration testing with interface partners, including test planning, test script creation, data staging, test execution, troubleshooting, and test result reporting.

The Contractor shall support performance testing of the application. The Government is responsible for performance test creation and execution. The Contractor shall work to resolve defects and/or performance issues that are identified during performance test execution.

The Contractor shall prepare an annual ranking of dependencies (libraries) that should be upgraded or replaced.

3.7 Program Management and Technical Oversight

The Program Management and Technical Oversight task includes the oversight of the execution of requirements analysis, code development, testing, configuration, deployment, administration, monitoring, and maintenance of the EHR solution. The Contractor shall provide integrated program management support, including personnel management, program reporting and cost management, technical risk and issue management, and technical system documentation. The Contractor shall provide a release planning team that works closely with the Government program manager to ensure streamlined, effective, and productive communications and work products. The Contractor shall ensure all contractor personnel and subcontractors adhere to the Department security policies, directives, and guidance. The Contractor shall provide deliverables identified in Section 11 of the PWS as well as deliverables as mandated by Section 2, 3, 6, 14, 15, 16 and Appendix B through J of this PWS.

The Contractor shall use Agile Scrum development methodology. The Contractor shall be primarily concerned with the implementation cycle, which in the case of Scrum includes sprint planning, application design, development and testing, deployment, sprint review, and sprint retrospective. The requirements for the EHR system are divided into user stories using an Agile system development methodology and the Scrum Framework.

The Contractor shall provide a scrum master that leads and manages multiple sprints and their associated releases. The scrum master shall provide management and oversight of the activities associated with sprint completion including:

· Creating user stories

· Developing automated test scripts

· Creating architecture design documents

· Writing software code components

· Creating/updating/running manual and automated unit tests

· Creating/updating/running manual and automated functional qualification tests

· Creating/updating/running automated regression tests

· Supporting performance testing

· Conducting code review

· Updating master installation documents

· Delivering and deploying code with automated build and deployment capability

· Managing databases and associated design documents

· Monitoring integration tests The user acceptance criteria are based on the user stories mutually agreed upon by the Product Owner, Government Project Managers, and the Scrum Team. In addition, the Contractor shall be responsible for delivering the system documentation artifacts that contain business and technical information. The Contractor shall provide frequent updates to the ICE issue and project tracking tool (technical tasks, blockers, dependencies, story points, issue tracking). The Contractor shall provide system documentation artifacts at each release unless a request for deviation has exempted them.

The Contractor shall follow the DevOps software engineering practice of Continuous Integration and Continuous Delivery (CI/CD) for all releases.

3.8 Requirements Analysis and Code Development

The Contractor shall resolve existing bugs and system issues as determined by the Government. Using the information from the service desk tickets or other source issue documentation (e.g., JIRA), the Contractor shall review the business’ requirements and develop technical requirements/tasks accordingly. The Contractor shall document constraints and dependencies and determine the level of effort to complete development of the requirements using story points. The Contractor shall provide tools, graphics, and user interfaces that allow requirements analysis discussions with the business which demonstrate a clear understanding of business requirements and options for system implementation.

3.9 Testing

The Contractor shall support multiple levels of testing for the EHR systems. The Contractor shall write unit tests once user stories are finalized and before code is developed using JUnit or another Government approved product.

Functional testing shall include both unit testing and end-to-end system testing. The Contractor shall support user acceptance testing that shall be conducted by the Product Owner.

The Contractor shall lead integration testing, regression testing, and engineering testing, including the setup of production-like data sets in lower environments using data replication tools provided by ICE.

The Contractor shall develop and conduct automated regression testing using Katalon, Selenium, Playwright, or another Government approved product. The goal is to ensure that regression tests are no more than two releases behind each application’s current release.

The Contractor shall have an underlying familiarity with the business processes, understanding the impact and severity of defects and how they would impact operations and deployment decisions.

3.9.1 User Acceptance Testing

The contractor shall test and evaluate the software during development using an early engagement approach with selected IHSC staff for initial rollout of the application and with every upgrade of the application prior to release to the Production environment.

The Contractor shall propose a test and evaluation strategy of the EHR system that includes the areas listed below. The contractor shall execute the IHSC approved strategy starting with the preparation and continuing throughout planning and site deployment phases.

The Contractor shall include test & evaluation strategy components including, but not limited to the following:

· Development testing activities, joint IHSC and Contractor data migration testing (covers the data extract, transformation, loading, and data integrity validation) into the EHR system,

· Assessment and planning for legacy EHR and associated module(s) data, integration of data from external interfaces into new EHR system, data cleaning, data mapping and transformation, data migration, post-migration data validation and verification,

· Functional and non-functional requirements testing found in the Government RTM, including but not limited to, interface testing for system integration and interfacing for requirements. Interface testing includes interface connections, message formats, data integrity, and data mapping.

· Risk-based requirements validation and risk-based workflow testing, test observation & validation, system integration/interface & interoperability testing, do no harm testing for IHSC systems interfaced to the EHR system. IHSC Test and Evaluation activities for enterprise level requirements, workflows, interfaces are to be completed before the functionality is used at any live site.

· Site testing such as integration validation and medical device testing activities during IHSC site deployments.

The Contractor shall:

· Participate in a test integration workgroup that is comprised of IHSC end-users that have roles and responsibilities in the IHSC EHR system.

· Provide new development testing processes documentation which includes, but is not limited…