| Oracle® Clinical Administrator's Guide Release 4.6.2 E18818-02 |
|
|
PDF · Mobi · ePub |
| Oracle® Clinical Administrator's Guide Release 4.6.2 E18818-02 |
|
|
PDF · Mobi · ePub |
This section describes how to use standard replication and disconnected replication in your Oracle Clinical distributed study installation.
The Oracle Clinical replication concepts that apply to standard replication apply to disconnected replication as well. This section assumes you are familiar with the terms and concepts required to conduct a clinical study in a distributed environment or installation. For more information, see Chapter 13, "Conducting Studies in a Distributed Environment."
This section includes the following topics:
Figure 14-1 illustrates a sample installation configuration for an Oracle Clinical study that is distributed over three physically separate locations.
In this installation:
One study is being conducted at the investigation sites, that is, Hospital A, Hospital B, Hospital C, and Hospital CA.
Location A is the Global Library-owning location.
Location C is the study-owning location.
Location A and Location B are study-sharing locations.
Location A Maintains Global Information
As the Global Library-owning location, Location A is responsible for maintaining Global Library objects, and global lab information (lab units and panels).
Location C Replicates the Global Library
Location C, which is the study-owning location, is responsible for designing the study and defining study elements. Before beginning the study design and definitions, Location C must replicate the Global Library from Location A. To complete the study definition, Location C may need the global lab information as well. The heavy black arrow between Location C and Location A represents this replication task.
Sharing Locations Replicate Study Design and Definitions
Once Location C completes the study design and definitions, and makes the study available for replication, then the other locations (Location A and Location B) must replicate these study elements from Location C. The heavy gray arrows from Location C to both Location A and Location B represent this replication task.
Location A and Location B cannot modify any of the study design or definition elements. However, these locations must maintain certain local responsibilities such as assigning sites and investigators.
Local Processing and Lab Replication
Each location in the installation deals with local facilities to conduct their part of the study.
Location A conducts investigations at Hospital A and processes results at Lab A. Likewise, Location B conducts investigations at Hospital B and processes results at Lab B. Each of these Oracle Clinical locations is a lab-owning location for its local lab.
Location C has two hospitals serving as investigation sites, but this setup has no ramifications for replication. However, the lab setup at Location C does have an effect on replication. Location C is the lab owner for Lab Central, which services Location C and also processes some tests for the other locations. As part of its lab owning responsibility, Location C maintains the lab ranges for Lab Central. Because the other locations (Location A and Location B) use Lab Central, they must replicate the ranges for Lab Central from Location C. The dotted-line arrows from Location C to both Location A and Location B represent this replication task.
Figure 14-1 Sample Installation with Three Physically Separate Locations
Table 14-1 summarizes the roles and responsibilities for each location (Location A, Location B, and Location C) in the sample Oracle Clinical distributed study.
Table 14-1 Summary of the Roles and Responsibilities for Each Location in the Sample Installation
| Location | Roles | Responsibilities |
|---|---|---|
|
Location A |
Global Library owner |
Maintain Global Library objects Maintain global lab information—lab units and panels Maintain textbook ranges |
|
Lab owner (Lab A) |
Maintain lab units Maintain ranges for this lab |
|
|
Study-sharing location |
Replicate study design |
|
|
Replicate study definition (initial) |
||
|
Replication study definition (periodic) |
||
|
Lab user (Central Lab) |
Replicate lab range information |
|
|
Location B |
Non-Global Library owner |
Replicate Global Library (initial) |
|
Replicate Global lab data (initial) |
||
|
Replicate Global Library (periodic) |
||
|
Replicate Global lab data (periodic) |
||
|
Lab owner (Lab B) |
Maintain lab units Maintain ranges for this lab |
|
|
Study-sharing location |
Same as Location A |
|
|
Lab user (Central Lab) |
Same as Location A |
|
|
Location C |
Non-Global Library owner |
Same as Location B |
|
Lab owner (Central Lab) |
Maintain lab units Maintain ranges for this lab |
|
|
Study-owning location |
Replicate Global Library (initial) |
|
|
Replicate Global Library (periodic) |
A study-owning location has responsibility for the design and definition of a study. For the tasks involved in designing and defining a study, see Oracle Clinical Creating a Study.
This section describes the following elements of conducting a study that directly relate to replication:
Patient positions
Investigators
Sites
Defining patient positions is part of defining a study. In defining patient positions, the study-owning location declares which location owns each patient position. You can change ownership later to a different location, as long as no data has been associated with the position.
The process of changing the location of patient positions has two parts:
The owning location must change the ownership.
The receiving location must replicate, or retrieve, the patient positions.
When you create patient positions, you can define the patient positions as screening, normal, or replacement.
To change the ownership of any type of patient position:
Navigate to Design, Patient Positions, and then select Change Ownership.
The system displays a list of all studies. Select the study for which you want to change patient positions.
Click Change Owning Location.
Complete the fields in the Change Patient Position Owner window as follows:
In the Location to own Patients field, enter the name of the location that is to receive ownership of the set of patient positions.
If you are not the study owner, you can only change ownership back to the study-owning location.
In each Number To Update field, enter the number of patient positions you want to process for each patient type. Note that you can process one, two, or all three types of patient positions (screening, normal, and replacement) by entering a number into the respective Number To Update field.
In the Start patient-position Patient fields, enter the patient number to start with when changing the ownership. You can enter a starting number for each type of patient position (screening, normal, and replacement).
Click Change Owning Location to change the ownership.
After the study design is next replicated, the new owner will have control of these patients. The owner will be able to maintain their details, assign them to study sites, and enter data for them.
In a distributed study, the study-owning location controls the assignments of all patient positions. If a patient position currently owned by a sharing location must change ownership, the study-owning location must reclaim, or retrieve, ownership of the patient position first.
The study-owning location can reclaim ownership of a patient position from any sharing location provided no data has been entered for the patient.
To retrieve patient positions:
Navigate to Design, Patient Positions, and then select Retrieve Patients.
Complete the fields in the Replicate a Clinical Study window as follows:
In the Source Study Code field, select the study that currently owns the patient positions. The list of values includes only those studies that are available for replication and that are owned by the current location. If only one study is available, the system automatically populates the field for you.
Once you specify the source study code, the system automatically populates the Source Study Title field for you.
In the Retrieve Patient From field, select the source location. The available locations are based on the active locations defined in the SOURCE LOCATION CODE installation codelist.
Click Retrieve Patients.
Oracle Clinical processes and reclaims ownership of the specified patient positions provided no data has been entered for the patients.
Each study-sharing location assigns sites to the study and assigns investigators to those study sites. You cannot collect patient data without a study site and an assigned investigator.
Investigator and site names must be unique across all locations in the installation. Investigator and site information is replicated as part of data replication.
Replication imposes constraints on design activity at the study-owning location. Although a few exceptions exist (see sections below), you cannot delete the following once they have been replicated:
Patient positions
Clinical study
Clinical study versions
Clinical planned events
Treatment assignments
The study-owning location creates patient positions and assigns them to various sharing locations. In general, you cannot alter patient positions after they have been assigned to a sharing location, except in the following circumstances:
The study-owning location can reclaim ownership of a patient position from any sharing location provided no data has been entered for the patient.
Sharing locations cannot exchange patient positions with each other directly. However, the study-owning location can retrieve patient positions from one sharing location and then reassign those patients to another sharing location.
The study-owning location can delete a patient position if it owns the patient position and if no data has been entered for the patient.
After randomized patient positions have been replicated, you cannot re-randomize them, but you can expand the randomization. After a randomized study has been replicated, you cannot re-randomize the study.
The study-owning location can perform all study design activities. Sharing locations can perform only the following study design activities:
Assign sites and investigators to the study
Assign patients owned by that sharing location to study sites
These activities are managed by the owning location of the patient position. This location may be a sharing location or the study-owning location, depending on which one owns the patient position.
The study-owning location is the only location that can replicate study data directly from all sharing locations. As the study data repository, the study-owning location must schedule replications of data from the sharing locations for the study.
The sharing locations can replicate only from the study-owning location. So, at any point in the conduct of the study, the sharing locations have available to them only the data replicated by the study-owning location from the various sharing locations, plus the data collected at the study-owning location itself.
As a study-owning location, if you receive study data from a lab owned by another location, you must replicate that lab and its ranges into your database.
A sharing location takes its design and definition for the study from the study-owning location. It can conduct a study, but cannot modify the study design or definition. It can replicate, from the study-owning location, copies of data collected at other sharing locations for the study.
Sharing locations receive their study design from the study-owning location. Every replication results in a fresh copy of the study design, including all new patient positions assigned to the sharing location.
A location that shares a study may also own studies itself. Every location can see the creation and maintenance screens in study design, however; a location cannot access studies it does not own via those screens, only via the query screens.
In general, a sharing location cannot modify the study design. However, a few exceptions to modifying the study design exist. At a sharing location, you can alter the study design as follows:
You can:
Assign patients owned by your sharing location to the appropriate study site
To perform any of these tasks, navigate to Design, Investigators and Sites, and then select Study Sites.
You can locally disclose the treatment pattern assigned to a patient and create a blind break.
To do this, navigate to Design, Randomization, Randomization Maintenance, and then select Disclose Patient Treatment Assignments.
You can locally maintain patient details using either of the following options:
Navigate to Design, Patient Positions, and then select Patients.
Navigate to Data Entry, and then select Patient Enrollment.
You can create and amend site plans for local study sites. To do this, navigate to Design, Studies, and then select Study and Site Plans.
Note:
When performing any of these study design activities at a sharing location, you see only the patient positions assigned to your location since the last time you replicated the study design.The study-owning location defines all the core elements of a study—DCMs, DCM question groups, DCIs, and so on. A sharing location receives these definitions by replicating the study design and definition from the study-owning location. Study definition replicated from the study-owning location is available to view read-only from the study-sharing locations.
If the study-owning location changes any definitions, a study-sharing location must perform an incremental replication of the study definition. Once the study-sharing location completes the replication, Oracle Clinical ensures that all changes to the study definition are automatically applied to the study data during the next batch validation. The same automatic re-validation and re-derivation that occur at the study-owning location occur at each study-sharing location.
Note:
After the first full replication of a study definition at a study-sharing location, the study-sharing location must insert a record into the CLINICAL_STUDY_STATES table for the study-sharing location.The study-sharing location can perform all study conduct activities, including:
At a study-sharing location, you can replicate study data from the study-owning location, but you cannot replicate study data directly from other sharing locations. Therefore, at any point in the conduct of a study, you have available only the data that the study-owning location has replicated from the various study-sharing locations, plus the data that the study-owning location has collected itself.
At a study-sharing location, when you replicate study data, you can elect to replicate the available data from one participating location (either another study-sharing location or the study-owning location) or from all participating locations (all study-sharing locations plus the study-owning location).
The options for replicating labs and lab ranges at a study-sharing location are the same as those at the study-owning location.
The value of the Flex Study Enabled? setting at the source location must match the value of the Flex Study Enabled? setting at the target location. If a mismatch occurs, the replication job fails. Oracle Clinical reports the errors as follows:
If a mismatch occurs during either a full or an incremental replication of a single study, the replication job completes with FAILURE. The output file contains the following error message:
Error: Flex Study Enabled flags do not match between source and target for study: study_name
When you submit a replication job, you can use the % wildcard character to replicate all studies. If a mismatch occurs during either a full or an incremental replication of multiple studies and if the mismatch occurs with more than one study, the replication job completes with SUCCESS. The failure text in the Batch Jobs window displays the following message:
COMPLETED WITH WARNING DUE TO FLEXSTUDY FLAG MISMATCH
In addition, the output file contains the following warning message:
Warning: Flex Study Enabled flags do not match between source and target for one or more studies. Please check Clinical Study States form. The Job completed with Warnings.
If a mismatch occurs during data replication of a study, the replication job completes with FAILURE. The output file contains the following error message:
Error: Flex Study Enabled flags do not match between source and target for study: study_name
To resolve these issues:
Log in to Oracle Clinical at the source location.
Navigate to Conduct, Security, and then select Clinical Study States.
Verify the value of the Flex Study Enabled setting.
Update the value at each target location accordingly.
Save your changes.
A study is available for replication only if its Ready to Repl check box is selected. In addition, only the study-owning location can designate when a study is ready for replication.
To enable a study to be available for replication:
Navigate to Design, Studies, and then select Clinical Studies.
Scroll to the right in the window.
Select the Ready to Repl? check box. See Figure 14-2.
Click Save.
Standard replication is a retrieving operation, that is, the location that requires the information must request it from the study-owning location. In managing replication, you must make sure that specific replications occur at consistent intervals and that you inform people when particular information is updated.
Standard replication has two options:
Full replication — A full replication replaces the rows of the local tables with the current contents of the source location's table. For study definitions, only the rows for the replicated studies are replaced; for Global Library tables, all rows are replaced.
Incremental replication — When incremental replication occurs, all operations (inserts, updates, and deletes) that have occurred on the source location's tables since the last replication are applied to the local database. Because only new and changed information is transferred, this minimizes the amount of information that must be transferred between locations over a network.
To set up standard replication, you must complete the following tasks:
Configure the SOURCE LOCATION CODE installation reference codelist
Configure the OCL_INSTALLATION installation reference codelist
Configure the OCL_STATE local reference codelist
Create and set up the private and public database links
Create the study design replication packages
For details about these installation tasks, see Chapter 13, "Conducting Studies in a Distributed Environment."
Standard replication of a Global Library supports both full replication and incremental replication:
A full replication of a global library replaces all existing Global Library information at a sharing location with information from the tables at the Global Library-owning location.
An incremental replication of a global library applies to the Global Library-sharing location only those operations (inserts, updates, and deletes) that have occurred at the Global Library-owning location since the last Global Library replication was performed at the Global Library-sharing location.
When using standard replication to replicate a Global Library, Oracle recommends that you execute a full replication initially, and incremental replications thereafter. You need to repeat the full replication of the Global Library only if the target library is corrupted.
To use standard replication to replicate a global library:
Select one of the following options:
To execute a full replication of a global library, navigate to Admin, Replication, and then select Full Library.
To execute an incremental replication of a global library, navigate to Admin, Replication, and then select Incremental Library.
You do not need to specify any input parameters to replicate the Global Library.
Click Schedule to open the Schedule Jobs window.
Define when you want the replication to occur.
Click OK to save your changes.
Click Submit Job to submit the batch job.
Click Exit to return to the main menu.
When you use standard replication to replicate a study design, Oracle Clinical performs a full replication of the design information for a single study from the study-owning (source) location. Study design replication includes all design information except randomization and blinding information.
Because you might not want to make all study definitions available for replication— perhaps they are incomplete or intended only for local use—you must explicitly enable a study to be available for replication.
To use standard replication to replicate a study design:
Navigate to Design, Studies, and then select Replicate Clinical Study.
Complete the following fields in the Replicate a Clinical Study window:
In the Source Location field, select a location from which to replicate a study design. The list of values includes only the active location codes defined in the SOURCE LOCATION CODE installation codelist.
In the Source Study Code field, select from the studies owned by the selected source location that are available for replication. Note that the field lists only those studies that are owned by the location you specified in the Source Location field and that are designated as ready for replication. See "Enabling a Study for Replication" for details.
Oracle Clinical automatically populates the Source Study Title field, the Target Study Code field, and the Target Study Title field.
Click Replicate Study. Oracle Clinical immediately begins the replication process.
Your terminal remains locked until the replication completes, which may take anywhere from a few minutes to several hours, depending on the size of the study design and the traffic on your network.
Every study, whether replicated or not, requires a record in the CLINICAL_STUDY_STATES table. Study design replication does not automatically create the record. Therefore, after you replicate a study design for the first time at a study-sharing location, you must manually create a record in the CLINICAL_STUDY_STATES table.
In addition, you can configure several study-level settings in the CLINICAL_STUDY_STATES table that control collection at the study-sharing location. When you save your changes, Oracle Clinical automatically creates study access accounts at the study-sharing location that are required to perform data extract.
To create the Clinical Study States record and configure the study-level settings:
Navigate to Conduct, Security, and then select Clinical Study States.
Select the study.
Select the configuration settings for this study.
Save your changes.
Once the study-owning location makes a study available for replication, you can replicate the study definition to a sharing location. The study definition includes the DCIs, DCMs, and Procedures, but not the received DCIs, received DCMs, responses, and discrepancies.
When you replicate a study definition, Oracle Clinical automatically replicates the Global Library before replicating the study definition to ensure that all Global Library information is consistent with references from the replicated studies.
Standard replication of the study definitions supports both full replication and incremental replication:
A full replication of a study definition replaces all the existing study definitions being replicated with a copy of the information from the study definition tables at the study-owning location.
An incremental replication of a study definition applies all operations (inserts, updates, and deletes) that have been performed on study definition tables at the study-owning location since the last replication.
To use standard replication to replicate a study definition:
Select one of the following options:
To execute a full replication of a study definition, navigate to Admin, Replication, and then select Full Study.
To execute an incremental replication of a study definition, navigate to Admin, Replication, and then select Incremental Study.
Complete the Current Value field for each parameter as follows:
For the Source Location Code parameter, select the code for the study-owning location. The list displays the active location codes from the SOURCE LOCATION CODE installation reference codelist.
For the List of Study names to be replicated parameter, select the study that you want to replicate. The list displays only those studies that are owned by the location you specified for the Source Location Code parameter.
You can also use the % wildcard to replicate one, several, or all studies owned by the specified source location.
Click Schedule to open the Schedule Jobs window.
Define when you want the replication to occur.
Click OK to save your changes.
Click Submit Job to submit the batch job.
Click Exit to return to the main menu.
Data replication includes investigators, sites, patient positions, and patient data. Optionally, data replication can include discrepancies and associated data clarification forms (DCFs).
This section includes the following topics:
When you initiate data replication, Oracle Clinical automatically:
Replicates data for all patients, including all data modifications since the last data replication.
Oracle Clinical moves, tracks, and commits the data one patient at a time to avoid single large transactions. This includes responses that change because a univariate validation criterion is modified, which causes the value to move from the exception value text to the response value text field.
Invocates incremental study definition replication, and if necessary, Global Library replication.
Replicates investigator and site information to ensure that all referenced information is present at the receiving location. This includes investigators, sites, study sites, study site roles, and patient position information.
In addition, data replication includes discrepancies and associated DCFs if the ALLOW_DISC_REPL parameter in the OCL_INSTALLATION codelist is set to Y. You set the ALLOW_DISC_REPL parameter at the Global Library-owning location only. See "Configuring the OCL_INSTALLATION Installation Reference Codelist for Replication" for more information.
Oracle Clinical uses the STUDY_REPLICATION_JOBS table to track the execution of a replication, along with information about the timing and completion status of each data replication for a study.
To invoke study data replication:
Navigate to Admin, Replication, and then select Data.
Select the study that you want to replicate.
Complete the fields in the Replication of all the Study Data window as follows:
Source Location Code — Enter the name of the location that owns the study definition.
Data Location Code — Enter a percentage sign (%) to replicate all available data stored at the study-owning location; or enter the name of a single location participating in the study to replicate the data from that location currently available from the study-owning location. This name could be any sharing location or the study-owning location, unless you are replicating from the study-owning location itself.
Refresh all data? — Enter Y to have Oracle Clinical examine and refresh all data. Enter N to have Oracle Clinical refresh only data that has changed since the last replication. Selecting N results in a large reduction in data volume and consequently, reduces the likelihood of greatly degrading performance.
Click Schedule to open the Schedule Jobs window.
Define when you want replication to occur.
Click OK to save your changes.
Click Submit Job to submit the batch job.
Click Exit to return to the main menu.
Only locally owned data can be modified at any given location, and changes to the study definition should be applied uniformly at each location.
Oracle Clinical enforces the integrity of distributed data by ensuring that each location can modify data and related information only for patients owned by that location. Oracle Clinical implements this integrity in the following activities:
Log-In — Only locally assigned patient positions can be entered or accessed.
Data Entry — Only locally assigned patient positions can be accessed, unless in browse mode.
Patient Enrollment — Only locally owned patient positions can be accessed.
Batch Data Load — Only locally owned patient positions can be loaded.
Discrepancy Management — A location has only its own discrepancies available in the local discrepancy database tables.
Data Freezing and Locking — A location can freeze and lock only locally assigned patients and their data and locally owned study sites. The study-owning location can freeze the study only after all locations with data stored at the study-owning location have frozen the study at their locations.
Batch Validation — Procedures and other validation activities are only applied to patients owned by the current location.
Investigator/Site — Each location maintains its own investigator and site assignments to the study; other locations can only view those assignments.
Site Plans — Each location creates and maintains its own site plans; the study-owning location maintains the study plan.
Data consistency means maintaining the correct relationship between the study definition and the data in the study. For example, data consistency guarantees that:
You cannot replicate data for a DCM question to a location that does not yet have the definition for that DCM question.
A modification to a DCM question's range at the study-owning location results in the re-validation of all data collected for that DCM question at all locations.
Making a Derivation Procedure provisional then active, after removing a derived question and placing its derivation in another Procedure, results in the correct sequence for deleting existing derived information and re-deriving the information at all locations.
To preserve this data consistency, Oracle Clinical:
Conducts an incremental replication to automatically update the study definition at the target location before replicating any data from the study-owning location.
Tracks and replicates information about changes to Procedures and derived information, and tracks the times of previous replications to ensure detection and application of changed definitions when batch validation is executed.
Data Extract poses the following special problems for distributed study data:
Data extract view maintenance does not correctly detect all changes to DCM definitions when run in incremental mode. Therefore, all sharing locations should run data extract view maintenance in full mode.
Stable and snapshot data extract views provide a consistent and unchanging view of data. However, when data from multiple locations is present in a study, you must be aware of these limitations:
Replication of data entered at a local time prior to a snapshot, or prior to the batch validation run that defines a stable view, causes data to appear in the view. Therefore, a view is truly stable only after all data entered before the time stamp defining the view is moved to the location with the views.
Replication of data whose own stable time stamp (Last Batch Run) is later than the local time stamp (which can arise due to time-zone differences) can cause data to be viewed where the derived information is inconsistent with entered information.
You can handle these limitations on a day-to-day basis by timing the replications. As long as you do not invoke replication during the day, stable views remain stable during the course of the day. Snapshot views will be stable as long as you ensure that all locations have been replicated before being used. As long as the local batch validation occurs later than the time stamp of the batch validation at the source location, no inconsistencies occur between entered and derived information in the stable views.
To ensure completely consistent and stable snapshot views—such as for interim analysis—you must ensure that following batch validation at each location serving as a source of data for the snapshot, no data is entered or modified for a time interval greater than or equal to the difference in time zones. A second batch validation run then establishes a second time stamp from which data modification activities can resume.
You can usually satisfy these constraints by scheduling the batch validation to run in the early evening and the replication to run in the middle of the night. You can then establish the second stability point by scheduling a second batch validation to run in the morning, prior to data entry resuming. The second batch validation does little processing because no data or definition changes need to be applied. This caution is necessary only if the data is to be accessed for reporting or other formal purposes through the stable or snapshot views.
Lab information distribution includes the global definition of lab units, lab panels, and related information, as well as the ability to share lab definitions and lab ranges among locations processing tests at the same lab.
The lab range system consists of three sets of information with different relationships in a distributed environment. See Table 14-2 for details.
Table 14-2 Lab Information and Management Location
The globally maintained lab units and panels information is maintained at the same location that maintains the Global Library. At all other locations, you can access only the query versions of the forms.
Global lab replication invokes full replication of the centrally maintained lab system information. No parameters are necessary to submit the replication batch job. Each time you execute global lab replication, Oracle Clinical copies to your location a fresh copy of all the information maintained in those tables from the location that maintains the global lab information.
To use standard replication to replicate global lab information:
Navigate to Admin, Replication, and then select Global Lab Info.
Note that no parameters are necessary to submit the replication batch job.
Click Schedule to define when you want the replication to occur.
Click Submit Job to submit the batch job.
Each location maintains its labs and lab ranges. These labs and lab ranges can then be used by studies run locally or at locations that are part of a distributed study. Lab identifiers must be unique across all locations.
If a lab, such as a central lab, is shared by multiple locations, you can maintain the ranges for that lab at one location and replicate to other locations for their use. Alternatively, you can separately identify and maintain the lab at each location. You can only update lab and range information for labs owned by your location.
To use standard replication to replicate labs and lab ranges:
Navigate to Admin, Replication, and then select Labs and Ranges.
Select the name of the location that owns the lab, and then click Submit Job.
This process updates the list of labs that are available to you from that location. In addition, for those labs for which you have previously selected the Replicate? check box, this process updates the lab and lab ranges information for the labs owned by the site from which you replicate.
Navigate to Labs, Labs, and then select Labs to open the Maintain Labs window.
Query for all the labs owned by the source location.
Review the status of the Replicate? check box for each lab.
The Replicate? check box indicates whether to replicate its ranges the next time you run lab and ranges replication. Therefore, note that:
The first time you replicate labs from a lab-owning location, the Replicate? check box is not selected for those labs.
For any lab created by the lab-owning location since the last time you ran labs and ranges replication, the Replicate? check box is not selected.
Process each Replicate? check box as follows:
If you want the ranges for a lab that did not have the Replicate? check box enabled, select the check box and then select Admin, Replication, and Labs and Ranges again to replicate its lab ranges from the lab-owning location.
If, for some reason, you no longer want to replicate the ranges for a particular lab, clear the Replicate? check box. That lab's ranges will not be replicated again until you re-select the check box.
Note that you can use the information in the Last Replication field in the Maintain Labs window to determine when the lab ranges were replicated.
You will likely want to adjust the frequency of replications according to what activities are occurring. For example, while a study-owning location is creating and modifying the study definition, it must maintain a frequent schedule of replications of the Global Library to consistently have the most recent definitions.
When a study definition is replicated, Oracle Clinical automatically checks to ensure that the Global Library information is up to date. If the information is not up to date, Oracle Clinical automatically invokes incremental replication of the Global Library before proceeding.
In addition, you must consistently schedule data replication to ensure that all locations in the installation have access to all study data. For example, you could schedule the study-owning location to replicate data from each sharing location every evening, and then before work starts at each location the following day, you schedule a time for each sharing location to replicate data from the study-owning location. Because replication is a PSUB job, you can schedule each job to occur at a regularly scheduled time every day.
Disconnected replication supports bi-directional replication between locations without relying on a network connection. Instead of transferring data real-time via a Wide Area Network (WAN), disconnected replication transfers data between locations via file transfer.
This section includes the following topics:
With disconnected replication, you begin by exporting data to a file. When you export data to a file, you can choose to include the following type of information:
Global Library
Global Labs (textbook ranges and conversion tables)
Labs
Study designs
Study definitions
Patient data
Study randomizations
You can choose to replicate the Global Library, Global labs, labs, study designs, study definitions, and patient data either separately or as a single unit.
For each of these areas, all the existing functionality of the full replication mode is supported. With each selected type, all data is replicated.
Any user with the following privileges can run disconnected replication:
RXC_ADMIN
RXC_SUPER
RXC_SUPER_NOGL
Disconnected replication supports full replication only. It does not have an incremental option like standard replication. Instead, each time you initiate another disconnected replication, Oracle Clinical creates a new copy of the source data. When you import and load the new source data to the target location, Oracle Clinical overwrites the existing data at the target location with the new source data.
If your installations are set up for standard replication, you can, however, use disconnected replication in conjunction with standard replication. For example, you can choose to use disconnected replication to initially populate a study, and then use full or incremental standard replication at any time.
There are several circumstances where disconnected replication offers a valuable alternative to standard replication. Disconnected replication:
Enables a Contract Research Organization (CRO) to conduct clinical trials on behalf of an Oracle Clinical sponsor without requiring that the sponsor be able to communicate via a direct network connection.
Can perform the initial transfer of large studies or of the Global Library in a network environment. You can then use standard replication (full or incremental) to maintain the Global Library and studies over the network.
Can act as a backup to standard replication when a major network failure occurs.
Can transfer large volumes of patient data when a study is being consolidated for analysis.
Because the export file may contain confidential information, you should implement the following security measures:
Impose strict controls over who can access the file
Make read access to the file available only to authorized disconnected replication users
Encode the file if you intend to transfer the file over a public network
Control and restrict access to backup copies and to all physical media
In practice, a sponsor can use disconnected replication to transfer files to and from a Contract Research Organization (CRO) in the following manner:
The sponsor uses disconnected replication to export Global Library non-study data and the definition of a study to the CRO.
The CRO imports the information and begins to collect data to perform a study.
The CRO uses data replication to export the study data back to the sponsor.
The sponsor imports the study data from the CRO and refreshes the data in the Oracle Clinical database.
To set up disconnected replication, you configure or verify settings in the SOURCE LOCATION CODE, OCL_INSTALLATION, and OCL_STATE codelists. For details, see the following topics:
"Configuring the SOURCE LOCATION CODE Installation Codelist for Replication"
"Configuring the OCL_INSTALLATION Installation Reference Codelist for Replication"
"Configuring the OCL_STATE Local Reference Codelist for Replication"
In addition, see Chapter 13, "Conducting Studies in a Distributed Environment" for information about distributing a read-only copy of study designs, definitions, and data to other locations in your installation.
To extract source data to an export file:
Navigate to Admin, Replication, and then select Disc Repl Export.
Oracle Clinical opens an Extract Data for Disconnected Replication window, which varies slightly depending on whether the location owns the Global Library for the selected database.
Note that the window includes the following parameters only if the location is the Global Library-owning location:
Include GLIB
Include GLIB Labs
Enter values for the parameters displayed in the Extract Data window. See "Defining the Extract Data Parameters" for details.
Click Submit Job to send the replication job to the Parameterized Submission (PSUB) utility for processing.
Alternatively, you can click Schedule to schedule the job for a particular date and time.
For additional information about using the Parameterized Submission (PSUB) utility to submit jobs, see Oracle Clinical Getting Started.
This section describes the values that you can enter for each parameter displayed in the Extract Data window.
Select the name of a specific target location or select ALL. Note that the available target locations are based on the active values in the SOURCE LOCATION CODE installation reference codelist. See Figure 14-3.
The value you select depends on the type of data you are replicating:
For Global Library, Global labs (textbook ranges and conversion tables), or lab data, select ALL to extract data for replication to multiple sites. Select the name of one target location to extract data for replication to a single site.
For study design, study definition, or patient data, select the name of one target location to extract data for replication to a single site.
Set to Y to include Global Library information in the exported file. Note that the Include GLIB parameter is available only at the Global Library-owning location.
Set to Y to include textbook ranges and conversion tables in the exported file. The replicated data includes the following information:
Textbook Ranges
LAB_PANELS
LAB_PANEL_QUESTIONS
LAB_TEST_QUESTION_UNITS
LAB_UNITS
LAB_UNIT_CONVERSIONS
PREFERRED_LAB_UNITS
PREFERRED_LAB_UNIT_GROUPS
Note that the Include GLIB Labs parameter is available only at the Global Library-owning location.
Enter the appropriate value depending on the type of data you are replicating:
For study design, study definition, or patient data, select the name of a study. When you select a specific study, you can use the exported file only at the one site specified in the Target location field.
Note that a study is available for replication only if its Ready to Repl check box is selected. See "Enabling a Study for Replication" for details.
For Global Library data, enter N/A.
Studies previously owned by the current location and now being given to the target location.
After you create an export file that contains the data from the source location, you choose how to transport the export file to the target location. For example, you can choose disk media, tape media, E-mail, or local area network (LAN).
The target location then imports (or loads) the data from the export file.
Note that you can import study data only if, at the time of data extract, the Global Library at the target location is the same as, or more recent than, the Global Library at the source location.
To receive data from a source location:
Navigate to Admin, Replication, and then select Disc Repl Load. Oracle Clinical displays the Load Data for Disconnected Replication window.
Enter the name of the export file to load.
Click Submit Job to send the job to the Parameterized Submission (PSUB) utility for processing.
Alternatively, you can click Schedule to schedule the job for a particular date and time.
For additional information about using the Parameterized Submission (PSUB) utility to submit jobs, see Oracle Clinical Getting Started.
Disconnected replication commits data to the target location incrementally — completely committing the Global Library, for example, before staging the Global Library labs.
Commits occur in the following order:
Global Library
Global Library labs
Labs
Study design
Study definitions
Patient data, on a per patient basis
It is possible to change the owner of a clinical study. To do this, the current owner updates the Owning Location field in the Maintain Clinical Studies form. Ownership actually transfers the next time the new owner initiates replication.
If the receiving location does not have an up-to-date copy of the study definition, an error message is issued when the owning location is changed. The new owner can not replicate the study until receiving an updated copy of the study definition.
The replication process that changes ownership also replicates the randomization in the study.
Table 14-3 list the tables that are replicated as a part of standard replication and disconnected replication.
Note:
The CLINICAL_STUDY_STATES table is not replicated as part of standard replication. Therefore, with standard replication, you must manually create a record in the CLINICAL_STUDY_STATES table. For more information, see "Creating a Local Configuration for the Replicated Study".The CLINICAL_STUDY_STATES table is replicated as part of disconnected replication.
|
ACTUAL_EVENTS |
DCM_LAYOUT_TEXT |
QUERIES |
|
BATCH_DCMQ_CHANGES |
DCM_QUESTIONS |
QUERY_DETAILS |
|
BLIND_BREAKS |
DCM_QUESTION_GROUPS |
QUERY_KEY_COLS |
|
BLOCK_DEFINITIONS |
DCM_QUES_REPEAT_DEFAULTS |
QUERY_WHERE |
|
CLINICAL_PLANNED_EVENTS |
DCM_SCHEDULES |
QUERY_WHERE_COLS |
|
CLINICAL_PLANNED_PROCESSES |
DISCREPANCY_ENTRIES |
QUESTIONS |
|
CLINICAL_PROCEDURES |
DISCREPANCY_ENTRY_REVIEW_HIST |
QUESTION_ATTRIBUTES |
|
CLINICAL_STUDIES |
DISCRETE_VALUES |
QUESTION_CATEGORY_RELATIONS |
|
CLINICAL_STUDY_HISTORY |
DISCRETE_VALUE_GROUPS |
QUESTION_GROUPS |
|
CLINICAL_STUDY_OBJECTIVES |
ENROLLMENT_PLANS |
QUESTION_GROUP_QUESTIONS |
|
CLINICAL_STUDY_STATES |
EXTRACT_MACROS |
QUESTION_SETS |
|
CLINICAL_STUDY_VERSIONS |
EXTRACT_MACRO_PARAMETERS |
QUESTION_SET_QUESTIONS |
|
CLINICAL_STUDY_VERSION_SIZES |
FACTORS |
QUES_MEDICAL_EVAL_QUALIFIERS |
|
CLINICAL_SUBJECTS |
FORMAT_MASKS |
RANDOMIZATIONS |
|
CLIN_STUDY_ENROLLMENT_CRITERIA |
FORMAT_MASK_COMPONENTS |
RANDOMIZATION_BLOCKS |
|
CLIN_ST_TERMINATION_CRITERIA |
FORM_LAYOUT_TEMPLATES |
RANGES |
|
COMBINED_TREATMENT_COMPONENTS |
HTML_DCIF_FIELD_VALUES |
RDCI_HISTORY |
|
COMPLEX_QUESTIONS |
INTERVAL_TREAT_REGIMEN_ASSIGN |
RECEIVED_DCIS |
|
COPY_GROUPS |
LABS |
RECEIVED_DCMS |
|
COPY_GROUP_DETAILS |
LAB_PANELS |
RECEIVED_PAGES |
|
CORRELATION_ITEMS |
LAB_PANEL_QUESTIONS |
RECEIVED_PAGE_HISTORY |
|
DAILY_DOSES |
LAB_RANGE_SUBSETS |
REFERENCE_CODELISTS |
|
DATA_CLARIFICATION_FORMS |
LAB_TEST_QUESTION_UNITS |
REFERENCE_CODELIST_VALUES |
|
DATA_EXTRACT_VIEWS |
LAB_UNITS |
REGIONS |
|
DCF_DISCREPANCIES |
LAB_UNIT_CONVERSIONS |
RESPONSES |
|
DCF_DISCREPANCIES_HIST |
OCL_DOSAGE_FORMS |
RESPONSE_LOBS |
|
DCF_PAGES |
OCL_INVESTIGATORS |
STANDARDS_AFFILIATIONS |
|
DCF_PAGE_ENTRIES |
OCL_ORGANIZATION_UNITS |
STRATA |
|
DCF_PRINT_STATUS |
OCL_PRODUCT_MASTERS |
STRATUM_COMPONENTS |
|
DCF_STATUS_TRACKING |
OCL_PROGRAMS |
STRATUM_TREATMENT_PATTERNS |
|
DCIS |
OCL_PROGRAM_PRODUCT_MASTERS |
STUDY_COMMENTS |
|
DCI_BK_RULE_TRG_DCIS_TGT_STAT |
OCL_PROJECTS |
STUDY_REPLICATION_JOBS |
|
DCI_BOOKS |
OCL_SITES |
STUDY_SITE_PATIENT_POSITIONS |
|
DCI_BOOK_CPES |
OCL_STUDIES |
STUDY_STRATIFICATION_FACTORS |
|
DCI_BOOK_DCI_CONSTRAINTS |
OCL_STUDY_REGIONS |
S_A_SET_ITEMS |
|
DCI_BOOK_EXPLODED_RULES |
OCL_STUDY_SITES |
TEMPLATES |
|
DCI_BOOK_INTERVALS |
OCL_STUDY_SITE_ROLES |
TEMPLATE_COLUMNS |
|
DCI_BOOK_PAGES |
PATIENT_FLEX_TRACKING |
TEMPLATE_INDEXES |
|
DCI_BOOK_PHYSICAL_PAGES |
PATIENT_POSITIONS |
TEMPLATE_INDEX_COLS |
|
DCI_BOOK_RULES |
PATIENT_POSITIONS_HISTORY |
TITRATION_STEPS |
|
DCI_BOOK_RULE_TGT_DCIS |
PATIENT_STATUSES |
TREATMENT_ASSIGNMENTS |
|
DCI_BOOK_RULE_TGT_INTERVALS |
PATTERNS |
TREATMENT_PATTERNS |
|
DCI_BOOK_RULE_TRG_DCIS_INST |
PLANNED_STUDY_INTERVALS |
TREATMENT_PATTERN_REGIMENS |
|
DCI_BOOK_RULE_TRG_DCIS_STAT |
PP_EXPECTED_CPES |
TREATMENT_REGIMENS |
|
DCI_FORM_CONDITIONAL_BLOCKS |
PP_EXPECTED_DCIS |
TREATMENT_REGIMEN_BY_RANGES |
|
DCI_FORM_VERSIONS |
PP_EXPECTED_INTERVALS |
TREAT_PATT_BLOCK_DEFINITIONS |
|
DCI_HTML_FORM_VERSIONS |
PREFERRED_LAB_UNITS |
UNIONS |
|
DCI_MODULES |
PREFERRED_LAB_UNIT_GROUPS |
VALIDATION_REPORTED_VALUES |
|
DCI_MODULE_PAGES |
PROCEDURES |
VIEW_QUESTION_MAPPINGS |
|
DCI_USER_ROLE_PRIVS |
PROCEDURE_DETAILS |
VIEW_RESTRICTIONS |
|
DCI_USER_ROLE_PRIVS_DCIS |
PROCEDURE_QUESTIONS |
VIEW_RESTRICTION_COLS |
|
DCMS |
PROCEDURE_QUESTION_GROUPS |
VIEW_TEMPLATE_QUESTIONS |
|
DCM_CONDITIONAL_BRANCHES |
PROCEDURE_TEXTS |
XMLP_DCIF_FIELD_VALUES |
|
DCM_LAYOUT_ABS_PAGES |
PROCEDURE_VARIABLES |
|
|
DCM_LAYOUT_GRAPHICS |
PROC_DET_VAR_USAGE |
|
|
 Copyright © 1996, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
