Frequently Asked Questions

Transcription

1 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: 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 this field is required on all case closures. A separate Case Change event does not need to be submitted in this scenario. 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: 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.

2 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: 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: 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.

3 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: If a case contains three subunits (i.e. parcels), 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 Qualifer (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? 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

4 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: 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?

5 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 evtprimjofc (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: 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

6 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: How do we know whether the records we sent were accepted or had any errors? 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. Q: Can we ask if we currently have an outstanding errors?

7 A: Yes. Please contact the OSCA at 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? 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.

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

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