Role selector in Bliksund - EWA Insight

This document is targeting customers that can not provide data with a structured link between the user's departments and the assigned role in the OpenIdConnect token.

Why do the Bliksund system need this link?

The patients' medical records in the Bliksund EWA application are connected to a department ID based on the resource (e.g. ambulance) that created the medical record, via the corresponding station and the organization's ID, based on the health trust the station belongs to.

It should be possible to assign rights to a user based on the user's role, to view medical records created in a specific department or organization. The system must know which department a user gained the role from in order to filter medical records based on department/organization.

Solution

A role selector is being implemented in Insight which the user will be redirected to when logging in. The role selector reads all the departments (RESH IDs) from claims in the user's token. These are checked against a configured mapping and presented in a user-friendly way to the user as a list of departments to select from. The role selector also reads all the roles from the token, retrieves user-friendly names based on configured mappings and presents them to the user to select from. The user must select both department and role before they can proceed. If the user only has one RESH ID with mapping and one role with mapping, these will be pre-selected so that the user can proceed with only one click.

Once the user has selected the department and role, it will only be these choices that form the basis for all filtering of medical records and other objects in the EWA system.

RESH ID mapping

The system must contain a configuration to be able to map RESH IDs to user-friendly department names. This mapping must also contain the ID of the organization to which the department belongs.

Eksempel:

reshid	departmentName	organizationId
5432	Bergen, Sentrum sør-vest	983974724
5678	Haukeland akuttmottak	983974724

This mapping will be stored in the EWA database via the Migration and Seeding Tool which reads it from an importable JSON file.

Example of JSON structure:

[{
    "reshid": "5432",
    "departmentName": "Bergen, sentrum sør-vest",
    "organizationId": "983974724"
},
{
    "reshid": "5678",
    "departmentName": "Haukeland akuttmottak",
    "organizationId": "983974724"
}]

Role name mapping

In order to present the user with easily readable role names, the existing mapping configuration of role to access rights must be extended with a DisplayName.

This extended configuration is optional, but highly recommended for systems that will use the role selector.

RoleToAccessRights.json example with new value:

[{
    "Role": "sys_hbe_journalregistrering",
    "DisplayName": "Ambulansemedarbeider, Bergen",
    "AccessRights": [
        "OrganizationClient",
        "UserJournalView",
        "UserJournalEdit",
        "UserJournalComplete"
    ]
},
{
    "Role": "sys_akuttmottak",
    "DisplayName": "Akuttmottaksmedarbeider",
    "AccessRights": [
        "LiveView"
    ]
}]

Flow description

Prerequisites:

• The Bliksund EWA system is configured to use OpenIdConnect.
• Insight is configured to use the role selector.
• The EWA database contains configuration for RESH-ID mapping.

Start: A user navigates to Bliksund EWA Insight

1. The user is redirected to a federated login solution
2. The user logs in via the federated login solution
3. The federated login solution redirects the user back to Insight
4. Insight redirects the user to the role selector
   1. The role selector checks the RESH-ID mapping with the user's RESH-IDs to present a user-friendly department list.
   2. The role selector checks the roles to access rights mapping with the user's roles to present a user-friendly list of roles.
5. The user selects the correct combination of department and role based on the needs for the session.
   1. The user confirms that the selections are correct by pressing "Continue".
6. The user is redirected to the original page that the user tried to access.

Technical flow

A cookie will be used to store the selected department and role for the session. When the user is logged in, the user will always be redirected to the role selector as long as the cookie is not set, no matter which Insight endpoint the user is trying to access.

Prerequisites:

• The Bliksund EWA system is configured to use OpenIdConnect.
• Insight is configured to use the role selector.
• The EWA database contains configuration for RESH-ID mapping.

Start: A user navigates to Bliksund EWA Insight.

1. Before the user is redirected to a federated login solution, the cookie is invalidated if it already exists.
2. See points 1-3 of Flow description above.
   1. The user now has a valid token for the session.
3. A filter checks whether a cookie is valid before requests are made by Insight.
   1. The filter redirects the user to the role selector if the cookie is not valid.
4. When the user clicks "Continue" after selecting the department and role in the role selector:
   1. The selections are stored in a cookie with expiration set to when the session expires.
   2. The user is redirected to the original page that the user tried to access.