Projecten

LSP x Nuts

Status: loopt Waar: #lspxnuts

Wat het is

LSP x Nuts realiseert een koppeling tussen het Landelijk Schakelpunt (AORTA) en het Nuts-netwerk, zodat partijen aan beide kanten gegevens bij elkaar kunnen opvragen zonder dat elke deelnemer zich aan het andere stelsel hoeft aan te passen.

Het traject kent twee fasen. Fase 1 maakt het mogelijk dat Nuts-partijen gegevens kunnen raadplegen bij het LSP. Fase 2 maakt het mogelijk dat Nuts-partijen ook zelf als bron kunnen fungeren, zodat het LSP gegevens bij hen kan opvragen. In fase 2 worden de generieke functies gebruikt en wordt het nuts-knooppunt ingezet waar dat kan.

Het project heeft een eigen coördinatie, waarin naast Nuts onder meer VZVZ en VWS deelnemen. Het is daarmee geen project van de kring Techniek, maar de technische inhoud valt wel onder ons mandaat.

Waarom dit onder ons mandaat valt

Wij stellen de architectuur en de specificaties op, en zorgen dat de implementatie in de nuts-node beschikbaar is. Dat raakt zowel onze technische kaders als het beheer van onze eigen standaarden en de nuts-node. Besluiten over de koers van het project zelf liggen bij de projectcoördinatie.

Wat er nu speelt

Bewegende delen en TODO's:

Er loopt nogal wat, dit een lijstje om overzicht te houden.

Wie erbij betrokken zijn

Rol Wie
Architectuur, PSA en solution design Steven van der Vegt, Dirk Geurs
Implementatie in de nuts-node Rein Krul
Technische afstemming pilots wekelijks, dinsdagmiddag

Aan VZVZ-kant en vanuit VWS zijn eigen contactpersonen betrokken; dat loopt via de projectcoördinatie.

Documenten en repositories

De PSA en het solution design staan op de SharePoint van VZVZ en zijn nog niet openbaar.

Hoe haak je aan

Voor vragen over deelname aan de pilots of over de technische vereisten: stel ze in #lspxnuts. Voor vragen over hoe dit zich verhoudt tot de technische kaders van Nuts: #kring-techniek-aanspreekpunt.

Verwijzen naar het Landelijk afsprakenstelsel

Status: loopt Waar: #kring-techniek-aanspreekpunt

Wat het is

Het Landelijk afsprakenstelsel (LAS) moet de plek worden waar generieke landelijke afspraken staan. Andere afsprakenstelsels verwijzen daar dan naar in plaats van eigen varianten te maken. De werkgroep Verwijzen naar Landelijk afsprakenstelsel heeft richtlijnen opgesteld voor hoe dat verwijzen moet werken. Nuts is een van de deelnemende afsprakenstelsels.

Wij hebben hier twee losse maar verbonden opdrachten.

Opdracht 1: deelname aan de werkgroep. Sergej van Middendorp nam tot juli 2026 namens Nuts deel en heeft dat overgedragen aan de kring Techniek. De werkgroep werkt aan het vervolg op de richtlijnen en organiseert een PoCathon om te toetsen of het verwijsmechanisme werkt. Het gaat daar uitsluitend om het mechanisme (permalinks, metadata, register), niet om de inhoud van de afspraken.

Opdracht 2: beproeving van de richtlijn. In ons eigen overleg is besloten dat de kring Techniek de richtlijn zou beproeven, met de afspraak Veilig netwerk als object om naar te verwijzen. Voorwaarde was dat Twiin eerst duidelijk zou maken waar de richtlijn staat, wat de status is en waar de afspraak staat. Dat is inmiddels geregeld. De beproeving zelf is nog niet uitgevoerd.

De twee opdrachten gebruiken dezelfde richtlijn maar hebben een ander doel. Opdracht 1 toetst het mechanisme gezamenlijk, opdracht 2 toetst het vanuit ons eigen stelsel.

Waarom dit onder ons mandaat valt

Verwijzen naar externe afspraken raakt hoe wij onze eigen specificaties publiceren en versioneren: permalinks, metadata, en notificatie bij breaking changes. Dat is documentatie- en beheerwerk aan onze eigen standaarden en valt daarmee onder ons mandaat.

Wat wij wel en niet kunnen toetsen is belangrijk om vooraf vast te leggen. Wij kunnen vaststellen of een verwijzing technisch werkt: of het object vindbaar is, een stabiele permalink heeft, versioneerbaar is en zelfstandig leesbaar. Wij kunnen niet vaststellen of dat waarnaar wij verwijzen logisch en passend is. De afspraak Veilig netwerk stelt eisen aan de bedrijfsvoering van zorgaanbieders en hun leveranciers, en dat is niet iets waar wij als Nuts eisen over willen of kunnen stellen.

Twee onderdelen vallen daarmee buiten ons mandaat:

Hoe het speelveld in elkaar zit

Wat er nu speelt

Eerste analyse

Dit zijn inzichten uit het lezen van de richtlijnen en het PvE en uit navraag bij Twiin. De beproeving en de huiswerkopdracht zijn nog niet uitgevoerd.

Documenten

Wat Waar
Richtlijnen Verwijzen naar landelijke afspraken in Twiin, v0.2, juni 2026 twiin.nl
PvE Netwerkbeveiliging Twiin Deelnemer (TA150), normatief afsprakenstelsel.twiin.nl
PvE Netwerkbeveiliging Twiin Deelnemer (TC150D), prepublicatie consultatie.twiin.nl
Landelijk afsprakenstelsel, algemene informatie datavoorgezondheid.nl
Uitnodiging PoCathon, Kris van Hamelen (VWS), 3 augustus 2026 per e-mail, 29 oktober 2026 in Den Haag

De richtlijnen v0.2 bevatten in bijlage 1 een begrippenmodel en in bijlage 2 een metamodel voor de meta-informatie van een afspraak.

Wie erbij betrokken zijn

Rol Wie
Overdracht deelname werkgroep Sergej van Middendorp
Coördinatie en analyse Steven van der Vegt
Deelname werkgroep en PoCathon nog te bepalen

Contactpersoon bij Twiin is Ursula Letschert. Voor vragen over de status van de richtlijnen en over eventuele verplichting: Ageeth Wahle (VWS).

Hoe haak je aan

Voor vragen over deze opdrachten of over deelname aan de werkgroep en de PoCathon: #kring-techniek-aanspreekpunt.

Werkgroep Technische Convergentie

Status: in voorbereiding, eerste bijeenkomst gehouden Waar: #wg-technische-convergentie en #kring-techniek-pub

De werkgroep kwam op 27 augustus 2026 voor het eerst bijeen. De instelling is nog niet in beide kringen bekrachtigd en de opdracht vanuit kring Techniek staat nog niet vast. Zie Wat nog niet is vastgesteld.

Het leidende document is het Voorstel Werkgroep Technische Convergentie: het gezamenlijke besluit, de opdrachten van beide kringen, de resultaten en de grenzen. Agenda's, aanwezigen en acties staan in het logboek van de werkgroep. Deze pagina geeft de context en wat deze kring te besluiten heeft.

Wat het is

Kring Toepassingen en Kring Techniek stellen samen één Werkgroep Technische Convergentie in. Beide kringen geven de werkgroep een eigen, aanvullende opdracht en vaardigen zelf deelnemers af. De opdrachten zijn niet aan elkaar gericht maar aan dezelfde werkgroep; de werkgroep werkt als één team, en de herkomst van een deelnemer bepaalt niet wie welk deel van het werk doet.

De werkgroep komt in de plaats van het zorgtoepassingsontwerpersoverleg. Ons jaarplan beschrijft dezelfde werkvorm: een structuur waarlangs signalen van toepassingsontwerpers en leveranciers bij de kring binnenkomen en waarlangs wij de technische richting teruggeven. Het gaat dus om hetzelfde gat, en daarom wordt het één werkgroep in plaats van twee.

Het is een werkgroep, geen overleg. Een werkgroep heeft een opdracht, levert een resultaat op en vraagt tijd van deelnemers tussen de bijeenkomsten door.

Relevantie voor Nuts

De migratie naar did:web en de convergentie naar gedeelde bouwblokken lopen per zorgtoepassing, en het eigenaarschap daarvan ligt bij de toepassingen. Onze rol is faciliterend: technische input en context leveren, niet de migratiepaden van andere kringen bezitten. Wat tot nu toe ontbreekt is een vaste plek waar die twee kanten elkaar treffen. Daardoor komen ondersteuningsvragen ad hoc binnen en blijven kaderkeuzes liggen omdat niemand ze voorbereidt.

Voor deze kring is het belang concreet: hier komt in beeld welke gedeelde bouwblokken de toepassingen nodig hebben, wordt getoetst of de referentie-ontwerpen daarop aansluiten, en wordt zichtbaar welke vraagstukken om een kaderkeuze in de kring vragen.

Wat de kringen samen besluiten

Het voorstel vraagt beide kringen de werkgroep in te stellen, de gezamenlijke opdracht en grenzen te onderschrijven, elk deelnemers af te vaardigen, Edwin de Wit en Roland Groen te vragen de start en procesbegeleiding te organiseren, en na drie maanden te evalueren.

Het besluit treedt in werking zodra beide kringen het gezamenlijke deel hebben bekrachtigd. Een kring kan haar eigen opdracht aanpassen; wijzigingen aan het gezamenlijke doel, de grenzen of de werkwijze vragen instemming van beide kringen.

Wat wij de werkgroep vragen

Kring Techniek vraagt de werkgroep om:

  1. Per zorgtoepassing het technische beeld op te bouwen dat nodig is om te kunnen ondersteunen bij de migratie naar did:web en de landelijke generieke functies: welke technische stap er aan de orde is en waar die op vastloopt.
  2. Als mede-auteur te werken aan de referentie-ontwerpen per communicatiepatroon, en die toe te passen bij het ontwerp van een nieuwe toepassing of een nieuwe versie daarvan.
  3. Technische ontwikkelingen, releases en standaarden vanuit de kring Techniek te vertalen naar gevolgen en acties voor de zorgtoepassingen.
  4. Bij de kring Techniek neer te leggen wat de toepassingen tegenhoudt en niet in een referentie-ontwerp is op te lossen: ondersteuningsvragen die capaciteit vragen, en vraagstukken die een kaderkeuze nodig hebben, met het probleem, de mogelijke richtingen en hun voor- en nadelen.

De referentie-ontwerpen zijn de vorm waarin de kring Techniek de gedeelde bouwblokken oplevert: een uitgewerkt ontwerp per communicatiepatroon waarop een toepassing zich profileert. De Werkgroep Architectuur bepaalt welke bouwblokken een referentie-ontwerp kent en hoe die samenhangen, en beheert het geheel; de invulling per bouwblok gebeurt samen met deze werkgroep. Welke bouwblokken nodig zijn en met welke prioriteit, volgt uit de behoefte van de zorgtoepassingen.

Blijkt een referentie-ontwerp in de praktijk niet uitvoerbaar, binnen de beschikbare tijd of met de bestaande implementaties, dan is dat aanleiding om het ontwerp aan te passen en niet om ervan af te wijken. Komen beide werkgroepen er samen niet uit, dan gaat het als kaderkeuze naar de kring Techniek.

Deze kring vaardigt zelf deelnemers af, bij voorkeur via de Werkgroep Architectuur. Is die werkgroep bij de start nog niet actief, dan wijst de kring tijdelijke vertegenwoordigers aan.

Kring Toepassingen vaardigt per zorgtoepassing een inhoudelijk verantwoordelijke af en vraagt de werkgroep vooral om zicht op de technische ontwikkelingen, afhankelijkheden en migratievoortgang per toepassing, en om kansen voor harmonisatie uit te werken tot vervolgstappen.

De werkgroep bepaalt zelf haar agenda, werkwijze en interne taakverdeling binnen de opdracht. Zij heeft geen eigen domein en neemt geen besluiten namens de kringen over technische kaders, standaarden, prioriteiten van toepassingen, de inzet van mensen en middelen, of de governance van afzonderlijk gefinancierde trajecten.

Wat nog niet is vastgesteld

De werkgroep is gestart voordat de instelling en de opdracht rond waren. Dat kan, maar het heeft gevolgen die hier expliciet staan.

Afvaardiging. Je bent afgevaardigd als je kring met consent heeft ingestemd met naam, rol, tijdsbeslag en termijn. Dan spreek je namens die kring en koppel je daar terug. Zonder dat besluit draag je bij op persoonlijke titel. Voor geen enkele deelnemer is nu een afvaardigingsbesluit vastgelegd: de lijst uit het voorstel van 5 augustus 2026 was voorlopig, en de vraag was of mensen konden aansluiten, niet of ze een rol aanvaardden.

Borging. De werkgroep kan van start, maar stel de afvaardiging snel vast, want zonder is er geen borging dat besluiten worden gedragen en uitgevoerd. Dit is een taak voor de eerste bijeenkomsten.

Mandaat en subkringen. De subkringen binnen kring Toepassingen bestaan nog niet. Deelnemers ontlenen hun mandaat dus aan de kring zelf, of ze hebben het niet.

Openstaande vragen:

  1. Welke deelnemers bevestigt de eigen kring, met welke rol, welk tijdsbeslag en welke termijn?
  2. Welke toepassingen zijn nu niet met mandaat vertegenwoordigd, en wat is er nodig om dat te regelen?
  3. Wat is de status van wat de werkgroep oplevert zolang die vertegenwoordiging ontbreekt: een voorstel aan de kringen, of een afspraak tussen toepassingen?
  4. Welk tijdsbeslag verwacht de werkgroep tussen de bijeenkomsten door, en is dat met werkgevers afgestemd?

Planning

Wanneer Wat
19 augustus 2026 Instemming in het operationeel overleg van kring Toepassingen
27 augustus 2026 Eerste bijeenkomst, daarna elke twee weken
15 september 2026 Bekrachtiging en afvaardiging in kring Toepassingen
21 september 2026 Bekrachtiging, opdracht en afvaardiging in kring Techniek
Eind november 2026 Evaluatie van opdracht, samenstelling en werkwijze

Te besluiten

  1. Geeft de kring consent op het gezamenlijke besluit en op de opdracht vanuit deze kring, zoals opgenomen in het voorstel?
  2. Wie vaardigt de kring af, met welke rol, welk tijdsbeslag en welke termijn, en loopt dat via de Werkgroep Architectuur of via tijdelijke vertegenwoordigers?
  3. Maakt de werkgroep in haar opleveringen zichtbaar welke toepassingen niet met mandaat vertegenwoordigd waren?

Samenhang met andere trajecten

Bronnen

Wat Waar
Voorstel Werkgroep Technische Convergentie, leidend document Google Docs
Logboek van de werkgroep, agenda's en acties Google Docs
Logboek Kring Techniek, vergaderingen 20 en 27 augustus 2026 Google Docs
Voorstel van Edwin de Wit voor het omvormen van het zorgtoepassingsontwerpersoverleg, 5 augustus 2026 Slack
Zorgtoepassingenkompas, beoogd als centraal statusoverzicht, nu in draft zt-kompas.vercel.app

Wie erbij betrokken zijn

Rol Wie
Start, agenda en procesbegeleiding Edwin de Wit en Roland Groen
Afvaardiging vanuit Kring Techniek nog te bepalen, bij voorkeur via de Werkgroep Architectuur
Afvaardiging vanuit Kring Toepassingen per zorgtoepassing een inhoudelijk verantwoordelijke, nog te bevestigen

Aan de eerste bijeenkomst namen elf mensen deel; de aanwezigen staan in het logboek. Zij dragen bij op persoonlijke titel totdat hun kring de afvaardiging bevestigt.

Hoe haak je aan

Wil je meedenken over de convergentie tussen zorgtoepassingen of over de migratie van een specifieke toepassing, sluit aan in #wg-technische-convergentie of laat het weten in #kring-techniek-aanspreekpunt.

Werkgroep Architectuur

Status: in voorbereiding Waar: #kring-techniek-pub

Wat het is

Er ligt een reeks architectuurvraagstukken die nu stuk voor stuk in de hoofdkring landen en de agenda vullen: de deelname aan de VWS Design Authority en de structuur daaromheen, de reactie op het A&A-advies, de PKIOverheid G4-transitie, de Twiin-werkgroep LAS, de transitiearchitectuur binnen GIS-A, en de samenhang van de technische documentatie.

Er is eerder gesproken over een subkring Architectuur. Daar hoort een uitgewerkt domein bij met een coördinator en een afgevaardigde, en dat ligt er nog niet. Een werkgroep is de lichtere vorm die het mandaat hiervoor biedt: een concrete opdracht, zelfstandig werken binnen die opdracht, resultaat terug naar de kring.

Relevantie voor Nuts

De kring stelt de technische kaders en de visie vast, maar de vraagstukken die daarom vragen komen nu ongefilterd op de agenda. Daardoor kost besluitvorming veel vergadertijd en blijven onderwerpen liggen die voorbereiding nodig hebben. Een werkgroep die deze punten besluitrijp maakt, geeft de kring de ruimte om te besluiten in plaats van uit te zoeken.

Daarnaast is er een structurele plek nodig voor architectuurwerk dat over meerdere trajecten heen loopt: de verhouding tussen de Nuts-specifieke voorzieningen en de landelijke generieke functies is niet één project maar een doorlopende vraag.

Voorgestelde opdracht

De kring stelt een werkgroep Architectuur in, met als doel de samenhang in de Nuts-architectuur te bewaken en architectuurvraagstukken besluitrijp te maken voor de kring.

Scope. De werkgroep:

Buiten scope: besluiten over technische kaders en over deelname aan externe gremia. Die blijven bij de kring. Ook het eigenaarschap van de migratiepaden per toepassing valt hier niet onder; dat ligt bij de toepassingen zelf.

Resultaat. Besluitrijpe voorstellen, met per vraagstuk het probleem, de oplossingsrichtingen en hun voor- en nadelen. Daarnaast een voorstel voor het domein van een subkring Architectuur.

Belegging. Roland Groen, Dirk Geurs, Rein Krul en Steven van der Vegt.

Werkwijze. De werkgroep werkt zelfstandig binnen deze opdracht en rapporteert in elke kringvergadering. De inhoudelijke ondersteuning aan de Werkgroep Technische Convergentie loopt via de deelnemer die deze kring daarheen afvaardigt.

Referentie-ontwerpen

Wie een toepassing op Nuts bouwt, staat voor een reeks technische keuzes die per toepassing opnieuw worden gemaakt: hoe autorisatie wordt vastgesteld, hoe de vindplaats van gegevens wordt bepaald, hoe de gebruiker wordt geauthenticeerd, en hoe partijen elkaar vertrouwen. Dat leidt tot divergentie tussen toepassingen, tot herhaald ontwerpwerk, en tot ontwerpen die pas laat op consistentie met de kaders worden getoetst. Het geldt voor nieuwe toepassingen net zo goed als voor bestaande die naar did:web migreren.

Referentie-ontwerpen vullen dat gat: een uitgewerkt ontwerp dat een toepassing als vertrekpunt neemt en waarop zij zich profileert. Ze maken de technische kaders concreet en toepasbaar, en zijn daarmee de invulling van de herbruikbare technische bouwblokken waar de ActiZ-evaluatie om vraagt.

Eén generiek referentie-ontwerp is te grof, omdat de communicatiepatronen te veel van elkaar verschillen. Het onderscheid loopt langs twee assen: gericht of ongericht beschikbaar stellen, en de wijze waarop de gegevens worden opgehaald en gelokaliseerd.

Patroon Voorbeeldtoepassing
Gericht beschikbaar stellen, pull, mogelijk met notificatie zonder workflow Huisartsinzage, al op did:web
Ongericht beschikbaar stellen, pull met lokalisatie of discovery de inzagetoepassingen
Indexed pull, waarbij de lokalisatie van de gegevens via een index loopt nader te bepalen
Notified pull met workflow eOverdracht
Taakgebaseerde autorisatie ANW

Maatwerk per toepassing blijft daarna nodig en ligt bij de toepassing zelf.

Verhouding tot de generieke zorginzage-specificatie. Die specificatie is in opzet hetzelfde: een generiek vertrekpunt waarop inzagetoepassingen zich profileren. Zij is echter buiten de kring tot stand gekomen en het beheer ervan is niet belegd. Overweging is die specificatie onder het beheer van deze kring te brengen, als referentie-ontwerp voor het patroon ongericht beschikbaar stellen. Dat is een apart besluit dat de kring los moet nemen; het blokkeert dit onderdeel niet. Wordt het besluit niet genomen, dan blijft er overlap tussen de zorginzage-specificatie en de referentie-ontwerpen bestaan.

Wie doet wat. Deze werkgroep maakt en beheert de referentie-ontwerpen. De Werkgroep Technische Convergentie geeft input op de referenties en past ze toe op de concrete zorgtoepassingen. De subkringen per toepassing implementeren ze en rapporteren blokkades terug aan de Werkgroep Technische Convergentie.

Wat er voor de werkgroep klaarligt

Onderwerp Waar het staat
Referentie-ontwerpen per communicatiepatroon deze pagina
Gedeelde bouwblokken en hun verhouding tot de generieke functies Werkgroep Technische Convergentie
Overkoepelende v6-vraagstukken, waaronder discovery service en GF-adressering jaarplan, openstaande kaderkeuze
VWS Design Authority en de structuur daaromheen afvaardiging belegd bij Roland Groen
Reactie op het A&A-advies van VWS eigen pagina
PKIOverheid G4-transitie eigen pagina
Twiin najaarsrelease 1.6 en de werkgroep LAS eigen pagina
Transitiearchitectuur Nuts binnen GIS-A jaarplan, nog niet belegd
Samenhang van de technische documentatie architectuurvraag onder het procesvoorstel van het COT, komt in stap 4 bij de kring terug

Planning

Wanneer Wat
Voor de Twiin-consultatie van 5 oktober Referentie voor notified pull gereed, als onderdeel van de impactanalyse eOverdracht

Te besluiten

  1. Geeft de kring consent op het instellen van de werkgroep en op de opdracht zoals hierboven beschreven?
  2. Klopt de samenstelling, en is er ruimte voor deelnemers van buiten de kring?
  3. Wie vaardigt de werkgroep af naar de Werkgroep Technische Convergentie?
  4. Brengt de kring de generieke zorginzage-specificatie onder haar beheer, als referentie-ontwerp?

Samenhang met andere trajecten

Bronnen

Wat Waar
Agendapunt B, kringvergadering 20 augustus 2026 Logboek Kring Techniek
Mandaat Kring Techniek, over werkgroepen en hun opdracht Google Docs

Wie erbij betrokken zijn

Rol Wie
Beoogde deelnemers Roland Groen, Dirk Geurs, Rein Krul, Steven van der Vegt
Afvaardiging naar de Werkgroep Technische Convergentie nog te bepalen

Hoe haak je aan

Deelname aan een werkgroep vraagt geen lidmaatschap van de kring. Wil je meedoen aan het architectuurwerk, laat het weten in #kring-techniek-aanspreekpunt.

Migratie naar Nuts v6 en did:web

Status: loopt Waar: #kring-techniek-aanspreekpunt en #development

Wat het is

Onder "de v6-migratie" gaan twee verschillende dingen schuil.

De node-upgrade van v5 naar v6 is een deployment-wijziging: een SQL-store, een domeinnaam, gewijzigde poorten en TLS-terminatie. v6 is backwards compatible op API's en features, dus een toepassing die op did:nuts draait blijft werken op een v6-node.

De toepassingsmigratie van did:nuts naar did:web is een herontwerp van de toepassing: did:web en did:x509, OpenID4VCI voor de uitgifte van credentials, OID4VP als basis voor het token request, een discovery service of de GF-adressering in plaats van het gRPC-netwerk, en autorisatie op basis van de eigen administratie in plaats van de NutsAuthorizationCredential.

Die twee worden vaak als één ding besproken. Dat heeft een risico: het maakt de node-upgrade afhankelijk van besluitvorming die daar niet voor nodig is. Deze pagina houdt ze uit elkaar en beschrijft wat de kring in beide doet.

Relevantie voor Nuts

did:nuts en het gRPC-netwerk zijn deprecated en moeten uit. Het netwerk vervult op dit moment vier functies: het distribueren van publieke credentials voor adressering en zoeken, het uitwisselen van private credentials tussen partijen, het publiceren van intrekkingen, en het publiceren van DID-documenten met de bijbehorende sleutelrotatie. Voor elk daarvan moet iets in de plaats komen voordat het netwerk uit kan.

Zolang dat niet gebeurt, stapelen de kosten zich op. De resourcebehoefte van het netwerk blijft stijgen, er moet een dubbele stack in stand worden gehouden, en nieuwe leveranciers willen niet meer op did:nuts bouwen terwijl bestaande toepassingen er nog op draaien. Dat maakt aansluiten bij een bestaande toepassing moeilijker, precies waar groei zou moeten ontstaan.

De drie stappen

Stap Wat Waar het ligt
1 Node-upgrade naar v6 Kring Techniek, rechtstreeks met leveranciers en node-beheerders
2 Ontwerp van de nieuwe toepassingsversie Werkgroep Technische Convergentie, met de Werkgroep Architectuur
3 Implementatie van dat ontwerp Kring Toepassingen en de leveranciers

Stap 1 en 2 kunnen parallel: ontwerpen vraagt geen v6-node. Stap 2 vraagt wel een referentie-ontwerp voor het betreffende communicatiepatroon; zolang dat er niet is, kan een toepassing wel starten maar loopt zij het risico keuzes te maken die later afwijken. Stap 3 vereist dat stap 1 klaar is en dat er een ontwerp uit stap 2 ligt.

Daarmee is de node-upgrade de kritieke voorwaarde voor het geheel, en die kan nu al vooruit zonder dat één toepassing een besluit hoeft te nemen.

Wat er nu speelt

Opdracht 1: node-upgrade naar v6

Doel. Alle deelnemers draaien op een v6-node, zodat het uitfaseren van did:nuts en het gRPC-netwerk niet op de deployment vastloopt.

Scope. Inventarisatie van wie nog op v5 draait en wat hen tegenhoudt; documentatie op het niveau van een beheerder in plaats van een ontwikkelaar; en ondersteuning per leverancier bij de upgrade zelf.

Buiten scope: het omzetten van de toepassing, en het beheer van individuele nodes bij deelnemers.

Resultaat. Een beeld van het resterende v5-gebruik, bijgewerkte migratiedocumentatie, en deelnemers die de upgrade kunnen uitvoeren.

Belegging. Het producteigenaarschap van de nuts-node, zie Beheer en doorontwikkeling nuts-node.

Werkwijze. Rechtstreeks met de leveranciers en node-beheerders, zoals dat bij KIK-V is gedaan via een eigen kanaal en een gezamenlijke doorloop van de bevindingen. Dit vraagt geen tussenkomst van een toepassing.

Opdracht 2: ontwerp van de nieuwe toepassingsversie

Doel. Elke toepassing heeft een uitgewerkt ontwerp voor de overgang naar did:web, gebaseerd op een referentie-ontwerp en niet op een eigen interpretatie.

Scope. Per toepassing in beeld brengen welke technische stap aan de orde is en waar die op vastloopt; de referentie-ontwerpen per communicatiepatroon toepassen op de toepassing; en de vraagstukken die om een kaderkeuze vragen terugbrengen naar de kring.

Buiten scope: de implementatie zelf, en de planning en prioritering daarvan.

Resultaat. Per toepassing een ontwerp dat als basis voor implementatie kan dienen, en zicht op wat er per toepassing nog aan besluitvorming of ondersteuning nodig is.

Belegging. De Werkgroep Technische Convergentie, met de referentie-ontwerpen en de kaderkeuzes vanuit de Werkgroep Architectuur.

Afhankelijkheid. Deze opdracht steunt op de referentie-ontwerpen. De volgorde waarin die beschikbaar komen bepaalt dus welke toepassingen als eerste aan de beurt zijn, en dat is een keuze die in samenhang met de behoefte van de toepassingen wordt gemaakt.

Stap 3: implementatie

De implementatie ligt bij de kring Toepassingen en de leveranciers, die dat zelfstandig doen. Vanuit deze kring is er ad-hoc ondersteuning via #development. Blokkades die tijdens de implementatie ontstaan gaan naar de Werkgroep Technische Convergentie, die ze bundelt en bij de kring neerlegt als ze capaciteit of een kaderkeuze vragen.

Deze stap staat hier om de afhankelijkheid zichtbaar te maken, niet omdat de kring er een opdracht in heeft.

Wat er al ligt

Wat Waar Aandachtspunt
Migratiehandleiding voor de node en de use case wiki, v5 naar v6 migration guide Een jaar niet bijgewerkt. Bevat een geordende migratiereeks per use case, en de aanname dat een use case één partij aanwijst die de discovery server host. Die aanname is geen vastgesteld kader.
Deployment- en migratiedocumentatie readthedocs Bijgewerkt in juni 2026. Te beknopt voor beheerders; aanvullingen over poorten en beveiliging zijn toegezegd.
Analyse van de KIK-V-migratie, in twee stappen Slack, #kikv-v6-migratie Bruikbaar als model voor andere toepassingen.
Bevindingenrapportage van Tribe, met de DaaS-leveranciers via KIK-V Geen blockers gevonden voor de node-upgrade.
Inventarisatie per zorgtoepassing, met DID-methode, protocollen en credentials spreadsheet zorgtoepassing-ontwerpers Uit begin 2025, actualisatie nodig.
Ontwerphandleiding voor toepassingen wiki, designing a nuts use case

Openstaande kaderkeuzes

Deze liggen bij de Werkgroep Architectuur en komen als besluit terug in de kring:

Te besluiten

  1. Welke termijn hangen we aan opdracht 1? De node-upgrade is de kritieke voorwaarde voor stap 3 en heeft nu geen einddatum.
  2. Wordt de migratiehandleiding bijgewerkt en als aanbevolen pad vastgesteld, en wie doet dat?

Samenhang met andere trajecten

Wie erbij betrokken zijn

Rol Wie
Opdracht 1, node-upgrade Rein Krul, vanuit het producteigenaarschap
Opdracht 2, ontwerp per toepassing Werkgroep Technische Convergentie
Referentie-ontwerpen en kaderkeuzes Werkgroep Architectuur
Implementatie de toepassingen en hun leveranciers

Hoe haak je aan

Draai je nog op v5 en wil je upgraden, meld je in #development. Gaat het over het omzetten van een toepassing naar did:web, dan loopt dat via de Werkgroep Technische Convergentie.

Generieke Functies

Status: Waar: #gf-cot

Wat het is

Relevantie voor Nuts

Wat wij de werkgroep vragen

Planning

Te besluiten

Samenhang met andere trajecten

Bronnen

Wie erbij betrokken zijn

Hoe haak je aan

Deelprojecten

Hosting

De projectgroep wil een test/sandbox omgeving hosten om demo's te kunnen geven en voor leveranciers om tegenaan te testen. In de toekomst kan het zijn dat we naar de gekozen hosting provider, ook andere Nuts services willen migreren (nu alleen de Wiki), want die worden nog gehost door Nedap.

Het selectieproces voor de hosting provider is als volgt:

  1. In kaart brengen requirements (zie GitHub issue)
  2. In kaart brengen hosting providers (zie GitHub issue)
  3. Keuze maken en voorleggen aan Kring Techniek ter goedkeuring

Hosting van de GF-testomgeving

Status: besluit voorgesteld. Het is bekrachtigd als er vóór maandag 7 september 2026 geen bezwaar is vanuit de leden van de kring Techniek. Waar: #kring-techniek-pub en #gf-cot

Wat het is

Vanuit project Generieke Functies wordt een test- en sandboxomgeving gebouwd, voor onszelf en voor leveranciers om tegenaan te testen. Het functioneel ontwerp beschrijft wat die omgeving moet doen.

Volgens de huidige praktijk zou die omgeving op de zakelijke hostingomgeving van Rein Krul komen te draaien, zoals de bestaande GF-testomgeving nu ook doet. Nu er meer diensten voor langere tijd gehost gaan worden, is de wens de hosting zo op te zetten dat iedereen binnen het COT haar kan onderhouden. In de huidige omgeving is dat niet mogelijk en niet wenselijk.

Waarom dit langs de kring gaat

Hosting van gedeelde omgevingen valt onder ons mandaat, net als de andere community-tooling en samenwerkingsmiddelen. Het gaat om een structurele voorziening met terugkerende kosten, om een contract dat namens de stichting wordt afgesloten, en om het weghalen van een afhankelijkheid van één persoon.

Het voorstel

Managed Kubernetes bij OVHcloud. Het eerste jaar op maandcontract, zodat er geen langdurige binding ontstaat en overstappen eenvoudig blijft.

Af te nemen diensten:

Na ingebruikname vervalt de hostingomgeving bij Rein.

Kosten. Naar verwachting 1200 tot 1800 euro voor het eerste jaar, ten laste van project GF.

Scope. Vooralsnog alleen diensten van project GF: de nieuwe test- en sandboxomgeving en wat daarvan nu bij Rein draait. Andere Nuts-diensten daar in de toekomst ook hosten wordt niet uitgesloten, maar is geen onderdeel van dit besluit.

Wanneer. Ingang medio 1 oktober 2026, evaluatie na zes maanden op 1 april 2027.

Wie. Het hostingcontract wordt afgesloten door Steven van der Vegt namens het bestuur van Stichting Nuts. Administratieve rechten worden ingericht zoals bij de GitHub-organisatie van Nuts, met dezelfde personen en vergelijkbare rechten. COT-leden krijgen operationele rechten om de omgeving te onderhouden, deployen en debuggen.

De afweging

Overwogen zijn STACKIT, IONOS, OVHcloud, Scaleway, Exoscale, T Cloud Public, Cyso Cloud en Hetzner. Alleen STACKIT, IONOS, OVHcloud en Scaleway scoorden voldoende op alle requirements. Scaleway is afgevallen vanwege slechte ervaringen met de supportdesk, bij Edwin en Formelio en bij Gaspar. Van de overgebleven drie is OVHcloud verreweg het goedkoopst.

Het nadeel van OVHcloud is dat er geen native ondersteuning is voor OpenTelemetry. Uit onderzoek en navraag bij Edwin en Formelio blijkt dat eenvoudig zelf te regelen, zonder veel extra hostingkosten.

De uitgebreide analyse staat in de GitHub-issues, zie Bronnen.

Requirements

Opgesteld door het COT.

Must:

Should:

Te besluiten

Het besluit is voorbereid door het COT en ligt als bezwaarronde bij de kring. Het is bekrachtigd als er vóór maandag 7 september 2026 geen bezwaar is van leden van de kring Techniek.

Samenhang met andere trajecten

Bronnen

Wat Waar
Besluit: hosting test/sandbox-omgeving project GF bij OVHcloud Google Docs
Functioneel ontwerp van de test- en sandboxomgeving Google Docs
Inventarisatie van de requirements nuts-knooppunt issue 528
Onderzoek naar hostingproviders nuts-knooppunt issue 558
OVHcloud ovhcloud.com
Bezwaarronde in de kring, 27 augustus 2026 Slack, #kring-techniek-pub

Wie erbij betrokken zijn

Rol Wie
Voorstel, requirements en selectie Rein Krul, namens het COT
Afsluiten van het hostingcontract Steven van der Vegt, namens het bestuur van Stichting Nuts
Beheer van de omgeving COT-leden, met operationele rechten

Hoe haak je aan

Bezwaar of vragen over de hostingkeuze, vóór 7 september: #kring-techniek-pub. Over de inhoud van de sandboxomgeving: #gf-cot.

Vernieuwing van de technische documentatie

Status: in voorbereiding, procesvoorstel ligt bij de kring Waar: #gf-cot en #kring-techniek-pub

Wat het is

In verschillende trajecten van het afgelopen jaar is vastgesteld dat de Nuts-documentatie niet toegankelijk is voor nieuwkomers. Daardoor is het moeilijker dan nodig om Nuts te begrijpen of ermee aan de slag te gaan. Het Centraal Ontwikkel Team werkt hieraan vanuit project Generieke Functies en heeft een procesvoorstel gemaakt om de vernieuwing aan te pakken.

De klachten die daaraan ten grondslag liggen:

Relevantie voor Nuts

De documentatie is onderdeel van hoe wij onze standaarden en implementaties beheren en uitdragen, en de omgevingen waarin zij staat vallen onder community-tooling en samenwerkingsmiddelen. De reikwijdte van dit traject omvat naast de knooppunt-documentatie ook de documentatie van de nuts-node en de specificaties, en raakt daarmee ook Beheer en doorontwikkeling nuts-node.

Beoogde uitkomst

Een eenduidige, goed doorzoekbare set documentatie met een duidelijke inhoudsopgave. Tekortkomingen worden opgehaald door met de community te praten; tooling wordt vernieuwd waar nodig, met consent van de huidige eigenaren van die bronnen. Het resultaat wordt getoetst door feedback te vragen aan de verschillende gebruikersgroepen.

Het proces

Stap Wat
1 Inventariseren: welke bronnen zijn er, met welk doel, voor welk publiek, wie schrijft ze en wat is de kwaliteit. En welke persona's willen we bedienen.
2 Wensen vaststellen: interviews met vertegenwoordigers van stakeholders, aanvullende wensen ophalen en bestaande adviezen verwerken, zoals het rapport van ActiZ en InfoZorg. Resultaat is een doelsituatie met requirements voor inhoud en tooling.
3 Selectie van documentatie-tooling, op basis van onderzoek naar de opties.
4 Voorstel tot verbetering: welke bronnen samengevoegd, verwijderd of gearchiveerd, geherstructureerd of uitgebreid moeten worden.
5 Prototype ontwikkelen, met voorbeelddocumentatie in de gekozen tooling.
6 Voorstel aan de kring Toepassingen en de kring Techniek: gaan we de documentatie herzien volgens dit prototype?
7 Realisatie: nieuwe systemen opzetten, content migreren, publiceren, nieuwe documentatie schrijven en de bestaande herstructureren.

Stap 6 is het besluitmoment. Voordat er iets aan de huidige documentatie verandert, ligt er een inhoudelijk plan bij de kringen. De kringen worden uitgenodigd een afgevaardigde aan het proces te laten deelnemen.

Wat er al ligt

Het document bevat naast het procesvoorstel ook een vooronderzoek en een eerste vernieuwingsvoorstel:

Wat er nu speelt

Het procesvoorstel is op 13 augustus 2026 gedeeld in #kring-techniek-pub en geagendeerd voor de kringvergaderingen van 20 en 27 augustus. Twee commentaarpunten zijn verwerkt. Eén punt is blijven staan: de scope van het traject. De uitkomst van de behandeling is niet vastgelegd in het logboek.

Daarnaast loopt een discussie over twee parallelle sporen en over het ontwikkelen van een prototype.

Te besluiten

  1. Onderschrijft de kring het procesvoorstel en de reikwijdte daarvan, inclusief de nuts-node-documentatie en de specificaties?
  2. Vaardigt de kring iemand af naar dit proces?

Samenhang met andere trajecten

Bronnen

Wat Waar
Procesvoorstel Vernieuwing Nuts Documentatie, met vooronderzoek en vernieuwingsvoorstel Google Docs
Aankondiging en verzoek om commentaar, 13 augustus 2026 Slack, #kring-techniek-pub

Wie erbij betrokken zijn

Rol Wie
Procesvoorstel en uitvoering Rein Krul en Dirk Geurs, namens het COT
Afvaardiging vanuit de kring Techniek nog te bepalen
Afvaardiging vanuit de kring Toepassingen nog te bepalen

Hoe haak je aan

Heb je last van de huidige documentatie of wil je meedenken over de nieuwe opzet, laat het weten in #gf-cot of in #kring-techniek-aanspreekpunt.

POC TTA Notifications v0.6

Status: in uitvoering
Opdrachtgever: Steven van der Vegt, coördinator Kring Techniek
Uitvoering: Gasper, vanuit het COT
Type: operationele opdracht van de coördinator, ter mededeling in de kringvergadering

Wat

Bouw een proof of concept van de TTA Notifications v0.6 in het knooppunt, op een losse branch. De nadruk ligt op het beantwoorden van de onderzoeksvragen, niet op de code. De code is wegwerpcode en hoeft niet aan de gebruikelijke kwaliteitseisen te voldoen. Of en in welke vorm het naar main gaat, besluiten we daarna op basis van de conclusies.

De POC implementeert beide rollen uit de TTA:

Optionele features en permutaties. De TTA laat een aantal keuzes open: in-band of out-of-band, heartbeat wel of niet, $events wel of niet, empty of id-only. Optionele features zijn meestal het resultaat van een onderhandeling waarin de ene partij iets belangrijk vond en de andere niet. De vraag is wat er gebeurt als die twee partijen samen gaan uitwisselen. Onderdeel van de opdracht is daarom de combinaties van deze keuzes te beproeven tussen een server en een client die verschillende keuzes maken. Als dat in code te duur wordt, mag het in de analyse worden afgehandeld, met per combinatie wat er volgens de spec zou moeten gebeuren en waar de spec dat open laat.

De TTA werkt authenticatie en autorisatie niet uit. Voor de POC mogen die worden gemockt, maar het is wel een onderzoeksvraag.

Waarom

  1. Feedback op de specificatie naar Twiin. Wij schrijven mee aan de harmonisatie van de TA Notified Pull en de TTA Notifications is daar het eerste resultaat van, zie Harmonisatie TA Notified Pull. Een implementatie is de snelste manier om te zien of de specificatie volledig en consistent is. De bevindingen brengen we in via de subwerkgroep en de consultatie van Twiin najaarsrelease 1.6.
  2. Input voor de toepassingen. De toepassingen (eOverdracht voorop) moeten een impactanalyse doen op de nieuwe TTA. Een referentie in het knooppunt laat zien wat er op hen afkomt en wat het knooppunt daarvan voor hen kan afvangen.

Onderzoeksvragen

  1. Is de specificatie volledig en correct? Waar loop je vast, waar moet je zelf een keuze maken die de spec had moeten maken, waar spreekt de spec zichzelf tegen?
  2. Hoeveel werk is het om te implementeren?
  3. Hoeveel werk neemt een referentie-implementatie in het knooppunt de implementator uit handen? Is de abstractie voldoende, of bouw je alsnog alles in je eigen applicatie? Wat beheert het knooppunt (subscriptionstate, event-numbers, retry, heartbeats) en wat blijft bij de toepassing?
  4. Op welke onderdelen helpt de knooppunt-implementatie je concreet, en op welke niet?
  5. Hoe past authenticatie en autorisatie in ons model? Waar landen de verplichte autorisatie- en consentchecks (voor activatie en voor iedere notificatie) in het knooppunt, en hoe verhoudt de mTLS-eis uit de TTA zich tot ons model? Is de autorisatiehint uit de huidige Twiin TA NP een zinvol onderdeel van de notificatie?
  6. Optionele features. Wat gebeurt er als server en client verschillende keuzes maken op de optionele onderdelen? Waar gaat het mis en zegt de spec daar iets over?
  7. FHIR-versie. De TTA schrijft R4 of R4B voor voor het subscriptionframework. De eOverdracht zit op STU3. Werkt het framework naast STU3-resources, en wat betekent dat voor een toepassing?
  8. Id-only eisen. De TTA stelt eisen aan resource-identifiers (stabiel, opaak, onvoorspelbaar). Voldoen de identifiers die onze toepassingen en gangbare FHIR-servers nu uitgeven daaraan? Zo niet, wat is de consequentie?
  9. Adressering. Hoe lost het knooppunt het notificatie-endpoint en het Subscription-endpoint op via GF Adressering (mCSD, Endpoint met payloadType Subscription)?
  10. Verschil met nu. Wat is het verschil met de huidige eOverdracht-notificatie en met de Nuts-variant van de TA NP, en wat is grofweg het migratiepad?

Wanneer

Wie

Waar

Resultaat

  1. Werkende POC op een branch, beide rollen, demonstreerbaar.
  2. Een demo.
  3. Een deelbaar bevindingendocument met antwoorden op de onderzoeksvragen, met twee delen: fouten en gaten in de specificatie (naar Twiin) en implementatie-impact (naar de toepassingen).
  4. Een korte conclusie voor de werkgroep Technische Convergentie als input voor de impactanalyse van de toepassingen.

Samenhang met andere trajecten

Bronnen

Wat Waar
TTA Notifications v0.6 ontwikkelsupplement.twiin.nl
Concept notificatiespecificatie in de generieke-functies-IG build.fhir.org
Integratiefase: plan en budget, mei 2026 Google Doc
Oproep aan de eOverdracht-deelnemers over de impactanalyse, augustus 2026 Slack, #kring-toepassingen
Bespreking en toewijzing in het COT-planningsoverleg, 7 september 2026 COT logboek operationeel overleg