# Projecten



# LSP x Nuts

**Status:** loopt
**Waar:** [#lspxnuts](https://nuts-foundation.slack.com/archives/C057FDAHZ5F)

## 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

- De specificaties zijn vrijwel gereed en de eerste tests voor access-token-requests zijn geslaagd.
- We werken toe naar de eerste koppeling van fase 1 en bereiden fase 2 en de bijbehorende autorisatielijn voor.
- Er ligt een uitgewerkt generiek autorisatiemodel dat over verschillende afsprakenstelsels heen werkt (AORTA-on-FHIR, MedMij, Twiin, Nuts-toepassingen). VWS en de GIS-doelarchitectuur zijn hierop aangehaakt.
- VWS is voornemens LSP x Nuts aan te wijzen als plek waar een generieke deelcomponent wordt gerealiseerd. In de aanbesteding voor de GF-pilots is de uitwisseling LSP x Nuts expliciet genoemd binnen de tranche Medicatieoverdracht.
- Er ligt een voorstel om namens LSP x Nuts deel te nemen aan de Twiin werkgroepen TA Pull en TA Indexed Pull, zodat de ontwikkeling daar in lijn blijft. Wie dat doet is nog niet bepaald.

## Bewegende delen en TODO's:

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

- Participation Guide: met TBD sectie die nog moet worden uitgezocht.
- Andere Guides: bijwerken op basis van de gekozen toepassing
- Leveranciers begeleiden
- PvE van VZVZ: doorlopen en vergelijken met solution design
- Technische specificatie van VZVZ: doorlopen en vergelijken met solution design
- Impact analyse van de use-case op de infrastructuur:
  - informatiestandaard (keten bouwstenen?)
  - beschikbaarheid van bouwblokken bij de bronsystemen
  - Autorisatie scopes van [authz model](https://build.fhir.org/ig/nuts-foundation/nl-generic-functions-ig/branches/add-authorization-information-model/authorization-model.html) uitwerken en inbouwen
  - FHIR queries in kaart brengen
  - toetsing van de autorisatie afspraken voor nieuwe type raadplegers
- Implementatie in de nuts-node (zie [issues](https://github.com/nuts-foundation/nuts-node/issues?q=is%3Aissue+state%3Aopen+label%3ALSPxNuts)): issues bijwerken.
- Uitgifte van Deelname credential (dienstverlener en zorginstellng?) en software: [issue #4092](https://github.com/nuts-foundation/nuts-node/issues/4092)
  - Proces in kaart brengen van toelating
  - Data model ontwerpen
  - Bouwen van de issuer
  - Authenticatie afspreken
    - van de VZVZ gebruiker: 2-factor, integratie met VZVZ identity provider?
    - van de dienstverlener bij de uitgifte van de VC (zorgab user/passw?) of mailtje sturen met een link/token. (out of band authenticatie).
    - of service provider geen did en krijgt in de mail het VC terug. Geen lastige authenticatie procedure, wel een net proces voor het aanvragen met bijv. copy identificatie en handtekening.
- Werkende testomgeving met issuer en nuts raadpleger die ATs en data kan ophalen.

## Wie erbij betrokken zijn

| Rol | Wie |
| --- | --- |
| Architectuur, PSA en solution design | [Steven van der Vegt](https://nuts-foundation.slack.com/team/UBRJHSL1H), [Dirk Geurs](https://nuts-foundation.slack.com/team/U093U5CU50D) |
| Implementatie in de nuts-node | [Rein Krul](https://nuts-foundation.slack.com/team/US77A2MQR) |
| Technische afstemming pilots | wekelijks, dinsdagmiddag |

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

## Documenten en repositories

- [Participation guide voor de pilots](https://github.com/nuts-foundation/lspxnuts-pilots/blob/main/docs/LSPxNuts-participation-guide.md)
- [Autorisatiemodel (concept-IG)](https://build.fhir.org/ig/nuts-foundation/nl-generic-functions-ig/branches/add-authorization-information-model/authorization-model.html)
- [Openstaande issues in de nuts-node](https://github.com/nuts-foundation/nuts-node/issues?q=is%3Aissue+state%3Aopen+label%3ALSPxNuts)

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](https://nuts-foundation.slack.com/archives/C057FDAHZ5F). Voor vragen over hoe dit zich verhoudt tot de technische kaders van Nuts: [#kring-techniek-aanspreekpunt](https://nuts-foundation.slack.com/archives/C0BN2HA409L).

# New Page



# Verwijzen naar het Landelijk afsprakenstelsel

**Status:** loopt
**Waar:** [#kring-techniek-aanspreekpunt](https://nuts-foundation.slack.com/archives/C0BN2HA409L)

## 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:

- **Toepassingen.** Voorlopig niet aan de orde. Zodra verwijzen naar een landelijke afspraak betekent dat onze specificaties inhoudelijk moeten wijzigen, hoort dat daar. Dat is nu niet het geval; de PoCathon gebruikt een testobject.
- **Gezamenlijk belang.** Twee vragen. Wordt naleving van de richtlijnen verplichtend voor afsprakenstelsels, en wie besluit daarover? En willen wij als Nuts verwijzen naar afspraken die eisen stellen aan de bedrijfsvoering van onze deelnemers en hun leveranciers? Op de eerste vraag kan Twiin geen antwoord geven en wordt verwezen naar VWS (Ageeth Wahle). De tweede is aan onszelf.

## Hoe het speelveld in elkaar zit

- **Inhoudseigenaren.** De inhoud van landelijke afspraken komt uit VWS-programma's: Landelijk dekkend netwerk (LDN), Implementatie generieke functies, Eenheid van taal en techniek, en Data voor burgers. Veilig netwerk komt uit LDN.
- **Landingsplaats.** Het Twiin Afsprakenstelsel publiceert de landelijke afspraken en bouwt het Register landelijke afspraken met de meta-informatie. Twiin is tegelijk zelf een afsprakenstelsel naast de andere deelnemende stelsels.
- **Opdrachtgever.** De werkgroep valt onder het VWS-project Implementatie Landelijk afsprakenstelsel (Ageeth Wahle). De bredere Tafel Afsprakenstelsels is een apart gremium; daar kwam in april een huiswerkopdracht uit om de richtlijnen toe te passen op Veilig netwerk. Of die opdracht voor ons nog staat is niet vastgesteld.
- **Doelarchitectuur.** De GISA (gezondheidsinformatie-architectuur) is de richting waarnaar de rollen in landelijke afspraken moeten convergeren.

## Wat er nu speelt

- 1 september: online werkgroepoverleg om gezamenlijk het plan van aanpak voor de PoCathon te maken. Daar wordt ook besloten of er tussentijds huiswerk is.
- 7 september: online Tafel Afsprakenstelsels met toelichting op de PoCathon.
- 29 oktober: PoCathon in Den Haag. Testobject wordt Adressering of Toestemming. De hele Tafel wordt uitgenodigd om de resultaten te zien.
- Wie namens Nuts deelneemt is nog niet bepaald.

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

- **Veilig netwerk is een tijdelijke afspraak.** Twiin had een tijdelijke afspraak in het stelsel opgenomen en heeft LDN gevraagd om afspraken en specificaties. Er komt een duurzamer afspraak met specs.
- **De afspraak krijgt de rollen van de landingsplaats mee.** De eisen dragen de rollen Twiin Deelnemer en GTK Leverancier en de toetsingscategorie Via Twiin, terwijl de afspraak daar zelf niet over gaat. Een stelsel dat hiernaar verwijst neemt impliciet het Twiin-rolmodel en Twiin als toetsende partij over. Twiin onderschrijft dit: wordt het een echte landelijke afspraak, dan moet die neutraler beschreven worden met rollen die bij de GISA passen.
- **De inhoud van het PvE is organisatorisch, niet technisch.** De eisen gaan over bedrijfscontinuïteit, leverancierscontracten, MFA op beheeraccounts, pentests en awareness. Er is niets aan te implementeren in de nuts-node of in onze profielen.
- **De objecten voldoen nog niet aan de richtlijnen zelf.** Losse eisen hebben geen eigen permalink of meta-informatie, en het register is nog in ontwikkeling. Ook is niet elke eis testbaar, terwijl de richtlijnen dat als definitie van een eis gebruiken.
- **Vragen over de inhoud horen bij de bron.** Voor inhoudelijke vragen of bezwaren over deze eisen is LDN het adres, niet Twiin als publicerende partij.

## Documenten

| Wat | Waar |
| --- | --- |
| Richtlijnen Verwijzen naar landelijke afspraken in Twiin, v0.2, juni 2026 | [twiin.nl](https://www.twiin.nl/media/downloads/richtlijnen-verwijzen) |
| PvE Netwerkbeveiliging Twiin Deelnemer (TA150), normatief | [afsprakenstelsel.twiin.nl](https://afsprakenstelsel.twiin.nl/normatief/ta150/pve-netwerkbeveiliging-twiin-deelnemer) |
| PvE Netwerkbeveiliging Twiin Deelnemer (TC150D), prepublicatie | [consultatie.twiin.nl](https://consultatie.twiin.nl/prepublicatie/tc150d/pve-netwerkbeveiliging-twiin-deelnemer) |
| Landelijk afsprakenstelsel, algemene informatie | [datavoorgezondheid.nl](https://www.datavoorgezondheid.nl/onderwerpen/l/landelijk-afsprakenstelsel) |

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](https://nuts-foundation.slack.com/archives/C0BN2HA409L).

# Werkgroep Technische Convergentie

**Status:** in voorbereiding
**Waar:** [#kring-techniek-pub](https://nuts-foundation.slack.com/archives/C09PXMF9R1D) en [#zorgtoepassing-ontwerpers](https://nuts-foundation.slack.com/archives/C087KQ58E0J)

Het leidende document is het [Voorstel Werkgroep Technische Convergentie](https://docs.google.com/document/d/1sPzZmK-ty_d_O8LgOP0QHg7WmmMl5gk1twRd5NI1Xf8/edit). Daarin staan de exacte formulering van het gezamenlijke besluit, de opdrachten vanuit beide kringen, de resultaten en de grenzen, en worden de openstaande punten bijgehouden. 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.

## 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 met 27 augustus 2026 als beoogde startdatum, 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](https://wiki.nuts.nl/books/kring-techniek/page/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.

## Planning

| Wanneer | Wat |
| --- | --- |
| Voor 27 augustus | Bekrachtiging van het gezamenlijke deel in beide kringen |
| 27 augustus 2026 | Beoogde startdatum van de werkgroep |
| Na drie maanden | 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, en loopt dat via de Werkgroep Architectuur of via tijdelijke vertegenwoordigers?

## Samenhang met andere trajecten

- **[Werkgroep Architectuur](https://wiki.nuts.nl/books/kring-techniek/page/werkgroep-architectuur).** Beheert de referentie-ontwerpen en is de beoogde route waarlangs deze kring deelnemers afvaardigt.
- **Migratie naar did:web.** Het onderwerp waar de werkgroep het meest concreet op stuurt; het eigenaarschap blijft bij de toepassingen.
- **Generieke functies.** De landelijke functies waar de migratiepaden naartoe werken.
- **[Harmonisatie TA Notified Pull](https://wiki.nuts.nl/books/kring-techniek/page/harmonisatie-ta-notified-pull).** Bepaalt het patroon waarop het referentie-ontwerp voor notified pull steunt.
- **Vernieuwing van de eOverdracht-standaarden.** Ligt bij Kring Toepassingen en loopt mee in de migratie.

## Bronnen

| Wat | Waar |
| --- | --- |
| Voorstel Werkgroep Technische Convergentie, leidend document | [Google Docs](https://docs.google.com/document/d/1sPzZmK-ty_d_O8LgOP0QHg7WmmMl5gk1twRd5NI1Xf8/edit) |
| Voorstel van Edwin de Wit voor het omvormen van het zorgtoepassingsontwerpersoverleg, 5 augustus 2026 | [Slack, #zorgtoepassing-ontwerpers](https://nuts-foundation.slack.com/archives/C087KQ58E0J/p1785919541021609) |
| Zorgtoepassingenkompas, beoogd als centraal statusoverzicht, nu in draft | [zt-kompas.vercel.app](https://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 |

## Hoe haak je aan

Wil je meedenken over de convergentie tussen zorgtoepassingen of over de migratie van een specifieke toepassing, laat het weten in [#kring-techniek-aanspreekpunt](https://nuts-foundation.slack.com/archives/C0BN2HA409L).

# Werkgroep Architectuur

**Status:** in voorbereiding
**Waar:** [#kring-techniek-pub](https://nuts-foundation.slack.com/archives/C09PXMF9R1D)

## 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:

- pakt de openstaande architectuurpunten op en bereidt die voor besluitvorming in de kring voor
- beheert de brede technische kaders: de randvoorwaardelijke afspraken die voor alle toepassingen gelden, zoals het gebruik van FHIR, identifiers en codestelsels, het vertrouwensmodel, netwerk- en beveiligingseisen, de toepassing van NEN-normen en de juridische kaders die daaraan raken
- brengt in kaart welke gedeelde bouwblokken er zijn of nodig zijn, en hoe die zich verhouden tot de Nuts-specifieke voorzieningen en de landelijke generieke functies
- maakt en beheert de referentie-ontwerpen voor toepassingen op Nuts, zie hieronder
- werkt de overkoepelende technische vraagstukken rond de v6-migratie uit, waaronder het gat tussen de discovery service en de nog niet beschikbare GF-adressering
- ondersteunt de [Werkgroep Technische Convergentie](https://wiki.nuts.nl/books/kring-techniek/page/werkgroep-technische-convergentie) inhoudelijk: verzorgt de aansluiting vanuit deze kring, beantwoordt de vragen die daar opkomen over bouwblokken en de v6-migratie, en brengt vraagstukken die om een kaderkeuze vragen terug naar de kring
- werkt een voorstel uit voor het domein van een subkring Architectuur

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](https://wiki.nuts.nl/books/kring-techniek/page/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](https://wiki.nuts.nl/books/kring-techniek/page/reactie-op-de-vws-memo-harmonisatie-van-authenticatie-en-autorisatie) |
| PKIOverheid G4-transitie | [eigen pagina](https://wiki.nuts.nl/books/kring-techniek/page/pkioverheid-g4-transitie) |
| Twiin najaarsrelease 1.6 en de werkgroep LAS | [eigen pagina](https://wiki.nuts.nl/books/kring-techniek/page/twiin-najaarsrelease-16) |
| 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

- **[Werkgroep Technische Convergentie](https://wiki.nuts.nl/books/kring-techniek/page/werkgroep-technische-convergentie).** De werkgroep Architectuur is de beoogde route waarlangs deze kring daar deelnemers afvaardigt, en levert de inhoudelijke ondersteuning op bouwblokken en v6-vraagstukken.
- **Subkring Architectuur.** Het uitwerken van dat domein is onderdeel van deze opdracht; de werkgroep is de tussenstap.
- **Externe verzoeken en consultaties.** De opdrachten die uit externe verzoeken volgen kunnen bij deze werkgroep worden belegd, zodat ze niet van één agenda afhangen.

## Bronnen

| Wat | Waar |
| --- | --- |
| Agendapunt B, kringvergadering 20 augustus 2026 | [Logboek Kring Techniek](https://docs.google.com/document/d/1smTHGgPe5LrUhGp77pAY98mlrgU7YrMkImN3QfUkkI8/edit) |
| Mandaat Kring Techniek, over werkgroepen en hun opdracht | [Google Docs](https://docs.google.com/document/d/1tet3CcciKe_4w1wSU7pvudg_HBntZbjsQuisLdyQbq0/edit) |

## 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](https://nuts-foundation.slack.com/archives/C0BN2HA409L).

# Migratie naar Nuts v6 en did:web

**Status:** in voorbereiding
**Waar:** [#kring-techniek-aanspreekpunt](https://nuts-foundation.slack.com/archives/C0BN2HA409L) en [#development](https://nuts-foundation.slack.com/archives/C02GJMAE7TL)

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

## 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](https://wiki.nuts.nl/books/kring-techniek/page/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](https://wiki.nuts.nl/books/kring-techniek/page/werkgroep-technische-convergentie), met de referentie-ontwerpen en de kaderkeuzes vanuit de [Werkgroep Architectuur](https://wiki.nuts.nl/books/kring-techniek/page/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](https://nuts-foundation.slack.com/archives/C02GJMAE7TL). 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](https://wiki.nuts.nl/books/v5-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](https://nuts-node.readthedocs.io/en/latest/pages/deployment/migration.html) | 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](https://nuts-foundation.slack.com/archives/C0B0PKLDJRX) | 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](https://docs.google.com/spreadsheets/d/1fS-j483994KBJsDBhxB5umPi3UQ7Z_D5d1V6EYjHo6g/edit) | Uit begin 2025, actualisatie nodig. |
| Ontwerphandleiding voor toepassingen | [wiki, designing a nuts use case](https://wiki.nuts.nl/books/designing-a-nuts-use-case) | |

## Openstaande kaderkeuzes

Deze liggen bij de [Werkgroep Architectuur](https://wiki.nuts.nl/books/kring-techniek/page/werkgroep-architectuur) en komen als besluit terug in de kring:

- **Adressering in de tussenperiode.** De discovery service uit v6 wordt vervangen door de GF-adressering, die nog niet beschikbaar is. Laten we partijen wachten, gebruiken ze tijdelijk de uit te faseren discovery service, of zetten we zelf een tijdelijke voorziening op?
- **Migratiescenario.** Gaat een toepassing in één keer over, of migreert zij stapsgewijs met een periode waarin oud en nieuw naast elkaar bestaan? Beide scenario's moeten worden uitgewerkt, met hun gevolgen en hun voor- en nadelen.
- **Status van de migratiehandleiding.** Het migratieboek bevat een geordende reeks stappen per use case en een richtingkeuze over de discovery server. Stelt de kring die reeks vast als aanbevolen pad, en wordt het boek daarvoor bijgewerkt?

## Te besluiten

1. Bevestigt de kring de scheiding in drie stappen, en de belegging van opdracht 1 en 2 zoals hierboven beschreven?
2. Welke termijn hangen we aan opdracht 1? De node-upgrade is de kritieke voorwaarde voor stap 3 en heeft nu geen einddatum.
3. Wordt de migratiehandleiding bijgewerkt en als aanbevolen pad vastgesteld, en wie doet dat?

## Samenhang met andere trajecten

- **[Werkgroep Architectuur](https://wiki.nuts.nl/books/kring-techniek/page/werkgroep-architectuur).** Maakt de referentie-ontwerpen en bereidt de kaderkeuzes voor.
- **[Werkgroep Technische Convergentie](https://wiki.nuts.nl/books/kring-techniek/page/werkgroep-technische-convergentie).** Brengt het beeld per toepassing op en past de referentie-ontwerpen toe.
- **[Beheer en doorontwikkeling nuts-node](https://wiki.nuts.nl/books/kring-techniek/page/beheer-en-doorontwikkeling-nuts-node).** Opdracht 1 loopt via het producteigenaarschap.
- **Generieke functies.** De GF-adressering bepaalt of de tijdelijke voorziening nodig is; de overige generieke functies zijn de bestemming van de toepassingsmigratie.
- **[PKIOverheid G4-transitie](https://wiki.nuts.nl/books/kring-techniek/page/pkioverheid-g4-transitie).** Deelnemers die nog op v5 draaien krijgen twee wijzigingen tegelijk over zich heen.

## 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](https://nuts-foundation.slack.com/archives/C02GJMAE7TL). 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](https://nuts-foundation.slack.com/archives/C0909GUSE0P) 

## 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](https://github.com/nuts-foundation/nuts-knooppunt/issues/528))
2. In kaart brengen hosting providers (zie [GitHub issue](https://github.com/nuts-foundation/nuts-knooppunt/issues/537))
3. Keuze maken en voorleggen aan Kring Techniek ter goedkeuring