Acknowledgements

A note of great appreciation goes to Ms. Anne S. Baines, Vice-President and Editor-in-Chief of LEXIS Online Publishing for her support and for sponsorship by LEXIS-NEXIS for this project. Also, thanks to Mr. Ron Staudt, formerly with LEXIS and now with Chicago-Kent School of Law for his support. Additional thanks to the Dixon Conference sponsored by the National Clearinghouse for Automated Information Research (NCAIR) for allowing us to air the original concept to the court and legal community. And finally, a very special thank you to my co-author, Stephanie Rondenell for her yeoman work on the court case management systems data dictionary compilation.

Most of you may not know about the Dixon Conference that was held in March, 1998. A distinguished group of judges, attorneys, academics, and administrators met in Washington, DC. After considering more than 100 ideas, endorsed the idea for creation of XML data exchange standards as one of the most important initiatives. For technicians, it is gratifying to note that highly experienced people representing many different areas of the legal system recognize the importance of electronically exchanging information in the future.

Purpose

The purpose of this report is to first, provide a compilation of data elements currently being used in court management database systems in the United States in 1999. This second purpose is to apply concepts used in database normalization and in Electronic Data Interchange standards definition such as ANSI X.12 and UNI-FACT. By applying these concepts we believe that it will be possible to define an initial eXtensible Markup Language (XML) namespace/data tag dictionary (DTD) for use by the courts. This proposed DTD is not intended to be a complete or comprehensive standard at this time. This is primarily because of our limited understanding of XML and all of it’s variants. However, it is hoped that by providing this starting point, a standard namespace for court data can be created in the near future.

Two additional caveats before we begin. First, this report also does not explore the tags necessary to format the style or document output format. Second, the report also does not try to identify tags necessary for marking knowledge concepts that are necessary to build indexing or decision support systems. This is work for a future time.

Organization (or lack of it) of this paper

This part of the report is intended to qualify the work that was done on the project. The most important sections of the report are the appendices. Those sections contain links to the posted Excel spreadsheet sources for the compiled case management data fields and the first draft of the initial proposed namespace DTD. We have also included my compiled series of articles from The Court Technology Bulletin on case management systems and links to appropriate Electronic Data Interchange internet resources. To understand the data table roll up and the namespace compilation one needs to recognize the underlying relationality of the data. Hopefully these resources will help in this understanding.

Methodology

When we started this project it was understood that are a lot of data fields and data types recorded in the courts. Case management systems have been in development for approximately thirty years. These systems reflect different operational needs and data reporting criteria. These systems also reflect the data structures upon which they were built. Hence, in the spreadsheets you will see many fields that are needed because of hierarchical or even flat file database systems. In modern relational databases it is possible to normalize data and using relational data tables there is no need for these separate data fields.

My colleague, Ms. Stephanie Rondenell collected more than a dozen court case management system data dictionaries. Some of these dictionaries were from older hierarchical types systems and some were from newer relational database systems. She then compiled these data dictionaries into three Microsoft Excel 97/2000 spreadsheets: Criminal, Civil, and Juvenile. In addition, during June, 1999 a Family court spreadsheet will be posted. These spreadsheets can be downloaded from the following FTP site:

http://ctl.ncsc.dni.us/bbsfiles/xml/crtdata.zip

All three (and eventually four) spreadsheets can be downloaded individually or, they have been zipped into one file: crtdata.zip

The criminal spreadsheet is the most detailed. In that spreadsheet the field name, required or optional, data description, and attributes were compiled. Due to time and budget limitations, the civil and juvenile spreadsheets contain field name and description of data.

The last column of the spreadsheet contains the roll-up field name. The premise behind this column relates to normalizing the data field. Name fields are a good example. An attorney could be the plaintiff’s attorney in one case; a defendant’s attorney in a second case; and even a defendant themselves in a third case. The person is the same, but their role in the case and thus their relationship changes. There is no need to create three separate fields to define this attorney’s relationship to the case. However, in the past the older database systems required this type of structure.

Electronic Data Interchange, Case Management and Normalization

Once the roll-up names were identified it became apparent that a reasonable number of consolidated data tags could be created if we were to apply Electronic Data Interchange (EDI) techniques. If these techniques are not used, then we believe that with more than 800 data fields (not counting duplicates) identified in the spreadsheets, that an XML dictionary of that size would be unwieldy and unusable. Therefore, both the ANSI X.12 and the UN-EDIFACT data dictionaries were examined to evaluate the field name but more importantly, how data fields were grouped to allow both specificity and flexibility.

EDI relies upon both name and qualifier or coded lists to reduce the number of defined fields. In XML, coded lists are referred to as attribute lists using the ATTLIST tag. When reading through the initial DTD in Appendix B, please note that ELEMENT tags that are defined as coded lists should be replaced with the ATTLIST tag with appropriate attribute code lists at a later date. Whether or not the ATTLIST tags can be a state or national standard or, as we believe, used as a starting point for group to group definition awaits further development.

The “Event” Concept

When reviewing the spreadsheets please note that we have assigned the roll-up name of “event” to many fields. Also, please note that we have defined the the Event tag in the DTD to allow ANY other tags to reside within that structure. Other than information related to persons, nearly all the rest of the data collected in a case management system relates to an event. The eventid tag provides identification information about the event, but an event must be allowed to contain data about persons, documents, identification numbers, and all other kinds of information. We believe that without this capability, the DTD will not be flexible enough to meet the data needs of the justice and legal community.

Namespace Name

You should note that we have proposed the namespace identifier of “ncsc1999a”. The moniker stands for National Center for State Courts, version 1999a. Yes, I (Jim McMillan) work for that organization. However, that is not why we have proposed this name. First, the NCSC is the national non-profit secretariat organization for the Conference of Chief Justices and the Conference of State Court Administrators. Second, the NCSC is a recognized leader in court technology through projects such as the Court Technology Conference, Court Technology Laboratory and Courtroom 21. Third, the NCSC Internet web site is recognized worldwide as the first source for court administration and court technology information. And finally, the NCSC exists to improve the courts and thus is not biased or favors any private corporation, organization, or governmental entity.

The NCSC proposes to work with all interested groups, particularly the Legal XML group sponsored by Georgia State University, and work being done by the US District Court in New Mexico, the State Courts of Utah, and other interested private vendors. We wish to assist in the development and promulgation of guidelines and standards that promote the open exchange of electronic information for the court system.

Therefore, we believe that it is likely that several namespace DTD’s will be required to service the needs of the judicial and legal environment. The attached DTD is only the first step. We further wish to offer the services of the NCSC to post and promulgate this information and, to promote endorsements from court organizations such as the Conference of Chief Justices, Conference of State Court Administrators and the National Association for Court Management.

Possible future directions

It is our hope that by getting this initial report “down on html” (to paraphrase an old adage) that work can begin on refining the proposed DTD and development of additional namespaces.

To facilitate discussion of this paper, all comments should be directed to either James E. McMillan ( jmcmillan@ncsc.dni.us ) at the National Center for State Courts or to the Legal XML listserve is posted at: http://www.legalxml.org/

Appendix A – Data table links

Adult Criminal Data Table: http://ctl.ncsc.dni.us/bbsfiles/xml/crim.xls

Civil Data Table: http://ctl.ncsc.dni.us/bbsfiles/xml/civil.xls

Juvenile Data Table: http://ctl.ncsc.dni.us/bbsfiles/xml/juvenile.xls

Zip file of all tables: http://ctl.ncsc.dni.us/bbsfiles/xml/crtdata.zip

Appendix B – Draft ncsc1999a Namespace / DTD definition

May, 1999

Proposed tag categories

DOCUMENT HEADER ELEMENT

<courtdocument>

DATA ELEMENT GROUP HEADERS

<account_id>

<address>

<amount>

<citation>

<datetime>

<document>

<email>

<eventid>

<event>

<frequency>

<group>

<id_number>

<legal_charge>

<length_of_time>

<location>

<name>

<number>

<occupation>

<payment_detail>

<physical_description>

<status>

<telephone>

<type>

POSSIBLE ELEMENTS

<question>

<response>

POSSIBLE OTHER ELEMENTS NOT DEFINED AT THIS TIME

<language>

<risk>

Draft DTD – May, 1999

Namespace Identifier: ncsc1999a

HEADER RECORD

Possibly The Rich Himes / New Mexico XCI Specification for a Data Envelope?

<! ----- document toplevel ------------- >

<!ELEMENT courtdocument (account_id , address , amount , datetime , document , email , eventid , event , frequency , group , id_number , legal_charge , length_of_time , location , name , number , occupation , payment_detail , physical_description , status , telephone , type ) * >

<! ----- header record ??? ------------->

underfined at this time

<!------ account identification record ---------- >

<! ELEMENT account_id (account_id_num , code_list_qualifier , code_list_qualifier , responsible_agency , account_number , account name ) * >

<!ELEMENT account_id_num (#PCDATA)> agreed upon account identification attribute list

<!ELEMENT code_list_qualifier (#PCDATA)> account attribute list qualifier such as series or start date

<!ELEMENT responsible_agency (#PCDATA)> agency responsible for maintaining / updating code list

<!ELEMENT account_number (#PCDATA)> alpha numeric account code number

<!ELEMENT account_name (#PCDATA)> text

<!------- address record --------- >

<!ELEMENT address ( address_purpose , address_type , address_status , address_status_date , address_line1 , address_line 2 , address_line3 , address_line4 , address_line5 , address_city , address_state , address_postcode , address_country , address_description ) * >

<!------- address sub-records --------- >

<!ELEMENT address_purpose (#PCDATA)> coded field agreed to by the parties

<!ELEMENT address_type (#PCDATA)> type of address – home, business, school etc.

<!ELEMENT address_status (#PCDATA)> coded field to reflect active or inactive or other status

<!ELEMENT address_status_date (#PCDATA)> effective date of address_status

<!ELEMENT address_line1 (#PCDATA)> text address lines

<!ELEMENT address_line2 (#PCDATA)> text address lines

<!ELEMENT address_line3 (#PCDATA)> text address lines

<!ELEMENT address_line4 (#PCDATA)> text address lines

<!ELEMENT address_line5 (#PCDATA)> text address lines

<!ELEMENT address_city (#PCDATA)> the city

<!ELEMENT address_state (#PCDATA)> the state, province or postal entity

<!ELEMENT address_postcode (#PCDATA)> the zip or postal code

<!ELEMENT address_country (#PCDATA)> the name or postal country code

<!ELEMENT address_description (#PCDATA)> text for locations that don’t have an address system

<!------- amount record --------- >

<!ELEMENT amount ( amount_qualifier , amount_type , amount_value , alpha_num_value , currentcy_qualifier ) * >

<!------- amount sub-records --------- >

<!ELEMENT amount_qualifier (#PCDATA)> agreed upon table of amount

<!ELEMENT amount_type (#PCDATA)> code that defines amount type

<!ELEMENT amount_value (#PCDATA)> numeric value of the amount

<!ELEMENT alpha_num_value (#PCDATA)> alpha numeric value of the amount

<!ELEMENT currency_qualifier (#PCDATA)> defines currency type

<!------- citation record --------- >

<!ELEMENT citation ( cite_qualifier , cite ) * >

<!------- citation sub-records --------- >

<!ELEMENT cite_qualifier ( #PCDATA) > the source of the case citation

<!ELEMENT cite (#PCDATA)> citation text

<!------- date and time record --------- >

<!ELEMENT datetime ( datetime_qualifier , datetime_period , datetime_format ) * >

<!------- date and time sub-records --------- >

<!ELEMENT datetime_qualifier (#PCDATA)> coded field to identify the type of event the date refers to

<!ELEMENT datetime_period (#PCDATA)> this is the actual date and time data

<!ELEMENT datetime_format (#PCDATA)> coded field that identifies the format of the date or time

<!------- document record --------- >

<!ELEMENT document (document_qualifier , document_date , document_version , document_code , document_text , document_name , document_format , document_link ) * >

<!ELEMENT document_qualifier (#PCDATA)> agreed upon table of document code qualifier

<!ELEMENT document_date (#PCDATA)> version date of document

<!ELEMENT document_version (#PCDATA)> version number of document

<!ELEMENT document_code (#PCDATA)> document identifier

<!ELEMENT document_text (#PCDATA)> document text

<!ELEMENT document_name (#PCDATA)> document name/id

<!ELEMENT document_format (#PCDATA)> text format of document

<!ELEMENT document_link (#PCDATA)> electronic location (XLL compatible?)

<!------- electronic mail record --------- >

<!ELEMENT email (#PCDATA ) * > electronic mail address

<!------- event identification record --------- >

<!ELEMENT eventid ( event_sequence_number , event_type , event_code , event_code_qualifier , event_code_reference , event_responsible , event_action , event_process , event_instruction , event_text ) * >

<!------- event identification sub-records --------- >

<!ELEMENT event_sequence_number (#PCDATA)> defined or next event number

<!ELEMENT event_type (#PCDATA)> agreed upon table

<!ELEMENT event_code (#PCDATA)> agreed upon table

<!ELEMENT event_code_qualifier (#PCDATA)> **qualifier from table that assures proper use of code [i.e., description of event]

<!ELEMENT event_code_reference (#PCDATA)> location of tables for all event tag codes

<!ELEMENT event_responsible (#PCDATA)> group, agency, individual responsible for the code table

<!ELEMENT event_action (#PCDATA)> agreed upon table

<!ELEMENT event_process (#PCDATA)> next event or workflow called

<!ELEMENT event_instruction (#PCDATA)> qualifies event_action and event_process

<!ELEMENT event_text (#PCDATA)> text associated with the event

<!------- event record --------- >

<!ELEMENT event ANY> any tags can be included within this structure

<!------- frequency record --------- >

<!ELEMENT frequency ( frequency_qualifier , frequency_value , frequency_unit , range_qualifier , range_minimum ,

range_maximum ) * >

<!------- frequency sub-records --------- >

<!ELEMENT frequency_qualifier (#PCDATA)> agreed upon code for frequencies of event, weights, or time requirements

<!ELEMENT frequency_value (#PCDATA)> frequency amounts

<!ELEMENT frequency_unit (#PCDATA)> agreed upon tables – daily, weekly, monthly

<!ELEMENT range_qualifier (#PCDATA)> agreed upon table defining the range value

<!ELEMENT range_minimum (#PCDATA)> agreed upon minimum value

<!ELEMENT range_maximum (#PCDATA)> agreed upon maximum value

<!------- group record --------- >

<!ELEMENT group ( group_id , group_type , group_qualifier , group_relationship , group_location , group_status , group_status_date , group_status_date_qualifier ) * >

<!------- group sub-records --------- >

<!ELEMENT group_id (#PCDATA)> group identification number

<!ELEMENT group_type (#PCDATA)> agreed upon description of groups or relationships

<!ELEMENT group_qualifer (#PCDATA)> coded field that further defines group_type

<!ELEMENT group_relationship (#PCDATA)> relationship between group and other groups

<!ELEMENT group_location (#PCDATA)> group location

<!ELEMENT group_status (#PCDATA)> status of association with group

<!ELEMENT group_status_date (#PCDATA)> date of status

<!ELEMENT group_status_date_qualifier (#PCDATA)> agreed upon code for status date

<!------- identification number record --------- >

<!ELEMENT id_number ( id_qualifier , id_number , id_status , id_status_date ) * >

<!------- identification number sub-records --------- >

<!ELEMENT id_qualifier (#PCDATA)> agreed upon code that defines id number (associated location / facility)

<!ELEMENT id_number (#PCDATA)> code number value

<!ELEMENT id_status (#PCDATA)> code associated with identification number

<!ELEMENT id_status_date (#PCDATA)> effective date of identification number

<!------- legal charge record --------- >

<!ELEMENT legal_charge ( legal_charge_type , legal_charge_code , legal_charge_desc , legal_charge_ref1 , legal_charge_cross ) * >

<!------- legal charge sub-records --------- >

<!ELEMENT legal_charge_type (#PCDATA)> legal charge type code (example criminal or misdemeanor and class)

<!ELEMENT legal_charge_code (#PCDATA)> legal charge code number (statutory reference number)

<!ELEMENT legal_charge_desc (#PCDATA)> legal charge description (text description of charge)

<!ELEMENT legal_charge_ref1 (#PCDATA)> legal charge reference number (example NCIC code number)

<!ELEMENT legal_charge_cross (#PCDATA)> legal charge cross reference code source (example NCIC)

<!------- length of time record --------- >

<!ELEMENT length_of_time ( unit_of_time , time_value , amount_of_time ) * >

<!------- length of time sub-records --------- >

<!ELEMENT unit_of_time (#PCDATA)> agreed upon format (daily, weekly, bi-weekly, monthly, etc.)

<!ELEMENT time_value (#PCDATA)> time value

<!ELEMENT amount_of_time (#PCDATA)> calculated total of time charged, spent, or credited

<!------- location record --------- >

<!ELEMENT location ( location_id , location_qualifier , location_text , related_location , location_function ) * >

<!------- location sub-records --------- >

<!ELEMENT location_id (#PCDATA)> agreed upon table of location /facilities

<!ELEMENT location_qualifier (#PCDATA)> coded field that further defines location/facilities

<!ELEMENT location_text (#PCDATA)> text associated with location

<!ELEMENT related_location (#PCDATA)> agreed upon table of related locations/facilities

<!ELEMENT location_function (#PCDATA)> agreed upon table of location function/description

<!------- name record --------- >

<!ELEMENT name ( name_type , prefix , firstname , middlename , lastname , suffix , generation , composite_name , composite_name_type , name_alias , name_format ) * >

<!------- name sub-records --------- >

<!ELEMENT name_type (#PCDATA)> coded field agreed upon by the parties

<!ELEMENT prefix (#PCDATA)> formal name prefix such as Mr. or Ms.

<!ELEMENT firstname (#PCDATA)> first name of the person

<!ELEMENT middlename (#PCDATA)> middle name, initials or multiple initials

<!ELEMENT lastname (#PCDATA)> last name of the person

<!ELEMENT suffix (#PCDATA)> trailing suffix name such as Jr or III

<!ELEMENT generation (#PCDATA)> numeric field that identifies persons of same names in different generations

<!ELEMENT composite_name (#PCDATA)> combined name if name cannot be broken into parts – can be used for business

<!ELEMENT composite_name_type (#PCDATA)> identifies the type of composite name whether it is a person or business

<!ELEMENT name_alias (#PCDATA)> maiden or AKA name

<!ELEMENT name_format (#PCDATA)> coded field agreed upon by parties

<!------- number record --------- >

<!ELEMENT number (number_qualifier , number_format , value , alphanum_value ) * >

<!------- number sub-records --------- >

<!ELEMENT number_qualifier (#PCDATA)> code defining type of number

<!ELEMENT number_format (#PCDATA)> coded field agreed upon by parties

<!ELEMENT value (#PCDATA)> actual number value

<!ELEMENT alphanum_value (#PCDATA)> character or alphanumeric value

<!------- occupation record --------- >

<!ELEMENT occupation (employee_id_code , employee_id_number , occupation ) * >

<!------- occupation sub-records --------- >

<!ELEMENT employee_id_code (#PCDATA)> agreed upon occupation codes

<!ELEMENT employee_id_number (#PCDATA)> associated id number

<!ELEMENT occupation_desc (#PCDATA)> occuption title or description

<!------- payment detail record --------- >

<!ELEMENT payment_detail (payment_conditions , payment_guarantee , payment_list_qualifier , payment_list_responsible , payment_method ) * >

<!------- payment sub-records --------- >

<!ELEMENT payment_conditions (#PCDATA)> agreed upon tables of payment conditions (i.e. installment)

<!ELEMENT payment_guarantee (#PCDATA)> agreed upon tables of payment guarantees

<!ELEMENT payment_list_qualifier (#PCDATA)> Determine whether responses are valid – table verification

<!ELEMENT payment_list_responsible (#PCDATA)> Agency responsible for maintaining / updating code list

<!ELEMENT payment_method (#PCDATA)> agreed upon table for methods of payment (i.e. cc, cash, check)

<!------- physical description record --------- >

<!ELEMENT physical_description ( gender , height , weight , eye_color , hair , scars_marks_tatoos , scars_marks_tatoos_text , date_of_birth , place_of_birth , ethnicity , citizenship , marital_status , religion ) * >

<!------- physical description sub-records --------- >

<!ELEMENT gender (#PCDATA)> agreed upon table of codes for gender

<!ELEMENT height (#PCDATA)> agreed upon table for feet / inches

<!ELEMENT weight (#PCDATA)> agreed upon table for weight

<!ELEMENT eye_color (#PCDATA)> agreed upon table of codes for eye color

<!ELEMENT hair (#PCDATA)> agreed upon table of codes for hair color

<!ELEMENT scars_marks_tattoos (#PCDATA)> agreed upon table of scar_marks_tattoos - location, type

<!ELEMENT scars_marks_tattoos_text (#PCDATA)> text associated with scars_marks_tattoos

<!ELEMENT date_of_birth (#PCDATA)> date field

<!ELEMENT place_of_birth (#PCDATA)> location

<!ELEMENT ethnicity (#PCDATA)> agreed upon table of codes for ethnicity

<!ELEMENT citizenship (#PCDATA)> codes that define citizenship status

<!ELEMENT marital_status (#PCDATA)> agreed upon table of marital status

<!ELEMENT religion (#PCDATA)> agreed upon table of religious preference

<!------- status record --------- >

<!ELEMENT status ( status_qualifier , status_code , status_date , status_reason , status_reason_qualifier ) * >

<!------- status sub-records --------- >

<!ELEMENT status_qualifier (#PCDATA)> agreed upon status qualifier

<!ELEMENT status_code (#PCDATA)> agreed upon table of status codes

<!ELEMENT status_date (#PCDATA)> effective date of status

<!ELEMENT status_reason (#PCDATA)> agreed upon table of status reasons

<!ELEMENT status_reason_qualifier (#PCDATA)> agreed upon table of status reason qualifier codes

<!------- telephone record --------- >

<!ELEMENT telephone ( phone_type , phone_status , phone_status_date , phone_number ) * >

<!ELEMENT phone_type (#PCDATA)> type of telephone number – home, business, fax. pager, alternate, relative

<!ELEMENT phone_status (#PCDATA)> status of the telephone number – active or inactive

<!ELEMENT phone_status_date (#PCDATA)> date that the status was assigned

<!ELEMENT phone_number (#PCDATA)> telephone number and extension

<!------- type record --------- >

<!ELEMENT type (#PCDATA) > agreed upon code

<! ------POSSIBLE CODE ORIENTED TAGS ------>

<!------- question record --------- >

<!ELEMENT question (question_text , question_code , question_qualifier ) * >

<!------- question sub-records --------- >

<!ELEMENT question_text (#PCDATA)> Example: US Citizen?

<!ELEMENT question_code (#PCDATA)> Code list associated with question

<!ELEMENT question_qualifier (#PCDATA)> Determine whether the response is valid by verifying if response is in the list

<!ELEMENT question_responsible (#PCDATA)> Agency or person responsible for maintaining / updating code list

<!------- question response record --------- >

<!ELEMENT response ( response_text , response_code , response_qualifier ) * >

<!------- question response sub-records --------- >

<!ELEMENT response_text (#PCDATA)> text associated with the response to a question

<!ELEMENT response_code (#PCDATA)> Simple data element tag – example ‘Ethnicity’

<!ELEMENT response_qualifier (#PCDATA)> Determine whether the response is valid by verifying if response is in the list

<!ELEMENT response_responsible (#PCDATA)> Agency responsible for maintaining /updating list

Appendix C – Case Management Systems – by Jim McMillan (1995)

Case Management Systems

National Center for State Courts

James E. McMillan, Director, Court Technology Laboratory

Preface

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-259-1544, fax at 757-259-1840, 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.

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

II. The Person

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.

III. The Case

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.

IV. Time

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.

V. Financial

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.