PZP

• PZP Volume 1 - Functioneel overzicht
• PZP Volume 2a - Technical Agreements
• PZP Volume 2b - Transactions
• PZP Volume 3 - Content
• Connectathon 29 Sept 2025

PZP Volume 1 - Functioneel overzicht

WIP!

BZ: moeten we de drie verschillende momenten los uitwerken? Dus 1) inzage (bij spoed/ambu/OHCA bijv), 2) overdracht (bij veranderen van zorgorganisatie of lijn, bijv thuiszorg naar Hospice of oncoloog naar huisarts en wijkverpleging) of 3) samenwerking (bijvoorbeeld tussen huisarts of specialist in het ziekenhuis en wijkverpleging)

Doel en relevantie

Het doel van deze usecase is om behandelgrenzen en -wensen van zorgvragers — zoals afgesproken in het kader van proactieve zorgplanning (PZP) — digitaal beschikbaar te maken voor geautoriseerde zorgverleners binnen het netwerk van de zorgvrager. De gegevens worden eenduidig vastgelegd, (mede) ontsloten via de Nuts-infrastructuur, en zijn snel en veilig te raadplegen bij spoed, overdracht of reguliere zorgmomenten.

Hierdoor wordt gewaarborgd dat behandelwensen bekend zijn en gerespecteerd worden, onafhankelijk van tijd, locatie of zorgaanbieder.

Bedrijfsrollen

Rol	Toelichting
Vastleggende zorgverlener	De zorgprofessional die het PZP gesprek gevoerd heeft met de zorgvrager en de informatie vastlegt.
Raadplegende zorgverlener	De zorgprofessional die PZP gegevens wil opvragen bij een andere zorgorganisatie.
Bronhouder*	De zorgorganisatie waar de zorgvrager (eerder) zorg ontvangen heeft, en die het PZP deelt met bij de zorg betrokken professionals bij een andere zorgorganisatie.

*Om consistentie te bewaren binnen de usecases die over Nuts gaan, gebruiken we hier de term Bronhouder.

Proces en context

Patient Journey:

TODO

PZP Volume 2a - Technical Agreements

This volume describes the technical side of the agreements to realize data availability for the use case Advance Care Planning. This volume provides the technical agreement needed for transmitting the data between parties. Technical agreements are made on

• identifying health organizations
• identifying vendors
• identifying professionals
• authenticating vendors & health organizations
• authenticating professionals
• localization
• addressing
• data request

Exchange pattern: indexed pull

Due to the nature of the use case, the exchange pattern is indexed pull. In short this means that fetching data globally consists of two steps: Localization: Localising the data holders (via one or more indices) and then Data request: actually reuqesting the data at each known data holder.

Identifying health organizations

The use case Advance Care Planning makes use of the generic technical agreement Identifying health organisations.

Identifying vendor organizations

The use case Advance Care Planning makes use of the generic technical agreement Identifying vendor organisations.

Identifying professionals

The use case Advance Care Planning makes use of the generic technical agreement Identifying professionals.

Authenticating health organisations

The use case Advance Care Planning makes use of the generic technical agreement Authenticating health organisations.

Authenticating vendor organizations

The use case Advance Care Planning makes use of the generic technical agreement Authenticating vendor organizations.

Authenticating professionals

The use case Advance Care Planning makes use of the generic technical agreement Authenticating professionals.

Localization

The use case Advance Care Planning does not make use of a generic technical agreement. The use case Advance Care Planning uses the following technical agreements:

Make data localisable:

• COULD: Every healthcare organisation maintains a CareTeam-resource per patient that contains all known involved relevant healthcare organizations

• LATER: For testing purposes the facilitators of the test make sure that the NVI is filled

• LATER: Vendor that wish to do so can register the CareTeams with the NVI (specifications)

Localise:

• MUST: Get URA’s from organizations that have registered support for PZP-service from Nuts Discovery Service
• COULD: Get URA’s from data holders from local CareTeam
• LATER:
  • Send bsn to NVI
  • receice 1 or more URA's from data holders that host a CareTeam
  • fetch at least 1 CareTeam-resource

Addressing

The use case Advance Care Planning does not make use of a generic technical agreement. The use case Advance Care Planning uses the following technical agreements:

Publish addresses

• SHOULD: Register at NutsDiscoveryService with X509Credential and DiscoveryRegistrationCredential containing a fhirBaseUrl-elemement.
• MUST: Parties that choose not to register at the NutsDiscoveryService themselves are registered at the NutsDiscoveryService via a hack
• FALLBACK: make sure you know the fhir base urls of other parties in some way (this can also be done via a local list)

Retrieve addresses

• Query the NutsDiscoveryService and use the values for fhirBaseUrl and auth-url
• FALLBACK: make sure you know the fhir base urls of other parties in some way (this can also be done via a local list)

Authorization

The use case Advance Care Planning makes use of the generic technical agreement Authorizing incoming requests.

The following access policies are used in ACP:

Rego script here
to do

Legal basis: local explicit consent

The use case Advance Care Planning uses an explicit consent that is stored locally in a system of the data holder a legal basis for the processing of data. The use case Advance Care Planning makes use of the generic technical agreement Local explicit consent.

Data request

In some contexts this is referred to as Pull. TO DO jorrit

PZP Volume 2b - Transactions

Within this volume the transactions that are used for the use case Advance Care Planing are described.

Publish ACP data source to NVI

Later. not in scope for September 2025 hackathon

Search ACP data source at NVI

Later. not in scope for September 2025 hackathon

Getting data from multiple sources

Legend: If you use an option to localize data, you must use the corresponding option to get endpoint addresses. In other words: stick to 1 color!

Image:

PlantUML: https://github.com/nuts-foundation/application-on-nuts-acp-pzp/blob/main/sequence-diagrams/request-data-from-multiple-data-holders.puml

PZP Volume 3 - Content

De zorgtoepassing PZP gebruikt als content onderstaande zibs, FHIR-profielen en EHR-archetypen. Dit artikel is een beknopte weergave van hoofdstuk 3.3 uit de Afsprakenset Proactieve Zorgplanning PZP Coalitie. De Afsprakenset Proactieve Zorgplanning PZP Coalitie is leidend.

Zorginformatiebouwstenen

Er wordt gebruik gemaakt van de zib Patient (versie 2020) en de zib Behandelaanwzijzing2

FHIR resources en queries

Voor PZP wordt gebruik gemaakt van FHIR R4. Hieronder staan de endpoints die beschikbaar gesteld moeten worden door de partijen die optreden als bronhouder in de use case PZP. Ter verheldering zijn de kolommen Sort en Count toegevoegd om aan te tonen hoeveel resultaten er geretourneerd worden en op welke manier deze worden gesorteerd. Het is van belang dat bij een aanroep alle parameters worden gebruikt die in de tabel staan en ook geen extra. Dit heeft te maken met de controle die de systemen doen op de verifiable credentials. Die controle wordt op die manier gedaan om te voorkomen dat met een parameter zoals een include extra gegevens meekomen.

ZIB	Method	Sort	Count	Endpoint	Profiel
Patiënt	POST			Zie onder de tabel	https://simplifier.net/nictiz-r4-zib2020/nlcorepatient
BehandelAanwijzing2	GET			Zie onder de tabel	https://simplifier.net/PZP-Hacka/NlcoreTreatmentDirective2

Patient

Voor het ophalen van de Patiënt geldt:

POST /fhir/Patient/_search

Header: Content-Type = x-www-form-urlencoded (zie https://www.hl7.org/fhir/http.html#search-post)

Body: identifier=http://fhir.nl/fhir/NamingSystem/bsn|{bsn}

BehandelAanwijzing2

Voor het ophalen van de BehandelAanwijzing2 geldt:

GET /fhir/Consent?patient=<patient-fhir-id>&_profile=http://nictiz.nl/fhir/StructureDefinition/nl-core-TreatmentDirective2

Waarbij <patient-fhir-id> wordt vervangen door de technische referentie naar de opgehaalde patient, bijv. Patient/xyz.

openEHR

Er kan gewerkt worden met opslag o.b.v. het openEHR template uit de informatiestandaard, een alfa versie is hier te vinden. Als er met openEHR wordt opgeslagen kan de FHIR-Connect mapping uit de informatiestandaard gebuikt worden om met FHIR uit te wisselen, een alfa versie is hier te vinden.

Connectathon 29 Sept 2025

Choices made

1. We will use the discovery service of Topicus (see definition files
2. We will use the test-environment
3. We will use any public trust certificates for the mTLS, see decision 3 here: https://wiki.nuts.nl/books/generic-technical-agreements-generieke-bouwblokken/page/authenticating-vendor-organisations
4. We will use fake-uzi-certificates. Please use this manual to generate a fake-UZI-cert and generate a x509Credential and this manual to load it into your org wallet.
5. Scope of test: scenarios 1 to 5 from Nictiz page
6. we will use the technical agreements as specified in Vol 2a
7. we will use option 1 and/or option 2 in this sequence diagram
8. We use the fhir search query for Consent that is defined here: https://wiki.nuts.nl/books/pzp/page/pzp-volume-3-content. After the connectathon we will move towards the search query defined in https://as-iknl-api-documentatie.azurewebsites.net/docs/pzp/r4/data-exchange.html.

Preparation

Deploy Nuts-node

1. A vendor COULD use this deployment guide and/or this docker-compose file
2. This deployment also includes some components for the Generic Function Addressing that we will not use in the PZP Connectathon but they will not do any harm

Deploy Nuts admin-app

1. deploy Nuts-admin-app: https://github.com/nuts-foundation/nuts-admin

Configure Nuts-node

1. https://wiki.nuts.nl/books/implementing-a-nuts-use-case/chapter/initial-configuration-of-nuts-node

Register PZP service at discovery service

1. https://wiki.nuts.nl/books/implementing-a-nuts-use-case/page/register-service-at-discovery-service
2. use this format: https://github.com/nuts-foundation/application-on-nuts-acp-pzp/blob/main/discovery-service-presentation-definitions/test/discovery_pzp_test.json