3 Synchronizing Clinical Study Subject Information

This chapter provides an overview of the synchronization of Clinical Study Subject information between Oracle Clinical and Siebel Clinical and discusses:

• Section 3.1, "Overview"

• Section 3.2, "Clinical Study Subject Information Flow"

• Section 3.3, "Siebel Clinical Interfaces"

• Section 3.4, "Oracle Clinical Interfaces"

• Section 3.5, "Industry AIA Components"

• Section 3.6, "Integration Services"

3.1 Overview

After enabling patient integration for an Oracle Clinical study, the synchronization process can be initiated. In Oracle Clinical, patient positions are created for the target enrollment of a study and assigned to study sites based on the target enrollment for it. The enrollment date for a patient position indicates that a patient has been enrolled in the study and assigned an Enrollment ID. This creates a subject for the appropriate Protocol Site in Siebel Clinical and the subject is screened and enrolled against the active Subject Visit Template.

If data is collected for a patient position in Oracle Clinical or OCRDC and no enrollment date has been specified, the system assumes this to be a patient undergoing the screening process and assigns a Screening ID. This creates a subject for the appropriate Protocol Site in Siebel Clinical and will be screened against the active Subject Visit Template.

To create a subject in Siebel Clinical, the subject's initials and birth date are required. However, these are not required fields in Oracle Clinical and if the patient's initials are not available in Oracle Clinical, the Enrollment ID is used as the initials in Siebel Clinical. If the patient's birth date is not available in Oracle Clinical, it is set to Jan 1, 1800 in Siebel Clinical. This is an invalid date that can be used to identify subjects whose information has to be updated. You can manually enter the correct data in Siebel Clinical, if desired.

To assign an Enrollment Visit Template to a subject in Siebel Clinical, the date the informed consent was signed on is required. This date is optional in Oracle Clinical and if it is not entered, a default value of Jan 1, 1900 is entered in Siebel Clinical. This will alter the dates in the Visit Schedule for the subject and you may want to manually correct this in Siebel Clinical.

To assign a Screening Visit Template to a subject in Siebel Clinical the screen date is required. This is not a mandatory field in Oracle Clinical and if this date is not available, the subject's birth date is used in Siebel Clinical. This adversely impacts the dates in the subject's Visit Schedule and should be manually corrected in Siebel Clinical.

When a patient is enrolled in a study or begins the screening visit process, Oracle Clinical sends patient information to Siebel Clinical so that a subject may be created for the appropriate Protocol Site in Siebel Clinical. Oracle Clinical transfers the Study ID and Patient ID, which identify the patient along with the following information:

• Patient_Position_id

• Initials

• Sex

• Birth Date

• Informed Consent Signature Date

• Death Date

• StudySite the patient is assigned to

• Start Date of the patient assignment

• DCI Book assigned to the patient

• Frozen Flag

• Include in Efficacy Flag

• Include in Safety Analysis Flag

• Position Type (Screening, Enrollment, Replacement)

• Patient Dropped Flag

• Early Termination Flag

• Enrollment Date

• Exclude from Efficacy Reason

• Inclusion/Exclusion Date

• Exclude from Safety Reason

• Patient Reference

• Randomization Date

• Last Pregnancy Date

• First Screening Date

• Termination Date

• Patient Status History

This process flow is triggered by one of the following events:

• Specifying an enrollment date for a patient position in Oracle Clinical

• Entering the first CRF for a patient who does not have an enrollment date

• Updating information in any of the fields listed for an enrolled patient or a patient with collected data.

3.2 Clinical Study Subject Information Flow

This section provides the activity diagrams and functional descriptions for the Clinical Study Subject Information flow.

3.2.1 Flow Diagram

The following diagram shows the Clinical Study Subject information flow:

Figure 3-1 Clinical Study Subject Information Flow

Description of "Figure 3-1 Clinical Study Subject Information Flow"

3.2.2 Create Study Subject

The following list describes the Create Study Subject information flow:

1. When Patient Integration is enabled for a study and either the enrollment date is entered for a patient position or the first CRF is entered for a patient position with no enrollment date, Oracle Clinical writes a message (ABM) to the Clinical_Study_Queue Advanced Queuing (AQ).

2. The UpdateClinicalStudyOCAQConsumer consumer service picks the message and passes to the UpdateClinicalStudyOCHealthSciencesReqABCSImpl (requester ABCS).

3. The message will then be transformed into an UpdateClinicalStudyEBM and:

   1. The ClinicalStudySubject ID value is updated in the CLINICALSTUDY_CLINICALSTUDYSUBJECTID cross-reference table.

   2. The ClinicalStudySite identification is retrieved from the CLINICALSTUDYSTUDYSITE cross-reference table.

   3. The Clinical Subject status is retrieved from the ClinicalStudySubject_Status DVM table.

4. The UpdateClinicalStudyEBM is passed to the HealthSciencesClinicalStudyEBS (EBS).

5. The EBS uses the configuration routing rules to pass the EBM onto the UpdateClinicalStudySEBLHealthSciencesProvABCSImpl (provider ABCS).

6. The provider ABCS transforms the EBM into an ABM for the Siebel Clinical ClinicalSubject Web service and retrieves the following information during the transformation:

   • The Siebel Clinical ID for the Protocol Site from the ClinicalStudyStudySite cross-reference table.

   • The Siebel Clinical ID for the Subject from the ClinicalStudy_ClinicalStudySubjectId cross-reference table.

   • The Clinical Subject status from the ClinicalStudySubject_Status DVM table.

7. A synchronous call is made to the Siebel Clinical ClinicalSubject Web service; the ID of the newly created Subject is returned, which will then be added to the ClinicalStudy_ClinicalStudySubjectId cross-reference table.

3.2.3 Update Study Subject

The following list describes the Update Study Subject information flow:

1. When Patient Integration is enabled for a study in Oracle Clinical and information from the patient positions table, the patient_statuses table is changed or the patient position assignment to a study site is changed, a Clinical Study ABM is written to the Clinical_Study_Queue AQ.

2. The UpdateClinicalStudyOCAQConsumer adapter service picks the message and passes to the UpdateClinicalStudyOCHealthSciencesReqABCSImpl (requester ABCS).

3. The requester ABCS retrieves the following for populating the UpdateClinicalStudyEBM:

   • Clinical Study Subject identification from the ClinicalStudy_ClinicalStudySubjectId cross-reference table.

   • Clinical Study Site identification from the ClinicalStudyStudySite cross-reference table.

   • ClinicalStudySubject Status from the ClinicalStudySubject_Status DVM.

4. The message is then transformed into an UpdateClinicalStudy EBM and passed to the HealthSciencesClinicalStudyEBS (EBS).

5. The EBS will follow routing rules to pass the EBM to the UpdateClinicalStudySEBLHealthSciencesProvABCSImpl (provider ABCS).

6. The provider ABCS retrieves the following before transforming the EBM into an ABM for the Siebel Clinical Web service:

   • Siebel Clinical ID for the Protocol Site from the ClinicalStudyStudySite cross-reference table.

   • Siebel Clinical Row ID for the Subject from the ClinicalStudy_ClinicalStudySubjectId cross-reference table.

7. A synchronous call to the Siebel Clinical ClinicalSubject Web service is made.

These processes are part of a global transaction. Compensating steps will be taken if an error occurs at any point, which prevents the process completion.

3.3 Siebel Clinical Interfaces

The integration uses the following Siebel Clinical artifacts:

Table 3-1 Siebel Inbound Web Services

Name	Schema
ClinicalSubject	Clinical Subject Internal Integration Object

See Also:

Siebel Life Sciences Guide, Version 8.1, Rev. H for more information about Siebel Web Services.

3.4 Oracle Clinical Interfaces

Outbound from Oracle Clinical Event Interfaces:

Oracle Clinical writes Clinical Study ABM to the CLINICAL_STUDY_QUEUE AQ.

3.5 Industry AIA Components

The integration workflow uses the following components:

• ClinicalStudy EBO

• HealthSciencesClinicalStudyEBSV1

• UpdateClinicalStudyEBM

The industry EBO and EBM XML Schema Definition (XSD) files can be located by EBO within the following parent folder:

$AIA_HOME/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/Industry/HealthSciences/EBO/

The industry EBS Web Services Description Language (WSDL) files can be located by EBO within the following parent folder:

$AIA_HOME/AIAMetaData/AIAComponents/EnterpriseBusinessServiceLibrary/Industry/HealthSciences/EBO/

For detailed documentation of individual EBOs and EBMs, click the AIA Reference Doc link on EBO and EBM detail pages in Oracle Enterprise Repository or Oracle Clinical.

See Also:

Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack 11g Release 1, "Configuring and Using Oracle Enterprise Repository as the Oracle AIA SOA Repository", for more information about using the Oracle Enterprise Repository and configuring it to provide the AIA Reference Doc link.

EBOs can be extended, for instance, to add new data elements. These extensions are protected, and will remain intact after a patch or an upgrade.

See Also:

Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack 11g Release 1, "Understanding Extensibility".

3.6 Integration Services

These are the services delivered with this integration:

• UpdateClinicalStudyOCAQConsumer

  This is an AQ adapter consumer service that reads an XML message from the AIA_ClinicalStudyQ in the Oracle Clinical database. This service routes the ABM to the Requester ABCS, UpdateClinicalStudyOCHealthSciencesReqABCSImpl.

• UpdateClinicalStudyOCHealthSciencesReqABCSImpl

  This requester ABCS is responsible for transforming the Oracle Clinical ClinicalStudy ABM into an UpdateClinicalStudyEBM.

• HealthSciencesClinicalStudyEBS

  This EBS service is responsible for passing the message from the Requester ABCS to the Provider ABCS.

• UpdateClinicalStudySEBLHealthSciencesProvABCSImpl

  This Provider ABCS is responsible for transforming the UpdateClinicalStudyEBM into the appropriate ABMs to call the Siebel Clinical ClinicalSubject Web service.

See Also:

Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack 11g Release 1, "Configuring and Using Oracle Enterprise Repository as the Oracle AIA SOA Repository", for more information about using the Oracle Enterprise Repository and configuring it to provide the AIA Reference Doc link.