Skip to main content

Page 1

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

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.

Pciture: ccms9

But now, full document functionality is a core component in CCMS.   But please note that the 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.  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
( 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:

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 categorize 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. 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.

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, an document validation should all be “built-in” CCMS functions.  See:

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 will 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 will be provided 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 document 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.