| Oracle® Clinical Conducting a Study Release 4.6 Part Number A85201-06 |
|
|
View PDF |
| Oracle® Clinical Conducting a Study Release 4.6 Part Number A85201-06 |
|
|
View PDF |
This chapter contains the following topics:
The other windows under Security in the Conduct menu are documented as follows:
Clinical Study States are covered in "Maintaining Clinical Study States" in the Oracle Clinical Creating a Study manual.
Patient Transfers are covered in this manual in "Transferring Patient Data".
The Delete Study Information batch job is covered in this manual in "Batch Deleting Data".
This section contains the following topics:
After response data has been reviewed and cleaned, you may want to ensure that no one makes changes to it unless explicitly authorized. You may also want to prevent any new data from being entered for a particular study or study site, or by a particular Investigator.
Oracle Clinical includes two related mechanisms for data security: Freezing and Locking. These mechanisms are described below and contrasted in Table 9-1, "Comparison of Freezing and Locking Data".
Locking prevents changes to previously collected data except by users with privileged update. You can lock data collected in a particular RDCM or RDCI, or lock all data for which a particular Investigator is responsible in a single study, or all data in a study site, or all data for a range of patients or individual patient, or for a single event, DCI, or data accessibility date range. See "Locking Data".
After data has been locked, it cannot be unlocked. However, users with privileged update can modify locked data in Update or any other mode.
Freezing data prevents any further data from being entered for the unit frozen, and also locks data already collected for the unit. You can freeze data by the following units: study, Investigator (all study sites currently assigned to a single Investigator), study site, patient range, or individual patient. When you freeze a study, the system also freezes sites and patients for the study. The study-level lock excludes the study from any validation processing. See "Freezing Data".
Frozen units can be unfrozen by users with the necessary privileges, and new data entered (see "Unfreezing Studies, Study Sites, Investigators, and Patients"). However, collected data locked as a result of freezing remains locked and can be modified only by users with privileged update.
Table 9-1 Comparison of Freezing and Locking Data
| Characteristic | Freezing | Locking |
|---|---|---|
|
Unit affected |
Can freeze study, study site, all study sites currently assigned to one Investigator, patient range or individual patients. |
Can lock one or more RDCMs or RDCIs; can lock by Investigator, study site, patient range, individual patients, event range or single event, DCI name, or Data Accessibility Start and End Date. |
|
Cascade effect? |
Yes, subunits are frozen and patient data within frozen units is locked. |
No. |
|
Possible to undo? |
Can unfreeze. |
Cannot unlock. |
|
Data modifiable? |
No, but can unfreeze and then modify locked data via privileged update. |
Yes, by users with privileged update. |
|
Effect on future data collection |
Prevents future data collection for the unit frozen. |
No effect on future data collection. |
You can freeze and lock data by submitting standard PSUB batch jobs. You can also lock individual RDCIs and RDCMs manually.
Oracle Clinical includes two batch jobs for freezing clinical study units:
To freeze a study site, Investigator, or patient (range or individual), from the Conduct menu, select Security, then select Freeze. See "Freezing Data by Site, Investigator, or Patients".
To freeze an entire study, from the Conduct menu, select Security, then select Freeze Study. See "Freezing Data by Study".
When you freeze a unit, the system freezes all its subunits and locks all the previously collected data within the frozen unit. See "About Locking Data".
To freeze and lock data:
Enter information about the unit you want to freeze. Choose either Investigator, Study Site, or Patient (range or individual):
Investigator. Select an Investigator from the LOV to freeze all study sites for which this Investigator is the current Investigator.
Study Site. Select a site from the LOV to freeze all collected patient data in this study for this site.
Patient Range. Select the low and high ends from the LOV of a range of patients to be "frozen". Or enter either one without the other to freeze the data for a single patient.
To submit the job for immediate execution, click Submit Job.
To schedule the job to run in the future, click the Schedule button to enter the execution time and date.
Refer to the "Submitting batch jobs and reports" section of the Getting Started manual for additional information on running a PSUB batch job.
The Freeze Study and All Sites and Patients in the Study batch job operates on the study you have been working on. If you need to freeze a different study, choose Select Study from the Special menu.
When you freeze a study, all its sites and patients are also frozen.
There are no parameters to enter. To freeze the study immediately, click the Submit Job button. To schedule the job to run in the future, click Job Details and then Schedule, and enter a time and date on which to freeze the study.
Refer to the "Submitting batch jobs and reports" section of the Getting Started manual for additional information on running a PSUB batch job.
See "Freezing and Locking Data" for further information.
Before allowing any CRF to be logged in or any data to be entered or updated, Oracle Clinical checks the status of the study, Investigator, and patient, ensuring that all levels of data are unfrozen. If any levels of data are frozen, Oracle Clinical displays an error message and does not continue processing the update.
You can see whether data has been frozen in different locations in Oracle Clinical, depending on the frozen unit, or level:
To see if a study is frozen, from the Conduct menu, select Security, then select Clinical Study States, and look at the Frozen? flag for the study.
To see if a study site is frozen, from the Design menu, select Investigators and Sites, then select Study Sites, and look at the Frzn flag for the study site.
To see if a patient is frozen, from the Design menu, select Patient Positions, then select Patients, and look at the Frozen? flag for the patient.
Oracle Clinical includes two batch jobs for unfreezing:
To unfreeze a study site, Investigator, or patient (range or individual), from the Conduct menu, select Security, then select Unfreeze. See "Unfreezing Sites, Investigators, and Patients".
To unfreeze data for an entire study, from the Conduct menu, select Security, then select Unfreeze Study. See "Unfreezing a Study"
When you unfreeze, all collected data locked by the freeze remains locked. See "About Locking Data".
To unfreeze, you must start by unfreezing the largest unit that was frozen, and explicitly unfreeze each subunit. For example, if a patient is frozen because the study site to which the patient is assigned was frozen, you must unfreeze the study site as well as the patient.
Enter information about the unit for which you want to unfreeze data. Choose Investigator, Study Site, and/or Patient. Enter the low and high ends of the range to unfreeze a group of patients, or enter either a low or high value to unfreeze a single patient.
To submit the job for immediate execution, click Submit Job.
To schedule the job for future execution, click the Schedule button to enter the execution time and date.
Note:
If you are working in a flexible study and you unfreeze a patient whose Enhanced DCI Book was activated while the patient was frozen, run the expectedness calculation job manually from Special menu in the Enhanced DCI Book window; see Oracle Clinical Creating a Study.When you unfreeze a study, only the study itself is unfrozen. The study sites and patients remain frozen until you explicitly unfreeze them by selecting Security, and then selecting Unfreeze from the Conduct menu.
When you unfreeze a study, you can add new patients and data for those patients, but existing patients remain frozen unless you explicitly unfreeze them.
The Unfreeze Study batch job operates on the study you have been working on. If you need to unfreeze a different study, choose Select Study from the Special menu.
There are no parameters to enter. To unfreeze the study immediately, click the Submit Job button. To schedule the job to run in the future, click Job Details and then Schedule, and enter a time and date on which to unfreeze the study.
Refer to the "Submitting batch jobs and reports" section of the Getting Started manual for additional information on running a PSUB batch job.
Locked data cannot be modified except by users with privileged update. After data has been locked, it cannot be unlocked.
Oracle Clinical provides three methods for locking collected patient data:
To lock all collected data associated with a particular Investigator, study site, patient range (or single patient), clinical planned event, accessible date range, or DCI name, from the Conduct menu, select Security, then select Lock. See "Batch-Locking Data".
To lock one or more Received DCIs or Received DCMs—corresponding to one or more CRFs or portions of a CRF—from the Conduct menu, select Security, select Lock Received DCIs/DCMs. See "Manually Locking RDCIs and RDCMs".
In addition, when you freeze a study, Investigator, study site or patient, the patient data associated with that unit is automatically locked. See "Freezing and Locking Data".
To batch-lock data:
Enter information about the unit for which you want to lock data. Enter information for only one type of unit:
Investigator. Select an Investigator from the LOV to lock all collected patient data in this study for all the sites for which this Investigator is the current Investigator.
Study Site. Select a site from the LOV to lock all collected patient data in this study for this site.
Patient Range. Select the low and high ends of a range of patients from the LOV. Or enter either one without the other to lock the data for a single patient.
Clinical Planned Event Range. Select the first and last visit in a range of CPEs (visits) to lock data for all patients collected at those CPEs. Or enter either one without the other to lock data for a single CPE.
Accessible Data Range. Enter the first and last date in a range to lock all data that became accessible during that period.
Note:
Data is accessible when Data Entry is complete. If Second Pass Data Entry is not required in the study, data is accessible when First Pass Data Entry is complete for the RDCI or RDCM. If Second Pass Data Entry is required in the study, data is accessible when Second Pass is complete.To submit the job for immediate execution, click Submit Job.
To schedule the job to run in the future, click the Schedule button to enter the execution time and date.
Refer to the "Submitting batch jobs and reports" section of the Getting Started manual for additional information on running a PSUB job.
To lock data for one or more RDCIs—each of which corresponds to the responses to a CRF for a single patient at a single visit—or one or more of the RDCMs contained in a RDCI, do the following:
From the Conduct menu, select Security, then select Lock Received DCIs/DCMs.
Enter a query to retrieve the RDCIs you want to lock. It does not need to be an exact match; you can select RDCIs to lock from the query results.
For each RDCI you want to lock, select its Lock box.
Alternatively, to lock all the RDCIs that meet your query criteria, select Lock All Recs from the Special menu. The system locks all retrieved RDCIs, even if they are not in the visible portion of the window.
Alternatively, if you want to lock an RDCM, put the cursor on the RDCI that contains the RDCM you want to lock, click the Received DCMs button, and select Lock for the RDCM you want to lock.
Note:
Lock RDCMs only rarely. In most cases, locking the whole RDCI (or more data) is more useful.Save. This process may take a few minutes, depending on the number of RDCIs affected by the action. Click Exit to return to the main menu.
See "Freezing and Locking Data" for further information.
You can choose to require Second Pass Data Entry on a study-by-study basis. The Enable/Disable Pass 2 Required batch job changes the Pass 2 Required status for the currently selected study.
The consequences of changing this requirement in an ongoing study with existing data are:
If you require Pass 2 for a study with previously collected data, the collected data becomes inaccessible until Pass 2 Data Entry is completed.
If you disable Pass 2 Required for a study with collected data with Pass 2 complete, there is no change to data with Pass 2 complete. If there is any data with only Pass 1 complete, it becomes accessible.
To enable or disable Pass 2 Required for a study:
From the Conduct menu, select Security, then choose Enable/Disable Second Pass Required. The Enables Disables Second Pass for a study window opens.
If you have not selected a study during this Oracle Clinical session, the study window also opens.
If you do not have a study currently selected, or you want to change the Pass 2 Required setting for a study other than the one you have currently selected, choose the study you want to change.
The window populates the Second Pass Reqd? (Y/N) field with the Pass 2 Required behavior that will take effect when you run this job. If this field is Y, Second Pass is not required for the selected study, but it will be after you submit the job.
Submit the job.
|
 Copyright © 1996, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
