| Oracle® Health Sciences Adverse Event Integration Pack for Oracle Health Sciences InForm and Oracle Argus Safety Implementation Guide Release 1.0.2 E49090-01 |
|
 Previous |
 Next |
| Oracle® Health Sciences Adverse Event Integration Pack for Oracle Health Sciences InForm and Oracle Argus Safety Implementation Guide Release 1.0.2 E49090-01 |
|
Previous |
Next |
This chapter provides an overview of Adverse Event: InForm and Argus Safety Integration and discusses:
This integration automates the sending of serious adverse event data from the EDC system, Oracle Health Sciences InForm, to the safety system, Oracle Argus Safety. The steps will differ based on the trial design.
However, the following will always happen. The Study Designer in Central Designer will define the items to be sent and the trigger to send the data. For more information, see Section 3.4.
Oracle Health Sciences InForm Publisher will monitor the InForm Trial database and send a message containing all the data items mapped in the Safety Logical Schema to the AIA layer. This message will include adverse events, concomitant medications, and labs that fall into the time frames specified in Oracle Health Sciences InForm Publisher. For more details, see InForm Publisher On Demand 1.0.2.0 Installation Guide. The AIA layer will transform the message to an E2B+ file. If auto-acceptance is configured in Argus, a case will be created. If not, the file will appear in the Pending E2B Reports screen in Argus.
Once the case is accepted or rejected either manually or automatically in Argus, the case ID, status, and rejection reason (if applicable) will be sent back to Oracle Health Sciences InForm. This last step is optional and can be disabled.
This section describes the functional process flow.
Depending upon the trial design, the steps to trigger the sending of data from Oracle Health Sciences InForm to Oracle Argus Safety will vary. The following is an example:
There is one form in the trial to collect Adverse Event information. This form includes all the serious information.
The form may include a check box field that indicates the serious or reportable adverse event is ready to be sent to safety.
Once the information is ready to report to safety, select the check box and submit the form. This triggers the sending of the safety data to Oracle Health Sciences InForm.
If you forget to select the check box, after a specified time frame configured in Oracle Health Sciences InForm Publisher for the trial elapses, the Oracle Health Sciences InForm Publisher sends the safety data even though the check box was not selected. Selecting the check box from this point will have no impact.
For more information, see Section 3.4.1.1.
There is some data that is pre-populated by the integration when sending the safety data. The following details are sent to Safety regarding the serious adverse event:
The full name of the user who marked the AE as serious or reportable. This user is considered the primary reporter of the case while sending the event details to Oracle Argus Safety.
The Site mnemonic concatenated with the site name will display as the institution of the reporter in Argus.
The name and address of the site where the subject experienced the adverse event is considered as the address.
Based on the above details, the Safety user searches for the Principal Investigator of that site where the serious adverse event had occurred and enters the details of the Principal Investigator as the primary reporter of the case in Oracle Argus Safety.
If qualification code for the reporter is not mapped to an item in the Safety Logical Schema or the value is not entered, the qualification code of the reporter will be sent as Physician.
The Initial Received Date is the date in the time zone of the site when the adverse event was marked as serious or reportable.
If the product name is not mapped in the Logical Schema, the value in StudySponsorDrug field in the trial database will be sent as the Product Name for the Drug and/or Device product. If this value is not entered and the product name is not entered on a form in Oracle Health Sciences InForm, the integration sends the string StudyDrug when any drug information is entered in Oracle Health Sciences InForm and StudyDevice when any device information is entered.
The integration will always send Reported from Study as the report type.
The subject number will be sent as the patient ID.
Oracle Health Sciences InForm Publisher sends this initial message to the AIA layer. The AIA layer generates an E2B+ file conforming to ich-icsr-v2.1-FDA-PIP.dtd, or ich-icsr-v2.1-PMDA_PIP.dtd based on the language settings. Language settings can be specified at individual trial level or at site level using Domain Value Maps in the AIA layer, which are discussed later in this document.
If the site or trial level language value is eng, or if the value entered for the country of the site in InForm does not map to the common value, JAPAN, in the Country DVM, then the AIA layer generates an E2B+ file conforming to ich-icsr-v2.1-FDA-PIP.dtd.
If the site or trial level language value is jpn, or if the value entered for the country of the site in InForm maps to the common value, JAPAN, in the Country DVM, then the AIA layer generates an E2B+ file conforming to ich-icsr-v2.1-PMDA_PIP.dtd.
If the language is not configured for trial and site, and if the value entered for the country of the site in InForm does not map to the common value, JAPAN, then default language value would be eng.
To populate language settings:
If the trial is being conducted entirely in Japan, and a country code is entered in InForm, ensure that the country entered in InForm for the site address follows a standard, and map the standard values to the common value Japan in the Country DVM.
If the site address country is not entered in InForm, or is not entered consistently in InForm, you can specify the language as jpn in the HS_TRIAL_SAFETY_CONFIG DVM.
If the trial is conducted in multiple countries, enter the value that applies to the majority of the sites in HS_TRIAL_SAFETY_CONFIG DVM, and then enter the other value for each of the sites that will collect in that language in the HS_SITE_SAFETY_CONFIG DVM.
For example, if most sites collects data in English, and a few sites collects data in Japanese, then enter eng for HS_TRIAL_SAFETY_CONFIG DVM, and enter each site that collects data in Japanese in HS_SITE_SAFETY_CONFIG DVM with language set to jpn.
The AIA layer writes the generated E2B+ file to the incoming directory on the Oracle Argus Safety server. The filename and message ID will be unique for each message.
If the mandatory fields required for Argus are not provided, Argus will automatically reject the case.
If the mandatory fields are provided and Argus is configured to automatically accept all E2B Reports, the case will be automatically accepted.
If the mandatory fields are provided and auto acceptance is not configured, the case will then show up in the Pending E2B Reports screen in Argus.
The Pending E2B Reports screen is sorted in the order the messages were transmitted by the sender.
As mentioned in the assumptions section, you must process these files in this order.
|
Note:
|
The Argus Safety user can perform the following actions:
Accept the case as a new case in Argus.
Search for duplicates and accept the case as follow-up into an existing case in Argus.
Reject the case and provide a reason (this would be very rare).
Oracle Argus Safety writes an acknowledgement file to the Argus ESM server. Optionally, the AIA layer reads this file and sends the status, case ID (if accepted), and reason for rejection (if rejected) back to the Oracle Health Sciences InForm Adapter Web service.
If Oracle Health Sciences InForm Adapter is used, the InForm Adapter web service updates the status of the serious adverse event, the rejection reason, and the Argus case ID, as provided by Oracle Argus Safety. This flow can be disabled and then the case ID, status, and rejection message will not come back to Oracle Health Sciences InForm
If Argus J module is enabled and Japanese data is sent from InForm to Argus Safety using the PMDA profile, then in order to accept follow-up from Pending E2B Reports, Argus Safety user should enter the following information on initial case form.
Go to Case Form > Events > Event Assessment tab, and click Recalculate button.
|
Note:
|
Navigate to Case Form > Analysis > PMDA > General tab, and for each product row enter:
License Category
Reporting Category
Reporting Category comments
If the case is not considered complete for PMDA reporting, then go to Case Form > Analysis > PMDA > Comments, select Product and enter Case Incomplete comments.
After a case is submitted to Oracle Argus Safety, additional information about the safety event can be entered or the existing information can be modified in Oracle Health Sciences InForm. This information can be entered in response to a request for follow-up or because more information was obtained by the site. It is important to report follow-up information to Oracle Argus Safety so that the safety team has the latest information. However, changes to insignificant items related to the case are not necessary to send to safety because too many follow-ups can hinder the review process. Therefore, you must indicate items that are significant and are required to be sent as a follow-up to the Oracle Argus Safety.
The safety system may receive information on a case from different sources. Therefore, the Argus Safety user can decide which follow-up information should be accepted into the case. You can use the Pending E2B reports screen of Oracle Argus Safety for this functionality. You can view the differences between the case in Oracle Argus Safety and the data coming in the XML file. You can select the changes to be accepted into Oracle Argus Safety and can select the ones that can be ignored.
A process is run at a time interval configured in Oracle Health Sciences InForm Publisher. This process checks if any of the items mapped to the Significant Data Series of the Safety Logical Schema have changed. If there is any change, a follow-up message is sent containing all the items mapped to the Safety Logical Schema and all the AEs, ConMeds, and Labs in the specified time frames.
Note that Logical schema mappings are not study version specific. If a protocol amendment or other reason for new study version occurs, the messages going to safety contains the fields that are currently mapped to the logical schema. Therefore, if a field had been collected and sent for a patient but is no longer being collected for the trial, it is not sent with the follow-up.
Oracle Health Sciences InForm Publisher sends this follow-up message to the AIA layer. The AIA layer generates an E2B+ file conforming to ich-icsr-v2.1-FDA-PIP.dtd, or ich-icsr-v2.1-PMDA_PIP.dtd based on the language settings. Language settings can be specified at individual trial level or at site level using Domain Value Maps in the AIA layer, which are discussed later in this document.
If the site or trial level language value is eng, or if the value entered for the country of the site in InForm does not map to the common value, JAPAN, in the Country DVM, then the AIA layer generates an E2B+ file conforming to ich-icsr-v2.1-FDA-PIP.dtd.
If the site or trial level language value is jpn, or if the value entered for the country of the site in InForm maps to the common value, JAPAN, in the Country DVM, then the AIA layer generates an E2B+ file conforming to ich-icsr-v2.1-PMDA_PIP.dtd.
If the language is not configured for trial and site, and if the value entered for the country of the site in InForm does not map to the common value, JAPAN, then default language value would be eng.
To populate language settings:
If the trial is being conducted entirely in Japan, and a country code is entered in InForm, ensure that the country entered in InForm for the site address follows a standard, and map the standard values to the common value Japan in the Country DVM.
If the site address country is not entered in InForm, or is not entered consistently in InForm, you can specify the language as jpn in the HS_TRIAL_SAFETY_CONFIG DVM.
If the trial is conducted in multiple countries, enter the value that applies to the majority of the sites in HS_TRIAL_SAFETY_CONFIG DVM, and then enter the other value for each of the sites that will collect in that language in the HS_SITE_SAFETY_CONFIG DVM.
For example, if most sites collects data in English, and a few sites collects data in Japanese, then enter eng for HS_TRIAL_SAFETY_CONFIG DVM, and enter each site that collects data in Japanese in HS_SITE_SAFETY_CONFIG DVM with language set to jpn.
The AIA layer writes the generated E2B+ file to the incoming directory on the Oracle Argus Safety server. The filename and message ID will be unique for each message.
If Argus is configured to automatically accept follow-up, the case will be updated with the new data. If not, the file will show up in the Pending E2B Reports screen in Argus.
|
Note:
|
The Oracle Argus Safety user can:
Accept the follow-up into the same case in Oracle Argus Safety.
Accept the case as follow-up into a different case in Oracle Argus Safety (This happens, if original case was closed as duplicate of another case and a new case is the current case for the corresponding event in Oracle Argus Safety).
Reject the follow-up and provide a reason.
Oracle Argus Safety user can accept the entire follow-up or select which updates to accept on a field basis. Oracle Argus Safety writes an acknowledgement file to the Argus ESM server. Optionally, the AIA layer reads this file and sends the status, case ID (if accepted), and reason for rejection (if rejected) back to the Oracle Health Sciences InForm Adapter Web service.
When Argus J is enabled and Japanese data is sent from InForm to Argus Safety, then Argus Safety user must enter PMDA data on Initial Case Form > Analysis > PMDA tab before follow-up can be accepted.
If Argus J module is enabled and Japanese data is sent from InForm to Argus Safety using the PMDA profile, then in order to accept follow-up from Pending E2B Reports, Argus Safety user should enter the following information on initial case form.
Go to Case Form > Events > Event Assessment tab, and click Recalculate button.
|
Note:
|
Navigate to Case Form > Analysis > PMDA > General tab, and for each product row enter:
License Category
Reporting Category
Reporting Category comments
If the case is not considered complete for PMDA reporting, then go to Case Form > Analysis > PMDA > Comments, select Product and enter Case Incomplete comments.
If Argus Safety user accepts a follow-up that does not have a reporter, event, product, or dosage regimen that exists in the current Argus case, this will not cause that information to be deleted from Argus. It is up to the Argus safety user to determine whether the information should be removed. Also, if mandatory information such as, the event description is blanked out in InForm, it will not be blanked out in Argus when the follow-up is accepted.
If an adverse event (AE) that was marked as Serious in InForm is changed to Not Serious, this will come over as regular follow-up, and then the Argus Safety user may decide how to proceed. However, InForm Publisher will no longer monitor this AE for follow-up changes since it is no longer a serious AE.
If Oracle Health Sciences InForm Adapter is used, the InForm Adapter web service updates the status of the serious adverse event, the rejection reason, and the Argus case ID, as provided by Oracle Argus Safety. This flow can be disabled and then the case ID and so on will not come back to Oracle Health Sciences InForm.
If the serious or reportable event that triggered the sending of the potential new case is deleted or cleared, a nullification message will be sent to Argus.
For example, if an SAE was entered for patient 123 instead of patient 456 by accident, the Oracle Health Sciences InForm user deletes the SAE for patient 123 and enters a new SAE for patient 456. The integration sends a nullification message to Argus for the SAE entered against Patient 123 and a potential new case message for the SAE entered for Patient 456.
The reason entered by the InForm user for deleting the SAE will be sent in the nullification message as the nullification reason.
Oracle Health Sciences InForm Publisher sends the nullification message to the AIA layer. The AIA layer generates an E2B+ file conforming to ich-icsr-v2.1-FDA-PIP.dtd, or ich-icsr-v2.1-PMDA_PIP.dtd based on the language settings. Language settings can be specified at individual trial level or at site level using Domain Value Maps in the AIA layer, which are discussed later in this document.
If the site or trial level language value is eng, or if the value entered for the country of the site in InForm does not map to the common value, JAPAN, in the Country DVM, then the AIA layer generates an E2B+ file conforming to ich-icsr-v2.1-FDA-PIP.dtd.
If the site or trial level language value is jpn, or if the value entered for the country of the site in InForm maps to the common value, JAPAN, in the Country DVM, then the AIA layer generates an E2B+ file conforming to ich-icsr-v2.1-PMDA_PIP.dtd.
If the language is not configured for trial and site, and if the value entered for the country of the site in InForm does not map to the common value, JAPAN, then default language value would be eng.
To populate language settings:
If the trial is being conducted entirely in Japan, and a country code is entered in InForm, ensure that the country entered in InForm for the site address follows a standard, and map the standard values to the common value Japan in the Country DVM.
If the site address country is not entered in InForm, or is not entered consistently in InForm, you can specify the language as jpn in the HS_TRIAL_SAFETY_CONFIG DVM.
If the trial is conducted in multiple countries, enter the value that applies to the majority of the sites in HS_TRIAL_SAFETY_CONFIG DVM, and then enter the other value for each of the sites that will collect in that language in the HS_SITE_SAFETY_CONFIG DVM.
For example, if most sites collects data in English, and a few sites collects data in Japanese, then enter eng for HS_TRIAL_SAFETY_CONFIG DVM, and enter each site that collects data in Japanese in HS_SITE_SAFETY_CONFIG DVM with language set to jpn.
The AIA layer writes the generated E2B+ file to the incoming directory on the Oracle Argus Safety server. The filename and message ID will be unique for each message.
If Argus is configured to automatically accept nullification, the case will be updated with the new data. If not, the file will show up in the Pending E2B Reports screen in Argus.
|
Note:
|
This nullification will show up in the Pending E2B Reports screen showing as Follow-up. The Argus Safety user will review the information in the message and update the case in Argus accordingly. They may or may not delete or close the case.
If they do accept or reject the case, nothing will happen in Argus Safety but the acknowledgement file will be written and the status will be sent back to InForm.
The Argus Safety user can only view the nullification reason by viewing the XML file in the pending E2B screen. The user can accept or reject the nullification file but this will not impact the case in Argus. It is up to the safety user to determine whether to delete the case in Argus.
As the Oracle Argus Safety user, you may want to view the Safety event information in Oracle Health Sciences InForm to find related data that are not sent from Oracle Health Sciences InForm. Oracle Health Sciences InForm sends a link that you can use to login to InForm and view the related data.
Once the case is accepted into Oracle Argus Safety:
Go to the Case Form and navigate to the Additional Information tab.
The URL is listed as a Reference ID in the list of references.
Copy and paste the URL shown in the Notes field into a browser.
A login screen is displayed.
After you login, if you have the access to view the form, the Safety Event form opens where you can view the safety event data.
Figure 2-1 illustrates the overview of the integration solution.
Figure 2-1 Overview of the Integration Solution
The InForm Publisher component sends XML messages by invoking InForm JMS Producer component on the integration layer using SOAP/http(s).
JMS Producer validates the trial name, and if the trial name is valid, it writes the message to JMS queue.
If the message is successfully added to the queue, the service sends a response back to the caller with http 202 response code.
If the message has been received, but was not added to the queue, the service raises a fault and sends a response back to the caller with http 500 response code.
JMS Consumer Mediator dequeues the message and routes it to the InForm Requester. InForm Requester transforms the InForm ABM to ReportDrugSafetyReport EBM.
HealthSciencesDrugSafetyReportEBS is an application independent web-service that provides mediation between requester and provider ABCS based on routing rules. The role of the Argus Provider ABCS is to interface between EBS and the Argus Safety application. It transforms ReportDrugSafetyReport EBM to E2B+ ABM. The actual interface with Argus Safety is file-based. Hence, a WriteFileAdapter service is used to write the E2B+ ABM to E2B+ file on Argus Interchange server and ReadFileAdaper service is used to read the acknowledgement file from Argus Interchange server.
The ReadFileAdapter sends the message to the Argus Requester ABCS which transforms it to the ReportDrugSafetyReportResponse EBM. The HealthSciencesReportDrugSafetyReportResponse EBS routes the message to the InForm Provider ABCS which calls the InForm Adapter Safety Web Service to update the SAE or SE form with the status, Argus case ID (if accepted), and reason (if rejected).
The acknowledgement flow is optional and can be disabled.
The Integration uses the E2B+ interface of Argus Interchange. The following are the Oracle Argus Safety artifacts used by this integration:
Inbound to Argus interface dtds:
Inbound:
For FDA based profile: ich-icsr-v2.1-FDA-PIP.dtd
For PMDA based profile: ich-icsr-v2.1-PMDA_PIP.dtd
This DTD file defines the E2B+ XML message format. This DTD is shipped with the integration.
Outbound:
For FDA based profile: FDA-icsrack-v1.1.dtd
For PMDA based profile: icsrack-v1.1.dtd
This DTD file defines the Safety acknowledgement XML message format for this integration. This DTD is a part of the standard Argus install.
For more information, see Oracle Health Sciences Adverse Event Integration Pack for Oracle Health Sciences InForm and Oracle Argus Safety Installation Guide.
InForm Publisher and InForm Adapter are used to interface with InForm.
The Oracle Health Sciences InForm Adapter uses the SafetyService web service to update the form containing the serious adverse event information with the status of whether the Argus user accepted or rejected the E2B file, the case ID (if accepted), and reason (if rejected).
The communication between integration pack and Oracle Health Sciences InForm is done through SOAP/http(s).
Whenever Oracle Health Sciences InForm user selects a check box that SAE information is ready to be sent or a configurable time period elapses since a safety event is marked as serious or reportable, then the Oracle Health Sciences InForm Publisher component sends XML messages by invoking InForm JMS Producer component on the integration layer using SOAP/http(s).
JMS producer BPEL service writes to the JMS queue AIA_InFormDrugSafetyReportJMSQueue in binary format on integration pack SOA server. This queue is stored in an encrypted tablespace. It is internal to the integration pack and not exposed to Oracle Health Sciences InForm.
The following XSD file defines the format:
oramds:/apps/AIAMetaData/AIAComponents/ApplicationObjectLibrary/InForm/V1/schemas/InformToSafetyDrugSafetyReportEBO.xsd
The integration flow uses the following components:
DrugSafetyReportEBO
ReportDrugSafetyReportEBM
ReportDrugSafetyReportResponseEBM
HealthSciencesDrugSafetyReportResponseEBS
HealthSciencesReportDrugSafetyReportEBS
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.
EBOs can be extended, for instance, to add new data elements. These extensions are protected, and remain intact after a patch or an upgrade.
For more information, see Oracle Application Integration Architecture - Foundation Pack: Integration Developer's Guide.
The following are the services delivered with this integration:
InFormDrugSafetyReportJMSProducer - JMS producer BPEL service receives InFormtoSafetyDrugSafetyReport ABM and puts it into the AIA_InFormDrugSafetyReportJMSQueue in binary format (BytesMessage type).
InFormDrugSafetyReportJMSConsumer - JMS consumer mediator service consumes the InFormtoSafetyDrugSafetyReport ABM from the AIA_InFormDrugSafetyReportJMSQueue in binary format (BytesMessage type) and routes it to the ReportDrugSafetyReportInFormReqABCSImpl in XML format (Text Message type).
ReportDrugSafetyReportInFormReqABCSImpl - This BPEL service transforms the InFormtoSafetyDrugSafetyReport ABM to the ReportDrugSafetyReportEBM. The transformed ReportDrugSafetyReportEBM is passed to the HealthSciencesDrugSafetyReportEBS.
HealthSciencesDrugSafetyReportEBS - This mediator component routes the ReportDrugSafetyReportEBM to the ReportDrugSafetyReportArgusProvABCSImpl.
ReportDrugSafetyReportArgusProvABCSImpl - This BPEL service transforms the ReportDrugSafetyReportEBM to Argus E2B+ specification and passes it to the ReportDrugSafetyReportWriteE2BFileAdapter. Based on the language settings, the E2B+ file will either be produced following the ich-icsr-v2.1-FDA-PIP.dtd file, or the ich-icsr-v2.1-PMDA_PIP.dtd file.
ReportDrugSafetyReportWriteE2BFileAdapter - This BPEL service uses a file adapter component to write an E2B+ file in Argus Safety specified directory location.
ReportDrugSafetyReportReadAckFileAdapter - This BPEL service uses a file adapter service to read an acknowledgement XML file from Oracle Argus Safety specified directory location. After the file is processed, it is moved to the ack-archive directory on the Argus Interchange server.
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, status, and rejection message are parsed from the error message in the acknowledgement message and sent back to Oracle Health Sciences InForm using the ReportDrugSafetyReportResponseEBM.
This BPEL process reads an acknowledgement ABM and transforms it to the ReportDrugSafetyReportResponseEBM and invokes the HealthSciencesDrugSafetyReportResponseEBS.
HealthSciencesDrugSafetyReportResponseEBS - This mediator service routes the ReportDrugSafetyReportResponseEBM to ReportDrugSafetyReportResponseInFormProvABCSImpl.
ReportDrugSafetyReportResponseInFormProvABCSImpl - This BPEL service reads the ReportDrugSafetyReportResponseEBM and transforms it to Oracle Health Sciences InForm acknowledgement ABM and invokes the Oracle Health Sciences InForm Adapter Web service (SafetyService) that updates safety event case acknowledgement information in the InForm database.
|
 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|