Search Results

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 id...

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 hackatho...

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 Coaliti...

Version 2025-07-04 Status draft Introduction This techincal agreements descibes how health organizations should be identified in the context of data exchanges. Agreements Decision Health organizations are identfied using URA-number (UZI-Register ...

Version 2025-07-04 Status draft Introduction This techincal agreements descibes how vendor organizations should be identified in the context of data exchanges. Agreements Decision Vendor organizations are identfied using KvK-number (Kamer van Koo...

Version 2025-07-04 Status draft Introduction This techincal agreements descibes how professionals should be identified in the context of data exchanges. Agreements Decision 1 Professionals are identfied using local employee number Rationale All ...

Version 2025-09-10 Status draft Jorrit Spee: This needs rework: Using PKIo is not really authenticating but merely a means of security. Action: talk to Steven about this. Introduction This technical agreement descibes how vendor organizations sho...

Version 2025-07-04 Status draft Introduction This technical agreement descibes how health organizations should be authenticated in the context of data exchanges. Agreements Decision Health organizations are authenticated using a X509credential ba...

Version 2025-07-04 Status draft Introduction This technical agreement descibes how professionals should be authenticated in the context of data exchanges. Agreements Decision 1 Professionals are "authenticated" (it is probably better ot refer to ...

to do

to do

Version 2025-07-04 Status draft Introduction This technical agreement descibes how incoming requests must be authorized in the context of data exchanges. Agreements Decision 1 Authorization rules are technically defined using access policies writ...

Version 2025-07-04 Status draft Introduction This technical agreements descibes the needed technical agreements for the use of local explicit consent by data holders. Agreements Decision 1 Data holders are free to implement local explicit consent...

This document describes how to issue the X509Credential for a UZI server certificate, used to authenticate in several applications on Nuts/ use cases. Introduction Several applicatopns-on-nuts specify that care organizations are authenticated using a Verifiabl...

First, a new identity, with associated DID(s), needs to be created for the tuple (organization, environment). Using API Perform the following REST API call. Note that subject is optional. POST <internal Nuts interface>/internal/vdr/v2/subject Content-Type: app...

Using API To load the credential into the Nuts node via its REST API, perform the following HTTP request: POST <internal Nuts interface>/internal/vcr/v2/holder/<subjectID>/vc Content-Type: application/json "<JWT>" Replace <subjectID> with the subject, and <J...

Before another party can interact with you, they will first need to find your endpoints. The discovery service in the Nuts node helps you. You do this once per organization, per use case. Using API POST <internal Nuts interface>/internal/discovery/v1/<serviced...

Choices made We will use the discovery service of Topicus (see definition files We will use the test-environment We will use any public trust certificates for the mTLS, see decision 3 here: https://wiki.nuts.nl/books/generic-technical-agreements-generieke-bo...

At Nuts uses the RFC8615 spec for .well-known URIs (https://www.rfc-editor.org/rfc/rfc8615.html). This means well-known resources, like the OAuth server, are resolved from the root of the (sub)domain. If you host the Nuts node on a subpath, you need to do some...

Scenario if you want to use Nuts-node (default) deploy Nuts-node using Scenario if you want to use Knooppunt You could use this deployment guide and/or this docker-compose file.