PDF files can be read and printed using Adobe's free Acrobat Reader.
National Center for State Courts
Sixth National Court Technology Conference (CTC6)
Los Angeles, 14–16 September 1999
Note: The author was Deputy Registrar of the High Court of Australia during the development of the case management system discussed in this article. He no longer works for the Court, and the views that he expresses in this article are not necessarily those of the Court.
The slides used for the presentation of this paper are available as an Acrobat PDF file (1.4M/53 pages).
| PDF files can be read and printed using Adobe's free Acrobat Reader. |
|
The High Court is the highest court in the Australian judicial system. Its functions are to interpret and apply the law of Australia; to decide cases of special federal significance, including challenges to the constitutional validity of statutes; and to hear appeals from Federal, State and Territory courts.
The Principal Registry of the High Court is in the nation's capital, Canberra, in the Court's own building. (A virtual tour of the High Court building can be taken at <http://www.highcourt.gov.au/>.) In addition, there are offices of the High Court Registry in the capital of each State and in the Northern Territory.
The High Court Registry provides traditional registry services to the Court. These include managing the case flow of the Court, providing information to Justices concerning matters filed, and providing information to the profession and the public about the case flow and practice of the Court. Registry staff also respond to counter, telephone and written enquiries concerning the status and disposition of cases.
In early 1996 the Court decided to replace its case management system. It required a new system that:
After preparing formal specifications and reviewing existing case management systems in a number of other courts, it was decided to construct a system "in-house" rather than attempt to modify an existing system. The firm now known as PricewaterhouseCoopers was selected to construct the new system, using Lotus Notes. Application development proceeded through 1997 and the system "went live" for the first time on 2 January 1998.
The system has now been in use for over a year, and it is appropriate to review its operation and the extent to which it has met the specified requirements.
The decision to develop the new system using Notes was significantly motivated by a belief that Notes will be available, and will continue to be improved, for many years to come, and that people skilled in the maintenance and improvement of Notes applications will continue to be widespread. Notes has rich functionality and, to the extent possible in today's rapidly changing world, provides a "future-proof" environment within which to operate the system.
Lotus Notes databases consist of any number of documents. These documents, in turn, contain fields which can contain, essentially, any kind of electronic information. A scripting language, LotusScript, allows Notes developers to construct sophisticated mechanisms for processing the information contained in these databases. Document templates, or forms, determine how the information in a document is displayed, allowing information to be hidden for clarity or for security purposes, if required. Views display hierarchical lists of documents to assist the user in traversing a database.
All of the data in the documents that make up a database (including any embedded objects, or attachments, which are part of a field of a document) can be indexed for full text searching purposes. Using a Domino server, the content of Notes databases can be dynamically published to the Internet or to an Intranet.
The case management system comprises several interconnected Notes databases:
The decision to develop the system using Notes involved a departure from a traditional relational database architecture. Unlike traditional relational database solutions, Notes allows unstructured information (text, sound, pictures, video, etc.) to be embedded in a database, and indexed and manipulated in new ways.
In a traditional, relational database, information can be thought of as being stored in tables. Every record (or row) in a table is distinct due to a unique field (or combination of fields) called the primary key. Every field (or column) has a distinct name, but the same field can appear in many tables. The requirement of referential integrity in a relational database ensures that tables within that database are consistent with each other.
Much of the flexibility and power of Notes derives from its being freed of the constraints of relational databases. However, some aspects of the case management system's functionality require features of a relational database—an example is given below—necessitating the development of LotusScript programs to implement these features within the unstructured Notes environment.
The system is built around the concept of an event. An event is something that happens in a case, and falls into one or more of three categories:
An event can be shared by more than one case. So, for example, when several cases are heard together, a single hearing event—a single event document—is linked to each of those cases.
An event is either past or pending. A past event has happened; a pending event may happen. An event becomes pending when it is created by a user (because she/he expects that it will happen, and wants to indicate that expectation on the system) or it is automatically created by the system because another event has been set to past (because the normal sequence of events, for this type of case, suggests that the pending event will probably follow the event that has just happened). The fields that make up a given event document vary depending upon the type of the event.
The use of events means that on-line copies of transcripts, for example, can be attached to the event document logically associated with that transcript (a "hearing" event) rather than to the case document itself. Notes's full text searching mechanism ensures that a search for a string that occurs in the transcript attached to a "hearing" event will return that event, giving the user information about the hearing as well as ready access to a copy of the transcript itself.
In each case document is stored a list of summary details of the past and pending events associated with that case. This feature, which gives the user an easy-to-read summary of what has happened, and what is likely to happen, in each case, required the implementation of relational database features in Notes. However, each case document's list of event details is only updated to reflect changes to the event documents when the case document is opened (in a relational database, any change to a given field would be instantly reflected in any other field that was linked to it). This can produce anomalous results for ad hoc queries as the event summary details stored in case documents may not be up-to-date.
Several different views of the documents in each database are available. Users can access different views, depending on their needs. Some of these views restrict the documents shown (e.g. showing only documents for current cases); some sort the documents on different bases (e.g. by case type; by responsible Registry officer); and some do both (e.g. showing only current cases, sorted by case type). A view can list documents, or display them in a calendar format. Of course, none of these views changes the way in which the data is stored in each database. They merely provide different views of the same data, allowing the user to choose the most convenient view for her/his purposes.
The system allows the use of Notes's full text searching capabilities to generate ad hoc queries. Whilst packages exist which allow powerful statistical analysis of Notes databases, the Registry's needs have to date been met by Notes's simple search interface which allows the user to construct, and save for future use, general search queries.
The next phase of the project, pending approval from the Court and subject to the availability of funds, will involve making selected information from the case management system available over the Internet to any person with a web browser. If implemented, this will doubtless prove of great utility to parties and interested members of the public, and should reduce the number of routine enquiries about the status of various cases presently dealt with by Registry staff.
Domino includes native web publishing and server replication facilities. The ability to publish selected fields, including embedded objects, is an added advantage. Web access to this information would be made possible by regularly copying, to a proxy Domino server, selected information from the databases that make up the case management system. The proxy server would respond to connections from web browsers by dynamically producing hypertext markup language (HTML) documents.
The use of a proxy server to publish information to the Internet would guarantee the integrity of the primary databases: no direct connection to the system from the Internet would be possible. At worst, a hacker could gain access only to the proxy server. Any information damaged or changed on the proxy server would be restored at the next replication.
If the Court decides to proceed with this phase of the project, it is hoped to make the information available on the Internet in 2000.
The system contains data, migrated from the old case management system, for cases filed in the Court as early as 1980. The cases database allows three types of case record: full (for cases active since the new case management system became operational), partial (with a restricted set of possible events, for cases not active since the new system became operational and whose details were stored in the old case management system), and minimal (for cases for which the Court has no on-line information). These minimal case records could be used to store limited information on every case filed in the Court for which there is not already information stored in a full or partial case record. In this way, the new case management system could provide information on every case filed in the Court since its establishment in 1903.
The High Court's new case management system has been operational since the beginning of 1998. Some minor difficulties have been experienced. As explained above, the summary lists of event details in each case document are not automatically updated, which can produce anomalous results for ad hoc queries because the event information stored in case documents may not be up-to-date. This is due to Notes not being a relational database system, and could be overcome by updating all of the case documents before entering a query. Furthermore, the generation of data for the annual report places strains on the system, and the automatic generation of Court lists (a feature included in the original specification) has not yet been implemented.
However, the system has assisted workflow and improved management of cases within the Registry. It has also greatly simplified the generation of sophisticated correspondence, which has increased the amount of information regularly supplied to parties, explaining the status of cases and the procedures that have to be followed.
After a year of operation, the High Court's new case management system has met most of its specified requirements, and (if the Court approves the second phase) it will also improve the amount and quality of information that is available to the general public about cases before the Court.
| Home page: | <http://www.popple.net/james/> |
| E-mail: | <james@popple.net> |
| Last modified: | 14 September 1999 |