CONTACT US
SEARCH
Home | Resources & Services | Court Services | Judicial Data Management Services (JDMS)

Judicial Data Management Services (JDMS)

Florida's State Courts System has begun the development of an Integrated Trial Court Adjudicatory System, a project that will optimize the ability of judges and case managers to electronically process and manage cases. The project is also designed to assist chief and administrative judges and court managers in the effective management of court operations and resources. The project has two major components: 1) Judicial Viewers, which focus on case management services for judges; and 2) Judicial Data Management Services (JDMS), which focuses on state level court activity data and analysis services for court managers and other stakeholders.

The JDMS project will develop a computing environment to provide state-level data management services to all elements of the court system. Those services include:

  • Data Consolidation and Standardization Services
  • Reporting Services
  • Processing Services
  • Data Warehouse and Analytical Services

Specifically, the JDMS system will benefit judges, court managers, and users of the court system by providing meaningful data and analysis to: 1) improve adjudicatory outcomes through case management and program evaluation, 2) increase operational efficiency through efficient use of shared resources, and 3) support organizational priorities through legislative resource and budgetary requests. JDMS will additionally enhance the ability of the state courts system to provide court-related data to assist policymakers in evaluating policy and budget options.

FY2015-2017 JDMS Project Plan

July 2017-Dec. 2017 Project Plan Addendum

 

Quarterly Status Reports

Each quarter of the project development cycle, a Project Status report will be published in this section. This document reports the project elements completed during the current release and outlines the tasks identified for work in the next quarter.

December 31, 2017

June 30, 2017

March 31, 2017

December 31, 2016

September 30, 2016

June 30, 2016

March 31, 2016

December 31, 2015

September 30, 2015

 

Uniform Case Reporting (UCR) Project

On September 17, 2015, the Commission on Trial Court Performance and Accountability adopted the final proposal for the Uniform Case Reporting (UCR) Project and the accompanying data collection specification. On April 27, 2016, the Supreme Court issued AOSC16-15 In Re: Uniform Case Reporting Requirements directing clerks of court to provide case activity data to the Office of the State Courts Administrator in accordance with the specification provided below.  As with all new data collection efforts, the UCR Project is being developed in accordance with the JDMS framework and principles.  The current version of the UCR Data Collection Specification is provided below. 

UCR Final Proposal

AOSC16-15 In Re: Uniform Case Reporting Requirements

UCR Data Collection Specification v.1.3.0  (Issued June 28, 2017)

 

On June 28, 2017, the Supreme Court revised the Implementation Schedule, which is posted below:

 

Clerk of Court Transition to Uniform Case Reporting

Transitioning to reporting under the UCR will occur in two phases:

Phase I – Data Exchange Capability

This goal of this phase is to develop the necessary infrastructure to report case activity data to the OSCA using one of the approved reporting mechanisms established in the UCR Data Collection Specification.  This includes:

  • The development of the extract or trigger queries to output relevant event records as the data changes
  • Formatting the event records into the UCR data packages as per specification
  • Exchanging those data packages with the OSCA UCR data exchange service
  • Providing an initial upload of all open and reopened cases (active and inactive)

Working with clerks of court during a series of initial meetings in December 2017 and January 2018, the Office of the State Courts Administrator (OSCA) defined the following milestones for Phase I.  Note that the milestones differ depending on which data exchange option is chosen.

Milestones for data exchange via web services:

  1. Develop the extract or trigger queries to output relevant event records as the data changes

  2. Format case activity event records into the UCR data packages as per specification

  3. Connect to OSCA data exchange service

  4. Exchange a data UCR data package with service

  5. Complete an initial upload of all open and reopened cases  Please note: User credentials are required for interacting with the OSCA's web service, and the sender's IP address must be recorded to open the firewall for consumption. Contact the OSCA to coordinate access to the test and production sites before attempting to upload data.

  6. Define a meaningful and responsive error reporting and correction process

  • Identify the error communication mechanism
    • Local web service
    • Email with formatted record file
  • Identify procedure for clerk response to errors

Milestones for data exchange via CMS replication:

  1. Establish a CMS replica accessible by OSCA

  • OSCA establish linked server connection to replica
  • Negotiation of appropriate Service Level Agreements
  • Sharing of data dictionaries
  • Verification that clerks CMS capable of satisfying UCR requirements
  1. Develop the extract or trigger queries to output relevant event records as the data changes

  2. Format case activity event records into the UCR data packages as per specification

  3. Complete an initial upload of all open and reopened cases

  4. Define a meaningful and responsive error reporting and correction process

  • Identify the error communication mechanism
  • Identify protocol for responding to errors

 

At the end of Phase I, the clerk’s office will be able to:

  • Transmit an initial upload of all open and reopened cases
  • Transmit case activity event records in near real time to the OSCA data exchange service with event records generated as data changes.

At the end of Phase I, the OSCA will be able to:

  • Receive and process case activity event data
  • Provide clerks of court with timely and relevant event record error information

 

Phase II – Analysis and Verification

The UCR reporting structure is intended to replace a number of existing reporting requirements. (Please see page 7 of the Uniform Case Reporting Specification.)  This phase will ensure that the OSCA is able to produce accurate and reliable reports based on clerk data.  Previous experience with other data collection systems such as the Offender Based Transaction System and the Foreclosure Initiative Data system has demonstrated that this phase is most productive following a variation of the plan-do-check quality cycle.  The OSCA will validate each report for the clerk of court as an iterative series of submissions, analytical reviews, and corrective actions. 

The corrective action will be focused on the process of reporting the data in addition to the actual data values so that the OSCA can build confidence that the clerk will continue, after the verification cycle, to submit reliable and accurate data and the clerk of court can build confidence that the OSCA is computing accurate case activity statistics. 

This phase begins at completion of Phase I with live near-real time case activity event data.  Time to complete Phase II will vary by clerk’s office, although it is anticipated take 4-6 months.

Throughout Phase II, OSCA and clerk staff will:

  • Reliably submit UCR event data in near real time
  • Review summary and diagnostic reports to verify data quality.  Report review will occur as follows:
    • Judge Inventory Report (includes case inventory statistics and pending caseload)
    • Summary Reporting System (SRS) reports
    • Complex Civil Litigation reports

The clerk, as custodian of the record, retains responsibility for report accuracy through the detail data.  As each clerk of court certifies the corresponding report results, the OSCA will provide a date on which the clerk’s office may stop sending each report via the previous reporting mechanism and transition for that report will be complete.

 

Additional UCR Resources

The XML schema document provided below contains all the validation criteria for each type of event reported per the specification.  Please use the current version of the UCR02 schema to validate your XML reports.  Also provided is a UCR Data Dictionary, which lists the required and optional data elements for each event type in chart format.  

Note: Previously, there were three separate XML schema documents for this project.  During the pilot phase, the three schemas were collapsed into a single document, which is the lastest version of the UCR02 schema.  

UCR02 XML Schema Document Version 1.2.5

UCR Data Dictionary

UCR Frequently Asked Questions (updated June 13, 2018)

Examples of Event Type Records:

Case Init event record

Case Closure event record

Case Change event record

Case Reopen event record

Case Reclosure event record

Documentation for the OSCA's web service: 

OSCA Web Service Technical Specification Version 1.0.2

Please note: User credentials are required for interacting with the OSCA's web service, and the sender's IP address must be recorded to open the firewall for consumption. Contact the OSCA to coordinate access to the test and production sites before attempting to upload data.