HelseID and SFM: principles for use

HelseID is a separate product from NHN and general information is available in this Utviklerportalen.

An access token from HelseID is placed as a bearer token in http Authorization header. This token contains the following information necessary for SFM to determine the instance, and subsequenty perform an access control.

  • journal-id or SFM-id. journal-id takes preference, and is generally mandataory for multi-tenancy tokens.
    • e-helse:sfm.api/client/claims/sfm-id
    • nhn:sfm:journal-id
  • aud : must be e-helse:sfm.api
  • scope : must contain one of the SFM scopes
  • helseid://claims/client/claims/orgnr_parent - allways containing the top level of an organization, or "etat" in a norwegian kommune. Similar field for orgnr_child is optional. SFM will first try to match the lower level
  • helseid://claims/identity/pid - national id of person logged in. Appears together with at least one of the two level indicatiors for strong identity
  • helseid://claims/identity/security_level must be 4
  • helseid://claims/identity/assurance_level must be high
  • helseid://claims/client/client_tenancy is multi, single or missing, in case interpreted as single.
  • helseid://claims/client/claims/orgnr_supplier indicates the owner of the helseID client, usually vendor or supplier org. This number MUST correspond to a preregistered supplier in SFM.

Furthermore, the standard fields as issuer an expiration are all a part of token validation.

Why the jornal-id?

The simple answer is that the world is complex, and SFM is flexible. The journal-id and its predecessor SFM-id indicates a stable id for one journal system over time. Technically there is an many to one association, as one SFM instance may have multiple journal-id's pointing to it. The mechanism covers:

  • orgnaization changes, including transfer of activity from one organization to a norwegian
  • HelseID transitions
  • multiple EHR systems in the same organization. journal-id will select the correct journal/SFM-instance, from otherwise equal tokens.
  • and more

Multi or single tenancy

As single tenancy was the only option in early adoption, the choice is now on the vendor. Obviously, when running a web-based multi tenant system, the managemente will be more efficient with a multi tenant client. For systems installed "on site", the opposite choice is natural, and there will be a mix between. For each HelseID client there is a secret with limited lifetime, and that is probably one major driver for transition from single to multi tenancy.

What is new for multi tenant systems in SFM?

The three important things to notice are:

  • Vendors using multi tenant systems must preregister to SFM with the organization number appearing in orgnr_supplier. In test this may be done by an email to kundersenter@nhn.no or by other effective channels.
  • Vendors must provide functionality for creating and maintaing the journal-id for their customers, including inheriting from other vendors for new customers.
  • Include the journal-id in the token request to HelseID. See HelseID documentation for details.