Frequently Asked Questions
How do I start using EDI 2.0? Who do I contact?
You can begin developing the logic that calls the EDI 2.0 API at any time. For early testing you can obtain mock tokens from the HelseID test‑token service (developer portal link):
Most API endpoints also require adressation (from Adresseregisteret). The domain‑level authorisation in EDI 2.0 validates the HelseID tokens against this adressation.
To start the mercantile process steps that are needed for these integrations, follow the instructions on the Norsk Helsenett site:
https://www.nhn.no/tjenester/elektronisk-meldingsutveksling/edi-og-edi-2.0.
To create or update entries in the Adresseregister, contact Norsk Helsenett customer service ("Kundesenter": kundesenter@nhn.no).
I am new to message handling in the health sector. What do I need to know?
Message handling consists of two separate layers:
- Handling the medical content of a payload, including application receipts.
- Transport of the payload, including transport receipts.
EDI 2.0 is responsible only for the transport layer and the associated transport receipts. All processing of the medical content is left to your medical application.
The basic standards for electronic communication - including the most common message types - are defined by Helsedirektoratet and are available on Sarepta:
- Helsedirektoratet: https://www.helsedirektoratet.no/digitalisering-og-e-helse/referansekatalogen-for-e-helse/grunnleggende-standarder-for-elektronisk-samhandling
- Sarepta: https://sarepta.helsedir.no
Other message types exist. The owners of those exchanges maintain their own specifications.
The standards describe the structure of each message, how recipients must be addressed, and the overall usage patterns. EDI 2.0 implements the EbXml standard (https://sarepta.helsedir.no/standard/EBXML%20rammeverk) for payload transport.
Norsk Helsenett also has its own general guide for electronic message exchange exchange found here:
How should I handle my pre-existing entries in Adresseregisteret? Do I need new ones?
No new entries are required. In production you should update existing entries in Adresseregisteret.
For test environments it can be useful to create separate test entries.
Full‑system and integration tests need a top‑level unit in Adresseregisteret (“virksomhet”) that matches - or is a legal sub‑unit of - the organisation represented in the HelseID token that initiates the request. (The test organisations may be fictitious.) If it is easier to satisfy this requirement with brand‑new test entries, feel free to create them.
Having at least two test entries for EDI 2.0 is recommended - one for sending messages and another for receiving them. If you already have an EbXml message handler, a third entry can be used to point to that handler for three‑way testing.
What do I do with my existing Message Handler ("Meldingstjener"/MSH)? When can I decommision it?
An EbXml message is considered in transit for up to 96 hours. Therefore, after you have deployed an EDI 2.0‑enabled application and migrated all relevant Adresseregister entries, you should keep the old MSH running for at least four full days to receive stragglers.
Reasons to retain the old handler beyond that period:
- Delayed transport: The sender may still be attempting to resend the original message or its transport receipt.
- Stale adress caches: Other parties might have cached an old address from Adresseregisteret and continue to use it.
If you continue to receive messages after four days, keep the MSH active until the flow has fully quieted down. Contact the sender(s) to resolve any issue.
How do I maintain application specific logic for adressation, EbXml envelopes or transport receipts?
- Outbound envelopes: If you need to customise the EbXml envelope you send (e.g., special values for Service, Action, Role, CpaId, etc., when communicating with NAV), EDI 2.0 allows you to override the default parameters on a per‑message basis.
- Inbound envelopes: EDI 2.0 does not provide customisation for the envelopes you receive. The EbXml standard is deliberately strict: a medical application should only need to process the payload, not the transport metadata. EDI 2.0 has a status-checking endpoint that provides the functionality you may want to use envelope-specific logic to solve.
If you have a legitimate requirement for the transport that is not supported, feel free to contact us with details of your case.