Exhibit_A.9_-_JMS_Interfaces_25-P-147JRD.pdf

JMS Exhibit A.9 Interfaces Page 1 of 11

Exhibit A.9 – JMS Interfaces

A. Current Configuration Interface Overview

The current JMS system has multiple interfaces. Most of these interfaces have some added functionality which will be described. This is a list of the interfaces with our current JMS System. Most of these are explained in this overview; a few will have an additional document(s).

1. AFIS

2. Axon Body Cams

3. BizTalk/MSMQ

4. Body Scanners

5. CoreEMR

6. Database Replication

7. IVR (IC Solutions)

8. Public/Intake Displays

9. FDLE Rapid ID

10. Handhelds

11. JMS Commissary and Banking (Keefe)

12. LEO Site

13. FACES

14. Public Mugshot Site

15. Sheriff Views

16. State Attorney Views

17. Social Security Administration Request

18. Statute Tables

19. Tablets (Smart Communication)

20. Video Visitation (IC Solutions)

21. VINES

22. WebFOCUS

JMS Exhibit A.9 Interfaces Page 2 of 11

B. Interface Overviews

1. AFIS

The interface between the Jail Management System (JMS) and the Florida Department of Law Enforcement (FDLE) supports two outgoing and two incoming message types. Before any data is transmitted, an auto-generated entry is created and sent to the ID/Receiving Livescan machine for intake processing. This entry is pre-populated with the inmate’s demographic information, booking number, and mugshot. Once fingerprints are captured, the record is automatically transmitted to

FDLE.

FDLE responds with a message containing the Offender-Based Tracking System (OBTS) number, and potentially the State Identification (SID) number. These identifiers are automatically updated in the JMS.

An update transaction is triggered when the following three conditions are met:

The booking officer selects "Process Complete" for the inmate.

The Automated Fingerprint Identification System (AFIS) operator selects "Process Complete."

The SRETD message containing the OBTS is received.

Once all three conditions are fulfilled, a message including the inmate’s charges and mugshot is sent to FDLE. FDLE responds with a message that always includes the SID and OBTS, both of which are automatically updated in the JMS.

The interface uses standard message formats but is customized to transmit updates only after all three required steps are completed.

Handling Additional Charges

In cases where an inmate incurs additional charges, new fingerprints must be submitted and a new OBTS number received. Because the initial submission may still be in process, each subsequent transaction must be uniquely identifiable. To ensure this, the JMS system appends an alpha character to the booking number, allowing multiple, distinct transactions to be linked to the same inmate record.

The new JMS must retain all current functionality and ensure full compatibility with Idemia Livescan equipment and FDLE interface protocols, including any customizations related to transmission timing and data formatting.

2. Axon Body Cams

The Corrections department currently utilizes Axon body-worn cameras. At present, there is no integration between the body camera system and the JMS. However, it would be highly beneficial to have functionality that enables body camera footage to be linked directly to an inmate’s record, facilitating more efficient documentation and tracking of incidents.

JMS Exhibit A.9 Interfaces Page 3 of 11

3. BizTalk/MSMQ

Our organization relies on Microsoft BizTalk Server and Microsoft Message Queuing (MSMQ) to support reliable, real-time communication with numerous external agencies. This integration platform is essential to our operations, enabling secure, bidirectional data exchanges that are both outbound and inbound.

The BizTalk environment includes approximately 80 orchestrations, each designed to support specific business processes and integrations. Complementing this, MSMQ handles 36 distinct XML-based data exchanges across 41 message queues. These XML structures vary in complexity based on the requirements of the connected external systems.

Many exchanges not only send data but also receive, process, and import structured responses directly into our Jail Management System (JMS), enabling seamless interoperability with third-party partners.

Security is enforced through a key-based validation mechanism for each transaction.

Additionally, every external agency is assigned a dedicated local user account on the BizTalk server, authenticated via SSL/TLS using one-to-one client certificate mappings in IIS. This ensures only authorized entities can access the system, with all interactions being fully logged and auditable.

To assist with evaluation and potential migration or integration planning, we are providing comprehensive documentation detailing each orchestration and message queue, along with descriptions of the supported data exchanges. Sample XML payloads are also included to illustrate message structures and content.

The new JMS must support sending and receiving all existing XML-based data exchanges with external agencies, as currently handled through our BizTalk/MSMQ infrastructure.

4. Body Scanners

Our Corrections department currently operates two OD Security Body Scanners at two different locations (County Jail and Correctional Facility) integrated with our JMS to streamline the inmate intake and scanning process. Upon initiating a scan, correctional staff enter the inmate’s unique identifier (SPN number) directly into the scanner interface. This triggers an API request to the JMS, which returns the inmate’s information in real time to confirm identity and validate the scan.

This integration is essential for ensuring compliance with safety protocols. The body scanner is configured to limit each inmate to a maximum of two scans within a defined period, thereby minimizing radiation exposure. Access to inmate data through the JMS ensures the scanner can enforce this restriction reliably.

Currently, once a scan is completed, the image remains stored on the body scanner.

It would be beneficial to implement an interface that automatically pushes the scanned image to the new JMS. This enhancement would streamline the workflow, reduce

JMS Exhibit A.9 Interfaces Page 4 of 11 manual intervention, and ensure images are securely and reliably transferred to the appropriate system for storage and review.

5. CorEMR

The current integration between the JMS and CorEMR supports both one-way and bi-directional data exchanges, facilitating the management of inmate demographic data, special conditions, and dietary requirements.

Demographic Data Load A one-way data load process populates CorEMR with inmate demographic information sourced from the JMS. CorEMR accesses this data through a structured view and retrieves the necessary records each time the process runs. This data extraction does not track or filter based on prior transmissions, and it operates independently from the special conditions and diets functionality.

It is critical that all inmate records be included in the data load, even in cases where a mugshot is not yet available, for example, when an inmate is placed in a cell due to behavioral or mental health concerns prior to the mugshot being taken.

Special Conditions and Diets The integration also supports bi-directional exchange of special condition and dietary flags. Both Corrections officers and CorEMR staff can apply these flags to an inmate’s record, for example, suicide watch (special condition) or diabetic diet (special diet). All entries are fully auditable, with the initiating system and user recorded for traceability.

To ensure data integrity and operational clarity:

A predefined list of acceptable conditions and diets is maintained. Only CorEMR staff are authorized to remove existing flags; Corrections personnel cannot delete or modify them once applied. The data exchange is carefully managed to avoid redundant or recursive updates between systems.

Requirement for Future JMS Any new JMS must support equivalent functionality, including:

One-way demographic data extraction via structured views

Inclusion of all inmate records, regardless of mugshot status

Bi-directional exchange of special condition and diet data

Audit logging of user/system activity

Strict controls to prevent unauthorized modification or deletion

Logic to prevent infinite update loops between systems

6. Database Replication

Our current architecture includes multiple database replication processes across

JMS Exhibit A.9 Interfaces Page 5 of 11 various systems, implemented using a combination of tools tailored to specific use cases and performance requirements. A key component of this strategy is the replication of our JMS database, which is replicated to a separate environment to support reporting and analytics through WebFOCUS.

This approach ensures that reporting activities do not adversely impact the performance or availability of the live JMS system, maintaining system responsiveness for operational users while supporting comprehensive reporting needs. However, this replication is not a direct one-to-one copy. As part of the process, data transformation occurs to align the replicated data with a reporting-optimized schema that supports the structure and logic required by our existing reporting framework.

Maintaining the current structure of the replicated database is a high priority, as it supports hundreds of existing WebFOCUS reports. Significant schema changes would require extensive redevelopment and validation, introducing unnecessary complexity, cost, and risk. If the proposed solution includes integrated reporting capabilities, full replication of all existing WebFOCUS reports within the new system would also be acceptable.

7. IVR (IC Solutions)

JMS Inmate information is transmitted using SFTP on a WebFocus schedule to the IVR vendor (IC Solutions) from the JMS system. The inmate information is accessible by telephone and includes their booking number, name, DOB, charges, court dates, bond information, and some other information (court addresses, etc.). It is current as of the last half hour.

The new JMS must continue to support the scheduled transmission of inmate information via SFTP to the IVR vendor (IC Solutions), ensuring that data remains accessible by telephone and is updated at least every 30 minutes.

8. Public/Intake Displays

Within our correctional facilities, we currently operate Public/Intake Display screens that provide visitors and staff with access to non-sensitive, informational content, such as:

Inmates scheduled for release

Expected release times

Intake queue

These displays are powered by Raspberry Pi devices, which retrieve data through an API integration with our JMS system. While this functionality is not considered mission-critical, it offers meaningful operational value by improving transparency and reducing the need for direct staff inquiries.

That said, Raspberry Pis are not the preferred hardware solution due to security and

JMS Exhibit A.9 Interfaces Page 6 of 11 maintainability concerns. While this feature is not required, support for similar display functionality—delivered via more secure and enterprise-supported hardware—would be considered a beneficial addition.

9. FDLE Rapid ID

The Volusia County Jail utilizes the RapidID software and hardware package, provided by DataworksPlus, to accurately identify individuals during the booking process.

This system captures two fingerprints using a RapidID device, which are then transmitted to the State Automated Fingerprint Identification System (AFIS) via a connected PC or laptop with network access. The AFIS processes the fingerprint data and returns results to the same device, which subsequently communicates a simplified response of either “Hit” or “No Hit” back to the RapidID unit.

This identification process enables validation of an individual’s identity by checking against prior bookings within the state of Florida or records within the FBI database, ensuring reliable and efficient inmate processing.

10. Handhelds

Our current system includes a critical integration with Zebra handheld scanner devices, which operate using a mobile version of our JMS. These devices communicate with the main JMS application through a dedicated API, allowing for real-time updates to database records and immediate visibility of those updates within the JMS interface.

The new Mobile Enablement will be able to have the capacity to be two-way interface integration.

This integration supports several essential operational tasks, including:

Inmate headcounts

Meal tracking and logging

Inmate transports

Security and wellness checks

The use of handheld devices has significantly enhanced our operational efficiency by providing a safe, reliable, and real-time method for conducting routine tasks.

Additionally, it has played a vital role in reducing paper-based processing, minimizing manual data entry, and lowering the risk of errors, data duplication, or misplaced records.

As we assess future system capabilities, it is preferred that any proposed solution includes robust support for handheld and mobile device integration. This includes real-time data synchronization, secure and stable API communication, and compatibility

JMS Exhibit A.9 Interfaces Page 7 of 11 with enterprise-grade mobile hardware.

11. JMS Commissary and Banking (Keefe)

The Jail Management System (JMS) communicates with the Inmate Banking System using XML messages to request and receive the following information:

Inmate Account Balance

Inmate Indigent Indicator

Inmate Telephone PIN

The inmate’s account balance is provided on-demand in response to a JMS user request. This transaction includes the inmate’s booking number along with the current account balance.

Updates to the inmate’s indigent indicator and telephone PIN are automatically transmitted to the JMS whenever these fields are created or modified within the inmate banking system.

Each transaction includes user and device identification details, as well as the transaction status, which are passed to the stored procedure handling the request.

The JMS/Inmate Banking interface currently operates using the SOAP API to communicate.

The new JMS must maintain integration with the Inmate Banking System via XML/SOAP, supporting real-time exchange of inmate account balance, indigent status, and telephone PIN information, including on-demand requests and automatic updates.

12. LEO Site

Our environment includes an internal web-based application known as the LEO Site, which mirrors the functionality of the public-facing mugshot site but is designed exclusively for law enforcement use. Access to the LEO Site is restricted and requires authenticated login credentials.

This application is actively used by all local police departments to perform key investigative functions, most notably the ability to generate photographic lineups (commonly referred to as "six-packs"). This capability is a critical component of each agency’s investigative workflow and supports case development, witness identification, and other law enforcement operations.

Any future solution must either preserve or enhance this functionality, ensuring that secure access, search capabilities, and lineup generation tools remain available to authorized law enforcement personnel.

JMS Exhibit A.9 Interfaces Page 8 of 11

13. FACES

The current JMS transmits XML documents to Pinellas County via SFTP on a scheduled basis whenever a mugshot exchange is initiated or deleted. Pinellas County processes these documents in daily batch operations.

The new JMS must continue to transmit XML documents to Pinellas County via SFTP on a scheduled basis to support mugshot exchange and deletion, in alignment with the current batch processing workflow.

14. Public Mugshot Site

The Public Mugshot application is a web application written by Beacon that allows the public to search mugshots by first name, last name, or booking #. They can also search recent mugshots. The data displayed includes the mugshot image, inmate id, booking #, booking date, release date, first name, last name, middle name, city, state, zip, age, race, and sex. The information is retrieved via SOAP API connecting to the JMS.

The new JMS must maintain support for the Public Mugshot application by continuing to provide inmate data and images via SOAP API, enabling public search functionality by name or booking number.

15. Sheriff Views

Various data views in the JMS that have been built for person demographics, alias, identifying physical characteristics, warrants, charges, mugshots, record consolidations, and releases for the sheriff agency use.

The reason we have these views available is so that the real time crime center can pull near real time data during investigations.

The new JMS must allow the creation and maintenance of custom data views as needed, to support real-time access to inmate-related data (e.g., demographics, aliases, charges, mugshots, and releases) for investigative use by the Sheriff's Office and Real Time Crime Center.

16. State Attorney Views

Currently we have MSMQ exchanges between our JMS and SA. However, key values were omitted during the development of exchanges. To provide the required fields for SA, it was decided to grant them access to a view in the JMS with the needed information.

17. Social Security Administration Request

On the first day of each month, a report is automatically generated from the current JMS. This file is then uploaded directly from a local drive to the Social Security Administration website. Any proposed solution must support

JMS Exhibit A.9 Interfaces Page 9 of 11 the required data fields and provide the capability to generate this report accurately, maintaining or improving upon the current automated submission process.

The new JMS must support granting access to specific data views containing required fields for SA, supplementing existing MSMQ exchanges to ensure complete and accurate information sharing.

18. Statute Tables

Statutory codes differ among Volusia County agencies — the Sheriff’s Office, Corrections, and the Clerk of Court each maintain distinct statute sets that may not align. To address this, VCIT utilizes a program that standardizes statutes, allowing the Sheriff’s statutes to be accepted during booking while Corrections transmits statutes formatted for use by the Clerk’s reporting system.

Additionally, there is a process in place that extracts statute updates from the Clerk’s system and integrates them into the JMS to maintain consistency.

Any future solution should support this statute reconciliation and update functionality or, at a minimum, provide the capability to develop a custom in-house process. Ideally, this capability would be incorporated as a built-in feature of the system.

19. Tablets

As part of our intake process, we utilize tablets equipped with access to our JMS to support critical intake documentation tasks. These tablets are dedicated primarily to intake functions, where they play a vital role in the photographic documentation of inmate property and physical identifiers, such as scars, marks, and tattoos (SMT).

The workflow includes:

Capturing high-quality photographs of each piece of property as it is received.

Sealing property items on a designated property board.

Verifying that all items shown in the initial photo are accurately logged in JMS.

Taking a secondary verification photo using the tablet after confirmation.

Storing the physical property in the appropriate secured location.

This tablet-based process enhances efficiency and accuracy, while also creating a reliable, visual chain of custody for inmate property. The larger

JMS Exhibit A.9 Interfaces Page 10 of 11 screen size of the tablets allows staff to confirm photo quality in real time, reducing the need for retakes or additional handling.

Previously, while using the VCIT SMT application, tablets also supported direct on-screen editing of SMT images, which streamlined documentation and eliminated the need for external editing tools.

Looking ahead, any replacement or future solution must continue to support:

Tablet-based access to JMS or equivalent intake functionality

High-resolution photo capture and review

Integration with property logging workflows

SMT documentation tools, including annotation or editing capabilities

The tablet interface has proven to be a critical tool for maintaining intake accuracy, reducing paper dependency, and improving overall processing efficiency.

20. Video Visitation (IC Solutions)

Our current Jail Management System (JMS) integrates with IC Solutions for video visitation via a Beacon service that calls the IC Solutions API. This integration allows visitation data to be automatically inserted into the JMS.

The replacement JMS must support an equivalent integration with IC Solutions, including the ability to receive and process data returned from the IC Solutions API, such as Visiting Schedule

The new JMS must be able to accurately capture, store, and utilize this information to maintain current operational workflows.

21. VINES

The current VINE interface operates on database triggers. When triggered, the process executes SQL commands that populate the VINE_XXX table. File transmissions to VINE are performed via SFTP using a domain account, not a local system account.

This interface operates continuously, sending XML transaction files approximately once per minute from the JMS.

Any proposed solution must include integration with the VINE system, supporting similar trigger-based processing and secure, frequent SFTP transmissions. All such transactions must be logged to ensure comprehensive auditing and traceability.

JMS Exhibit A.9 Interfaces Page 11 of 11

22. WebFOCUS

WebFOCUS is a critical reporting tool extensively used within the agency. The JMS database is replicated in real-time, enabling WebFOCUS to generate reports from the replicated dataset without impacting the primary system.

The proposed JMS solution must support database replication to enable real-time reporting and ensure compatibility with existing reporting tools such as WebFOCUS.

Alternatively, the solution must include the full implementation of all existing WebFOCUS reports within the new system.