Second Opinions

A College Grapples with 'Judicial' Records

By Neil Aresty

THE OFFICE of Student Life at a private university has among other things, the responsibility of administering the university judicial system. Over the years it has handled hundreds, perhaps thousands of matters. Of course, part of the problem this office has is that there is, at present, no easy way to ascertain correct figures on its matters.

In an effort to enhance the delivery of this judicial process (also known as the swift administration of justice) the staff has come to the conclusion that the quality of service would be greatly enhanced through the application of technology to the judicial workflow process and the office record keeping.

Towards that end they have decided to put together a request for proposal seeking an electronic document and case management system. They want to incorporate all the bells and whistles, including a system that can handle scanned document images, OCR (optical character recognition) text, Boolean full text retrieval, a searchable database and some sort of workflow management capability. Ideally the investment in this system will last as it will evolve into a future system that they imagine will meet the longer-term goal of being an all electronic document and case management system...(a paperless office?).

There is one other important requirement. The school would like a system that is upgradeable and "turnkey" so that it will need as little support from the University's computer information services department as possible. The University has informed them that as far as a computer system goes, they are on their own and whatever solution they implement, it had best be able to integrate with the University's mainframe (ostensibly to share data on those students)!

Oh well. Just another set of impossible computer requirements that need to be implemented A.S.A.P. and with the least amount of money possible. The knee jerk reaction would be to try to find an off the shelf package that will meet those requirements. In my opinion, there is no such thing. No matter what they look at they will struggle to make it fit the way they work. There will be constant groaning as staff tries to make someone else's database capture their workflow.

The best way to approach solving this problem will be to build it on their own (possibly with the use of a competent consultant -- one that might even come from their own University community. In order to preserve the investment in this system they should build it using software based on PC "open standards," i.e. software that meets certain open standard requirements, such as the ability to import and export all its data in an ASCII text delimited format.

There is no guarantee that the software they model or build the system on will be sufficient to meet their growing needs. And with a view towards the future they should be thinking about enabling the system with internet technologies so that it will be capable of running under a Web browser in either an Intranet or Extranet fashion.

Two basic tools required to "evolve" (rather than "build") this application will be a database manager and a Boolean full text indexer/search engine. But before they set out to build the next great case management tool with all the necessary bells and whistles for dispensing justic, they are going to have to go through a self-evaluation phase, commonly known as a systems analysis, of the Office of Student Affairs.

Process Analysis Phase

The first step towards building a new case management system will require a type of "life cycle" analysis. In order to find out how the office processes cases we would want to ask each employee to describe what he or she does in terms of handling a matter through its life cycle. Each employee should be asked to describe his or her perception of where matters come from, what they look like in a "gestation period," exactly when and where is a matter "born" (when are they recognized and docketed as a new matter in the office), who handles the matter during its life, how are the matters handled, what happens when the matter dies and does it ever come back to life? During this interview phase it will also be important to have "sticky fingers;" make sure you ask for and take copies of any and all intake forms, routing slips, practice based checklists and even some sample documents.

By asking employees to describe their work in terms of the same metaphor, we should be able to adduce the actual workflow as well as the intended process (work flow) of the life of a matter in this office. The goal should be to develop a consensus as to the definition of what constitutes the basic work unit (a matter) within the context of this office. You might be surprised at how difficult, yet important it is to get a consensus on the definition of "a matter." This will be a key component to the building of the business logic behind the case management system.

The systems analysis phase is going to be as important, if not more so, than any other aspect of the implementation. Too often, staff inherits a system that has never been examined. Matters may tend to be handled in an individual and often, ad hoc fashion. In an office that is in the business of the administration of "justice" services, the operational goal should be to promote, among other things, the ability to access prior cases (precedents) in order to provide decision makers with the knowledge to treat similar matters, similarly. You know, like in the real world.

Hardware

The office will be running its own local area network and should be on a high-speed network connection hub (100 MB Ethernet). The 100 MB Ethernet will be necessary to preserve their investment and to handle the bandwidth necessary for handling the image and audiovisual files that will increasingly populate their network traffic. Access to the Internet will be through the University backbone (i.e. the University's high speed, fiber optic network cable that connects all buildings on campus).

Either the Internet Information Server (IIS) that ships with Windows 2000 server or a Linux based Apache Web server. With respect to Apache, my assumption is that there will always be some local talent available to set up and administer this freeware based web server. After all it is driving better than 50 percent of all Web servers on the Internet. The internal Web server will enable the office to have an Intranet which will be increasingly important to the success of the customized case management and records keeping system.

In addition to a file/application server based on Windows 2000, the office should run a Web server. I am going to assume that the University will help spec out or acquire the server machines. Suffice it to say that they should have redundant storage and tape back up devices, plenty of disk space (50 or more GB) and room to grow.

Each desktop should be a recent vintage Pentium class PC running at a minimum of 350 MHz. If buying new equipment the rule of thumb is to buy the most that money can buy at that time. Quite frankly, by the time you are reading this any new PC purchased for the department would likely be 700 MHz or higher. The desktop PCs should have at a minimum, 64 MB of RAM, although 128 MB would be preferable.

The office will also need a high-speed printer in order to "blow back" those entire documents they intend on imaging. One of the top of the line HP 5000 laser jets should fit the bill. Finally, they will need a cost effective, medium to high speed, duplex, sheet fed scanner. Companies such as RICOH, Fujitsu, Kodak and others make these. For examples of this hardware and current pricing take a look at the following websites; www.pcconnection.com or www.imagemagazine.com.

Software

The great thing about building your own case management system in the year 2000 is that there has never been a better assortment of standard, off the shelf tools that you can use to build the model on the cheap and then scale up as necessary. Based on the interviews of the staff, an analysis of the checklists, intake forms, sample documents, etc., there should be a brainstorming session with the objective to list what I like to call the 20 questions one needs to ask about every matter. (O.K., it might be 50 questions, but we are going to recommend that it get reduced). Before the process is finished we will probably have several linked (relational) databases; a common basic info database containing bibliographic and other high level information regarding the matter; a people database, along the lines of Rolodex™ type information; a document database that tracks basic information about the document and links or points to the file location of the document image; and finally a more substantive matter type database that may vary given the types of mattes involved.

In order to capture the information that moves a matter along in its life cycle we will sketch out a databases on paper, discuss them and then build the prototypes in an application such as Access or File Maker Pro. Both of these database programs are quite popular and there should be plenty of people around (increasingly so) who feel comfortable building database applications using either of those products. As either database is populated we will get feedback on what works and what does not. It will be important to stress that this application is going to evolve and require some patience and teamwork. In order to structure the "build" there should be some projected dates for the second round of enhancements (bug fixes go on all the time).

Both Access and File Maker Pro can be run in either a client or server mode. Both have Web technologies built into their latest version, so they will recognize hyperlinks as a unique data type and both can fairly easily publish to a Web page. Ultimately, either program can be migrated to a SQL compliant database server, which is where this program will end up when it gets big enough.

In addition to the database program we will need a Boolean full text-indexing engine that is similarly network able and ultimately Web server based. In order to enhance the structured search capability of the case management system we will want to be able to perform a Lexis or Westlaw like search across all the work product and some of the database fields. That way if one can not remember whether a person was a defendant, complainant or witness, but they do know that they have dealt with that name in the office, they can just drop the name into the full text search engine and see what files show up with his/her name. The full text search engine is there to complement the structured analysis and retrieval that the case management application will give.

Perhaps all of this sounds too complex. There is no doubt that it will take time and there will be frustrations along the way. In my opinion the building of this system is something that is doable, especially in the context of a university setting where the department can get access to some talented students. Sure computers, networks, databases and Web servers are a complete mystery to many. However they are here to stay and increasingly law offices will have to obtain some minimal competency in the management of these capabilities or outsource them altogether.

Neil Aresty is a member of the LTN Editorial Advisory Board. He combines a Boston-based law practice with a computer consultancy, Legal Computer Solutions, Inc, and runs LextraNet, a Web-hosted litigation support and case management system.