| Oracle® Clinical Creating a Study Release 4.6.2 E18820-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Clinical Creating a Study Release 4.6.2 E18820-01 |
|
|
PDF · Mobi · ePub |
This chapter describes Oracle Clinical's Test mode, which is a reduced set of features for testing a study's design and some data definitions. It is a scaled-down version of some Production mode functionality. Test mode is separate from production mode, so it is unsuitable for validating an installation or system functions. This chapter includes the following topics:
Note:
For a new database installation, implementing Test mode requires these preliminary tasks:The Global Librarian should create the domain INSTALL_TEST to hold objects for testing purposes. (See "Using Domains within the Global Library" for more information.)
Manually enforce the constraint that two domains cannot reference each other, and that only STANDARD objects can be available for production work.
Test mode is a tool for testing your procedures and your data entry layouts before you go into production.
You can test the usability of data entry screens, that the Validation Procedures identify possible discrepancies, and that the Derivation Procedures correctly calculate the responses you want. Here are some ways you can use Test mode in the Definition subsystem:
You can test the appearance of data entry form layouts in Oracle Clinical, RDC Classic, and RDC Onsite.
You can test the algorithms in validation and derivation procedures.
You can use Test mode to train new data entry operators on a particular study's data entry screens.
You can test data extract views before entering production data.
You can test Mass Changes before applying them to production data.
See "Testing Definitions" for more information.
This is a typical testing sequence:
Test a live study's design. See "Setting Up Test Study Design".
Add some definitions to the study from Production mode. These are some production definitions you can test in Test mode:
DCMs
DCM Layouts
DCIs
Patient Positions assigned to sites and Investigators
Clinical Planned Events
Validation and derivation Procedures
Mass Changes
Start a Test mode session and refine patient, Investigator, and site definitions. Oracle Clinical generates some dummy definitions for you, but you can add to them.
Create test data. See "Creating Test Data".
Batch load your test data. If you have a lot of test data, you can batch load it. See "Creating and Loading Test Data".
Batch validate your data. See "Testing Validation Procedures".
Review the results of the batch validation. See "Checking Validation Results".
Test Mass Change functions.
Test your Data Extract Views; see "Testing Data Extract Views".
If you are using Remote Data Capture (RDC), test data entry layouts; see "Testing Layouts in Remote Data Capture (RDC) OnSite" or "Testing Layouts in Remote Data Capture (RDC) Classic".
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, and 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 navigate to Design, then Investigators and Sites, you can only enter or select non-test objects; the system places the data in Production mode tables.
The design objects you see from the Test a Study Design navigation path is not shared. However, DCMs, DCM layouts, DCIs, procedures, and Mass Change criteria are shared between Production and Test modes.
Oracle does not support using Test mode for the certain operations:
Oracle does not support using Test mode to validate an entire Oracle Clinical installation, or individual system functions.
Test mode cannot emulate the discrepancy management workflow process. In particular, you cannot generate Data Clarification Forms (DCFs), in Test mode.
Test mode does not optimize indexes or queries.
Test mode does not preserve or track the results of previous test executions.
Test mode cannot handle the large amounts of patient data you would typically collect in Production mode.
You cannot migrate the test data entered in the classic Data Entry to PDF RDC in test mode.
Test mode deletes all existing discrepancies and derived responses each time you run batch validation in Test mode.
Batch Validation in Test mode runs derivation and validation procedures with Provisional status. (Production mode does not.) This difference can impact performance in Test mode if you have many provisional procedures.
Open an Oracle Clinical session in Test mode by entering a particular URL in your browser. In Internet Explorer, enter the URL for one of these sessions, where computer_name.domain is the connecting application server's network name, a separating period (.), and your organization's network domain name (for example, us.oracle.com). These are the Test mode URLs:
Oracle Clinical Test mode:
http://computer_name.domain/opa46/launcht.htm
RDC Classic Test mode:
http://computer_name.domain/opa46/rdclauncht.htm
RDC in Admin Test mode:
http://computer_name.domain/opa46/rdcadmint.htm
RDC Onsite Test mode:
http://computer_name.domain/olsa/oc/rdcLogin.do?event=doSetup&mode=T&d
When you create a live clinical study version, Oracle Clinical automatically assigns test sites, Investigators, and ten patient positions to it. This provides the framework you need to test your definitions. You can use Test mode layouts and forms as you would their Production mode counterparts, ensuring that they correctly represent the study's requirements.
When you enter data into a CRF, you specify or select Investigator, Site, Patient, Clinical Planned Events (CPEs), and Visits. Oracle Clinical uses Test mode data for Investigator, Site, and Patient information. However, Oracle Clinical uses the same CPE and Visit information for both Production and Test mode. (The data comes from the same tables.)
The test sites, Investigators, and patient position names that are included with the installation have a leading X to distinguish them from production data. If you need additional cases you can modify or add to this data. For example, you can modify the generated details in a patient position where you need procedures requiring different sexes or dates of birth.
If you modify or supplement these test objects, Oracle recommends adhering to a naming convention that avoids confusion with production data. Oracle Clinical prevents using test data in Production mode, but hard copy reports or SAS data sets with test data that have similar names to production data could cause confusion.
The Design Test mode systems are identical to their production counterparts. For instructions for using these utilities, refer to the references included in this list:
Testing Investigator Design: See "Maintaining Investigator Records". From the Design menu, select Test a Study Design, then Investigators.
Testing Site Design: See "Maintaining Site Records". From the Design menu, select Test a Study Design, then Sites.
Testing Study Sites: See "Assigning Sites to a Study". From the Design menu, select Test a Study Design, then Study Site.
Testing Site Investigator Assignments and Details: See "Assigning Investigators to Study Sites".
Testing Patient Positions Maintenance: See "Maintaining Patient Positions". From the Design menu, select Test a Study Design, then Creating/Deleting Patient.
Linking patients to a test study: See "Linking Patient Positions in Different Studies". From the Design menu, select Test a Study Design, then Patients, and click the Patient Positions button.
Maintain test study Patient Positions: See "Maintaining Patient Positions" for more information. From the Design menu, select Test a Study Design, then Patients, and click the Patient Positions button.
Oracle Clinical creates the following private synonyms that point to the test tables or to the views in Test mode. When you access a Test mode option, Oracle Clinical creates synonyms for you that point to the test tables. Oracle Clinical drops the synonyms for Production mode.
| Test Synonym | Production Mode Table or View |
|---|---|
|
ACTUAL_EVENTST |
ACTUAL_EVENTS |
|
ACTUAL_EVENTS1T |
ACTUAL_EVENTS1 |
|
ACTUAL_EVENTSVT |
ACTUAL_EVENTSV |
|
DISCREPANCY_ENTRIEST |
DISCREPANCY_ENTRIES |
|
DISCREPANCY_ENTRY_REVIEW_HISTT |
DISCREPANCY_ENTRY_REVIEW_HIST |
|
DISCREPANCY_MANAGEMENTT |
DISCREPANCY_MANAGEMENT |
|
INVESTIGATORST |
INVESTIGATORS |
|
INVESTIGATORST |
OCL_INVESTIGATORS |
|
SITEST |
OCL_SITES |
|
RXC_STUDY_SITEST |
OCL_STUDY_SITES |
|
STUDY_SITE_ROLEST |
OCL_STUDY_SITE_ROLES |
|
OPA_LEVEL_PRIVST |
OPA_LEVEL_PRIVS |
|
PATIENT_POSITIONST |
PATIENT_POSITIONS |
|
PATIENT_POSITIONS_VT |
PATIENT_POSITIONS_V |
|
RDC_AUDIT_VIEWT |
RDC_AUDIT_VIEW |
|
RDC_DISCREPANCIEST |
RDC_DISCREPANCIES |
|
RDC_PDF_VRVST |
RDC_PDF_VRVS |
|
RDC_VRVST |
RDC_VRVS |
|
RDCI_HISTORYT |
RDCI_HISTORY |
|
RECEIVED_DCIST |
RECEIVED_DCIS |
|
RECEIVED_DCIS_VT |
RECEIVED_DCIS_V |
|
RECEIVED_DCMST |
RECEIVED_DCMS |
|
RECEIVED_DCMS_VT |
RECEIVED_DCMS_V |
|
RECEIVED_PAGE_HISTORYT |
RECEIVED_PAGE_HISTORY |
|
RECEIVED_PAGEST |
RECEIVED_PAGES |
|
RESPONSEST |
RESPONSES |
|
RXC_STUDY_SITEST |
RXC_STUDY_SITES |
|
SITEST |
SITES |
|
STUDY_SITE_PATIENT_POST |
STUDY_SITE_PATIENT_POSITIONS |
|
STUDY_SITE_ROLEST |
STUDY_SITE_ROLES |
|
VALIDATION_REPORTED_VALUEST |
VALIDATION_REPORTED_VALUES |
|
VALIDATION_REPORTED_VALUES_VT |
VALIDATION_REPORTED_VALUES_V |
Until you move a study to production, all of your Oracle Clinical sessions for that study are in Test mode. When you are in Test mode, your Oracle account points to test tables. This condition applies even after you log out and log back in. You can check whether you are pointing to test or production tables by looking in the User Synonyms table in a SQL session.
You can batch load test data. This can be helpful, for example, to test sample files from labs to confirm they are delivering the correct file formats. Oracle Clinical enables you to batch load data into test database tables, batch delete data from the test tables, and execute a batch validation session on test data. Test mode Batch Data Load is a way to get test data into the system, and to check that your files formats are correct. However, the Test mode batch system is not optimized for large volumes of data, and it uses separate tables; so there's no correlation between test mode and production mode performance. This section includes an overview of each of these tasks:
These are some guidelines for creating test data:
Use actual clinical study data from a previous study for the best test data. You can batch load data in Test mode.
Test mode Batch Data Load is not tuned for performance. If you have a large BDL file, consider taking a subset of the file to reduce load time.
Embed the test cases in error-free data.
List all the ways each Question on the DCM for which you are building test data can be invalid. Consider these points of view:
Misleading responses from patients
Misunderstanding the patient response by the clinical staff (Omissions and commissions)
The data entry operators' mistakes reading the CRF, misreading the CRF, mistakes of entry, misunderstanding wording on the DCM layout).
Include responses that are invalid from the point of view of the system, but not from the point of view of the person responding.
Modify your test data to create responses that are out of range, not in the correct DVG, incorrect units, incompatible with other responses on the DCM, or from earlier planned events.
Create test data that is valid, slightly invalid (just over the range, for example), and extremely invalid; sometimes Validation Procedures catch errors near a set point, but fail to handle errors totally outside the expected range.
Batch load test data to make the following tests:
Internal study definition—of, for example, format masks, DCIs, DCMs, and DCI_Modules
Validation and derivation Procedures
Test batch data load works like production batch data load, giving similar errors and warnings in similar circumstances; however, objects in a test load are test objects, and data is loaded into test database tables.
Test batch data load differs from production batch data load in two additional respects:
You can apply both provisional and active format masks to test data files and test operating system files.
You can use both provisional and active DCIs, DCMs, and DCIs in test batch load files.
Deleting data from test database tables allows reproducible testing of study conduct and data entry on provisional objects, which is particularly useful during the initial setup of a study. Deleting batch data also frees up database space.
When full study data delete is run in Test mode, all relevant test mass change information is deleted for the study.
The data you delete depends on the input parameters from the test database tables for a study. Parameters are DCI, Document Number, Data File, and Data File Group. DCIs can be Active or Provisional; but the three other parameters must be Test. When data is deleted, it can be deleted from actual tables as well as the staging, according to the parameters input.
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.
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:
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:
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.
Enter values for the Procedure Name and Version Number; both fields are list-enabled.
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.
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).
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.
Log in to RDC Classic using the test-mode URL; see "Launching Test Mode Sessions" and enter test data for a patient in order to test character DCM layouts. In addition, generate and print a Patient Data Report and check that each page is complete.
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.
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.
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.
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.
To create test data extract views in Test, follow these instructions:
Run PSUB to create the view: Navigate to Conduct, then Data Extract, and finally Data Extract Views.
Select TEST for account type and study_name$TEST for the account.
Click Submit.
|
 Copyright © 1996, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|