| Oracle® Study, Subject, and Visit Synchronization Integration Pack for Siebel Clinical and Oracle Clinical Implementation Guide Release 11.1 E36156-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Study, Subject, and Visit Synchronization Integration Pack for Siebel Clinical and Oracle Clinical Implementation Guide Release 11.1 E36156-01 |
|
|
PDF · Mobi · ePub |
This chapter discusses:
The Study, Subject and Visit Synch: Siebel Clinical – Oracle Clinical PIP integrates two complementary clinical technology applications.
This integration includes the following processes:
Study Site Coordination (including address, investigator, and so on)
Study Subject Coordination
Activity Completion Integration
The Study, Subject and Visit Synch: Siebel Clinical – Oracle Clinical PIP enables timely exchange of data between Oracle Clinical and Siebel Clinical. Information sent from Siebel Clinical, (for example, investigator and site details) automates the creation of a study site and eliminates the manual creation of a Site, Investigator, and Study Site. Information sent from Oracle Clinical, such as patient numbers and information related to the completion of Oracle Clinical items (Visits, DCIs, DCMs, Questions), facilitates efficient and accurate patient counts and activity completion tracking in Siebel Clinical. The automation of these processes ultimately provides the means to effect timely and accurate Investigator payments. It also aids accurate tracking and response to issues related to site performance and protocol adherence.
The general business process is as follows:
In Siebel Clinical, sites are created at a protocol level. Siebel Clinical sends protocol site information to Oracle Clinical, including address, investigator name, and site number. This information is used to automatically create or update Investigators, Sites, and Study Sites in Oracle Clinical.
When a patient has enrolled in a study or commences the screening visit process, Oracle Clinical sends information to Siebel Clinical about the patient to create a subject for the appropriate protocol site in Siebel Clinical. Subsequent updates to the patient are transmitted to Siebel Clinical, which then updates the patient in that system.
Siebel Clinical can schedule activities to be completed during patient visits, including the designation of a patient visit as an individual activity. Certain data collection tasks in Oracle Clinical may correspond to completion of activities in Siebel Clinical. For example, an ECG DCI in Oracle Clinical will correspond to a visit activity in Siebel Clinical. The collection or completion of a visit or specific sets of data within a visit in Oracle Clinical can be used to update the status of an activity in Siebel Clinical.
Table 1-1 describes some of the common terms used in this guide:
Table 1-1 Common Terms Used in this Guide
| Siebel Clinical Term | Oracle Clinical Term | Definition |
|---|---|---|
|
A document that describes the objective(s), design, methodology, statistical considerations, and organization of a trial. Within Siebel Clinical, protocol is synonymous with study. |
||
|
The organization with which the investigator on the study is associated. This entity is not associated with a Study. An account is not equivalent to a site in Oracle Clinical. In Siebel Clinical, the account includes all the locations of an organization. In Oracle Clinical, a site is a particular location where a clinical study can be conducted. However, in Oracle Clinical, you cannot include the same site in the study with different principal investigators. In Siebel Clinical, an account can belong to multiple protocol sites in a protocol with a different principal investigator assigned to each one. |
||
|
The physician or clinician responsible for conducting the trial. |
||
|
None |
An identifier in Oracle Clinical that is a placeholder for a real participant in a clinical study. Patient Positions are created, based on the target enrollment in a study and assigned to a study site. As each subject is enrolled or data is collected for that subject, a patient position will be assigned. |
|
|
Persons recruited by investigators that participate in the trial at a study site. |
||
|
The expected events (visit and activities or procedures) that are conducted throughout the course of the trial as specified in the study protocol. |
||
|
None |
The planned schedule of events for a particular subject at a site based upon the Subject Visit Template. Once the actual events occur the information in the Schedule is updated. |
|
|
None |
A set of parameters, defined in Oracle Clinical and based on visit, clinical planned event, received DCI, received DCM, or question(s) response(s), which can be used to assign a completion date to a Siebel Clinical activity. |
|
|
None |
Required procedures or tasks in the visit schedule in Siebel Clinical. |
This section provides an overview and discusses the following process flows:
During the study set up process, protocols are created in Siebel Clinical under a Program. Clinical Studies are defined in Oracle Clinical under a Program and Project. To utilize this integration, you must manually enter Study code from Oracle Clinical into the CDMS Study ID field of the corresponding protocol in Siebel Clinical. Once the CDMS study ID is entered, the Synchronize Activities Sites flag must be selected.
When a protocol site is created in Siebel Clinical and when it is ready to be shared with Oracle Clinical, the Activate for Synchronization check box is selected, which creates a study site in Oracle Clinical. All future updates to the protocol site will be sent to Oracle Clinical. If the principal investigator for the protocol site does not exist in Oracle Clinical, the system will create one.
The combination of the primary address and account assigned for the protocol site are considered as a site in Oracle Clinical. If this combination does not exist in Oracle Clinical, a new site will be created.
Figure 1-1 shows the Create or Update Study Sites flow:
Figure 1-1 Create or Update Study Sites Flow Diagram
In Oracle Clinical, patient positions are created for the target enrollment for a study and assigned to study sites based on the target enrollment for the study site. The enrollment date for a patient position indicates that a patient has been enrolled in the study and assigned this enrollment ID. This creates a subject for the appropriate protocol site in Siebel Clinical and the subject will be screened and enrolled against the active Subject Visit Template.
In Oracle Clinical or Oracle Clinical Remote Data Capture (OCRDC), if data is entered for a patient position and no enrollment date has been specified, it is assumed that the patient is undergoing the screening process assigned to this screening ID. This creates a subject for the appropriate protocol site in Siebel Clinical and the subject will be screened against the active Subject Visit Template.
Siebel Clinical requires the subject's initials and date of birth to create a subject. These are not required fields in Oracle Clinical. Therefore, if the patient's initials are not entered in Oracle Clinical, the enrollment ID populates the initials in Siebel Clinical. If the date of birth of the patient was not entered in Oracle Clinical, the default value of Jan 1, 1800 is used in Siebel Clinical. The user should recognize this date as invalid. You can enter the correct data manually in Siebel Clinical.
To assign an Enrollment Visit Template to a subject in Siebel Clinical, the date the informed consent was signed is required. Informed Consent Signature date is an optional field in Oracle Clinical, and if it is not entered Siebel Clinical assigns a default value of Jan 1, 1900. This will adversely impact the dates in the Visit Schedule for the subject and you must manually correct it in Siebel Clinical.
To assign a Screening Visit Template to a subject in Siebel Clinical, the screen date is required. However, this is not a required field in Oracle Clinical. Therefore, if this date is not entered in Oracle Clinical, the subject's birth date is used. This will adversely impact the dates in the Visit Schedule for the subject and you must manually correct it in Siebel Clinical.
Figure 1-2 Create or Update Study Subjects Flow Diagram
This workflow updates the completion date of Subject visits and Subject visit activities based on data entered into Oracle Clinical or OCRDC. To initiate this, the Study Manager and Data Manager should collaborate and determine what data must be completed in OCRDC for a visit or activity to be considered complete in Siebel Clinical. They must also decide how to determine the visit completion date in Oracle Clinical. Enhancements have been made to Siebel Clinical to indicate that multiple activities or visits share the same completion criteria. Enhancements have been made to Oracle Clinical to define the activity completion criteria in terms of Oracle Clinical data collection objects such as Data Collection Instruments (DCI), Data Collection Modules (DCM), or DCM questions.
After the Activity Completion criteria are defined, you can schedule a batch job to initiate a process that analyzes patient data to evaluate whether any visits or visit activities have been completed since the last time the process ran. If any activity completion criteria has been added or changed, all patient data will be analyzed.
This batch job sends messages regarding the completion date of either activities or visits or both, which updates the completion date and status of the associated activities, or visits for the appropriate Subject Visit schedule in Siebel Clinical.
Figure 1-3 Update Visit or Activity Completion Date and Status Flow Diagram
These are the solution assumptions and constraints:
The following are the assumptions:
For the Clinical Study Subject workflow integration to proceed, you must populate the enrollment date for a patient in Oracle Clinical. This can be done in various ways through the Patient Positions form. The enrollment dates can be loaded in Oracle Clinical data entry, by batch loading enrollment dates or using Patient Synchronization in a derivation procedure to populate the date from a CRF.
Investigators defined in Oracle Clinical may be used on any Clinical Study. The integration assumes that reassigning the principal investigator for a protocol site will not cause the investigator to be deleted from Oracle Clinical.
When a protocol site is deleted in Siebel Clinical, you may not want to delete the corresponding study site in Oracle Clinical. Hence, this is not currently part of the integration.
As patient data can be deleted and re-entered in Oracle Clinical, it will not be desirable to remove the subject in Siebel Clinical when the enrollment date was left blank or patient data was removed.
The following are the constraints:
Protocols are created in Siebel Clinical under a Program, and Clinical Studies are created in Oracle Clinical under a Program and Project. Therefore, mapping a Clinical study to a Protocol is not an automatic process and must be done manually.
The investigator address is not required in Oracle Clinical. The synchronization of investigators is a separate business process and the investigator address will not be populated in Oracle Clinical by this integration.
Unplanned visits in Oracle Clinical will not be associated with Siebel Clinical activities. Since no mapping will exist, Oracle Clinical will not be able to determine whether an unplanned activity has been completed or not.
Due to size limitations for Study Site code in Oracle Clinical, the Protocol Site Number cannot be longer than 10 characters. Oracle recommends that you incorporate this length restriction in your Siebel Clinical environment to avoid errors.
The changes to the investigator data (for example last name or phone number) will not be propagated to Oracle Clinical until some other data in the protocol site is changed or the investigator is assigned to another protocol site that is synchronized.
To create a site in Oracle Clinical, you need to specify the value for the State to be defined as a region within the region you specify for the Country. This restriction does not exist in Oracle Clinical User Interface.
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
