CTEP_ESYS Statement of Work_Final.pdf

STATEMENT of WORK

1. TASK ORDER TITLE

NCI Oncology Clinical Trial System, Management, and Support

2. BACKGROUND

The National Cancer Institute (NCI) is the federal government's principal agency for cancer research and training. Established under the National Cancer Institute Act of 1937, NCI is part of the National Institutes of Health (NIH), one of the agencies that make up the Department of Health and Human Services (HHS).

NCI’s mission is to lead, conduct, and support cancer research across the nation to advance scientific knowledge and help all people live longer, healthier lives. As the leader of the cancer research enterprise, collectively known as the National Cancer Program, and the largest funder of cancer research in the world, NCI manages a broad range of research, training, and information dissemination activities that reach across the entire country.

The Cancer Therapy Evaluation Program – Enterprise System (CTEP-ESYS) is NCI’s enterprise system environment for supporting the conduct, oversight, and evaluation of NCI-sponsored oncology clinical trials. It provides integrated applications, data repositories, interfaces, and services that support protocol development, study administration, regulatory oversight, user and site credentialing, investigational agent management, safety reporting, data exchange, and operational decision-making across the clinical trials enterprise.

The initial contract was awarded in 1996 in response to the recommendations to design, develop, and implement innovative data collection systems, management tools, and information storage as well as communication capabilities to support the oncology research community. This effort supports the NIH/NCI science initiatives to modernize biomedical data systems and enhance the availability, quality, and usability of cancer research for investigators nationwide.

Enhancement, modernization, and integration decisions for CTEP-ESYS are guided by the following principles:

• Reduce research burden: Develop and maintain tools and processes that reduce the research burden on the oncology community to eliminate or minimize barriers to NCI trial participation

• Cost-effectiveness: Implement solutions that efficiently address administrative, scientific, and regulatory needs of the NCI research community

• Reliability: Ensure consistent delivery of accurate clinical results and toxicity data

• Scientific Focus: Enable scientists and physicians to prioritize scientific research over administrative tasks

• Patient Safety: Improve patient/trial safety through improved systems and workflows

• Security and Confidentiality: Safeguard proprietary and patient information using rigorous security and privacy controls

• Regulatory compliance: Provide tools and services that meet and/or exceed Federal IT, cybersecurity, privacy, accessibility, records management and research requirements

• Data Integrity: Eliminate redundancy and maintain consistency of data throughout the oncology research community

• Data Empowerment: Provide timely access to high-quality data to support informed decision-making

• Scalability and Flexibility: Design/Build systems that can evolve with emerging research demands and technologies

• Interoperability: Enable smooth integration with other systems and applications to support collaboration and data sharing

Today, the CTEP-ESYS is a highly integrated enterprise system consisting of 24 applications and services that support clinical trials management, regulatory oversight, data exchange, and operational decision-making for NCI-sponsored clinical research. Some applications are available to clinical trial staff and external site staff to support federally required data submission and other research-related activities, while most of the applications are accessible only by NCI/NIH personnel (and approved Contractors) to support CTEP and NCI mission operations and improve the efficiency of current and future business practices.

CTEP-ESYS integrates with systems and applications operated by NCI and other partner systems/applications, requiring robust interoperability, security, and coordinated lifecycle management. As the core component of CTEP Clinical Oncology Research Enterprise (CORE) system, CTEP-ESYS must continue to support ongoing operations while enabling modernization, enhanced integration, improved user experience, improved reuse of structured protocol and study information, and compliance with evolving federal and research requirements. NCI requires CTEP- ESYS to function as an increasingly interoperable, data-driven enterprise ecosystem that reduces fragmented workflows, minimizes manual workarounds and duplicate data entry, and supports efficient movement of information across authorized systems and stakeholders.

This requirement is for research support services. It does not require the Contractor to independently conduct clinical or scientific research. Rather, the Contractor shall provide technical, informatics, analytical, engineering, operational, and modernization support that enables and improves the conduct, oversight, and evaluation of NCI-sponsored oncology clinical research.

Note: A Glossary of Acronyms is provided in Appendix 2.

3. OBJECTIVE

The objectives of this Statement of Work (SOW) are to acquire technical, informatics, operational, analytical, and program management support services for CTEP-ESYS and related capabilities that support the conduct, oversight, and evaluation of NCI-sponsored clinical trials. This includes services to operate, maintain, secure, enhance, modernize, integrate, configure, evaluate, and improve CTEP- ESYS applications, infrastructure, workflows, data repositories, interfaces, and support services. The requirement also includes work involving systems or groups supported or utilized throughout NCI, including, but not limited to, the Clinical Trials Support Unit (CTSU), Enterprise System and Clinical Trials Monitoring Service (CTMS), Division of Cancer Treatment and Diagnosis (DCTD), Division of Cancer Prevention (DCP), the Coordinating Center for Clinical Trials (CCCT), the Center for Biomedical Informatics and Information Technology (CBIIT), NCI National Clinical Trials Network (NCTN) Groups and other grantees, which may require interoperability, data exchange, process alignment, or technical integration with the CTEP-ESYS.

The Contractor’s support shall directly enable protocol development, study administration, user and site credentialing, investigational agent management, safety reporting, regulatory support, interoperability, reporting, clinical data integration, and research decision support across trial phases.

The Contractor shall also support enterprise data flow, standards-based exchange, structured information management, and reduction of redundant manual data entry and fragmented workflows across internal and external systems.

The objectives also include support for continuous improvement and modernization, including the assessment, design, development, testing, demonstration, pilot implementation, prototyping, integration, and transition of approved new or emerging technologies, methods, standards, and architectures that can improve efficiency, usability, scalability, interoperability, data quality, and service delivery. As directed by NIH/NCI, the Contractor shall also support the establishment and use of measurable key performance indicators (KPIs) to assess operational effectiveness, modernization outcomes, and the value of deployed capabilities.

4. SCOPE OF WORK

The Contractor shall provide technical and operational support services for CTEP-ESYS applications, services, infrastructure, and information management capabilities in direct support of the conduct, oversight, and evaluation of NCI-sponsored oncology clinical trials.

The Scope includes support for system operations, maintenance, enhancement, design, development, technical evaluation, modernization, hosting environments, cybersecurity, disaster recovery, application support, help desk services, configuration management, documentation, training, data repositories, standards implementation, reporting, and interoperability with internal and external systems. The work also includes assessment of existing capabilities, workflow inefficiencies, and alternatives; identification of opportunities to reduce manual effort, fragmented processes, and duplicate data entry; testing, pilot implementations, and NIH/NCI-approved transition of new or emerging technologies into operational use; and development of metrics, analyses, and reporting capabilities to measure system performance, user adoption, operational efficiency, data quality, interoperability, and modernization outcomes, as directed by NCI/NIH.

5. TASKS

The Contractor shall perform the following tasks:

Task Area 1 – Task Order (TO) Management Task Area 2 – Infrastructure, Hosting, Security, and Continuity Task Area 3 – Operations, Maintenance, Enhancement, and Support Services Task Area 4 – Information Management, Data Integration, and Interoperability

5.1.1 TASK 1 – TASK ORDER (TO) MANAGEMENT

Effective Task Order (TO) management is essential to the success of the Contract. The Contractor shall:

1. Provide the technical and functional activities necessary for the management of this SOW, including oversight of all tasks provided by Contractor personnel, including Subcontractors, to satisfy the requirements identified in this SOW.

2. Assume responsibility to meet the cost, performance, and schedule requirements through the task execution.

3. Participate in regular meetings with Government staff and designated stakeholders to review system priorities, protocol-related workflows, data integration needs, regulatory and scientific support requirements, and operational impact of changes on ongoing clinical research activities.

4. Meet with CTEP personnel within two working hours’ notice at either NCI or Contractor meeting location or by use of available technologies (e.g., WebEx, Microsoft Teams, etc.).

5. Develop, implement, and maintain management processes for planning, coordination, risk management, issue tracking, status reporting, and quality oversight.

6. Develop, implement, and maintain change management processes that incorporate involvement of subject matter experts, key stakeholders, and COR review and approval.

7. Coordinate work across task areas to ensure that activities related to infrastructure, application, security, data, and interoperability are planned and executed in an integrated manner.

8. Identify risks, mitigation strategies, dependencies, and resource issues that may affect performance, and elevate such matters to the COR in a timely manner.

9. Support Government oversight by preparing and presenting status updates, schedules, risks, accomplishments, and recommended next steps as requested by the COR.

10. Ensure that all work products, documentation, and communications are accurate, timely, and aligned with Government direction.

11. Develop, maintain, and update a Government-approved performance measurement framework for CTEP-ESYS that includes key performance indicators, operational metrics, and outcome measures related to system performance, service delivery, data quality, interoperability, user support, and modernization progress.

12. Provide recurring management reporting, dashboards, and analyses that track operational status, risks, integration activities, modernization progress, user support trends, and implementation status of Government-approved enhancements.

13. Conduct, no less than annually, a structured review of the CTEP-ESYS application and service portfolio to identify overlapping functionality, opportunities for consolidation or retirement of redundant capabilities, and priorities for modernization and alignment with evolving business needs and present the review to the COR.

5.2 TASK 2 – INFRASTRUCTURE, HOSTING, SECURITY, AND CONTINUITY

The work to be performed under this task relates to the implementation, administration, protection, monitoring, continuity, and transition of CTEP-ESYS hosting environments and supporting infrastructure, including data center and cloud components. This task includes protection of the data and respective applications from internal and external threats, restoration of services after security incidents or outages, and support for hosting transitions as directed by the HHS/NIH/NCI.

The Contractor shall comply with all applicable federal regulations, HHS/NIH/NCI policies, and contract clauses governing information technology, security, privacy, accessibility, continuity, and records management, including but not limited to Section 508, FISMA, FedRAMP, HIPAA, HHS/NIH/NCI policy, and applicable NIST guidance.

5.2.1 Data Center and Cloud Services

The current primary data center is located at the Building 12 facility on the NIH Bethesda campus, and the secondary data center is located at the Sterling facility in Virginia. The Contractor shall maintain the CTEP-ESYS applications and supporting systems within the NIH data center and approved cloud environment. It is anticipated that the NIH Building 12 data center will be decommissioned during the life of this contract, and all CTEP-ESYS applications and supporting components currently hosted in Building 12 shall be migrated to a Government-approved target environment no later than December 31, 2030, unless otherwise directed by the Government. The contractor shall plan for and implement, with COR approval, a transition to an alternative solution with the Government-approved Cloud environment the preferred option. Where full cloud migration is not feasible within the limited time required by NIH/CIT, the Contract shall migrate the remaining applications and supporting components to the secondary NIH data center.

All information management, hosting, and migration activities shall be performed in compliance with applicable federal regulations and HHS/NIH/NCI policies governing data security, privacy, records management, and system performance.

The requirements below define the Contractor’s responsibilities for maintaining CTEP-ESYS applications, software, and hardware regardless of hosting location. Migration and transfer activities are identified separately. Upon completion of any migration, all maintenance and support requirements shall continue to apply in the new hosting environment.

Unless otherwise specified, the maintenance and support requirements in Sections 5.2.1.1 through 5.2.1.4 apply regardless of the physical or logical hosting location of CTEP-ESYS components, including NIH data centers, alternate data centers, or HHS/NIH/NCI approved cloud environments.

5.2.1.1 Operational Support and Services

The Contractor shall provide ongoing operational support for CTEP-ESYS applications and services within NIH data center and cloud environments. All services shall be performed in accordance with NIH hosting, security, and performance requirements. The Contractor shall:

1. Notify data center and/or cloud management team of any changes in operational needs or requirements.

2. Provide current contact and escalation information for the Federal Sponsor and Technical Project Lead.

3. Submit service requests in accordance with applicable data center and cloud policies.

4. Use the designated on-call process for critical emergencies.

5. Proactively maintain, monitor and report on infrastructure health, performance, and availability across both data center and cloud environments.

6. Respond to incidents and outages in accordance with NIH escalation procedures and defined response times

7. Maintain operational readiness to support continuity of mission-critical services.

5.2.1.2 Software Maintenance and Support

The Contractor shall ensure all software supporting the CTEP-ESYS environment remains functional, secure, and compatible during ongoing operations and throughout the transition from NIH data center to cloud or alternate data center environment. The Contractor shall:

1. Provide and maintain all software and associated licenses required for CTEP- ESYS operations that are not provided by the Government data center or cloud environment.

2. Manage and maintain all required software licenses, subscriptions, and support agreements necessary to operate CTEP-ESYS, including tracking license counts, renewal dates, usage compliance, and compatibility with hosting environments.

3. Notify the COR of upcoming license expirations and provide recommendations for renewal or modification in advance of expiration dates.

4. Ensure all software has vendor or community support in accordance with HHS policy.

5. Build, maintain, and operate secure, stable and compliant applications and services.

6. Document CTEP-ESYS application configurations and maintain accurate technical documentation.

7. Manage all CTEP-ESYS applications, including deployments, shutdowns and restarts.

8. Provide remediation for all CTEP-ESYS applications and service issues.

9. Validate application compatibility with the Government-designated cloud environment and implement any required re-platforming or configuration adjustments.

5.2.1.3 Equipment

For purposes of this section, “equipment” refers to physical information technology assets, including but not limited to servers, storage devices, network equipment, appliances, workstations, laptops, monitors, and other peripherals required to operate, maintain, or support CTEP-ESYS. Independently, and not as an agent of the Government, the Contractor shall furnish all the necessary materials, equipment, and facilities, not otherwise provided by the Government as needed to perform the Statement of Work. Software, licenses, and application components are addressed separately in Section 5.2.1.2. The Contractor shall:

Contractor Furnished Equipment:

1. Provide, procure, configure, support and maintain all equipment that is necessary for CTEP-ESYS environment or service that is not provided by Government, subject to Government approval as required by the contract.

2. Assess the lifecycle status of equipment and recommend refresh or replacement when equipment reaches End of Service/Support Life (EOSL), no longer meets operational or security requirements, or is incompatible with supported software or operating systems.

3. As a general planning guideline, hardware refresh cycles are expected to occur approximately every five (5) years from the date of purchase, unless otherwise directed by the Government. The Contractor shall plan hardware refreshes on a staggered, multi-year basis across the period of performance, rather than as a single bulk replacement effort, unless otherwise approved by the Government. Refresh planning shall consider equipment age, end-of-support status, performance, security, operational impact, and available funding.

4. Manage all CTEP-ESYS equipment including deployments, shutdowns, restarts, installation, replacement, and decommissioning, as applicable.

5. Maintain equipment inventory documentation consistent with Federal requirements and regulations.

6. Perform capacity planning to ensure equipment supports required system availability and performance.

7. Monitor all CTEP-ESYS equipment to ensure availability, performance, capacity, and compliance with security and operational requirements.

8. Ensure that proper security protocols and security agents are enabled and current on all equipment and systems.

9. Notify the CTEP leadership and COR of any equipment issues that may affect operations, migration readiness or continuity of service.

10. Submit equipment acquisition, replacement, and refresh recommendations to the COR for review and to the Contracting Officer for approval, as applicable.

Any Government-approved equipment acquisitions shall comply with applicable NIST standards and Federal "No Buy" restrictions.

Government Furnished Equipment (GFE):

1. Assess the lifecycle status of GFE and recommend refresh or replacement when equipment reaches End of Service/Support Life (EOSL), no longer meets operational or security requirements, or is incompatible with supported software or operating systems.

2. Maintain equipment inventory documentation consistent with Federal GFE requirements and regulations.

3. Monitor all GFE equipment to ensure availability, performance, capacity, and compliance with security and operational requirements.

4. Ensure that proper security protocols and security agents are enabled and current on all equipment and systems.

5. Notify the CTEP leadership and COR of any equipment issues that may affect operations, migration readiness or continuity of service.

All equipment procurement recommendations shall be submitted to the COR for review and approval. Any Government-approved equipment acquisitions must comply with applicable NIST standards and Federal “No Buy” restrictions.

5.2.1.4 Facility Safety

The Contractor shall follow all HHS/NIH/NCI and cloud facility safety guidelines during operations, transition activities, and any required handling of Government-furnished equipment. The Contractor shall:

1. Shut down and isolate any CTEP-ESYS contractor-managed equipment if it is detected that it presents a immediate hazard, damage facility infrastructure, or otherwise adversely affect the facility. If equipment provided or managed by NIH or CBIIT is determined to present a hazard or cause damage, The Contractor shall immediately notify the COR and the designated NIH/CBIIT support contact. However, if immediate action is necessary to protect personnel, the facility, or other equipment, the Contractor may take the minimum action necessary to mitigate the hazard and shall notify the COR and appropriate support personnel as soon as practicable.

2. Adhere to rules of behavior specified in the NIH Data Center and NCI Cloud Policy and Work Rules document, if publicly available, or as otherwise provided by the Government.

3. Adhere to the NIH or NCI Data Center and Cloud Infrastructure Guidelines for infrastructure rack, wiring, tools and labeling, and naming standards within the Data Center and/or cloud environment.

4. Coordinate with facility personnel to ensure safe-handling, relocation, or removal of equipment during the decommissioning of the NIH data center.

5.2.1.5 Migration and Transfer to Alternate Hosting Environments

The Contractor shall continue to plan, coordinate, and execute the orderly, secure migration of CTEP-ESYS applications and supporting components from the current hosting environment to a Government-designated cloud environment or, if directed, to an alternate NIH data center. This includes completion of ongoing migration activities already underway, execution of any remaining migration phases, and support for any additional transition activities directed by the NIH/NCI during the period of performance. Migration activities shall be performed in accordance with NIH/NCI hosting, security, and performance requirements and shall minimize disruption to ongoing operations.

The Contractor shall be responsible for the following migration and transfer activities:

1. Develop and maintain a transition project plan to migrate services to an alternative hosting environment. The plan shall include: timelines, Work Breakdown Structure (WBS), LOE estimates, and risk mitigation strategy.

2. Identify and prioritize applications, services, and supporting components for migration in coordination with the Government.

3. Provision required resources in the target cloud or alternate data center environment to support migration activities.

4. Perform safe and secure migration of applications, data, configurations, and related components using Government-approved methods and tools.

5. Coordinate migration activities with Government stakeholders and other CTEP-related contractors, as applicable.

6. Conduct testing, validation, modernization, and certification of all migrated applications and services to ensure full functionality, security, efficiency, and compliance prior to production use.

7. Support phased migration activities in accordance with Government direction, including execution of Migration Phases I–IV as described in Appendix 3 of this SOW, which is incorporated herein by reference.

8. Continue to perform all maintenance and support requirements in the new hosting environment following migration

Upon completion of migration activities, the Contractor shall continue to perform all maintenance and support requirements defined in Sections 5.2.1.1 through 5.2.1.4 in the new hosting environment.

5.2.2 System Security

The Contractor shall:

1. Implement robust security measures to protect IT infrastructure and systems, ensuring compliance with applicable federal laws, regulations, and HHS/NIH/NCI policies governing information security and privacy. This includes, but is not limited to, compliance with the HHS Information Security and Privacy Policy (IS2P), Federal Information Security Modernization Act (FISMA), and applicable National Institute of Standards and Technology (NIST) guidance, as required by the contract and governing regulations.

2. Install software vendor released security patches, update the antivirus definitions to permit automatic updates, and remediate critical and high vulnerabilities in an expedited manner, or within software vendor and agency specified timeframes.

Notification of routine updates shall occur as part of standard Change Management (see section 5.3.3).

3. Report any potential security breach in accordance with agency-specific incident reporting procedures (e.g., CTEP Cybersecurity Incident SOPs for external and internal).

4. Define the process for identifying and assessing security risks at external sites and specify criteria for determining the severity and potential impact of the risk.

5. Follow established SOP as well as notify the Contracting Officer (CO), Project Manager (PM), and Contracting Officer Representative (COR) within one hour, upon realization of any potential security breach.

6. Coordinate communication with external partners, sharing of security protocols, and collaborate on mitigation strategies to ensure the protection of sensitive data and system integrity.

7. Submit a Vulnerability Scan Report to the COR within five (5) business days after completion or receipt of each scan, unless otherwise directed.

8. Document security incidents, responses, and outcomes including procedures for regular reporting to the COR and other relevant parties.

9. Maintain Single Sign-on (SSO) using SAML or other federated standard to exchange user identity and authentication information between the CORE systems and other information sources for CTEP Clinical Trials (e.g., NCTN group websites).

10. Expand SSO services for new websites/web-based systems as approved by PM or

COR.

11. Integrate SSO services with other security-related authentication mechanisms and applications, including federally approved identity providers, as directed by the COR or PM.

12. Utilize automation, advanced analytics, or Government-approved AI-enabled security capabilities, where authorized, to improve monitoring, threat detection, system reliability, and incident response.

13. The contractor shall document all AI-enabled security tools, their data dependencies, and their integration points with NIH's broader AI platform as part of the system security plan maintained under this task.

5.2.3 System Backup and Disaster Recovery Management

The Contractor shall maintain and verify system backups and support operational continuity for all critical CTEP-ESYS applications and data. The Contractor shall:

1. Regularly perform and verify full and incremental system backups for all critical CTEP-ESYS applications and data, in accordance with approved data retention and backup policies.

2. Ensure backups are securely stored in geographically dispersed locations (e.g., off-site or cloud-based) and are encrypted at rest and in transit. Backup integrity checks must be performed periodically.

3. Execute the approved Contingency/Disaster Recovery Plan (C/DRP): In the event of any individual system and component failures, the Contractor shall execute the approved Operational Contingency Plan and, if needed, the approved C/DRP. Deviations from the approved Operational C/DRP shall require prior COR approval when practicable. In circumstances requiring immediate action to protect system availability, data integrity, security, or continuity of mission support, the Contractor may implement a deviation without prior approval if delay would materially increase operational risk; however, the Contractor shall notify the COR and CO within one (1) hour of the decision to deviate, provide appropriate justification for the deviation, document all actions taken, and obtain Government concurrence as soon as practicable thereafter. Any deviation with contract cost, scope, or schedule impact shall require CO approval. For purposes of this requirement, “operational” means restoration of essential mission functions for authorized users, which may include limited functionality or temporary workarounds; “fully operational” means restoration of normal production functionality, interfaces, security controls, and service levels. Critical CTEP-ESYS applications must be operational within 4 hours and be fully operational within 24 hours of failure detection.

4. Immediate Notification of System Failures: Notify the CO, PM, and COR within one hour of discovery of any system failure or outage.

5. Failure Resolution and Communication: Work diligently to restore any affected systems in the most expedient manner, while providing status updates to the COR as requested by COR post initial synchronous notification until the system failure is fully resolved.

6. Major Disaster Response: in the event of a disaster causing shutdown of CTEP- ESYS operations (e.g., catastrophic disaster), execute the approved C/DRP or deviate as needed, with justification, to expedite recovery and minimize operational impact.

7. Backup Storage: Provide backed-up data storage with capacity to hold up to one year of data in a secure location no less than 25 miles physically away from the primary data center (e.g., tapes at a secure remote facility, CLOUD). If using cloud as a backup solution, ensure that it accommodates future growth and changes in data storage needs and integrate seamlessly with existing systems to facilitate efficient data management.

8. Backup Availability and SLA Compliance: Ensure backed-up data is readily accessible to support rapid recovery of CTEP-ESYS services to meet the SLA requirements.

5.3 TASK 3 – OPERATIONS, MAINTENANCE, ENHANCEMENT, AND USER

SUPPORT

The work performed under this task supports the operational conduct, oversight, and evaluation of NCI-sponsored clinical studies by maintaining and enhancing CTEP- ESYS applications, services, and workflows that underpin core clinical trial administration functions, including protocol development and tracking, regulatory documentation and submission, user and site credentialing, investigational agent management, safety reporting, and related operational processes. This task also includes support for workflow modernization, improved usability, reporting, standards-based data exchange, and the evaluation and implementation of approved capabilities that improve enterprise efficiency and reduce administrative burden across the clinical trials ecosystem.

The work may also entail collaboration with a third-party organization to conduct system audit(s) as needed to verify technical and/or functional components.

The Contractor shall:

1. Ensure all CTEP-ESYS applications are fully functional (with the exception of pre-approved scheduled maintenance), 24 hours per day, 7 days per week.

2. Utilize best practices consistent with Capability Maturity Model Integration (CMMI) maturity level 3 or higher (https://cmmiinstitute.com/learning/appraisals/levels).

3. Comply with information security and privacy requirements, Enterprise Performance Life Cycle (EPLC) processes (see https://www.hhs.gov/web/governance/digital-strategy/it-policy-archive/policy-for-information-technology-enterprise-performance.html), HHS Enterprise Architecture requirements to ensure information is appropriately protected from initiation to expiration of the contract. All information systems development or enhancement tasks supported by the Contractor shall follow the HHS EPLC framework.

4. Utilize IT Service Management best practices such as the ITIL framework to help align IT service delivery with business goals.

5. Ensure updates that are compliant with relevant patient consent provisions of Health Insurance Portability and Accountability Act (HIPAA) as applicable to the CTEP-ESYS.

6. Maintain compliance with all regulatory requirements concerning patient records in electronic format that are created, modified, maintained, archived, retrieved, or transmitted under agency record requirements. This compliance also applies to any electronic record submitted to the agency.

7. As appropriate, comply with relevant sections of the Code of Federal Regulations (21 CFR Part 11) for computer systems (including hardware and software).

8. Provide technical and audio-visual support to Government staff for meetings hosted by the Contractor at CTEP facilities and be familiar with the audio-visual systems used at NCI Shady Grove campus after receipt of training from CTEP UC/AV contract located in the facility.

5.3.1 Help Desk

Help Desk support for end-users, NCI staff, and Contractors is essential. The Contractor shall:

1. Operate the help desk to provide telephone and email support coverage during normal Government business hours, Monday through Friday, excluding Federal holidays, from 8:00 a.m. to 4:00 p.m. Eastern Time (ET) for CTEP- ESYS end-users.

2. Provide after-hours capture of customer support requests (e.g., voice mail, email), and maintain a government-approved after-hours virtual assistant, chatbot, or AI-assisted self-service capability, if directed by the Government, to support request intake, knowledge-based assistance, ticket creation, and routing for common user issues. Any such capability shall comply with applicable NIH/NCI governance, security, privacy, accessibility, and AI policy requirements.

3. Requests received after normal help desk hours shall be logged and made available for response at the start of the next business day, unless otherwise directed by the COR or covered by separate incident escalation procedures.

4. Provide an initial response to all requests within 4 work hours of receipt during normal help desk hours, defined in Section 5.3.1 (1). Requests received after-hours shall receive a response within 4 working hours from the start of the next working day.

5. Develop and maintain a triage system to promote rapid and accurate response to queries, ensuring help desk ticket categorization according to service desk best practices (e.g., ITIL) to differentiate between an incident (e.g., break/fix) or a service request (e.g., see section 5.3.3). All tickets must be categorized, tracked, and resolved properly to support smooth business operations.

6. Work with COR and CTEP Leadership to ensure response timelines are appropriate for the type of assistance requested (e.g., currently CTEP-AERS SAE report submission issues must be addressed within 4 business hours).

7. Develop and implement innovative help desk and IT support solutions, including the use of Artificial Intelligence (AI), automation, and other new/emerging technologies, to augment and enhance baseline help desk processes, improve service quality, enhance user experience, optimize resource utilization, and support achievement of service level objectives. Such solutions may be used to support functions including, but not limited to, intelligent request intake, advanced ticket categorization and prioritization, knowledge management, self-service capabilities, trend analysis, and proactive issue detection, subject to Government approval.

8. Develop mechanisms to measure and track customer satisfaction (e.g., surveys, feedback tools) and identify opportunities to improve help desk services and user experience.

9. Analyze the help desk logs and ticket data to identify recurring issues, defects, and trends impacting day-to-day operations, and present findings and recommended improvements to the COR for consideration.

10. Provide proactive end-user communication regarding planned releases, major changes, known issues, workarounds, service disruptions, and new functionality in a manner approved by the COR.

11. Conduct recurring user outreach, education, and training activities, including Government-approved webinars, demonstrations, office hours, job aids, and refresher sessions as needed, unless otherwise directed by the COR, to support effective adoption of CTEP-ESYS capabilities.

12. Analyze help desk contacts, training questions, and user feedback to identify usability issues, recurrent workflow obstacles, and opportunities for self-service improvements, enhanced training, or system redesign, and provide recommendations to the COR.

5.3.2 Incidents (Break/Fix Support)

The Contractor shall:

1. Report any identified defects/bugs found during UAT (including application scan software findings) to the COR prior to release into production. Such defects/bugs shall not be put into production unless approved by the COR.

2. Resolve any help desk reported defects/bugs within the time frame required by the COR to ensure the end-user is not impeded from completing their work. If the identified defect(s)/bug(s) cannot be resolved within the timeframe required, devise and implement workarounds with COR approval to overcome system issues and provide resources to adequately handle ad hoc maintenance needs as well as customer support to prevent interruptions until such issues can be addressed.

3. Inform COR within 1 business day of any NIH/NCI noted application scan findings. All findings must be addressed within the timeframe required by NIH/NCI.

4. Document outcomes and lessons learned to inform future enhancements and maintain alignment with organizational goals.

5.3.3 Enhancement, Development and Configuration Management (CM)

Information systems designed or developed for or on behalf of NIH at non-NIH facilities shall comply with all NIH policies developed in accordance with Federal Information Security Modernization Act (FISMA), NIST, and related NIH security and privacy control requirements for Federal information systems. This includes information and system security categorization level designations in accordance with FIPS 199 and FIPS 200 with implementation of all baseline security controls commensurate with the FIPS 199 system security categorization. The current FIPS 199 categorization is Moderate. The security controls must be designed, developed, approved by NIH, and implemented in accordance with the provisions of NIH security system development life cycle as outlined in NIST Special Publication 800-37.

1. Identify, analyze, design, develop, implement, integrate, test, deploy, document, and maintain approved enhancements and new capabilities for CTEP-ESYS in accordance with HHS/NIH/NCI approved requirements, architecture, security, and configuration management processes.

2. Evaluate and, if approved by COR, implement HHS/NIH/NCI approved new or emerging technologies, including but not limited to artificial intelligence (AI), machine learning (ML), automation, advanced analytics, and other innovative capabilities, to improve operational efficiency, reduce manual workload/burden, improve data and service quality, support modernization, and strengthen CTEP-ESYS performance.

a. Such capabilities may also be applied across application functionality, data management, system integration and interoperability, user support, IT operations, and security monitoring.

b. Any AI or ML capabilities proposed, developed, or implemented under this contract shall align with NIH's validated enterprise AI platform and shall not introduce independent commercial AI tools or contractor-managed AI infrastructure without explicit written approval from the COR.

c. The contractor shall coordinate with NCI's AI and modernization teams during the design phase of any AI-enabled capability to confirm alignment with NIH's existing technology stack, security authorizations, and governance requirements prior to development.

d. The contractor shall coordinate with NCI's AI team to identify applicable tools already in development or production before proposing new capabilities. Where existing NIH tools can fulfill the requirement, the contractor shall integrate with those tools rather than develop independent solutions.

3. Ensure all CTEP-ESYS system enhancement requests received from any source are vetted through the CTEP CM process to ensure proper evaluation and prioritization of changes to applications in the production environment according to its impact on the customer, implementation complexity, security, and IT resources. The goal of CM is to ensure that all system modifications follow a structured an orderly process for evaluation, approval, implementation, and documentation.

4. Present to the COR and other applicable CTEP Leadership personnel information necessary to make decisions for authorization and implementation of change requests, depending on the type of change. The CTEP approved Change Request (CR) document (Appendix 6) shall be used to establish a common understanding and agreement among product owners/stakeholders regarding the scope of changes (data, software, hardware, network, and people). The Contractor lead is responsible for ensuring that the CR document contains supporting information associated with the change request. The Contractor shall use the following guidelines for assessing the change type (see also Table 1):

a. Standard Change: This change type is a preauthorized change to the service or infrastructure. It has an accepted procedure to deliver a specified change need (e.g., maintenance activities, including but not limited to, updates of codes, reports, XML transactions, patching, system updates). Standard changes must have a written procedure on how they are done. Except in emergency situations, updates and patches must be tested to ensure there is no impact on operations. If the system fails after implementation of updates, the system must be rolled back to its original state, and all findings shall be reported as per the Operational Contingency Plan (see section 5.2.3).

b. Minor Change: This change type is a modification to the appearance and/or function in one application (e.g., application-specific workflow). The change must not impact the logical data flow of the system, require the hardware to be taken offline, and/or require the software to be restarted without a redundant system to ensure that the software is active for end-users.

c. Major Change: This change type includes a modification to the appearance and/or function of multiple applications (e.g., end-to-end workflow). This change may involve the addition of new technical components (e.g., AI or cloud native technologies) into the data model. Also, it may have an impact on the logical data flow of the system, require the hardware to be taken offline, or require the software to be restarted without a redundant system. For any Major Change request, the contractor shall provide or reference current enterprise workflow dependency diagrams covering the affected systems and data flows. At a minimum, the contractor shall develop and maintain dependency diagrams for the following core workflows: protocol activation, protocol amendment propagation, and patient enrollment. These diagrams shall be treated as living documents, updated with each Major Change, and submitted to the COR as part of the change request package.

d. Emergency Change: This change type requires expedited implementation to satisfy an immediate operational, security, availability, or mission need. It may include repair of a service error, restoration of failed functionality, or remediation of a critical issue affecting the research mission. Emergency changes may vary in scope and risk and are not limited to low-risk changes. Accordingly, an emergency change shall follow a condensed change management process rather than the full standard review process to enable rapid response. If practicable, the change shall be tested before implementation; if prior testing is not feasible, the Contractor shall document the justification, assess potential impacts, and implement appropriate safeguards and rollback procedures. Immediate notification to the COR is required upon discovery of any system failure or other condition requiring an emergency change.

Table 1: Change Type(s)

Category Standard Minor Major Emergency

Risk Impact Low Low-Moderate High Unknown

Application(s) One or many One Many Unknown

Content Accepted procedure

Display and format (Layout)

Logical/Physical Data flow Unknown

Contracts One or many One One or many One or many

Reason Routine updates End-user request End-user request Satisfy an immediate need

Operations No Impact No impact (End-user training)

May Impact (End-user training) Unknown

5. Work with end-users and other NCI Contractors to document the business process flow/s, gather requirement/s, and classify the change/s. The Contractor shall review the current state with every change request to ensure standardization of system workflows and content. The Contractor shall consider ways to reduce complexity of maintenance tasks, support data quality and increase ease of use of the application and other integrated systems.

6. Work with end-users and other NCI Contractors to validate the business specifications to ensure the change is aligned with operational, regulatory, and scientific needs (e.g., conform with terminology standards for data exchange and FDA reporting, support research data collection in cancer Data Standards Repository (caDSR) and other NIH/NCI data collection, support existing or new trials, aligned with operational requirements of NIH/NCI and new/current multi-center organizations).

7. Ensure that the CR document includes detailed requirements with clear assignment to a specific component within the system and associated challenges/risks. The CR document shall include corresponding documentation (e.g., Implementation Plan, Training Plan) and shall contain targeted performance improvement goals.

8. Ensure conformity to the CM process. Change requests must be presented to the COR for discussion unless otherwise directed by the COR. The phases of scheduling, building, testing, and implementation may commence upon receiving approval via email from the COR.

9. Ensure that the final COR decision is entered in the CR document and the COR decision is communicated back to the requestor.

10. After the change is complete, the Contractor shall document the status (e.g., implemented, failed, or backed out) and lessons learned in the CR document. All new and closed CR documents shall be uploaded in the COR designated storage location with the appropriate naming convention approved by the COR. Status update shall be provided during change review meeting(s).

11. Collaborate with other NCI staff and Contractors on enhancement, optimization and integration activities to ensure that the functional and technical specifications meet the customer’s needs, and work with internal and external stakeholders to identify system improvements to eliminate waste (e.g., retire redundant features/systems) and decrease resources for system maintenance and support.

12. Collaborate with other NCI staff and Contractors on access management activities to prevent permission creep, e.g., analyze system workflows to ensure that system profiles, roles, and permissions are designed to match the user’s function within the organization.

13. Regularly assess emerging technologies and methodologies for potential integration into existing systems. Conduct structured evaluations and pilot projects to test feasibility and effectiveness. Implement successful solutions in a controlled manner, ensuring alignment with system integrity and interoperability goals in Section 5.4.2.

14. Establish and monitor performance metrics related to configuration management activities, such as change success rates, implementation times, system stability post-change, and stakeholder satisfaction levels. Use these metrics to evaluate the effectiveness of the CM process and identify areas for improvement. Develop actionable plans to address identified issues and enhance the reliability and efficiency of change management practices. Report findings and progress to stakeholders and leadership to ensure transparency and support informed decision-making.

5.3.4 System Manuals and Training

1. Maintain a set of up-to-date Administrator/System manuals detailing the operational procedures and business rules for all CTEP-ESYS applications. These manuals shall be reviewed and approved by the COR and then posted online to a secure reading room.

Administrator/System manuals shall be updated as needed with revised versions posted for review and use by project leadership team.

2. Maintain a set of up-to-date user guides for all CTEP-ESYS applications. User Guides shall be maintained on the appropriate application’s landing page after log in. These user guides shall be reviewed and approved by the COR or designee prior to posting. User guides shall be updated as needed and/or as requested by the COR.

3. Develop, update, maintain, and provide training and education materials for all applications (e.g., integrations, enhancements) and provide training to Government and other stakeholder personnel at the direction of the COR. Upon request by the COR, education and training materials must be provided in a format compatible with the CLASS Learning Management System.

4. Develop and support enhanced communication regarding CTEP-ESYS activities with stakeholders through the use of, but not limited to, monthly project review meetings, release notes, trainings sessions, and…