Legal Services Corporation
America's Partner For Equal Justice

 

Program Letter 02-6
 

President
John N. Erlenborn

Board of Directors
Douglas S. Eakeley
Roseland, NJ
Chairman

LaVeeda M. Battle
Birmingham, AL
Vice Chair

Hulett H. Askew
Atlanta, GA

John T. Broderick, Jr.
Manchester, NH

John N. Erlenborn
Issue, MD

Edna Fairbanks-Williams
Fairhaven, VT

F. Wm. McCalpin
St. Louis, MO

Maria Luisa Mercado
Galveston, TX

Nancy H. Rogers
Columbus, OH

Thomas F. Smegal, Jr.
San Francisco, CA

Ernestine P. Watlington
Harrisburg, PA

TO: All LSC Program Directors

FROM: Randi Youells, Vice President for Programs

DATE: June 6, 2002

RE:

Limitation of Defaults in Case Management Software

As you know, the Legal Services Corporation and its grantees were severely criticized several years ago for inaccuracies in the Case Service Report (CSR) data.  Through your hard work, this problem has been effectively addressed.  Error rates, as reported through the self inspection process, have dropped from 11% in 1999 to 5% in 2001.  

This program letter addresses a small additional step that you can take, if you haven't already done so, to eliminate a significant source of remaining problems in CSR counting.  Defaults are insertions of a particular value that are automatically made in a data base.  Because it is possible for someone entering data to skip over a field that already contains data rather than correcting the default when it is not accurate, defaults can be a source of errors in the record.  In this letter, we require grantees to remove defaults where they present the danger of presenting false information about crucial eligibility information, and make other suggestions about defaults.

Why have any defaults?

It is very common for different fields in a case management software (CMS) program to default to a predetermined value. There can be good reasons for this. For example, your office is located in Big City, and most of your clients are from Big City. It makes sense for the software to default to “Big City” in the city field so that staff do not have to type “Big City” over and over.

With CMS, many fields are required fields. This means the record cannot be saved unless there is an entry in that field. Often there is a default value programmed into the CMS so that there is something in every required field. 

While this may be a handy device for being sure a record can be saved, it is not the best way to ensure the accuracy of the data. When you come back to the record, you do not know if staff entered the data, or it was simply left there from the default.

What needs to be done is to strike a balance that makes the software easier to use but does not sacrifice accuracy. We have prepared this Program Letter to give you guidance in this process. 

Fields where defaults are not permitted

The first thing we will do is to advise you which fields should never have a default value. Deciding which fields these are is very simple. If client eligibility depends upon the data in the field, it should never have a default. These fields are income, number in household, assets, and citizenship.

Why shouldn’t you have a default for these? It is tempting to default citizenship to Yes since most persons applying for service are citizens. This will save typing. The problem is that if the software defaults to Yes then when the records are checked for accuracy there is no way to know if the applicant was asked if he/she was a citizen or the question was skipped. In either of the cases, if there is a default, the answer is Yes. So the answer tells you nothing.

However, if the default is removed so that the field is blank, when it is checked and found to contain “Yes”, it verifies that the question was asked and the answer recorded. If it had not been, the field would still be blank. This is just as critical for income, assets and number in household. These fields should be blank when you start an intake.

Fields where defaults are not recommended

But CMS has many more fields than these three. What about them? As a rule, removing defaults will increase the accuracy of the information. We strongly suggest you remove defaults for the following common fields: age, race, sex, LSC problem code, and funding source. Defaults for age and LSC problem code save little time because there is no usual answer. It can be argued that having a default for race, sex and funding source helps intake staff. We understand this but do not recommend having defaults for these fields. That said, if you continue to have defaults, be sure you have procedures to check the data for errors.

Fields where defaults are optional, even useful

For other fields, such as city, county, and state, defaults are valuable and can save time. We suggest that you look at these other fields and decide when defaults will be useful and appropriate.

How to remove defaults

Defaults are functions of the structure of the database software used to build your CMS. As well as sending this Program Letter to you, LSC is distributing it to major vendors of CMS. These include Legal Files, Practice Manager, Pika, Kemp’s Case Works, Telelawyer, and Time. If your vendor is not listed, please contact Glenn Rawdon, grawdon@lsc.gov, and he will be sure to get them this information.

If you have a proprietary CMS, or if your commercial CMS program allows the end user to make modifications to the software, here are some things you can do to make these modifications. First, be sure to back up all files associated with the database, both data and program files. This way you can always get back to where you were if something doesn’t go right with the changes.

Next, you need to identify which fields have defaults. To do this, open a new case record and see which fields already contain data. The ones that do are the ones that have defaults. Now see which of the fields that have data are the ones covered by this letter. Once you do that, you will know which field defaults need to be removed.

Data for the CMS is stored in a database table. Each field in the table has definitions, such as whether it is an alphanumeric, a date, or a number field. Typically, one of these field definitions is for a default. When the field for a new record is created, this default is displayed. To remove the defaults as outlined in this letter, you should start by looking at field definitions for the fields covered by this letter. Most software has a design view that allows you to look at these and change them. Start by removing any field definition defaults for these fields.

If the field has a default, but you find nothing in the default value in the field definition, the default may be contained in the form that is displayed when you enter the data. (Database files may contain many objects, such as tables, forms, queries, reports, and macros.) In the database, find the form that is displayed when you enter client data and look at it in the design or programming mode. Go to the field that has the default you need to remove and look at the properties for that field. One of these may be for a default. If so, you should remove it here. Also, you need to be aware that, with many CMS programs, the forms reside on the workstation while the data tables reside on a central server. If this is how your CMS works, removing defaults for the form on one computer will not remove them on other computers. To do this, the client file on each workstation must either be changed or replaced with one that has been changed.

If a field has a default and you did not find it in the table or in the form, it may be coming from another table. Some programs store default values this way. This is a good design method because it makes it easy for the user to change the defaults. If your CMS does this, it is likely you have a menu for Setup, User Settings, or something similar. If so, go to this function of your CMS and see if the default you need to remove is here. If so, delete the entry for that field.

Not everyone can change a CMS. This is not a job for the normal computer user. Hopefully you have someone on staff familiar with the database your program uses or can hire a consultant who is. If you know another legal services program that uses the same program you do, you might contact them and pool your efforts. The changes you need to make are not extensive and should not take that long. The most time consuming part will be updating each workstation with the new program file if that is required by your CMS. 

While we at LSC cannot make the changes for you, we will try to assist you by answering questions from you or your CMS vendor. For this technical assistance, please contact Glenn Rawdon, grawdon@lsc.gov or 202.336.8868.         

    

 

750 First Street, NE 11th Floor
Washington, DC 20002-4250
Phone 202.336.8800 
Fax 202.336.8959
www.lsc.gov

 

Return to the Index