legalxml-courtfiling — archive

RE: [legalxml-courtfiling] Thought on CMS interface

From: Roger Winters
To: [email protected]
Date: Mon, 28 Mar 2005 18:23:00 -0000

MHonArc v2.5.0b2 -->

legalxml-courtfiling message

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

From: "Winters, Roger" <[email protected]>
To: 'Dallas Powell' <[email protected]>, Electronic Court Filing Technical Committeee <[email protected]>
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 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

[email protected]