Exhibit B _ JMS Technical Requirements.xlsx
XLSX spreadsheet 719 KB Posted
- Solicitation number
- PE-63100-NONST-2026-000000096
- Issued by
- Clayton County, Georgia
About this file
This is a Technical Requirements Compliance Matrix for Clayton County, Georgia's Jail Management Solution (JMS) modernization project, establishing comprehensive technical and functional specifications that qualified vendors must meet or address. The document outlines over 150 detailed technical requirements organized into 25 categories including accessibility, auditability, backup and recovery, configuration, content management, data exchanges, security, reporting capabilities, user authentication, and user experience. Vendors must respond to each requirement using standardized response codes (Y for existing functionality, N for unable to meet, T for third-party software, C for customization required, or I for interface) and provide mandatory explanations for any N or C responses. The solution must support a jail population of approximately 1,790 inmates with annual admissions of 19,000 and discharges of 19,100, accommodate 315 concurrent users across three shifts (130 users during 0700-1500, 120 during 1500-2300, and 65 during 2300-0700), maintain 99.90% availability with maximum downtime of approximately 8 hours 45 minutes annually, and process significant transaction volumes including 21,232-21,244 intake and discharge transactions and 71,648 movements annually.
The proposed JMS solution must integrate with approximately 38 existing legacy and modern systems including GCIC, CPU8, RMS (Central Square), Keefe commissary, Eagle Biometrics, VINES victim notification, Kronos time and attendance, and numerous court and justice partner systems through defined data exchange mechanisms such as SFTP, web services, HL7 messages, ODBC connections, and RESTful APIs. The solution must comply with Section 508 accessibility standards, HIPAA regulations, FBI CJIS Security Policy, and American Correctional Association standards, support 256-bit encryption for data in transit and at rest using FIPS 140-2 certified methods, and maintain comprehensive audit trails with real-time monitoring capabilities. Data migration requirements include converting approximately 45 years of historical records across multiple domains (343,504 offender records, 4.17 million classification records, 1.53 million movements, and 1.08 million visitation records), with the solution requiring both desktop and mobile functionality across Windows 10, iOS, Android, and Keefe kiosk platforms. The document specifies detailed requirements for reporting, dashboards, user interface design, role-based security, multi-factor authentication, and administrative capabilities to enable Clayton County to maintain and support the system without continuous vendor assistance.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Exhibit A _ Data and Infrastructure.pdf | ||
| Exhibit G _ JMS Project Gates and Deliverable.pdf | ||
| Attachment B _ JMS Cost Proposal Form.xlsx | XLSX spreadsheet | |
| Exhibit C _ JMS On_Going Support and Training.pdf | ||
| Exhibit F _ JMS Project Management.pdf | ||
| Exhibit E _ Data Integration Hub Requirements.xlsx | XLSX spreadsheet | |
| Attachment B _ DIH Cost Proposal Form.xlsx | XLSX spreadsheet | |
| Exhibit D _ JMS Functional Requirements.xlsx | XLSX spreadsheet | |
| 26_24 Integrated Justice Information and Mana.pdf |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Instructions Jail Management Solution
| TECHNICAL REQUIREMENTS COMPLIANCE MATRIX |
| For each Technical Requirement in this document, the Applicant must address each of the listed requirements by providing one of the response choices in the “Response Code” column. |
The Applicant is further encouraged to provide comments, clarification, or references to other areas of the proposal which provide additional details related to the requirement. Applicants should NOT rely on references to documents that are not included in the proposal in their response, including URL links to information on the Internet.
Responses in the Response Code column are limited to the choices below. Entry of an incorrect Response Code will be considered an ‘X’; if Applicant enters multiple Response Codes for one requirement the City may assign a code of its own choosing.
| Response Code | Description |
| Y | Yes – The requirement can be met with Existing Functionality out-of-the-box or through simple configuration (not customization / custom code). |
| Existing Functionality means that this capability exists, is being used in-production elsewhere and can be demonstrated. The requirement may also be met by leveraging standard County tools such as Active Directory and SQL. This response code includes interfaces that are part of the base product available out-of-the-box. | |
| N | No – The requirement cannot be met. |
| T | Third Party Software – The requirement can be met with a third-party software product provided by Applicant, including any work to incorporate the Third-Party Software to work with the Applicant’s software. |
| C | Customization or Modification – The requirement will be met by making programmatic (software development) changes to existing software, or developing new software. |
| I | Interface – Refers to building an interface to the applications listed in this list of requirements. |
| Where ‘C’ is the response, the required customization must be fully described, and any additional cost to the County identified. |
Where ‘N’ is the response, a full description of all features that the software will not provide and all respects in which it will not satisfy the requirement must be provided. These further explanations are to be provided in text sections identified by entering a reference number in the last column of the spreadsheet, with a separate reference number to the additional text for each requirement.
JMS Technical Reqs
| Technical Requirements | ||||
| Note: Please refer to the Worksheet "Reference Information" for operational and technical volumes, KPIs, metrics and other data associated with the requirements. | APPLICANT RESPONSES | |||
| Category | Req # | Requirement Text | Response Code | |
| (Y, N, T, C, I) | Applicant Notes |
(Mandatory for responses N and C)
| Accessibility | NF-AC-01 | The JMS Solution shall comply with Section 508 (b) of the Rehabilitation Act of 1973, as amended 29 USC § 794 (d). § 794d pertaining to visually or hearing impaired employees. |
| Auditability | NF-AU- 01 | The JMS Solution shall provide an Audit Trail capability that enables the to capture and store information on records and at the field level that have been created within JMS, such as but not limited to: |
- Create / Insert
- Edit / Modify
- Delete
- Logon
- Logoff
- Save
- Update
- Open / View
- Login Successful
- Login Failure
- Password Change
- Password Change Failure
- Device / Terminal ID (or location)
| Auditability | NF-AU- 02 | The JMS Solution shall provide the capability to export, archive, purge and overwrite event logs. |
| Auditability | NF-AU- 04 | The JMS Solution shall provide the capability to provide System Admin Alerts or Notifications for logged events (including associated emails and texts if available in the solution). |
| Auditability | NF-AU- 05 | The JMS Solution shall protect the audit log information from tampering or unauthorized access. |
| Auditability | NF-AU- 06 | The JMS Solution shall have the ability to backup and restore the audit log to/from archival storage. |
| Auditability | NF-AU- 07 | The JMS Solution shall provide the capability to support notifications based on user-defined event triggers (example: Notification to Security Officer for unauthorized User ID access attempts exceed a predefined number of attempts). |
| Auditability | NF-AU- 08 | The JMS Solution shall provide the ability to track transaction response times. |
| Auditability | NF-AU- 09 | The JMS Solution shall maintain an audit log record for the data exchange activities to support the accountability, reconstruction of events and problem identification. |
| Auditability | NF-AU-03 | The JMS Solution shall provide the capability to export events logs in real-time via the tool SysLog. |
| Auditability | NF-AU-10 | The JMS Solution shall record the following attributes for each data exchange activity to provide the current status of a transaction: Transaction type, Date / Time, Status, Source system of data exchange. |
| Auditability | NF-AU-11 | The JMS Solution shall enable the System Administrator with the ability to independently select and review the actions of any one or more JMS Users (including privileged users and based on individual user identity) with the objective of reconstructing a User's actions for investigative purposes. |
| Auditability | NF-AU-12 | The JMS Solution shall enable the to search on Inmate Records using a set of search criteria / attributes (Desired search attributes included but are not limited to: Inmate PID#, User Name, Housing Location down to block / cell number, Inmate date of birth, inmate name, inmate alias, specific dates and times). |
| Auditability | NF-AU-13 | The JMS shall enable the to view the Audit Trail associated with each Inmate’s record(s), such as but not limited to data entered, data changed or deleted with user ID and date/time stamps. |
| Back-Up and Recovery | NF-SLA-RT-06 | The JMS Solution shall be able to perform back-ups without creating any service disruptions to the end users (within impacting system availability). |
| Back-Up and Recovery | NF-SLA-RT-07 | The JMS Solution shall be able to perform back-ups without creating any service disruptions to the end users (within impacting system performance). |
| Back-Up and Recovery | NF-SLA-RT-07 | The JMS Solution architecture shall enable the monitoring and control of system resources. The solution must report application errors, resource limitations through suitable system management abstractions so that standards-based systems management tools can effectively monitor and manage JMS. |
| Back-Up and Recovery | NF-SLA-RT-08 | The JMS Solution shall have adequate redundancy to allow the to perform pre-identified critical business continuity applications in the event of failure of any component of the infrastructure. |
| Back-Up and Recovery | NF-SLA-RT-09 | The JMS Solution shall allow for maintenance and support performance activities (such as "Hot" backup procedures) to be carried out while the application and supporting systems are on line. |
| Back-Up and Recovery | NF-SLA-RT-10 | The JMS Solution shall limit the loss of un-saved data in the event of a system problem where the JMS application (or a specific screen or function) crashes or fails. |
| Concurrent Users | NF-SLA-RT-09 | The Solution shall accommodate each of the estimated User counts in Table 5: Concurrent Users above while maintaining required operational performance levels. |
| Configuration | NF-CNF-01 | The JMS Solution shall be capable of allowing the JMS System Administrator to configure elements, such as tables, lists or pull-down menu fields, via a GUI based configuration tool. Examples of such data includes, but is not limited to: Offender programs, facility codes, cell codes / designations, locations, Rosters, Gangs, Priority lists for movement, Offenses, class levels, billing rates. |
| Configuration | NF-CNF-02 | The JMS Solution shall be capable of allowing the JMS System Administrator to add new fields to the user interface, via a GUI based configuration tool. |
| Configuration | NF-CNF-03 | The JMS Solution shall provide the JMS System Administrator with the ability to configure the titles (names) of data fields on the user interface to titles that the Department commonly uses, via a GUI based configuration tool. |
| Configuration | NF-CNF-04 | The JMS Solution shall provide the JMS System Administrator the ability to add new specific data fields to the user interface, via a GUI based configuration tool. |
| Configuration | NF-CNF-05 | The JMS Solution shall provide the JMS System Administrator with the ability to configure system notifications to appropriate users, via a GUI based configuration tool. |
| Configuration | NF-CNF-06 | The JMS Solution shall provide a Workflow Utility that allows the JMS System Administrator to adjust / augment approval workflow within the appplication for without vendor assistance, via a GUI based configuration tool. |
| Configuration | NF-CNF-07 | The JMS Solution shall provide the JMS System Administrator the ability to configure the JMS by hiding unwanted/unused fields so they are not presented to the Users, via a GUI based configuration tool. The therefore also need to be able to reveal (“unhide”) any fields previously hidden / unwanted. |
| Configuration | NF-CNF-08 | The JMS Solution shall provide the JMS System Administrator the ability to customize and add new Data Input Screens (e.g., for a new Form), via an administrative user GUI tool. |
| Configuration | NF-CNF-09 | The Solution shall allow authorized Department staff to easily add new user configurable forms and workflows in any area in the system that will support complex multi-step processes with multiple participants and, where appropriate, approvers |
| Configuration | NF-CNF-10 | The Solution shall have the capability to assign, track, and maintain, through configurable business rules, the types and statuses needed to manage for the jail: unit/facility types, intake status, inmate custody, classification status, health status, housing assignment, disciplinary, job/program assignment, release review |
| Content Management | NF-CM-1 | The Solution shall associate the attachments to an inmate and for the appropriate logical unit within the inmate, party or case record as appropriate (for example - signed property sheet document shall be associated with the property screen for that inmate). The attachment shall be readily retrievable and available by the user when accessing the inmate, party or case record. |
| Content Management | NF-CM-2 | The Solution shall have the ability to store, index and retrieve attachment files. |
| Content Management | NF-CM-3 | The Solution shall be able to perform electronic document management associated with Client/IP. |
| Content Management | NF-CM-4 | The Solution shall provide the capability to upload and download media attachments (e.g., photos, videos) and PDF files, as required. |
| Data Dictionary | NF-DD-01 | The JMS Solution shall include a searchable, comprehensive data dictionary covering all data elements in all databases supporting the Solution. |
| Data Dictionary | NF-DD-02 | The JMS Solution shall include documentation of the database schema including entity relationship diagrams (ERDs) or data structure diagrams (DSDs); descriptions of the specific data elements that belong to each data structure; and a description of each data structure and the relationship to other data structures. |
| Data Dictionary | NF-DD-03 | The JMS Solution shall have the capability to have the data dictionary updated, either manually or automatically, as changes occur in the Solutions database schemas or structure. |
| Data Exchanges | NF-DE-1 | The Solution shall have the ability to provide a historical log of all transactions with external interfaces. |
| Data Exchanges | NF-DE-2 | The soution will have the ability to integrate with a Data Integration Hub and support the exchange of information, such as custody status, housing location, current location in near real time. |
| Data Exchanges | NF-DE-3 | The Solution shall have the ability to interface real time with justice partners to exchange release offender's custody and medical data. |
| Data Exchanges | NF-DE-4 | The Solution shall provide the ability to setup new data exchanges with external agency partners maintaining proper security protocols and encryption standards. |
| Data Exchanges | NF-DE-5 | The provider will identify any applications in Table 9 for which there is a defined or leverageable integration message. Please specify whether there is a defined exchange, what the content and pattern of the message(s) is. |
| Data Import and Export | NF-DA-01 | The JMS Solution shall support the ability to import and export data using: |
• Delimited files (e.g., CSV, tab delimited)
• Fixed length files
• Excel files
• JSON files
• Shapefile
• File Geodatabase
• GeoJSON files
• Layer files
• GeoTIFF
• JPEG2000
• MrSID Preference is for a standard definable schema, such as ASCII.
| Data Import and Export | NF-DA-02 | The JMS Solution shall allow to export JMS to the Data Warehouse and to stay in sync with it (in real time or near-real time). | |
| Data Import and Export | NF-DA-03 | Should a Cloud Solution be proposed, the JMS Solution provides with the ability to retrieve all JMS data, as needed: | |
| - | Data retrieved will go back to Day 1 (all data from the first day the system is implemented) | ||
| - | Data retrieved will be structured data, meaningful and ‘useable’ | ||
| Data Import and Export | NF-DA-05 | The JMS Solution shall support data replication to a datamart server that will be utilized for data analytics, trend reports, tracking performance metrics and performance indicators, enable automated generation of reports. | |
| Data Import and Export | NF-DA-06 | The JMS Solution shall provide real-time or near real-time synchronization of data between the production database and the reporting database. This should meet the same security levels identified in the Technical Requirements. | |
| Data Import and Export | NF-DA-07 | The JMS Solution shall be ODBC Compliant. | |
| Data Import and Export | NF-DA-08 | The JMS Solution shall integrate with Microsoft SSRS for Ad-Hoc Reporting. | |
| Data Import and Export | NF-DA-09 | The JMS Solution shall support the system's data retention requirements . Specifically, JMS data should be available live / online for 10 years, but accessible forever in archived or offline storage. | |
| Data Migration | NF-DM-1 | The providor will define and support the migration of data as defined in Table 9. The providor will provide detail on the methodology for migration, tools that will be leveraged and responsibilites of the County and the providor. | |
| Design Constraints and Environment | NF-DC-01 | The JMS Solution shall support the use of data exchanges which conform to standards defined in the National Information Exchange Model (NIEM), HL7, Information Exchange Package Document (IEPDs) including NIBRS, N-DEx, APCO, and NCSC, and the Global Reference Architecture (GRA), and LEXS for inter-system communication. | |
| Design Constraints and Environment | NF-DC-02 | The JMS Solution shall support interfaces using the exchange types and mechanisms described in Table 7 (See Reference Information Worksheet). | |
| Design Constraints and Environment | NF-DC-03 | The JMS Solution's Application Program Interface (API) shall be fully documented with required and optional parameters, triggering event, return types, and error or exception return types. | |
| Design Constraints and Environment | NF-DC-04 | The JMS Solution documentation shall identify the prerequisite software that is needed or recommended in order to create interfaces which utilize the provided API. | |
| Design Constraints and Environment | NF-DC-05 | The database management system on which the JMS Solution relies must provide durability, ensuring that once a transaction has been committed it will remain so, even in the event of hardware failure, power loss, crashes, or errors (i.e.; transactions must be recorded in non-volatile memory). | |
| Design Constraints and Environment | NF-DC-06 | The JMS Solution shall utilize Network Time Protocol (NTP) to synchronize time throughout all System components. | |
| Design Constraints and Environment | NF-DC-07 | The JMS Solution shall enable to perform quality assurance processes such as stress testing, system testing, regression testing. | |
| Design Constraints and Environment | NF-DC-08 | The JMS Solution shall provide a unique identifier for each Inmate that is associated with each JMS capability, function or record the Inmate is associated with. The unique identifier is referred to as the LE number. By default, the LE is a 7-digit number generated. If no LE is provided, a unique Inmate ID must be provided for the Inmate by JMS. (Note: the PID is often referred to casually in other contexts as the PPN, Inmate#, Inmate ID or Photo#). | |
| Design Constraints and Environment | NF-DC-09 | The JMS Solution shall support a unique identifier referred to as the LE or "LE" that numeric. (Note: The current LE provided by the that uses as the unique Inmate identifier uses numbers only and is not alpha-numeric) | |
| Design Constraints and Environment | NF-DC-10 | The JMS Solution shall provide a unique identifier referred to as the Prisoner Identifier or "PID" that is presented to a User within the user interface, as associated with any Inmate record. | |
| Design Constraints and Environment | NF-DC-11 | The Solution shall support multiple, distinct environments, including but not limited to: Development, Staging, Testing, Training, Production. Please specify varied environments supported (for example – production, staging, ad hoc reporting, training, acceptance testing, maintenance (initial deployment), documentation of environment refresh from other environments in a repeatable, operation capacity | |
| Devices and Inputs | NF-DV-01 | The JMS Solution shall operate on the Desktop environment, as described in Table 8 (See Reference Information Worksheet). | |
| Devices and Inputs | NF-DV-02 | The JMS Solution shall operate on the Mobile environment(s), as described in Table 8 (See Reference Information Worksheet). | |
| Devices and Inputs | NF-DV-03 | The JMS Solution shall be capable of using Internet Explorer 11 or greater, Microsoft Edge, Chrome and Firefox. | |
| Devices and Inputs | NF-DV-04 | The JMS Solution shall support application extensions that use bar codes / RFID technology to track Inmate and documents and permit scanning and the use of bar codes to accomplish data entry. (This requirement includes the use of bar codes to inventory and manage offender personal property and match property to the offender). | |
| Devices and Inputs | NF-DV-05 | The JMS Solution shall support other interaction modes / device types, for specific business functions, such as Kiosks. | |
| Devices and Inputs | NF-DV-06 | The JMS Solution shall enable mobile devices (such as laptops or tablets/smart phones) to operate in a limited capacity in the absence of a wireless network, such as through an “offline mode” or similar function that provides JMS functionality through local caching or equivalent capability. Upon reconnection to the network, a User’s session and data is synced with JMS. | |
| Information Security | NF-SE-IS-01 | The JMS Solution shall provide a mechanism to authenticate publisher and subscriber systems involved in a data exchange using multifactor authentication. | |
| Information Security | NF-SE-IS-02 | The JMS Solution shall include a catalog of the account roles that are provided for controlling access to database tables and stored procedures for querying, report execution, update, and administrative purpose (changing access). | |
| Information Security | NF-SE-IS-03 | The JMS Solution shall provide the capability to terminate the network connection associated with a communications session at the end of the session. | |
| Information Security | NF-SE-IS-04 | The JMS Solution shall provide the capability to terminate the network connection associated with a communications session after a Prisons Department specified time period of inactivity. | |
| Information Security | NF-SE-IS-05 | The JMS Solution shall be CJIS compliant, covering the sharing of specific kinds of information with external entities, systems and users. The proposed Solution should be able to enforce authorization checks to protect specific kinds of data as needed. This should also cover access to reports, etc. | |
| JMS Availability | NF-SLA-RT-01 | The JMS Solution shall be designed to avoid single points of failure. | |
| JMS Availability | NF-SLA-RT-02 | The JMS Solution shall be designed / architected to support requirements for Service Level Availability defined in Table 3, Operational Metrics in Table 4 and User Volumes in Table 5, above. | |
| JMS Availability | NF-SLA-RT-03 | If the proposed JMS Solution (core or non-core components) must be down for planned maintenance, in spite of the preference for 24 x 7 uptime, the planned outage must fall within the window of 7:00 am - 10:00 am Eastern Standard and Daylight Time on Saturday or Sunday only. | |
| JMS Availability | NF-SLA-RT-04 | The proposed JMS Solution shall be able to tolerate simple failures without disruption of service, application errors in some of the components and / services). | |
| JMS Availability | NF-SLA-RT-05 | With the exception of planned infrastructure maintenance and system upgrades, the proposed JMS Solution must be operational, reliable, available and performant 24x7x365 for essential business processes and mission-critical business operations against the SLAs defined in NF-SLA-RT 3.1 – JMS Availability | |
| JMS Availability | NF-SLA-RT-06 | The proposed JMS solution must be able to support overlaps of shifts during shift change with no drop in system performance or availability. (refer to User Volumes by Shift, Table 5). | |
| Network Connections | NF-SLA-RT-08 | The JMS Solution shall accommodate the forecasted number of network connections in Table 4: Concurrent Network Connections above while maintaining required operational performance levels. | |
| Operational Continuity | NF-SLA-RT-04 | The JMS Solution shall provide the ability to track Solution uptime by issuing log entries indicating Solution startup and shutdown times. | |
| Operational Continuity | NF-SLA-RT-05 | The JMS Solution shall provide the ability to track Solution uptime and transaction response times for both pre-formatted and ad-hoc queries. | |
| Operational Continuity | NF-SLA-RT-05 | The JMS Solution system may operate in a reduced capacity should a major issue occur (such as hardware failure within architecture). However, in such a scenario, no data will be lost or corrupted and the user can perform all system functionality, albeit with slower response times. | |
| Operational Transaction Volumes | NF-SLA-RT-10 | The Solution shall accommodate the transaction volumes in Table 8: Operational Transaction Volumes above and estimated transaction growth, while maintaining required operational performance levels. | |
| Reporting Capabilities | NF-RC-1 | The Solution shall provide the ability to perform, store, track, and report on: Add/modify table of charges | |
| Reporting Capabilities | NF-RC-10 | The Solution shall have the ability to maintain a list of user-defined fields available for a standardized report. | |
| Reporting Capabilities | NF-RC-11 | The Solution shall have the ability to provide option to save ad-hoc report criteria. | |
| Reporting Capabilities | NF-RC-12 | The Solution shall have the ability to provide parameter driven reporting capabilities to meet business needs. | |
| Reporting Capabilities | NF-RC-13 | The Solution shall provide comprehensive reporting with real-time metrics, and data. In addition, data analytics features shall be available to authorized users. | |
| Reporting Capabilities | NF-RC-14 | The Solution shall support flexible, ad-hoc queries without IT intervention. | |
| Reporting Capabilities | NF-RC-15 | The Solution shall support use of a Business Intelligence analytics tool for ad hoc queries, dashboards, and reports. | |
| Reporting Capabilities | NF-RC-2 | The Solution shall provide the ability to perform, store, track, and report on: Deletion of any information (e.g., Cases, Offender records, Discipline Reports, Incident reports, Client/IP photos). | |
| Reporting Capabilities | NF-RC-3 | The Solution shall provide the ability to perform, store, track, and report on any action that impacts critical data, requires an override or is a significant exception. Examples include expungements, Inmate or defendant record merge | |
| Reporting Capabilities | NF-RC-4 | The Solution must have the ability to pull data from multiple databases and/or from multiple areas within The Solution and combine all the information into a single report. | |
| Reporting Capabilities | NF-RC-5 | The Solution shall have a reporting environment that is separate from the operational database with the following characteristics: |
• At minimum it should be a replicated environment
• Reports shall not compete for capacity with real-time business transactions
• Prevent users from causing The Solution to crash when developing a robust or complex report
| Reporting Capabilities | NF-RC-6 | The Solution shall have the ability for reports to be automatically generated on a scheduled basis and distributed on a periodic basis. |
| Reporting Capabilities | NF-RC-7 | The Solution shall have the ability to distribute reports through various mediums such as email, downloaded to share drives, intranet, internet. |
| Reporting Capabilities | NF-RC-8 | The Solution shall have the ability to generate reports from a data snapshot. |
| Reporting Capabilities | NF-RC-9 | The Solution shall have the ability to generate various reports with multiple parameters. |
| Security | NF-SE-CS-01 | The JMS Solution shall support a group / role-based security model. |
| Security | NF-SE-CS-02 | The JMS security system shall enable the JMS System Administrator to establish an number of user permission groups / roles. |
| Security | NF-SE-CS-03 | The JMS Solution shall provide the capability for specific authorized users to ‘lock down’ (restrict, hide) individual JMS records for security purposes, at the discretion of . |
| Security | NF-SE-CS-04 | The JMS security system shall provide module-level security. |
| Security | NF-SE-CS-05 | The JMS Solution shall provide, Authentication, and Authorization, and Accounting capabilities throughout the Solution using Active Directory. |
| Security | NF-SE-CS-06 | The JMS Solution shall comply with HIPAA standards upon implementation and throughout the performance of this contract by applying and/or recommending changes and enhancements to the Solution, as necessary. |
| Security | NF-SE-CS-07 | The JMS Solution shall comply with the FBI CJIS Security Policy and state statutes and regulations upon implementation and throughout the performance of this contract by applying and/or recommending changes and enhancements to the Solution, as necessary. |
| Security | NF-SE-CS-08 | The JMS Solution shall support, at a minimum, 256-bit encryption of data in use by the Solution. (Supports FIPS 140-2 certified FIPS 197 AES encryption methods) |
| Security | NF-SE-CS-09 | The JMS Solution database shall be configurable to provide, at a minimum, 256-bit encryption of data at rest within the database. (Supports FIPS 140-2 certified FIPS 197 AES encryption methods) |
| Security | NF-SE-CS-10 | The JMS Solution shall provide the ability to generate reports listing the roles or groups who have been granted access rights to available functions. |
| Security | NF-SE-CS-11 | The JMS Solution shall provide the capability to restrict the use of maintenance tools to authorized personnel only. |
| Security | NF-SE-CS-12 | The JMS Solution shall support the American Correctional Association Accreditation Standards, applicable state statutes and regulations |
| Security | NF-SE-CS-13 | The Solution shall support field level masking and provide a means to configure fields that need masking. Example: only last few digits of SSN shall be displayed in UI but other digits are masked. |
| Security | NF-SE-CS-14 | The Solution shall have ability to flag any records as restricted; thereby, limiting user access. |
| Security | NF-SE-CS-15 | The Solution shall have the ability to support multi-factor authentication for off-site access. |
| Security Alerts and Reporting | NF-SE-AR-01 | The JMS Solution shall have the ability to produce a report documenting all security related events in the system by selectable duration (shift, day, month, etc.) |
| Security Alerts and Reporting | NF-SE-AR-02 | The JMS Solution shall have the ability to notify the appropriate personnel if a security breach is detected. |
| Security Alerts and Reporting | NF-SE-AR-03 | The JMS Solution must have audit logging capabilities. At a minimum, the logs should be able to determine the identity of the users, the date / time of the interaction, details about the actions performed by users, IP address, Computer name and status of the interaction (success / failure). |
| Security Alerts and Reporting | NF-SE-AR-04 | The Solution must have the capability to enable authorized users to view the security logs for investigative and other purposes. |
| Security Alerts and Reporting | NF-SE-AR-05 | The JMS Solution must have the capability to enable authorized users to view the name of the user that created the record and any / all users who may have subsequently updated the record. |
| Security Alerts and Reporting | NF-SE-AR-06 | The JMS Solution will report failed identification / authorization checks to the system logs, including notifications. |
| Security Alerts and Reporting | NF-SE-AR-07 | The JMS Solution wil. report failed attempts to access unauthorized data to the system logs, including notifications. |
| Supportability | NF-SU-01 | The JMS Solution shall provide ‘self-service’ support capabilities, giving the end users the ability to perform actions such as, but not limited to Submitting of Trouble tickets / Support requests |
| Supportability | NF-SU-02 | The Proposer shall provide JMS application installation procedures for the JMS Solution, so that can maintain the system without always needing direct vendor support. |
| Supportability | NF-SU-03 | The Applicant shall specify and provide the architectural design that is to be employed for the JMS Solution, so that can maintain the system without direct vendor support. |
| Supportability | NF-SU-04 | The Applicant shall provide documentation defining the functionality of modules that comprise the Solution that are available for assignment of access rights by role or group. This shall include, but is not limited to: capabilities for creating accounts, updating accounts, deleting accounts, querying records, and changing administrative access. |
| Supportability | NF-SU-05 | The JMS Solution shall provide the ability to generate reports listing the roles or groups who have been granted access rights to available functions. |
| Supportability | NF-SU-06 | The JMS Solution shall provide the capability to restrict the use of maintenance tools to authorized personnel only. |
| Supportability | NF-SU-07 | The JMS Solution shall support defined roles, processes, and responsibilities for views, data marts, and extracts. |
| Supportability | NF-SU-08 | The JMS Solution shall provide user help documentation (soft-copy format, such as PDFs). |
| Supportability | NF-SU-09 | The JMS Solution shall provide the capability to create, administer and modify help scripts and any online manuals / documentation provided. |
| Supportability | NF-SU-10 | The JMS Solution shall provide context-sensitive user help documentation (on-line/web-based help resources). |
| Supportability | NF-SU-11 | The JMS Solution shall provide useful prompts or tool tips when the user ‘hovers over’ certain features, controls and commands around the user interface. |
| Supportability | NF-SU-12 | The JMS Solution shall provide the ability to link to a policy or other process / document that governs specific business functions associated with JMS modules or functionality within the system. This may reside in another system that currently utilizes or within the JMS Solution itself. |
| Supportability | NF-SU-13 | The JMS Solution shall provide the System Administrator to perform certain management operations based on policies and procedures, such as but not limited to: |
1. Merge 2 inmates (Based on Policies & Procedures)
2. Merge 2 visitors (Based on Policies and Procedures)
3. Expunge case, admission, or release
4. Delete a case, admission, or release
5. Reverse an Inmate discharge
6. Delete Reports such as an Inmate Misconduct
7. Charge Maintenance Fee for released inmates
| Supportability | NF-SU-14 | The JMS Solution shall provide with the ability to perform secure remote administration, as well as on-site administration. Example operations include, but are not limited to: | |
| 1. | User account and password management | ||
| 2. | System security management | ||
| 3. | System log review and maintenance | ||
| 4. | System monitoring and generating system reports | ||
| 5. | Notification management | ||
| 6. | Software threshold parameter management | ||
| 7. | System and database backup initiation | ||
| 8. | Transaction management / pushes to external systems as needed | ||
| Supportability | NF-SU-15 | The JMS Solution shall maintain an Audit Trail of all changes made to the System’s components. This includes a centralized repository for any / all error messages. This repository must be accessible and exportable by the System Administrator. | |
| Supportability | NF-SU-16 | The JMS Solution shall ensure that system error and events for software, hardware, interfaces, operating system, and network are written to a system event log accessible and searchable by a system administrator. | |
| Supportability | NF-SU-17 | The JMS Solution shall have formal, documented, release management procedures for the release and distribution of all releases, upgrades, patches and the withdrawal or retirement of each. | |
| Supportability | NF-SU-18 | The JMS Solution shall provide formal, documented, procedures to restart system components. | |
| Supportability | NF-SU-19 | The JMS Solution shall provide formal, documented, procedures to recover / restore incomplete transactions that are in appropriate states. | |
| Supportability | NF-SU-20 | The JMS Solution shall immediately notify the System Administrator when definable thresholds are exceeded, and, if the occurrence or accumulation of these relevant events continues, the system must take the least disruptive action to terminate the event. | |
| Supportability | NF-SU-21 | The JMS Solution shall be compatible with standard enterprise system monitoring tools. (Specifically Networking, Servers, Applications monitoring tools). The Vendor is requsted to describe which tools are supported. | |
| Systems Interfaces | NF-IF-01 | The JMS Solution shall provide an integration layer that allows any third party vendors’ systems the ability to integrate. | |
| Systems Interfaces | NF-IF-02 | The JMS Solution shall provide the required API’s to be published to a discoverable library. |
Examples of these applications include, but not limited to, MBIS machines, Iris Scans for authentication and RFID, Bar coding for movement tracking. It should be noted that some 3rd party applications might require specific plug-ins to be built and configured in the Solution in order to integrate, however, the proposed Solution must permit this at the integration layer.
| Systems Interfaces | NF-IF-03 | The JMS Solution shall have the ability to integrate with other providers that are normally utilized in a Jail setting. Examples of these are commissary service systems, food service systems, payment systems, health care systems, banking systems (see complete list of interfaces in Table 9). | |
| Systems Interfaces | NF-IF-04 | The JMS Solution shall support the use of data exchanges which conform to standards defined in the National Information Exchange Model (NIEM), HL7, Information Exchange Package Document (IEPDs) including NIBRS, N-DEx, APCO, and NCSC, and the Global Reference Architecture (GRA), and LEXS for inter-system communication. | |
| Systems Interfaces | NF-IF-05 | The JMS Solution’s integration layer shall support the publishing of notifications when certain, pre-identified, events occur (such as processing the admission of an Inmate). These interactions should be permitted without exposing the product’s database to external systems. | |
| Systems Interfaces | NF-IF-06 | The product should support the expected interfaces standards described in Table 7 (See Reference Information). | |
| Systems Interfaces | NF-IF-07 | The JMS Solution shall archive the sending, receiving and logging of each transaction through all interfaces. This must be searchable and include reporting capabilities by inmate, transaction type, date range, facility, housing locations and various other statistics for trend analysis. | |
| Systems Interfaces | NF-IF-08 | The JMS Solution shall log interface transactions (categorized by status, such as but not limited to: Sent, Received, Failed etc. with reasons) and provide the Systems Administrator with a meaningful view of the transaction history. | |
| User Authentication | NF-SE-UA-01 | The JMS security system shall provide User Authentication capabilities through Microsoft Active Directory. | |
| User Authentication | NF-SE-UA-02 | The Solution must be compliant the organization ITP (IT Policy) with for user authorization, including the use of two-factor authentication. | |
| User Authentication | NF-SE-UA-03 | The JMS Solution will provide the ability to search on and retrieve a list of User Session Durations. | |
| User Authentication | NF-SE-UA-04 | The JMS Solution will provide the System Administrator with the ability to terminate a User Session (e.g. if user sessions are open for an extraordinary duration, or other reason). | |
| User Authentication | NF-SE-UA-05 | The JMS Solution shall ensure that Users are only allowed to have one (1) active session by default. Users wih elevated privileges can have a maximum of three (3) active sessions. | |
| User Authentication | NF-SE-UA-06 | The JMS Solution will enable to System Administrator with the ability to create / modify / remove access for authorized External Users to a limited, read-only, access to a subset of data within the JMS (to be determined during the JMS Implementation). | |
| User Experience | NF-UX-01 | The JMS Solution shall provide the ability to enable the users to navigate through the system with a minimum number of clicks. | |
| User Experience | NF-UX-02 | The JMS Solution shall provide the ability to enable users to retrieve information very easily without having to go through multiple screens. | |
| User Experience | NF-UX-03 | The JMS Solution shall provide basic word processing functionality, including word wrap, spell check, and font control, for the entry and manipulation of text data. | |
| User Experience | NF-UX-04 | All data entered into JMS should be included in the JMS Audit Trail, with timestamps of who created and updated the data. | |
| User Experience | NF-UX-05 | All data entered into JMS must be searchable, printable and reportable. | |
| User Experience | NF-UX-06 | The JMS Solution shall minimize data entry efforts by: | |
| - | Providing default values for fields based on previous input, referential lookup or other mechanisms | ||
| - | Providing lookup tables for the values for fields | ||
| - | Ordering values by most frequently entered | ||
| User Experience | NF-UX-07 | The JMS Solution shall support the auto-filling of date/time entry fields but allow for manual date changes. | |
| User Experience | NF-UX-08 | The JMS Solution shall have the ability to display a calendar to select from to populate the date fields. | |
| User Experience | NF-UX-09 | The JMS Solution shall provide the ability to enter a date by using shortcuts but also allow for manual overrides. | |
| User Experience | NF-UX-10 | The JMS Solution shall provide data quality editing, consistency and validity checks on data elements at the point of data entry. The proposed Solution must display a meaningful error message, and prevent entry of data that does not pass edit checks. | |
| User Experience | NF-UX-11 | The JMS Solution shall provide a logical sequence of screens and fields enabling users to quickly access, modify, skip or jump to other areas of interest for data entry based on specific workflow developed during the JMS Implementation. | |
| User Experience | NF-UX-12 | The JMS solution shall provide a chevron type display, or another form of in-app navigation, so a user knows where they are within the application and/or within a workflow i.e. Intake, Discharge, etc. | |
| User Experience | NF-UX-13 | The JMS will provide authorized External Users with read-only access, via a Portal or other proposed solution, to a limited subset of JMS data, to be determined with the Applicant during the JMS implemtation. | |
| User Experience | NF-UX-14 | The Solution shall have the ability to support a browser-agnostic based interface. | |
| User Experience | NF-UX-15 | The Solution must be compatible with and support Microsoft® Edge, Google Chrome, Apple Safari browsers. The Solution shall maintain compatibility with the three most current versions of each browser and provide data over a web browser interface for example. | |
| User Experience | NF-UX-16 | The Solution shall allow creating Dashboards with drilldown capabilities for data analysis, along with the ability to distribute Dashboards and reports to selected users. | |
| User Experience | NF-UX-17 | The Solution shall be able to display a synthesis of information based on parameters set by staff. This includes being able to request information from different areas of an Inmate’s totality of information available and having it displayed for staff on a user-friendly dashboard. | |
| User Experience | NF-UX-18 | The Solution shall have the ability to provide summary information as well as the ability to drill down to the details associated with the summary information. | |
| User Experience | NF-UX-19 | Context-Sensitivity: The Solution shall provide the capability to dynamically display menus, pages, data fields and functionality based on the security access and roles defined of the user. | |
| User Experience | NF-UX-20 | Multiple Windows: The Solution shall provide the capability to view multiple windows at a time while maintaining data and session integrity. | |
| User Experience | NF-UX-21 | The Solution user interface shall provide help features based on process and context. | |
| User Experience | NF-UX-22 | The Solution shall support a common user interface "look and feel" across the entire application. | |
| User Experience | NF-UX-23 | The Solution shall support standard data validation on all input fields including but not limited to data type validation, range validation, and format validation. | |
| User Experience | NF-UX-24 | The Solution user interface shall provide help features based on process and context. | |
| User Experience | NF-UX-25 | The Solution shall have the capability to allow multiple users to view records at the same time. |
&P &"Calibri,Regular"&11&K000000&A
Reference Information
| Reference Information | ||||
| Applicants must complete the Technical Requirements Compliance Matrix (provided in the MS Excel file). The information provided below is relevant to a subset of those detailed technical requirements only. | ||||
| NF-AV 3.0 – JMS Services level expectations | ||||
| Availability relates to the time that the Solution is expected to be available for use by its users. It is the objective of the County that the proposed Solution be highly reliable and able to be configured to provide maximum uptime and availability to all systems and users that depend upon its services. These requirements allow for only a small amount of planned downtime related to installation of upgrades, patches, and bug fixes. Planned outages may be necessary for regular system maintenance, and a fail-over capability can be utilized during that time to maintain operations if feasible. | ||||
| NF-SLA-RT 3.1 – JMS Availability | ||||
| End user availability relates to the time that the system is expected to be available to the users. This requirement is inclusive of downtime due to both planned outages and failures. Planned outages will be necessary for regular system maintenance and a fail-over server may be utilized during that time to maintain operations. | ||||
| Due to the nature of Jail Management business processes, the Solution’s components are anticipated to be used 24 hours x 7 days per week x 365 days per year. | ||||
| Table 1: JMS Availability Requirements | ||||
| %Availability Target SLA | Approx. Downtime Per Year | Approx. Downtime Per Month | Approx. Downtime Per Week | |
| Jail Management System (Core JMS) | 99.90% | 8h 45m 57s | 43m 49.7s | 10m 4.8s |
| Third Party / Associated Solution Components (Non-Core JMS) | 99.90% | 8h 45m 57s | 43m 49.7s | 10m 4.8s |
| Interfaces (Web Services, Data Exchanges, etc.) | 99.90% | 8h 45m 57s | 43m 49.7s | 10m 4.8s |
| Table 2: Operational Metrics | |
| Metric | Value |
| Inmate Population | 1790 |
| Annual Admissions | 19,000 |
| Discharges | 19,100 |
| Estimated Annual Growth Rate | +1% - 2% p.a. |
| Table 3: User Volumes by Shift | |
| Concurrent User Volumes by Shift | |
| 0700 – 1500 Concurrent Users | 130 |
| 1500 – 2300 Concurrent Users | 120 |
| 2300 – 0700 Concurrent Users | 65 |
| External Users (e.g. Portal Access ) | N/A |
| Total Users | 315 |
| NF-SLA-RT 4.0 – Capacity Limits |
| NF-SLA-RT 4.1 – Network Connections |
| Network Connections refers to the number of connections expected between internal/external County systems and the JMS Solution’s components. The network connections include the sub-systems handling message services and external data synchronization. |
| Table 4: Concurrent Network Connections | ||
| Est. Number of Concurrent Network Connections | Min | Max |
| Number of estimated concurrent JMS network connections based on interfaces listed in Table 9 | 65 | 130 |
| NF-SLA-RT 4.2 – Concurrent Users | |
| The table below identifies the number of individuals (regular users and administration) expected to utilize the Solution and it is sub-systems concurrently. | |
| Table 5: Concurrent Users | |
| User Roles | # of Users |
| Normal Operations Maximum Users | |
| Maximum Total Users | 315 |
| Maximum Mobile Users | 315 |
| Maximum Concurrent Users | 315 |
| Maximum External Concurrent Users | N/A |
Note: The maximum number of users is representative of what may happen in an emergency situation. This is intended to reflect performance needs not licensing needs.
| NF-SLA-RT 4.3 – Operational Transaction Volumes |
| The table below identifies the historical operational transaction volumes. |
| Table 6: Transaction Volumes | ||
| Description | Estimated Volume | Year |
| - Intakes | 21,232/16,853 | 2024/2025 |
| - Discharges | 21,244/17,059 | 2024/2025 |
| - Incidents | xxxInvestigations | 2024 |
| 2,342 Inmate Violations | ||
| - Shake-Downs / Searches | 365 Shakedown events | 2024 |
| xxx Beds Searched | ||
| - Shift Log Entries | 400 Lines est per day | 2024 |
| - Movements | 71,648 | 2024 |
| - Inmate Transactions | 38,519 | 2024 |
| NF-DC 9.0 – Design Constraints & Environment |
| This section specifies the constraints imposed on the Solution by compliance to identified standards. |
| Table 7: Exchange Types / Mechanisms | |
| Exchange Type | Mechanism |
| Flat file | SFTP (Push / Pull) |
| Self-contained structure (JSON, RESP [ack]) | Web service (Push / Pull) |
| Message (e.g. HL7) | TCP connection (Out / In) |
| Images | SFTP (In) |
| SQL | ODBC (Push / Pull) – Encrytped |
| Report | SFTP (Push) |
| Restful APIs | Web Service (Push / Pull) |
| NF-DV 10.0 – Devices & Inputs | |||
| The Solution must comply with the following device standards and needs. | |||
| Table 8: XXX Supported Devices | |||
| Device Category | Device Types | Platform | Device Volumes (Units Required) |
| Desktop | Windows Machines | Windows 10 (Current / n-1) | 315 |
| Tablet / SmartPhone | Apple | iOS | N/A |
| Android OS (Preferred) | 8 | N/A | |
| Kiosks | Keefe Kiosk | Keefe Proprietary | 5 |
| Infrastructure | Servers | Windows (Preferred) | Dependent on Applicant's Proposed Solution |
| Linux |
| NF-IF 11.0 – System Interfaces | |||||||
| To achieve the functionality required by the JMS Solution, several interfaces to other systems are required. The Applicant shall work with the County and other system vendors to develop interfaces, the approach for which is described in the ‘Systems Interfaces’ within the Proposed Statement of Work in the Appendix. | |||||||
| The County expects the Applicant will work with County to determine the best method for exposing the listed interface (e.g., web service, existing API, file, etc.). Where available, The County is seeking a Data Integration Hub solution to handle most data exchanges. In some instances, there may be justfication for direct exchange of information between the proposed solution and specific solutions within the Jail ecosystem. The County wishes to understand interfaces the Applicant already includes in the base product or has already completed as part of a previous project. The Applicant and Clayton County will further refine the specifications for interfaces during the interface design phase of the project. | |||||||
| The current and planned JMS interfaces are listed | |||||||
| Table 9: System Interfaces | |||||||
| Application | Direction | Frequency | Interface Type | Business Purpose | Data Elements | Retire/Modify/Integrate | DIH Scope |
| Palatine | One Way Outbound | Integrate or Retire | Phase 2 | ||||
| GCIC | One Way Outbound | Integrate | Phase 2 | ||||
| CPU8 Courts | Bi-Directional | Retire | Phase 2 | ||||
| CPU8 Jury | NA | NA | |||||
| CPU8 Complaints | NA | NA | |||||
| CPU8 Grand Jury | NA | NA | |||||
| RMS – Central Square | One Way Inbound | Integrate | Phase 4 | ||||
| Tracker | NA | NA | |||||
| JCATS | NA | NA | |||||
| Keefe | Bi-Directional | Integrate | Point to Point | ||||
| Tyler eFile Georgia | NA | NA | |||||
| ICS | Bi-Directional | Integrate | Point to Point | ||||
| EHR | Bi-Directional | Integrate | Point to Point | ||||
| Picture Link | Bi-Directional | Integrate or Retire | Point to Point | ||||
| Brazos | One Way Inbound | Integrate | Phase 4 | ||||
| IRIS | Point to Point | ||||||
| Utility | NA | NA | |||||
| Axon | NA | NA | |||||
| Jagware | One Way Outbound | Integrate | Phase 2 | ||||
| In Court – Catalyst | NA | NA | |||||
| Ameris | NA | NA | |||||
| Quickbooks | NA | NA | |||||
| Munis | NA | NA | |||||
| Eagle Biometrics | Bi-Directional | Integrate | Phase 2 | ||||
| VINES | One Way Outbound | Integrate | Phase 2 | ||||
| CourtView | NA | NA | |||||
| CJT JusticeTech | NA | NA | |||||
| Fythe | NA | NA | |||||
| ZAPs | NA | NA | |||||
| Imfax | NA | NA | |||||
| Connexis | NA | NA | |||||
| Tech Friends | Bi-Directional | Integrate | Phase 4 | ||||
| Kronos | One Way Inbound | Integrate | Phase 4 | ||||
| OnPoint | Bi-Directional | Integrate | Phase 4 | ||||
| NF-DM 12.0 - Data Migration | |||||||
| The county wishes to migrate and maintain data from the legacy solution in the following domains to support continued operations, processing of repeat offenders, and compliance with jail standards and auditing needs. The County wishes to convert 45 years (estimate) years of historical data. | |||||||
| Table 10: Data Migration | |||||||
| Domain | Total Records | Active | Released - On Probation | Inactive | Years of History | ||
| Offender | 343,504 | 1,675 | 85,526 | 341,751 | All (est. 45 yrs) | ||
| Classification | 4,172,492 | 32,351 | 931,444 | 3,978,266 | All (est. 45 yrs) | ||
| Incidents | 120,917 | 117,969 | X | 2,948 | All (est. 45 yrs) | ||
| Visitation | 1,085,731 | 3,847 | X | 81,233 | All (est. 45 yrs) | ||
| Housing | 343,864 | 1,674 | X | 341,752 | All (est. 45 yrs) | ||
| Movements | 1,532,851 | N/A | X | N/A | All (est. 45 yrs) | ||
| Sentence | 483,149 | N/A | X | N/A | All (est. 45 yrs) | ||
| Programs | All | Not currently tracked in CPU8 | |||||
| inmate transactions | All | Not currently tracked in CPU8 |
Legacy Applications
| Application Name | Description of Use | Capabilities | Unit(s) | Retire/Modify/Integrate |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .