This installment in the court case management series explores the concept of groups and relationships.
***
By James McMillan and John T. Matthias, NCSC, September 2012
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 the 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 are unable 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 can 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 multiple 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 needs to track the status of those claims and which parties are involved. Again, many CCMSs are unable to easily handle the patchwork 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 “offender 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.).
So what is a potential answer? 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 minds 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 to facilitate judges and court administrators managing relationships and groups.
Next time: Configurability
Footnote: The original Court Technology Bulletin “four bubble” case management series of articles contains a longer discussion of the concept of relationships as the overall theme. (PDF)
Links to previous articles in the CCMS 2012 Series:
- Introduction
- Part 1: It's About Change
- Part 2: Does it help you do your work?
- Part 3: The Court Organization, Users, and Roles
No comments:
Post a Comment