CMS NextGen PWS SOL 959P0026Q0001.pdf

Pretrial Services Agency for the

District of Columbia

Performance Work Statement for

Client Management System (CMS) Next Generation

Solicitation Number 959P0026Q0001

Table of Contents

1. Introduction 3

2. Objective 3

3. Scope 4

4. Background 5

5. Period of Performance 11

6. Place of Performance 11

7. Applicable Documents 11

8. General Guidance 12

9. General Project Tasks 14

10. Key Project Tasks 17

11. Contractor Quality Assurance 20

12. Deliverables 20

13. Meetings 24

14. Special Instructions 25

15. Special Clauses 28

Performance Work Statement (PWS) Client Management System Next Generation

1. Introduction The Pretrial Services Agency for the District of Columbia (PSA) was created by an act of Congress (the District of Columbia Bail Agency Act) in 1967. Under the National Capital Revitalization and Self-Government Improvement Act of 1997, PSA was established as an independent entity within the Court Services and Offender Supervision Agency (CSOSA) in the Executive Branch. PSA has served the District of Columbia for nearly 60 years and is widely recognized as a leader in the pretrial field. PSA’s mission is to promote pretrial justice and enhance community safety. PSA’s vision is to improve public safety and serve the community through data-driven decision making by a committed workforce that provides evidence-based pretrial supervision and support services.

Pursuant to Title 23, Section 1303 (h) of the D.C. Code and Title 18, Section 3154 of the U.S.

Code, PSA assists judicial officers in both the Superior Court of the District of Columbia and the United States District Court for the District of Columbia by conducting a risk assessment for every arrested person who will be presented in court, identifying detention eligibility and formulating release recommendations, and providing supervision services intended to reasonably assure that defendants return to court and do not engage in criminal activity pending their trial and/or sentencing.

2. Objective PSA’s objective to award this acquisition is to establish a five-year (one base and four options) contract to modernize PSA’s Client Management System (CMS) and fully align the system with the Risk-Based Services (RBS) model.

CMS needs to be modernized to fully support the RBS model. Since its inception, PSA has utilized some form of risk assessment to drive supervision recommendations and practices. The Agency leverages risk assessment data to inform all aspects of defendant engagement, from the diagnostic process through the conclusion of the supervision period. In April 2023, PSA transitioned from a program-based case management model to a risk-based services model, where release recommendations are individualized, and supervision is tailored to each defendant’s risk designation. CMS was modified to support the transition, but the system was fundamentally designed to support the program-based approach.

One objective of modernization is to improve the user experience (UX). The desired outcome for the UX is that the human centered design must create a new way to interact and provide information to stakeholders.

PSA expects to modernize CMS in five phases as follows:

Phase 1 – Core Services and Drug Testing Specimen Collection (DTSC) functionality

(base year) Phase 2 – Client Information (CI) and Criminal History (CH) functionality (option year 1).

Phase 3 – Risk Based Services (RBS) functionality (option year 2)

Phase 4 – Treatment (TR) functionality (option year 3) Phase 5 – Diagnostic and Release Information (DRI) functionality (option year 4)

The project objectives are as follows:

1. System design is optimized for user experience accessibility, efficiency and productivity.

2. The system is architected for integration, performance and scalability.

3. The modern application development framework incorporates contemporary technologies and practices to automate the software development lifecycle; improve communication and collaboration between teams; and deliver new features and functionality faster and with fewer errors.

4. The system is secure-by-design. Security is a priority consideration in the design and development of the product.

5. The innovative approach to artificial intelligence is iterative and collaborative. Designers gather feedback from users and stakeholders for organic adoption, risk reduction, and value realization.

6. The system is operationalized for data-driven decision making. CMS modernization is integrated with the data governance project.

3. Scope This performance work statement (PWS) is for Software Development and Software Integration services to modernize PSA’s CMS.

The scope for the system development and modernization tasks includes architecture, data governance, interconnections, network and platform infrastructure, legacy source code, system security and web components. The new features and functionality must be designed and developed to integrate with the existing Azure commercial infrastructure. The scope includes bridge development to ensure backwards compatibility. Modernization must be performed in phases. New capabilities must be deployed over time requiring the legacy system to stay in production until all aspects of the legacy system have been replaced.

The new functionality must be created, tested, and deployed to replace existing legacy functionality. The legacy functionality will be turned off as modernized functions are deployed.

This process will continue until the project is complete. For example, it is expected that at the end of the base year PSA will be using new software application(s) to collect drug testing specimens while all other operations continue working under legacy PRISM.

When it comes to the UX it is expected the contractor must follow a human-centered design approach. Harvard Business School defines human-centered design as:

“a problem-solving technique that puts real people at the center of the development process, enabling the designer to create products and services that resonate and are tailored to the audience’s needs.”

The goal of human-centered design is to keep users’ wants, pain points, and preferences front of mind during every phase of the process. In turn, it allows for more intuitive, accessible products that are likely to meet the stakeholders’ expectations. PRISM stakeholders include Pretrial

Services Officers (PSO), Drug Testing Technicians (DTT), Assistant Pretrial Services Officers (APSO), Supervisory PSO (SPSO), Units Chiefs, Senior Leaders, Community Services Officers (CSO), and external partners (e.g., judges, clerks, and attorneys) among others.

Legacy PRISM was designed to support the program-based case management model. In that model all defendants, regardless of risk-level and/or unique circumstances, were enrolled in a program and experienced uniform supervision requirements. The scope of this project is to make sure the new PRISM is fully compliant with the risk-based services case management model or RBS. Working with the Government’s project team and using human-center design techniques, the contractor must create a system that fully supports individualized supervision tailored to each defendant’s risk designation and individual circumstances and needs.

This contract will create new software that will eventually replace the legacy PRISM with modernized functionality. The new system will enhance how PSA collects drug testing specimens, client demographic information, and defendant’s criminal history information. Also, modernized functionality will fully track risk-based supervision services and treatment services compliance. Culminating with a new and improved Pretrial Services Report (PSR) for use in Court.

4. Background The Pretrial Realtime Information System Manager (PRISM) became operational on March 3, 2002, and is the key component in the PSA’s Client Management System. PRISM’s primary purpose is to provide reliable information that improves the timeliness and quality of recommendations and decisions associated with the supervision of defendants who enter the criminal justice system in the District of Columbia.

The following subsections describe the Client Management System components and provide current PRISM attributes as background for planning. The following sub-sections provide context for current user interface and user experience and introduce new features and system enhancements that must be developed and integrated in the new system.

4.1 Client Management System - Applications

The Client Management System (CMS) is the collective name given to PSA's proprietary mission critical web-based applications named PRISM, PRISMJ, and DTMS.

4.1.1 Pretrial Real-time Information System Manager (PRISM)

PSA’s automated information system called the Pretrial Real Time Information System is the Agency’s mission-critical client management system (CMS) used for administering the case management of defendants released on pretrial supervision. The system is the Agency’s mainstay for providing reliable information that improves the timeliness and quality of recommendations and decisions associated with the interview, supervision and treatment of defendants.

PRISM was launched in 2002 with a unique database that contains local and national criminal history information on every person arrested in DC since the early 1970s. This mission-critical system contains the supervision history and outcomes for these individuals, and any sensitive personally identifiable information (PII) associated with them, including demographic information, criminal history, release recommendations, supervision compliance, substance use test results, assessment results and other information. PRISM interfaces with PSA’s Drug Testing Management System (DTMS).

PSA operates 24 hours a day, seven days a week, and must always be available for use.

PRISM exchanges information with local and Federal law enforcement agencies and justice partners, such as DC Metropolitan Police Department, DC Superior Court, US District Court for DC, US Attorney’s Office, DC Office of Attorney General, Federal Bureau of Investigation, US Marshals, and the Criminal Justice Coordinating Council

(CJCC).

4.1.2 PRISM for Juveniles and Family Court (PRISMJ)

PSA created a separate instance of PRISM dubbed PRISMJ to support the District of Columbia Superior Court Family Court drug testing specimen collection process. This instance is supported by the PRISM codebase. Unlike PRISM, which was designed to support criminal matters, PRISMJ supports respondents and those in family court. As a result, PRISMJ houses less information, needing only the most basic defendant information required to collect and process drug testing samples.

Two things are important to understand about PRISMJ. One, most of the PRISM related functionality is turned off because the business process does not require it. Two, Drug Testing Specimen Collection functionality upgrades to be done under this contract must take PRISMJ into consideration.

4.1.3 Drug Testing Management System (DTMS)

The Office of Forensic Toxicology Services (OFTS) operates an in-house forensic laboratory. The 'Lab' performs urine forensic drug testing for pretrial defendants under PSA’s supervision and offenders under the CSOSA Community Supervision Program (CSP) (i.e., persons on probation, parole, and community release), as well as respondents ordered into testing by the DC Superior Court Family Division.

The Lab tests about 10,000 samples for an average of 9 substances each month, which translates to over a million analyses for various illicit drugs each year. The expected turnaround for each test is less than 24 hours from sample receipt. Testing is done using clinical analyzers connected to the in-house laboratory information management system (LIMS) called the DTMS. The Drug Testing Management System version 3.0 has proven to be reliable and has continuously delivered quality services since its inception in February 2019. The system has already been refactored to handle an extremely high number of substances per test and to utilize modern web technologies. DTMS sends and receives data to and from PRISM on a regular basis.

4.2 CMS – System Components

PRISM is an n-tier web application built on Microsoft .NET framework. The information is stored in a relational database managed in MS SQL Server and delivered by a web front end. For scoping purposes below are a few system attributes and tools used to build and maintain the system.

Presentation layer Screens: 280+ Modules: 10

Reports: 132+

Business layer Services: 30+ Libraries: 20

DLLs: 18

Data layer

Tables: 1,300+ Views: 65+

Stored procedures:

3,400+

Functions: 150+ Total Size: 250 GB+

Interfaces Incoming:8 Outgoing:6

Partners: local and federal agencies.

Source Code Lines of Code: 180,000 +

Files: 7,500 +

Visual Studio 2022 .Net Core

.NET Framework v4.x ServiceStack

ASP.NET Web Forms v4.0

VB.NET

C# Telerik’s AJAX Controls

HTML

JavaScript and JQuery

Bootstrap

CSS

MS SQL Server MS SQL Server

Reporting Services

XML

JSON

RESTful API

4.3 PSA User Experience (UX) requirements

According to Digital.gov there are four key pillars to meet the federal web requirements related to design and user experience. One, design a consistent user experience. Two, continually test products and services to ensure they meet user needs. Three, listen to and act on customer feedback. And four, be device-agnostic. As per Digital.gov, great systems are rooted in customer understanding, the contractor must learn what PSA needs by observing stakeholders interact with the current system and its devices and address design issues that cause unnecessary work or confusion.

The resulting system must provide an improved user experience by including the following design elements and considerations:

a. Consistency: the system must have a uniform user interface that is easy to use and understand. Elements within the design must be consistent with each other such as buttons that are the same color, size, and in common locations, and follow common usage patterns. The user interface must look and behave consistently from one device to another (responsive design).

b. Seamless interactions: the system must provide seamless interactions when going from one screen to another on a single device or from one device to another.

https://digital.gov/resources/an-introduction-to-design

c. Colors: the system must use color to create depth and help stakeholders understand how to interact with the design.

d. Graphics and animation: the system must use purposeful graphics, charts, and animation to assist a user in taking an action, waiting for a result, providing instruction, alerting, or illustrating a given step in a process.

e. Easy to read font: the system must use readable typefaces and avoid decreasing the font sizes to display too much information.

f. Voice interfaces: if appropriate the system must use purposeful voice interface to receive information and to provide information. The system must provide visual feedback when the interface is in listening mode.

g. Smart forms: the system must provide smart forms and inputs with real-time validation.

A major pain point in the current system is capturing addresses. The new system must allow for a single line address entry and must validate it, verify it, and parse it at once.

When capturing phone numbers, the system must allow for unformatted and formatted entries and the system must ensure uniformity.

h. Dashboards: the system must provide dashboards that are clear, purposeful, user-centric, interactive and actionable. They must present data and convey the story behind it, guiding stakeholders toward making informed decisions without overwhelming them with details.

Interactivity must encourage exploration and therefore allow for filtering and sorting information, highlighting and drilling down.

i. Customization and personalization: the system must allow stakeholders to customize and/or personalize systems components. For example, in the case of dashboards a user must be able to rearrange components and hide or show components. In addition, grids showing lists of items must allow for multiple heading sort, filters, and exporting.

j. Reports: the system must provide reports that are accurate, consistent, aesthetically pleasing, efficient, and usable as described below.

The accuracy principle means the content of a report represents what it claims it does.

The consistency principle requires that the format and layout of a report is like prior issuances of the same report or other reports issued by the same team or unit. The appearance principle means that the report is aesthetically pleasing and professional-looking and includes proper alignments, use of white space, borders, shading, and color.

The efficiency principle involves ensuring that a standard report can be prepared as quickly and easily as possible, which often means utilizing automated or formulaic fields where possible. The usability principle relates to decision support for the report recipients. Therefore, data must be organized to allow for easy extraction by recipients, and it must be easily understood given the specific background(s) of the recipients.

k. Spellchecking: the system must provide built-in spellchecking capabilities in all text prompts and report building functionality.

l. Responsiveness: the system must be designed to minimize the time taken to respond to user inputs and external events to provide positive user experience. Responsiveness must be achieved through writing efficient algorithms, providing timely feedback, using parallel problem solutions (work ahead or delay processes), queue optimization, monitoring resource usage, and using predictive computing.

4.3 CMS Modernization – PRISM Functional Requirements

PSA has documented necessary enhancements to the system which are included in the companion document to this acquisition package titled “CMS Modernization Project: PRISM Functional Requirements” dated April 2025.

Drug Testing Specimen Collection (DTSC)

1.1. Find client and client profile

1.2. Lock up list and streamlined drug testing

1.3. Drug testing and sample collection

1.4. Random drug testing placement and schedules

1.5. Client photos functionality

1.6. Specimen boxing functionality

1.7. Appointment slips

1.8. Drug testing interfaces

1.9. Accessing the system

2. Client information (CI) and Criminal History (CH) information

2.1. Name, identifiers, birth/death, and Social Security information

2.2. Characteristics and language

2.3. Addresses, communications, and community ties

2.4. Education, employment, military service, and financial information

2.5. Health and substance use

2.6. Citizenship, travel and associates

2.7. Document Library

2.8. Criminal History and warrants

2.9. Sealing and Unsealing information

2.10. Release Services

2.11. Criminal History report

2.12. Criminal History interfaces

3. Risk-Based Supervision Services (RBS)

3.1. Release orders, programs and activities

3.2. Case Review

3.3. Dashboard alerts and responses to defendant conduct

3.4. Check-In, appointments, and event chronology

3.5. EM (electronic monitoring) alerts

3.6. Electronic notifications and messages (to defendants)

3.7. Supervision log

3.8. My Case Load, watch list and match list

3.9. Case assignment, reassignments, and alternates

3.10. Report writing, approval, and delegation

3.11. Case Audit functionality

3.12. Client reports

3.13. EM (Electronic Monitoring) Reports

3.14. Form Letters

3.15. Summary Reports

3.16. Court Letter Tracking

3.17. Supervision Interfaces

4. Treatment (TRT)

4.1. Treatment registration

4.2. Treatment client sessions

4.3. Treatment multiple client registration

4.4. Treatment group maintenance

4.5. Treatment notes

4.6. Group search

4.7. Treatment maintenance

4.8. Treatment Placements

4.9. Treatment reports- PSA STARS Reports

4.10. Audit Behavioral Health Entries

4.11. Drug Court Eligibility

4.12. Treatment interfaces

5. Diagnostic and Release Information (DRI)

5.1. Diagnostic processing screen

5.2. Diagnostic interview

5.3. Reports - PSR (Pretrial Services Report) List

5.4. Release orders, programs and activities

5.5. Arrests, case filing, and BACE

5.6. Diagnostic reports

5.7. FTA (failure to appear) log

5.8. Charge flagging and classification

5.9. Criminal history

5.10. Case folder management and tracking

5.11. Diagnostic Interfaces

6. Framework Functional Requirements

6.1. Records Management

6.2. System Security

6.3. System Administration

6.4. System Architecture

6.5. Other

5. Period of Performance The period of performance is one base year with four option years.

6. Place of Performance Tasks outlined in this PWS must be performed at the contractor’s site via remote connectivity except for functional testing that must be executed from PSA’s Headquarters in Washington, DC.

The Government will provide both development and test environments for the contractors to perform application development tasks. The Government will provide equipment capable of securely connecting to the agency’s network. Contractor personnel must work remotely within the continental United States and must be available during PSA’s business core hours of 8:30 AM through 5:00 PM Eastern Time. The Government will provide the contractor access to the government managed development environment between the hours of 6:30AM and 6:00PM Eastern Time on weekdays. The Government reserves the right to call a meeting in person with 24-hour advanced notice. The Government will provide a physical location that can be used by contractor personnel when onsite (i.e., conducting in-person meetings).

7. Applicable Documents The following document is included for reference:

CMS Modernization - PRISM Functional Requirements

The contractor must comply with the following agency policies:

PS1008 Records and Information Management PS4060 Personnel Security Program PS5000 Information Technology Security Program PS5002 Safeguarding PII PS5336 Acceptable Use Policy PS5335 Prohibition of Network Access and GFE use outside of the United States PS5510 Electronic and Information Technology Accessibility (508 Compliance) JPS1113 Privacy Recertification

Tasks performed under this PWS must acknowledge and follow all current federal statues;

policies; law and guidance applicable to the protection of Federal Communication and Federal Information System Technology.

Applicable Cyber Laws

The Clinger-Cohen Act of 1996 Privacy Act of 1974 as amended (5 U.S.C. 552a) The Federal Information Security Modernization Act (FISMA) of 2014 E-Government Act of 2002 (44 U.S.C. Chapters 35 and 36) Federal Information Technology Acquisition Reform Act (FITARA)

Applicable Frameworks & Standards

Federal Information Processing Standards: FIPS 140-2, FIPS 140-3, FIPS 199, FIPS 200, and FIPS 201-1

NIST SP 500-292 Cloud Computing Reference Architecture https://mypsa/Policies/Electronic%20and%20Information%20Technology%20Accessibility%20(508%20Compliance)%20E.D.%205.7.2019.pdf

NIST SP 800-37 Risk Management Framework NIST SP 800-53 Revision 5, Security and Privacy Controls for Information Systems and Organizations NIST SP 800-218 Secure Software Development Framework

Applicable Executive Orders & Memorandums

Executive Order 13556, The Controlled Unclassified Information (CUI) Program Executive Order 13800, Strengthening the Cybersecurity of Federal Networks and

Critical Infrastructure Executive Order 14028, Improving the Nations Cybersecurity Executive Order 14306, Sustaining Select Efforts to Strengthen the Nation's

Cybersecurity and Amending Executive Order 13694 and Executive Order 14144 Executive Order 14144, Strengthening and Promoting Innovation in the Nation’s

Cybersecurity Executive Order 14179, Removing Barriers to American Leadership in Artificial

Intelligence OMB Circular A-130, Managing Information as a Strategic Resource OMB Memorandum 22-09, Moving the US Government Toward Zero Trust

Cybersecurity Principles OMB Memorandum 22-18, Enhancing the Security of the Software Supply Chain through Secure Software Development Practices OMB Memorandum 24-15, Modernizing the Federal Risk and Authorization

Management Program OMB Memorandum 25-21, Accelerating Federal Use of AI through Innovation, Governance, and Public Trust

8. General Guidance

8.1 Project Management

The agency conducts projects using the project management principles from Project Management Institute (PMI). The contractor Project Manager must follow PMI project management principles when creating the following deliverables:

i. Project Plan

ii. Work breakdown structure (aka WBS)

iii. Risk Register

The contractor must develop project plans for each phase of the project. Each performance year represents a phase of the modernization project. The project plans must include a document detailing the plans for designing, developing, testing and staging the functional and technical requirements. The contractor must deliver a detailed project plan with tasks and completion timeframes; resource matrices; required hardware/software and component inventory; assumptions; dependencies; issues and risks. The contractor must include backup;

contingency; disaster recovery and performance as well as other key planning considerations.

The contractor must create and maintain the WBS. The contractor must develop and maintain a risk register. The contractor must report to the Government PM issues and dependencies impacting the product delivery. The project plan acceptance is crucial to the product delivery and management of the key tasks.

8.2 Records Management

In accordance to records management policy this PWS conforms to the following pertinent laws, codes and regulations; 44 U.S.C chapters 21, 29, 31 and 33; Freedom of Information Act (5 U.S.C. 552); Privacy Act (5 U.S.C. 552a); 36 CFR Part 1222 and Part 1228. In addition:

a) Contractor must treat all deliverables under the contract as the property of the U.S.

Government for which the Government Agency must have unlimited rights to use, dispose of, or disclose such data contained therein as it determines to be in the public interest.

b) Contractor must not create or maintain any records that are not specifically tied to or authorized by the contract using Government IT equipment and/or Government records.

c) Contractor must not retain, use, sell, or disseminate copies of any deliverable that contains information covered by the Privacy Act of 1974 or that which is generally protected by the Freedom of Information Act.

d) Contractor must not create or maintain any records containing any Government Agency records that are not specifically tied to or authorized by the contract.

e) The Government Agency owns the rights to all data/records produced as part of this contract.

f) The Government Agency owns the rights to all electronic information (electronic data, electronic information systems, electronic databases, etc.) and all supporting documentation created as part of this contract. Contractor must deliver sufficient technical documentation with all data deliverables to permit the agency to use the data.

g) Contractor must comply with Federal and Agency records management policies, including those policies associated with the safeguarding of records covered by the Privacy Act of 1974. These policies include the preservation of all records created or received regardless of format [paper, electronic, etc.] or mode of transmission [e-mail, fax, etc.] or state of completion [draft, final, etc.].

h) Contractor must not dispose of documents without the prior written consent of the Contracting Officer. The Agency and its contractors are responsible for preventing the alienation or unauthorized destruction of records, including all forms of mutilation. Willful and unlawful destruction, damage or alienation of Federal records is subject to the fines and penalties imposed by 18 U.S.C. 2701. The contractor must not remove records from the legal custody of the Agency or destroy records without regard to the provisions of the agency records schedules.

i) Contractor is required to obtain the Contracting Officer's approval prior to engaging in any contractual relationship (sub-contractor) in support of this contract requiring the disclosure of information, documentary material and/or records generated under, or relating to, this contract. The Contractor (and any sub-contractor) must abide by Government and Agency guidance for protecting sensitive and proprietary information.

8.3 Agile/Scrum

The contractor must use Agile Scrum methodology to manage the application development tasks in this project. The contractor must conduct the work to deliver as many of the required features as fast as possible. The contractor must provide project administration during the entire length of the contract (base year and option years).

The contractor must prepare user stories. The contractor must track progress and completion of all tasks and user stories. The contractor must facilitate and lead sprint planning and sprint review. The Government PM may request specific presentation formats for conducting sprint planning and sprint review.

8.4 Azure DevOps

The Agency uses Azure DevOps for project managing application development projects.

Azure pipelines are used for continuous integration / continuous development, testing and deployment. The contractor must work with the technical SMEs to leverage Azure DevOps while performing the development tasks of this contract.

8.5 Design Proposal/ Build Plan

The contractor must deliver design proposals with the project plan. The design proposal must be delivered in a combination of written and visual representations of the deliverables. The contractor may use documents, story boards, wireframes or similar methods to describe the design for the development deliverable.

9. General Project Tasks

9.1 Task 0 – On Boarding

The contractor must follow the instructions provided by the COR in providing contractor personnel clearance documents for key personnel assigned to perform tasks on the contract.

The contractor must adhere to all deadlines and appointment times communicated by the COR. The contractor must work to expedite the return of all required documents. The contractor should be aware that the Government will decline to initiate clearance for contractor personnel that cannot provide proof of US citizenship. All government credentials and equipment must be issued to contractor personnel from PSA Headquarter office at 633 Indiana Ave NW Washington, DC. The Government does not assume responsibility for travel expenses for contract personnel coming to PSA offices. Contract staff must appear in person to complete the (Personal Identity Verification) PIV process and receive government equipment. The estimated time for completion of for this task is five business weeks from the contract award.

9.2 Discovery

The contractor must work with the Government to ensure common understanding of the objectives and scope of the project. The contractor must review all documentation supplied by the Government; work with Government Application Development SME and technical stakeholders to conduct thorough review of the legacy CMS source code and database design;

also conduct interviews with Government Infrastructure SMEs for insights on the existing CMS infrastructure and the computing environment. The contractor must take into consideration all aspects of government supplied information from architecture review, code review, documentation review and government personnel interview. The contractor must work with the Government to document the discovery by digital recording. The Government must arrange a Zoom meeting for the contractor to discuss in detail the key aspects of the computing environment and existing application components with respect to the project scope and contract tasks. The contractor must perform and complete the discovery no later than 10 days following the completion of Task 0.

9.3 Requirements

The contractor must work with the Government PM to host meetings with Government Business Analyst, Government Product Team Lead, Government Product Team stakeholders, Government Records Manager SME, Government Application Development SME, Government Information Security SME, Government Infrastructure SME and Government Cloud Engineer SME to review functional and technical objectives. A series of meetings must be scheduled with government staff and contractor staff to review business processes and workflows; functional and technical requirements; and related documentation. The contractor must maintain a reference list of all functional and technical requirements. The contractor must reference the requirements list when developing user stories, tasks and EPICs.

9.4 Testing

The contractor must generate and execute testing plans and make them part of the user stories.

The contractor must recommend tools for testing. The testing procedures and automated scripts must test usability, functionality, and stress/performance. Working in conjunction with the Product Team stakeholders, Government Application Development SME, Government Information Security SME, Government Infrastructure SME and Government Cloud Engineer SME, the contractor must perform testing of the developed components to ensure its functionality and operation. The contractor must address, correct and retest uncovered defects.

The contractor must document test results whether successful or not. If a test is not successful, the contractor must take immediate remediation actions and once the issue(s) is/are solved the item must be retested. The contractor must provide all the artifacts and results at the end of the applicable sprint.

9.5 Information Security

The contractor must work with the Government Information Security SME to understand the security objectives for the project. The contractor must perform governance, risk and compliance (GRC) tasks in addition to recommending security mechanisms, security configurations and security controls. The contractor must assess the security of the existing CMS and operating environment. At the discretion of the Government, the contractor must recommend security enhancements for the existing CMS. The contractor must recommend modernization and security configurations, security controls, mechanisms and security tools to be designed, built, configured and integrated or implemented into the new system including the operating environment. The contractor must compile and provide reports for applicable cloud system and web application controls and provide the mapping between NIST, FedRamp and cloud security reference framework. The control mappings must cover the entirety of applicable security controls commensurate with the moderate risk classification and sensitivity of the system. The contractor must recommend modernization of encryption and data security within CMS. The contractor must work with the Government to implement a third-party solution for identification and authentication in the new system. The contractor must review the databases and recommend security improvements for the existing system. The contractor must offer guidance to the Government information security officer on secure configurations;

application settings; and software tools to improve system security.

The contractor must conduct the following information system security testing to identify and assess vulnerabilities within CMS and the new system to ensure the system can protect data and maintain functionality as intended.

• Vulnerability and Security Control Assessment – The contractor must conduct a risk assessment for the existing CMS in the base year. This involves identifying potential weaknesses in CMS such as misconfigurations, outdated software, or flaws in the code. The contractor must assess all applicable security controls for the existing CMS in the base year.

The contractor must deliver a security assessment report for the existing system in the base year. The government must provide directions to the contractor to conduct risk assessments at later phases of the modernization based upon the schedule of deliverables. The contractor must perform security control assessments in the base year and as part of phase two and five of the contract.

• Web Application Scan & Penetration Testing – Testers will simulate real-world attacks to see how easily they can exploit vulnerabilities in CMS and gain unauthorized access to CMS.

The main objective is to uncover vulnerabilities in CMS and evaluate the effectiveness of the system security controls, security policies and security measures such as firewalls and intrusion detection systems. Web application scanning must be conducted as part of security testing in all phases of the contract. Penetration Testing must be performed in the base year and all phases of the contract.

• Security Code Review – Examining the code for potential vulnerabilities and weaknesses.

The contractor must use a code review tool to identify security weaknesses. The contractor must conduct a code review on all code developed and delivered to the Government. The code review may be conducted on the existing CMS. The contractor must recommend a tool, and it must be approved by the Government to use in the code review and security testing.

The contractor must remediate all weaknesses and rectify any misconfigurations that are discovered during testing. The deliverable must be a report that details the test results and provides constructive feedback.

• Security Audit – The contractor must verify that the new system adheres to relevant federal security standards and regulations. The contractor must test whether the new system meets federal security standards and configuration requirements as determined by STIG, NIST, Cloud Security Framework and FedRAMP. The contractor must verify compliance with internal policies, industry standards and regulatory requirements. The contractor must conduct a security audit in the base year and as part of phases three and five of the contract.

9.6 Training

The contractor must develop training documentation including manuals, train-the-trainer sessions and video presentations. The contractor must create and deliver training for business and technical audiences. The contractor must deliver training at the request of the government on topics determined based on the needs of the project and product delivery. The contractor must create training to assist the Government in using the product once deployed and to assist the Government technical staff in maintaining the product, configurations and services associated with modernization. The contractor must submit all final training deliverables to the Government no later than 20 business days before the end of the performance period.

9.7 Hand-off

During the performance of this contract, the contractor must be privy to critically sensitive information and data regarding PSA, CSOSA and DOJ data flows; network devices and topology; and security vulnerabilities. The contractor is not authorized to create, copy, store, email or transmit data or information on a device that is not authorized by PSA for use with this contract. PSA does not have the ability, now nor beyond the scope of this contract, to actively monitor or control the security of contractor devices and networks. The agency does not accept redaction as a means for protecting critically sensitive information on a device/network not within the agency’s control. The contractor must not assume rights to any data or deliverables produced in the performance of these contract tasks. The contractor must surrender any digital form and physical documentation that contain Pretrial Services Agency (PSA) for District of Columbia proprietary information to include the following: account credentials for any application; enterprise network or service; application source code;

architectural diagrams; business workflows; cloud services and networking architecture; data mappings; data tables; database names and relationships; data flows; firewall and network IPs;

IP ranges and namespaces; resource names; server names; operating system information;

software/hardware and technology tools details; risk assessment reports and details; security assessment and vulnerability reports details; software installation keys; penetration testing data and reported results; system test results; web application scans and testing results at the end of the performance period. The contractor must provide an email acknowledgment of compliance at the end of the performance period of the contract.

10. Key Project Tasks

10. 1 Phase 1 - Software Development Services for the Framework and Drug Testing

Specimen Collection (DTSC) functionality Modernization in this functional component must include improved user experience and taking advantage of contemporary web technologies and techniques. The contractor must deliver functional requirements related to the drug testing specimen collection functionality.

Contractor must review the functional requirements document. The contractor must meet with product team stakeholders to collect and refine requirements. The contractor must deliver requirements related to this functionality. The contractor must review the functional requirements document. The contractor must meet with the product team stakeholders to collect and refine requirements. The Contractor must deliver requirements related to this functionality as outlined in CMS Modernization Project: PRISM Functional Requirements dated April 2025.

The Drug Testing Specimen Collection (DTSC) includes the following modules: find client, client profile, lockup list, streamlined drug testing, drug testing and sample collection, random drug testing placement and schedules, client photos functionality, specimen boxing functionality, appointment slips, drug testing interfaces, and accessing the system.

10.2 Phase 1 – Core Services

The contractor must architect the CMS to ensure each newly developed/enhanced module must be able to co-exist with the existing module in the legacy CMS. The contractor must make recommendations for modernizing the existing full tool stack. The contractor must build the bridge code/logic in the existing CMS as well as the new CMS so the new and legacy components seamlessly co-exist. The contractor must build the modern core framework which is the replacement for the existing core enterprise library below. The contractor must ensure the CMS application security be changed to accommodate multiple roles for users (currently each user can only associate with one role). The contractor must modernize application logging. The contractor must modernize the core framework to include the architecture and functionality in the legacy CMS core enterprise library. The contractor must deliver records management requirements in this phase. The contractor must deliver the necessary GUIs/applications to administer the application security.

Core Enterprise library - The purpose of the Core Enterprise library is to provide a set of core functionalities that can be used across multiple applications within PSA. In its present form, the library provides support for application logging, secure data access, exception handling, application security, and user identity management. The library also includes the code responsible for user authentication via the Agency's in-house Identity Provider (or security token service). The agency intends to replace the authentication in the existing CMS. At the discretion of the government, the contractor must recommend an alternative solution for identification and authentication for the core services of the new system. The contract must assist the government with the implementation of a third-party solution in the new system.

The contractor must recommend a photo application that can independently (stand-alone) work on different platforms such as iOS (iPad or iPhone) or Windows tablet/PC. The contractor must integrate the photo application into the new CMS.

The contractor must ensure any new reports created must fit into the current PRISM design whereby reports are set up (parameters defined, permissions granted, etc) and configured in the database with the administrator screens in PRISM to maintain.

The contractor must update existing PRISM reports related to the Drug Testing process, include but not limited to Appointment Slips, Labels (interview and drug testing labels), Drug Test Results Client Reports and Summary Reports modifications.

The contractor must review the database schema and design of the existing CMS. The contractor must make recommendations for improvements and a new schema design to be implemented with the new system.

Phase One deliverables must be delivered to the Government prior to the end of the base performance period.

10.3 Phase 2 – Software Development Services for the Client Information (CI) and Criminal History (CH) functionality

The contractor must refer to section 2 of the accompanying PRISM Functional Requirements document. This section is titled "Client information (CI) and Criminal History (CH) information" and it covers two major PRISM modules the Client (defendant) profile and the known Criminal History (internal, external, and/or juvenile). The contractor must work with the Government to implement the updated functionality.

Contractor must review the functional requirements document. The contractor must meet with product team stakeholders to collect and refine requirements. The contractor must deliver requirements related to this functionality.

The Client information (CI) includes the following modules: name, identifiers, birth/death, and Social Security information, characteristics, language, addresses, communications, community ties, education, employment, military service, financial information, health and substance use, citizenship, travel, associates, document library.

The CH information includes the following PRISM modules and screens: criminal history screens (internal, external, and juvenile), warrants, sealing and unsealing information, release services, criminal history report, and criminal history interfaces.

Phase Two deliverables must be delivered to the Government prior to the end of the first option performance period.

10.3 Phase 3 – Software Development Services for Risk Based Supervision Services (RBS) functionality

Modernization in this functional component must include improved user experience and taking advantage of contemporary web technologies and techniques. The contractor must deliver functional requirements related to the risk-based supervision services functionality.

This phase includes section 3, titled Risk Based Supervision Services of the accompanying PRISM Functional Requirements document.

Contractor must review the functional requirements document. The contractor must meet with product team stakeholders to collect and refine requirements. The contractor must deliver requirements related to this functionality.

The Risk-Based Services (RBS) section includes the following modules: release orders, team assignment, activities, case review, dashboard alerts, responses to defendant conduct, check-in, appointments, event chronology, electronic notifications, messages (to defendants), supervision log, my case load, watch list and match list, case assignment, case reassignments, alternates, report writing, approval, and delegation, case audit functionality, and reports.

Phase Three deliverables must be delivered to the Government prior to the end of the second

10.4 Phase 4 – Software Development Services for the Treatment functionality Modernization in this functional component must include improved user experience and taking advantage of contemporary web technologies and techniques. The contractor must deliver functional requirements related to treatment functionality. Contractor must review the functional requirements document. The contractor must refer to section 4, titled Treatment (TRT) of the accompanying PRISM Functional Requirements document. The contractor must meet with product team stakeholders to collect and refine requirements. The contractor must deliver requirements related to this functionality.

The Treatment (TRT) section includes the following modules: treatment registration, treatment client sessions, treatment multiple client registration, treatment group maintenance, treatment notes, group search, treatment maintenance, treatment placements, treatment reports and behavioral health services entry report.

Phase Four deliverables must be delivered to the Government prior to the end of the third

10.5 Phase 5 – Software Development Services for Diagnostic and Release Information (DRI) functionality

Modernization in this functional component must include improved user experience contemporary web technologies and techniques. The contractor must deliver functional requirements related to the diagnostic and release information functionality. Contractor must review the functional requirements document. The contractor must refer to section 5, titled Diagnostic and Release Information (DRI) of the accompanying PRISM Functional Requirements document. Contractor must meet with product team stakeholders to collect and refine requirements. Contractor must deliver requirements related to this functionality.

The Diagnostic and Release Information (DRI) section includes the following modules:

diagnostic processing screen, diagnostic interview, report - PSR (Pretrial Services Report), release orders, team assignment, activities, arrests, case filing, BACE, diagnostic reports, FTA (failure to appear) log, charge flagging and classification, criminal history, case folder management and tracking.

Phase Five deliverables must be delivered to the government prior to the end of the fourth

11. Contractor Quality Assurance The Government shall submit a Quality Assurance Surveillance Plan (QASP) for acceptance at the time of the contract award.

12. Deliverables Based on the size and complexity of the deliverables, the Government will take between five (5) and seven (7) business days for reviews, comments, or approval.