HelseID Client

HelseID is an authentication mechanism for the health sector developed by Norsk Helsenett. Read more about HelseID on the Norsk Helsenett website or on the HelseID self‑service portal. Technical documentation and additional information are available on the HelseID developer portal page.

HelseID is based on legal delegation of data‑processing rights from the organisations that own the data. Read about the link to message addressing and the implicit scope of these rights on the HelseID considerations page.

EDI 2.0 uses client credentials, meaning that the client itself is authenticated, not a logged‑in user.

Requirements for Setup in HelseID

Client system:

• You must have a registered client system ("klientsystem") in HelseID.
• The client system must allow "API calls" as an authentication option.
• The client system must support "Meldingstjener REST API" with nhn:msh as audience.
• The organisation you will exchange messages for must delegate HelseID rights in Altinn. That organisation — or a sub‑organisation — must be listed as the virksomhet in the Address Registry that owns the service acting as the addressee in the exchange.

Client configuration:

• You must create a client configuration ("klientkonfigurasjon") from the client system.
• The client configuration must include nhn:msh/api as a scope.
• The client configuration must contain herid as an API‑specific claim (see the explanation below).
• The client configuration must be manually approved before it can be used in production.

Requirements for Code When Authenticating Against HelseID

EDI 2.0’s test environment uses HelseID’s test environment, the production environment uses HelseID’s production environment.

EDI 2.0 requires both a token and a DPoP proof from HelseID. Read more about DPoP on the HelseID developer portal page. As a client of EDI 2.0 you must generate access tokens and the corresponding DPoP proof, and use them both in your API calls to EDI 2.0.

About the API‑Specific Claim herid

The API‑specific claim herid will be phased out. Read more about this claim on the HelseID considerations page.

The functionality of this claim has been deprecated in API version 3. While the claim herid is still required in HelseID, you may provide the value 0.

Tips

In the test environment you can use HelseID’s test‑token service ("test-token-tjenesten") to obtain a token and the associated DPoP proof. This is simpler than configuring a full client system and is handy if you just want to explore what EDI 2.0 can do. For production, however, you will need to develop a real HelseID integration for the test environment first. Read more about the test‑token service on the HelseID developer portal page.

The easiest way to create a client system is to use HelseID’s self‑service solution (test, production). Deploying a client in the test environment can be done via the self‑service solution’s test environment.

HelseID provides its own client libraries for .NET (GitHub) and Java (GitHub) that implement their security profile. Publicly available sample code is also made available (GitHub).

Security documentation and code review with HelseID are required as part of the production rollout of a client system. Some waiting time should be expected for such a review. Perhaps a couple of weeks (unofficial estimate).

Example of a client configuration in HelseID self‑service, using the Message Server SHP REST Test client as the client system. This client configuration is scoped to HER‑Id 8142092 through the API‑specific claim herid.