Two different client patterns

This document describes the difference between the multi-tenant and single-tenant client patterns, and the usage of each of these patterns.

Single-tenant clients

In HelseID, a single-tenant client is a software installation that is used by one consumer (e.g. a GP’s office or a municipality) only. This kind of software will typically be an electronic health record system, installed on a single server.

This implies that when the software is set up to use HelseID, the consumer must use HelseID Selvbetjening to get a client ID for the software. By doing this, the consumer will then be given the right for usage of HelseID. It also implies that the client ID has a one-to-one connection to the consumer's organization, specifically the consumer's organization number. This organization number allows HelseID to check whether the consumer has signed the required documents for use of any API's the software installation needs to consume.

Multi-tenant clients

Multi-tenancy is an architecture pattern that allows multiple consumers of a software vendor to use the same instance of the vendor’s software. This system can also be an electronic health record system, but is typically set up as a SaaS (Software as a Service) system. The consumers share the usage of this system, but are unaware of each other. The system is served by a supplier, e.g. a software company that delivers a SaaS-type EHR system.

The initial stage for creating this pattern is that the consumer (e.g. a GP’s office or a municipality) delegates a right to the supplier (the software company that for instance delivers a SaaS-type EHR system). This right allows the supplier to use HelseID for its software on behalf of the consumer.

Delegation

The implication of this is that when a logged-in user accesses a service (e.g. SFM) where the system uses the OAuth 2 protocol through HelseID, a claim that indicates the organization number for the Consumer that the user represents can be present in the access token.

Organization claim

What pattern should I use?

In some cases, an API will set spesific demands for a client. The client may need special functionality in order to use this API.

APIs My software is a SaaS-type My software is set up as local installations
SFM You will need to send an SFM-id in the request to HelseID
Kjernejournal You must use the new login service for Kjernejournal
VKP The VKP service does not yet have the ability to use multi-tenant clients
Persontjenesten

Usage of organization numbers

If an API that the client consumes needs an organization number in the Access Token, there exists separate mechanisms, regarding whether the client is single- or multi-tenant.