Vault Safety supports receiving E2B(R2) and (R3) files from AS2 Gateway trading partners or through the Vault API.
Note: Depending on your Admin’s configuration, object, field, and section labels, lifecycle states, and workflows may differ from the general information on this page. Refer to your organization’s business processes for guidance.
Receiving E2B Transmissions
When Vault Safety receives an E2B Transmission, the system imports the E2B file and automatically creates an Inbox Item for each Case in the E2B file.
Vault Safety can receive single or multi-case E2B Transmissions from the following sources:
- E2B files sent through the Vault API Intake Inbox Item endpoint
- Incoming AS2 Gateway Transmissions
During E2B Transmission import, Vault Safety validates the data against the Transmission Profile’s Validation Criteria. For each Transmission Profile, your Admin can configure the Validation Criteria based on the Sender.
Prerequisites
Before you can receive E2B Transmissions from a trading partner or health authority, your Admin must set your Vault up to communicate with the sender:
- For inbound AS2 Transmissions, your Admin must configure an AS2 Connection and Transmission Profile with the appropriate Origin and Destination pair.
- For the Intake Inbox Item API endpoint, your Admin must Configure Your Vault for the Intake Inbox Item API.
To validate the E2B Transmission data against sender-based validation rules, your Admin must:
E2B Receive Process
The following image shows how Vault Safety processes incoming E2B Transmissions:
When Vault Safety receives an E2B Individual Case Safety Report (ICSR) from an AS2 gateway or API Transmission, the system performs the following actions:
- Creates an Inbound Transmission record.
- Adds the Transmission documents to the Library, including:
- The E2B file
- Narrative and translations
- Attachments
- Initiates the import E2B process to create an Inbox Item from the E2B file.
- Performs data conformance checks on the incoming E2B(R2) or (R3).
See the E2B Transmission Data Conformance Validations section for more information. - Performs sender-based inbound validation (if enabled and configured).
You can access the validation results for each Validation Criteria and a validation summary file in the Inbound Validation Result section of the Inbox Item. - Creates the Inbox Item.
- Generates an ICSR acknowledgment, which is attached to the Inbound Transmission.
- For Gateway Transmissions, automatically returns the acknowledgment to the sender.
For E2B Import mapping, see E2B Case Import Data Mapping.
Data Conformance Validations
Before the system validates the incoming E2B file based on the configured Validation Criteria on the Transmission Profile, it performs data conformance checks.
The following table provides the list of conformance checks based on whether the Enable Sender-Based Inbound Validation setting is enabled:
| Enabled | NOT Enabled |
|---|---|
| For any date field, if the minimum date precision is not met, the system still imports the date. | For any date field, if the minimum date precision is not met, the system does not import the field and will provide a warning. |
| For fields with a value and unit, if either the value field or unit field is left blank, the system imports the populated field. | For fields with a value and unit, if either the value or unit field is missing, the system does not import the populated field and will provide a warning. |
For any text field, if the text value exceeds the maximum length of characters, the import fails and a NACK (commit rejected or CR) is sent to the sender (if a Gateway Transmission). |
Same as enabled. |
| For any number field, if the number value falls outside the minimum-maximum range, the import fails and a NACK is sent to the sender (if a Gateway Transmission). | Same as enabled. |
| For decimal number values, if the value exceeds the maximum number of decimal places, the import fails and a NACK is sent to the sender (if a Gateway Transmission). | For decimal number values, if the value exceeds the maximum number of decimal places, the system truncates the value without providing a warning. |
If the Enable Sender-Based Inbound Validation setting is enabled, the system generates a validation summary file with the failed validations and attaches it to the Inbound Validation Result section on the Inbox Item. For E2Bs that failed to import, the corresponding Inbox Item is set to the Import Error state.
Acknowledgment Generation
When an Inbox Item is imported from an E2B file, Vault Safety generates an ICH-compliant E2B ICSR acknowledgment in the same E2B format the file was received in. Vault Safety supports generating both E2B(R2) and (R3) ACKs.
For Gateway Transmissions, the system automatically returns the acknowledgment to the origin Gateway.
For API Transmissions, a separate API call (Retrieve Job Status) returns the acknowledgment.
You can also view the acknowledgment on the Inbound Transmission record, attached to the Case imported from the E2B file.
View the Acknowledgment
- From the Inbox, open the Inbox Item received from an E2B Transmission.
- Expand Inbound Transmissions.
- Open the Inbound Transmission, and then expand Transmission Messages.
- Open the Transmission Message.
The acknowledgment file is an attachment on the Transmission Message. - To view the acknowledgment, select Message Body.
Result
A window appears displaying the acknowledgment.
ACK Generation Mapping
Review the following sections to learn how Vault Safety generates E2B R3 and R2 ACKs:
E2B R3 ACK
The E2B (R3) Acknowledgment message is comprised of two sections:
- Message Header Section, which contains:
- ACK.M Section ICSR Batch Acknowledgment Header
- ACK.B section ICSR Message Acknowledgment Header (repeated for each report in the file)
- ACK.A Section ICSR Batch Acknowledgment Header
The following sections describe how Vault Safety maps information to populate the E2B (R3) ACK.
M.1 ICSR Message Header
| E2B Data Element Name | Populated Value |
|---|---|
| ACK.M.1 Acknowledgement Batch Number | The GUID of the record being created. |
| ACK.M.2 Acknowledgement Batch Sender Identifier | The value from the Destination ID (destination_transmission_id__v) field on the Inbound Transmission (transmission__v). |
| ACK.M.3 Acknowledgement Batch Receiver Identifier | The value from the Origin ID (origin_transmission_id__v) field on the Inbound Transmission (transmission__v). |
| ACK.M.4 Acknowledgement Date of Batch Transmission | The date and time to the second of the ACK generation. |
| ACK.A.1 ICSR Batch Number | The value from the E2B Message ID (e2b_message_id__v) field on the Inbound Transmission (transmission__v), which is mapped from data element N.1.2 in the received E2B file. |
| ACK.A.2 Acknowledgement Local Message Number | The message number is populated in the format {transmission__v.name__v}_{GUID}_YYYYMMDDHHMMSS |
| ACK.A.3 Date of ICSR Batch Transmission | The value from the Transmission Date (transmission_date__v) field on the Inbound Transmission (transmission__v), which is mapped from data element N.1.5 in the received E2B file. |
| ACK.A.4 Transmission Acknowledgement Code | An acknowledgment code is populated, based on the result of the E2B Import action.
If the Sender-Based Inbound Validations feature is enabled, an acknowledgment code is populated based on the result of the data conformance and sender-based Validation Criteria checks, and not on the E2B import status. |
| ACK.A.5 Batch Validation Error | If ACK.A.4 is Warning (02) or Failure (03), this element contains the error message. |
ACK.B.r ICH ICSR Message Acknowledgement Header
| E2B Data Element Name | Populated Value |
|---|---|
| ACK.B.r.1 ICSR Message Number | If the inbound E2B file has a Wordlwide UID (C.1.8.1) that matches the Inbox Item UID, this value is mapped from the Inbox Item Worldwide UID (wwuid__v) field. Otherwise, this is mapped from the Case Identifier (name__v) of the Case Identifier (case_identifier__v) where (source__v == case_contact__v.organization__v of type Sender) |
| ACK.B.r.2 Local Report Number | The Name (name__v) of the Inbox Item imported from the E2B file. |
| ACK.B.r.3 ICSR Message ACK Receiver | Identifies the organization that submitted the ICH ICSR message. The value from the Origin ID (origin_transmission_id__v) field on the Inbound Transmission (transmission__v). |
| ACK.B.r.4 ICSR Message ACK Sender | Identifies the organization that received the ICH ICSR message. The value from the Destination ID (destination_transmission_id__v) field on the Inbound Transmission (transmission__v). |
| ACK.B.r.5 Date of ICSR Message Creation | The date the ICSR message was created. |
| ACK.B.r.6 Acknowledgment Code for a ICSR Message | An acknowledgment code is populated, based on the result of the E2B Import action.
If the Sender-Based Inbound Validations feature is enabled, an acknowledgment code is populated based on the result of the data conformance and sender-based Validation Criteria checks, and not on the E2B import status. |
| ACK.B.r.7 Error / Warning Message or Comment | More details about the E2B import warning or failure from ACK.B.r.6, to a limit of 250 characters. |
E2B R2 ACK
The E2B (R2) Acknowledgment message is comprised of two sections:
- Message Header Section
- Acknowledgment Section, which contains:
- Message Acknowledgment
- Report Acknowledgment (repeated for each report in the file)
The following sections describe how Vault Safety maps information to populate the E2B (R2) ACK.
M.1 ICSR Message Header
| E2B Data Element Name | Populated Value |
|---|---|
| M.1.1 Message Type | Populated with ichicsrack |
| M.1.2 Message Format Version | Populated with 1.1 |
| M.1.3 Message Format Release | Populated with 1.0 |
| M.1.4 Message Number | The GUID of the ACK message. |
| M.1.5 Message Sender Identifier | The value from the Destination ID (destination_transmission_id__v) field on the Inbound Transmission (transmission__v). |
| M.1.6 Message Receiver Identifier | The value from the Origin ID (origin_transmission_id__v) field on the Inbound Transmission (transmission__v). |
| M.1.7 Message Date | The date and time to the second of the ACK generation. |
A.1 Message Acknowledgement
| E2B Data Element Name | Populated Value |
|---|---|
| A.1.1 ICSR Message Number | The value from the E2B Message ID (e2b_message_id__v) field on the Inbound Transmission (transmission__v), which is mapped from data element N.1.2 in the received E2B file. |
| A.1.5b ICSR Message Date | The value from the Transmission Date (transmission_date__v) field on the Inbound Transmission (transmission__v), which is mapped from data element N.1.5 in the received E2B file. |
| A.1.6 Transmission Acknowledgement Code | An acknowledgment code is populated, based on the result of the E2B Import action.
|
| A.1.7 Parsing Error Message | If A.1.6 is 03, then this element is populated with "Message cannot be parsed."
|
B.1 Report Acknowledgement
| E2B Data Element Name | Populated Value |
|---|---|
| B.1.1 Safety Report ID | If the inbound E2B file has a Wordlwide UID (C.1.8.1) that matches the Inbox Item UID, this value is mapped from the Inbox Item Worldwide UID (wwuid__v) field. Otherwise, this is mapped from the Case Identifier (name__v) of the Case Identifier (case_identifier__v) where (source__v == case_contact__v.organization__v of type Sender) |
| B.1.3 Local Report Number | The Name (name__v) of the Inbox Item imported from the E2B file. |
| B.1.4 Regulatory Authority's Case Report Number | The value from the Worldwide UID (wwuid__v) field on the Inbox Item, which is mapped from data element A.1.10.1 in the received E2B file. This element is displayed if the Inbound Transmission.First Sender = Regulatory (the file was sent from a regulatory authority). |
| B.1.5 Other Sender's Case Report Number | This is mapped from the data element A.1.10.2 in the received E2B file. This element is displayed if the Inbound Transmission.First Sender = Other (the file was sent from a non-regulatory sender). |
| B.1.7 Date of Receipt of the Most Recent Information | This is mapped from the data element A.1.7 in the received E2B file. |
| B.1.8 Acknowledgment Code for a Report | An acknowledgement code is populated, based on the result of the individual ICSR import.
|
| B.1.9 Error Message or Comment | More details about the specific E2B import warnings or failures encountered, to a limit of 250 characters. |