[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-courtfiling] Thought on CMS interface
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:
AND
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 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-----
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]