Case management systems have made dramatic progress in recent years in the United States. Primarily this improvement has been made by commercial companies supplying software to the courts. However some courts, Wisconsin and Utah have developed good systems in house. I believe that there are several factors that have influenced this growth.

First, relational database software (the file cabinet for data) has allowed information systems designers to more accurately reflect the complex web of information that are court cases. This alone has allowed courts to justify the cost of new case management systems. My series of articles from The Court Technology Bulletin in 1995 which are attached as Appendix B to this paper describe the many-to-many relationship of data within courts. Hierarchical and index-sequential databases could never adequately reflect the fact that many judges are associated with many cases in many different and unique ways. This is example is but one of hundreds which exist within judicial systems.

Second, good application development software is now available. In the early 1990's several companies used advanced fourth generation computer tools such as Progress, JAM, and Synon to write court systems. Currently, at least seven companies are using PowerBuilder, Visual Basic, or VisualAge to write case management application software. These companies are:

• Choice Information Systems
• Crawford Consulting, Ltd.
• Evans Caseload, Inc.
• IBM
• Justice Systems, Inc.
• Progressive Solutions, Inc.
• Unisys

The Utah state courts have also written their government developed case management application using PowerBuilder and Informix database. I have attached a list of case management companies with Internet web addresses as Appendix C.

Third, event/table driven systems have allowed commercial case management companies to develop a "foundation" system which are easily modified to reflect the procedures of the courts where they are installed. Fundamentally speaking, all courts have a process. Events occur within the court. These events are recorded. The key is that event tables can be coded to tell the system the next series of steps that should automatically occur. These steps or events might be to schedule a hearing, produce a notice, or place a reminder in the queue two weeks from now. Court clerks are trained to know these steps based on the input (event) that is received. Event/table systems reflect this process, but more important they allow the courts to modify the process without programmer intervention. My paper in Appendix B further explains these ideas.

Fourth, use of word processing and ad hoc reporting programs have allowed court personnel to create and modify the output reports from the case management system without programmer support. Many companies provide interfaces between their case management systems and either Corel WordPerfect or Microsoft Word.

Fifth, and perhaps most important, a good economy generating tax income combined with less expensive computer hardware has allowed more courts to fund automation projects. This in turn has allowed companies already in the marketplace with their first generation products to develop a new generation of projects. Appendix A shows a map of the United States that details which states have purchased commercial case management systems for implementation. Wisconsin and Utah have developed new generation case management systems. Nearly all of these systems are some type of graphical (Windows) user interface and client/server architecture. A few are based on Unix and have a mix of dumb terminals and Windows clients. The remaining systems shown on the map are either older third generation mainframe or minicomputer based systems.

Sixth - years of teaching about active caseflow management have raised court's expectations of what court case management systems should do. This was recently reflected by a California Judicial Council task force who evaluated twelve (12) commercial and three government developed case management systems. As part of the evaluation the committee "brainstormed" the ideal system. I hope to have permission to reproduce this list for conference attendees. Suffice to say that courts are expect more work to be done by these systems than in the past.

It is an exciting time for case management systems in the USA. In the near future we will see increasing use of electronic filing to automatically feed the case management systems. Choice Information Systems currently has a pilot to test these concepts in Ontario, Canada. Further, development of data exchange standards for civil judgment reporting, bankruptcy reporting and criminal history reporting are underway. And finally, with the increase in computer power, we are starting to investigate optical character recognition for handwritten forms. This could facilitate data entry from law enforcement officers.

The Court Technology Laboratory project at the National Center for State Courts in Williamsburg, Virginia, USA has many of the top case management systems installed. We also continue to work with all the companies to improve these systems. I want to invite you to visit us in person in the future or, at least on our Internet site at: http://www.ncsconline.org/

The following articles were written by me and published in the National Center for State Courts Court Technology Bulletin throughout 1995. These articles explain the basic structure of modern court case management systems. Suffice to say that the goal of these systems for all courts is to produce work. Earlier systems were intended to generate statistics or produce management reports. This is not good enough today.

These articles can also be used as a basis for understanding commercially available court case management systems. With the increasing use of relational SQL compliant databases (that means you can read and manipulate the data with many software tools) and modern fourth generation languages, these companies have the ability to deliver complete systems to all sizes of courts. Therefore, it is very difficult to convince me of the need for government to undertake these expensive software development projects.

The National Center for State Courts is a federally chartered non-profit organization. The Court Technology Programs group maintains information on all manner of technologies which are useful to courts and the legal profession. If you require additional information please contact us at 757-253-2000, fax at 757-220-0449, or via Internet at our WWW home page: http://www.ncsc.dni.us or by e-mail at: tis@ncsc.dni.us.

 

 

I. Relationships

Do 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.

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 remainders); 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 time and 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 driver's 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 the links that can be easily removed or new links created if the information proves to be incorrect.

In the upcoming sections, 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.

In the first previous section we discussed the overall structure of court case management systems (CMS) and the four basic types of data--person, time, case, and financial--and their relationships with computer databases. In this article, I will focus on the most complex module, the person.

I use the term "person module" in the most global context. A person in a CMS is any individual or legal entity that interacts with the court, including judges, attorneys, clerks, litigants, witnesses, social service case workers, etc. As an example, a judge can be related to a case in several different ways. In an individual case assignment system, the judge is the sole adjudicating officer. In a master case assignment system, different judges may be assigned to different portions of the same case. Judges may also be a plaintiff (or even defendant) in their own courts.

Likewise, a person can have associations with many companies, family members (current and former), and attorneys, as well as with treatment programs, social service programs, court orders, and even warrants. It is the relationship of a person to the case that is important. A CMS must reflect the complexity of the relationships that occur in legal matters.

I stated above that the "person" is the most complex data module. If one recognizes the amount and complexity of the system data needed to related to a "person" rather than a "case," then one begins to understand the amount of work necessary to program a CMS. One of my criticisms of current criminal history systems is their use of hierarchical databases, which tend to simplify the data. The information is rolled up into the most serious offense, or category, or the most current data. Using relational databases, courts can collect all of the information necessary to identify patterns and practices of individuals and use this information to make better decisions.

To deal with the complexity of the person module, the modern CMS organizes data into many different tables, each relating to a person's master identification (ID) number. I recommend that court systems track multiple addresses against a person. Business and home addresses are obvious, but the ability to store a history of addresses is also important for postjudgment, collection, and warrant processing. While several persons may live or work at these addresses, the CMS links the individual to each place.

A unit in the District of Columbia courts has an excellent database for tracking pretrial drug testing. Although a person may be related to several different cases, it is the person and the results of his/her drug tests, even over several years, which is the focus of this database. In an ideal system, this database--although located in a different computer system--would be linked to the master person record and be directly accessible to the court for initial appearance and release hearings. The Midtown Manhattan Community Court Project offers another good example of effective person-related data linking.

Creating an accurate master identification number is one of the most daunting problems facing courts today. Courts currently rely on state and regional Criminal Justice Information Systems (CJIS) and criminal history systems using fingerprint identification for a person's criminal ID number. If the offense is serious enough, there may be a National Crime Information Center (NCIC) number. In most jurisdictions this identification process takes too long. Often, prior convictions are not alleged by the prosecution because of the time consuming nature of obtaining fingerprint ID. Also, many criminal ID systems have strict rules concerning the acceptance of conviction information with incomplete or smudged fingerprint cards. Consequently, many convictions are not entered into the state and national systems. Finally, for traffic and misdemeanor offenses, only location information is typically used to identify uncooperative persons.

Fortunately, technology will help. Automated Fingerprint Identification Systems (AFIS) are being installed throughout the country. If used in conjunction with "Live Scan" technology (a method of digitizing fingerprints), the process of identifying serious offenders can be greatly shortened, and accurate person identification numbers can be q quickly obtained. Also, some state motor vehicle departments are beginning to photograph drivers digitally and to store these images in central computer systems. With the growth of the "information superhighway" courts can plan to match defendants' faces with their official driver's license records. New technologies such as voice print also identify persons quickly.

Through good design and planning, an effective person-related module of court case management system can capture and store this type of data for case processing and post-adjudication work.

In the previous two sections we discussed the overall structure of case management systems and the first of the four major sections, the person module. Last time I promised to discuss the time module in this article. I’ve changed my mind. (I mean really, it is my prerogative since I'm doing the work). In this article we will discuss the easiest of the modules, the case module. I say that it is easy because good automation design of this module gives the courts the greatest potential to grow in the future with the greatest benefit.

Simply, the case tracking module is the case history. In a manual court clerk's office the case history is traditionally found in the docket book or the register of actions. In some systems the documents and actions received in the clerks office were separated from the actions which occurred in the courtroom. These actions were recorded in "minute books". Suffice it to say that courts have found a need to record a case history.

At this point we should probably ask why courts decided to keep docket books. First, the case history provided a quick reference to the clerks on the status of the case and the documents that were received. Second, it was a double check against the case file to determine it's completeness. And third, it could be used to quickly review the results of cases without having to read the case file.

For automation purposes, it is best to view the case module as simply tracking events. For example, events include when documents were received; when the court issues an order; when the court held a hearing; or, a case terminating event occurs such as a payment of a fine or a convicted person completes probation.

Current automated case modules have several elements for tracking these events. First is always the date of the event. Second, some type of numeric or alphanumeric code is typically assigned to the event. For example "INF" might signify the initial filing event. These codes are convenient for statistical tracking and for shortcutting data entry. The computer system will either "look up" the associated text in this case for the initial filing and place it in a text field or, dynamically display the text when the case history is accessed or printed (dynamic allocation saves disk space which was formerly a great concern). Third, good systems will allow either free text to be entered relating to the event or, provide a link to the related electronic file that contains the description of the event. Very good systems will have word processor type capabilities for this work. Free text is necessary since the road to justice is not like an accounting system where everything must be registered under an account number. Pre-coded entries, while fine for most events cannot meet all the requirements of the court, especially for sentences and judgments. Therefore, automated systems must allow the court to accurately enter what has occurred.

Some case management systems will add fields for additional material such as fees associated to the case event, the judge and/or clerk who entered the event, and other statistical "flags". With good relational databases most of this work can be handled through links to other tables. However, if you have a large volume court, it is probably best to forfeit some disk space to gain speed in retrieving this information.

The future of the case module is in it's links to electronic documents (JEDDI), and images. Remember that the case module is the history of the case and the summary of the case file. If I were designing a new case system today I would make sure that the electronic documents or images were summarized only once in the case module. It doesn’t make sense to keep two distinct systems (document/imaging system and case tracking system) that index the case file if you are dealing with electronically stored documents. After the electronic documents are stored and properly logged and summarized, comes the big payoff... workflow. Case events should be coded with "triggers" (thanks to Oracle for that term) so that once an event is logged, the next scheduled event and the case file or document is cued into the calendaring/tickler reminder system for the judge or other court staff member. When you log into your workstation, your daily tasks will be presented to you. No more looking for that lost file. Also, once the triggering system is in place, work can be evenly distributed. Bottlenecks can be identified and dealt with.

Time, the court's most critical resource. As most of us know, government is typically frugal in their financial support of the courts. Court managers have learned to manage the time used by the judge and by the litigants when they come to the courthouse. However, I believe that courts have not been as active in the management of staff and "out-of-court" time. A good "time module" in a case management system will help courts use time more efficiently.

When courts talk about the time-tracking function of their court case management system they are typically referring to the court's calendar system. Many court administrative offices manage the court's formal calendar for courtroom and chambers. Court use standalone calendar automation, which is not connected to the case management system. I believe this is a mistake; here's why:

I define the time function in global terms. First of all, when I refer to the time module, I am referring to events that will occur in the future. I don't care if they are formal events, those appearing on the traditional court calendar, or events that either the court staff or the court's computer system needs to perform. My ideal time system creates many different calendars. The formal ones for the court actions and informal ones for the staff. Clerks need to know when to produce notices. Judges need to know which cases to prepare for. Everyone needs these informal tickler systems, which result in action.

Action is the key word here. I often talk about the case management "shark." Most sharks have to keep moving to stay alive. So, too, do our cases. Every case should have a future date set for either court or clerk action until it is finally completed (and I mean really finished--not just for statistical reporting). This includes probate and juvenile cases, which may require decades to complete. Courts should schedule some future date to review the status of these cases.

Now you might complain that the court has enough to do just to keep up with the events on the court's formal calendar. Again, this is because the time-tracking function is not effectively linked to the remainder of the case management system. It is important to have time events automatically "triggered" (there's that word again!) from the court calendar, from the financial system, and to a lesser extent from the person databases. For example, the receipt of a pleading means that the computer system needs to create a notice (queue number 1), set a hearing (queue number 2), and set time for the judge to review the pleading before the hearing (queue number 3), and if a response is not received from the opposing party, a reminder is sent by the clerk (queue number 4).

Clerks and judges carry this flow of cases around in their heads. They know about the court rules that require a notice to be mailed once a hearing has been held or the time standards required for receipt of a pleading. Since they know this information, a computer can be programmed to take care of it -- if it is linked to the other parts of the case management system. If not, clerks and judges have to enter the information into some other program on their computer systems or into an informal to-do lists. They should just let the computer do it!

These automated work queues will be especially handy as courts implement imaging and JEDDI systems. The computer will be able to look at the work queue of each person and prepare their daily work. The computer would automatically retrieve the proper documents or files for a judge. If the judge prefers the information on paper, it could be sent to the laser printer during the night and be ready by morning. If the judge wants the information on the screen, it will be waiting there. Similarly, the clerk could be presented with a list of cases that require notices and other work.

Finally, I believe that the best case management systems present time information in a variety of ways. Of course, they must be able to produce the traditional court calendar with party and attorney information. But these systems should also be able to display the calendar in different graphical views. Several commercial case management packages summarize the number of actions occurring in a courtroom on an on-screen monthly calendar. This report looks like a page from a monthly calendar and shows the number of actions and the time allocated in the courtroom for each day. It is very easy to see where their might be an opening. Similarly, several years ago I saw a calendar-reporting system developed in the San Diego, California, Superior Court, which used bar charts to show each day of the week and the number of matters, by type, scheduled for the court. Both of these calendaring methods conveyed the information rapidly and concisely.

When I wrote the simple case management system for Arizona, half of the computer code was for the financial module. The remaining code covered the three modules discussed so far in this series--person, case history and calendar. This example illustrates the complexity of the financial portion of the case management system.

Once again I define a case management function in a very global manner. This is because courts accepts a variety of payments--not just in monetary terms. Courts accept payment in terms of days in jail, years in prison, work service hours, and compliance with probation terms. All of these payments are obligations which need to be accounted for by the court. In addition, the court holds money in the form of bonds and trusts. This requires establishing new accounts and different tracking procedures. Finally, the court also tracks and passes monies through for child support and victims restitution. I'm sure I haven't named all the financial tracking devices used by courts, but suffice to say, court accounting systems are unique.

Now that you see how complex the financial system is, and for the benefit of my hard working programming colleagues, I feel it is important that all judges and court administrators understand that developing these financial systems requires a significant amount of time.. However, the good news is that with modern programming techniques of building table driven systems, it takes less time than it used to.

Let's take a typical criminal sentence as an example. A person was sentenced to four weekends in jail (eight days total), a fine of $1,000, forty hours of workservice, and one year of probation. But as you know, this gets worse before it gets better. The $1,000 fine does not include the various state surcharges. In this example, the basic surcharge is 33% but, since the defendant was convicted of a particular offense, an additional $50 surcharge is levied. Now the total fine is $1,380. It gets even worse. For purposes of this example, let’s assume there is a state law that requires that from all monies collected the first payee is the state, followed by the city.

The defendant begins to serve the sentence and sets a time payment agreement with the court to pay the fine back in $100 increments over the next 14 months. This time payment agreement should be docketed in the case history. From the sentence four account records need to be created, all linked to the case number and more importantly, to the person ID number used in the court. By linking these records to the person number, all obligations can be consolidated for a global view by someone in the justice system. By keeping these obligations apart, each category can be consolidated for reporting in summary reports such as outstanding fines and persons on probation.

The financial system should record transactions as the sentence is served. Reports coming from the jail, probation, and work service as that portion of the sentence is being served. I realize that many courts are unable to track these reports because of the extra work involved. I suggest that small modules could be programmed to either accept electronic reports from these other parts of the system, or provide a simple interface for data entry into the court's system. Monetary payments are also recorded and distributed to the proper accounts. I believe that a summary note should be written to the case history for each of transactions.

Consolidations are a concern in the financial area. As defendants are convicted and required to pay fines and serve time for multiple cases, these obligations add up. If the financial system is based upon the person ID number, this is reasonably simple. The larger question is determining which accounts to pay first. I don't have a single answer to that question. It is up to the jurisdiction and laws of the state. In the example, the payments to the state are allocated--the first $380 to two different state accounts and the remainder to the city account. If there are no guiding laws then I suggest that cases be paid off in chronological order.

Security is another major factor in financial systems. Unfortunately, many courts have been victims of embezzlement. The reason? Because courts deal in cash. There are ways to combat this problem. For example, in many systems it is easy for court clerks and judges to "adjust" or "forgive" fines. Thus, if our defendant were illegally "forgiven"--it would be easy for a court employee to pocket the final $200 on the computer system since the defendant would continue to pay. I believe that all adjustments must be approved by at least two persons. Typically this is the chief judge and head clerk. However, I might suggest that this practice be changed to the chief judge and someone outside the court like the city manager or the head of finance. This would separate accounting controls to two different political entities. Please give this some thought. I'm sure your court can come up with a workable plan to safeguard this area.

I also believe that whether you buy or develop your own financial system, courts should require an independent audit and certification as soon as possible in it's implementation. It will be expensive and time consuming but in the long run certainly worth it.