Page 1

Relationships of judges to cases, staff to judges, attorneys to cases, attorneys to case events, cases to one another, attorneys to law firms, parties to one another, and many other permutations are important to capture in a Court Case Management System(CCMS).  This is because information captured about relationships can greatly help both the court’s case administration and decision support functions.  But it is also one of the most difficult concepts to build into a CCMS because of its complexity.

An example of relationship complexity cited by our NCSC colleague Lawrence Webster of a juvenile court proceeding that may have as parties the prosecutor, three children of one mother, and three different fathers.  There may be many more participants.  Each child may have a separate attorney to represent each child, and a court-appointed special advocate (CASA) may be appointed for one, several or all children.  (Some states have guardians ad litem who may or may not be attorneys, to represent the best interests of the child, not necessarily the child itself.)  The mother will have an attorney representing her.  Fathers participating in the case may have their own attorneys.  Add to this constellation of case participants some number of social workers and investigators, and the result is a complex set of relationships that many CCMSs should able to easily handle when the court needs to give notice of hearing or send a copy of a consent decree.

The second related concept is groups.  Group functionality in a CCMS should serve greatly increase system efficiency.  For example, court session scheduling can be more efficient by organizing and referring to the judge’s courtroom team as a group.  Then a single functional call to that group in the database can associate those persons to that court session.  But more commonly, cases may be grouped.  In a court that creates one case per charge, one traffic stop may result in a traffic charge (the probable cause), seat belt and insurance violations, and a DUI charge resulting in four cases total.  These cases need to be scheduled and handled as a group.  The defendant may have another case or set of pending cases related to another incident, which may become part of an overall plea agreement, which need to be scheduled together.  And the defendant may be on probation, for which the new offense(s) may be grounds for violation of probation.  Thus when a motion is received that applies to these grouped cases, the CCMS should enable a single docket/registry entry for notice of hearing, and generation of a notice, to automatically apply and be recorded in all of the cases based on the grouping, rather than individually, case by case.

In complex civil litigation, a case may have multiple plaintiffs/ petitioners and multi defendants/ respondents (claimants).  These parties and counter-claimants, cross-claimants, and third-party claimants may be involved only as to certain claims, so only parties involved in motions concerning certain claims need be noticed for court events or sent court orders.  As certain claims are amended, adjudicated or settled, the CCMS should track the status of those claims and which parties are involved.  Again, many CCMS should be able to easily handle the patch work of claimants and claims.

These examples show what everyone in courts knows -- relationships and groups are dynamic and complex.

It is therefore challenging for relational database designers to be able to reflect this complexity in the CCMS.  Most systems that we have seen attempt to address this
requirement are often content to simply create a group table for a specific area and define it via a single linking number or name.   This is the concept behind the single “offend identification number” in criminal justice systems.

The issues do not end here.  There is also the need to define, for example, not just yes-or-no relationships described above, but also the term or length of an attorney relationship (for example, starting and ending dates for an attorney in the prosecutor’s office and for limited representation of a client by an attorney only for certain matters or hearings), and attributes (ongoing, temporary, formal employment) and/or definition of a relationship (employee, father, member, friend, colleague, acquaintance, etc.).

Very early in the development of the Internet a similar need was identified.  So the concept of meta-tags was introduced.  And since there is no limit to the number of metadata that could be associated with a record, this provides great flexibility in defining the relationships and groupings of case-related entities.

Parenthetically one might argue that metadata has no place in relational databases.  But this view is now dated since the major relational database systems from Microsoft, Oracle, and IBM can all handle XML data natively in their systems.

Thus our court relationship data needs are mirrored on the Internet.  Great mind including the founder of the World Wide Web (the www typed at the beginning of most URLs), Sir Tim Berners-Lee, have envisioned a graphical connection called “Marbles” that provides a visual representation of relationship connections (see the graphics at the project website: http://marbles.sourceforge.net).  It’s clear that new tools are needed in CCMSs should have to facilitate judges and court administrators managing relationships and groups.