Escaping the relational database paradigm:
Case management in the High Court of Australia

System structure

Lotus Notes

Contents

(Slightly) relational

The new case management system comprises several interconnected Notes databases:

the cases database holds information about cases in the High Court;
the representatives database holds information about the representatives of parties to matters in the Court (firms of solicitors, or self-represented persons);
the practitioners database is the register of legal practitioners who are entitled (by virtue of their ability to practice as practitioners in one or more states or territories) to practice in any federal court, including the High Court;
the letters database holds correspondence generated by the system;
the reports database generates tables suitable for inclusion in the High Court's annual report; and
the private database holds, in a completely distinct database, information about cases which is accessible to only a few High Court officers (e.g. the real name of parties to a matter which involves the custody of children, who are known by their initials).

The interconnectedness of these databases is such that a user of the system need not be aware of the division of information within the system. Information is passed between the different databases, and users move between databases by following links between documents. So, for example, in a document in the cases database, the user is shown the name and contact details of a party's legal representatives. That information is obtained by the cases database from the representatives database. At the click of a button in the document in the cases database, the system opens a document in the representatives database allowing information on that firm of solicitors to be changed. Those changes are reflected in the document in the cases database when that document is next opened.

The cases database

The cases database contains three different kinds of document: cases, parties and events. There is a case document for every matter, or case, which comes before the Court (see Figure 2). Each contains information about the case: what type of case it is (e.g. an appeal, an application for prerogative relief, a writ of summons) what it is called, what it is about, where and when it was commenced, which officer is responsible for it, the location of the (paper) file, etc. The fields displayed in a case document vary depending on the type of the case: only those fields that are relevant to cases of that type are displayed.

Figure 2:

An example case document from the cases database, showing some of the fields available for storing information about cases of this particular type.

There is a party document for each party to each case (see Figure 3). This document stores information about who that party is, and who are its legal representatives. A summary of information about each party to the case is displayed in the case document and, by clicking a button, the user is taken to the party document for that case.

Figure 3:

An example party document from the cases database.

Similarly, from each party document there are links into the representatives database, connecting a party with information about its firm of solicitors (if represented) or with contact information (if self-represented). There are also links from party documents into the practitioners database, connecting a party with its solicitors and barristers.

Information about events which have occurred, and which may occur, in a case is stored in event documents. These events are the essence of the system's structure, and are discussed below.

The representatives database

A party's representative is either a firm of solicitors or her/himself (if self-represented). The representatives database is a collection of documents with contact information about these firms and persons (see Figure 4).

Figure 4:

An example representative document from the representatives database.

The practitioners database

Like the representatives database, the practitioners database is an uncomplicated collection of documents. Each document contains contact and admission details for a legal practitioner, and includes links to firm details in the representatives database where appropriate (see Figure 5).

Figure 5:

An example practitioner document from the practitioners database.

(Practising certificates and certificates of good conduct, issued to practitioners, are generated by this database and details of their issue are stored here for future reference.)

The letters database

At present, there are 22 standard letters which are generated by the case management system (see Figure 6). These letters are constructed upon the occurrence of various events; a letter is produced for each party to a case, as appropriate, and stored in the letters database. Some of these letters are quite complicated, and have many variants depending upon the values of different fields in the event document which generated them, and upon fields in case, party, representative and practitioner documents.

Figure 6:

An example letter from the letters database.

Once generated, each letter can be individually edited if necessary. Each can be printed immediately, or stored for printing (with other letters) later. The user can opt to print each letter to a printer, with a postal or a DX (document exchange) address as appropriate. An e-mail gateway can be enabled if required. The user can also opt to send each letter directly to a fax gateway, transmitting the letter by facsimile without ever having to print it.

Once printed, or faxed, a letter document can be marked as having been processed and stored in the letters database as a record of correspondence.

The reports database

The High Court's annual report includes 30 different tables analyzing the judicial workload over different periods of time. Each of these tables can be generated by the reports database, which interrogates the cases database for the information it needs.

The private database

Like most documents kept on the paper file associated with each case, most of the information stored in the case management system is public information. Information, which is not public, is stored in the "private" (classified) database. So, for example, if a case involves the custody of children, the parties to that case are known only by their initials. The appropriate party document is changed so that only the initials are kept in that document: the party's real name is stored in a new document in the private database, with a link between the party document and the private document (see Figure 7). Only users with a high security level can access the private database, so only those users can find out the real names of parties who are known by their initials.

Figure 7:

One of the links between the cases database and the private database. In this (fictitious) example, an alias is about to be created for a party. The party's full name and alias will be stored in the private database, and will be accessible (via the cases database) only by users with a sufficient level of access. After the "OK" button has been clicked, only the alias will be stored in the cases database.

Storing sensitive information in a separate database, means that users cannot use Notes's powerful full text searching capability to circumvent restrictions the system places upon their access to information. A search for "Smith" would not return a party document for a person with that family name if that person were to be known by an alias because the word "Smith" would not occur in that party document (as a visible or a hidden field). A user could only connect the word "Smith" and that person's party document via the private database.