Zorgdeclaraties met AI controleren: van consultregistratie naar controleerbaar bewijs

Je hebt een consultregistratie die er netjes uitziet, maar dat is nog geen declaratiebewijs. Zodra een AI-systeem zelf een prestatiecode kiest en de declaratie doorzet, verschuift de fout van een verkeerd woord in het dossier naar geld, controleerbaarheid en mogelijk een retourbericht. De veilige route is daarom niet: laat AI declareren. De route is: laat AI een onderbouwd voorstel maken, toets dat voorstel aan de juiste regelversie en geef pas vrij na een menselijke controle en een read-back.

Controleerbare declaratiecontrole is een werkstroom waarin een consultregistratie wordt vertaald naar een voorgestelde zorgprestatie, met bronpassages, een vastgelegde regelversie, bevoegdheidscontrole, verplichte velden en een menselijke vrijgave. Na verzending controleert de werkstroom ook de retourstatus en vergelijkt hij de ontvangen declaratie met het vrijgegeven voorstel.

De stap vóór deze gids blijft belangrijk. Een AI-scribe moet eerst een gecontroleerd dossier opleveren, zoals bij consultregistratie naar een gestructureerd dossier. Deze gids begint waar dat dossier ophoudt: bij de vraag of de vastgelegde zorg ook aantoonbaar als de gekozen prestatie mag worden gedeclareerd.

Wat je nodig hebt

Begin klein. Kies één zorgsector, één soort consult en één declaratiebestemming. In het voorbeeld verderop is dat fysiotherapie in 2026. De technische vorm kun je later naar huisartsenzorg, ggz, logopedie of wijkverpleging vertalen, maar de prestatiecodes, voorwaarden, standaarden en bevoegdheden moet je per sector opnieuw vastleggen.

Je hebt deze bouwstenen nodig:

• Een bronvaste consultregistratie. Bewaar naast de uiteindelijke tekst ook welke passage de datum, duur, behandelaar, zorgvorm, verwijzing, locatie, patiëntrelatie en bijzondere omstandigheid ondersteunt. De bron kan een gecontroleerd SOEP-verslag zijn, een gestructureerd EPD-veld of een combinatie daarvan.
• Een regelregister met versies. Neem per sector de bron, het kenmerk, de ingangsdatum, de einddatum, de prestatiebeschrijving, voorwaarden, uitzonderingen en een inhoudelijke eigenaar op. Voor fysiotherapie zijn voor 2026 bijvoorbeeld de Regeling paramedische zorg NR/REG-2620, de Beleidsregel prestatiebeschrijvingen voor fysiotherapie BR/REG-26100 en de Prestatiebeschrijvingbeschikking fysiotherapie TB/REG-26600-01 relevant. De NZa publiceert de sectorspecifieke documenten bij elkaar en maakt duidelijk dat de regels per jaar wijzigen. De 2026-pagina van de NZa koppelt de regeling, beleidsregels en prestatiebeschikkingen per paramedische sector.
• Een bronregister voor bevoegdheid. Leg vast welke zorgaanbieder declareert, welke behandelaar de zorg leverde, welke AGB-code bij de declaratie hoort en welke kwalificatie of erkenning de prestatie ondersteunt. Een AGB-code is een identificerende sleutel, geen bewijs dat iedere medewerker iedere prestatie mag uitvoeren.
• Een declaratiebestemming. Dat kan een module in je EPD of HIS zijn, een leverancierskoppeling, een financieel systeem of Vecozo. Noteer welke landelijke standaard, versie, certificaat- of toestemmingsroute en retourberichten gelden. Een workflow die alleen een bestand kan maken, maar niet weet wat een technische afwijzing betekent, is nog niet klaar.
• Een staginglaag. Bewaar hier het voorstel, de gebruikte bronnen, de regelversie, de huidige recordversie, de reviewer, de beslissing, de payload-hash en de tijdstippen. Staging is geen extra administratie. Het is de plek waar je voorkomt dat een modeluitvoer meteen een financieel feit wordt.
• Een menselijke vrijgever. De reviewer moet de consultregistratie, bronpassages, regelvoorwaarden, voorgestelde prestatie en exacte declaratiepayload naast elkaar kunnen zien. De behandelaar kan inhoudelijk beslissen; de administratief verantwoordelijke kan de technische volledigheid controleren. Spreek af wie welke beslissing mag nemen.
• Een herstelpad. Je hebt een uitzonderingsqueue nodig voor ontbrekende bron, regelconflict, ontbrekende bevoegdheid, gewijzigde patiëntgegevens, twijfel over de prestatie en retourinformatie. Voeg ook een manier toe om een voorstel te annuleren of te crediteren volgens de procedure van je declaratiesysteem.
• Een meetset. Meet minstens het aandeel voorstellen dat naar menselijke review gaat, de reden van iedere uitzondering, de tijd tot vrijgave, de technische afwijzingsratio, dubbele inzendingen en de tijd tot herstel. Een laag reviewpercentage is geen doel op zichzelf. Een laag aandeel fouten en een goed verklaarbare route zijn dat wel.

Voor de eerste proef heb je geen eigen taalmodel nodig. Een EPD-module kan de bronregistratie en declaratie al dicht bij elkaar houden. Voor de werkstroom eromheen kun je n8n gebruiken, mits je de verwerking van gezondheidsgegevens technisch en organisatorisch goed inricht. n8n documenteert expliciete menselijke goedkeuring voor gevoelige gereedschappen zoals records wijzigen, en noemt daarvoor onder meer Chat en Slack als kanaal. De goedkeuring moet wel in jouw staginglaag worden vastgelegd, met reviewer en tijdstip. De n8n-documentatie beschrijft dat de workflow pauzeert en pas na goedkeuring een gekoppeld gereedschap uitvoert.

De kernvoorwaarde is eenvoudig: als je een voorstel niet kunt terugbrengen naar een passage, een regelversie en een bevoegde zorgaanbieder, mag het niet automatisch verder.

Concrete stappen: van consultregistratie naar vrijgegeven declaratie

Met controleerbare declaratiecontrole ga je van een bronvast consult naar een gevalideerde declaratiepayload met verplichte velden, contracttarief, menselijke vrijgave en read-back. Je ziet per stap welke gegevens een regel ondersteunen, wanneer de workflow blokkeert en wat de ontvanger na verzending terugstuurt.

Volg deze stappen:

Stap 1. Bevries de scope en de regelversie

Schrijf eerst op wat je wel en niet automatiseert. Een goede eerste scope is bijvoorbeeld: individuele fysiotherapiezittingen uit gecontroleerde consultregistraties voorstellen, controleren op bron en bevoegdheid, en klaarzetten voor vrijgave. Zet lange zittingen, groepsbehandelingen, toeslagen, buitenlandse verzekerden, correcties en ontbrekende verwijzingen aanvankelijk op menselijke beoordeling.

Koppel ieder voorstel aan een rule_set_id, bijvoorbeeld fysio-2026-v1, met de drie NZa-documentkenmerken en hun geldigheidsperiode. Gebruik nooit alleen de tekst “NZa 2026”. Een regelregister moet na een wijziging kunnen uitleggen welke versie op 22 oktober 2026 is gebruikt en waarom een voorstel van 31 december 2026 niet dezelfde logica hoeft te volgen.

De NZa maakt voor paramedische zorg duidelijk dat zij de prestaties vaststelt, terwijl de prijzen in die sector vrij zijn en zorgaanbieders en verzekeraars daarover onderhandelen. Laat je workflow dus niet zelf een prijs afleiden uit een algemene tabel als de contractprijs of polisvoorwaarde in een ander systeem staat. De NZa beschrijft het onderscheid tussen prestaties en vrije prijzen op de pagina over registreren en declareren.

Controle na deze stap: je kunt één testdatum invoeren en een machineleesbare lijst terugkrijgen met de geldige regelversie, prestaties en voorwaarden. Ontbreekt die lijst, dan is je proces nog te afhankelijk van een prompt of de kennis van één medewerker.

Stap 2. Maak de consultregistratie geschikt als bewijs

Een samenvatting als “behandeling uitgevoerd, patiënt reageerde goed” helpt een behandelaar, maar draagt geen volledige declaratiecontrole. Maak voor ieder consult één bewijs- en declaratierecord. Art. 5.1 van NR/REG-2620 verlangt op patiëntniveau de patiëntgegevens, geleverde prestatie, eenheden, tarief en totaalbedrag, leverdatum, declaratiecode en AGB van de declarerende zorgaanbieder. Verzekeringsgegevens zijn aanvullend nodig om de juiste ontvanger, polisroute en contractprijs te valideren.

Leg deze velden afzonderlijk vast:

• patient: patient_id, naam, geboortedatum, adres, postcode en woonplaats. Het interne patiënt-ID is een koppeling, geen vervanging voor de patiëntgegevens die op de declaratie horen.
• insurance: verzekeraar, polisnummer, UZOVI- of ontvangerroute, dekkingstype en verified_at. Controleer dat de polis actief is op de behandeldatum en bij de gekozen declaratiebestemming past.
• performance: de prestatieomschrijving, de NZa-prestatieletter of -code en de declaratiecode. Controleer de combinatie tegen de geldige prestatiebeschrijving en de mapping van de gekozen verzekeringsroute.
• units: het aantal geleverde eenheden per prestatie. Dit is een positief getal dat overeenkomt met de geregistreerde zorg, niet een standaardwaarde die het model invult.
• treated_on: de behandeldatum of -data. Controleer die tegen de bronregistratie, de geldigheid van de regelset en eventuele contractperiode.
• tariff_eur en total_eur: het contracttarief per eenheid en het totaalbedrag. Haal het tarief uit het geldige contract of de polisroute en controleer total_eur = units × tariff_eur; de NZa stelt voor paramedische zorg geen vast tarief vast.
• declaring_agb: de AGB-code van de zorgaanbieder die declareert. Controleer de code tegen het actuele AGB-register en het juiste aggregatieniveau. Bewaar performer_agb en de werkrelatie apart.
• evidence en rule_set_id: de bronpassage per beslissende voorwaarde en de regelversie die op de behandeldatum gold.

Valideer dus zowel aanwezigheid als samenhang. Een bestaande tariff_eur is niet genoeg als het contract voor deze verzekeraar of datum verlopen is. Een bestaande declaratiecode is niet genoeg als die niet bij de prestatie en de bestemming hoort. Ontbreekt één veld, bronpassage, actuele AGB-relatie of contracttarief, dan wordt het voorstel blocked en gaat het naar de uitzonderingsqueue.

Laat een taalmodel ontbrekende feiten niet invullen. Geef het model een uitkomst zoals onvoldoende_bron en stuur die naar de uitzonderingsqueue. De AI-outputcontrole vóór verzending of publicatie werkt met dezelfde basis: een tweede modelmening is geen bewijs, een bronpassage en een controle wel.

Maak onderscheid tussen een feit en een interpretatie. “De patiënt heeft MS” kan uit een gecontroleerd dossier komen. “Daarom is een lange zitting toegestaan” is een conclusie die je nog aan de actuele prestatievoorwaarden moet toetsen. Bewaar beide apart, zodat een reviewer ziet waar de grens ligt.

Controle na deze stap: laat vijf normale consulten, één ontbrekende bron en één tegenstrijdig consult door de bewijslaag. De ontbrekende en tegenstrijdige gevallen moeten stoppen voordat er een prestatiecode wordt voorgesteld.

Stap 3. Match eerst deterministisch, gebruik AI voor het moeilijke werk

Begin met harde regels. Filter op zorgsector, datum, consultvorm, behandelaar, locatie, verzekeringsroute en eventuele verwijzing. Gebruik pas daarna AI om vrije tekst aan een beperkt aantal kandidaten te koppelen of om ontbrekende informatie te markeren.

Een voorstel heeft bijvoorbeeld deze velden:

Voor fysiotherapie is dit onderscheid concreet. De beleidsregel noemt onder meer individuele zittingen, lange zittingen, groepszittingen en toeslagen. Een lange zitting is bedoeld voor complexe of meervoudige zorgvragen waarbij de behandeling niet in een individuele zitting kan worden uitgevoerd. Een groepszitting heeft eigen voorwaarden, en een individuele zitting mag niet alsnog worden gedeclareerd als onderdeel van die groepszitting. De geldige fysiotherapiebeleidsregel voor 2026 benoemt deze prestaties en voorwaarden.

De NZa gebruikt in de beleidsregel de prestatieletter m; de concrete declaratiecode komt uit de declaratie- of verzekeringsroute. In dit voorbeeld is 1700 de vastgelegde fysiotherapiemapping voor de testroute. VGZ noemt voor een lange zitting de codes 1700, 1701 en 1702; welke code jouw route vereist, leg je contractueel vast. Controleer die mapping altijd tegen je actuele route en contract. Een onbekende of niet-passende code blokkeert de payload.

Laat het model dus niet vragen: “Welke code lijkt op deze tekst?” Laat het beslissen tussen een kleine set kandidaten en teruggeven welke voorwaarden het wel en niet kan bewijzen. Bij twee passende kandidaten is menselijke_review de juiste uitkomst, ook als de modelscore hoog is.

Controle na deze stap: maak een testset met normale zittingen, groepszittingen, toeslagen, een consult zonder verwijzing en een oud consult uit 2025. Elk geval krijgt een verwachte route: voorstel, uitzondering of geen declaratie.

Stap 4. Controleer bevoegdheid en AGB op het juiste niveau

Gebruik voor de bevoegdheidscontrole niet de naam die in de consulttekst staat. Raadpleeg een actuele bron. Vektis beheert het AGB-register met informatie voor declareren en contracteren in opdracht van zorgverzekeraars. AGB-registraties bevatten kwalificaties en erkenningen. De erkenning komt uit een bronregister, zoals het BIG-register voor fysiotherapeuten. Vektis legt uit hoe erkenningen de bevoegdheid van een zorgaanbieder vastleggen.

Bewaar drie zaken los van elkaar:

1. de AGB-code van de organisatie of persoon die de prestatie declareert;
2. de AGB-code en werkrelatie van de behandelaar die de zorg uitvoerde;
3. de erkenning of kwalificatie waarop je prestatievoorwaarden steunen.

De NZa-regeling voor paramedische zorg schrijft voor dat bij iedere declaratie een AGB-code wordt vermeld. De regeling maakt daarbij onderscheid tussen codes op verschillende niveaus en legt voor de declaratie de nadruk op het hoogste aggregatieniveau van de zorgaanbieder die de prestaties declareert. Dezelfde regeling verlangt volledige, juiste en actuele registratie en een administratie waarmee een audit trail mogelijk is. Die voorschriften staan in NR/REG-2620, die vanaf 1 januari 2026 geldt.

Controle na deze stap: maak een test met een behandelaar die wel in het EPD staat, maar van wie de AGB-werkrelatie is verlopen. Het resultaat moet blokkeren. Een eerder geldige koppeling is geen actuele bevoegdheid.

Stap 5. Bouw de menselijke vrijgave rond verschillen

Een reviewer hoeft niet ieder voorspelbaar voorstel opnieuw te schrijven. Hij moet wel gericht kunnen beslissen over de punten waar de declaratie kan breken. Toon daarom in één reviewkaart:

• het gecontroleerde consult en de bronpassages;
• de voorgestelde prestatie en de voorwaarden die zijn afgevinkt;
• de gebruikte regelversie en geldigheid;
• declarerende organisatie, behandelaar, AGB en kwalificatie;
• het verschil tussen huidige dossierdata en de data in het voorstel;
• de volledige payload die naar de declaratiemodule gaat;
• de gevolgen van goedkeuren, afwijzen of terugzetten naar de uitzonderingsqueue.

Gebruik vaste beslisuitkomsten: approved, rejected, needs_more_evidence en expired. Laat goedkeuren geen algemene toestemming zijn voor toekomstige declaraties. De beslissing hoort bij één proposal_id en één payload-hash.

In n8n kun je een gereedschap dat records wijzigt achter menselijke review hangen. De workflow pauzeert dan vóór uitvoering, waarna goedkeuren het gereedschap uitvoert en afwijzen de actie annuleert. Gebruik zo’n functie als bedieningslaag, maar bewaar het formele besluit, de reviewer en de payload in je eigen stagingrecord. Bij self-hosting blijf je zelf verantwoordelijk voor TLS, versleuteling, gebruikersbeheer en het verwijderen van uitvoeringsdata. n8n noemt die maatregelen expliciet in zijn privacydocumentatie. De self-hosted beveiligingsinstructies van n8n leggen die verantwoordelijkheid bij de klant.

Stap 6. Verzend pas na een laatste server-side controle

De vrijgave-executor leest het voorstel opnieuw. Hij controleert, in deze volgorde:

1. de status is wacht_op_goedkeuring;
2. de regelversie is nog geldig voor de behandeldatum;
3. alle verplichte bronpassages zijn aanwezig;
4. de AGB- en bevoegdheidsgegevens zijn nog actueel;
5. het dossier of de consultregistratie niet is gewijzigd sinds de review;
6. de payload-hash gelijk is aan wat de reviewer zag;
7. alleen toegestane velden in de payload staan;
8. er nog geen eerdere verzending met dezelfde idempotency key bestaat.

Een taalmodel mag helpen bij het vullen van een gestructureerd voorstel. Deze laatste controle hoort in gewone programmaregels of een declaratiemodule te staan. Zo blijft de grens bestaan als een prompt, modelversie of medewerker verandert.

Stap 7. Lees de retourstatus terug en sluit het dossier af

Verzenden is niet hetzelfde als accepteren. Vecozo voert bij het indienen een ontvangstcontrole uit op autorisatie, leesbaarheid, bestandstype, versie en bestandsgrootte. Na de knop voor direct indienen volgt een tweede controle voordat het bericht wordt doorgestuurd. De status kan daarna onder meer Aangeboden, Bezorgd of Afgekeurd door dienst zijn, met foutcode en melding. De actuele Vecozo-instructie beschrijft deze twee controles en het opnieuw indienen na herstel.

Sla bij iedere verzending op:

• submission_id en de idempotency key;
• timestamp, verzendroute en afzender-AGB;
• hash van de vrijgegeven payload;
• ontvangst- en retourbericht;
• foutcode, reden en verantwoordelijke voor herstel;
• moment waarop de declaratie opnieuw is aangeboden of gecrediteerd.

Vergelijk daarna de read-back met het vrijgegeven voorstel. Komt een andere prestatie, datum, verzekeraar of hoeveelheid terug, dan markeer je het voorstel als verschil en laat je het niet stilzwijgend als geslaagd staan. Bij dubbele inzending neem je contact op met de ontvanger en start je de correctieroute. De declaratie is pas afgerond als de technische status en de inhoudelijke uitkomst bekend zijn.

Valkuilen: waar de automatisering in de praktijk breekt

De AI kiest op herkenning in plaats van op voorwaarden. Een consult met “langdurige behandeling” lijkt op een lange zitting, maar dat is geen bewijs. Leg de voorwaarden in regels vast en laat het model alleen kandidaatprestaties voorstellen. Ontbrekende voorwaarden leiden tot menselijke review.

De regelversie staat alleen in een prompt. Prompts zijn geen versiebeheer. Sla de bronkenmerken, geldigheidsperiode en gebruikte passages op in een regelregister. Plan een controle vóór ieder nieuw declaratiejaar en na iedere wijziging van de NZa-regel of het contract.

AGB wordt als één vrij tekstveld behandeld. Een naam of praktijkcode kan technisch geldig lijken, terwijl de behandelaar, werkrelatie of erkenning niet klopt. Splits declarerende partij, uitvoerende behandelaar en kwalificatie, en controleer elk onderdeel.

Een goedgekeurd consult wordt als goedgekeurde declaratie gezien. De inhoudelijke controle van het dossier zegt nog niets over de juiste declaratiestandaard, versie, verzekeraar of technische ontvanger. Voeg een technische validatie toe en bewaar het retourbericht.

De reviewer ziet alleen het modelantwoord. Zonder bronpassage, regelversie en payload kan niemand gericht controleren. Toon het verschil tussen oud en nieuw en laat de reviewer één beslissing nemen over één voorstel.

Een wijziging tussen review en verzending wordt genegeerd. Een patiëntrecord of behandelregistratie kan intussen veranderen. Vergelijk een bronversie of last_modified_at vóór verzending. Bij verschil gaat het voorstel terug naar review.

Een chatbericht is de audit trail. Een goedkeuring in Slack is een signaal, geen compleet declaratiebewijs. Sla de beslissing op met reviewer, tijdstip, voorstel-ID, payload-hash en regelversie. Het kanaal mag de reviewer helpen, maar moet niet de enige opslag zijn.

Een generieke AI-dienst krijgt ruwe gezondheidsgegevens. De AP zegt dat je ook bij een pilot of proefproject eerst moet vaststellen of je aan de AVG kunt voldoen en privacyrisico’s moet beperken. De AP-pagina over AI en de AVG is bijgewerkt op 18 december 2024 en gecontroleerd op 23 oktober 2026. De AP benadrukt dat de AVG techniekneutraal ook geldt bij algoritmes en AI met persoonsgegevens. Gebruik een verwerkersovereenkomst, beperkte gegevens, passende toegang en een DPIA waar nodig. Self-hosting lost je zorgplicht niet vanzelf op.

Een technische bezorging wordt als inhoudelijke vergoeding gezien. Bezorgd betekent dat het bericht bij de ontvanger is afgeleverd. Het betekent niet dat de verzekeraar de prestatie inhoudelijk heeft vergoed. Houd technische status, inhoudelijke retourinformatie en financiële verwerking als drie verschillende statussen bij.

Beslis-kader: kant-en-klaar, orkestratie of maatwerk?

Kies niet eerst een model. Kies eerst waar je controle moet wonen. Voor één zorgsector met een stabiele standaardprestatie is de native module van je EPD meestal de beste start. Je koopt dan vooral een onderhouden declaratiepad. Zodra je meerdere bronnen, uitzonderingen, EPD’s of eigen bewijsvoering moet verbinden, heb je een orkestratielaag of maatwerk nodig.

Gebruik deze criteria:

• Kant-en-klaar in het EPD: kies dit bij één EPD, één of twee zorgsectoren, stabiele consultvelden en een leverancier die regelupdates, audit trail, retourverwerking en menselijke vrijgave aantoonbaar ondersteunt. Vraag in de demo om een verlopen AGB-relatie, een dubbele verzending en de normale happy path.
• Orkestratie met n8n: kies dit als je EPD of HIS een bruikbare API of export heeft en je een aparte bron-, regel-, review- en retourlaag wilt. n8n kan HTTP, databases en AI-gereedschappen combineren en heeft een menselijke goedkeuringspoort. Self-hosting vraagt wel eigen beheer van beveiliging, logs, retentie en updates.
• Maatwerk: kies dit bij meerdere EPD’s, sectoroverschrijdende regels, een verplichte bewijsstructuur, hoge foutkosten, een eigen declaratieportaal of een bestaand systeem zonder passende API. Bouw de regelengine en read-back als aparte onderdelen, zodat een modelwissel niet je hele declaratieproces verandert.

Mijn praktische drempel: als je alleen een gecontroleerde consultregistratie naar een bestaande EPD-functie wilt brengen, begin kant-en-klaar. Als je drie of meer van deze zaken nodig hebt, wordt maatwerk snel verdedigbaar: meerdere regelsets, meerdere bronnen, meerdere declaratiebestemmingen, bewijs per voorwaarde, uitzonderingsrouting met rollen, of een gegarandeerde read-back met herstel.

Prijzen en versies hieronder zijn gecontroleerd op 23 oktober 2026. Het bedrag voor n8n is alleen de workflowlaag. Daar komen hosting, modelgebruik, koppelingen, logging en zorgspecifieke inrichting bij. Azure Document Intelligence is een documentuitleeslaag, geen NZa-regelengine.

De n8n-prijzen en het aantal workflowuitvoeringen komen uit de actuele prijspagina, waar ook staat dat de prijs niet per stap of gebruiker wordt berekend. n8n vermeldt €20 voor Starter, €50 voor Pro en €667 voor Business bij jaarbetaling. Voor documentuitlezing is Azure Document Intelligence 4.0 op dit moment GA; Microsoft verwijst voor de raming naar het aantal verwerkte pagina’s, model, regio en de prijscalculator. De Microsoft-documentatie beschrijft zowel de actuele v4.0-status als de stappen voor kostenraming.

Let op het verschil tussen een goede demo en een controleerbaar proces. Een leverancier die een consult naar een mooie tekst omzet, heeft nog niet bewezen dat hij een geldige prestatie kiest. Vraag altijd om de bronpassage, de toegepaste regelversie, de AGB-controle, de afhandeling van een uitzondering en de read-back van een afgekeurde declaratie.

Uitgewerkt voorbeeld: een fysiotherapiesessie met bronbewijs

Dit is een fictief rekenvoorbeeld om de keten zichtbaar te maken. De regelverwijzingen zijn echt en gelden voor de gekozen 2026-context; de praktijk, patiënt en aantallen zijn illustratief. Ook 1700, de AGB-codes en het contracttarief van €68,00 zijn synthetische testwaarden: het tarief is geen NZa-tarief, maar een voorbeeld uit een fictieve contractmapping.

Fysiopraktijk Rivier werkt met een EPD dat na consultcontrole een gestructureerd verslag kan exporteren. De praktijk heeft op 22 oktober 2026 één sessie van patiënt P-042 geregistreerd bij behandelaar B-17. Het consult was één-op-één. In de gecontroleerde registratie staan de aandoening MS, de behandeldoelen, de behandeling en de passage dat de zorgvraag door combinatie van klachten niet binnen een gewone individuele zitting kon worden uitgevoerd. De behandelaar heeft het verslag al vrijgegeven.

1. De bronlaag maakt de feiten los van de conclusie.

De workflow haalt vier bewijsstukken op:

• de gecontroleerde behandeldatum en de behandelaar;
• de passage over MS en de meervoudige zorgvraag;
• de passage over de feitelijke behandeling en één-op-één contact;
• de praktijk- en behandelaarreferentie met actuele AGB-gegevens.

De AI mag op basis hiervan lange zitting als kandidaat voorstellen. Hij mag niet schrijven dat de kandidaat zeker is omdat de tekst “complex” klinkt. De regeltoets moet de diagnose, de complexe of meervoudige zorgvraag en de onmogelijkheid van een gewone individuele zitting afzonderlijk kunnen aanwijzen.

2. De regelengine toetst de kandidaat.

De datum valt in de geldigheid van BR/REG-26100 en TB/REG-26600-01. De beleidsregel noemt MS bij de specifieke aandoeningen voor de prestatie lange zitting. Hij vraagt ook dat de aandoening en situatie maken dat de behandeling niet in een individuele zitting kan worden uitgevoerd. De engine zet daarom twee vinkjes op groen en één inhoudelijke vraag op geel: staat de onmogelijkheid voldoende duidelijk in de bron, of moet de behandelaar dat expliciet bevestigen?

De engine controleert tegelijk dat het geen groepszitting was en dat geen toeslag wordt toegevoegd zonder de bijbehorende prestatie. Er wordt geen tarief door de AI berekend. De praktijkprijs komt uit het contract en de declaratie-inrichting, terwijl de prestatievoorwaarden uit de regelset komen.

3. De bevoegdheidslaag controleert wie declareert.

De praktijk-AGB wordt gebruikt als declarerende AGB op het niveau dat de regeling verlangt. De behandelaar wordt apart gecontroleerd op actuele werkrelatie en kwalificatie. Bij een verlopen erkenning gaat het voorstel naar de uitzonderingsqueue, ook als de consultregistratie inhoudelijk klopt.

4. De staginglaag maakt de declaratievelden expliciet.

De workflow zet na de regel- en bevoegdheidscontrole een concrete, nog niet verzonden payload klaar. De waarden hieronder zijn synthetisch, zodat je ziet welke gegevens de server-side controle moet lezen:

{
  "proposal_id": "prop-2026-10-22-0042",
  "patient": {
    "patient_id": "P-042",
    "name": "Testpatiënt 042",
    "date_of_birth": "1978-04-12",
    "address": "Teststraat 1",
    "postal_code": "1234 AB",
    "city": "Utrecht"
  },
  "insurance": {
    "insurer": "VGZ",
    "policy_number": "TEST-042-2026",
    "route": "verzekeraar",
    "verified_on": "2026-10-22"
  },
  "treated_on": "2026-10-22",
  "performance": {
    "name": "Lange zitting",
    "nza_prestatie": "m",
    "declaratiecode": "1700",
    "units": 1
  },
  "tariff_eur": 68.00,
  "total_eur": 68.00,
  "declaring_agb": "12345678",
  "performer_agb": "87654321",
  "rule_set_id": "fysio-2026-v1",
  "contract_id": "FYSIO-2026-VGZ-v3",
  "review_status": "wacht_op_goedkeuring"
}

De release-executor blokkeert vóór verzending als een patiënt- of verzekeringsveld, prestatie, declaratiecode, eenheid, behandeldatum, declarerende AGB, tarief of totaalbedrag ontbreekt. Hij blokkeert ook als 1700 niet aan prestatie m is gekoppeld, als het contracttarief voor de verzekeraar en datum ontbreekt of verlopen is, of als total_eur niet exact units × tariff_eur is. Gebruik hiervoor expliciete statussen zoals blocked_missing_declaration_field en blocked_missing_contract_tariff. null, een geschat bedrag of een menselijke klik is geen geldige vervanging; eerst moet de bron of het contract worden aangevuld en daarna moet een nieuw voorstel worden beoordeeld.

Read-back na verzending:

{
  "submission_id": "sub-2026-10-22-0042",
  "status": "Bezorgd",
  "patient": {
    "patient_id": "P-042",
    "name": "Testpatiënt 042",
    "date_of_birth": "1978-04-12",
    "address": "Teststraat 1",
    "postal_code": "1234 AB",
    "city": "Utrecht"
  },
  "insurance": {
    "insurer": "VGZ",
    "policy_number": "TEST-042-2026",
    "route": "verzekeraar"
  },
  "treated_on": "2026-10-22",
  "performance": {
    "name": "Lange zitting",
    "nza_prestatie": "m",
    "declaratiecode": "1700",
    "units": 1
  },
  "tariff_eur": 68.00,
  "total_eur": 68.00,
  "declaring_agb": "12345678",
  "performer_agb": "87654321",
  "payload_hash": "sha256:TEST-0042"
}

De read-back wordt veld voor veld vergeleken met de vrijgegeven payload. Ontbreekt een veld, wijkt de datum, verzekeraar, prestatie, hoeveelheid, het tarief, totaalbedrag of de declarerende AGB af, of komt alleen een technische status zonder inhoudelijke bevestiging terug, dan wordt het item een verschil en niet geslaagd.

5. De reviewer ziet één verschil dat ertoe doet.

De reviewkaart toont de bronpassages, de regelversie fysio-2026-v1, de kandidaat lange zitting, de AGB-controles en de exacte uitgaande payload. De reviewer bevestigt dat de passage over de complexe zorgvraag voldoende is en kiest approved. De workflow slaat de beslissing, tijd, reviewer en hash op. Als de reviewer vindt dat de bron te vaag is, kiest hij needs_more_evidence en vraagt hij een aanvulling in het dossier, zonder zelf een declaratieveld te overschrijven.

6. De verzending en read-back sluiten aan.

De release-executor controleert opnieuw dat het verslag en de AGB-gegevens niet zijn gewijzigd. De declaratie gaat via de bestaande software- of Vecozo-route. De technische status wordt Aangeboden; later komt de retourinformatie binnen. Het systeem koppelt die informatie aan proposal_id, vergelijkt de prestatie, behandeldatum en afzender-AGB met de payload en markeert het item pas daarna als technisch_bezorgd.

Stel dat een tweede item dezelfde patiënt, datum en prestatie bevat door een dubbele workflowtrigger. De idempotency key voorkomt een tweede verzending. Stel dat de verzekeraar een ontbrekende verwijzing meldt. Dat is geen modelprobleem meer. De workflow zet het item op inhoudelijk_uitval, bewaart de retourcode, wijst een medewerker toe en laat een nieuwe poging alleen toe na een nieuwe menselijke vrijgave.

In dit voorbeeld doet AI dus drie dingen goed: hij vindt kandidaten in vrije tekst, hij verzamelt bronpassages en hij ordent uitzonderingen. De beslissende grens blijft buiten het model: een regelversie, een actuele bevoegdheid, een menselijke vrijgave en een read-back die verschillen zichtbaar maakt.

Een declaratieproces wordt pas betrouwbaar wanneer je achteraf dezelfde vraag opnieuw kunt beantwoorden als de verzekeraar of NZa: welke zorg is geregistreerd, welke bron droeg de prestatie, welke regel gold die dag, wie was bevoegd, wie gaf vrij en wat ontving de ontvanger? Als één van die antwoorden alleen uit het geheugen van een model komt, is de automatisering nog niet af. De winst zit niet in zo min mogelijk menselijke klikken, maar in een keten waarin iedere klik, regel en uitzondering uitlegbaar blijft.