Making Sure that History Repeats Itself


The state monitors want to see how you have handled changes in an applicant's eligibility and benefits as the applicant's situation has changed. What that means in a paper-based file is that you will write initial responses into a workbook, then make changes as notations in the margins or as pieces of paper in the record. An electronic workbook and application file has no margins and no scraps of paper. Therefore, the ONE/Case system has to have a way to record and store changes in an applicant/client situation electronically.

The most powerful tool for storing changes in situation is the Change History feature. Every time you press F13 or Enter to save the data on a screen, the system makes a fresh copy of the response and date-stamps them in its electronic files. Study the screens.  On line 4 of most screens is a 'Last Changed' field. That is the last day a worker saved that screen. If you press F13 to update, the date will change because "today" becomes the last date a worker changed the screen.

The system does not know whether you actually changed a value in one of the fields on that screen. It assumes that if you take the trouble to save the screen, it is likely that you did change a value.

If a worker saves a screen five times, there will be five separate records containing the values on the screen when it was saved. 

Currently, the only way to see all these changes is to print them out. Go to the section of this guide entitled. You will see the selection parameters shown below. 

Statement as of date........ _6/03/1997 (mm/dd/yyyy)

Print change history since.. __________ (mm/dd/yyyy)

By changing the 'Statement as of date' you can see the values on that date. By specifying a date in the 'Print change history since' field you can see all the changes to every question between the two dates.