HelseID Considerations

HelseID is built on the delegation of data‑processing rights from a top‑level organisation in Altinn. The delegation performed in HelseID has only a single access level: you either receive access to everything under the organisation, or you receive no access at all.

The technical delineation of which actors process data in the EDI/EbXml regime takes place in the Address Registry ("Adresseregisteret"), where various suppliers and individuals can be granted access to specific registered entities through a role‑based login system.

Linking HelseID to the Address Registry

By default there is no connection between the Address Registry and HelseID delegation.

EDI 2.0 manages and verifies API calls against entries in the Address Registry, so that an authenticated HelseID access can be associated with a set of communication parties ("kommunikasjonsparter"). The entity under which the communication parties are registered in the Address Registry always has an organisation number. Any API client using EDI 2.0 will only be authorised to interact with a message or on behalf of a communication party if either:

• The organisation number found in the Address Registry belongs to the top-level unit that delegated access to the HelseID-client making the call, or:
• The organisation number found in the Address Registry belongs to a sub-unit of that top-level unit.

EDI 2.0 verifies this connection to a top-level delegating unit.

Authorization of Requests Is Based on Organisational Membership

Because of the single access level in HelseID, a HelseID client with delegated rights is implicitly permitted to interact with all Address Registry communication parties belonging to that top-level organisation. This means your API client may be authorized to fetch, read, and acknowledge messages that technically (though not legally) should be received by someone else.

Reserving a Communication Party with Your HelseID Client

You may configure a communication party (by its HER-Id) to only be accessible by your HelseID client. The technical documentation is available on the configuration endpoint page. Setting this configuration, prevents other HelseID clients to interact on behalf of the communication party being configured.

This configuration will need to be removed, or at least un-reserved when your domain application relinquishes responsibility for a communication party.

If you don't lock the communcation party HER-Id to your HelseID client, you technically run the risk of other applications/EPJs with rights delegated from the top-level organisation interfering with the communication party. Someone else (in the same top-level organisation!) may:

• Send messages on behalf of "your" communication party.
• Download messages to "your" communication party.
• Mark messages to "your" communication party as downloaded (which may trigger the message to be deleted from EDI 2.0).
• Send application receipts for messages to "your" communication party.
• Change the MSH configuration of "your" communication party.

This situation is most likely to occur in the largest top-level entities, such as a county ("Kommune"). Overall, the probability of such a severe misconfiguration or ill-intended attack are probably quite low anyway.

The API‑Specific Claim herid

The herid claim in HelseID clients that connect to EDI 2.0 will be phased out, because API‑specific claims in HelseID are are being phased out too.

The purpose of this claim was to handle scoping of HelseID-delegated rights within an organization, selecting specific HER-Ids to be included in the claim. This approach turned out to be unsuccessful for all but the simplest of cases. Users of version 3 of the EDI 2.0 API should reserve its communication parties with configuration instead, like stated above.

For as long as the API-specific claim herid exists and is mandatory in HelseID (as long as some clients still use version 2), you may put the value 0 in your HelseID-configuration, which grants access to the entire organisation.