How the System Stores the Audit Trail

Understanding the audit trail display requires understanding how Oracle Clinical handles changes made to RDCIs, RDCMs, and response data. For example:

Table 1-1 Audit Trail Example Beginning Data

Date	Activity
15-JAN-1996 10:00	A vital signs DCI for Patient 27, Visit 1 is logged in and First-Pass Entry is completed.
16-JAN-1996 10:00	The patient number is changed from 27 to 21.
16-JAN-1996 14:30	Second-Pass Entry is performed. During this pass, the patient's Systolic Blood Pressure is changed from 120 to 180.
19-JAN-1996 09:00	Following confirmation from the Investigator, the patient's Systolic Blood Pressure is changed back to 120.

Changes are handled by storing versions of the corresponding RDCI, RDCM, and patient response data records. The Entry and Update fields represent timestamps of when the versions were in effect. Records for the previous example would be:

Table 1-2 Example Received DCI and Received DCI Records

Entered	Updated	DCI Name	Patient Number	Clinical Planned Event
15-JAN-96 10:00	16-JAN-96 10:00	VITALS	27	VISIT 1
16-JAN-96 10:00	-	VITALS	21	VISIT 1

Table 1-3 Example Patient Response Data

Entry Time	Update Time	Question Name	Change From	Change To	Change Reason
15-JAN-96 10:00	16-JAN-96 14:30	SYSTOLIC BP	120	180	PASS 2
16-JAN-96 14:30	19-JAN-96 09:00	SYSTOLIC BP	180	120	INV CORR

The "current" record is always designated by an Update Time displayed as blank. Also, for RDCIs and RDCMs, the audit trail consists of a copy of the entire previous record, whereas for the patient response data, the audit trail is maintained individually for each data point; for example, no audit trail records will exist for diastolic blood pressure, since this was never changed.

Note:

When you save a CRF, the date/time that is recorded in the audit history (as observed in OC, RDC, and Patient Data Reports) is the database server date/time (SYSDATE) as retrieved at the time you opened the CRF (as opposed to at the time you clicked the save button) for the data entry.