Netherlands - Zorginzage Implementation Guide - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Volume 2a

Exchange patterns: pull and indexed pull

This specification describes data exchanges that use the exchange pattern "pull" or the exchange pattern "indexed pull". See https://www.datavoorgezondheid.nl/documenten/2025/07/14/whitepaper-communicatiepatronen-vws.

In short this means that fetching data globally consists of the following steps:

1. Addressing: The data user finds the addresses of the FHIR- and OAuth-endpoints of each (possible) data holder.
2. Authentication: The data user authenticates (organisation and person level)
3. Localisation: The data user finds the data holders that have data about a patient (in a specific context)
   1. Patient search request: The data user performs a patient search at each possible data holder, using bsn as parameter.
   2. Patient search reponse: When the data user has data about the requested patient, it returns the internal technical identifier of the requested patient.
4. Data request: The data user performs data requests at each possible data holder, using the technical identifier of the requested patient as parameter.
5. Authorisation: The data holder authorizes the incoming data request.
   1. Check consent: As part of the authorization process the data holder can check the presence of patient consent, locally or at Mitz.

Principles

This specification uses the following principles:

• This specification makes use of did:web and verifiable credentials (commonly referred to as "Nuts v6")
• This specification makes use of FHIR API's

Identification

Healthcare organisations

Identifier: URA

Healthcare organisations are identified using URA-number (UZI-Register Abonneenummer).

Rationale

• Identification of healthcare organisations by URA conforms to the national information model for health orgnizations (Zorginformatiebouwsteen Zorgaanbieder: https://zibs.nl/wiki/Zorgaanbieder-v3.6(2024NL))
• The URA-number is issued by a public organization (CIBG)
• The URA-number is cryptographically verifiable because it is contained in a PKI-certificate (UZI-servercertificaat, CPS: https://www.uziregister.nl/over-het-register/certificeringsbeleid/archief-certification-practice-statement)

HealthcareProviderRoleType

Healthcare organisations use a HealthcareProviderRoleType attribute to express which type(s) of healthcare organisations they are.

Rationale

• In indexed pull scenarios, OTV-consents (online toestemmingsvoorziening, Mitz) are relevant. The use of OTV-consents requires uniform communication of the type of healthcare organisation of both data user organisation and data holder organisation.
• The type of healthcare organisation is a useful attribute in authorisation and localisation processes.
• The HealthcareProviderRoleType is self-issued by each healthcare organisation. No trusted third party issuer is active at the moment.

Vendor organisations

No identifier

Vendor organisations are not identified by a business identifier. The parapraph Network Security descibes mTLS-based client and server authentication.

healthcare professionals

Identifier: local employee identifier

• Healthcare professionals are identified using a local employee identifier.
• Local employee name and local employee role are used as non-identifying attributes.

Rationale

• All professionals have a local employee number
• A national healthcare professional identifier is not yet available for all professionals
• A national healthcare professional role is not yet available for all professionals

Authentication

Healthcare organisations

X509credential

The URA number of health organizations is authenticated using a X509credential based on a UZI-servercertificate.

Rationale

• UZI-servercertificate is issued by a public organization (CIBG) URA-number is contained as attribute in the UZI-servercertificaat, CPS: https://www.uziregister.nl/over-het-register/certificeringsbeleid/archief-certification-practice-statement
• The URA-number can securely be contained in a X509credential using the open source software did:x509 and X509Credential Toolkit

HealthcareProviderRoleTypeCredential

The HealthcareProviderRoleType attribute will be authenticated using a self issued HealthcareProviderRoleTypeCredential.

Rationale

• No trusted third party issuer is active at the moment.

Standard Nuts processes

The standard did:web-based Nuts-processes for access token requests and introspects, and jwt-based data requests are used. The exact specifications and sequences are described in volume 2b.

Vendor organisations

The parapraph Network Security descibes mTLS-based client and server authentication.

Healthcare professionals

The identity of healthcare professionals is federated from data user organisation to data holder organisatin using a NutsEmployeeCredential.

Rationale

• A nation-wide solution for cross-organizational authentication (e.g. Dezi) is not in place.
• NutsEmployeeCredential can be used now and is not dependent of other (national) initiatives

Addressing

To exchange data between healthcare organisations that are not previously known to each other, it must be possible to discover addressing information within the healthcare network. Address information is data that describe an organisation's topology and the various ways an organisation can be reached. These can be physical, digital, or logical entities.

For all use cases, the starting point is finding the correct endpoints, for example, to request an access token or to send a task. The Nuts community uses their discovery service for this purpose.

A complete description of the Discovery Service can be found on the Nuts Wiki.

In terms of required credentials, we use three different types during the discovery process: an X509Credential, a DiscoveryRegistrationCredential and a HealthcareProviderRoleTypeCredential. These credentials are used when registering and requesting addressing information.

Searches can be performed by organisation URA, organisation type and use case.

Actiz is organisationally responsible for hosting the discovery service. One discovery service will be used for all specific applications-on-Nuts that are based on the generic application-on-Nuts Zorginzage.

X509Credential

The X509Credential is an organisation credential that is used to present the URA number.

This is an X509Credential in accordance with Nuts RFC023, signed with an UZI server certificate. It can be created, for example, with the go-didx509-toolkit or the Java library. It has been decided to include the chain closest to the leaf certificate as the issuer.

HealthcareProviderRoleTypeCredential

A self-signed HealthcareProviderRoleTypeCredential has to be presented when registering at the discovery service. This can be used by users of the Discovery Service to look up the HealthcareProviderRoleType of an organisation.

DiscoveryRegistrationCredential

The DiscoveryRegistrationCredential is a temporary credential that communicates the information for making a new registration in the discovery service. This is a DiscoveryRegistrationCredential as explained on the Nuts Wiki page about Service Discovery. A field named fhirBaseURL has been added to the credentialSubject. This can be used by users of the Discovery Service to know where the actual FHIR data can be retrieved. A field named authorization_server_url has been added to the credentialSubject. This can be used by users of the Discovery Service to look up the access token request endpoint.

Localisation

Localisation is the process of finding out which organisations have data on a patient.

The generic function localisation is not yet available in production environments. This specification uses bsn broadcasting using the Nuts Discovery Service for indexed pull scenarios. This means that organisations that implement this specification perform bsn broadcasting and accept incoming bsn-based patient searches and matches.

This method is the only viable way to localise without external dependencies, however it requires an appropriate legal basis to be in place.

In practice the BSN broadcast is realised by searching for a patient record with an identifier.

```http request POST /fhir/Patient/_search Content-Type: application/x-www-form-urlencoded

identifier=http://fhir.nl/fhir/NamingSystem/bsn|618359710&_elements=id ```

• Requestor must pre-filter resources servers that the BSN is broadcasted to by use case and organisation type during addressing
• Requestor must provide the _elements & identifier= query parameters when searching the patient
• Data holder must only return patient ID's when there is data available for the specific use case

The aim is to replace localisation in the next version of this spec with either pseudonym broadcasting or the GF localisation. Always make sure to check the legal basis before broadcasting any BSN's.

Authorisation

For authorization, we prefer a fine-grained policy based access model over a role based model. Whether a requestor gets access to the data they are requesting depends on whether they pass the access-polices of the source (bronhouder).

To ensure everyone uses the same rulesets express policies in a domain specific language called Rego. The input for evaluating the policies is commonly agreed upon information model. A similar model has been described in the proposal for the generic function authorization.

See also: https://nuts-foundation.github.io/nl-generic-functions-ig/authorization.html

Note: Implementors are free to choose to not implement a Rego-interpreter as part of their authorization solution, as long as the implemented authorization solution follows the exact same rules as specified in the Rego-policy-file.

For policy evaluation the PDP functionality in the Nuts Knooppunt can be integrated with any policy enforcement point. Policies are version controlled in a Git repository controlled by the Nuts Foundation.

Policy are selected based on the use case scope provided by the Nuts node as part of the authentication process. A single name is used that connects the scope, Nuts policy and authentication policy.

The following guidelines should be taken into account when designing new policies.

• ura identifier of requesting organization is mandatory
• when the request is for FHIR endpoint, evaluate conformance to a capability statement
• patient context is mandatory for accessing patient data
  • for search interactions either a patient id or patient bsn must be possible to derive from the query
  • for read interactions the requested resource should have a direct link to a patient (for example through a patient field)
• For data requests that require explicit consent, patient consent must be checked in a local system or in Mitz before returning the data
• check on active treatment relation, optionally in context of specific use case

For data requests in which explicit consent is not checked, one of the following is mandatory:

• The treatment relation of the data user organisation with the patient is checked technically by the data holder organisation (e.g. using a PatientEnrollmentCredential). This treatment relation can be scoped to a specific context (e.g. a use case).
• A legal construction has been created in which explicit consent is not necessary. This is not be checked technically.

The treatment relation of the data holder organisation with the patient may be checked technically by the data holder organisation.

Consent

• It is up to the data holder organisation to decide whether to use explicit consent and/or another legal basis when authorizing an incoming data request.
• When using explicit consent, it is up to the data holder organisation to decide whether to use a locally stored consent record or an OTV-consent (Mitz).
• When using implicit consent, it is up to the data holder organisation to decide how to implement this (e.g. by expressing that implicit consent in a FHIR Consent resource or not).
• A locally stored consent record minimally contains the following elements:
  • URA of data holder organisation
  • URA of intended data user organisation
  • BSN of client/ patient
  • A standardized way to express the context (e.g. using a use case identifier)
• The first release of the zorginzage specifcation after Mitz being production ready for all zorginzage participants will make the "Mitz gesloten vraag" mandatory when no locally stored consent record is available.

Network security

1. Production environments: Vendor organizations use server- and client-authentication (mutual TLS) based on PKIoverheid-certificates.
2. Acceptance environments: Vendor organizations use server- and client-authentication (mutual TLS) based on PKIoverheid-certificates.
3. Test environments: Vendor organizations use server- and client-authentication (mutual TLS) based on PKIoverheid-certificates or any public trust certificates.

Registering a new use case

New use cases can be registered by providing a pull request to the nl-zorginzage-resources repository.

A complete use case contains:

• The Nuts policy
• An authorization policy
• Discover service presentation definition

Use cases are scoped to a version of this implementation guide and reviewed by Actiz.