Setup in the Address Registry

Requirements for Setup in the Address Registry

• You must have an organisation registered as a "virksomhet" in the Address Registry. The associated organisation number must be the same, or belong to a legal sub‑unit of the organisation that is authenticated in the HelseID client configuration. Read about HelseID on the HelseID prerequisites page.
• You must have (at least) one client registered as a "tjeneste" in the Address Registry, as a sub‑unit of the business.
• The service must have EDI 2.0’s EDI address and business certificates ("virksomhetssertifikater") registered – either as part of its own registration or inherited from the virksomhet registration*.

* If you are only sending messages to other communication parties that are also users of EDI 2.0, then this point is not necessary. However, in most cases you won't know all the communication parties your application will need to communicate with ahead of time. Your communication party does in any case have to exist in the Address Registry.

Addresses per Environment

EDI 2.0’s test environment uses the Address Registry’s test environment. EDI 2.0’s production environment uses the Address Registry’s production environment. The relevant EDI addresses for each environment are:

* For the time being a shared EDI address is used for all EDI 2.0 users, but this may change in the future.

Explanation

The Address Registry is a register of addressing information used in message exchange within the health sector. Each registration is called a communication party ("kommunikasjonspart").

The usually correct setup (there are exceptions) in the Address Registry is:

• An organisation linked to health care is listed with the type "virksomhet".
• A health service organised under that organisation is listed with the type "tjeneste", as a sub‑unit of the business.

To send messages through the EDI 2.0 API, the EDI 2.0 message handler must take over the message handler responsibility from the API user. In practice this happens when the addressing information for the relevant communication parties is changed to EDI 2.0’s addressing information. The relevant addressing data that must be changed is the information needed to send using the EbXml standard (HIS 1037:2011) over the EDI protocol, which many in the sector use.

Specifically, the EDI address and business certificates ("virksomhetssertifikater", separate for encryption and signing) for each service must be registered as belonging to EDI 2.0.

Addressing information can be registered individually for each service, or for the business as a whole. You can configure the system so that the addressing information registered for a business is inherited by the services that belong to that business.

A unique HER‑Id is registered for each communication party. When making API calls you should use the tjeneste HER‑Id to identify which communication party’s messages you want to interact with. In general you should not use the virksomhet HER‑Id in the addressing, because EDI 2.0 follows service‑based addressing ("tjenestebasert adressering", HIS 1153:2017). Some actors in the sector nevertheless deviate from the standard at this point.

Read more about the Address Registry on the Norsk Helsenett website.

Example of a communication party in the (test) Address Registry linked to EDI 2.0’s test environment (as of 14 October 2024).