RE: [legalxml-courtfiling] Thought on CMS interface

MHonArc v2.5.0b2 -->

legalxml-courtfiling message

[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]

Subject: RE: [legalxml-courtfiling] Thought on CMS interface

From: "Winters, Roger" <>

To: 'Dallas Powell' <>, Electronic Court Filing Technical Committeee <>

Date: Mon, 28 Mar 2005 10:22:17 -0800

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 13th 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