| Oracle® Clinical Creating a Study Release 5.1 E52787-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Clinical Creating a Study Release 5.1 E52787-01 |
|
|
PDF · Mobi · ePub |
This manual covers the study design process from the initial organization planning stage to the active study stage.
Oracle Clinical organizes the study creation process into several subsystems. The subsystems correspond to a progressively maturing protocol. They parallel the stages of clinical study creation, from the general features common to all studies to features specific to modeling one protocol for one study.
However, the tasks in creating a study are iterative, nonsequential, and often performed by more than one individual or team, so Oracle Clinical's modular subsystems enable your company to develop different parts of a study concurrently. The general stages for creating any study in Oracle Clinical, (with the corresponding subsystems in parentheses) are:
Program and project definition (the Plan subsystem)
Study definition (Design)
Defining data collection objects (Glib and Definition)
Testing (Design)
The following sections describe the tasks required in each of the major and minor subsystems of Oracle Clinical to create a study:
The Global Library is the repository for all the required objects for creating and maintaining your organization's data collection, validation, and extract operations. You can create some of these objects in the Global Library. Others, you can create, test, and validate at the study level, then elevate to the Global Library. Once in the Global Library, they are available for use in other studies and at other locations.
Only people with certain database roles can access the Global Library screens, thereby retaining the integrity of the objects. For instance, by default, only RXC_SUPER and RXC_GL_FULL users have access to the Maintain Questions form (from the Glib menu, select Questions). (Oracle Clinical provides many roles, and your company can modify them or add new ones.)
Few of the tasks in the Global Library fit into simple linear sequences where you start with one task and progress straight to the end. Most of the tasks are iterative; many require cooperation with other users carrying out such system tasks as designing data collection; and all have a management component, such as determining Question status or managing reference codelists.
The Design subsystem provides the facilities to model a clinical study after a study protocol. It provides a set of planning and recording facilities to handle diverse studies. No single study would use all its functions and options. Oracle Clinical provides two approaches to modeling a protocol: applying the Easy Study Design module, or applying the full complement of standard design modules.
During the early phases of study design, some details are often either unclear or disputed. For this reason, the Design subsystem enables you to design a study as a series of refinements. You can design the study's basic outlines early in its lifecycle, and refine it, exploring alternatives, until it matures into a fully operational study. The following sections describe the major levels and components of this subsystem.
You can employ the Easy Study Design module—an integrated subset of the standard Design modules—to develop the fundamental details of a study to a testable stage of development. Oracle Clinical recommends that you begin creating a study with the Easy Study Design module, then clarify the details, as necessary, with the standard modules. If you have study planning privileges, you can create a planned study and a live study simultaneously. You also have the option to create or assign Intervals, planned events, treatment patterns, and patient positions.
Use the standard Design subsystem modules to refine the properties of a study originating in the Easy Study Design module, or to create new properties. The Design subsystem includes the following facilities:
At the planning level, you establish the organizational and geographic relationships for a new study and the program and project it belongs to.
As the design of your study matures, you move it to the clinical study level. The clinical study record holds the basic details about the study.
A version is a variation on a proposed study design. Often basic study objectives and strategy are clear, but doubt remains about the effects that different stratifications, randomizations, or schedules of events might have on the results. Because a study has many variables, it is often difficult to predict which variation of a study would produce the clearest results. Clinical study versions contribute to solving this problem in two ways: (1) they facilitate building and comparing variations on one basic study design; (2) they permit altering one component, such as the stratification, without redesigning the entire study.
The planned study Intervals in a study make up the study timeline. A timeline is composed of phases, divided into periods, further divided into sub-periods. Each of these represents a planned study Interval.
A clinical process is a name for a type of visit in a study, such as a normal dosing visit. The clinical process is then used to describe the clinical planned event (CPE). A clinical process can be scheduled to occur several times within a study.
A study's treatment patterns—one or more treatment regimens in a particular sequence—specify the drugs and medical procedures. You can assign a patient to a treatment pattern and then follow the course of treatment specified by the treatment regimens during parts of the study.
With patient positions you specify the number of screening patients, "normal" patients, and replacement patients in the study.
Details of pattern assignment are usually kept secret until after completion of a study's inclusion/exclusion process. If an Investigator discovers details of the pattern for a patient, creating a blind break, Oracle Clinical provides facilities to record and report it.
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:
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.
Create the necessary new DCMs, or copy them from the Global Library or other clinical studies.
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.
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.
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.
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.
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.
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.
Build or refine the study's data extract views. Condition your data to conform to the formatting requirements of other applications, such as SAS.
The Definition subsystem includes the following data collection objects you create or modify:
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.
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.
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.
Write Validation Procedures to specify allowable entry values and Derivation Procedures to create additional values.
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 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.
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.
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.
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.
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 Chapter 9, "DCMs and DCIs."
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 Chapter 12, "Creating Graphic Layouts."
|
 Copyright © 1996, 2014, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
