HelseID and SFM: principles for use
HelseID is a separate product from NHN and general information is available in HelseIDs pages here in Utviklerportalen.
You as a vendor need to implement support for HelseID before you are able to use SFM. Note that HelseID has its own approval-process that is required.
Multi or single tenancy
There are two different client patterns that can be used in HelseID: Multi or singe 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 management will be more efficient with a multi tenant client. For systems installed "on site", the opposite choice might be more natural. 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. For production then please contact your SFM contact person. - 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.
Specific integration requirements need to be adopted before using multitenant in SFM.
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
The Token
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
orSFM-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 bee-helse:sfm.api
scope
: must contain one of the SFM scopeshelseid://claims/client/claims/orgnr_parent
- allways containing the top level of an organization, or "etat" in a norwegian kommune. Similar field fororgnr_child
is optional. SFM will first try to match the lower levelhelseid://claims/identity/pid
- national id of person logged in. Appears together with at least one of the two level indicatiors for strong identityhelseid://claims/identity/security_level
must be4
helseid://claims/identity/assurance_level
must behigh
helseid://claims/client/client_tenancy
ismulti
,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.