Using Standard Replication

Review of Setting Up Standard Replication

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 Setting Up Replication.

Parent topic: Using Standard Replication

Replicating a Global Library

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.

Parent topic: Using Standard Replication

Replicating Study Designs

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.

For more information , see:

Parent topic: Using Standard Replication

Replicating the Design of a Clinical Study

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:
1. 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.
2. 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.

Parent topic: Replicating Study Designs

Creating a Local Configuration for the Replicated Study

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.

Parent topic: Replicating Study Designs

Replicating a Study Definition

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:
1. 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.
2. 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.

Parent topic: Using Standard Replication

Replicating Data

Data replication includes investigators, sites, patient positions, and patient data. Optionally, data replication can include discrepancies and associated data clarification forms (DCFs).

For more information, see:

Parent topic: Using Standard Replication

What Does Oracle Clinical Include in Data Replication?

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 OCL_INSTALLATION Installation Codelist

Parent topic: Replicating Data

Tracking the Execution of Data Replication

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.

Parent topic: Replicating Data

Invoking Study Data Replication

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.

Parent topic: Replicating Data

Managing Data at Multiple Locations

Only locally owned data can be modified at any given location, and changes to the study definition should be applied uniformly at each location.

Integrity

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.

Consistency

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.

Consistency and Data Extract

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.

During both incremental and full replication, the system preserves local language translations for the Global Library, study design, and study definition.

Parent topic: Replicating Data

Replicating Lab Information

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 the following table for details.

Table 13-2 Lab Information and Management Location

Information Set	Location Relationship
Lab units, lab panels, textbook ranges, and all related information	Maintained centrally at Global Library-owning location; replicated to all Global Library-sharing locations in the Oracle Clinical installation
Labs and lab ranges	Maintained at the location responsible for lab; replicated to any location that has replicated study data referencing the lab
Lab assignment criteria	Maintained separately at each location; not replicated

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.

For more information , see:

Parent topic: Using Standard Replication

Replicating the Global Lab Information

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.
Click Exit to end the function and return to the main menu.

Parent topic: Replicating Lab Information

Replicating Labs and Lab Ranges

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.

Parent topic: Replicating Lab Information

Replication and Frequency

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.

Parent topic: Using Standard Replication