The Need for Court E-Forms Identification (Meta-Data) Standards - Part 2

In Part 1 of this series we looked at the ability to create XML meta-data identifiers in commonly used word processing and PDF applications. In this part we will explore the benefits of electronic forms identification.

***

As noted in Part 1, the “forms identification problems” are threefold. First, there is a need for CMS and E-filing systems to be able to easily recognize an E-form so that it can be routed (via automated work flow) to the proper department or person in the court. Second, and more important, the submitted forms ARE in many instances the contents of the case file and should therefore be viewed both technically and operationally as part of the CMS database. And third, because documents and forms are very often used by individually by themselves without a CMS/EDMS to provide a reference as to their origin and purpose that in turn provides more efficiently retrieval by the legal system information users. Each of these points will be addressed in the following sections.

Automatic Forms Routing

In manual court systems, the forms simply by their title often help a filer to locate the proper part of the clerks office to submit their document. A “small claims” pleading would go to, you guessed it, the small claims division. But most (I can think of only a few exceptions) current E-filing systems do not have the ability to “read” the documents being submitted. Therefore, submitters are asked a series of questions regarding the document that is being sent to the court (this approach was pioneered by the US Federal Courts in 1996). These questions are needed in order to identify and route the document to the proper section of the clerk/registry for review and acceptance¹. But, if the form was “self identifying” via meta-data, some or all of the questions wouldn't be needed. And since I would further argue that a majority of court document filings use court forms, this would significantly reduce redundant questioning and data entry work by the filer. And in turn this approach reduce costs to the litigants and improves the accuracy of the form work flow in the receiving court.

Forms IN the CMS

We have writtenabout XML and court case management databases in 2006; but have yet to see courts use these capabilities despite the fact that documents contain much more information for decision support, research, and statistical analysis than a what a CMS relational database (designed to support court operational processes) could ever hope to address. This is because relational databases have a fundamental constraint, they aren't flexible. The information containers (fields) and table relationships have to be set and built in the initial database design. And for court operations this is good. But to describe the case inputs and decision outputs via relatively locked relational design is a poor solution simply because civil and criminal justice systems operate and are governed by laws results in messy data that is best captured in a form and/or document.

But I also think that a significant problem and opportunity in using XML forms data as part of the case management system is that it is difficult to search and find the document data “in context”. Context is important because one wants to normally search for data by case type or even a specific event such as in the instances of a charging, sentencing, or modification of sentence forms. Librarians provide context by categorizing information in the catalogs. Similarly, court forms inherently provide this context simply because forms are designed to address a specific court decision or process need. If the forms are identified via their meta-data, that allows the court's automation systems to index and search by the type (the context) of the form.

For example, often courts receive policy questions that were not anticipated during the CMS or database design such as how many filers checked a particular status box? When these questions arise court staff must search through the documents in the case type files for the answer. But wouldn't it help if say for example one knew that the answer was on a particular form? If one could just call the list of those forms or better yet, just search for the answer in a particular form it would significantly speed and ease both the policy research and the results.

Non-Court Forms Usage

Third, meta-tagged E-forms can address the ability for non-court information systems to better access and use the court's information. Many court information users are interested in specific documents such as case initiation and sentencing/judgments. The normal retrieval approach is for the users/systems to search the case file (online or not) for documents by title. But this adds all manner of complexity and cost to the external user's work as courts are notorious for inconsistent docketing text entry and event codes.

Therefore information users should be allowed to search and retrieve (or even subscribe) to particular forms via their meta-tag identification information. And once retrieved, there is an additional advantage in that if a registered user has downloaded sentencing/judgment documents and, subsequently the court issues a modification of sentence or judgment, those users could be notified of new, related, or order modifying documents.

Potential Reference Fields

In researching this article I looked at several state's online forms libraries. I found the following data fields that were inconsistently applied.

• Case type
• Case sub-type
• Source – state, county, circuit, court
• Form name
• Form number
• Active Date
• Revision Date
• End Date
• Version
• Confidentiality flag

In addition the National Information Exchange Model (NIEM) has the following identifiers for forms that are of some, but not perfect help.

• j:IncidentForm
• j:IndidentFormName
• j:IncidentFormType
• j:IncidentFormComment
• j:IncidentFormSubmittedIndicator

Future Action

The final format of the identifier is of less consequence versus the completeness of the information. Each field could be identified by a separate XML meta-data tag. This is preferable. But because of possible PDF limitations, the concatenated approach might be easier to implement. And when the issue is model "purity" compared to something that is easily implemented, I normally choose the latter.

By concatenated I mean that the fields could be grouped into one line just like we have done in court case numbers for more than 100 years. For example:

Case Type-Source-Form Number-Active Date-Version-Confidentiality Flag

As long as the order and separators are consistent, the technologists can deal with it via E-filing.

Therefore, I would like to propose that the ideas presented here are something that our court standards groups such as the COSCA/NACM Joint TechnologyCommittee, CITOC, or OASIS-Open LegalXML, and perhaps others elsewhere could consider and study.

Your ideas? Comments? Please feel free to share below.

---

1 Or in the US Federal Courts example, automatically docketed/registered into their CM/ECF system.