Court Case Management Systems Part 10: Documents

Courts produce documents…lots of documents.  So Court Case Management Systems (CCMS) should help to produce and manage them.

---

Court Case Management Systems Part 10: Documents
By James McMillan and John T. Matthias, July 2013

It should be no surprise that document automation was one of the first functions that introduced computers into most courts.  In those early days (70’s and 80’s) it was called word processing and the dedicated computers for that function were called word processors.  However, almost immediately the ability to “mail merge” data with templates to generate documents for notices and summonses was recognized as an opportunity to begin automating repetitive work.  That fact led to the NCSC itself developing a CCMS using a Wang Laboratories (when was the last time you saw that company show up in an article?) word processing computer in the late 1980’s.

From that time forward, as more computers were introduced into the courts, creation and editing of documents, particularly by judges and their staff, became an integral part of the fabric of the judicial system.  Most commonly, “free form” document creation used by judges was viewed as separate from the CCMS functionality because the results were printed and not stored.  And CCMS document creation functionality focused on standardized programmed letters/notice creation.  Only later did the CCMS generate documents that were created in an editable format (most often RDF) that a clerk or judge could revise or annotate.

But now, full document functionality is a core component in CCMS.   But please note that a document management system (DMS) is not a CCMS.  We will explain.

In Part 6 of this series on Tasks, Events, and Workflow, we touched upon documents as part of the task-oriented interface.  Makes sense, right?  Almost all of the results of court tasks eventually involve the creation of a document.  The issue is, therefore, how much can the CCMS do to help create the document, and how much user interaction is required to complete the document creation task?  With this in mind, let’s divide CCMS documents into two general categories, static and editable.  But before we get into the document types, let’s talk about document identification.

Document Identification

From the beginning of word processing systems, file naming conventions were implemented.   This was hard to do with the original MS/PC-DOS 8.3 (http://en.wikipedia.org/wiki/8.3_filename) file name restriction.  Later, a DMS that connected a CCMS database to the documents through integration provided a lot more flexibility.  And CCMS, as a database itself, also can provide this document management service as part of its wider mission.  However, documents themselves with E-filing and E-Notice/E-Service need to have identification contained within the document itself.  This is where metadata can help or hurt.  In 2004, the Court Technology Bulletin noted issues with word processing metadata in this article: http://courttechbulletin.blogspot.com/2011/01/being-embarassed-by-your-word.html

Therefore, metadata contained in editable or PDF documents can and should be controlled and “fed” by the CCMS.  And in turn, when the document is downloaded and repurposed by the legal system, that metadata can be used to validate the document (when compared with the court’s source CCMS version) and potentially better categorized and used.

Static Documents

Static documents, most often some type of form notice, were the first to be automated in CCMS.  In many instances the CCMS output data was simply a report that printed an entire notice type of document (one court for example had different colors of paper for each type of notice it sent, that in turn facilitated sorting/processing when returned).  In other instances the system printed the data in the blank fields in pre-printed form documents.  Now, this is still a useful approach.  Self-seal forms/mailers are still incredibly useful for jury summonses, past-due/collection notices, and similar mass-mailings.  And postal systems are very good at producing this kind of output these days as they continue to expand their portfolio of business services.  This approach also reduces problems that courts in developing countries have affording printer toner, ink, and paper costs, as it is a centralized approach for their entire national court system.

And don't forget to bar code these documents, especially when they are printed on paper.  Quick Response (QR) codes could allow the document to be verified by a mobile (cell) phone connecting to the court’s database.  And bar codes facilitate both the identification of the case number but also carry data of the form of “event” being received by the court.

Editable Documents

As both CCMS and word processing programs advanced, it became possible for the CCMS to first produce the “mail merge” data file and later, to embed the data directly into the document in a document assembly process that in turn was saved for review/editing by the court users.  Editable documents are different from static documents in that they allow for text wrapping, pagination, and the ability to flexibly embed images, most often, a signature facsimile.

Until relatively recently, editable document formats were in proprietary formats.  This resulted in a considerable amount of work by CCMS programmers to be able to merge data into the documents.   But that has changed; “Standards to the rescue!”  Documents are now created in some manner of XML file format such as ODF, OOXML, or enhanced PDF.  Thus it is possible to write the data directly into the appropriate section of the XML file without disturbing the formatting or other parts of the document.  To read more about the Open Document Format (ODF) see: http://www.opendocumentformat.org/features/

We strongly recommend that courts consider adopting ODF and ISO standard PDF/2 for their CCMS document integration.  This approach allows multiple non-proprietary tools to work with the documents and provides a measure of “future-proofing” the resulting systems as these standards are already in place, and are widely used by the major and open-source software producers.

Further, editable documents are literally the raison d’être for appellate courts where documents are authored, shared, and modified by multiple authors in and between judicial chambers.  Therefore CCMS should be able to provide all manner of access/use security as well as organization, version control, and collaboration capabilities.   And the CCMS should also provide document authentication and signature capabilities with encryption that set a new bar for document, and hence information, protection.

In our opinion, the disconnected, non-integrated manner in which some courts have implemented document management systems separate from the CCMS has been one of the causes of judicial discomfort with moving to an electronic environment.  When one must go to multiple systems, or have no system to control electronic document information, that discomfort is warranted.

Therefore, user access control (including the public), encryption, digital signature, and document validation should all be “built-in” CCMS functions.  See: http://courttechbulletin.blogspot.com/2011/05/trust-and-e-filing.html
http://courttechbulletin.blogspot.com/2013/06/handwritten-signatures-now-punch-line.html

Electronic Documents as the Database

Finally, with documents being produced by and in concert with the CCMS, as well as coming into the system via E-filing, we believe that courts need to change a common view that document files and the CCMS database are separate entities.  It is not surprising that this occurred because court registry / docket books have been traditionally separate functions in the court organization from maintaining the court files that were used by the judges, chambers, and courtroom staff.  Now that documents are in electronic format and, as we suggest, referenced and stored by the CCMS database, they too can be used as part of that database.  Obviously searching both data fields in the database and text in documents should be part of a new CCMS system, thanks to new search technology and XML-enabled databases (accepting XML as input and rendering XML as output).  But if the documents contain XML markup (we wrote about that possibility here in 2006), then those searches become much more precise and efficient.  And, even better, the documents could contain data that would not need to be replicated in relational database fields. (please see Note 1 below)  Form-structured documents with XML tags are the obvious starting point for this combined approach.  But we would also suggest that court technologists should keep an eye on the work being done in the legal research industry in developing taxonomies (please see Note 2 below) and full-text indexes that provide a rich content environment.  After all, isn't one of the main points of CCMS to support the court’s decision making process?

Note 1: There have been concerns expressed that XML documents embedded in relational databases could hurt performance.  The major commercial relational databases have had this “hybrid” capability since 2004.  For those of technical readers who might like to see how the Oracle database system handles building different types of indexes to support XML as well as text data see this website/article: http://docs.oracle.com/cd/B28359_01/appdev.111/b28369/xdb_indexing.htm

Note 2: The OASIS LegalDocumentML technical committee is a good place to start learning about taxonomy work being done in this area.  As stated in the committee’s overview: “the LegalDocumentXML Specs provides a common legal document standard for the specification of parliamentary, legislative and judicial documents, for their interchange between institutions anywhere in the world and for the creation of a common data and metadata model that allows experience, expertise, and tools to be shared and extended by all participating peers, courts, Parliaments, Assemblies, Congresses and administrative branches of governments. The standard aims to provide a format for long-term storage of and access to parliamentary, legislative and judicial documents that allows search, interpretation and visualization of documents.”

There are links to work done by the African Akoma Ntoso project as well as to CEN Metalex and URN:Lex which has been written about here on the CTB in the past.

Next Time: E-Filing and CCMS

Previous articles in the CCMS series.