Definition

Defining data collection for a clinical study within Oracle Clinical consists of building a database model of the study in the Oracle Clinical relational database. From this model, Oracle Clinical creates the logic necessary for data capture, validation, extract, and management. The main tasks you perform in the Definition subsystem are:

1. Determine how many and what kind of DCMs you need for the new clinical study. The initial work you do in the Design subsystem provides the structure of the study and a clinical study name.
2. Create the necessary new DCMs, or copy them from the Global Library or other clinical studies.
3. Populate the DCMs with Questions in Question Groups. Most of these objects are available for copy from the Global Library. A study designer with Global Library privileges can create new Questions.
4. Set the DCM schedule. Since each DCM corresponds to medical data collected at visits, you must associate each DCM intended for collection at a particular visit to the appropriate clinical planned event.
5. Customize each DCM's data entry form. Oracle Clinical creates forms automatically, but you can modify them to suit individual study needs or to simulate a Case Report Form.
6. Construct the DCIs, each of which establishes a correspondence between a Case Report Form (CRF), or batch data, and its DCM(s). Since a DCI may contain one or more DCMs and may run over more than one clinical visit, you must complete the construction of your DCMs before building DCIs. In the common case of a single DCM corresponding to a single DCI, Oracle Clinical automatically creates the DCI with the same name.

   You can optionally create one or more DCI books to structure the data entry process and to associate particular instances of a DCI with CRF page numbers. These DCI books consist of an ordered list of DCIs with their page numbers and visit identification. Later, during data entry, you can choose to step through the data entry screens in the order defined in your DCI book.

7. Define Validation and Derivation Procedures to standardize data entry. Validation Procedures test that data values meet your criteria, and Derivation Procedures create new data values.
8. Test the DCM data entry screens and Validation and Derivation Procedures with test data. You can then refine your objects if necessary, before using them in production.
9. Build or refine the study's data extract views. Condition your data to conform to the formatting requirements of other applications, such as SAS.

For more information, see:

• Definition Components
  
• Data Entry and Report Layout Design
  

Definition Components

The Definition subsystem includes the following data collection objects you create or modify:

Data Collection Modules - A data collection module (DCM) associates one or more related groups of Questions to a single clinical study visit. It is the equivalent of the section of a CRF that must be completed during a single clinical visit. A DCM can also define data such as laboratory results for electronic loading. Sometimes it is useful to define a DCM to collect data that continues across visits, such as the data in an adverse event log.

Data Collection Instruments - A DCI groups DCMs according to the study's CRFs.

DCI Books - You can optionally organize the DCI s (and the DCMs they reference) into DCI books, which associate the DCI s with CRF pages and organize the workflow of data entry.

CRF Page Tracking - You can set up new studies you create with Oracle Clinical to have an exact correspondence between a DCM, DCI, or DCI book, and the page number of a paper CRF.

Procedures - Write Validation Procedures to specify allowable entry values and Derivation Procedures to create additional values.

Validation Procedures - Validation Procedures help to ensure the accuracy of data collected in a study by checking for inconsistencies and discrepancies among Question responses. They also help find and analyze medically important relationships in collected data. Validation Procedures compare data collected for more than one response, and include simple comparisons of data from a single DCM as well as complex comparisons of data from multiple DCMs and visits. You can use arithmetic functions and manipulations of the data in tests. Validation Procedures can compare previously derived responses with user-entered data. When Validation Procedures uncover discrepancies, or values you have defined as inconsistent or out of range, Oracle Clinical records them in a discrepancy database.

Each Validation Procedure consists of one or more logically related test, or detail. You can specify the data objects (DCM Question Groups or Questions) and visit to test and write an expression using these items that, if true, should result in an entry in the discrepancy database.

Derivation Procedures - Derivation Procedures perform calculations on one or more user-entered responses to derive responses to derived Questions. For example, you can calculate the response to the derived Question Age from the patient's date of birth and the date of the visit. The system generates a derived Question's response from a Derivation Procedure.

Labs - The Lab subsystem establishes and maintains the required information to track labs, lab ranges, lab assignment criteria, and units of measure and conversion for clinical laboratory test results.

Data Extract - Set up Oracle Clinical's extract modules to create data extract views, SAS datasets, and SAS Proc Prints.

Data Entry and Report Layout Design

Oracle Clinical provides character-based and graphic-based layout systems for creating data entry and report output. Features that are specific to either system include the terms Character or Graphic in their interface names.

For more information, see:

• What the Layout Systems Have in Common
  
• How the Layout Systems Differ
  
• Character-Based Layouts
  
• Graphic Layouts
  

What the Layout Systems Have in Common

The systems share the same data collection definitions. Both systems have a set of tools for generating and editing layouts. The systems' layout tools are similar.

It is possible to use both the character-based and the graphic systems simultaneously. However, if you enable a study for DCI forms, but continue to allow character-based data entry against the CRFs in a study, you create the possibility that data can be entered against the incorrect character mode layout, and have a different meaning when viewed through the DCI forms layout. You must guard against this possibility to ensure the integrity of your data. One way you might prevent this possibility is to block character mode Data Entry in RDC for such studies.

Even if you do not implement RDC Onsite, you can utilize the graphic system to create rich-format Patient Data Reports.

How the Layout Systems Differ

The graphic system allows you to create much richer layouts with more exact placement of objects. The character system lays out DCMs, but the graphic system lays out all the parts of a CRF, including DCI headers, footers, and DCMs.

Character-Based Layouts

For creating layouts for the Oracle Clinical Data Entry subsystem, configure your definitions to use a character-based layout editor. It is most suitable for trained data entry operators who can perform rapid data entry with no dependence on mouse actions or physical resemblance to CRFs. The instructions for maintaining the character-based system are part of DCMs and DCIs

Graphic Layouts

Oracle Clinical includes a Graphic layout system to create CRF renderings in PDF format. The renderings can look like—or even replace—your CRFs. They can be a single source for blank CRFs, CRFs with patient data filled in (Patient Data Reports, or PDRs), and for data entry through RDC Onsite. See Creating Graphic Layouts