 |
|
| Alextronic Discovery An Electronic Discovery Blog covering News, Articles and Thoughts for the Legal and Corporate Community Author: Alexander H. Lubarsky, LL.M., Esq. - alubarsky@enterusa.com - Tel. (415) 533-4166 OR 800-375-4222 THIS BLAWG IS NOT AFFILIATED WITH THE WEB SITES WWW.DISCOVERYRESOURCES.ORG OR WWW.DISCOVERYRESOURCES.COM |
|
|
Tuesday, January 06, 2004 Tips to Consider when Designing a Litigation Support Database Tips to Consider when Designing a Litigation Support Database When designing your litigation support database form, there are always a plethora of choices to consider: Do I create lookup tables? How many numbering schemes will I assign? Will I have certain relational fields or not? Do I create a big and busy form or a simple one? Will I need a feel to store OCR'd text? Can I incorporate fuzzy querying to accommodate such a field? To help in the decision making process, here are a few considerations that should be addressed: 1. What kind of data will I be "coding"? Databases keeping track of discovery responses may need multiple fields such as respondent's name, the question or interrogatory being addressed, the date of the response and a link field to any image or other file that corresponds with the response. Of course, if the data being tracked are standard corporate documents such as interoffice memos and e-mail, then standard fields should be employed (date, author, issue, Bates Number etc). If, of course, that data is electronic, then the database designer should insert an electronic data component into the database for storage of metadata with such files as metadata, cc, bcc, versions, sender's address, subject, number of revisions, printed and other such fields that typically correspond to metadata. 2. Is there an obvious distinction between importance of documents? In many matters, certain documents will be inherently more sensitive or private than others. Also, certain documents will clearly be undisputedly "hot." The database designer should create "switches" or buttons which can be easily triggered by the first level objective coder and/or the final subjective reviewer so that documents can be quickly labeled confidential or "hot" or "key". Further, the designer will usually want to set the system so that it sorts queries based on these critical documents first. 3. Issues... Issues.... Issues Perhaps the most critical field in a litigation support database remains the issues field. If you think about it, a litigator's job is either to prove or disprove that the prima facie elements in a certain cause of action exist (plaintiff) or do not exist (defendant). Of course, these elements are broken into basic issues. A slip and fall case database should contain a lookup table of issues: cause in fact, proximate cause, duty, breach of duty etc... which correspond with the elements of this cause of action. A wise litigation support manager once told me that the surefire way to cover the relevant issues is by going into an ALR (American Law Reports) and looking up the textbook definition of the cause of action at issue and then simply inserting the elements of that cause of action as your issues. 4. Unwrapping the Structure Today's discovery responses may spill out of crates, box cars banker's boxes, backup tapes, CD's etc... Make sure your litigation support database mimics the structure of the sources of your data. If you typically receive paper in banker's boxes from the opposing side or your client and you also receive the electronic data via backup tapes, make sure to have a field called "Box Number" and another titled "Tape ID" or something of the like. A failure to mimic the structure of the data you unwrap as it comes in can lead to huge problems later on when the physical source or that data is at issue or if the data simply needs to be retrieved for authentication and the like. 5. Dude, check out them waves! If you are involved in litigation that involves multiple "waves" of responses, be sure to have a field created such as "discovery production number" whereby you can indicate who produced the evidence and which "wave" or "production set number" can be associated with a particular document. Sounds simple but this is one of the fields most frequently ignored and one of the most difficult to populate after the fact. 6. Shortcuts Try to program shortcuts for recurring information. If many of the e-mail messages coming in are authored by Bill Garland you may want to program an expandable "BG" that can autoexpand to Bill Garland when the coder types those two letters. Better yet, you may want to put Bill's name on a short lookup list of the most commonly coded names in the litigation. 7. Don't forget Verification Fields If you have a field for social security numbers (SSN's) you should certainly put a verifier on it to make sure that the field accepts exactly nine digits in the following format ###-##-#### anything that doesn't fit this format will be rejected. This will insure that such data is entered in a standard format with no room for errors. You will want to repeat this for telephone numbers and dates as well. It would be more difficult to do for e-mail address or bank account numbers which can vary in length and contain both alphas and numerics. These are just a few things you may want to consider the next time you are applying your wizardry to the litigation support form. Happy coding! posted by Alexander | 4:47 PM |
|
|
|
|
|
|
 |
||||
|
|||||
