1 About Argus Interchange
Oracle Argus Interchange is an electronic submission and exchange module that enables the transmission of required ICH:E2B reporting functionality as well as the exchange of vital drug safety information with regulators and partners worldwide. Cases are reported instantly and accurately using standardized, worldwide reporting and transmission processes.
A color-coded graphical display provides peace of mind by delivering real-time insight into transmission status. Further, Argus Interchange is seamlessly integrated with Oracle Argus Safety, facilitating import, export, and transmission of cases. In addition, it supports immediate case triage upon electronic intake of data.
Argus Interchange provides the critical link to connect the pre-clinical and post-marketing safety information domains. This is the crucial component enabling pharma companies to communicate between their e-clinical and safety systems, delivering immediate return on investment gains. Argus Interchange will allow any standards-based systems (ICH:E2B to CDISC:ODM) to instantly exchange adverse events data. It thereby eliminates costly data entry redundancy and any possibility for introduction of errors.
Note:
The term E2B that is used in this document refers to E2B (R2), E2B (R3), eVAERS and E2B (R3)reports.1.1 Argus Interchange Process Overview
The following flowchart shows the steps to follow when using Argus Interchange.
The following table describes each of the steps in the preceding flowchart.
| Task | Description |
|---|---|
| Logging on | Explains how to log on to Argus Safety. |
| Schedule E2B Report | Explains how to schedule an E2B Report for a case using the New Expedited Report Dialog. |
| View E2B Report | Explains how to view a scheduled E2B Report in the ICSR Viewer and check for validation errors. |
| Transmit E2B Report | Explains how to transmit E2B reports by using the Bulk Reporting features in Argus Safety. |
| View Status | Explains how to view and understand the status of a transmitted E2B report. |
| View Acknowledgement | Explains how to view the detailed acknowledgement information from a trading partner or a regulatory authority. |
The following flowchart displays the steps to import E2B Reports through Argus Interchange:
The following table describes each of the steps in the preceding flowchart.
| Task | Description |
|---|---|
| Incoming E2B Reports | Explains how to view Incoming E2B Reports. |
| View E2B Reports | Explains how to view an Incoming E2B Report in the ICSR Viewer. |
| Duplicate Search | Explains how to search for possible duplicate cases in the Argus Safety system. |
| View Difference Report | Explains how to view differences between the current XML being imported (a message not yet imported into the database), the current case data in the database and the last imported case. |
| Accept/Reject | Explains how to accept or reject single/multiple E2B Follow-up/Initial reports. |
| View Process ICSR Reports | Explains how to view the Processed ICSR Reports. |
1.2 ICSR
ICSR is a a report that contains information describing a suspected adverse drug reaction related to the administration of one or more medicinal products to an individual patient.
E2B is the international standard for transmitting medicine adverse event reports specified by the International Conference on Harmonisation of Technical Requirements for Registration of Pharmaceuticals for Human Use (ICH).
1.2.1 Minimum Requirement for Electronic Report Generation
The minimum requirements (mandatory) for generating an ICSR report are as follows:
-
One identifiable patient - any one of several data elements is considered sufficient to define an identifiable patient (such as initials, age, sex)
-
One identifiable reporter - any one of several data elements is considered sufficient to define an identifiable reporter (such as initials, address, qualifications)
-
One adverse event/reaction (or outcome), and
-
One suspect or interacting drug
Reporting Destination can be configured with a message profile for E2B(R2), E2B(R3), eMDR or eVAERS report form.
E2B (R2) report contains the following information:
A: Administrative and Identification Information
A.1 - Identification of the case safety report
A.2 - Primary source(s) of information
A.3 - Information on sender and receiver of case safety report
B: Information on the Case:
B.1 - Patient characteristics
B.2 - Reaction(s)/event(s)
B.3 - Results of tests and procedures relevant to the investigation of the patient
B.4 - Drug(s) information
B.5 - Narrative case summary and further information
E2B (R3) and eVAERS reports are built using HL7 version 3 (V3) messaging standards with the following sections:
Section A:
C.1 - Identification of the Case Safety Report
C.2 - Primary Source(s) of Information
C.3 - Information on Sender of Case Safety Report
C.4 - Literature Reference(s)
C.5 - Study Identification
Section B
D - Patient Characteristics
E - Reaction(s)/Event(s)
F - Results of Tests and Procedures Relevant to the Investigation of the Patient
G - Drug(s) Information, and
H - Narrative Case Summary and Further Information
eMDR reports are built using HL7 version 3 (V3) messaging standards with the following sections:
A - Patient Information
B - Adverse Event or Product Problem
D - Suspect medical device
E - Initial Reporter
F - For Use by User Facility/Importer (Devices Only)
G - All manufacturers
H - Device manufacturers only
The following are the key features of reports in HL7 format:
-
Structure and Cardinality - Messages are built using Health Level 7 Version 3 (HL7 V3) messaging standard.
-
International Standard Code Sets - International Standard Code Sets are used in HL7 messages: ISO 5218, ISO 639-2, NCI and UCUM.
-
Null flavors - ICH ICSR uses the codes from the HL7 Messaging Standard to categorize exceptions. Null flavor such as NI, NA, UNK enables transmission of an empty element and provides an explanation for the reason for the lack of data using codes. Confidential information such as Patient or Reporter's name and address can be masked by the sender due to security, privacy or other reasons by using MSK Null flavor.
-
Attachments can be presented in-line within the ICSR message itself. In-line data is transmitted as part of the encapsulated data value in the ICSR message.