What GOR3 can offer?
GOR3 is a solution to handle the new ICH E2B R3 regulation to meet the compliance requirements for FDA , PMDA and EMA to validate,transform and transmit ICH E2B R3 to EMA, E-VAERS to FDA-CBER and E-MDR to FDA-CDRH.
GOR3 can be easily plugged into your existing Adverse Event Reporting System to Validate and Transform the E2B R2 files to E2B R3 XML files as per the ICH defined validation rules.
GOR3 provide user’s ability to not only transform files from R2 to R3 but also allow business users to verify the transformed R3 files before transmitted to the Agencies and Partners so as to meet 100% compliance. GOR3 Provides users to compare multiple ICSR files in both R2 and R3 format in split tree screen view that can be drill down to lower nodes to compare specific message or specific block of th ICSR. Mutiple files can be transmitted in single click by the reporting officer.
GOR3 will provide users to auto transmission/ auto import feature also to any particular reporting destination based on the configuration setting.
GOR3 provide dashboard indicator for outbound and inbound ICSR’s including the MDN status so the business users can track the movement of the R3 files and get an confirmation of the delivery of the files to Health Authorities and License Partners and vice versa.The utility hence able to handle the three ACKs received from agency – MDN, ACK2, and ACK3. Below is the description for the different types of ACK:
| ACK | Acknowledgement |
| ACK2 | Acknowledgment when the file is moved from agency database to internal processing database e.g. when VAERS R3 moves to FAERS database an ACK2 is sent back |
| ACK3 | Business Level Acknowledgment. When the transmitted R3 file is accepted in the agency database |
GOR3 has robust error log mechanism to track for any validation, parsing or transformation error and make business users alert for any error/warning during GOR3 validation and transformation.
GOR3 is capable of handling Error log to track about any validation, parsing or transformation error for outgoing and incoming files.
GOR3 also provide reconciliation report to verify whether all transmitted E2B + (R2) files for export were transformed and made available in outgoing folder as E2B (R3) file for export
Validation Business Rules :
====================
We allow existing schema provided by ISO/HL7 for ICH ICSR messages to be customized as per the business requirement of local drug safety units.We parse the E2B R2 files based on the validation rules to make sure transformed R3 files has correct values for the DTD elements.
E2B Extension Elements:
====================
To meet the local Drug Safety Units, We help customers to add new User Define Fields , map to extension DTD element of the profiles and customize the export logic for those newly added element and map them to the E2B R3 File. Example for below fields:
- Amendment
- Event medically confirmed
- Event Country
- Drug Characterization
- Event Seriousness
GOR3 can be customize to add the validation rule for these new User Define Fields.
GOR3 support Batch Report Transformation and Batch Report R3 transmission and Vice Versa.
GOR3 provide a coded/ decoded view of both E2B+ (R2) and E2B (R3) formats displaying E2B tags in line with the associated Argus Case form fields.
GOR3 team can help you with updating the SOPs and work manuals based on E2B (R3) changes.
GOR3 team conduct the training of the staff in regards to the new changes and give possible approaches to deal with the problems with the implementation
GOR3 team offers complete range of Pharmacovigilance and Device Vigilance Safety services.
GOR3 offer the users site security to make sure E2B R3 files available on the dashboard to group of users per their site sceurity.
R3 Technical Changes:
- Date format: the E2B(R2) guideline supports dates with 2 separate fields, one for the date itself and one for the date format. The implementation of the E2B(R3) message has taken another approach by supporting the date data type, i.e., with both date value and date format in the same field. Guidance is provided on the conversion of dates.
- Code mapping: E2B(R2) and E2B(R3) provide sets of codes for several fields. In some case, one format has additional code values than the other. Guidance is provided on the conversion of codes.
- Deletion: some fields of E2B(R2) have been deleted in E2B(R3). Guidance is provided on the way to handle such fields.
- Addition: some fields have been added in E2B(R3). Guidance is provided on the way to handle such fields.
- Field length: some fields have been extended (i.e., increased field length) in E2B(R3). Guidance is provided on the conversion of such fields.
- Masking: E2B(R3) provides another way to mask information, for privacy purposes, or because information is unknown. Guidance is provided on the way to pass from one encoding to the other, and vice versa.
- Structure: E2B(R3) provides another way to structure the information that was available in E2B(R2) guideline. Guidance is provided on the way to pass from one structure to the other, and vice versa.
R3 Functional Changes:
Causality assessment in E2B (R3) – Mandatory use of causality assessment for SUSARs (remains optional for the rest of expedited reporting). This method of assessment should be provided along with the EU Source of Assessment (e.g. investigator, sponsor, etc.) and the EU Result of the Assessment (Reasonable possibility or No reasonable possibility). The same assessment is used in E2B (R2) using the free text fields, whereas in E2B (R3) these fields are controlled vocabularies. – Implementation of ISO ICSR standard requires the use of controlled vocabularies for source, method and result of assessment (free text fields were formerly used in E2B (R2)).
Amendment reports – In case of need of a correction (e.g. after internal review) or if a need arises to attach a document that was not available at time of the original report, an amendment report could be sent at a later time. Amendment reports need not alter the case information (i.e. they are not followups) and therefore the “date of receipt of the most recent information” field does not change between the amendment and the original report
Attachments – E2B (R3) allows attachments such as literature articles or other documentation (e.g. autopsy reports, copies of lab results) to be incorporated in the ICSR xml file (previously it was not possible to attach documents to your reports). This new feature needs to be restricted for those documents that add value to the report (i.e. it is not intended for uploading full documentation of a case). The main use of this feature would be to attach literature articles (when requested).
Information moving from case to event level: –
- Seriousness
- – Medical confirmation
- – Country of occurrence Information moving
Characterization of drug role: “Drug not Administered” – The code “Drug Not Administered”, can be used for submitting events in clinical trials and for medication error cases. – Trial events and medication errors can be reported as normal expedited cases.
Concept of null flavours – For specific reasons, information on mandatory data elements might be lacking for an ICSR that is still considered valid. Null flavour flags give a reason why this information is lacking (e.g. unknown, not provided).
Additional data fields and/or codes –
Implementation of international standards for the Identification of Medicinal Products (IDMP) for human use in the EU (use of controlled vocabularies) o The ISO IDMP terminologies are not yet available for use with ICSRs. Current E2B (R2) terminologies or free text will be used by senders of ICSRs until they become available. – New option for the field ‘Patient age group’- ‘Foetus’. – Coding special situations (in additional drug information field) – counterfeit, overdose, drug taken by father, misuse, medication error, expired lot, etc. – Biological products o Mandatory population of batch number field for all suspect biological drugs (or else a null flavour) – Device component o Additional fields: Device ID, Device name, Device batch/lot number
iche2br3 