RE: [legalxml-courtfiling] Thought on CMS interface

["Winters, Roger" <Roger.Winters@METROKC.GOV>]

The reason many of us got involved with LegalXML in the first place was the potential we saw for the automation of a substantial amount of data entry that is typically done by the clerk while handling, recording, indexing, retaining, and providing access to filings in support of court processes.

 

We have a great deal of labor that involves the following sorts of action - for work where the task is simply to locate certain data elements in the filing (source document) and get those data elements entered into other systems (targets), at a minimum, into the official case index:

 

• Receive, route the document to the clerk doing the work (which assumes a receive, stamp, distribute process)
• Read enough of the document to verify which case, etc., and that it is the appropriate item to work on
• Locate the information (data elements) in the source document
• Obtain, open the target location or system into which the data element is to be entered
• Navigate to the appropriate place for entry of the information/data element in the target
• Key the information/data element into the target (that is, retype the data element value - this is to repeat, but not to re-use the keystroke labor used to put the data element into the source document, the filing, in the first place)
• Notate that the task has been completed (so it won't be attempted by someone else, duplicating effort)
• Go on to the next data element to be located, recognized, entered, etc., until finished
• Route the source document to its next destination

 

AND

• Discover that a data entry error was made
• Locate the source document to verify source data element and the target where the erroneous entry was made
• Make correction(s)
• Notate that correction(s) were made
• Return source document to its appropriate location
• Other clean-up work - follow the "downstream" actions taken using the erroneous information, in case further corrections are needed

 

I made up the above list, not to write a Use Case, but to help describe what potentially can be saved from automating the routine transfer of data from court filings to targets. We have about 8,000 documents filed daily in our court (serving the 13^th largest county in the US) and at least four data elements are required at minimum for each document for basic "docketing" (entry into the official case index). For about 60% of the filings, that's all we do. For the rest, more complicated actions are taken (e.g., setting up a calendar item, entering a judgment transaction). Whatever could be automated thanks to XML standards would constitute enormous savings in labor and time, for this court and in general, all courts.

 

Bottom line: The technical standards on which we focus are necessary but they do not fully address (yet) the data transfer automation that many of us have been looking for.

 

Regards,

 

Roger

 

Roger Winters

King County
Department of Judicial Administration

Continuing Legal Education (CLE) Coordinator

and

Programs and Projects Manager

516 Third Avenue, E-609 MS: KCC-JA-0609

Seattle, Washington 98104

V: (206) 296-7838 F: (206) 296-0906

roger.winters@metrokc.gov

 

-----Original Message-----
From: Dallas Powell [mailto:dpowell@tybera.com]
Sent: Thursday, March 24, 2005 10:35 AM
To: Electronic Court Filing Technical Committeee
Subject: [legalxml-courtfiling] Thought on CMS interface

 

Last week I was working with some clerks, their IT staff, and the CMS vendor to launch efiling at a new court.  We were analyzing and mapping all the processes required to integrate to their existing CMS and DMS.  In this case the CMS is a case maintenance system not a case management system and the behavior is different.  During this process I continued to reflect back on the use cases that we were discussing in SLC.  The reality of the situation is that the communications between the CMS and our software requires workflow that clearly was not identified in the use cases.

 

After thinking about the situation, it occurred to me that the current use cases that we were including in Blue were use cases that support the functions that support the functions of an external court source (formerly known as the EFSP functions).  The use cases do not address the complexities of workflow to automate clerk behavior and actions.

 

The court we are working with wants to minimize clerk entry and review, thus capture the necessary data so that the interface between the receiving function at the courts will perform the actions the clerk would  do if they receive paper documents.  Some submissions require human intervension and decisions and those submissions cannot be completely automated.

 

My interest in sharing these thoughts with the group is to manage expectations of courts that eventually will request their CMS vendors to support the CM API in Blue.  We do not want the courts to think that the use cases we are working on are all that is needed to automate their efiling process.  The CMS use cases in Blue are designed to support the external efiling submission process and it does not completely address the automation processes that may be embedded in the clerk review functions.

 

Dallas