Publisert - 24.04.2026

Message Status

For detailed technical specifications, please refer to the Swagger documentation.

Get Status of a Message You Have Previously Sent

GET /messages/{id}/status

Provide the id of the message returned by the POST /messages endpoint. Returns an array of statusInfo objects for each receiver of the message.

Response

Property Type Description
statusList StatusInfo[] One entry per receiver (including copy‑receivers).
StatusInfo.receiverHerId integer HER‑Id of the receiver for which this status applies.
StatusInfo.transportDeliveryState enum DeliveryState Transport outcome:
Unconfirmed – awaiting confirmation by receiver.
Acknowledged – transport acknowledged by receiver.
Rejected – transport rejected by receiver.
Abandoned – transport abandoned after sending attempts failed.
StatusInfo.sent boolean true if the message was successfully handed over to the transport layer for this receiver.
StatusInfo.apprecInfo ApprecInfo (nullable) Contains information of the application receipt (if any) that the receiver has sent back to you.
ApprecInfo.appRecStatus enum AppRecStatus "Ok" – message accepted by receiver.
"Rejected" – message rejected by receiver.
"OkErrorInMessagePart" – currently not supported.
ApprecInfo.appRecErrorList AppRecError[] (nullable) Detailed error codes when appRecStatus is "Rejected".

Explanation of Status Types and Values

transportDeliveryState

The transportDeliveryState field indicates the transport or delivery status of the underlying transport protocol. This type is designed to be compatible with the possible receipt situations defined in the EbXml standard (HIS 1037:2011) for sending over EDI. The following values are possible:

  • Acknowledged – The message has been accepted at the transport level.

    • If the receiver uses EDI 2.0, the message is available for retrieval via API calls. This should always be the case when exchanging between two EDI 2.0 clients.
    • If the receiver uses traditional EDI, we have received a positive transport acknowledgment (“Acknowledgement”) from that receiver.

  • Rejected – The message has been rejected at the transport level.

    • If the receiver uses EDI 2.0, this status can only occur if the receiver has explicitly configured EDI 2.0 to reject the message you sent as "not supported".
    • If the receiver uses traditional EDI, we have received a negative transport acknowledgment (“MessageError”) from that receiver. The receiver’s message handler has rejected the message due to reasons related to the EDI exchange or the EbXml protocol.

  • Unconfirmed – The message has not been responded to at the transport level.

    • If the receiver uses EDI 2.0, the message is still being processed.

    • If the receiver uses traditional EDI, we have not received any transport acknowledgment (neither negative nor positive) from that receiver.

      • This could mean the message is still being processed by the EDI 2.0 message server.
      • This could mean the transport acknowledgment from the receiver is malformed, and cannot be read or correlated with the message.
      • This could mean the message was lost somewhere in the EDI transport.
      • This could mean the receiver has received the message but has not responded.

    • Messages with transportDeliveryState=Unconfirmed that are destined for a traditional EDI receiver will be re‑sent periodically. More details on the EbXml standard implementation page.

sent

The sent field is the internal transport status within the EDI 2.0 message handler. It is a boolean value:

  • true – The message has been fully processed by the message server and is "sent" in the traditional sense.

    • If the receiver uses EDI 2.0, the message is available for retrieval via API calls. This should always be the case when exchanging between two EDI 2.0 clients.
    • If the receiver uses traditional EDI, we have sent the message out (SMTP). Whether the message has been acknowledged is indicated by transportDeliveryState.

  • false – The message is still being processed by the message server. If this status persists, it indicates an error that must be investigated by NHN.

appRecStatus

The appRecStatus field reflects the status exchanged between clinical applications (application receipt). The value corresponds to codes standards (8258) as defined in the standards for application receipts version 1.1 (HIS 80415:2012) and version 1.0 (HIS 80415:2004). The possible values are:

  • Ok – Equivalent to "OK". The receiving application reports that the business document has been received, can be interpreted correctly, and is ready for further processing.

  • Rejected – Equivalent to "Avvist". The receiving application reports that the business document cannot be interpreted, or for some other reason will not be accepted into the system for clinical handling.

  • OkErrorInMessagePart – Equivalent to "OK, feil i delmelding". Only used for messages of type "behandlerkravmelding" used by Helfo. The clinical system reports that the overall message is accepted, but one of the message parts contained an error and therefore will not be entered.

If appRecStatus is anything other than Ok, the receiver must specify the reason for the rejection. This information is found in the property appRecInfo.appRecErrorList, or in the AppRec business document itself.

Søk i Utviklerportalen

Søket er fullført!