4 Validate ICSR Reports

4.1 Why perform an ICSR check?

During case data entry and prior to E2B file generation, the user may want to verify that sufficient data and the quality of data collected will generate a valid E2B file.

To do so, a Data Validation check is required for E2B profiles and to provide a listing of data elements that do not satisfy the criteria required to generate an E2B report.

On performing an ICSR check, the system performs a validation and lists the following types of validation errors for the data elements that are failing the validations in the ICSR Report data check errors and warnings:

E2B (R2), eVAERS, and eMDR:

1. Mandatory

2. Mandatory Optional

3. Together DTD Element Validation

4. Other Validation

5. Date Validation

6. E2B Generation Validation (only E2B(R2) reports)

7. Encoding Validation

8. Length check Validation

E2B (R3):

1. Mandatory

2. Conditional Mandatory

3. Other Validations

4. Together DTD Validation

You can run an ICSR check by clicking the ICSR icon from the Quick Launch menu shown below.

ICSR check can be used to validate E2B (R2), eVAERS and eMDR reports, provided the ICSR check flag is marked in the Interchange Mapping Utility.

ICSR check can be used to validate EMA E2B (R3) and PMDA E2B (R3) profiles provided the following conditions are met:

• ICSR check flag is marked in the Interchange Mapping Utility

• Profile is configured with atleast one of the reporting destinations

The following illustration shows a sample ICSR check report that is generated in PDF format:

As can be seen in the PDF, the sample report displays the case form fields where the validation error has occurred. Apart from the case form location where the error occurred, the report lists the type of error, data elements, DTD elements, the actual message/cause of the error, and the profiles which were tested for each validation type.

The following are not covered by ICSR check:

• Attachment size validations are not supported as part of the ICSR check for any of the E2B (R3), eMDR, and eVAERS Profiles.

• The ICSR check does not validate data elements pertaining to the Batch and Message headers of the ICSR.

• Validation are not be provided for elements that are mandatorily captured in Argus Safety.

• Validations related to follow-up and Nullification reports are not displayed in the ICSR check report.

To perform an ICSR check, the system requires some reference data based on which validations can be performed. The system uses the following (existing) logic:

4.2 Report Generation Validations

The system performs the following validations at the time of report generations and displays validation error if there are failures:

1. Missing Mandatory Elements

2. Missing Mandatory Optional Elements

3. Length Validation for character data

4. M2 Code validation

5. Report File Size validation (for HL7 Reports only)

6. File type of attachments that qualify to be included

The system displays an error message in the following scenarios:

1. While generating draft E2B or eVAERS or eMDR report using Draft tool button, if the default Reporting Destination is not specified for E2B or eVAERS or eMDR in Common Profile Switches.

2. While generating draft/final E2B or eVAERS or eMDR report for the Reporting Destination which is not configured with valid Message Profile as E2B or eVAERS or eMDR respectively.

3. While generating E2B(R3) or eVAERS or eMDR report, if the size of inline attachments or overall size of xml file exceeds the maximum file size limit specified in the Reporting Destination configuration.

4. While validating the file type of the attachments that qualify to be included in the E2B(R3) report and displays a validation message to indicate the file type provided for the attachment does not confirm with the allowed file types for the report.

4.3 Validation Rules

Validation Rules for all profiles can be viewed from Argus Console > System Configuration > Interchange Mapping > Manage Profile.

E2B Generation validation rules are executed on the generated ICSR report data.

The validation rules that are applicable to individual element is governed by configuration in the Conformance Rules tab for that element for the respective profile.

Validation Rule the elements is categorized amongst the following categories:

• Basic Data Validation: This category covers all the applicable validation based on the Length of the field.

  Length - This validation check validates if the data type length of output is within with the configured Data length or not. If the data length is exceeding the configured length then validation error is listed in the validation report.

• Allowed Values Data Check: The element for which the Allowed Value Check Required checkbox is checked is validated against the allowed values codes associated with them using Allowed Values Configuration Dialog for the respective profile.

• Mandatory Along with (Together): Elements for which the Mandatory along with element is specified, validation rule validates for such elements in the generated ICSR the element itself and the configured Dependent element co-exist or none of them exists in the report.

• Validation Category Based: The element is validated as per the value configured for that element in the Validation Category drop-down list in the Conformance rule tab.

  The elements for which there exists a SQL based validation for which Primary Validation checkbox is checked in the Additional Validation Configuration Dialog, the framework based validation is not executed for them; rather the configured SQL based validations is executed for them.

  These validations are categorized in two sub categories, one for the ICSR reports for EMA the profile, and the other ICSR Report for PMDA profile

  • EMA

  The validation for the PMDA report is fired at each reporting category level:

  Mandatory: The element which is configured as Mandatory should be present in the ICSR Report; if it is not present in the report output then application displays the validation failure in the validation report.

  Conditional Mandatory: The element which is marked as Conditional Mandatory is present based on certain condition, hence it is expected that user will configure a Validation for it in the Additional Validation Dialog. There is no framework based validation for the elements configured with this validation type in Conformance rule tab.

  Optional: The element which is marked as optional may or may not be present in the report, but still there could be a possibility that there might exist a validation under the Additional Validation Dialog and if any of the configured validation is failed it will be listed in the validation report.

  Other Fatal: There is no framework based validation for the elements configured as other fatal validation type in Conformance rule tab.

  • PMDA E2B

    Mandatory: The element which is configured as Mandatory should be present in the ICSR Report; if it is not present in the report output then application displays the validation failure in the validation report.

    Mandatory for Completion: The element which is marked as Mandatory for completion should be present in the ICSR Report if J2.7.1 (MHLWADMICSRCOMPLETECLASS) = completed for that report; if it is not present then application displays the validation failure in the validation report.

    Conditional Mandatory and Conditional Mandatory for Completion: The element which is marked as Conditional Mandatory or Conditional Mandatory for Completion is present in the report based on certain condition, hence it is expected that user will configure a Validation for it in the Additional Validation Dialog. There is no framework based validation for the elements configured with these validation types in Conformance rule tab.

    Do not Enter: The element which is marked as Do not enter are not present in the report, and if they are present than application lists the validation failure in the validation report (Argus report generation logic removes the elements that are marked as Do not enter at the time on generation itself).

    Optional: The element which is marked as optional may or may not be present in the report, but still there could be a possibility that there might exist a validation under the Additional Validation Dialog and if any of the configured validation fails, it is listed in the validation report.

    Other Fatal: There is no framework based validation for the elements configured as other fatal validation type in Conformance rule tab.

• Additional Validations: The Additional SQL based validations associated with elements in the respective ICSR profile (element level for E2B other than PMDA and Reporting category level for PMDA E2B), the validation is fire based on the SQL logic specified under the Validation SQL.