ESBD_443357_1754488294863_Attachment 3 - Requirements Response Workbook Final.pdf

RFO 212-25-0959

ATTACHMENT 3: REQUIREMENTS RESPONSE WORKBOOK

Texas Office of Court Administration Public Safety Report System

Attachment 3: Requirements Response Workbook

ATTACHMENT 3: REQUIREMENTS RESPONSE WORKBOOK

1 Overview and Instructions This attachment contains the detailed requirements for the Public Safety Report System. Offerors should insert the appropriate response in the Offeror Response Code and Offeror Comments columns for each requirement.

Please also note:

• An omitted response will be assumed to be the same as a response code of “N”.

• Only one (1) response per requirement will be accepted.

For each requirement, one of the following responses must be selected:

Response Code

Definition Additional Notes

O Out of the Box - The Offeror provides the functionality from its own code base. No customizing, working around, or configuration is required. The functionality must be installed and operational at other sites and be able to be demonstrated to

OCA.

Additional comments from Offeror are optional.

N No - Not included in the proposed solution. Additional comments from Offeror are optional.

G Configuration - The functionality can be accomplished with the Offeror's solution, but some configuration is required. The requirement will be met through configuration changes to settings of tables, switches, rules, or user experience without modification or customization to the source code.

Indicate in the comments:

• What will need configuration

• Who is expected to perform the configuration (Offeror, OCA, the Node Administrator)

• Level of complexity (Very complex to Not complex)

C Customization - The functionality can be accomplished with the Offeror's solution, but some customizing or work around is required. This would include custom code developed to perform specific functions or validations outside the standard code.

Indicate in the comments:

• What will need customization

• Who is expected to perform the customization (Offeror, OCA, the Node Administrator)

• Level of complexity (Very complex to Not complex)

3 3rd Party Integration - The Offeror has established a relationship with a business partner to provide this functionality, which is fully integrated (data, process, application) with the proposed solution. If the proposed solution includes a third-party component, Indicate in the comments:

• Name of the third-party package

• Integration/Interface services provided including if configuration or customization is needed

Attachment 3: Requirements Response Workbook the Offeror as the prime must include all initial and on-going costs in its bid.

F Future Feature - The functionality will be met with a particular feature that is in development.

Indicate in the comments:

• Explanation of the new feature

• Expected date made available

Offerors must insert an explanation for how a requirement will be met in the Offeror Comment column when responding with a code of G, C, 3, or F, or if the requirement explicitly requests the Offeror to provide a comment. If Offerors do not provide a comment when explicitly requested, the requirement will be given the lowest evaluation score. Offeror responses with code O or N do not require explanation.

Within the requirements below, several system roles are mentioned. They are defined as follows:

1. Authorized User – any person or entity with access to the System, including, but not limited to, judges, court staff, probation office staff, pre-trial office staff, law enforcement and prosecutors.

2. Global Administrator – this is typically a person at OCA or the Offeror that has access to all facets of the system.

3. Node - a collection of Authorized Users as designated by OCA.

4. Node Administrator –person with permissions to control all configurations for a Node.

Attachment 3: Requirements Workbook

2 Business Requirements ID Category Requirement Offeror

Response Code

Offeror Comments

01 Role-based Security Ability to have Global Administrator(s) with the ability to:

1. Add/modify/disable/delete Authorized Users within the system.

This includes changing the user’s registered email address and resetting any multi-factor authentication settings.

2. Provide appropriate role-based security to Authorized Users within the system.

3. Upload and configure DPS offense codes including dates those codes are valid and marking codes that make a defendant ineligible for personal bond and marking default bond conditions for offenses.

4. Add/modify/disable discretionary bond condition categories to be selected when a Node Administrator creates/modifies a discretionary bond condition.

5. Expunge individual records from the system including all screens, reports, and data files.

6. Expunge records through a batch process by uploading a CSV file containing the name, date of birth, and arrest date of the defendant to be expunged.

7. Indicate which Nodes can use the API to insert completed bail forms into the system.

8. Configure the number of days in which incomplete bail forms will be deleted from the system.

9. Merge duplicate bail forms.

10. Monitor the connection between the system and TLETS in real-time to see the number of connections and whether TLETS is responsive.

11. Add/modify listing of district attorney notification email addresses for each county.

Describe the configuration items the Global Administrator can maintain.

ID Category Requirement Offeror Response Code

Offeror Comments

12. Add/modify listing of county officials appointed by the local administrative judge to receive notifications of an additional felony offense occurring outside the county.

02 Role-based Security Ability to have Node Administrator(s) with the ability to:

1. Add/modify/disable Authorized Users within their Node.

2. Provide appropriate role-based security to Authorized Users

(Magistrate, Chief of Police, or Sheriff's designee).

3. Add/modify/disable discretionary bond conditions, including bond condition category, that can be used within their Node.

4. Customize default discretionary bond conditions per magistrate level user within their Node.

Describe the configuration items the Node Administrator can maintain.

03 Role-based Security Provide all Authorized Users with a user profile that contains at a minimum:

• First name

• Last name

• Email address (which must go through a verification process)

• Phone number

• TLETS User ID

• TLETS certification

• Date of last TLETS certification

Describe any additional information collected in the user profile.

04 Role-based Security Provide Node Administrators access to a Node profile that contains at the minimum:

• ORI Number

• Email address to send system notifications and announcements

• Email address to send notifications of attorney appointment requests

Describe any additional information collected in the Node profile.

05 Arrest Entry Ability for Authorized Users with appropriate credentials to insert defendant's name, aliases, immigration status and date of birth, SID # and FBI #, and the data elements of the live scan, race/ethnicity, gender, cause numbers, if available, and the offense code(s), including any enhancements

Response Code

Offeror Comments or modifiers for which the defendant was arrested, and date/time and zip code of arrest. This includes an indicator if the person is in-custody or not in-custody.

06 Arrest Entry Ability of the system to alert the Authorized User upon an attempt of duplicate entry of defendant name/date of birth/arrest date/time/offense code.

07 Arrest Entry Provide an API for authorized systems to securely enter defendant and arrest information.

08 TLETS Data Pull Based on the arrest data entered, ability to use/operate/support the OpenFox Message Switch API, provided by DPS, to access TLETS and NLETS to process and display complete and accurate criminal history, protective orders, pretrial release status, parole status and active warrants from Texas and other states, including:

• previous misdemeanor or felony convictions and dismissals (including with or without prejudice if available)

• pending charges

• any previous sentences imposing a term of confinement

• any previous convictions or pending charges for offenses involving violence as specified in CCP 17.03 (b-3)(2)

• previous failures of the defendant to appear in court following release on bail

• current bail status and conditions of release

• pretrial release status

• community supervision, parole, or mandatory supervision status

• outstanding warrants, including warrant for violation of any community supervision condition and warrant issued in connection with parole or mandatory supervision issued by Pardons and Paroles Board or Director

• any current protective orders

Response Code

Offeror Comments

Provide monitoring services to confirm the criminal history information received from DPS required to be included in the public safety report is being accurately and completely captured in the public safety report.

09 TLETS Data Pull Provide a notification to the Global Administrators if the system is unable to interact with the DPS system for at least 15 minutes continuously, followed by another notification once the connection is recovered.

10 TLETS Data Pull Automatically delete pulled TLETS Data after 30 days.

11 Public Safety Report Ability to display/generate public safety report that displays the following:

• the requirements for setting bail under Art. 17.15, Code of Criminal Procedure, and list each factor provided by Art. 17.15(a)

• defendant’s name and date of birth, and if impracticable, other identifying information, the cause number of the case, if available, and the offense for which the defendant was arrested

• eligibility of the defendant for a personal bond based on entered information and criminal history derived from data received from

DPS

• the data pulled from TLETS for each defendant in summary form, excluding juvenile criminal history and dismissed cases

• previous failures of the defendant to appear in court following release on bail.

12 Public Safety Report If confirmed by the Authorized User that:

• The correct defendant is identified

• The arrested offense(s) is a felony

• The defendant has a completed bail form for a felony offense in the system in a different jurisdiction(s) (e.g., court, county, municipality or judicial officer)

The system must:

• Alert the Authorized User that the defendant is possibly out on bail on a felony offense in a different jurisdiction (e.g., court, county, municipality or judicial officer)

Response Code

Offeror Comments

• Provide the ability for the Authorized User to send notification of arrest/charge(s) via email to the other jurisdiction(s)/Nodes(s) email address maintained by the system

13 Public Safety Report Ability of the system to provide information regarding the applicability of any required or discretionary bond conditions.

14 Public Safety Report Ability of the system to alert the Authorized User if a defendant has been convicted of a violent offense.

15 Public Safety Report Ability for Authorized User to provide financial information that can be used by the magistrate.

16 Pending Magistrations Provide a searchable listing of pending magistrations for Authorized Users in a Node, and globally for Global Administrators. At a minimum, the columns in the listing must include:

• Defendant Name (Exact and SoundEx)

• Date of Birth

• Arrest Date/time

• Cause Number

• Time since arrest

• DPS data pull status

• Public safety report creation date/time

• Public safety report created by

17 Pending Magistrations Ability of the system to automatically delete pending magistrations that have not been completed in a timely manner (as configured by the Global Administrator). This includes displaying an alert to the Node Administrator that <number> of magistrations will be deleted in the next 30 days with a link to a listing of incomplete magistrations.

18 Bail Form Completion Ability for a magistrate, judge, sheriff, peace officer, or jailer who sets bail to complete a bail form for a defendant charged with an offense punishable as a Class B misdemeanor or any higher category of offense.

Class C misdemeanor is optional.

Response Code

Offeror Comments

The bail form must have:

1. Cause number (if available) the defendant ’s name, date of birth, and offense for which the defendant was arrested.

2. If no information was returned from DPS, an indicator that an attempt to pull information was made.

3. Name and office or position of the person setting bail.

4. Bail type, by offense (granted personal bond with or without conditions; granted surety or cash bond with or without conditions; or denied bail in accordance with the Texas Constitution and other law).

5. Amount of the bail, and any conditions of bail; If multiple offenses are indicated, an indication of which bail condition, type, and amount applies to each offense.

6. If a bail condition has sensitive information, such as a victim name in it, an indicator that sensitive information is included.

7. An indicator that the form is the original bail form or a modified bail form for the arrest event.

8. If the defendant is under 18 at the time of arrest, an indicator that the defendant has been certified as an adult.

9. An indicator if the defendant requested an attorney be appointed, and if so, counsel request date, indigency application ruling date, and the date counsel appointed (if granted).

10. An indicator if the defendant qualifies for mandatory bond release under the Code of Criminal Procedure chapter 17.151.

11. An indicator that the form was completed within 48 hours arrest and a free-text comment box to explain if the time standard was not met.

12. An indicator for each individual charge that no probable cause was found.

13. A certification that the person considered each factor provided by Article 17.15(a), Code of Criminal Procedure.

Response Code

Offeror Comments

14. A certification that the person considered the information provided by the public safety report system.

15. Be electronically signed and certified by the person setting the bail at the time of completion or by routing.

16. The date and time the bail form was initially created, last modified, and certified.

19 Bail Form Completion Ability of the system to automatically send the completed bail form for violent offenses to the email maintained by the system for the district attorney with jurisdiction over cases magistrated by the Authorized Users in a Node.

20 Bail Form Completion Provide an API for Nodes configured by the Global Administrator to add completed bail forms to the system.

21 Bail Form Completion Ability for magistrate or magistrate’s designee to generate a standardized bail order.

22 Bail Form Completion Ability for magistrate or magistrate's designee to provide:

• notice to the defendant on a form

• copy of the completed bail form

• copy of the bail order if the standardized bail order form used

23 Bail Form Completion Provide a searchable listing of completed bail forms for Authorized Users in a Node, and globally for Global Administrators. At a minimum, the columns in the listing must include:

• Defendant Name (Exact and SoundEx)

• Date of Birth

• Arrest Date/time

• Cause Number

• Magistration Date/time

• Indicator that magistration completed within 48 hours

• Indicator that bail form completed within 48 hours

24 Bail Form Completion Ability for magistrate or magistrate’s designee to correct a completed bail form after it has been completed.

Response Code

Offeror Comments

25 Bail Form Completion Ability for a Authorized User to create a bail modification. Using the original bail form, the system should:

• Create a duplicate bail form and indicate that it is a modification of the original form.

• Be related to the original bail form and any other modifications so that a timeline of bail forms can be derived.

• Use the defendant arrest information from the original form.

• Pull the criminal history as of the modification date.

• Present the bail form to the magistrate for modification and certification.

26 Reporting Provide a publicly accessible website that allows the public to search completed bail forms by:

• Defendant Name

• Cause Number

• Jurisdiction (e.g., court, county, or municipality)Offense(s)

This includes the ability to export and download search results into an excel or CSV file.

Upon selection from the search results, the public should be shown a detailed screen to include the same elements as seen on https://topics.txcourts.gov (view details of a bail form). Additionally, bail conditions that do not contain sensitive information should also be shown.

27 Reporting Provide a secured website that allows attorneys in the state to search completed bail forms in the same manner as the publicly accessible website with all bail conditions.

28 Reporting Provide and maintain an API connection to the OCA data warehouse to transmit completed bail forms daily.

29 Reporting Provide the following reports for a given timeframe:

https://topics.txcourts.gov/

Response Code

Offeror Comments

1. Number of defendants for whom bail was set after arrest (original bail forms), by each category of offense, by offense code, by bond type, by magistrate type.

2. Number of defendants for whom bail was modified, by each category of offense, by offense code, by bond type, by jurisdiction (e.g., court, county, municipality or judicial officer) type.

3. For Node Administrators (restricted to Authorized Users in their Node) and for Global Administrators (all Authorized Users)

a. Audit logs of Authorized Users accessing criminal history reports with date/time searched and name of defendant.

b. Listing of active and inactive Authorized Users including contact information, date of last login, and date of TLETs certification expiration.

30 Reporting Ability to display summary statistics by timeframe to the public such as (but not limited to) the existing dashboards found at https://baildashboard.txcourts.gov

31 Reporting Ability to print public safety report and bail form.

https://baildashboard.txcourts.gov/

Public Safety Reporting System

3 Technology Requirements ID Category Requirement Offeror

Response Code

Offeror Comments

01 Global Provide access to multiple environments such as test and staging environments, that mirror the production environment configurations, services, user role-based security, and interfaces.

Describe proposed environments.

02 Global Comply and maintain compliance with Texas Administrative Code (TAC) Chapter 202 (security standards), Chapter 206 (accessibility standards for websites), Chapter 213 (accessibility standards for anything else), and WCAG 2.1. This includes the implementation of standard security controls as outlined in the DIR Security Control Catalog (see https://dir.texas.gov/sites/default/files/2022- 01/DIR%20Security%20Control%20Standards%20Catalog%202.0.pdf).

03 Global Hosted in a CJIS compliant cloud, configured and maintained by the Offeror.

04 Global Provide a Solution that can run on an internet connected device utilizing any commonly utilized browsers (Chrome, Safari, Edge - versions back to n-2) without any browser plug-ins, extensions, or add-ons. Ensure Solution stays compatible with browser updates/versions.

05 Global All SOAP APIs must include up-to-date Web Services Description Language (WISDL) files that describe the webservice and is provided to others needing access to the APIs.

06 Global All REST APIs must adhere to the Open API Specification (OAS) as defined by the Open API initiative. This includes the delivery of a comprehensive Open API Document (in YAML or JSON format) for each API developed under this Agreement, describing its structure, endpoints, parameters, and responses.

07 Global Perform upgrades to the system without OCA or Node Administrators having to perform any reconfiguration. This includes regular infrastructure patching and security related patching and maintenance to APIs to ensure continued connectivity and data flow.

08 Global Provide a space on publicly available web page that allows Global Administrator to display text for system notification and outages.

09 Global Facilitate and provide technical support to Nodes and their vendors connecting to the API during implementation and provide ongoing operational support on issues as it relates to the API.

https://dir.texas.gov/sites/default/files/2022-01/DIR%20Security%20Control%20Standards%20Catalog%202.0.pdf https://dir.texas.gov/sites/default/files/2022-01/DIR%20Security%20Control%20Standards%20Catalog%202.0.pdf

Public Safety Reporting System

10 Global Facilitate and provide technical support to Authorized Users entering or modifying data through the user interface.

11 Security Generate reports reflecting user activity, metrics, and audit trails of system actions.

12 Security Encrypt data during transit and at rest using a supported secure protocol. Expressly disallow security protocols that are no longer supported or secure.

13 Security Alert the Authorized User that their credentials have already logged into the system through another session.

14 Security Provide monitoring services to detect, prevent, and report unauthorized access attempts to the system.

Describe how this would be implemented.

15 Security When an end user adds or modifies email addresses via the public website, the System must validate that the email address added are valid and link to the end-user.

16 Security Allow system to permit/restrict access to components, system functions, reports, and data based on user and/or user group or role.

17 Usability Provide on-screen help for Authorized Users to assist with standard system usage and functions.

18 Usability Highlight fields which must be completed and prevent Authorized Users from proceeding to the next screen until valid information is entered.

19 Usability Prevent errors or repetitive requests from inadvertent multiple clicks by a user.

20 Usability Highlight errors and prompt user for correction.

21 Usability Display visual indicators to denote that a transaction is in progress or complete.

22 Usability Hide/not display functions that are not available to a user based on permissions.

23 Usability Place common information in a consistent location on each screen.

24 Usability When using the mouse, the scroll-wheel must be interpreted as scrolling up/down on the screen.

25 Usability When presenting a page, the cursor should automatically be positioned in the first editable field. The next field should be presented upon hitting the tab key.

26 Usability When data is shown on the screen in a tabular format, the data must be sortable and groupable on columns. Columns must be resizable to fit the data.