Transitioning to UCR reporting Q: What is the process for beginning the transition for each division of court? A: The OSCA will work with up to 20 clerks of court at a time. However, staff is available to answer questions and clarify the reporting requirements for all counties prior to their respective transitions. When your county is ready to begin transition, please email OSCA with a request to start UCR transition. By this point, the clerk of court should have decided on a reporting mechanism, spoken with your vendor (if applicable), planned out development strategy, and otherwise made the necessary arrangements. Slots will be filled on a first come first serve basis. Phase I of the transition is expected to take 6-8 weeks of active development time. The milestones for Phase I are published on www.flcourts.org/jdms and culminates in submitting an initial upload of all open and reopened cases. After Phase I is complete, the county will participate in Phase II, which involves the validation and verification of the statistics calculated from the case activity events. This phase will vary by clerk s office, and is anticipated to take 4-6 months. Q: What are the specifications for the baseline/initial inventory? (revised 6/20/2018) A: A one-time submission of the division s entire open and reopened inventory, regardless of age, is needed prior to the commencement of sending event records per this specification. This is accomplished by sending Case Initiation Events for each of the currently Active and Inactive cases (or case subunits) and Case Reopen Events for each of the currently Reopen Active and Reopen Inactive cases (or case subunits). Q: When submitting the initial upload of all open and reopened cases, are the previous events (Case Initiation, Case Closure) required for the cases currently in a reopen status? Further, if a case previously not reported to UCR reopens in the future, are all the previous case activity events (Case Initiation, Case Closure) required to be submitted prior to reporting the Case Reopen event? A: No. Sending a Case Reopen event for a case not previously reported to the UCR project will not be rejected as an error. For UCR, historical data is not required for cases closed prior to a county s transition date for that division of court. Q: For sending the initial baseline inventory, can we send the UCR data packages by FTP or other alternative? (added 6/20/2018) A: No. UCR data packages are to be submitted via the OSCA s web service. Please contact the OSCA with any concerns regarding the size or volume of your county s initial baseline submission. For larger counties, this submission can be scheduled during off-peak hours.
Q: Can we transition the Circuit Civil and Family divisions at the same time? (added 6/20/2018) A: No. Please plan on transitioning each division individually. We are currently accepting only Circuit Civil data. Family is the next division scheduled; the specifications for this division are forthcoming. Q: Where do Juvenile Dependency and Juvenile Delinquency fit in the Implementation schedule? (added 6/20/2018) A: Both Juvenile Dependency and Juvenile Delinquency will be included in the Family Division. Q: Are the specifications for divisions other than Circuit Civil available on the web? (added 6/20/2018) A: No. We are working with each division individually. The specifications for each division will be made available as soon as they are finalized by the State Courts Administrator. Q: What if my CMS does not collect one of the data elements required by UCR? A: The UCR Data Collection Specification requires that certain case activity events and the data elements describing those events be reported as these events occur. The data describing the case activity event may be present in the clerk CMS as a field in a data table or may be derived from multiple fields within different tables. Each clerk CMS is different, and updates to the CMS may need to be requested in some instances. Whichever method is used, the resulting case activity event must be near real-time, accurate and reliable. Q: What is a case subunit? (added 5/25/2018) A: A case subunit refers to the individual part of a case reported with a Case Qualifier. This is required in cases needing more granular reporting, such as by parcel in Eminent Domain cases, but will not be used by any case that can be tracked by its Uniform Case Number alone. Please see the Case Qualifiers section in the specification for a more detailed discussion. Note: Once case qualifiers are reported on a case, every subsequent event must be submitted with the appropriate case qualifier. For example, if two Case Initiation Events are submitted for two parcels on an Eminent Domain case, a Case Closure submitted with the UCN and no Case Qualifier would not properly close either parcel. The Case Closure must uniquely identify the subunit it is closing. The exception is the Bulk Reporting method provided in the specification. Q: Are any of the data elements optional? A: The UCR data set represents a minimal data set necessary to capture the case activity and compute appropriate reports. Therefore, all fields must be reported when appropriate. The clerk is required to report only those data elements essential to the event being reported.
For example, a case initiation event requires, at a minimum, 1. Report Date 2. Uniform Case Number 3. Case Qualifier (if applicable) 4. Event Date (in this context, the filing date) 5. Primary Judicial Officer (may be NOJUDGEASSIGNED) Other elements such as the case type or Local Division Assigned may also be reported on a case initiation event if those elements have been determined. If they have not been determined, they may be reported on a subsequent case change event. Please refer to the UCR Data Collection Specification Table 1 for a comprehensive list of required data elements. Q: When will we be able to stop reporting to the Summary Reporting System (SRS)? A: During Phase II, the OSCA will validate each report for the clerk of court as an iterative series of submissions, analytical reviews, and corrective actions. The clerk, as custodian of the record, retains responsibility for report accuracy through the detail data. As the clerk is comfortable with the statistics calculated for that division of court, he/she will certify each report. As the clerk 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. Q: The UCR transition begins with Circuit Civil. Will we be able to stop reporting Circuit Civil data to the Summary Reporting System (SRS) as we complete Phase II, or do we have to transition all divisions of court before we re permitted to cease reporting to SRS? A: You will be able to stop reporting each division of court as each is transitioned to UCR. This means that after the transition for Circuit Civil is complete, the clerk s office will only be responsible for submitting SRS forms for the remaining divisions of court. Q: We [the county] currently produce summary and detail SRS audit reports for correcting errors. How will the auditing be handled once the OSCA is computing our SRS from UCR data? (added 6/20/2018) A: Phase II of each county s transitions includes the validation and verification processes and can take 4-6 months to complete. This will be a collaborative process between OSCA and the county. Once OSCA receives a complete month of UCR data, SRS reports with accompanying audit trails will be provided to the county for review. If any discrepancies are discovered, the county will then submit the missing case events or resubmit corrected events. OSCA will rerun
the SRS reports for the county s review. The process is expected to repeat several times until the reports appear valid. Q: We build Involuntary Civil Commitment of Sexually Violent Predator cases in CA (Circuit Civil). Do we need to exclude these from the Circuit Civil cases reported to UCR, or are there case type codes available for these? (added 6/14/2018) A: The Involuntary Civil Commitment of Sexually Violent Predator cases are not part of UCR at this time. The reporting requirements have yet to be defined. Please exclude them from the Circuit Civil division for reporting to UCR. Q: Are County to Circuit Appeals also being excluded from the Circuit Civil phase of UCR? (added 6/15/2018) A: The codes to report an Appeal from County Court are being added so that UCR can replace all of the Summary Reporting System requirements. Q: How do I test our connection to the OSCA s web service? A: During transition, you will test connection to the OSCA s test web service before being permitted to connect to the production web service. Please see www.flcourts.org/jdms for the technical specification. You will need to request your county s user credentials OSCA. Q: My vendor supports multiple counties. Do they need unique credentials for the web service for each county? A: Vendor-specific credentials will be provided that can be used for all customer counties. However, both the test and production web service can only be reached from the internal court network. Q. Who do I contact for assistance with connecting to issue with the web service? (added 6/12/2018) A. Send an email explaining the issue to UCRhelpdesk@flcourts.org. OSCA staff will initiate a help desk ticket for our network team. If you would like someone to contact you regarding the issue, please include your contact information in the email sent to the UCRhelpdesk. If you do not include a contact, the network team will only notify the OSCA s UCR team of any resolution.
UCR Case Activity Events Q: If a case closes, we must report a Case Closure event record. Since the case status element is not part of the Case Closure event record, do we also need to send a Case Change event record to show the case status changed to CLOSED? A: No. If a Case Closure event is sent, the UCR system automatically sets the case status to CLOSED for that case (or case subunit). Similarly, when a Case Reclosure event is sent, the case or case subunit s case status is automatically changed to RECLOSED in the UCR system. The type of event submitted communicates the case status information. Q: How do we report if a case type changes at disposition? A: If it changes at disposition, it can be reported as part of the Case Closure event record, as any and all fields that also change on the event date/time should be submitted. Alternatively, a separate Case Change event for the case type may be submitted in this scenario. Q. Can we send unchanged fields in a Case Change Event as long as at least one field in the Case Change Event changed? (added 6/12/2018) A. Case Change Events should only contain information that changed from the last submitted values. Each Case Change Event may contain a single changed value or multiple changed values, if applicable. The format of the Case Change Event record was designed to allow for the clerk to make multiple changes to the same record without submitting individual Case Change Events for each change. While the system is designed to handle unchanged fields, submitting these fields could have adverse effects on the system. Q: Will it be considered an error if a Case Reopen event record is received before a Case Closure event record? A: As long as both records are sent close to one other (less than a day between the two records), our system will not flag this to be an error. The event date/times on each should reflect the actual date/time that the closure occurred and the reopen occurred, which will order them correctly in our system. Q: If a case is currently in an INACTIVE status, and an order of judgment is received, do we have to report a Case Change event placing the case back in ACTIVE status before sending a Case Closure event record? A: No. Sending the Case Closure event is sufficient. Q: How to we report multiple reasons for a case being placed in an INACTIVE status? Do we send all the reasons for status change or only one?
A: Every reason for status change may be sent as a separate Case Change event (with an INACTIVE case status) in order to report each reason. However, only one Case Change event placing the case or case subunit back in ACTIVE status is needed (with a single reason for the return to ACTIVE status). Q: Currently, we don t place any cases in INACTIVE status. Cases that have a suggestion of bankruptcy are closed in our CMS to allow to proper reporting to SRS. Can these cases continue to be reported as closed in this scenario? (added 6/13/2018) A: Case status identifies those open cases on which the court can proceed and those on which it cannot. The definitions of ACTIVE and INACTIVE cases were established in AOSC14-20 In Re: Case Event Definitional Framework. A suggestion of bankruptcy is one of the established reasons a case is placed in an INACTIVE status. This allows for the actual disposition on the case to be reported at the time of closure, with the corresponding closure date, disposition categ. Q: According to AOSC14-20, a case in mediation should be placed in INACTIVE status. However, while the case is actively going through mediation, hearings may be scheduled. Do we report the case as ACTIVE upon scheduling the hearing? Do we report the case as ACTIVE when the hearing is held since the court in engaged with the case? The clerk s office often does not know if the hearing actually took place. A: It is not required to report the case as back to an ACTIVE status upon scheduling a hearing. If the hearing occurs (so the case is technically ACTIVE for an hour), and the case is immediately INACTIVE again due to what happens at the hearing, there is also no requirement to report the change in case status. Case changes lasting for less than a day are not required to be reported. If at/after the hearing, the period of mediation is over and the case returns to the court, the case should then be reported as changed to ACTIVE status. Q: A case may receive an order to remove to Federal Court, but later, the case comes back to the court and is heard in this jurisdiction. How should the order to remove to Federal Court be reported? Is the case Closed or in Inactive status? A: Report the case as Closed with the disposition category Transferred to Another Jurisdiction. (Note: This is different that the SRS rules, which direct the case to be reported as Disposed by Other.) If the case is returned to the trial courts, report a Closure Vacated record. Q: If a case contains three subunits (i.e. parcels in Eminent Domain cases), do we send one Case Initiation event record with three Case Qualifier elements or three separate Case Initiation records, one for each case qualifier? A: You must sent three separate Case Initiation event records, each with a different parcel number as the Case Qualifier. Each time an event occurs for one of the parcels, a Case Change,
Case Closure, etc. record will be sent for that individual parcel. That way, each parcel can have its own disposition date and disposition category, if applicable. Further, one parcel may be closed and already reopened, while a different parcel on the case is still in open from its original filing on the case. Q: For cases requiring a Case Qualifier (such as parcels in Eminent Domain cases), if the first parcel is disposed but other parcels on the case are still open, how do we report the closure of this parcel, but not the rest of the case? (revised 6/15/2018) A: A Case Closure event should be submitted for this subunit of the case (which includes the Case Qualifier Type and Case Qualifier Value). An N would be reported in the Case Closure Flag field to indicate that this event does not close the entire case. The other parcels on the case will remain in their current status. (Please note that reporting a Y does not automatically close the outstanding subunits on a case. Each subunit needs its own Case Closure event with the appropriate date of closure and disposition category. The mechanism for closing multiple subunits with a single event is to populate the Case Qualifier Value with ALL.) Q: Consider the following scenario: There are four parcels on a case. Three parcels are closed, the first of which is already reopened. The fourth parcel is still open from the initial phase of the case. Do we report a Y for Case Closed Flag upon reporting the fourth parcel s disposition (since one parcel is in REOPEN ACTIVE status)? A: Yes. The Case Closure Flag applies to the phase of the case the closure (or reclosure) is reporting. When reporting the fourth parcel s closure, since this is the last parcel on the case to be disposed of, the Y can be reported in the Case Closure Flag (all parcels have been closed, despite the fact one has already been reopened). Later, when the first parcel currently reopened is reclosed, a Case Reclosure record can be sent with a Y can be reported in the Case Closed Flag to indicate the reclosure applies to the whole case (assuming no other parcels were reopened in the interim). Q: The Case Qualifier Value records the specific identifier for the subunit of the case (i.e. the number used to track this individual parcel within the case). Is the value expected to be a human readable/meaningful value (i.e. the spelled out parcel number as shown on documents), or can it be our local CMS serial ID for that parcel? Both qualify as the number used to track the parcel. It just depends on whether you re asking a programmer or business user. (added 6/13/2018) A: Ideally, it should be something meaningful to a business user. It wouldn t have to be the entire parcel number as shown on documents, but certainly can be. It should be a value that distinguishes the parts of the case and will be helpful to a business user looking at a report. (For example, the report will show that Parcel #1 is open, but Parcel #2 is closed. Will the business user find this useful?)
Q: What should the qualifier value be for a RPTCAT qualifier type? (added 6/13/2018) A: Similar to Case Qualifier Value, this is up to the local jurisdiction, but should be meaningful to a business user. Q: What is a team and is this a required element to report? I don t think our county has teams. A: A team is a group of two or more judicial officers (judge, senior judge, magistrates, hearing officers etc.) who jointly share responsibility for managing and adjudicating a case in such a way that no one judicial officer can be determined to have primary responsibility for that case work or outcome. Examples: A pool of senior judges manages cases on a day-by-day basis. Each day, a senior judge will handle cases scheduled for that particular day. If the work for that day includes a disposition, then that senior judge on duty disposes the case. If it does not, the next action on the case is set for another day where a different judge in the pool will handle. Two or more judges within a circuit take turns traveling to different counties each day in the circuit to hear foreclosure cases scheduled for that day. Q: How do I report a team? Do I report a Team Assigned instead of a Primary Judicial Officer Assisgned? A: There are two elements in the ucr02 xml schema that can be used to report the primary judicial officer for a case. One is the group of evtprimofc (primary judicial officer) elements for last, first, middle, middle initial and suffix for an actual person. The other element is the evtteamassignment (team assignment), which contains the name of a group of judges assigned to review cases equally. Not all counties and circuits use the team concept. For those that do not use teams, there is no need to report anything in the evtteamassignment field of the UCR event record. For those jurisdictions that do use teams, it is critical that cases be reported assigned to these teams so that the court system can effectively measure the work of the courts. Q: Since we don t name our teams as defined by the UCR specification, what do we report in the evtteamassignment field? (added 6/13/2018) A: Please contact the OSCA for guidance on developing team names for each division of court and in the future when a new team name needs to be added to the possible values.
Q: How do I report Supplemental Judicial Officer? A: A supplemental judicial officer is any judicial officer (judge, senior judge, magistrate, hearing officer etc.) who assists the judge who has been assigned primary responsibility for a case. You may report a supplemental judicial officer when one works on the case. You do not need to unassign the previously reported supplemental judicial officer. Examples: A magistrate who handles a case and writes a recommendation. A duty judge who fills in for the primary judge who is out sick. A judicial officer who handles one type of hearing or case conference within a specific case type. Q: Sometimes a different judge disposes of the case (his/her signature is on the disposing order), but the judiciary wishes the primary judge assigned to the case to remain the same. Currently, we do not change the case to that new judge in our CMS. Do we need to report this new judge to the UCR project? A: Yes, but in the Supporting Judicial Officer Assigned field. No change will be reported to the Primary Judicial Officer Assigned, and he/she will remain listed as the primary judicial officer, while the judge who helped to dispose the case is listed as the supporting judicial officer. Q: Follow-up to previous question: If a judge steps in to help with a single hearing and/or when the primary judge is sick, the clerk doesn t always know this information. Are we required to report the supplemental judicial officer each time a judge or magistrate works on a case? A: If the assistance is temporary, it is not required to be reported to the UCR. This field is to capture when a magistrate, senior judge, or any judge is working on a case to which the official assignment is to a different judicial officer. Thus, it is not required to be reported every time a judge steps in to help. If the assisting judicial officer actually issues a disposition on the case, it is appropriate to report at that time. Q: How do we report an order that vacates a judgment and dismisses a case simultaneously? A: Report two events to the UCR: a Closure Vacated event record and a Case Closure event record. Both records will have the same event date/time (as the order simultaneously vacated the previous closure and serves as the case s new closure date), but each record has a different
report/time since the case s previous closure would be removed in the system before the new one is entered. Q: After a case that has previously had its original closure vacated receives its new disposition, do the previously-submitted Case Reopen and Case Reclosure events need to be sent after the new Case Closure event? A: No, the reopen and reclosure events will not need to be sent again. Our system will retain the information, and the last record submitted will be the new case closure record. Q: How are existing reopens handled when an Order Granting Motion to Vacate is filed to close an existing reopen, but a reclosure has not been sent due to a pending reopen that has not yet ben reclosed? A: If a Motion to Vacate Disposition is granted and the original case returns to the court, the reopen block (which includes the pending reopen) will be considered reclosed at that time. If the case leaves the reopen state due to a Vacated Closure, that reopen block must also be considered closed. Once the case is closed for a second time, a new reopen block will begin immediately following the second closure. Q: Our local workflow differs greatly from the example on page 13 of the UCR Data Collection Specification (version 1.3.0). What does that mean for reporting to the UCR? (added 6/13/2018) A: Please contact the OSCA for guidance regarding how your local workflow and practices best fit into the requirements of the UCR.
Corrections and Maintenance Actions Q. What is the process for reporting a changed UCN? (added 6/12/2018) A. This is a two-part process. First, submit a Delete Case Action for the old UCN. Then, submit a Case Initiation Event for the new UCN. Q: What do we resend after a delete all reopen action? Do we only send the current corrected reopen (if one exists) or all post-judgment prior reopen/recloses? (added 6/13/2018) A: All valid post-judgement Case Reopen/Case Reclosure events should be sent after a Delete All Reopen action was submitted. Q: If we identify that an incorrect event date/time on a previously-submitted Case Reopen that has since been Reclosed, should we correct the Case Reopen s event date/time? Or is the UCR only concerned with the current caseload? (added 6/13/2018) A: Yes. You should submit a correction with the actual event date/time of the Case Reopen. The UCR is concerned with all case activity, including all post-judgment events.
Error Reporting Q: How do we know whether the records we sent were accepted or had any errors? (updated 6/13/2018) A: The OSCA will send an error report to the county that include any files rejected for violating the XML schema and individual event records containing errors. All files not included in the error report were accepted and processed into the UCR system. Counties are given two choices regarding how to receive errors: Email or via a Web Service. For counties choosing email, the errors will be in an attached csv file. Establishment of each county s error reporting process is part of Phase I of the UCR transition. Q: Can we ask if we currently have an outstanding errors? A: Yes. Please contact the OSCA at UCRhelpdesk@flcourts.org. Q: When the OSCA sends a specific error back to county, it includes a unique identifying number. Does the county need to submit the correction using the unique identifying number? (updated 5/25/2018) A: No. All errors should be corrected using the normal UCR event submission process. Most corrections will require a simple change event record with the appropriate event date/time and correct data element value. Some types of errors, such as errors in filing date or closure category will require the appropriate Case Initiation event or Case Closure event be resubmitted. The OSCA system will identify when an error has been corrected and will drop that error as appropriate. In the event that a particular error is unusually difficult to diagnose or to correct, the unique identifier may help OSCA staff when working with clerk staff to determine the best way of correcting the issue. Q: Once we correct a case listed on our error report, how do we know the error was successfully corrected? (added 6/20/2018) A: Each error report will contain the current outstanding errors. Corrected errors will come off of the error report once it has been corrected. Example: On July 1 st, the error report contains 30 errors. The county immediately corrects 20 of the errors. The July 2 nd error report will show the remaining ten errors plus any new errors from the incoming UCR events.
Reporting via CMS Replication Q: What is involved in reporting via CMS replication? A: For counties electing CMS Replication as their UCR reporting mechanism, the following steps are required during the Phase I/Evaluation process of their transition. During the evaluation process, OSCA staff will work closely with clerk staff to determine the replica s suitability for satisfying the UCR requirements. If determined to be suitable, the OSCA will complete the bulk of the work to extract, format, and transmit the UCR data packages as per the specification. Phase I is completed when an initial upload of all open and reopened cases is extracted by the OSCA. 1. The clerk of court provides the OSCA with access to a replica of their case maintenance system (via linked server connection). a. Access should be read-only. b. This connection must be stable and reliable, and replica access (userid, password) must be consistent. c. The clerk of court may use any appropriate replica configuration provided it enables sufficient access to enable efficient extract of data and sufficient bandwidth to support near-real time extract and transmission of data. d. This replica should include all court activity data, and not be limited to the required fields in the current version of the specification. e. If the replica is also being used to support the circuit CAPS viewer, or is maintained by the circuit, the clerk must establish an agreement between the circuit and county before the clerk of court may use the replica server to satisfy UCR requirements. This should include a discussion of bandwidth, storage space and technical assistance to the OSCA. f. Please note: The requirements of UCR reporting cannot disrupt the judges daily activities through their CAPS viewers. If OSCA access to a CMS replica that is supporting the circuit CAPS viewers will negatively impact the judges use of CAPS, the replica is not usable for UCR reporting. 2. The clerk s office provides the OSCA with timely business and technical expertise to ensure that the OSCA is extracting the proper data from the CMS replica and correctly associating data elements required for UCR. a. This includes the sharing of data dictionaries, data models, and other related documentation. b. Clerk staff is expected to collaborate with the OSCA to determine the required elements that can be extracted from the directly from the CMS replica and identify those that cannot be readily determined. This includes defining the business rules for deriving those data elements not available explicitly from the CMS replica. c. If technical expertise resides with a vendor, it is the responsibility of the clerk of court to make arrangements with the vendor for the necessary support.
3. The OSCA and clerk of court negotiate a Memorandum of Understanding to govern the ongoing process of sharing the case activity data maintained in the clerk s CMS replica in support of the Uniform Case Reporting requirements. Reporting via CMS Replication requires significant resources. The clerk of court is solely responsible for providing and maintaining those resources. If at any time it is determined that the replica server cannot satisfy the requirements of UCR, the OSCA will decertify its use and the clerk of court must report UCR data via the web services interface, which is the primary reporting mechanism for UCR. Regardless of the employed mechanism, all counties must actively participate in Phase II of their UCR transition. Please see the project s webpage (www.flcourts.org/jdms) for additional details on Phases I and II. The clerk, as custodian of the record, retains responsibility for report accuracy through the detail data, regardless of the reporting mechanism selected.