| 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 |
The Plan subsystem provides an organizational framework for research groups that conduct diverse studies. You can use it to arrange the Oracle Clinical database to model your group's associations: programs, projects, organizations, or regions.
Note:
Oracle recommends that you use the Easy Study Design facility to create a new study. See Chapter 3, "Easy Study Design."This chapter describes these Plan tasks:
A program represents the top level in the grouping hierarchy of studies. A program contains projects, which contain studies. In general, you create a program for each intervention. For pharmaceutical research, you map a program to each research compound. However, you can also use programs to control which users can access studies.
The program hierarchy organizes research around a drug. You can also use programs to control user access to studies. Typically, pharmaceutical companies assign a program for each drug under investigation. Assign programs to planning-level studies in the Maintain Planned Studies window.
You can define and maintain programs from the Maintain Programs and Projects window: from the Plan menu, select Programs. To add a new program (or to modify an existing program):
Place the insertion point in an empty row. If there are no empty rows, select Insert Record (F6).
Enter a new, unique code for the program. This code identifies the program throughout Oracle Clinical.
Describe the program.
Save. By default, the system selects the Active box upon saving this record. You can make it inactive at any time by clearing the Active box.
The system stores the information you enter through these windows in the PROGRAMS database table.
The Maintain Programs and Projects window has two buttons:
Projects – Displays the Projects window, listing all available projects.
Compounds Assigned to Program – Displays the window where the compounds assigned to the selected program appear.
You can group programs into projects that specify the dimension of the intervention under investigation. For pharmaceutical research, a project maps to an indication, or a formulation, of the drug. Each project is a collection of the individual studies for the drug.
To create, update, or delete projects associated with the current program, from the Plan menu, select Programs. From Maintain Programs and Projects, choose a program, click the Projects button, and then select the project record you want.
To assign compounds to the selected program, click the Compounds Assigned to Program button. The Compounds for Program window opens, displaying the details of the compounds for the selected program.
To enter a new compound, click the Insert button. You can assign a compound to a particular program only once. Use the list function to choose from existing compounds. Choose the Primary field if this is the primary compound under investigation in this program. You can only designate one compound assigned to this program as the primary compound. This field defaults to selected when the first compound is assigned to the program. You can change this designation at any time.
The system populates the Compound Code and Description fields, according to the compound values set in the Maintain Active Substances window. There are two columns under the field title Compound Code. The first is the Compound Code, the second is the Compound Subcode. The subcode column has values only if your company uses subcodes to classify compounds.
As you add compounds, assign one of them as the primary compound. This affects Oracle Clinical reports and window displays, but you can change this designation at any time.
Organization units designate the sponsors of clinical studies. To create and maintain organization units, access the Maintain Organization Units window. From the Plan menu, select Organization Units. The window automatically displays all available organization units. If you want to select an existing unit to update or delete, select the record from the list. If you want to create an organization unit, click the Insert button, and enter the name. The system enters the current date in the Start Date field. You can indicate the unit's expected end date, or leave it blank.
In this module, you can create and maintain records of geographical regions and the structure of regions within regions. To reach the window, from the Plan menu, select Regions. Information you enter is stored in the Maintain Regions module in the Regions and Regions Components database tables.
You can delete a region from either of the Maintain Regions windows. When you delete a region, the system deletes any region components linked to it (Made From or Part Of). If you try to delete an active region—that is, one assigned to a clinical study, you get an error message, "Deletion not allowed, assigned to Clinical Studies." You receive a similar message if the region is used elsewhere in the system.
Occasionally you may need to update or change a region or one of its attributes. You cannot update a region in the Part of Region window or the Region Contains window. You can only insert and delete "part of" regions or "contained" regions in these windows.
To update a region:
From the Plan menu, select Regions.
Query for criteria about the region you want to update.
Click the Clear Field button to remove the field's contents, or just type over the existing text.
Enter new information in the field.
Save your work by clicking the Commit button.
This Maintain Regions window has two buttons:
Regions This One is a Part Of – Lists the regions, including the current region.
Regions Within This Region – Lists the regions composing the selected region.
You can use region components to further refine the organization of your regions. The Region Components window records the regions of which a region is a part. To open the Maintain Region Components window, from the Plan menu, select Regions, then select Regions This One is a Part Of button.
You can only assign or remove "parent" regions in the Maintain Regions This One is a Part Of window; to create new regions or modify them, click the Exit button to return to the Maintain Regions window. As it appears, this window lists the existing regions in order of region code. Note that you can insert and delete in this window, but not update.
To maintain regions within this region, from the Plan menu, select Regions, then select the Regions Within This Region button. The Region <region name> window displays the regions this region currently includes. Use the list function to choose available values. You can only assign or remove "child" regions in this window; to create new regions or modify them, click the Exit button to return to the Maintain Regions window.
The Planned Studies utility allows you to assign general attributes that the clinical studies inherit. These attributes characterize studies at the design level. The Easy Study Design facility writes to a subset of these same database tables; you can modify the planning details of a study that originates in the Easy Study Design facility here.
Before you create a planned study, create affiliations: program, project, organization, and region. (See above.)
To create a new planned study, follow these steps:
From the Plan menu, select Planned Studies.
Enter a unique study identifier in the Study field of a blank line. If there are no empty rows in the window, use the Insert function. (From the Data menu, select Insert Record, or press F6.) You cannot change this field once you save your work.
Complete the Name and Title fields.
Assign an organization unit.
Assign one region to be the master country: the region that owns the study.
Enter the expected number of Investigators.
Use the list function to choose a design type. Design type is set in the EXP DESIGN TYPE CODE installation reference codelist.
Use the list function to choose a clinical phase. Clinical phase values are contained on the CLINICAL PHASE installation reference codelist.
Assign a program.
Assign a project. To modify the planning details of an existing study, select the appropriate field.
The Maintain Clinical Studies window is the starting point for creating a new clinical study. This window names and describes a clinical study, consolidating many of its details. You can create the new clinical study provided projects, organization units, and regions already exist in Oracle Clinical's Planning subsystem. You can also augment the details of a clinical study originating in the Easy Study Design facility.
Follow these instructions to create a new clinical study:
Navigate to Design, Studies, then Clinical Studies.
Click the Insert Record icon in the toolbar.
In the Study field, select a study code from the list of available codes. (Designers set these values in the Planned Studies window. See "Creating Planned Studies".)
Enter, modify, or accept the short and long study titles.
The system populates the Access field according to its designated randomization access. Designers with randomization privileges can set the list's values in the Amend Randomization (from the Design menu, select Randomization, then select Randomization Maintenance, finally choose Randomization Statuses).
Select the Pivotal Study? box if this is a pivotal study. Pivotal Study is an industry term indicating that failure terminates development of the drug.
Select the FDA? box if you expect to include the study's data in a submission to the FDA.
Save. When you exit, the system prompts you to confirm the creation. If you click Yes the system saves the record to the database and closes the window.
In the Maintain Clinical Study Objectives window, you can create, update, or delete descriptions of clinical study objectives. A study can have any number of objectives. The study can have more than one objective for an objective type. The system automatically queries the objectives for the selected clinical study when you open the window.
Select an objective to work with or use the Insert Record function to add an objective.
Choose the objective's type. You must choose the type of objective from values set in the OBJECTIVE TYPE CODE codelist.
If you have more than one objective for a type, you can rank their importance by assigning them numbers in the Order field.
Select the Final Analysis? field if the objective should be taken into account during the study's final analysis. Leave it deselected if the objective is for interim analysis.
Describe the objective.
Use the Maintain Enrollment Criteria window to create, update, or delete the enrollment criteria of participants in a study.
A clinical study can have any number of enrollment criteria. Use the multi-record window to view all the enrollment criteria already assigned to a study. The single-record window contains more complete names for the fields. In multi-record mode, the system sorts the list by the criteria flagged as inclusion criteria first.
To create, update, or delete the enrollment criteria:
From the Design menu, select Studies, then choose Clinical Studies. The Maintain Clinical Studies window opens.
Query for and select a study, then click the Enrollment button. The Enrollment Criteria for Study window opens.
Choose an enrollment criterion, or use the Insert Record data function to add a new criterion. Copy or write a description of the criterion in the Criteria Description field.
Select the Inclusion? field (labeled Is this one of the Inclusion Criteria? in the single-record window), if you use the criterion as a requirement a patient must meet to be included in the study. Leave the field deselected if you use the criterion to exclude patients from a study. Currently, the system does not use this information.
Select the Phone? field (labeled Used by Phone Randomization System? in the single-record window), if the criterion helps define a phone randomization system.
Select the Screening? field (labeled Used for Initial Screening? in the single-record window), if you use the criterion as an initial screening of patients. A blank field indicates the criterion applies to final enrollment into the study.
Enter a grouping code in the Group? field (Grouping code in the single-record window), if a criterion is an element of a set of criteria.
The field is optional and accepts any value. The list of values shows the existing values for the study. Grouping criteria creates an OR logic condition. For example, to define a criterion for blood group A or B, you would group a criterion for blood group A, and a second for blood group B. You would join them with a code of A_OR_B.
Choose any factors to measure in the enrollment criterion. (A factor is a trait people share that may affect the outcome of a study.)
To clarify a trait's influence, and to reduce the likelihood of an improperly distributed factor, regulate its distribution to randomization groups with the system's strata forms. Designers with randomization privileges can set the code values for factors in the Maintain Factors window (from the Design menu, select Strata, then choose Factors). Set minimum and maximum values to factors that are part of a range (type R). Set a single value for a single-value factor (type V).
From the Design menu, select Studies, then select Clinical Studies, and click the Termination button.
Select a termination criterion to work with, or use the Insert Record function to add one.
Describe the conditions that constitute an early termination.
Select the Early Term? box (Is Criteria for Early Termination?, in the single-record window), if the termination criterion disqualifies a terminated patient's data from being part of the study's final analysis. Leave the field deselected if an early termination does not remove any of the patient's collected data from final analysis.
Select the Incl In Safety? (Include in Safety Analysis?, in the single-record window), box if the termination criterion disqualifies an early-termination patient's data from being included in the study's safety analysis. Leave this field deselected if an early termination does not remove any of the patient's data from the safety analysis.
Select the Incl In Efficacy? (Include in Efficacy Analysis?, in the single-record window), box if the termination criterion disqualifies an early-termination patient's data from being included in the study's efficacy analysis. Leave this field unchecked if an early termination does not remove any of the patient's data from the efficacy analysis.
Choose any factors to measure in the termination criterion. Designers with randomization privileges can set the code values for factors in the Maintain Factors window (from the Design menu, select Strata, then choose Factors). Set minimum and maximum values to factors that are part of a range (type R). Set a single value for a single-value factor (type V).
A study can have any number of comments, and the system displays all comments for a study after you select it. You cannot update or delete a study comment. From the Design menu, select Studies, then choose Clinical Studies, and click the Comment button. Use the Insert Record function to add a comment. Create comments to record information that have no specific attributes. The system does not use the comments.
You can assign the regions to a study in this window. Study planners can create the values for regions in the Maintain Regions window (from the Plan menu, select Regions), or, from the Design menu, select Studies, choose Clinical Studies, and then click the Region button. The regions display by region code sequence. You can assign a region to a particular clinical study only once; however, a study can be conducted in more than one region and be expanded to include other regions than originally designated.
To maintain the regions for a clinical study, follow these steps:
Choose an assigned region, or use the Insert Record data function to add a new region.
Select the Regulatory? box if you include a region for regulatory reasons.
Select the Marketing? box if you include a region for marketing reasons.
Select the Reporting? box if this region is the region that appears in reports. Only one region can be the reporting region for a study.
Historical events may be one of two kinds: event recording triggered by the system, or a user-defined event. Historical events triggered by the system include:
Creation of this study
Creation of a study version
Setting or changing the randomization access codes for a study
Setting or changing the randomization access codes for a study phase
Setting or changing the study status
Setting the live study flag
Examples of possible user-defined historical events are producing a first draft of a study, or sending a first draft to another location for review. You can create or display clinical study history records, but you cannot delete or change a history entry. You can record dates for events you expect to occur in the future. The system populates the Type field, assigning user-generated records the value USERDEF.
To create or maintain historical event information, from the Design menu, select Studies, then select Clinical Studies, and click the History button.
Open this window to display planning data about a clinical study. From the Design menu, select Studies, then select Clinical Studies, and click the Planning button. These details are all set in the Planning subsystem. The system sorts and displays phases in chronological sequence.
The buttons along the bottom of this window open several Design utilities. The following section describes these utilities and some of the main fields.
Set the study status to classify the study according to its developmental maturity. The timestamp for each change in status appears in the study's history. Use the list function to set a study's status. Your company maintains study status values on the STUDY STATUS TYPE CODE codelist (from the Admin menu, select Reference Codelists, then choose Design Installation Codelists, and query STUDY STATUS CODE LIST). You can also set randomization access in this window.
The information you enter provides a basis for creating clinical study history records.
To update clinical study statuses:
From the Design menu, select Studies, then select Study Statuses.
Select the study of interest.
Use the list and query functions, if necessary, to locate the study.
Enter the study status code.
Deleting a clinical study also deletes these elements associated with the study:
To delete a clinical study, from the Design menu, select Studies, then select Delete Study. The Delete Clinical Studies window appears with a Clinical Studies window. The system displays all the current studies. Select the study you want to delete and click the Delete button. The clinical study disappears from the listing.
Note:
You receive an error message if you attempt to delete a clinical study with existing received DCIs; also, your company might place local safeguards.You can design a CRF so that the response to a particular Question for a particular patient changes which additional Questions should be entered for that patient.
There are three different types of branching available:
Indicator branching: If a patient's response to a Question should determine whether the remaining Questions in the same group should be collected for that patient, use indicator branching, which you define in the Global Library at the Question Group level. You define the first Question in the Question Group as an indicator Question and specify the response value that makes the remaining Questions in the Question Group collectible. If a value other than the indicator value is entered for a patient, the cursor moves next to the first Question of the next Question Group.
For example, define the first Question, SEX, to collect the patient's gender, with only two allowable values: MALE and FEMALE. If a patient's response to SEX is FEMALE, then the remainder of the Questions in the Question Group, which cover pregnancy and menopause, become collectible for the patient. If the patient is male, these Questions are not collectible for the patient. The next Questions available in data entry are in the next Question Group in the DCM, if any.
Conditional branching: If the initial, or source, Question should make Questions in the same or a different Question Group in the same DCM collectible, use conditional branching, which you can define in either the Global Library or in a study at the DCM Question Group Question level. You must specify a target Question for each allowable response. The logic can include a range of responses, defined as greater than, less than, or equal to a particular value.
For example, define a Question "Are you pregnant?" with a DVG containing three values: Yes, No, and I Don't Know. For the response Yes, define a target of the first Question in a Question Group about the pregnancy. For I Don't Know, define a Question "Is lab test scheduled?" as the target, with the Question "Date scheduled" nested. For No, either define a target of "Verification that lab test confirms" or do not define a target at all, in which case the cursor goes to the next sequential Question during data entry.
Branching to make Questions, visits, or Intervals expected or not expected for a patient: If the initial, or source, Question should make Questions collectible that are included in a different DCM, or even a different CPE (Clinical Planned Event, or Visit) or Interval, use Enhanced DCI Books and their rules to define these relationships; see "Designing a Flexible Study" and Appendix A, "Flexible Study Design Examples".
Note:
This type of branching is different from indicator and conditional branching in that the Questions made collectible by the response value may or may not be the next Questions answered in data entry—they may be in another CRF or visit entirely.For example, define a Question Age. If the study has an age limit of 60 and the patient is 60 or under, the normal series of visits becomes expected for the patient (up to the next source Question, if any). If the patient is over 60, only the End of Study visit is enabled.
This section contains the following topics:
If your trial is flexible—meaning that the protocol calls for decision points that determine which Intervals (groups of visits) and DCIs (equivalent to CRFs) are expected for each particular patient—use the Enhanced DCI Book feature to define the decision points and rules that determine Interval and DCI expectedness for each patient as he or she progresses through the trial.
Implementing a flexible study design in Oracle Clinical includes the following:
Schedule Define the study schedule, including Intervals (Phases, Periods, and Subperiods) and visits, or Clinical Planned Events (CPEs), in the same way as for nonflexible studies in Oracle Clinical, associating CPEs with Intervals and defining both CPEs and Intervals in chronological order. In the DCI Book, associate DCIs with CPEs.
Rules Create a conditional schedule by defining rules. Identify the particular Questions and responses to them (the rule trigger) that determine which DCIs or Intervals (the rule target) are expected for a particular patient.
An Intervals or DCI that is the target of a rule is conditional; it is expected for a particular patient only if the data condition specified in the rule trigger is met for that patient. An Interval or DCI that is not the target of a rule—or dependent on another Interval or DCI that is the target of a rule—is unconditional. It is expected for all patients assigned to the DCI Book.
It is also possible to define a rule with an Interval as a target and an action called Bypass To; when the trigger condition is met for this type of rule the target Interval becomes expected for the patient and all intervening Intervals are skipped; they are no longer expected.
Calculating Data Expectedness for Patients As sites enter data for a particular patient, Oracle Clinical recognizes the decision points you have defined as triggers in the DCI Book's rules, determines whether the value entered satisfies the defined condition and if so, makes the DCI(s) or Interval(s) defined as the target of that rule expected for that patient.
CPE and CRF Display in RDC Onsite RDC Onsite displays only CRFs and CPEs that are either collected or expected for each particular patient. They may be expected because the corresponding DCIs and Intervals are defined as unconditional or because their condition has been met.
Whenever a user updates data that triggers a rule, the system recalculates expectedness for the patient and RDC Onsite adjusts the display of expected CPEs and CRFs as necessary. If a CRF that already has data collected becomes not expected due to a data update, RDC Onsite still displays the CRF icon but an "N" for not expected appears next to the CRF icon.
Note:
See also Appendix A, "Flexible Study Design Examples."To take advantage of flexible study functionality in the Enhanced DCI Book window and in RDC Onsite, you must first define the study as flexible. When you create a new study using Easy Study Design, the system prompts you for the Flexible setting.
You can also make an existing study flexible in the Clinical Study States window under Conduct, Security if the following conditions are met:
No test or production data has been entered.
Note:
If the study has an active DCI Book, you must set it to Provisional and back to Active before you can use it for data entry. If you have patients assigned to the book and you plan to use the book with RDC Onsite, you must also run the Calculate Expectedness job.The study's Page Tracking setting is not checked.
You cannot reverse the Flexible setting from checked to unchecked if the study has production data.
As you plan your study schedule and how to define it, consider the ramifications for flexible studies:
Interval and CPE order determine the default order of the DCI Book. You can define rules that allow a particular patient to skip certain Intervals—for example, to follow Treatment Arm A instead of Treatment Arm B—but you cannot use the DCI Book to change Interval or CPE order. A patient can only move from one Interval or CPE to another defined later in the study schedule. For example, if a rest period is required after Treatment A and after Treatment B, you must define it after both Treatment A and Treatment B in the study schedule; see Figure A-8, "Multiple Paths" for an example. See "Defining a Study Schedule" and "Creating Clinical Planned Events" for information on defining Intervals and CPEs.
Using rules, you can make a whole Oracle Clinical Interval (Phase, Period, or Subperiod) that directly contains CPEs, expected (or skipped) for a particular patient if that patient's data meets conditions you define. Therefore define groups of CPEs that you want to enable or skip all at once as a single Interval.
You can make a particular DCI expected for a particular patient if that patient's data meets conditions you define. Even if the Interval as a whole is expected for a patient, you can define rules in such a way that every DCI at every CPE is not necessarily required.
You may want to give Intervals and CPEs nonnumeric names so that you can incorporate these names, or abbreviations of them, in DCI Book page numbers. In a DCI Book, each DCI, or Book page, must have a unique number. Normally no patient will have data collected for every DCI, so if you use purely numeric page numbers there will be gaps; see "Sample Numbering Schemes" for more information.
Note:
When you create a study using Easy Study Design, the system automatically creates a Phase Interval called DEFAULT STUDY PHASE. If you are creating a flexible study you cannot use this default Interval and must explicitly create Intervals.Design flexible studies with only one DCI Book. You can define multiple treatment arms and many decision points and rules within a single DCI Book. Use the same DCI Book for all patients in study.
The only time you may want to have more than one DCI Book for a study is when the protocol is amended during the trial. In that case, you may want to copy the DCI Book, make the necessary changes, and reassign patients to the revised Book.
Using multiple DCI Books that include different portions of the study schedule is not recommended because there is no validation that the definitions of the two Books are consistent with each other. Migration between such unrelated books will be successful but the new expectedness calculation will reflect only the structure and rules of the new Book.
This section contains the following topics:
Each rule consists of a trigger—the data condition that must be met to trigger the rule, and a target—the DCI or Interval that is enabled when the condition is met.
To determine what rules your study requires, it may help to draw a diagram similar to those in Appendix A, "Flexible Study Design Examples."
See "Validation Checks" for information about rule definition restrictions.
In most cases, a trigger is one or more specified values that, when entered in response to a specified Question in a specified DCI at a specified CPE, constitute the condition that invokes the rule and makes the trigger DCI or Interval expected for the patient. It is also possible to specify that any data collected for a specified DCM constitutes the condition; see "Using the Any Data Trigger".
Questions used as a rule trigger must:
have a Discrete Value Group (DVG) of type Internal or Thesaurus. The user must select the Question response value from the list of valid values specified in the DVG; see "Creating and Using DVGs".
be of type CHAR
not be a complex Question
not be included in a repeating Question Group
Question response values cannot be numeric and they cannot be a range of numbers. However, if you need a numeric value or range of values to serve as a trigger, you can effectively do that using a Derivation Procedure.
To convert a numeric value to a character value that can be used as a trigger, define a numeric Question to collect the numeric data, a derived Question to hold the character value, and a Derivation Procedure that takes the numeric Question response value as input, performs a calculation, generates a character value, and supplies the character value as the response to the derived character Question.
For example, if you want to require additional tests for patients whose systolic blood pressure is over 160, you can:
Define numeric Question SBP to collect the patient's actual systolic blood pressure.
Define a Derivation Procedure to take the value of SBP and determine whether it is greater than, equal to, or less than 160 and, if it is greater than 160, to return a value of Y and if not, to return a value of N.
Define derived Question DSBP to hold the derived value—either Y or N. (You must define the derived Question before you define the Derivation Procedure.)
Assign a Discrete Value Group (DVG) with the values Y and N to Question DSBP.
Define the rule trigger to be the value of DSBP, in a specified DCI and CPE, equal to Y.
Define one or more DCIs that collect the additional data—at one or more CPEs—as the target of the rule.
If a patient's systolic blood pressure has a value greater than 160, the Derivation Procedure generates a value of Y, the rule is triggered, and the specified DCIs become expected for that patient and visible in RDC Onsite.
The timing of the execution of the Derivation Procedure depends on the setting of its Exec Content field; if it is set to ON-LINE/DCM the Procedure is executed when the RDC data entry operator saves the value of Question SBP (if the RDCI status is high enough). If the Procedure generates a value of Y, the target DCI is immediately evaluated as expected for the patient and displayed in RDC Onsite.
See Chapter 16, "Validation and Derivation Procedures" for more information on defining Derivation Procedures.
Note:
The RDCI (collected data) must have a status of Batch Loaded or Pass 1 Complete or beyond. This might not be the case if the RDC user used the Save rather than the Save Complete action, or if data was entered through Oracle Clinical and Pass 2 was required for the study.Data entered through Oracle Clinical or earlier versions of RDC Classic and RDC Onsite triggers rules and makes Intervals and DCIs expected. However, expectedness is not interpreted by the user interface except in RDC Onsite.
The Any Data trigger satisfies the rule condition if the trigger DCI has any entered data at all. You do not need to define a particular Question as the rule trigger. As soon as any data is entered and saved for the DCI for a patient (if the RDCI has a status of Batch Data Loaded or Pass 1 Complete or beyond), the target Interval is enabled, or expected, for that patient.
For example, if the Rest or Followup Interval is not the target of any other rule, but must come after each treatment Interval, use Any Data in a DCI in the treatment Interval as the trigger to make the Rest or Followup Interval expected for a patient.
If you define a Rest or Followup Interval after each treatment Interval in the study schedule, it will be expected even without being the target of a rule. However, by defining the rule, the target Interval does not appear in RDC Onsite until they are logically expected.
Any Data is available only for Interval rules, and only with an action of Enable.
A rule target can be one or more DCIs or Intervals. Rules that have one or more DCIs as the target are called DCI Rules. rules that have one or more Intervals as the target are called Interval Rules.
In a flexible study, all patients may not have the same assessments at every CPE. For example, a subset of pages may be required only for patients assigned to a specific Treatment Group, or detailed information may be required only if certain criteria are met, such as a detailed smoking history for smokers. Use DCI rules to make this possible.
For example, to make the detailed smoking history expected only for patients who smoke, define a DCI to contain the smoking history Questions, associate the DCI with the appropriate CPE(s) in the DCI Book Pages window, and define a DCI rule with the DCI as the target.
There are two types of DCI rules:
Within CPE: The target DCI is in the same CPE as the trigger DCI, and is enabled in that CPE when the rule is triggered. (The same target DCI may be included in other CPEs, but other occurrences of the DCI do not become expected for a patient when the "Within CPE" DCI rule is triggered.)
Across CPEs: The target DCI is enabled in every CPE where it exists, including the same CPE as the trigger DCI if it exists there, when the rule is triggered.
Note:
If only a few Questions need to be conditional on a particular Question response, you may prefer to use conditional branching instead of a "Within CPE" DCI rule; see "Defining Conditional Branching".A DCI can be the target of only one rule. A DCI that is the target of a rule can also be the trigger for a rule, but it can act as a trigger only when it is expected and collected for a patient. See "Defining DCI Rules" for further information.
In a flexible study there are multiple pathways through the trial for different patients. There may be entire Intervals (groups of CPEs) that are not required for some treatment groups, but are for others.
An Interval can be defined in the Oracle Clinical study schedule as a Phase, Period or Subperiod. Phases can contain Periods, and Periods can contain Subperiods. You can define Phases, Periods, and Subperiods as targets, as long as the rules do not conflict with each other (see "Validation Checks").
An Interval can be the target of multiple Interval rules. It becomes expected for the patient the first time a rule targeting it is triggered.
If you do not define Interval rules, all Intervals are expected for all patients, though DCIs within Intervals may be conditional if they are the target of DCI rules. See "Defining Interval Rules" for further information.
There are two types of Interval rules:
Enable: The target Interval(s), with all their unconditional CPEs and DCIs, become expected for the patient when the trigger condition is met. You can use an Enable Interval rule, for example, to make Phase I of a particular treatment arm expected, depending on the response to a particular Question; see Figure A-4, "Enable Intervals Based on a Data Value".
Bypass To: The target Interval becomes expected for the patient when the trigger condition is met and all intervening Intervals—all Intervals that occur between the trigger and target Interval—are not expected. Any remaining expected DCIs in the trigger Interval are still expected.
You can use Bypass To Interval rules, for example, to handle patients who discontinue prematurely from the trial, using a Question as straightforward as "Will the patient continue in the trial?"; see Figure A-5, "Bypass To Interval".
A Bypass To Interval rule can have only one Interval as a target, and that target cannot be Next Interval. Bypass rules take precedence over Enable rules of all types (DCI—Within and Across—and Interval) if there is a conflict.
In Enable Interval rules, you can specify Next Interval as the target instead of a named Interval. Next Interval is defined as the Interval containing the next CPE in ascending CPE number order that is in an Interval different from the one that contains the trigger DCI.
Using Next Interval has the following advantages:
It reduces the number of rules required when the same trigger condition may appear repeatedly and the target is always the next Interval; for example, in oncology studies where patients continue on cycles of treatment until the disease progresses or they respond to treatment. You can define a single rule with a Next Interval target to move each continuing patient from one cycle to the next. See Figure A-7, "Enable Next Interval" for an example.
All potential Next Intervals—all Intervals whose preceding Interval contains a the trigger of a Next Interval rule—are treated as conditional by the system; RDC Onsite does not display for a particular patient them unless they become expected.
The target Interval may be an Interval within the trigger Interval; for example, if the trigger Interval is a Phase that contains CPEs directly and also contains Periods, a DCI in a CPE contained directly in the Phase could trigger the next Period in the same Phase.
If you are using both Oracle Clinical and Siebel Clinical for a clinical study, you can integrate the two systems to automatically pass certain data and metadata from one system to the other in order to:
Signal the completion of visits and activities.
Simplify study setup in Oracle Clinical and Subject setup in Siebel Clinical.
You can also integrate Oracle Clinical with other clinical trial management systems. For further information, see Chapter 18, "Integrating with a Clinical Trial Management System."
You can copy the details of a clinical study. This is limited to the Clinical Studies, Clinical Study Enrollment Criteria, Clinical Study Termination Criteria, Study Comments, Clinical Study History, and Study Regions tables. The copying function does not copy the Study Design. Use the Copy a Clinical Study Version function to copy the actual Design.
This utility is useful for importing the attributes of an existing study into a new study. Use this utility to reduce the effort required to design a new study when a similarly structured study already exists. This differs from copying a study version, where the system copies all attributes of another version exactly as is, including randomization. Before you can copy the attributes of one study to another, the target study must--at least--be at the planned level of development.
Select or query the record you want. You cannot insert, delete, or update in this window. Click the Copy Study button to view the Copy Study window, where you specify information about the new study.
From the Design menu, select Studies, then choose Copy Clinical Studies. The Clinical Studies window opens, listing only the studies available for copying attributes.
Enter—or query—the study code for the study to copy.
Click the Copy Study button.
Use the list function to choose a target study--the study to acquire the attributes of the study you selected in the previous window. Note: There is no recourse from the following step. Cancel if you are not certain you are selecting the correct target study.
A clinical study can be replicated from one location to another. Only one location can maintain a study design but other locations can have read-only copies. Use this function to replicate a study design from its owning location to yourself. See the "Distributed study conduct" chapter in the Oracle Clinical Administrator's Guide for more information about replication.
To replicate clinical studies, from the Design menu, select Studies, and choose Replicate Clinical Study for the Replicate a Clinical Study window. The system stores information from this form in many tables, including Clinical Studies, Clinical Study Objectives, Clinical Study Enrollment Criteria, and Clinical Study Versions. Select the record you want by entering the requested codes. The fields are list-enabled.
A study typically passes through several iterations of refinement and can have several potential designs, depending on the parameters included in its protocol. These iterations of refinement can be modeled in Oracle Clinical as clinical study versions, each of which may be thought of as a potential protocol. The attributes that affect the design are held at the version level. When the protocol is finalized, you choose one of these versions to be the "live" version. Once live, you cannot change it or any other version of the study back to "not live." However, the live version can still be modified and developed.
Note:
RDC does not work with studies that have multiple study versions. Errors include (but are not limited to):selecting and using a patient when a patient with the same patient code exists in two or more study versions
selecting and using a clinical planned event when a clinical planned event with the same name exists in two or more study versions
To use RDC for a versioned study, delete the clinical study versions that are not live: Delete any associated items (such as patient positions and clinical planned events), associated with the clinical study version.
Setting the live flag on a study makes that version the one to use throughout the study. The study timeline, treatment patterns, stratification, and randomization can all be defined separately for each version of the study design.
From the Design menu, select Studies, then select Study Versions. The Maintain a Clinical Study Version window appears, listing all current clinical study versions appropriate for your privileges. The system displays the clinical study and version, if any, of your current session. You can select another, and you can query to modify the list.
Oracle Clinical's copy logic distinguishes between copying a clinical study version within a clinical study and copying from one clinical study to another. When you copy a version within a study, you are usually creating a new version, a checkpoint in the study design process, or recording a change to the protocol. Oracle Clinical produces an exact copy of all attributes of the version, including randomization.
However, when you copy a version from one study to another, you are usually designing a new study. For this reason, Oracle Clinical performs the copy so that it looks as if the data is new. The system resets the creation user and timestamp to the current user and date, and the modified user and timestamp values are set to null. The system also sets the blinded attributes of a randomization to their default values.
You can project the enrollment expectations for studies and their study sites within the Maintain Study and Study Site Plans window. Each plan records a planned start date, planned enrollment target, and planned target date (date for achieving the enrollment target). You can modify plans until you finalize them by selecting the Baselined? field. To change a baselined study's plans you must supersede them with new plans. Furthermore, once enrollment for a study or study site has begun, you can no longer modify the planned start date in original or later plans.
For tracking actual study progress against the plan, use the study tracking reports. Specify the plan for the study from the Maintain Study and Study Site Plans window. From the Design menu, select Studies, then select Study and Site Plans. Select a study and modify the enterable fields as necessary. If you want to permanently record the plan for a study, select the Baselined? box.
The Study Plans window contains information about the Enrollment Plan for the study, including the Planned Start Date, Planned Target Date, and Planned Enrollment. Check that the Planned Target Date is greater than the Planned Start Date and that the Planned Enrollment is greater than zero.
Oracle Clinical calculates value of the Actual Enrollment field; you cannot manually update the field in this window. Oracle Clinical determines the actual enrollment based on the number of patients with a status of ENROLLED as calculated by the Patient Status Derivation Packaged Procedure. The system also maintains the Plan # field, incrementing it by one each time you create a new plan.
Oracle Clinical also maintains the Effective Date and Superseded Date. The current plan always has an Effective Date reflecting the time when the plan was created, and a Superseded Date of 15-AUG-3501. This date far in the future indicates that the plan has not been superseded, and is in fact the current plan. A plan with a Superseded Date of any other value was superseded at that time.
Create a new study plan when you have already baselined (permanently recorded), a study plan, but need a new one to meet changed conditions. To create a new study plan, from the Design menu, select Studies, and choose Study and Site Plans for the Maintain Study and Study Site Plans window. Click the Create New Plan button. A new plan record appears, which inherits many of the values of the previous plan. The new record also has an incremented plan number (Plan #), a newly calculated Actual Enrollment value, and new Effective and Superseded Dates.
Each time you create a new plan, the system resets each of these fields to the current date: the Superseded Date for the old plan and the Effective Date for the new plan. It sets the Superseded Date for the new plan to 15-AUG-3501. Viewing the Effective and Superseded Dates fields of each of the study plans reveals the time periods over which the prior plans were effective.
Use this window to plan the enrollment details for a site. To maintain the records for a planned study site:
From the Design menu, select Studies, then choose Study and Site Plans, and click the Sites button. The Study Site Plans window appears.
Create site plans by clicking the Create Initial Plans button. Defaults from the values supplied in the study plan give the initial values for the site plans.
When new sites are added to the study after the planning process has started, create initial plans for the new study sites by clicking the Create Initial Plans button. As a result, Oracle Clinical creates plans only for study sites that do not yet have plans, and leaves existing plans untouched.
The actions you can perform in the study sites window are identical to the actions you can perform at the clinical study level.
You can set or review several study-level settings that control data definition and collection in the Maintain Study States window. From the Conduct menu, select Security, then select Clinical Study States. These are the settings:
Enable Data Entry? This box must be selected to enable data entry for the selected study.
Allow 1st Pass from Login? Select this box to enable data entry operators to directly access the first-pass data entry window after completing a CRF's login information.
Frozen? Indicates if the study is frozen at the data level. You perform this operation by running a batch job. (From the Conduct menu, select Security, then select Freeze Study.) This is a view-only field.
Second Pass Required? Select this box to force a study to complete second-pass data entry to complete data collection.
Enable CRF Page Tracking? Select this box to use Oracle Clinical's Page Tracking utility in a paper-based study. See "Using CRF Page Tracking".
You cannot select both Enable CRF Page Tracking? and Flex Study Enabled?.
VB Enabled? Select this box to enable the Data Extract subsystem's View Builder utility. (See "The View Builder's Structure".)
DCI Forms Definition Enabled? Select this box to enable DCI Forms definition for the selected study in the Definition subsystem. (See "Enabling DCI Forms".)
DCI Forms Entry Enabled? Select this box to enable collecting data in RDC Onsite.
Flex Study Enabled? Select this box if your study has an adaptive (or flexible) protocol. If you check this box, you can use the Enhanced DCI Books window to define rules that make specified CRFs and Intervals expected for a particular patient based on data collected for that patient at specified points in the trial. You cannot select both Enable CRF Page Tracking? and Flex Study Enabled?.
You can change this setting for an existing study if no Test or Production data exists (test data can have been entered and then deleted). If you change a study from flexible to nonflexible, the system ignores any rules defined for its DCI Book and you can no longer see them because the rules button in the Maintain Enhanced DCI Book window is inactive.
Note:
The Enhanced DCI Books window includes Start Page renumbering, copying, and navigational enhancements that are helpful in any study. Studies with Enabled CRF Page Tracking? checked cannot use the Enhanced DCI Books window; they must use the original DCI Books window.Studies with neither Enable CRF Page Tracking? nor Flex Study Enabled? checked can use Enhanced DCI Books, but the rule definition required for a flexible protocol is available only for studies with Flex Study Enabled? checked. See "Traditional and Enhanced DCI Books" for further information.
Key Template Specifies a key template for the Data Extract View Builder.
Template Domain Specifies the Key Template's Domain.
You can also set a number of default study-level data entry settings from the Maintain Study Configuration window. From the Maintain Study States window, choose Special, then select DE Config. local database. The database-level settings are in effect unless you change them here; explicitly defined study-level settings override local settings, and user-level settings override both study and local settings. For many of these options, you can choose to enable them, disable them, or leave them in a "Not Set" state. In the Not Set state, the settings at the local database override settings here at the study level. These settings include:
Second Pass Comparison Failure Alert
Manual Discrepancy in Browse
Resolve Discrepancies in Data Entry
Privileged Update
List of Values for Thesaurus Questions
Univariate Failure Alert
Initiate DE Session Using DCI Book
Unhonored Patient Alert
Prevent Second-pass Entry by First-pass Operator
Browse Accessible Data Only
DCI and DCM Date Required
Default Height for Data Entry Page in DCM (character-based system)
Default Width for Data Entry Page in DCM (character-based system)
For more information on managing data entry configuration and user preferences, see the Oracle Clinical Administrator's Guide.
|
 Copyright © 1996, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
