Testing Definitions

You test data entry screens by using them to enter test data into a special test database in Oracle Clinical. Oracle Clinical holds this test data in separate tables from production data, which lets you change test data in ways you cannot change production data.

The test data is created following a naming convention so that you can easily recognize it as test data. In some cases, Oracle Clinical automatically applies a naming convention (for example, in Responses and Discrepancies). Testers should follow a convention for all others so that they don't confuse hard copies of reports and SAS data sets with test data.

Oracle Clinical prevents using test data in Production mode and production data in Test mode. For example, when you navigate to Design, Test a Study Design, then Investigators, you can enter or select only dummy Investigators, sites, and patients; the system places any data you enter for the CRFs in tables designed to contain only test data. Conversely, if you choose Investigators and Sites from the Design menu, you can only enter or select non-test objects; the system places the data in production tables.

You can test Validation Procedures by running them against the test data. The system writes any resulting discrepancies to a special test discrepancy table. Each time you initiate a new test, the system erases the previous test discrepancy data.

For more information , see:

• Testing Validation Procedures
  
• Testing Derivation Procedures
  
• Batch Validating Test Data
  
• Testing Layouts in Oracle Clinical
  
• Testing Layouts in Remote Data Capture (RDC) OnSite
  
• Testing in Debug Mode
  
• Checking Validation Results
  
• Testing Mass Changes
  
• Testing Data Extract Views
  

Testing Validation Procedures

Testing Validation procedures consists of running each Validation procedure against your test data before making the procedure active. The system deletes any existing discrepancies each time you run a procedure.

From the Validation or Derivation procedures forms (from the Definition menu, select Validation Procs or Derivation Procs), you can review discrepancies without leaving the form. The menu options accessible through the Special menu inherit the security of the external menu items, so your access to objects is the same. The menu options are:

• Execute in Test

• Show Test Discrepancy

• Execute in Production

• Show Production Discrepancy

Testing Derivation Procedures

You test a Derivation Procedure by executing it for one or more test responses, executing the Procedure in Test mode. Oracle Clinical writes validation test results to the Test Discrepancy Database. Oracle Clinical writes test results of calculations to the Test Responses database. The system stores the test data and discrepancies separately from production data and discrepancies. You view results from the reports and Test mode data entry screens.

Note:

In V3.1-style Procedures, you must explicitly allow for the possibility of pointing to either test or production database tables. See V3.1-Style and Pre-V3.1-Style Procedures for information.

To run a Procedure in Test mode, you must first have entered or loaded data in Test mode. Follow these steps to run the procedure in Test mode:

1. Launch a single Procedure execution; from the Definition menu, select Test a Study, then Execute Single Procedure. The PSUB submission window appears. Other paths:

   From the Definition menu, select Derivation Procs, then Procedures, choose Special, and select Execute in Test.

   From the Definition menu, select Validation Procs, then Procedures, choose Special, and select Execute in Test.

2. Enter values for the Procedure Name and Version Number; both fields are list-enabled.
3. A Debug mode is available for testing and lets you view the individual values as the system derives or validates them. If you want to execute the Procedure in Debug mode, enter Y for the Execute Procedure in debug_ mode? parameter.

Batch Validating Test Data

Executing batch validation on test database tables tests multiple Procedures at one time and confirms both univariate settings and indicator Question specifications. The goal is to review the current state of all validation specifications as executed against all data defined in the test database tables for a study. You can document the results through the Test Discrepancy Database reports.

In Test mode, batch validation validates all existing data entered for all existing test patients, regardless of previous validation status of the data. All discrepancies are deleted at the beginning of processing and re-created by the validation session, where applicable. Similarly, all existing derived test responses are deleted and the highest compiled version of all non-retired Derivation and Validation Procedures is run on the test data. These actions derive the appropriate responses and re-create the necessary discrepancies, which you can view through the Test Discrepancy Database (from the Definition menu, select Test a Study, then Discrepancy Database).

Testing Layouts in Oracle Clinical

Initial Log-In is the first step in testing a DCM layout. From the Definition menu, select Test a Study, then Test Data Entry, and choose one of its forms.

In Test mode Oracle Clinical redefines synonyms that point to the test data tables, so you maintain all system functionality. (Additionally, you can revise First- Pass data, which you cannot access in production mode.) This is why you can use existing patient positions and CPEs without affecting the actual study database.

From the Special menu in the Initial Log-In and Entry form, you can select another study, enroll another patient, or change the date format. Most importantly, you can go directly to data entry by choosing Change Task and then selecting First-Pass Entry from the pop-up window. You can also reach the next form you need from the Test a Study menu item. Completing this form lets you begin Test Data Entry.

Each option in the Special menu also maps to a function key. Use the List function to determine the mappings.

Testing Layouts in Remote Data Capture (RDC) OnSite

Log in to RDC Onsite using the test-mode URL; see Launching Test Mode Sessions and enter test data for a patient to test graphic DCM layouts. In addition, generate and print a Patient Data Report and check that each page is complete.

Testing in Debug Mode

You can execute both Validation and Derivation Procedures in Debug mode, against either test or production data. In Debug mode the small-scale operations of a Procedure and the data it sees after it has run are determined. Such detail-oriented modes are often called "verbose." The only time you cannot run a Procedure in Debug mode is when it is run automatically as a part of batch validation.

Each Procedure execution results in an output file on the server. When you launch the job, a dialog box lists the name of this file. The file name format is usually rxc_log:oxxxx.out, where xxxx is a unique job number. To view a log file for a Procedure execution, you must log on to the server and then view the file.

In the example of a verbose Procedure execution file that follows, Procedure ZAK processes three patients, with patient numbers 101, 102, and 107. For each patient, the system retrieves the responses to the ZAK_ENROLLMENT Question for processing. Date format in this file is always YYYYMMDD format.

Connecting... Connected.
Single procedure execution for study PARIS, Procedure ZAK, Version 0
Execution Start: 12-JUL-1994 18:25:25
Procedure ZAK: Debug Mode Enabled.
Processing Patient: 101

Z.VISIT_NUMBER = 1
Z.DCM_DATE = 19930202
Z.REPEAT_SN = 1
Z.ZAK_ENROLLMENT = 19930101

Z.VISIT_NUMBER = 2
Z.DCM_DATE = 19930202
Z.REPEAT_SN = 1
Z.ZAK_ENROLLMENT = 19930102

Z.VISIT_NUMBER = 3
Z.DCM_DATE = 19930202
Z.REPEAT_SN = 1
Z.ZAK_ENROLLMENT = 19930103
Processing Patient: 102
Z.VISIT_NUMBER = 1
Z.DCM_DATE = 19930202
Z.REPEAT_SN = 1
Z.ZAK_ENROLLMENT = 19940104
Processing Patient: 107

Z.VISIT_NUMBER = 1
Z.DCM_DATE = 19930202
Z.REPEAT_SN = 1
Z.ZAK_ENROLLMENT = 19930123
Discrepancies: 0 new, 0 remain current, 0 became obsolete
Procedure execution completed at 12-JUL-1997 18:25:35.

Checking Validation Results

The last step in testing Validation Procedures is to refer to the Test Discrepancy Database, which is accessed from the Test a Study menu. The Maintain Discrepancy Database form opens with a query about the filter you want. You can list the available values for Status and Review Status. Most of the entries on this form are clearly defined by context or by previous entries. For obscure fields, invoke the List function.

Testing Mass Changes

Mass Changes, except you execute it through the Test Mode menu options. Oracle Clinical uses the same tables for creating the Mass Changes Criteria for Production and Test modes, but when you use the criteria to create a Candidate Data Set or operate on the Candidate Data Set in a Test mode session, Oracle Clinical operates against Test data.

Testing Data Extract Views

To create test data extract views in Test, follow these instructions:

1. Run PSUB to create the view: Navigate to Conduct, then Data Extract, and finally Data Extract Views.
2. Select TEST for account type and study_name$TEST for the account.
3. Click Submit.