ESBD_443357_1755727878510_Public Safety Report System-QnA-Final.pdf

Public Safety Report System – Questions and Answers

ID Question/Answer 1 Is OCA seeking a Commercial O -the-Shelf solution or a custom solution?

OCA prefers a Commercial O -the-Shelf solution with configurations. However, if no such solution exists or is available, we will consider a custom solution.

2 Is Section 508 compliance required on all software and documentation?

As OCA is a government entity, the proposed solution should meet any applicable

ADA compliance requirements. This is currently set to WCAG 2.1 Level AA.

3 For data migration, is the vendor expected to do any sort of data cleansing or validation on the part of the migration? If so, can sample data snapshots be provided to assess cleanliness, and how many terabytes or gigabytes?

The vendor is expected to ensure that fields are mapped properly from the existing database to the new system and that all records have been converted into the new system. No other data cleansing or validation is anticipated. The current database is around 6GB.

4 Is DIR cooperative contract participation required for this RFO?

No. OCA seeks responses from any vendor that can provide a response to the

RFO.

5 Is there a technology standard that Texas prefers the system to use, such as

Java.net, SQL Server, Oracle?

Since the solution is required to be hosted/maintained in a vendor-controlled cloud, OCA has no technology standards other than those specified in the requirements workbook.

6 Is the current vendor eligible to submit a response to this RFO?

Yes. OCA seeks responses from any vendor that can provide a response to the

RFO.

7 What is the total number of users that will access the system?

The system has approximately 7,200 users.

8 How many clients are currently being served?

The system has approximately 7,200 users with di erent roles. See also question

29.

9 Will clients require access to a portal?

All users will require access to the system.

10 How many years of historical data will need to be migrated? Additionally, could you provide an estimate of the total data volume?

All data since the system’s inception in April 2022 will need to be converted. The current database is approximately 6GB and contains all necessary data.

11 Does your organization make referrals to external agencies? If so, will these agencies need access to the system? If yes, how many external users are anticipated?

For this system, OCA does not refer anyone to an external agency.

12 Do you require onsite services for rollout and training, or will o site/online options be acceptable?

O site/Online options for rollout and training will be acceptable.

13 What is the current technology stack (languages, frameworks, databases, hosting environment) for the existing Catalis-built Public Safety Report System?

The incumbent vendor may use any technology stack, as long as all Technology Requirements in the requirements workbook are met. The current system is hosted in an Azure government cloud and is CJIS compliant.

14 Is the current system built as a monolithic application or a modular/microservices-based architecture?

The system is provided in a “turn-key” fashion from the vendor. The internal architecture is unknown.

15 Which cloud provider currently hosts the system, and are there existing hosting agreements that would influence a transition?

The current system is hosted in the Azure government cloud – there are no existing hosting agreements as the system is provided in a “turn-key” fashion from the vendor.

16 How is authentication currently implemented (e.g., SSO, MFA, DPS authentication integration)?

Unknown at the application level. MFA is required and in-place. Authentication to DPS proceeds through the regular methods of gaining access to DPS systems including the use of individual ORI numbers, and TLETS usernames.

17 How does the system handle high availability and failover today?

The system is provided in a “turn-key” fashion from the vendor. The mechanics behind high-availability and failover are unknown. Expectations for high-availability and failover are in the Master Services Agreement, Section 7.2(a)(vii).

18 Are there known scalability limitations, e.g., performance degradation during peak bail-setting hours?

There are no known scalability limitations. At all times, the System is expected to maintain service levels described in the Service Level Requirements document.

19 What API management platform, if any, is in place for DPS, case management systems, and jail management systems integrations?

The vendor has constructed APIs for the entry of arrest data from jail systems and the export of bail information to local case management systems. DPS layers a products from OpenFox to allow for a secure connection to their systems to retrieve criminal history.

20 What audit logging capabilities exist today, and how is log retention handled?

We can trace any action in the system that a user makes based on their user profile, by requesting that information from the backend which the current vendor has direct access. Audit logs have been retained since the inception of the system in April 2022.

21 How is data validation currently implemented, and what gaps or issues have been identified?

The only current data validation that exists is date validation and required fields.

Issues identified with validation include (but are not limited to): text formats, impossible dates (in regards to a person’s age or an o ense date), special characters, typos, and duplicate information.

22 What are the technical details of the current integration with DPS (TLETS/NLETS) systems: protocols, security measures, authentication flows?

The TLETS/NLETS interface is a combination of products from OpenFox. This includes using sub-products like FoxTalk, Open Fox Markup Language (OFML) in an always open TCP connection. Details can be found on the DPS website. OCA intends to connect the selected O eror to DPS for connection.

23 Are there existing API integrations with local court CMS vendors, jail CMS vendors, or other law enforcement systems?

Yes, there is an active jail system integration.

24 How is the nightly BACPAC file delivered and processed: what format, protocol, and security measures are used?

The bacpac file is delivered to OCA nightly via SFTP through a known IP address along with an appropriate username/password.

25 Are there any existing batch processing or ETL routines beyond the BACPAC process?

Yes – OCA uses ETL routines to load the file for use in the dashboards and website. Please be aware that with the new system, OCA intends for the O eror to complete any necessary processes to provide the functionality of the dashboards and website. (See requirements #26 and #27 under Business Requirements.)

26 How does the system handle duplicate or conflicting records from multiple data sources?

There is currently no formalized process in place to handle duplicate or conflicting records from multiple data sources. OCA welcomes suggestions.

27 Which features of the current system are most heavily used by magistrates and law enforcement?

Magistrates, which generally fall into the category of judicial o icers, are the primary users of the final screen of making a bail decision. Law enforcement, if they are using the system, are more often involved in preparing the public safety report for judicial o icer review.

Law enforcement use the system to enter arrest information. Magistrates use the generated public safety report. Magistrates (or their sta ) then record their bail decision along with bond conditions and other information on the bail form.

28 What search capabilities exist for public safety reports, and how e ective are they considered to be?

In addition to reports from within the PSRS, there are two public portals to search for information on completed bail forms, and you can find the search capabilities here: https://topics.txcourts.gov/BailPublic and https://baildashboard.txcourts.gov/. Requirements 26-31 in the business requirements of the requirement workbook cover OCA’s reporting expectations.

29 How is role-based access managed across di erent user types (judges, prosecutors, law enforcement)?

Under the current system, when adding new users, they are assigned one of specific roles: Administrator, Certify Bail Form, Delete Record, Global Administrator, Integrator, Magistrate, and User.

30 Are there limitations in the current UI/UX that Authorized Users have flagged as pain points?

OCA has not identified any pain points in the current UI/UX.

31 How are updates to required bail forms currently deployed, and how long do they typically take to implement?

This question is unclear. Updates to bail forms would be deployed using the same process to deploy any other update to the system.

32 What current reporting and analytics tools are available within the system for

OCA and for courts?

In addition to reports from within the PSRS, there are two public portals to search for information on completed bail forms, and you can find the search capabilities here: https://topics.txcourts.gov/BailPublic and https://baildashboard.txcourts.gov/. Requirements 26-31 in the business requirements of the requirement workbook cover OCA’s reporting expectations.

33 What is the current average response time for user support requests?

For the month of July 2025, the average response time for user support requests was same business day.

34 Are support tickets tracked in a dedicated ticketing system with metrics available?

Yes – tracked by the vendor.

35 How is user onboarding and training conducted beyond the limited virtual webinars and calls?

There is nothing additional being o ered at this time.

36 Have there been issues with system adoption due to lack of training or system complexity?

This system is required to be used by magistrates when setting bail for defendants charged with a class B misdemeanor (or higher) category of o ense.

37 Which data sources (bail forms, DPS data, CMS/jail CMS data, CBO-related data) are considered mission-critical and must be preserved in the new system?

All data in relation to user profiles, audit logs, arrest information, bail forms and conditions stored in the existing system are critical and must be migrated to the new system.

38 Is historical data migration required for all past records, or will only recent data be migrated?

All data in relation to user profiles, audit logs, arrest information, bail forms and conditions must be migrated.

39 Are there any data cleanup or normalization initiatives planned before migration?

No.

40 Which current workflows must remain unchanged to avoid retraining challenges?

OCA expects the system to conform to the requirements and service levels specified. No workflows are required to stay the same.

41 Are there workflows in the existing system that should be reengineered or automated in the new system?

OCA expects the system to conform to the requirements and service levels specified. No workflows are required to stay the same.

42 What are the primary reasons for pursuing a replacement instead of continuing to enhance the Catalis-built system?

The initial contract for the PSRS will expire on August 31, 2026 and OCA seeks cloud services for hosting the PSRS.

43 Were there past upgrades or enhancement attempts that failed or proved too costly/di icult?

Yes. There was one material enhancement attempt that failed and was fixed.

44 Are there vendor lock-in concerns with the current provider that the new solution should avoid?

No.

45 Is there interest in reusing any existing system components or code in the new system?

The system is provided in a “turn-key” fashion from the vendor. OCA does not own or have access to any existing system components or code.

46 How many of the features described in the RFO are new capabilities versus enhancements of existing functionality?

In addition to this RFO being available on ESBD, O erors can look through the awarded postings and see the requirements workbook of the current system (212- 22-0177) to compare di erences.

47 Are there legislative changes on the horizon that may require entirely new modules or features?

No. The requirements posted contemplate changes from the last legislative session (89th – 2025). The next opportunity for legislative changes will be in the regular session in 2027.

48 Is there a desire to include advanced reporting, dashboards, or analytics beyond what is currently available?

Yes – See business requirements #26-31 for reporting expectations.

49 Should the new system allow for custom queries and reports by Authorized

Users without developer intervention?

The new system may allow custom queries and reports, but it is not required. See business requirements #26-31 for reporting expectations.

50 Is dynamic form generation intended to cover all standardized bail-related forms, or only select ones?

All standardized bail-related forms.

51 Are there plans to expand the API library to support more vendor integrations than today?

All planned APIs are detailed in the requirements workbook.

52 Does OCA have a preferred cloud provider or technology stack for future solutions? Are there state security, accessibility, or interoperability standards that must dictate technology choices?

No. If the technology requirements, including security requirements, are met, OCA has no preference.

53 Does the system need to support o line or low-bandwidth scenarios for rural courts?

See Technology Requirement #4 in the Requirements Workbook.

54 Are mobile or tablet-based interfaces a requirement for the new system?

Yes- See Technology Requirement #4 in the Requirements Workbook.

55 Will the new system require integration with statewide SSO or other enterprise authentication services?

No.

56 What is the desired timeline from contract award to production go-live?

OCA desires a timeline that provides a high quality solution that performs the statement of work, meets the requirements and maintains service levels.

57 Will there be a phased rollout by jurisdiction, or is a statewide cutover preferred?

A statewide cutover is preferred.

58 Are there blackout periods (e.g., legislative sessions) during which major system changes cannot occur?

There are no blackout periods.

59 How far in advance of the August 31, 2026 contract end date should the new system be fully operational?

This date of the system to be fully operational is negotiable. OCA desires a timeline that provides a high quality solution that performs the statement of work, meets the requirements and maintains service levels.

60 Is there a desired overlap period where both systems run in parallel for validation and training?

No, however, OCA expects that the new system be available for testing, validation and training (See Statement of Work) prior to switching to production.

61 What is the expected cadence for post-go-live enhancements and legislative update cycles?

The timelines for post-go-live enhancements are worked mutually between OCA and the vendor. Timelines for legislative updates are dictated by the Legislature.

The response times for all requests are outlined in the Service Level Requirements.

62 OCA notes approximately 24 court CMS vendors and an unknown number of jail CMS vendors statewide. Could you please clarify which CMS and jail products (including versions) OCA expects to be “connected” on Day 1 versus those that may be phased in later?

While OCA expects the APIs to be ready for production connections on Day 1, OCA realizes that the connection heavily depends on the readiness of the case management or jail management systems. These systems would be phased in as they become available.

63 Will the selected vendor be responsible for building and maintaining vendor-specific adapters, or will OCA enforce a single canonical API and require local vendors to conform? The SOW tasks us with meeting vendors, providing API documentation, and assisting with connectivity, while the technical requirements mandate OAS/WS* specifications.

The O eror will be required to build inbound and outbound APIs as presented in the requirements workbook. OCA will enforce a single canonical API and require outside vendors to conform. The SOW details what the expectations of the O eror are with regards to supporting the API(s).

64 Does OCA have any metrics or analytics regarding usage of the Public Bail Dashboard that can be shared?

No.

65 Can OCA provide the data schema for the TLETS/NLETS API? Additionally, is the data provided in JSON, XML, CSV, or another format?

The TLETS/NLETS interface is a combination of products from OpenFox. This includes using sub-products like FoxTalk, Open Fox Markup Language (OFML) in an always open TCP connection. Details can be found on the DPS website. OCA intends to connect the selected O eror to DPS for connection.

66 Would it be possible to receive the current database schema for the existing system?

OCA will provide a copy of the current database to the awarded O eror.

67 Does the TLETS/NLETS API data need to be updated more than once, or is a single retrieval su icient?

At the point in the process where criminal history is pulled, the data pull from

TLETS/NLETS occurs once (single retrieval), then gets processed in the system upon arrival. If bail is modified, another single retrieval criminal history pull would occur.

68 Would OCA be open to a hybrid build model for cost savings, where o shore resources do not access client data? Alternatively, would Canadian resources be permitted, as has been allowed in other state projects?

See Section 20.4 of the Master Services Agreement.

69 We would like to respectfully request a two-week extension to the proposal submission deadline to ensure a thorough and high-quality response.

Any change to the submission deadline will be posted to the ESBD. At this time, no extension to the submission deadline is anticipated.

70 Can we get access to review the current Catalis system before it expires in August 2026?

Only authorized users and those with the proper CJIS Certifications may be allowed access to the Public Safety Report System. There are online instructional, informational and training videos posted on our website (https://txcourts.gov/bail/training-education/ ) that show the current system.

71 What's the data structure, volume, and exact format of the 1.7 million bail forms we need to migrate?

The bail forms needing to migrate are stored in a SQL database. OCA can make available a BACPAC file that contains the data to the awarded O eror.

72 What's the process and timeline for getting the vendor approved for DPS system access?

All employees of the vendor that will be working in the system must be CJIS Certified and fingerprinted. The CJIS classes can be taken online. Fingerprinting is coordinated between DPS and the vendor. OCA will work with the awarded O eror to make the process and timeline as e icient as possible.

73 Are there existing and recent API documentation or integration guides we can reference?

Yes. This information will be provided to the awarded O eror.

74 What specific CJIS compliance verification process will the vendor need to complete?

All employees of the vendor that will be working in the system must be CJIS

Certified and fingerprinted. The CJIS classes can be taken online. Fingerprinting is coordinated between DPS and the vendor. OCA will work with the awarded O eror to make the process and timeline as e icient as possible.

75 Are there Texas-specific security requirements beyond federal CJIS policy?

In addition to CJIS (see Technology Requirement #3), the system must also meet

Texas Administrative Code Chapter 202 (see Technology Requirement #2).

76 What is the current tech stack (frontend, backend, etc)?

The incumbent vendor may use any technology stack, as long as all Technology

Requirements in the requirements workbook are met. The current system is hosted in an Azure government cloud and is CJIS compliant.

77 Would the UI/UX need to be responsive?

While responsive design is not a specific requirement, the system is required to run on laptops, desktops, and mobile devices (See Technology Requirement #4 in the requirements workbook).

78 Can you provide the current number and types of integrations (REST, SOAP, Batch, Streaming)?

The current system integrates with arresting entities (inbound) and case management systems (outbound) via REST based integrations and JSON data.

Please see the requirements workbook for API requirements of the new system.

79 Will there be a requirement to support any language(s) other than U.S.

english?

No.

80 Are there any dependencies on technology from third-parties that is not yet deployed to a production service?

No.

81 Will there be self-service registration?

There is no specific requirement for self-service registration. All O erors are encouraged to include any additional features that di erentiate their products as part of the Solution Overview (Section 5.A, of the O eror’s response).

82 How will users be vetted and role assignments happen? (Manual, automated, Hbrid?)

Role assignments are manually made by local administrative users and/or OCA global administrators.

83 What is the required user session timeout if any?

To be determined, but a maximum time of 30 minutes, per CJIS Security Policy.

84 What is the required Inactivity timeout?

To be determined, but a maximum time of 30 minutes, per CJIS Security Policy.

85 SLR-10: How does this SLR metric apply to during regular support business hours and after-hours?

It is anticipated to include regular support hours, which will be finally determined between OCA and the vendor. If this is not specific enough, please provide proposed language in your response.

86 For SLR-12 – does this apply to all defect levels?

Yes.

87 Section 4 Notification of Problems - What is the definition in the instance of a

“problem”?

Problem is defined in Exhibit 1: Definitions of the Master Services Agreement

(MSA).

88 What is the required timeline for implementing a fully live solution (including development, testing, implementation, training)? What are the consequences of not meeting the required timeline?

OCA desires a timeline that provides a high-quality solution that performs the statement of work, meets the requirements and maintains service levels. Failure to meet the required timeline may result in the exercise of any relief provided under the MSA and the laws of the State of Texas.

89 How will the State measure service levels—are “availability” and “response time” tied to user-reported incidents or system monitoring data? Will SLA response/resolution times vary by incident type (e.g., login issues vs. API outage vs. DPS data retrieval failures)?

OCA seeks to ensure that the system is operating e iciently and is responsive to users as appropriate. If this is not specific enough, please provide proposed language in your response.

90 Will the vendor�s sta and development team be required to submit fingerprints? Will OCA conduct a background check?

See questions #74 and #91.

91 Will the vendor�s sta be required to complete a CJIS security training and obtain a CJIS certification?

All employees of the vendor that will be working in the system must be CJIS

Certified and fingerprinted. The CJIS classes can be taken online. Fingerprinting is coordinated between DPS and the vendor. OCA will work with the awarded O eror to make the process and timeline as e icient as possible.

92 Will the OCA require the usage of a HUB, if so is the requirement 21.1%, 26% or another amount?

OCA encourages the use of a HUB, but it is not required.

93 Would a good faith e ort, associated with HUB, without sub-contracting meet the requirements? How does it factor into evaluation?

Information regarding HUB requirements and HUB forms are available from the

Texas Comptroller of Public Accounts here:

https://comptroller.texas.gov/purchasing/vendor/hub/