Please note that these materials are provided for historical purposes only. The information presented is out of date and may be neither accurate nor useful. External hyperlinks may no longer be valid. For current court technology information, please see the new Court Technology Bulletin.
January/February 1995 Volume 7 Number 1
Court Case Management Systems - Part 1
James E. McMillanDo you remember those introductory college courses? They were aimed at developing the understanding upon which more advanced courses were built. Likewise, to build or purchase an effective automated court case management system, one needs to understand the basic structure of court data. Visitors to the Court Technology Laboratory have heard this before, so please forgive my repetition.
When I was with the Arizona AOC, I was having a difficult time explaining to county and city automation staff why automated court case management systems (let's call them CMS for short) were difficult to build and maintain. Then, I had one of those "eureka" experiences and came up with the model that will be discussed in this article.
The CMS Challenge
Automation and court professionals find it difficult to design and build a CMS due largely to the relationships between the data. The model shows the four basic types of data maintained in courts: person related data (defendants, parties, attorneys); time related data (court calendars and reminders); case data (history and records); and financial data (fees, fines, work, and jail). The difficulty in automating court data is that each of these data types relate to each other in a many-to-many relationship. Let me explain.
Your bank account is a nice one-to-many relationship (we automation types like this term, which really means that it's easy to program). You have an account number by which all deposits and withdrawals are tracked. It is easy to program the computer to search all the records relating to your account, do the math, and produce your monthly statement.
In contrast, an "account" (i.e. person) in a court system may have many different actions, in many different stages, in many different cases. For example, a criminal defendant may simultaneously be involved in a domestic relations case, civil case, as well as multiple criminal matters. Each of these cases has its own time events on the calendar, many different filings, and a mix of attorneys and judges. The criminal defendant may also be paying on previously levied fines and child support. All of these relationships between persons, cases, time, and money can become very complicated very quickly. This is not good news to a computer system designer and programmer who must define these relationships to build the CMS.
In the 1970s, programmers built offender-based tracking systems (OBTS), which use a hierarchical database structure (a.k.a. the one-to-many relationship you just learned about). Now there are relational databases that are more flexible and allow programmers to build both one-to-many and many-to-many relationships. Unfortunately, relational databases still require programmers to define the relationships as they are building the system to get decent performance in retrieving and storing information. This is why current court case management systems use either a person-centered or case-centered design to access the database records. Person-centered systems--those systems using a person’s ID number such as a drivers license or criminal ID -- work best in traffic, criminal, and juvenile systems. Case-centered systems -- those using the case number as the primary access point -- work best for civil, probate, and appellate systems.
The future will bring object-oriented database systems, which will let programmers define relationships between data the way the courts work -- dynamically. If we find out today that the defendant is really part of a gang that is being indicted in another racketeering case, we can set the link between the two cases. Thus, when actions occur in either case, the other case’s records are automatically linked and the reader can easily view all the actions relating to the defendant. The difference between object-oriented databases and relational databases is that links can be easily removed or new links created if the information proves to be incorrect.
In the upcoming parts of this series, I will discuss each of the four basic types of data that are kept by courts -- person, time, case, and financial. I will also discuss the relationships between data types, and how current and future court case management software deal with the day-to-day complexities of court operations.
If you have any questions, or would like to comment on this article you can reach me through my new Internet address: jmcmillan@ncsc.dni.us or through the TIES/CTL Bulletin Board System at 757-259-1839.
James E. McMillan is the Director of the National Center for State Courts Court Technology Laboratory. This is the first of a series of articles to be written by Jim regarding case management systems.
Back to Court Technology Bulletin
Send comments to webmaster@ncsc.dni.us!
