EbXml Standard

EDI 2.0 implements the EbXml standard (HIS1037:2011) for communication with parties that do not use EDI 2.0. A key part of the standard is that the transport of a message must be acknowledged at the transport level (in addition to the application level).

When the EDI 2.0 message handler receives an EDI MIME message over SMTP, the message may contain critical errors that cause it to not be delivered to the recipient. If the message is readable, a few fundamental principles - mainly concerning security and addressing - are validated. Any violation can lead to the message being rejected with a MessageError. If there are no errors, a positive transport acknowledgement (Acknowledgement) is returned.

When the EDI 2.0 message handler is sending an EDI MIME message over SMTP, it awaits a transport-level receipt from the recipient's message handler. If none is received, we will try to re-send the message.

All messages containing clinical information have their content encrypted in a MIME-part with type pkcs7-mime. All messages, including receipts, contain a digital signature. For communication over EDI with the EbXml standard, the EDI 2.0 message handler handles encryption, decryption, signature production and verification. All certificate public information used for these procedures are the ones provided in the Address Register.

Handling of a Received Message Duplicate

• Mime duplicate – If a message arrives with a Mime header Message‑id identical to one that has already been received, the message will not be processed.
• EbXml duplicate – If a message arrives with an EbXml eb:MessageId identical to one that has already been received, the message will not be processed. If the message requires a transport acknowledgement, the same acknowledgement as for the original message will be sent again.

Validation Rules for a Received Message

Below is a list of what is checked when EDI messages are received (via SMTP). If one or more messages are found with severity Error, the message is rejected, not delivered to the recipient, and a MessageError is sent back to the sender.

Message types in the table above

• EbXml – Regular EbXml message with a clinical payload (e.g., a "epikrise" or "henvisning").
• Acknowledgement – A positive transport receipt.
• MessageError – A negative transport receipt.
• All – Applies to all three types listed above.

Abbreviations used in the table

• AR = Address Registry.
• MSH = Message Handler / EDI 2.0.
• Payload = Clinical message or "BusinessDocument" – the part of the message that contains the clinical information, for example, a "epikrise" or "henvisning".
• HIS1153 = Service‑based addressing ("Tjenestebasert adressering", HIS 1153:2017).
• HIS1037 = Framework for electronic message exchange in health care ("EbXml rammeverk", HIS 1037:2011).

Re‑Sending

Messages that have not received an acknowledgement (Acknowledgement or MessageError) will be resent.

• We check once per hour which messages need to be resent.
• We resend all messages that are at least 12 hours old since the last sending attempt.
• Up to 5 resend attempts are made.
• Consequently, a message can be in an EDI transaction for up to 72 hours.
• After that we give up on the exchange. This triggers the status delivery state to be "Abandoned".

Encryption and Signing

We encrypt the business document itself with symmetric AES‑256 (256‑byte key) in CBC mode (OID=2.16.840.1.101.3.4.1.42). The allowed recipient (CmsRecipient) is encrypted with SHA256RSA using their public certificate.

We create a signature using SHA256RSA with our private certificate.

Default Values for EbXml and System Metadata

You can specify values for the content of the EbXml envelope as metadata when you send a message. See the sending messages endpoint page for details. If these are not supplied, EDI 2.0 will use the following defaults:

• Service, Action and Role (HIS 1209:2018) are derived from the business document's content.
• MshSystem (HIS 1210:2018): Norsk Helsenett Meldingstjener.
• MshVersion (HIS 1210:2018): v1.0.
• AppSystem (HIS 1210:2018) is passed on from the API request body.
• AppVersion (HIS 1210:2018) is passed on from the API request body.

Procedure for Identifying Sender and Receiver in the EbXml Envelope When Addressing Deviates

The correct way to specify the sender in EbXml is to place a single integer HER‑Id value in the XML path <From>/<PartyId type="HER">. The correct way to specify the receiver is to place a single integer HER‑Id value in the XML path <To>/<PartyId type="HER">. When we receive EDI messages that contain addressing deviations, we still want to identify the actual communication parties so that we can inform you, the receiver, that a message with a deviation has been sent to you. The deviation is reported back to the sender by sending a MessageError, but only if the sender is also identifiable.

• If there is exactly one occurrence of <PartyId type="HER">, the communication party is taken from its value.

• If there are multiple occurrences of <PartyId type="HER">, the communication party is taken from the value in the first occurrence.

• If no <PartyId type="HER"> elements are found, we will try to look for <PartyId type="ENH"> elements.

  • If there is exactly one <PartyId type="ENH">, the communication party is taken from its value.
  • If there are multiple <PartyId type="ENH">, the communication party is taken from the value in the first occurrence.

• If neither <PartyId type="HER"> nor <PartyId type="ENH"> elements are present, we give up on identifying the communication party.

After we have identified a communication party (including those that were correctly addressed in EbXml), we will attempt to retrieve the required information about that party from the Address Registry. It is a prerequisite that the communication party has sufficient information registered for us to carry out the exchange.

To look up information about a communication party, we must be able to parse the value in the EbXml envelope as an integer.