Frequently Asked Questions

Transcription

1 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 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 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: I see several different UCR specifications and XML schema s on the JDMS web page. Which specification and schema should I be using? (added 1/19/2019) A: Each UCR specification has a corresponding XML schema associated with it that implements all of the reporting requirements for that specification. The XML schema also serves as the data dictionary for the specification. The current specification is UCR Data Collection Specification v (Issued June 28, 2017) with UCR Data Collection Specification Technical Memorandum (Issued August 13, 2018) along with the associated UCR02 XML Schema Document Version Each revision of the specification and schema represent important usability and quality enhancements to Uniform Case Reporting and are the relevant standard in effect at time of issuance. All counties entering Phase I Transition must comply with the standard in effect at the time they begin Transition. Thus those counties beginning transition review after August , should use the UCR Data Collection Specification v (Issued June 28, 2017) with UCR Data Collection Specification Technical Memorandum (Issued August 13, 2018) and UCR02 XML Schema Document Version Those counties who began Phase I Transition before Technical Memorandum who are using XML schema are encouraged to upgrade to version as soon as possible. However, upgrade to schema version is not required to satisfy reporting compliance

2 requirements for these counties. A timeline for upgrade will be included as part of the Phase I review process. Q: How are the Phase I Milestones Completed percentages published on the Uniform Case Reporting (UCR) Transition Progress webpage determined? (added 7/24/2018) A: The progress recorded in the Phase I Milestones Completed section reflects the OSCA s understanding of the milestones achieved by each county in transition. The milestones are weighted based on complexity and the time they take to complete. Please contact the OSCA if you would like more detail on what has been recorded for your county and to let us know if there are additional milestones your county has completed. Q: In Phase I, are test files being reviewed independently of previous data sent or do all events for a case need to be sent in chronological order? (added 7/24/2018) A: During Phase I, the files are reviewed independently to ensure each event is formatted correctly and all required fields are provided. Each event will be validated against the ucr02.xsd and can be sent in any order without generating an error. When a county moves into Phase II, the events are processed into the UCR system and the review focus changes to checking for data quality and logic errors of the data being transmitted. For example, a Case Reclosure should not be submitted without previously reporting a Case Reopen event. Q: Is there a format for the data errors generated from submissions? (added 8/21/2018) A: The automated error process will not be in use during Phases I and II. Q: Can we send UCR events as they would occur in the real world to test the programming logic once our data package formatting has been validated? A: Yes. Although not required during Phase I, test events may be sent as they would occur as part of Phase I testing. The OSCA will do a test-run into the UCR system to see if any errors are generated. (added 7/24/2018) 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).

3 Q: What date should be used for the event date in the initial upload? (added 8/21/2018) A: The event date for Case Initiation records is the Date of Initiation while the Reopen Date is used for Case Reopen records. 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: Do we have to send each type of event in separate UCR data packages (as is done in the example files) or can we send multiple events in the same data package? (added 6/26/2018) A: You can send any combination of events in the same package as long as each event has its own unique report date/time. Q: What is the process once the initial test load works? (added 11/13/2018) A: Once the initial test load has been verified, you will send the initial load for production, preferably overnight. You will then be live in production with updates occurring every five minutes. 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.

4 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 if my CMS does not collect the timestamp for the Event Date/Time field? (added 6/26/2018) A: Ideally, all date/time fields required by UCR will include the time to help maintain the event order. However, Event Date/Time values may be submitted with all 0s for the timestamp if necessary. Please note that this is only applicable to the Event Date/Time field, and times are required on every event s Report Date/Time, along with all other date/time fields in the data package. Example: T00:00: :00 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 the xml elements required to be in a specific order? (added 8/15/2018) A: Yes. Please follow the current xml schema document published on Q: Are any of the data elements optional?

5 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: Is there a list of the elements expected to be reported via Case Change events available? (added 8/23/2018) A: The UCR Data Collection Specification Table 1 lays out the fields contained in the Case Change event record. A Case Change event should be generated when any of the fields under the second set of bullet points changes from the value previously reported (or not yet reported). The exception would be Case Status. When the status changes to one indicating closure or reclosure, a Case Closure event or a Case Reclosure event must be reported. Similarly, when a case reopens, a Case Reopen event must be reported. (A Case Change event reporting a Case Status of Reopen Active is not permitted in this circumstance.) The case status field in a Case Change event is available for reporting when an open case changes from Active to Inactive or from Inactive to Active. It is also available for reopened cases changing from Reopen Active to Reopen Inactive and from Reopen Inactive to Reopen Active. Q: Are there any restrictions on formatting the judicial officer name fields? (added 7/24/2018) A: The UCR Data Collection Specification Table 1 requires that judge names be formatted as strings. Punctuation such as hyphens and periods are allowed. However, please utilize the provided first name, last name, middle name or middle initial, and suffix fields, as appropriate for the name of the individual being reported. Q: When will we be able to stop reporting to the Summary Reporting System (SRS)?

6 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?

7 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 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? (updated 7/16/2018) A: Vendor-specific credentials will be provided for the development and testing of the web service component. However, once a successful connection is achieved, each county s individual credentials will need to be used to submit UCR data packages for both testing and production submission. Both the test and production url can only be reached from the internal court network. Q: Do we have to provide an IP address during the testing phase? (added 6/26/2018) A: No, the IP address is required before moving to the production environment. Q: What happens if the web service goes down or we otherwise lose connectivity? (added 6/26/2018) A: In the circumstance that a network connection is unavailable or network load is high, it is permissible to cache the case event records into a file (called a UCR data package) and once network connectivity is re-established or network load is more manageable, transmit all events recorded since the last data package was transmitted. Alternatively, complete UCR data packages can be generated and queued awaiting the re-connection. If this strategy is taken, please note that each post to the service may contain only one UCR data package. Q: Is there a limit on the size the web service will accept? (added 6/26/2018) A: In addition to the limit of one complete UCR data package (xml file) per post to the web service, the size restriction for a post is set to 25mb. Q: What encoding should be used on the UCR data packages? (added 6/27/2018) A: Please transmit UCR data packages as ANSI-encoded text. Q. Who do I contact for assistance with connecting to issue with the web service? (added 6/12/2018) A. Send an 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 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.

8 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: We currently record the date a closing order is e-filed as the case s closure date, instead of the date on the closing order. What is the appropriate Closure Date that should be used for the Event Date/Time when reporting to UCR? (added 7/5/2018) A: For closure orders that are e-filed, the clerk clock-in date from the e-portal can be used instead of the date the judge signs the order that disposes or dismisses the case. The rare exception may be if the judge orders the case s disposition to be effective retroactively. Q: Are the values expected for the Reason for Status Change element county specific or are there mandated reasons? (added 8/16/2018) A: This is local; no reasons are mandated. Any time a case has been designated as INACTIVE (or goes back to ACTIVE after a period of inactivity) a reason for the status change, which is determined by local practice and/or judge designation, must be reported. The specification provides for several codes provided from the local jurisdictions as common reasons for status changes. However, if a case goes inactive for a reason not listed, the OTH and OTH-DISP

9 codes can be used. The comment field will also need to be included to describe what the other reason was. Q: There is only one Reason for Status Change listed in Appendix B, Table 3 that we currently use. What do we do if the reason we use is not listed? (added 10/17/2018) A: The OSCA has tried to provide a comprehensive list of reason codes for the counties use. If you have a reason for status change that occurs frequently, but the code that is not available, you may contact OSCA to request that it be included as a provided Reason for Status Change. For the time being, the OTH or OTH-DISP codes should be used to report this particular reason, along with the Reason for Status Change Comment to indicate the reason. Q: We are required to include a free-form Reason for Status Change Comment when we submit a Reason for status Change of OTH or OTH-DISP. Do we have to send the same comment when reporting the complimentary Reason for Status Change? (added 7/31/2018) A: No. The comment submitted when reporting the OTH reason will not be matched to the comment when the OTHDISP is later reported. The OSCA has tried to provide a comprehensive list of reason codes for the counties use. If you have a reason for status change that occurs frequently, but the code that is not available, you may contact OSCA to request that it be included as a provided Reason for Status Change. 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: Can we send multiple Case Reopen event records for the same case that occur at different times before a Case Reclosure event? (added 10/17/2018) A: Yes. Multiple Case Reopen events may be sent without individual Case Reclosure events. Case Reclosure events, however, should only be sent when the entire reopen block is closed. Please see AOSC14-20 for more detail. 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.

10 Q: When we submit our initial baseline inventory of currently open and reopened cases, do we report the Reason for Status Change codes for all cases, using the appropriate codes from the Active to Inactive and Inactive to Active columns from Table 3 of Appendix B? (added 7/24/2018) A: Only the cases that are reported as INACTIVE or REOPEN INACTIVE during the initial baseline inventory should have a Reason for Status Change reported. The codes reported must be one of the codes in the Active to Inactive column to report the reason why the case has been placed in an inactive status. All cases that are currently ACTIVE or REOPEN ACTIVE during the initial baseline inventory should not have a Reason for Status Change reported. When the currently INACTIVE or REOPEN INACTIVE cases go back to ACTIVE or REOPEN ACTIVE status, the Reason for Status Change must be reported with one of the code values provided in the Inactive to Active column of Table 3 in Appendix B. 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 category. 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

11 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: What is the Transferred to Another Jurisdiction disposition category? This is not a disposition category we currently use for SRS. (added 7/16/2018) A: That s correct. Cases transferred to another jurisdiction, such as by an order to remove to Federal Court, are reported to the SRS in the Disposed by Other category. The additional code has been made available to counties to report this specific occurrence to the UCR. 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

12 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: If we send a closure for each subunit on a case but do not set the Case Closed Flag to Y on any of the subunit closures, can we send a separate Case Closure Event with the Case Closed Flag set to Y without specifying a subunit to close the entire case? (added 6/26/2018) A: No. The Case Closed Flag should be set to Y for the last subunit closed. The single Case Closure Event reported for the UCN without a designated subunit would be treated as a separate subunit. Q: If we send a closure for each subunit on a case but do not set the Case Closed Flag to Y on any of the subunit closures, can we send a subsequent Case Closure Event with a Case Qualifier of ALL per the bulk reporting method, and set the Case Closed Flag to Y? (added 6/26/2018) A: No. Use of the bulk reporting method results in changes to every subunit on that case. In effect, this would change the closure date for all of the subunits overwriting any previouslyreported dates for the individual subunits. 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)

13 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 Assigned? 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.

14 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 un-assign 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

15 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.

16 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. Q: The specification provides for updates to a closure date via re-submitting a Case Closure event with the updated Event Date/Time. How can we correct a case that was closed by accident and should never have been reported as such? A Case Reopen would not be appropriate in this instance. (added 8/27/2018) A: That is correct. The new Undo Event action (see Tech. Memo 18-01) has been developed to provide a mechanism for correcting the following event types: Case Closure, Case Change, Case Reopen, and Case Reclosure. This action replaces the previously-provided Undo Change action, which was limited to Case Change events. The maintenance action will allow a Case Closure event reported in error to be un-done. The only event type that cannot be undone is a Case Initiation. Two possibilities for correct exist for Case Init events in error: (1) re-submit the Case Init event with a corrected Event Date/Time, which will overwrite the original initiation date on the case or case subunit, or (2) submit an Case Delete action if the case or subunit should never have been reported to the UCR. Q: How do we correct the Event Date/Time on a previously-reported Case Reopen event or Case Reclosure? How do we accomplish this correction without it appearing to be an additional Case Reopen or Case Reclosure? (added 8/27/2018)

17 A: The new Undo Event action (see Tech. Memo 18-01) has been developed to provide a mechanism for correcting the following event types: Case Closure, Case Change, Case Reopen, and Case Reclosure. It directly solves the problem you noted. This action replaces the previously-provided Undo Change action, which was limited to Case Change events. The Delete All Reopen action can also be used, but this will remove all Case Reopen and Case Reclosure events previously submitted. The Undo Event action will remove a single event and must report the identifying information of the event to which it corresponds.

18 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: or via a Web Service. For counties choosing , 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 provide different addresses for different court divisions? (added 7/16/2018) A: Not at this time. OSCA will send all UCR errors to one address. The county may wish to set up a distribution group address, rather than provide a personal address. The s will flag each error as a technical or content error to assist with routing to the appropriate unit. 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.

19 Q: How will errors be delivered to the counties? (added 6/26/2018) A: There are two ways of receiving errors: web services or . Web services requires the county to host a service to receive UCR error packages (error files) sent by OSCA and is the preferred method. Alternatively, the county may request to receive the error files as attachments. Q: How often will errors be sent to the counties? (added 6/26/2018) A: Errors will be sent either in real time or at regular intervals throughout the day based on the level of error. Immediate errors are generated when a UCR data package cannot be processed by the system such as an invalid XML file. These errors are generated as they occur and sent in real time. Errors that are not critical to the process will be queued up to be sent in batches.

20 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.

21 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 ( 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.