Case and Submission Validation

Learn how Vault Safety validates E2B files prior to submission.

Last Updated

Sections in This Article

About Schema Validation

Vault Safety validates E2B files against the XSD (XML Schema Definition) to catch E2B errors prior to ICSR submissions. The XML is validated automatically as part of the E2B generation process.

During validation, the E2B file is validated against the appropriate agency’s schema. The following list describes how the system validates each type of E2B file type:

  • EMA E2B(R3) are validated against the EMA XSD schema
  • FDA E2B(R2) files are validated against FDA ICSR XML DTD version 2.1
  • FDA E2B(R2) files with combination products are validated against FDA ICSR XML DTD version 2.2
  • HC E2B(R2) files are validated against FDA ICSR XML DTD version 2.1
  • FDA VAERS E2B(R3) files are validated against the EMA XSD schema
  • PMDA E2B(R3) files are validated against PMDA XSD schema

About Case and Submission Business Validation

Vault Safety performs validation for E2B R2 and R3 formats (ICH/EMA/FDA/FDA VAERS/PMDA). E2B Schema validation occurs at the Submission level once the E2B file is generated. Business validation occurs at the Case and Transmission levels (Submission and Distribution).

Non-SUSAR and manual submissions are not Case validated because Case validation operates on rule engine evaluation. Transmissions created manually are validated but the associated Case is not validated. Transmissions must reference a Transmission Profile, for a supported file format, for the file to be validated.

Note Consider the following limitations for E2B validation on Distribution-type Transmissions:

  • Vault Safety does not validate Email Distributions.
  • Other Distributions (non-email) are validated, but the system does not send a notification when validation is complete.
  • Vault Safety does not support Case-level validation for Imported Cases. See Migrate External Cases for more information on Imported Cases.

FDA Character Encoding Validation

The FDA supports only ISO 8859-1 characters for E2B(R2) submissions and does not support the UTF-8 character set.

During FDA E2B(R2) report validation at the Case and Transmission level, if any text fields or narrative documents have non-ISO 8859-1 characters, the system generates a validation warning along with a .csv file to capture the validation results for conformance with ISO 8859-1. The .csv file provides a direct link to the validation error for the character. Note that this is a separate file from the validation file, which captures all other validation errors.

ISO Smart Replace

Some UTF-8 characters with a matching character in ISO 8859-1 are auto-replaced in the generated FDA E2B(R2) file, while the remainder are replaced with blank fields.

The following table displays the UTF-8 characters that are auto-replaced with ISO 8859-1-compliant characters:

UTF-8 Character ISO 8859-1-Compliant Character
“ "
” "
‘ '
’ '
– -
— -
Other non-ISO-compliant character [White Space]

Configure the Excel File to View Unsupported Characters

When you open the ISO 8859-1 validation .csv file with Microsoft Excel, the Unsupported Characters column contains ambiguous characters because Excel does not automatically encode them as UTF-8.

To view these characters in the .csv file, perform the following steps:

  1. Close the downloaded file.
  2. Open a new Excel file.
  3. Perform one of the following actions depending on your operating system:
    • Mac OS: Go to File > Import.
    • Windows: Go to Data > From Text/CSV.
  4. Select CSV file then select Import.
  5. In your folder, select the downloaded .csv file and then select Get Data.
  6. From the File Origin dropdown, select Unicode (UTF-8), and then select Next.
  7. Under Delimiters, deselect Tab, and then select Comma.
  8. Perform one of the following actions depending on your operating system:
    • Mac OS: Select Finish.
    • Windows: Select Load.

Result

The unsupported characters on the .csv file are now viewable when you open the file.

Business Validation

Business validation occurs at the Case and/or Transmission level. Validations are completed based on global (ICH) and regional (EMA, FDA VAERS, PMDA) conformance rules. Regional validation occurs only at the Submission/Distribution level.

  • Over 150 ICH conformance rules validated at the Case and Transmission level against E2B(R3) documents (this includes ICH E2B(R3), EMA E2B(R3), and FDA VAERS E2B(R3) file formats).
  • Over 170 FDA VAERS conformance rules validated at the Transmission level against FDA VAERS E2B(R3) file format.
  • Over 90 EMA conformance rules validated at the Transmission level against EMA E2B(R3) file format.
  • Over 140 PMDA conformance rules validated at the Case and Transmission level against the PMDA E2B(R3) file format.

Some regional rules supersede (override) ICH global rules. In this case, only the regional rule is validated at the Transmission level.

Vaults created in 20R2 or earlier must be configured to add Case-level validation and to add the Validation Results section to Submission and Distribution page layouts.

Business validation results with fail or warning outcomes are reported in the Validation Results object. If you regenerate the E2B file, the reported validation results are deleted and new validation results records are created if there are any failures or warnings specific to the validation criteria.

Trigger Validation

The following describes when the system performs validation:

  • Transmissions: When a Submission or Distribution file is created, Vault automatically validates against the schema (for supported file formats), and against the Global (ICH) and regional (FDA VAERS, EMA, or PMDA) validation criteria.
  • Cases: A Case is validated when a user triggers the Evaluate Regulatory Conformance action. Administrators can configure your vault to automatically run the Evaluate Regulatory Conformance action as part of the Case lifecycle.

Business validation results with fail or warning outcomes are reported in the Validation Results object. If you regenerate the E2B file, the reported validation results are deleted and new validation results records are created if there are any failures or warnings, specific to the validation criteria.

Note Regional validations are not executed on E2B formats that will not be sent to a region.

View Validation Results

When a validation criteria rule evaluates as a fail or warning, a corresponding Validation Result record is created for the Case and Transmission. Validation Result records can be viewed from a Case or Transmission record. The Validation Results Summary record is also created for each validated Case and Transmission. The Validation Results Summary record is listed with the other validation results (including regional FDA VAERS, PMDA, and EMA E2B R3 validation results). Each Validation Results Summary record includes an attachment detailing all the results of the rules run: pass, fail, and warning.

The sections below describe the Validation Criteria and Validation Result objects. Validation Criteria and Validation Results appear on Cases or Transmissions after validation.

Note Validation Rules and Results are system managed. You cannot modify or delete existing system rules or validation rules. Custom validation criteria records are excluded during evaluation.

Validation File

Upon validation completion, the system generates a .csv file that captures the pass or fail result of each validation rule.

The file is added as an attachment to the Transmission (Submission or Distribution) record and linked to from vault notifications.

Validation Criteria Fields

The Validation Criteria object captures validation rule criteria (such as business and conformance rules) based on industry guidance.

The following table describes the fields on the Validation Criteria object:

Field Description
Agency Agency the rule originated from. For global (i.e. ICH) rules, this field will be blank.
API Name The record's unique identifier.
Conformance Business, conformance, schema or other rule definition based on the Source.
Data Element The Data Element number, as specified in the guidance document, for the evaluated value.
Data Element Name The name of the Data Element, as specified in the guidance document.
Data Element The Data Element number, as specified in the guidance document, for the evaluated value.
Evaluation Level The level at which the rule should evaluate (i.e. Case or Submission).
File Format The format used to drive validation rules.
Result Status Type Select Fail, Warning, or Hard Fail as the The rule result outcome. This field also populates the Validation Status on the Case or Transmission.
Note the difference between a Fail and Hard Fail value:
  • Either a Fail or Hard Fail result will prevent an auto-submission to a gateway.
  • Only a Hard Fail result will prevent you from triggering the Submit to Gateway action.
Rule Formula The formula used to validate the data element conformance.
Rule Version The validation criteria version.
Source The origin of the validation rule.
Vault Field The name of the field to be evaluated.
Vault Object The name of the object to be evaluated.
Supersedes Select a rule to override with the new conformance. The Superseded rule will not evaluate for the parameters specified.
Superseded Conformance The conformance for the superseded rule.

Validation Result Fields

The Validation Result object captures validation criteria results from the imported Case or Submission. Validation Results indicate failed and warning messages - rules that pass validation are not displayed.

Case Validation Result
Case Validation Result

Note Not all warnings are displayed as validation results. Previously implemented warnings will continue to be sent via notifications or email.

The following table describes the fields on the Validation Result object:

Field Description
Validation Criteria Reference to the validation criteria that resulted in the rule evaluation.
Conformance Reference to the validation criteria conformance that resulted in the rule evaluation. Value is inherited from the Validation Criteria.
Data Element The Data Element number, as specified in the guidance document, for the evaluated value.
Data Element Name The name of the Data Element, as specified in the guidance document.
Vault Object The name of the object to be evaluated.
Vault Field The name of the field to be evaluated.
Validation Status Indicates the rule outcome: pass, fail, or warning.
Agency Agency the rule originated from. For global (i.e. ICH) rules, this field will be blank.
File Format The format used to drive validation rules.
Case The Case record this validation result was evaluated for.
Transmission Specifies when the validation occurs at the Transmission level. This field references the related Transmission. This field will be blank if the rule was evaluated at the Case level.
Validation Criteria Version Version of the Validation Criteria used for the evaluation.
Organization Name of the organization associated with the case.
Vault Record ID This is the record id for the evaluated field. We recommend you remove this field from page layouts.

Validation Summary Record

The following table is a comprehensive list of every unique Validation Result that can be encountered as a fail/warning or in the attachment on the Validation Results Summary record.

For a complete list of the validation criteria, download the following file:

Download Validation Criteria

Field Description

Field is always required.

The specified required field is missing a value.

A two character country code will be used in all instances for the country component of the Unique Identifier.  The country code EU exists in the ISO 3166 country code list as an exceptional reservation code to support any application that needs to represent the name European Union. In this case, ‘EU’ will be accepted as the country code. The format of C.1.1 ensures a unique report identifier for the sender of particular ICSR. The use of a ‘-’ (dash/hyphen) should be avoided in the ‘company or regulator name’.

A country code value is invalid or a dash was inserted in the Company or Regulator Name field.

Minimum precision required is date and time to the second and the time zone may have to be specified (i.e. ‘CCYYMMDDhhmmss[+/-ZZzz]’)

The time entered on the Date field does not contain the necessary time information (i.e. time zone).

The date specified cannot refer to a future date.

The date entered on a Date field is a date beyond the present.

Value Allowed 1=Spontaneous Report 2=Report from study 3=Other 4=Not available to sender (unknown)

A invalid value was selected on the Type of Report field.

Minimum precision required is the day (i.e. ‘CCYYMMDD’).

The day value entered on a Date field is empty or invalid.

if C.1.6.1.r.2 (Included Documents) = true, C.1.6.1.r.1 (Documents Held by Sender) is required for that document.

A value is required for the Documents Held by Sender field is required if there are Documents included on the Case.

Value Allowed 1=Regulator OR 2=Other

A invalid value was selected on the First Sender of This Case field.

Required when Report Type (C.1.11.1) is either Nullification (1) or Amendment (2).

A value is required for the Reason for Nullification / Amendment if the Report Type is set to Nullification or Amendment.

Allowed nullFlavor: Masked (MSK), Asked But Unknown (ASKU), Not Asked (NASK)

A value entered on a Record reason omitted field is invalid.

Required if Primary Source for Regulatory Purposes (C.2.r.5) = 1.

A value is required on the Reporter’s Country Code field if the Primary Source is set to Regulatory Purposes.

Value Allowed 1=Pharmaceutical Company 2=Regulatory Authority 3=Health Professional 4=Regional Pharmacovigilance Centre 5=WHO collaborating centres for international drug monitoring 6=Other (e.g. distributor or other organisation) 7=Patient / Consumer

An invalid value was selected for the Sender Type field.

Required if the ‘Sender Type’ (C.3.1) is not coded as 7 (Patient / Consumer).

The Sender’s Organisation is required if the Sender Type field is set to Patient/Consumer.

Required if Type of Report (C.1.3) = 2 (Report from study).

The Study Type field is required if the Report Type is set to Study .

Value Allowed 1=Clinical trials 2=Individual patient use(e.g. ‘compassionate use’ or ‘named patient basis’) 3=Other studies (e.g. pharmacoepidemiology, pharmacoeconomics, intensive monitoring)

An invalid value was selected for the  Study Type Where Reaction(s)/Event(s) Were Observed field.

Each ICSR must contain at least one 'Suspect', 'Interacting', or 'Drug Not Administered'

An invalid value was selected for the Characterisation of Drug Role field.

Value Allowed 1 = Suspect 2 = Concomitant 3 = Interacting 4 = Drug Not Administered

An invalid value was selected for the Characterisation of Drug Role field.

Field is required if Strength (number) (G.k.2.3.r.3a) is populated.

The Strength (unit) field is required if the Strength (number) field contains a value.

Required if Authorisation / Application Number (G.k.3.1) is provided.

The Country of Authorisation / Application field is required if the Authorisation / Application Number contains a value.

Required if Cumulative Dose to First Reaction (unit) (G.k.5b) is populated.

The Cumulative Dose to First Reaction (number) field is required if the Cumulative Dose to First Reaction (unit) contains a value.

Required if Cumulative Dose to First Reaction (number) (G.k.5a) is populated.

The Cumulative Dose to First Reaction (unit) field is required if the Cumulative Dose to First Reaction (number) contains a value.

Required if Gestation Period at Time of Exposure (unit) (G.k.6b) is populated.

The Gestation Period at Time of Exposure (number) field is required if the Gestation Period at Time of Exposure (unit) contains a value.

Required if Gestation Period at Time of Exposure (number) (G.k.6a) is populated.

The Gestation Period at Time of Exposure (unit) field is required if the Gestation Period at Time of Exposure (number) contains a value.

Required if Indication (MedDRA code) (G.k.7.r.2b) is provided.

The MedDRA Version field is required if the Indication (MedDRA code) contains a value.

if nullFlavor is used in Indication as Reported by the Primary Source (G.k.7.r.1), select an appropriate MedDRA term to reflect that the indication is not available.

If the Indication (MedDRA code) does not contain a value, a MedDRA term must be selected to indicate the information is unavailable.

Required if MedDRA Version for Indication (G.k.7.r.2a) is provided.

The Indication (MedDRA code) field is required if the MedDRA version field contains a value.

Required if Time Interval between Beginning of Drug Administration and Start of Reaction / Event (unit) (G.k.9.i.3.1) is provided.

The Time Interval between Beginning of Drug Administration and Start of Reaction / Event (number) is required if a unit of measure was provided in either field.

Required if Reported Cause(s) of Death (MedDRA code) (D.9.2.r.1) is populated.

The MedDRA Version for the Reported Cause(s) of Death field is required if the Reported Cause(s) of Death (MedDRA code) field contains a value.

Required if MedDRA Version for Reported Cause(s) of Death (D.9.2.r.1) is populated.

The Reported Cause(s) of Death (MedDRA code) field is required if the MedDRA Version for the Reported Cause(s) of Death field contains a value.

Required if Date of Death (D.9.1) is populated.

The Was Autopsy Done? field is required if the Date of Death field contains a value.

Required if Autopsy-determined Cause(s) of Death (MedDRA code) (D.9.4.r.1b) is populated.

The MedDRA Version for the Autopsy-determined Cause(s) of Death field is required if the Cause(s) of Death (MedDRA code) contains a value.

Required if Test Name (F.r.2) is populated. Either Test Name (free text) (F.r.2.1) or Test Name (MedDRA code) (F.r.2.2b).

The Test Date field is required if either the Test Name (MedDRA code) or Test Name (free text) fields contain a value.

Required if Test Date (F.r.1) is populated and Test Name (MedDRA code) (F.r.2.2b) is not populated.

The Test Name (free text) and Test Name (MedDRA code) fields are required if the Test Date field contains a value and the Test Name (MedDRA code) field does not contain a value.

Required when Test Name (MedDRA code) (F.r.2.2b) is populated.

The MedDRA Version for Test Name is required if the Test Name (MedDRA code) field contains a value.

Required if Test Name (F.r.2) is populated, and neither Test Result (value / qualifier) (F.r.3.2) nor Result Unstructured Data (free text) (F.r.3.4) is populated.

The Test Result (code) field is required if the Test Name field contains a value and the Test Result (value / qualifier) and Unstructured Data (free text) fields do not contain values.

Value Allowed 1=Positive 2=Negative 3=Borderline 4=Inconclusive

An invalid value was selected for the  Test Result (code) field.

Required if F.r.2 is populated, and Test Result (code) (F.r.3.1) and Result Unstructured Data (free text) (F.r.3.4) is not populated.

The Test Result (value / qualifier) is required if the Test Name and Test Result (code) fields contain a value and the Unstructured Data (free text) field does not contain a value.

Required if Test Result (value / qualifier) (F.r.3.2) is populated.

The Test Result (unit) field is required if the Test Result (value / qualifier) field contains a value.

Required if Test Name (F.r.2) is populated, and Test Result (F.r.3) is not populated.

The Result Unstructured Data (free text) is required if the Test Result field does not contain a value.

Required if Number of Units in the Interval (G.k.4.r.2) is populated.

The Time Interval Unit field in the interval is required if the Number of Units field contains a value.

Minimum precision required is the year (i.e. 'CCYY')

The year value entered on a Date field is empty or invalid.

Required if Duration of Drug Administration (unit) (G.k.4.r.6b) is populated.

The Duration of Drug Administration (number) is required if the Drug Administration (unit) field contains a value.

Required if Duration of Drug Administration (number) (G.k.4.r.6a) is populated.

The Drug Administration (unit) is required if the Drug Administration (number) field contains a value.

This field is required. If the initials are known to the sender but cannot be transmitted due to data privacy requirements, this data element should be left blank with nullFlavor = MSK (Masked).

The Patient Name field is required. This field can be masked if confidentiality is required. 

Required if Age at Time of Onset of Reaction / Event (unit) (D.2.2b) is populated.

The Age at Time of Onset of Reaction / Event (number) is required if the Age at Time of Onset of Reaction / Event (unit) field contains a value.

Required if Age at Time of Onset of Reaction / Event (number) (D.2.2a) is populated.

The Age at Time of Onset of Reaction / Event (unit) field is required if the Age at Time of Onset of Reaction / Event (number) field contains a value.

Required if Gestation Period When Reaction/Event Was Observed in the Foetus (unit) (D.2.2.1b) is populated.

The Gestation Period When Reaction / Event Was Observed in the Foetus (number ) field is required if a unit of measure was provided in the (unit) field.

Required if Gestation Period When Reaction / Event Was Observed in the Foetus (number) (D.2.2.1a) is populated.

The Gestation Period When Reaction / Event Was Observed in the Foetus (unit ) field is required if a number was provided in the (number) field.

Required if Medical History (disease / surgical procedure / etc.) (MedDRA code) (D.7.1.r.1b) is populated.

The MedDRA Version for the Medical History field is required if the Medical History (MedDRA code) field contains a value.

Required if MedDRA Version for Medical History (D.7.1.r.1a) is populated.

The Medical History (MedDRA code) field is required if the MedDRA Version for the Medical History field contains a value.

When Parent Medical history already is provided (D.10.7), do not set this data element to 'true' (Yes) for similar medical concepts also coded for the patient.

The Family History field should be set to ‘No’ if the Parent Medical History field contains a value.

Required if Section D.7.1 (Relevant Medical History) is null.

Text for Relevant Medical History and Concurrent Conditions (except reaction / event) fields are required if the Relevant Medical History field does not contain a value.

Required by the schema if any data element in section D.8.r (Relevant Past Drug History) is used.

The Name of Drug as Reported field is required if any field in the Relevant Past Drug History section contains a value.

Any given drug entry may have either MPID or PhPID, but NOT both.

A record may contain a Medicinal Product Identifier (MPID) or a Pharmaceutical Product Identifier (PhPID) . A record with both identifiers will result in an error upon validation.

Required if Indication (MedDRA code) (D.8.r.6b) is populated.

The MedDRA Version for the Indication field is required if the Indication (MedDRA code) field contains a value.

Required if MedDRA Version for Indication (D.8.r.6a) is populated.

The Indication (MedDRA code) field is required if the MedDRA Version for the Indication field contains a value.

Required if Reaction (MedDRA code) (D.8.r.7b) is populated.

The MedDRA Version for the Reaction field is required if the Reaction (MedDRA code) contains a value.

Required if MedDRA Version for Reaction (D.8.r.7a) is populated.

The Reaction (MedDRA code) field is required if the MedDRA Version for the Reaction field contains a value.

Required if Age of Parent (unit) (D.10.2.2b) is populated.

The Age of Parent (number) field is required if the Age of Parent (unit) contains a value.

Required if Age of Parent (number) (D.10.2.2a) is populated.

The Age of Parent (unit) field is required if the Age of Parent (number) field contains a value.

Required if any data element in the Parent (D.10) section is populated.

The Sex of Parent field is required if any field in the Parent section contains a value.

Required if Medical History (disease / surgical procedure / etc.) (MedDRA code) (D.10.7.1.r.1b) is populated.

The MedDRA Version for the Medical History field is required if the Medical History (MedDRA code) contains a value.

Required if MedDRA Version for Medical History (D.10.7.1.r.1a) is populated.

The Medical History (MedDRA code) is required if the MedDRA Version for the Medical History field contains a value.

Required if Indication (MedDRA code) (D.10.8.r.6b) is populated.

The MedDRA Version for the Indication field is required if the Indication (MedDRA code) contains a value.

Required if MedDRA Version for Indication (D.10.8.r.6a) is populated.

The Indication (MedDRA code) field is required if the MedDRA Version for the Indication field contains a value.

Required if Reactions (MedDRA code) (D.10.8.r.7b) is populated.

The MedDRA Version for the Reaction field is required if the Reaction (MedDRA code) contains a value.

Required if MedDRA Version for Reaction (D.10.8.r.7a) is populated.

The Reaction (MedDRA code) field is required if the MedDRA Version for the Reaction field contains a value.

Required if H.3.r.1b (Sender's Diagnosis / Syndrome and / or Reclassification of Reaction / Event (MedDRA code)) is populated.

The MedDRA Version for the Sender's Diagnosis , Sender’s Syndrome and / or Reclassification of Reaction / Event is required if any corresponding MedDRA Code field contains a value.

Required if H.3.r.1a (MedDRA Version for Sender's Diagnosis / Syndrome and / or Reclassification of Reaction / Event) is populated.

The MedDRA Code for the Sender's Diagnosis , Sender’s Syndrome and / or Reclassification of Reaction / Event is required if any corresponding MedDRA Version field contains a value.

Required if H.5.r.1a (Case Summary and Reporter’s Comments Text) is populated.

The Case Summary and Reporter’s Comments Language fields are required if the Case Summary and Reporter’s Comments Text fields contain a value.

Ignore Validation Results

When a validation criteria rule evaluates as a fail or warning, you can ignore the validation result for the given criteria for any subsequent evaluations of that case or transmission. This option allows for submissions without deleting any case data, even when the evaluation returns validation failures, which helps to ensure ‌submissions are not blocked.

Prerequisites

An administrator must perform the configurations in Enable Ignore Validation Rule to use this feature.

Ignore Validation Results for a Case

  1. Go to Cases and select the case you want to submit.
  2. In the Validation Results (Failures & Warnings) section, select menu-button next to any validation results you want to ignore.
  3. Select Ignore Validation Result. Note that you can include this validation result in evaluations again by selecting Activate Validation Result.

Result

The system ignores the respective validation results for the Case and its associated Transmissions. The Case can now be submitted, considering all other criteria are met. The summary record will not include the validation result.

Ignore Validation Results for a Transmission

  1. Go to Transmissions > Distributions or Submissions.
  2. Select a Transmission.
  3. In the Validation Results (Failures & Warnings) section, select menu-button next to any validation results you want to ignore.
  4. Select Ignore Validation Result. Note that you can include this validation result in evaluations again by selecting Activate Validation Result.

Result

The system ignores the respective validation results for that Transmission only. The summary record will not include the validation result.

Assign Hard Fail to Validation Rules

We recommend that an administrator configure the following Result Status Types to be “Hard Fail”:

  • ICH.C.1.3-1
  • ICH.C.1.3-2
  • ICH.C.1.4-1
  • ICH.C.1.4-2
  • ICH.C.1.4-3
  • ICH.C.1.5-1
  • ICH.C.1.5-2
  • ICH.C.1.5-3
  • ICH.C.2.r.3-1
  • ICH.C.2.r.3-2
  • ICH.C.5.4-1
  • ICH.C.5.4-2
  • ICH.D.1
  • ICH.E.i.4-1
  • ICH.E.i.4-2
  • ICH.E.i.7-1
  • ICH.E.i.7-2
  • ICH.G.k.1-1
  • ICH.G.k.1-2
  • ICH.G.k.2.2

Note that this is a recommended list. You may choose to add more or less of these depending on your business’s evaluation of severity of each validation criteria.

  1. In the Admin area, go to Business Admin > Validation Criteria.
  2. Select [Validation Criteria].
  3. Select Hard Fail from the Result Status Type field.
  4. Select Save.

An administrator must also configure workflow transitions for Case validations.

Data Entry Validation

In addition to validating E2B XML during file generation, Vault Safety validates certain fields during Case data entry to prevent issues that would generate an invalid E2B file.

Value and Unit Field Validation

The system validates all standard (system-provided) combined Value and Unit fields.

When a field contains invalid data, the system prevents you from saving the record and marks the field with an Invalid label.

See the following example, where the Weight field has a unit but no value:

Invalid Data Tag
Invalid Data Tag

Reason Omitted Field Validation

The system validates standard (system-provided) Reason Omitted (nullFlavour) fields, with the exception of those listed below. Reason Omitted fields allow you to select only valid NullFlavour values, according to E2B specifications.

Data Entry Validation Limitations

Note the following limitations for data entry validation:

  • Custom (non-standard) fields are not validated.
  • The following Reason Omitted (nullFlavour) fields are not validated or filtered to valid values:
    Object or Document Type Field
    Case Contact Object Country (reason omitted) (country_reason_omitted__v)
    Case Object Medical History Text (reason omitted) (medical_history_text_reason_omitted__v)

    Note To comply with E2B specifications, ensure Case page layouts include the Medical History Text app control-type field, which is filtered to valid values for Reasons Omitted. For more information see Update the Case Page Layout for Reasons Omitted for Medical History Text.
    Case Object Study Name (reason omitted) (study_name_reason_omitted__v)
    Case > Source > Literature Document Type Reference (reason omitted) (reference_reason_omitted__v)

Prerequisites for E2B XML Validation

While E2B XML validation is automatically available in all vaults, we recommend that an administrator performs the following configuration to prevent the Submit to Gateway action when the system detects a validation error.

  • Read More...
    1. In Admin, go to Configuration > Object Lifecycles > Transmission Lifecycle.
    2. Open the Validation Error lifecycle state.
    3. Under Atomic Security: Actions, select Edit.
    4. For the Submit to Gateway action, change the State Behavior to Hide.
      Change Submit to Gateway Behavior to Hide
      Change Submit to Gateway Behavior to Hide

Trigger E2B XML Validation

To validate an E2B file, generate an EMA E2B (R3), FDA E2B (R2), or HC E2B (R2) file from a Transmission (Submission or Distribution) record.

The system validates files generated using either of the following methods:

  • Manually with the Generate Transmission Document(s) user action.
  • Automatically as part of a Submission or Distribution workflow.

Note The system does not validate E2B files generated from the Case.

Notifications

The system notifies the appropriate user if the system found errors during validation with a vault notification and email. These notifications are sent in addition to notifications about the success or failure of generating the transmission file.

The following list describes which users receive notifications:

  • If the file was generated manually with a user action, the system notifies the user who started that action.
  • If the file was generated automatically through a workflow, the system notifies Distribution Manager users for the Transmission Organization.
  • Otherwise, the system notifies the System Admin user group.

Resolve Validation Errors

Once the Submission record enters the Pending state, the system generates an E2B XML file and immediately validates it against the corresponding schema. At the same time, the Review Submission workflow starts, and the Distribution Manager should accept their task as they do in their standard workflow.

If there are validation errors, the Submission record lifecycle state changes to Validation Error. The Distribution Manager must review and fix the validation errors attached in the .csv file. Once the errors are resolved, the Distribution Manager must regenerate the transmission documents.

If there are no further validation errors, the system removes the attached validation .csv file and you can proceed with completing the Submission workflow.

If there are new validation errors, the appropriate user receives a notification and a validation .csv file replaces the previous attachment.

E2B Error Message Guide

The following tables describe the E2B validation errors you may encounter, and the possible cause of each error message.

EMA E2B R3 Error Messages

Error Possible Cause
cvc-complex-type.2.4.a: Invalid content was found starting with element 'responseModeCode'. One of '{urn:hl7-org:v3:creationTime}' is expected. The Submission record is missing a value in the Transmission Date field.
cvc-complex-type.2.4.a: Invalid content was found starting with element 'creationTime'. One of '{urn:hl7-org:v3:realmCode, urn:hl7-org:v3:typeId, urn:hl7-org:v3:templateId, urn:hl7-org:v3:id}' is expected. The Submission record is missing a value in the E2B Message ID field.
cvc-complex-type.2.4.a: Invalid content was found starting with element 'controlActProcess'. One of '{urn:hl7-org:v3:sequenceNumber, urn:hl7-org:v3:attachmentText, urn:hl7-org:v3:receiver}' is expected. A Transmission Profile was not found. Either the Transmission Profile was not configured, or it was not assigned to the Submission record correctly. Verify the Transmission Profile field on the Submission record links to a Transmission Profile, and verify the record is set up correctly.
cvc-complex-type.2.4.b: The content of element 'MCCI_IN200100UV01' is not complete. One of '{urn:hl7-org:v3:PORR_IN049016UV, urn:hl7-org:v3:PORR_IN049017UV, urn:hl7-org:v3:PORR_IN049018UV, urn:hl7-org:v3:receiver}' is expected. A Transmission Profile was not found. Either the Transmission Profile was not configured, or it was not assigned to the Submission record correctly. Verify the Transmission Profile field on the Submission record links to a Transmission Profile, and verify the record is set up correctly.

FDA and HC E2B R2 Error Messages

Error Possible Cause
The content of element type ichicsrmessageheader must match (messagetype, messageformatversion, messageformatrelease, messagenumb, messagesenderidentifier, messagereceiveridentifier, messagedateformat, messagedate). The message header is not formatted correctly due to missing Submission details. For example, the Submission record may be missing values in the Transmission Date or E2B Message ID fields.
E2B Generation Data Mapping
Understand the Reporting Rules Engine
Next →

Related Docs

Feedback?