Appendix

Extensible ICSR Profile Framework

When used with the current ICSR R2 framework, E2B+ allows the user to extend profile elements. However, extending a profile using the existing Framework includes some limitations such as:

Linking of extended child with the Parent: If the element is added to a node that is lower in the report hierarchy, the linking of the extended node to the higher level node becomes difficult.
For example:
- Level 1: SAFETYREPORT
- Level 2: PATIENT
- Level 3: Drug
- Level 4: Dosage
To extend an element at Dosage level using E2B+, the linking of the attribute with Drug becomes complex. As a result, an error may sometimes occur.
Cannot add a new Parent/repeater: It is not feasible to add a new repeater section that is not part of the standard E2B report. For example, ER: 15969640-Multiple Neonates can’t be imported into Argus thru E2B+.

Use Case:

Flexibility to cope up with the varying regional regulations

The different regulatory agencies across the world are adopting the R3 (HL7) based ICSR reporting framework. This HL7 framework facilitates the different regulatory authorities to extend the standard ICH elements to support their regional data capturing needs. For Example, ICH supports the following attributes for a Drug (G Block):

#	Element	Number
1	G.k.1	DRUGCHARACTERIZATION
2	G.k.2.1.1a	DRUGMPIDVERSION
3	G.k.2.1.1b	DRUGMEDICINALPRODID
4	G.k.2.1.2a	DRUGPHPIDVERSION
5	G.k.2.1.2b	DRUGPHARMAPRODID
6	G.k.2.2	MEDICINALPRODUCT
7	G.k.2.3.r	ACTIVESUBSTANCE
8	G.k.2.4	OBTAINDRUGCOUNTRY
9	G.k.2.5	INVPRODUCTBLINDED
10	G.k.3.1	DRUGAUTHORIZATIONNUMB
11	G.k.3.2	DRUGAUTHORIZATIONCOUNTRY
12	G.k.3.3	DRUGAUTHORIZATIONHOLDER
13	G.k.4.r	DOSAGEINFORMATION
14	G.k.5a	DRUGCUMULATIVEDOSAGENUMB
15	G.k.5b	DRUGCUMULATIVEDOSAGEUNITR3
16	G.k.6a	REACTIONGESTATIONPERIOD
17	G.k.6b	REACTIONGESTATIONPERIODUNITR3
18	G.k.7.r	DRUGINDICATIONR3
19	G.k.8	ACTIONDRUG
20	G.k.9.i	DRUGEVENTMATRIX
21	G.k.10	DRUGADDITIONALINFO
22	G.k.11	DRUGADDITIONAL

As per the PMDA regulation, the regulatory agencies request support the following regional attribute of DRUG:

#	Element	Name
1	J2.4.k	MHLWSTATUSCATEGORYOFNEWDRUGS
2	J2.5.k	MHLWRISKCATEGORYOFOTCDRUGS
3	J2.6.k	MHLWROUTEFORACQUIRINGOTCDRUGS

As per the EMA regulation, the regulatory agencies request support the following regional attribute of DRUG:

#	Element	Name
1	G.k.2.2.EU.1	DRUGINVENTEDAME
2	G.k.2.2.EU.2	DRUGSCIENTIFICNAME
3	G.k.2.2.EU.3	DRUGTRADEMARKNAME
4	G.k.2.2.EU.4	DRUGSTRENGTHNAME
5	G.k.2.2.EU.5	DRUGFORMNAME
6	G.k.2.2.EU.6	DRUGCONTAINERNAME
7	G.k.2.2.EU.7	DRUGDEVICENAME
8	G.k.2.2.EU.8	DRUGINTENDEDUSENAME

Flexibility to cope up with evolving regulation

As the regulatory authorities are still trying to adopt the R3 based reporting, there are several cardinality changes they are coming up in the revised guidance. For example, as per the initial eVAERS guidance, the authorities introduced Race of a patient as a regional element, expecting to capture only one Race per patient. However, the Guidance was later revised to support two Races per patient.

System Integration

The ICSR R3 report is based on the HL7 format, which is a standard data exchange platform for Healthcare data exchange. The ICSR R3 importing framework is extended for the user to integrate with different EDC systems such as Inform. In order to do so, it is expected that the regulatory authorities will add new attributes at the different level for the data exchange between the two systems.

Minimum Case Creation Validations on Incoming ICSR

MAH uses Oracle Argus Safety for capturing data from different sources to meet their regulatory and non-regulatory reporting needs. The ICSR Import is one big platform for data capturing from various sources. As a result,MAH are expected to use Oracle Argus Safety as an importing platform to pull the information from various sources in their safety database and then further process it using Oracle Argus Safety.

Since the purpose for the Oracle Argus Safety import is not confined to regulatory import, the OOTB import logic should allow flexibility to the user to control the validation during the import (i.e., to execute minimum case creation validations).

Note:

All the compliance validation will be maintained in the error/warning log so that the user can review the regulatory gaps with the incoming ICSR file.

Import Follow-up on non-E2B Compliant Case

As previously stated, the usage of the ICSR Import framework in not confined to regulatory purpose. For instance, the incoming ICSR file can be used only for data exchange. There can be scenarios in which the case on which the ICSR file is imported might not be regulatory compliant. Despite this, the user still wishes to import the update from the incoming ICSR. As a result, the application shall not execute the ICSR conformance validation check before importing the data from follow-up ICSR.

Provide Flexibility to User to Map Incoming E2B as Follow-up to Existing Case

As previously stated, the usage of the ICSR Import framework in not confined to regulatory purpose. As a result, the logic to link an incoming report to a report with an existing case will be configurable at the profile level in order to address the following use case.

Use Case:

Incoming Report to Case Identifier Linking Logic

Cases coming from Regulatory Authorities:

As per regulations, the MAH is expected to report separate ICSR for Marketed and Investigational licenses. Consequently, for two different reports that are sent from same case but for different license types, the SAFETYREPORTID will be different, even though the reports belong to same case. In this situation, COMPANYNUM or AUTHRITYNUM would be more appropriate to link the incoming ICSR with the case.

Cases coming from Integrated EDC System:

Since users will be leveraging the ICSR import framework to exchange the information between two systems, they will not be confined to send multiple reports per case. Instead, they would send one report for a particular case. As a result, the linking of the case to the report can be done based on SAFETYREPORTID for the integrating profile.

Comparison and Data Evaluation/Update for an Incoming Follow-up Report

As per the current implementation, the application provides the user with the following difference views for comparing the Incoming ICSR file in the ICSR format:

The newly imported ICSR message.
The ICSR message that was generated using the current case data against the ICSR profile for the importing agency.
The ICSR file that was last imported to the case.

The comparison logic performs a record matching based on the Metadata of the internal table by executing the key based comparison of the elements in the previously stated 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 update logic shall be enhanced for the following:

Support Deletion of Unwanted Data after Follow-up

As per the current comparison and data update logic, if two records are matched based on the key matching, the matching record is updated. In case there is no match found for the existing case record, a new entry is created for the newly incoming record. This leads to stale data in the case.

The ICSR comparison logic will support record level deletion of un-matching case data. Additionally, the deletion logic shall be configurable at the record level.

Flexibility in Primary Key Identification for Follow-up Records

As previously stated, the current comparison logic of incoming ICSR is driven based on the internal Metadata stored in an internal table, with limited flexibility for comparison key configuration. This logic will be made generic enough so that users can update the OOTB keys as per their use case.

Use Case:

Initial E2B  Initial Case

Follow-up E2B  Accept as Follow-up