7 Import ICSR Reports

7.1.1 Import both E2B (R2) and E2B (R3) Messages

The ICSR Import functionality supports the import of both the E2B (R2) and E2B (R3) reports without any data loss of data conversions. To determine if the Sender agency is sending an (R2) or (R3) message, the application relies on the configured E2B profile for the receiving Agency in the Argus Console.

Once the application identifies the message type, the incoming message is processed in accordance with message type and the profile so that the respective data element mappings are executed to extract the data without any data loss.

The application provides the OOTB profile to import ICH, PMDA, EMA & FDA E2B (R2) message, and the EMA & PMDA E2B (R3) message.

7.1.2 ICSR Import Framework

ICSR Import framework for (R3) import has been designed to provide greater flexibility with respect to (R2) import. It facilitates the user in extending, configuring and customizing the Import profile in such a way that broader use cases for importing data leveraging the ICSR import framework can be met.

The Import framework has been designed to achieve more flexibility by extending, configuring and customization the profile for the following:

1. Extensible ICSR Profile framework: With the current ICSR (R2) framework, E2B+ allows the user to extend the profile elements. However, extending a profile using the existing Framework has certain limitations:

   • Linking of extended child with the Parent: If the element is added to the node which is lower in the report hierarchy, linking of the extended node becomes difficult with the higher level node.

     For example:

     Level 1: SAFETYREPORT

     Level 2: PATIENT

     Level 3: Drug

     Level 4: Dosage

     Now, if the user wants to extend an element at Dosage level using E2B+, then the linking of that attribute with the Drug becomes complex and at times could error prone.

   • Cannot add a new Parent/repeater: Using the current E2B+ framework it is not feasible to add a new repeater section that is not part of the standard E2B report.

2. Minimum Case creation validations on Incoming ICSR: MAH uses Argus Safety for capturing data from different sources to meet their regulatory and non-regulatory reporting needs. ICSR Import is a big platform for data capturing from various sources. MAH are expected to use Argus as an importing platform to pull the information from various sources in their Safety database and then further process it using Argus for coping with regulatory and non-regulatory purposes.

   Note:

   All the compliance validation is maintained in the error/warning log for user to review the regulatory gaps with the incoming ICSR file.

3. Import F/U on non-E2B compliant Case: The usage of the ICSR Import framework in not confined to regulatory purposes only - the purpose of the incoming ICSR file can be just the data exchange. Therefore, there can be a scenario where the case on which the ICSR is being imported may not be regulatory complaint but the user would like to import the update from the incoming ICSR. Therefore, the application will not execute the ICSR conformance validation check before importing the data from Follow-up ICSR.

4. Provide flexibility to user to map Incoming ICSR as Follow-up to the existing case: As the usage of the ICSR Import framework in not confined to regulatory purposes, the logic to link an incoming report to the report with an existing case is configurable at the profile level.

5. Comparison and data evaluation/update for an incoming Follow-up report: As per the current implementation for comparing the Incoming ICSR file, the application provides the user a three view difference in the ICSR format:

   • Newly imported ICSR message

   • ICSR message generated using the current case data against the ICSR profile for the importing agency

   • Last imported ICSR file to the case

   This comparison logic performs a record matching based on the metadata of the internal table by performing the key based comparison of the elements in the above three ICSR files. The comparison logic can be configured by modifying the internal metadata to a certain extent with several limitations. The existing comparison and data updation logic has been enhanced for the following:

   a Support deletion of unwanted data after F/U

   b Flexibility in Primary key identification for F/U records

   c Special use case to support comparison based on External applications entity Identifier

   d Customizable comparison and updation for handling exceptional use scenarios (User Exits)

For more details, from the Argus Safety OHC">>Argus Safety OHC page, download the Technical Reference Manuals, and refer to the >Oracle Argus Interchange ICSR Extensibility Guide.

7.1.3 Interchange Accept Process

This section is specific to the E2B (R3) Import.

The application function flow for importing (R3) based ICSR messages in the Interchange accept process is similar to that of the (R2) except for the updates specified in this section.

• The application supports importing of batch (R3) messages consisting of more than one report.

• The maximum file size allowed to be imported into Argus respects the value configured in Argus Console -> Reporting Destination -> EDI -> Allowed report size (in MB) for the receiving Agency.

• The Interchange Accept process performs the following validations on the incoming (R3) message:

  Hard Validation: In case of a validation error under this category, the Interchange Accept process rejects the incoming message and generates a negative ACK with the required error message. For more information on ACK mapping details, refer to the ACK element level mappings. The following are the categories of hard validations:

  1. Length validation

  2. Code list data validations

  3. Minimum case creation validation

  Soft Validation: In case of a validation error under this category, the Interchange Accept process does not reject the incoming message. Instead, the process maintains a log of errors under this category for future reference in the ICSR Pending screen (for more details, refer to the ICSR Pending screen) and in the Case Attachment (for more details, refer Case creation/updation section). The following are the categories of soft validations:

  1. Element Conformance validation

  2. Mandatory along with validation

  3. Additional validation

  The logic to identify the case over which the Incoming (R3) ICSR message is imported as a Follow-up is configurable at the profile level.

• The accept process loads all the data from the incoming (R3) based ICSR message to staging schema without any data loss.

• The application logic to identify the Agency whose profile configuration is used during the import of the (R3) based ICSR message is as follows:

  1. Reporting Destination'EDI'Agency Identifier: N.1.3-BATCHMESSAGESENDERIDENTIFIER / N.2.r.2 - MESSAGESENDERIDENTIFIER

  2. Reporting Destination'EDI'Company Identifier: N.1.4-BATCHMESSAGERECEIVERIDENTIFIER / N.2.r.3 - MESSAGERECEIVERIDENTIFIER

  3. Reporting Destination'EDI' Primary Receive Agency: Checked

• All the respective statuses that are applicable for the existing (R2) message have been updated for the (R3) message in a similar manner. These statuses can be tracked in various screen in Argus UI such as Reports > ICSR Pending (Pending & processed tabs) & Utilities > ICSR > ICSR Receive Status).

• Duplicate (R3) message identification is governed based on the value in the N.1.2 -BATCHMESSAGENUMB tag.

• The existing application to identify the Initial/Follow-up/Downgrade/Nullification has been enhanced to identify the Amendment report based on the C.1.11.1- CASENULLIFICATION. The amendment identification is only applicable for (R3) message as the concept of amendment report is specific to (R3) reports only.

• The acceptance process every stage of import evaluates the various import stages and generates the ACK in the (R3) format.

7.1.4 Search for Duplicate Cases

The Duplicate Search Dialog for E2B report allows you to search for possible duplicate cases in the Argus Safety system. You can select different combinations of search criteria. When more than one criterion is selected, only cases that satisfy all criteria are listed. By default, only the fields that are present in the E2B Report are checked for the Duplicate Search.

Use the following procedure to perform a duplicate search.

1. Select Reports -> ICSR Pending Report.

2. When the system opens the Incoming ICSR Reports Dialog, right-click a case to perform a duplicate search.

3. The system displays the search results at the bottom of the Dialog box.

7.1.5 Use the View Differences Report

The View Differences Report enables you to view differences between the following:

• The current XML being imported (a message not yet imported into the database)

• The current case data in the database

• The last imported case

Click View Differences from the Duplicate Search screen to view the View Differences report. View Differences is available only for follow-up and nullification reports only.

The following table lists and describes the fields in the View Differences report:

7.1.6 View the E2B Report

Use the following procedure to view the E2B Report:

1. Select Reports -> Duplicate Search and right-click to the Duplicate Search Dialog box.

2. Click View E2B to view the E2B report in the ICSR Viewer. You can also view an E2B report from the ICSR Pending screen by right-clicking on a row and selecting ICSR Viewer.

7.1.7 Accept Single or Multiple E2B Reports

Use the following procedure to accept single and multiple E2B reports:

1. Select Reports -> ICSR Pending to open the Incoming ICSR Report Dialog box.

2. When the system opens the ICSR Pending screen:

   To accept a single report, right-click on it and select Accept E2B

   OR

   To accept multiple reports, select the check boxes for each report and click Accept E2B.

3. When the system opens the Acceptance of Initial Report Confirmation Dialog box, enter the password and any relevant notes.

4. Click OK to accept the case.

   Note:

   The acceptance of multiple E2Bs can be performed only when the system numbering is set to Automatic.

5. If the system is configured to automatically number cases, the system opens the case accepted Dialog appears with the generated case number.

6. Click OK to close this Dialog.

   Note:

   If the system is configured to manually number cases, you will be prompted to enter a case number for the case that is being accepted.

7.1.8 E2B Initial or Follow-up Intake

During case acceptance, you can access selective acceptance fields in the report.

• The Selective Acceptance feature is enabled only for single initial ICSRs and is a right-click option.

• If you select multiple ICSRs, the system disables this button.

• If you select a single follow-up or nullification ICSR, the system disables this button.

• When the system displays the E2B Difference Report Dialog, you can select the elements required to create or update a case without the system displaying the Case Number and Follow-up Number in the difference report Dialog for initial reports.

• The following changes have been made to the Initial Intake and the Follow-up Difference Report Dialogs:

  • The system displays the decoded view to enable you to select the elements (e.g., US [United States]).

  • The system prints the check box options for the Initial Intake and Follow-up Difference Report Dialogs.

  • The label is updated to Select when selecting elements for the Initial Intake and the Follow-up Difference report Dialog.

• You must select the following fields before the system will permit you to accept the Initial case. By default, all the fields are selected.

  • Country of Incidence (default and grayed out)

  • Report Type (default and grayed out)

  • Initial Receipt Date (default and grayed out)

  • Any one Product

  • Any one Event Term

• If you fail to select these fields, the system displays the following message:

  E2B cannot be imported as it does not meet minimum Argus requirements.

• The system permits you to print the Initial ICSR report.

• When you click Accept Initial, the system displays the Accept E2B Case Dialog. When you complete the data elements and click OK, the system displays the Error/Warning message Dialog for any elements you have selected.

• Once you accept the case as an initial or follow-up case, the system attaches the Source XML (ICSR) and the Initial Selection PDF to the case in the Additional Info tab.

• For Auto Accepted ICSRs, the system does not attach the source PDF in the case because the source XML is attached.

• Initial/Follow-up Source XML

  • Attachment Classification. As specified in the Reporting Destination for the XML source classification.

  • Date. The system date when the case you accepted XML for the case.

  • Description. The acceptance notes you entered for XML.

  • When you click the Source ICSR, you can see the ICSR when opening the ICSR View (ICSR Viewer).

• Initial Selection PDF

  • Attachment Classification: As specified in the Reporting Destination for the Selection Source Classification.

  • Date: The system date when you accepted XML for the case.

  • Description: The date you entered acceptance notes for XML.

• Follow-up Source XML

  • When you click the Source ICSR PDF or the E2B Difference Report, you can view the Initial Selection PDF or the E2B Difference Report in a different IE window.

• Once you accept a case as an initial or a follow-up ICSR, the system prefixes the Business Level Acknowledgement Notes with the case number in the following format:

  Imported Case #: XXXXX

  where:

  XXXXX is the case number

• The system attaches the current notes sent in the Business Level Acknowledgement.

• If the system receives the ICSR via the physical gateway (configured at the reporting destination level), the system sends a low level ACK to indicate the file was received by the Argus Interchange Service.

• The system places this file in the Physical Out folders as configured for the reporting destination in the E2B Mapping Configuration.

• For EDI received files, the system continues to let the EDI Gateway send the low level ACK as it does currently.

• The Interchange Services does not process the low level ACK received in the Physical In destination folder, but enters any errors in the log file since the file will always be rejected by the Interchange Service.

7.1.9 E2B Follow-up Acceptance for Closed or Locked Cases

• If you try to accept follow-up information for a closed or locked case, the system prompts you to unarchive or unlock the case for processing after entering the password and acceptance notes.

• If the case is in archived state while you are accepting the report, the system displays the Case Re-open Dialog to enable you to open the case.

• If the case is in locked state while you are accepting a report, the system displays the Case Unlock Dialog to enable you to unlock the case.

• After you reopen the case, the system accepts all updates as defined in the follow-up information you selected.

• If you do not have permission to reopen an archived or locked case, the system displays the following message:

• You do not have permission to Re-open an Archived/Closed case or Locked Case.

• If you select multiple open, locked, or archived cases or if you do not have permission to open the case, the system skips the cases.

• The system does not create follow-up actions for cases that it accepts automatically.