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:

   1. Support deletion of unwanted data after F/U
   2. Flexibility in Primary key identification for F/U records
   3. Special use case to support comparison based on External applications entity Identifier
   4. Customizable comparison and updation for handling exceptional use scenarios (User Exits)

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