Authentication of Healthcare Professionals in PoC 11&13

[jorritspee]

Introduction

At the moment it is not clear whether and if so, how, authentication of healthcare professionals is in scope for PoC 11&13. This document tries to give clarification on the value of authentication of healthcare professionals and scenarios to do so.

Value

The use case is the following:

1. After reception of the notification, Receiver-organisation pulls Task from Sender-organisation
2. After processing Task, Receiver-organisation pulls patient-identifying data from Sender-organisation
3. Receiver-organisation = Data-user-organisation
4. Sender-organisation = Data-holder-organisation

Reasons to authenticate an healthcare professional:

• Data-holder-organisation needs to check which natural person wants to access data
• Data-holder-organisation needs to check that natural person is related to the Data-user-organisation

Principles

1. We use Dezi to authenticate healthcare professionals
2. Dezi can only authenticate healthcare professionals in the context of 1 organization
   • Dezi does not support cross-organizational authentication of healthcare professionals
   • Dezi does not provide a means to transport healthcare professionals claims from Data-user-organisation to Data-holder-organisation
3. Dezi does support redirects
   • We could use this mechanism to authenticate the healthcare professional directly at the Data-holder-organisation
4. In PoC 11&13 the Twiin TA Authentication is used for the authentication of the data-user-organisation and the data-holder-organisation
   • The Twiin TA Authentication introduces the use of Verifiable Credentials
   • A Verifiable Credential could be used to transport healthcare professionals claims from Data-user-organisation to Data-holder-organisation

Scenarios

We see the following viable scenarios for the authentication of healthcare professionals in PoC 11&13:

• A. Professional asynchronously logs in in Data-user-EHR using Dezi, Dezi claims are transported to Data-holder-organisation using a VC that conforms to the Twin TA Authentication, in short "Transport Dezi-claims via VC"
• B. Professional authenticates synchronously at Data-holder-organisation during data-request using Dezi, in short "Dezi-login at data holder"

Comparison table

Item	A. "Transport Dezi-claims via VC"	B. "Dezi-login at data holder"
Number of log-ins for Healthcare Professional	once in local EHR	once in local EHR PLUS once per requested data holder
Dependent on Dezi	yes	yes
Dependent on Twiin TA Authentication/ GF Authentication	yes, for transport of Dezi-claims	no
Usable for Notified Pull (1 data holder)	yes	yes
Usable for (Indexed) Pull (n data holders)	yes	no
Data holder can verify integrity of presented identity-claims	yes	yes
Data holder can verify relation between presented identity-claims and requesting healthcare professional	no, data holder has to trust data user that data user does not mix up user sessions (within that same data user organisation)	yes, because healthcare professional logs in directly at data holder
Possible in current Dezi setup	yes	no, because healthcare professionals can only log into healthcare organizations for which a relation between that healthcare professional and that healthcare organization is already registered in the Dezi-register

• In terms of security scenario B "Dezi-login at data holder" scores better because in scenario B the data holder has absolute certainty about the relation between the end-user and the presented claims, where in scenario A data holder has to trust data user that it did not mix up user sessions within the data user organisation (only professionals within one organisation can be mixed up).
• In terms of usability scenario A "Transport Dezi-claims via VC" scores better because scenario B requires a new log-in by the Healthcare Professional per requested data holder.
• In terms of scalability scenario A "Transport Dezi-claims via VC" scores better because it is not only suitable for notified pull but can also be applied to (indexed) pull use cases (like used in PoC 12 (Medication data availability)
• Scenario B is not possible in the current Dezi setup

In these use cases, that uses a Notified Pull pattern, data are made available only to the intended Receiver organisation. Furthermore in these use cases the data that are fetched will be stored in the Receiver Organisation EHR. This makes the impact of a data user organisation mixing up user sessions low.

Scenario A. "Transport Dezi-claims via VC"

1. Healthcare professional logs into local Receiver EHR using Dezi
2. Data user EHR requests access token
3. Data holder handles incoming access token request
4. Data user EHR sends data request
5. Data holder handles incoming data request

1. Healthcare professional logs into local Receiver EHR using Dezi

1. User logs into Receiver EHR
   • EHR redirects to Dezi
   • Use this specification (version April 2024) for the iRealisatie-Dezi-testing-environment
   • Use this specification (version January 2026) for the CIBG-Dezi-testing-environment
2. User is logged into EHR of Data-user
   • Dezi-id-token and Dezi-claims are available inside EHR user session

2. Data user EHR requests access token

1. Receiver EHR finds correct endpoints of Sender in its Query Directory
   • fhir endpoint, Which payloadType?
   • access token endpoint, payloadType Nuts-OAuth
2. Request access token using Nuts OAuth endpoint
   • https://wiki.nuts.nl/books/implementing-a-nuts-use-case/page/requesting-access-outbound
   • you need to use version X of the Nuts-node for this to work TO DO
3. Put the Dezi-id-token in the access token request
   • See https://github.com/nuts-foundation/nuts-knooppunt/blob/main/docs/INTEGRATION.md#getting-an-access-token

3. Data holder handles incoming access token request

1. Nuts-node handles incoming request without manual action
   • you need to use version X of the Nuts-node for this to work TO DO

4. Data user EHR sends data request

1. Receiver puts received access token in http header Authorization, prefix the token by Bearer:

5. Data holder handles incoming data request

1. Data-holder receives incoming request
2. Data-holder introspects access token
   • you need to use version X of the Nuts-node for this to work TO DO
   • use introspect-token endpoint of Nuts-node
   • https://github.com/nuts-foundation/nuts-knooppunt/blob/main/docs/INTEGRATION.md#verifying-access-tokens
   • get data-user organisation claims from response (organization_ura)
   • get healthcare professional dezi claims from response (employee_roles)
3. Data-holder PEP sends request authorization request to Data-holder PDP
   • claims from token introspection
   • subject.properties.subject_id = employee_identifier from token-introspection
   • subject.properties.subject_role = employee_roles from token-introspection
   • subject_organization_id = organization_ura from token-introspection
   • subject_facility_type = "" (not needed in PoC 11 because no explicit consent is needed)
   • client_qualifications = scope from token-introspection
   • patient can be referred by FHIR-Patient_id or bsn

Scenario B. "Dezi-login at data holder"

1. Healthcare professional logs into local EHR using Dezi
2. Data user EHR requests access token
3. Data holder handles incoming access token request
4. Data holder redirects to Dezi Login
5. Healthcare professional logs into data holder system using Dezi
6. Data user EHR sends data request
7. Data holder handles incoming data request

[hansvr2022]

Am I missing something around the whole point of the Dezi roundtrip? The decrypted id_token doesn't at any way to validate as a data holder that the claims are coming from Dezi. As a Data holder it doesn't have any meaning what the claims are in the token since it has no way to really check that it belongs to an user. In what way does this have more authenticity then just adding the required fields to a NutsEmployeeCredential?

[jorritspee]

@reinkrul can you elaborate?
I think the signature on the Dezi-claims is also checked. So the data holder has proof that these claims are not just made up.

[reinkrul]

The DeziIDTokenCredential contains the decrypted id_token itself. When the credential is validated, the contained id_token is also validated (signature, expiration, revocation, credential claims vs id_token claims).

[SimonVeldhuijzen]

I think for the scope of the PoC, we should keep it simple and use scenario A.

Long term, having to relogin for every external call will probably not fall well with care professionals.

[jorritspee]

Okay clear. In scenario A no relogins for external calls are necessary.

[jorritspee]

These vendors have agreed on Slack to go for Scenario A (in alphabetical order):
✅ Gerimedica
✅ Nedap
✅ SYS
✅ Topicus

[vloothuis]

I see a potential security gap in Scenario A that I'd like to raise.

With Scenario A, data holder B can verify that:

1. A healthcare practitioner authenticated with organization A (via Dezi)
2. The credential is valid and not revoked

However, B cannot verify that the practitioner actually initiated this specific data request. The credential only proves
authentication happened at some point in the past - it doesn't prove the practitioner is aware of or consented to this
particular operation.

This creates a risk: tokens could be misused or misassigned by system A (intentionally or through compromise), and B would
have no way to detect this. In essence, A could make requests "on behalf of" practitioners without their knowledge, and B
would accept them as legitimate.

This could be an accepted risk of Scenario A - we acknowledge the limitation and rely on organizational trust and audit
trails to mitigate it.

But it also raises the question: if B cannot truly verify practitioner intent anyway, should we consider a Scenario C where
B simply trusts A's assertion about the practitioner? This would be more honest about where the trust boundary actually
lies, and potentially simpler to implement.

Since there are no hard requirements here afaik, I don't have a strong preference either way - but limitations like these
should be explicitly documented in whatever solution is chosen.

[SimonVeldhuijzen]

I would expect Dezi to provide a way to verify credentials, but as far as I know that's not (yet?) possible. This seems to also touch on the earlier concerns by @hansvr2022. I'm not yet convinced that this system actually provides the security it claims it does, but maybe I'm just misinformed. @jorritspee @reinkrul in case I'm indeed misinformed, how can I inform myself? And if I'm not, why should we go through the trouble of creating a "wassen neus" when the NutsEmployeeCredential provides the same security?

[reinkrul]

This has been a debate in our community for at least 6 years now, and it's a hard problem. NIST has a very good framework on this, discerning Identity (how strong is the initial identity creation), Authentication (how secure is it when the identity is used) and Federation (how strong are the guarantees when federating identities) assurance levels (FAL, AAL, IAL): https://pages.nist.gov/800-63-3/sp800-63-3.html#sec6

It all boils down to what risks we want to mitigate, and what level of UX we want to maintain for the care giver.

Having the care giver authenticate at the data holder opt. B) (initiated by the data requester) gives a high FAL; the data requester can't make requests without the human having been present. Note that as long as the care giver doesn't log out at Dezi (which it support btw), the data requester's system can still use the person's identity (token) after they've physicially left the keyboard/desk.
When Dezi is being used, IAL and AAL are also reasonably high.

Another security advantage of this, is that the requester system can't act without explicit consent from the user (the typical OAuth/OIDC "may Viewer XYZ access resources on Data Holder ABC on your behalf?" screen).

The downside of this, is that care givers will have to interact a lot more with Dezi; especially if data needs to be queried from multiple care organizations (e.g. Viewer or Medication Overview use cases). Currently, Dezi doesn't support user sessions, so that'd require the person to re-login each and every time.

However, the question is ultimately whether we need to mitigate this (and what'd be the impact of this risk, actually?), and with this level of assurance.

The "use Dezi ID token in exchanges" at least gives the data holder the assurance that this person was logged in to this data requester's system in, say, the last 4 or 8 hours. And it can use the identity claims (e.g. roles) to make authorization or data minimalization decisions. It makes it very hard, for instance, for a System Administrator to (illegally) query medical data.

So, if we have trouble making a decision here, a structured risk assessment might help (because if we're not aligned on which risks we want to mitigate, proposed solutions will never align).

[SimonVeldhuijzen]

Thanks :)

Shouldn't the focus then be on Dezi to support user sessions? Because having to relogin for each source system is simply not an option for, for example, the viewers that aggregate data from multiple sources.

[reinkrul]

That's would lighten the burden somewhat, but still depends on the choices Dezi makes to keep the user safe;

• If the user would still have to give consent each time ("let my EHR act on my behalf with care org. XYZ"), it would be quite safe. But at the same time, quite burdensome (5 sources means 5 times acknogledgement). Although you could store this consent, so once a year per remote source. Maybe that'd be good enough.
• If you don't ask for consent each time, the system/Dezi effectively bypasses the user's consent check.

But question is, would the care giver ever deny the consent question from Dezi is such cases? It's a closed system, the user trusts its own EHR and most probably whatever source they're going to query. It's not like a random web app (e.g. Github, or calendar app) that tries to access your mail or cloud storage account, which you actually might want to deny.