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

Events

(Slightly) relational

Contents

Views

For the case management system, an event is something that happens in a case. These events fall into one or more of three categories:

• a document having been filed (e.g. an application for special leave to appeal);
• correspondence having gone out from the Registry (e.g. a draft index to an appeal book having been sent to all parties for comment); or
• something having happened (e.g. a case having been heard by the Court).

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. Each case document has two scrollable windows (one for past events, one for pending) which list all of the events attached to that case. This allows the user to see, at a glance, the status of the case: what has happened in the case thus far, and what is expected to happen next (see Figure 8).

An event becomes past when the user confirms that the event has "happened". 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 which has just happened).

When the user creates an event for a case, she/he has more than 50 basic events from which to choose. The system assists the user in this choice by suggesting the next most likely event from a list giving the normal sequence of events for cases of that type (see Figure 9). If the required event is not in this first list, the user is able to choose from a list of all events that can occur in cases of that type. Finally (for extremely unusual events) the user is able to choose from a canonical list of all possible events, for all possible case types.

Sometimes the link between two events is stronger than merely the occurrence of one suggesting the occurrence of another. For example, when an index to an application book is settled (i.e. when an "index settled" event occurs) the application book becomes due at a specified time (i.e. an "application book" event is expected). So, when an "index settled" event is set to past, an "application book" event (with an appropriate date) is added to the list of pending events for that case (see Figure 10). As well as clearly indicating the status of the case—that the index has been settled and the application book is due—the automatic creation of pending events in this way reduces the amount of data entry required of the user by filling-in as many as possible of the fields in the pending event when it is created. For example, the likely date, and filing party of the "application book" event can be filled-in based upon the values of fields in the "index settled" event when that event is set to past.

The fields that make up a given event document vary depending upon the type of the event, allowing various information to be stored about different types of 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 means that a search for a string which 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.

Similarly, if a party or its legal representatives were to create and electronically file a document in the Court (a process not presently permitted by the High Court Rules) that document could be automatically attached to an appropriate event document in the cases database. Like any document in the database, the electronically filed document (which would not have to be a Notes document) would also be indexed for Notes's full text searching.

(Slightly) relational

Contents

Views