| Oracle® Device and Drug Adverse Event Data Integration Pack for Siebel Adverse Event Complaint Management and Oracle Argus Safety Implementation Guide Release 11.1 E26803-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Device and Drug Adverse Event Data Integration Pack for Siebel Adverse Event Complaint Management and Oracle Argus Safety Implementation Guide Release 11.1 E26803-01 |
|
|
PDF · Mobi · ePub |
This chapter provides an overview of synchronization of Siebel AECM Product Issue with Oracle Argus Safety System Case and discusses:
The synchronization automates the transfer of adverse event cases from Siebel AECM to the Oracle Argus Safety system. The synchronization feature is described in the following section:
Siebel AECM user enters an SR for the product complaint in Siebel AECM system when a customer calls the Call Center. The Siebel AECM user creates a Product Issue for the product complaint. The Siebel AECM user analyzes the Product Issue. If the adverse event is for a medical device or combination drug/medical device product, Siebel AECM user must select Event Type value containing the string device in the Language Independent Code (LIC).
For more information about how to set the Language Independent Code (LIC) in Siebel AECM, see Configuring Siebel Business Applications, Version 8.1, Rev. B,” Localizing Siebel Business Applications - Localizing a Multilingual List of Values”.
The Reportable field in the Product Issue List indicates whether the Product Issue is for a reportable adverse event or a potential reportable adverse event. The Send to Safety button is used to send the Product Issue information to the Oracle Argus Safety. Enabling and disabling of Send to Safety button is controlled by the values selected in Reportable field in the Product Issue List. Send to Safety button is enabled when the Reportable field is set to Yes or Potential.
When the Send to Safety button is pressed, an XML message is written by Siebel AECM to a JMS Queue on the SOA server. The Siebel ABM is transformed into the ReportDrugSafetyReportEBM.
There are two configurations on integration layer, which give control on sending additional non E2B fields from Siebel AECM:
SendNonE2B: (=true/false) property in AIAConfigurationProperties.xml, controls populating of non E2B, non device fields in the ReportDrugSafetyReportEBM. The following non E2B, non device fields of ReportDrugSafetyReportEBM are controlled by this property:
RegulatoryAuthoritySubmissionIndicationCode
DrugSafetyReportPatient/DrugSafetyReportReaction/SeverityCode
The default value for SendNonE2B property is false. If the SendNonE2B property value is set to true, Reported FDA and Event Severity fields in Siebel AECM are populated in the ReportDrugSafetyReportEBM.
SendDeviceFields: (=true/false) property in AIAConfigurationProperties.xml, and Siebel AECM Event Type field value containing string Device, controls populating of device fields in the ReportDrugSafetyReportEBM. The following device fields of ReportDrugSafetyReportEBM are controlled by this property:
Product Issue Product Model#
Product Issue Product Catalog#
Product Issue Product Serial#
Product Issue Product Device Operator
Product Issue Product Mfg Date
Product Issue Product Expiration Date
Product Issue Product Implant Date
Product Issue Product Explant Date
Product Issue Investigation Tab Evaluated by Mfg
Product Issue Product Device Available
Indicator of whether the device was labeled as Single Use and was Reprocessed and Reused on a patient
Product Issue MDV Tab Usage of Device
Product Issue Product Return Date
Product Issue MDV Tab Mfg Narrative
Product Issue Investigation Tab Remedial Action Type
Product Issue Investigation Tab Remedial Action Other
Product Issue Product Reprocessor
Product Issue Product Reprocessor Address
Product Issue Product Reprocessor City
Product Issue Product Reprocessor State
Product Issue Product Reprocessor Country
Product Issue Product Reprocessor Zip
Product Issue Investigation Tab Evaluation Codes Method Codes
Product Issue Investigation Tab Evaluation Codes Result Codes
Product Issue Investigation Tab Evaluation Codes Conclusion Codes
Product Issues MDV Tab Patient Code or Device Code
When Siebel AECM writes the message to the JMS queue, the Product Issue is updated with the Pending status. The adverse event data is sent to Oracle Argus Safety. The integration has its own DTD specification for Oracle Argus Safety. This includes the addition of some non-E2B fields in order to send device information and additional information that can be shared between Siebel AECM and Oracle Argus Safety. The integration writes an XML file that conforms to the DTD defined in the file - ich-icsr-v2.1-FDA-PIP.dtd
If Oracle Argus Interchange server is configured to auto accept the cases, the file is immediately imported and a new case is created in Argus Safety. If auto accept is not configured, the file is shown as a Pending E2B Report in Oracle Argus Safety; sorted by the Transmission date. The transmission date is the date when Siebel AECM sent the message to Oracle Argus Safety. The Oracle Argus Safety user can perform a search to see if a duplicate case exists and can choose to accept the report as a new case, or accept the report as a follow-up to an existing case or reject the case. Oracle Argus Safety writes an acknowledgement message. The case number is parsed out of an acknowledgement message and sent back to Siebel AECM, where the Product Issue is updated with the safety system case number, and the date the case was accepted or rejected in Oracle Argus Safety. The Product Issue status is updated to Submitted (or any other equivalent status value defined by you).
When the case ID is received from Argus Safety, follow-up information received by the call center can be sent in the same manner as for the new cases. Until the case ID is received from Argus Safety, any additional information sent by the call center is considered as a Potential New case. The Oracle Argus Safety user can choose to append the follow-up information to a different case in Argus. When this happens the Safety Case ID is updated for the Product Issue in AECM to reflect the new case it is appended to.
If the Oracle Argus Safety user rejects the case or the follow-up, a message is added to the Inbox of each product owner of the Product Issue and the Product Issue status is changed to Rejected (or any other equivalent status value defined by you). This message states that the Product Issue is rejected as a case in Oracle Argus Safety and includes the reason specified in the Oracle Argus Safety acknowledgement.
The call center can decide to void the case. This information is sent over in the same manner and the Oracle Argus Safety user has the option to accept or reject the nullification. The case is not deleted in Oracle Argus Safety even if the user accepts the nullification. The Oracle Argus Safety user must decide whether to delete the case in Oracle Argus Safety and then manually delete it.
For more information on entering Product Issues and sending them to the Oracle Argus Safety system, see Chapter 33: Setting Up and Configuring Safety System Integration, of the Siebel Life Sciences Guide, Version 8.1.1.6.
For more information about the Oracle Argus Interchange functionality refer to the Argus Interchange User's Guide, Release 6.0.1.
For more information related to Pending E2B Reports, see the Argus Safety User's Guide, Release 6.0.1.
This section describes the functional process flow and includes the flow diagram.
The following sequence diagram shows:
The flow of information through AIA components for the ReportDrugSafetyReport flow from Siebel AECM to Oracle Argus Safety
The flow of information through AIA components for the ReportDrugSafetyReportResponse flow from Oracle Argus Safety to Siebel AECM.
ReportDrugSafetyReport Flow:
Siebel AECM dispatches Adverse Event Product Issue information to Oracle Argus Safety. The three functional flows listed below are implemented with the two technical flows namely the Report Drug Safety Report Flow and Report Drug Safety Report Response Flow. Dispatch of adverse event Product Issue from Siebel AECM to Oracle Argus Safety covers the following three functional flows:
Initial: Dispatching new Adverse Event Product Issue information from Siebel AECM to Oracle Argus Safety system.
Follow-up: Dispatching updated Product Issue information from Siebel AECM to Oracle Argus Safety system.
Void: Dispatching an existing Product Issue that is voided from Siebel AECM to Oracle Argus Safety system.
Siebel AECM sends an XML message called Application Business Message (ABM) to a JMS queue on integration SOA server, when the Siebel AECM user clicks the Send to Safety button on the Siebel AECM Product Issue user interface. A JMS consumer, a mediator component on SOA server, reads the ABM from the JMS queue and routes it to the Siebel Requester Application Business Connector Services (ReportDrugSafetyReportSEBLReqABCSImpl). The Siebel Requester ABCS, a BPEL process on SOA server, transforms the Siebel ABM to the ReportDrugSafetyReport EBM. The Siebel Requester ABCS invokes the ReportDrugSafetyReport operation of HealthSciencesDrugSafetyReportEBS with ReportDrugSafetyReportEBM as the input message.
HealthSciencesDrugSafetyReportEBS, mediator component, routes the EBM to the Argus Provider Application Business Connector Service.
ReportDrugSafetyReportArgusProvABCSimpl, the Argus Provider ABCS converts the EBM to the format specified in the ich-icsr-v2.1-FDA-PIP.dtd file. This is an extension of E2B that is provided as part of this integration. The Argus Provider ABCS invokes a Write File Adapter service to write the XML file to the in directory of Oracle Argus Safety Interchange server. The Write File Adapter is a BPEL process which invokes the SOA File Adapter to write the XML files to the Oracle Argus Safety Interchange server. The file is then imported into Oracle Argus Safety. If Oracle Argus Safety is configured to auto-accept pending E2B reports, the case is created in Oracle Argus Safety. If not, the new case, the follow-up, or the nullification appears in the Pending E2B Reports in Oracle Argus Safety.
ReportDrugSafetyReportResponse Flow:
Oracle Argus Safety dispatches an acknowledgement to initial, follow up, and nullified reports. This information flows from Oracle Argus Safety to Siebel AECM. The acknowledgement files are generated for one of the following main reasons:
Acknowledgement file is auto-generated by Oracle Argus Safety when E2B import validation criteria are not met.
Acknowledgement file is generated when a safety user accepts or rejects a new case or follow-up in Oracle Argus Safety web application.
When a case is accepted or rejected in Oracle Argus Safety, an acknowledgement message is written to a directory on the Oracle Argus Safety Interchange server. A File Adapter service reads the acknowledgement file and passes it to the Requester ABCS, ReportDrugSafetyReportResponseArgusReqImpl. The File adapter moves the file to the archive directory after processing it. The filename has the conversation ID and a timestamp appended to it. The Requester ABCS transforms the acknowledgement message to the ReportDrugSafetyReportResponseEBM. The message is sent to the HealthSciencesDrugSafetyReportResponse EBS which routes it to the Provider ABCS, ReportDrugSafetyReportResponseSEBLProvABCSImpl.
The Provider ABCS updates the Product Issue in Siebel AECM with the Argus case ID, status (whether accepted or rejected) and the date on which safety system user accepted or rejected the case or the follow-up.
If the status is rejected, the Provider ABCS calls the Siebel web service to add a message to the Inbox of each owner of the Product Issue.
These Siebel AECM artifacts are used by this integration:
Siebel AECM Outbound and Inbound Web Services
Outbound - LSMedicalToSafetyIntegProductIssueInterfaceTarget
Inbound - LS_Medical_Product_Issue_Create_Inbox_Item_Inbound
Inbound - LS_Medical_Update_Product_Issue_Inbound
These Oracle Argus Safety artifacts are used by this integration:
Oracle Argus Safety Outbound and Inbound Web Services
Inbound - ich-icsr-v2.1-FDA-PIP.dtd (This DTD file defines the E2B+ XML message format for this integration.)
Outbound - FDA-icsrack-v1.1.dtd (This DTD file defines the Safety acknowledgement XML message format for this integration.)
The integration flow uses the following components:
DrugSafetyReportEBO
ReportDrugSafetyReportEBM
HealthSciencesDrugSafetyReportEBS
HealthSciencesDrugSafetyReportResponseEBS
This integration uses the DrugSafetyReportEBO.
This integration uses ReportDrugSafetyReportEBM and the response message that is sent back is ReportDrugSafetyreportResponse
The industry EBO and EBM XML Schema Definition (XSD) files can be located by EBO within the $AIA_HOME/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/Industry/HealthSciences/EBO/ parent folder.
The industry EBS Web Services Description Language (WSDL) files can be located by EBO within the $AIA_HOME/AIAMetaData/AIAComponents/EnterpriseBusinessServiceLibrary/Industry/HealthSciences/EBO/ parent folder.
For more information about using the Oracle Enterprise Repository and configuring it to provide the AIA Reference Doc link, see Oracle Application Integration Architecture – Foundation Pack: Development Guide, “Configuring and Using Oracle Enterprise Repository as the Oracle AIA SOA Repository”.
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.
For more information, see Oracle Application Integration Architecture – Foundation Pack: Integration Developer's Guide, “Extensibility for AIA Artifacts.”
These are the services delivered with this integration:
SEBLCLINDrugSafetyReportJMSConsumer - When the Siebel AECM user clicks the Send to Safety button, an XML message is written to a JMS queue, DrugSafetyReportSEBLQ, on the SOA server. This consumer service subscribes to that queue and read the messages and route them to the Siebel RequesterABCS - ReportDrugSafetyReportSEBLReqABCSImpl.
HealthSciencesDrugSafetyReportEBS - This service routes the ReportDrugSafetyReport EBM to the ReportDrugSafetyReportArgusProvABCSImpl.
HealthSciencesDrugSafetyReportResponseEBS - This service routes the ReportDrugSafetyReportResponse EBM to the ReportDrugSafetyReportResponseSEBLProvABCSImpl.
ReportDrugSafetyReportSEBLReqABCSImpl - The Siebel ABM is received and transformed into the ReportDrugSafetyReportEBM.
ReportDrugSafetyReportResponseSEBLProvABCSImpl - This service receives a ReportDrugSafetyReportEBM and calls the Siebel Web service LS_Medical_Update_Product_Issue_Inbound to update the Product Issue status, Safety System Case Number and Receipt date for the Product Issue. If the response code is rejected, it calls the Siebel web service LS_Medical_Product_Issue_Create_Inbox_Item_Inbound to add a message to the Inbox of each of the Product Issue owners.
ReportDrugSafetyReportArgusProvABCSImpl - This BPEL service uses a file adapter component to write an E2B+ file in Oracle Argus Safety specified directory location. The E2B+ format is defined for this integration in the DTD file ich-icsr-v2.1-FDA-PIP.dtd.
ReportDrugSafetyReportResponseArgusReqABCSImpl - This ABCS is invoked by a file adapter service that polls the Oracle Argus Safety directory to wait for an acknowledgement file to be written when the user accepts or rejects the Pending E2B report, or if the import fails. The case ID, safety received date, and rejection message are parsed from the error message in the acknowledgement message and sent back to Siebel AECM using the ReportDrugSafetyReportResponseEBM.
ReportDrugSafetyReportWriteE2BFileAdapter - This File Adapter service is used to write the XML file to the Oracle Argus Safety Interchange server.
ReportDrugSafetyReportReadAckFileAdapter - This service reads the acknowledgement message from the Oracle Argus Safety system directory, passes it to ReportDrugSafetyReportResponseArgusReqABCSImpl, and moves it to the archive directory underneath the out directory.
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
