Een declaratiemedewerker in de zorg herkent het patroon. Het bestand gaat de deur uit en twee weken later komt het retour met afkeuren die per regel moeten worden uitgezocht. Het merendeel daarvan was thuis al zichtbaar geweest: een ontbrekende AGB-code, een prestatie die buiten de contractperiode valt, een cliënt die per 1 januari is gewisseld van verzekeraar terwijl de regel nog onder de oude polis staat.
De vraag is dus niet hoe je een declaratie maakt, maar hoe je hem controleert voordat hij bij de verzekeraar ligt. Dat is een ander onderwerp dan declaraties vanaf een foto of bon, waar Declaraties in de zorg automatisch verwerken met AI over gaat. Hier draait het om declaraties van zorgprestaties: wat er in het dossier is vastgelegd en wat er met dat gegeven gebeurt voordat het de deur uit gaat.
De declaratiemodule is nooit de bron
De prestatie, de duur, de uitvoerende zorgverlener en de cliënt komen uit het EPD of het ECD. De declaratie is daar een afgeleide van, geen zelfstandig document. Wie die volgorde omdraait, automatiseert de fout mee.
Voor een complete regel heb je in ieder geval het verzekerdennummer en de geboortedatum van de cliënt nodig, de AGB-code van de uitvoerende zorgverlener en van de instelling, de prestatiecode met aanvang en einde, het aantal eenheden, het tarief of de contractprijs, en bij prestaties die een verwijzing vereisen de verwijzende partij. Ontbreekt een van die velden, dan is de rest van de controle verspilde moeite.
Een onderscheid bij het inrichten scheelt later veel discussie. Het uitlezen van een prestatieoverzicht of een PDF-specificatie is documentwerk. Het vergelijken van die gegevens met een referentietabel is gewone software met regels. AI is niet voor elke stap nodig, en een leverancier die dat wel suggereert maakt de inrichting onnodig duur en lastiger te auditen.
Neem het eigen risico
Deze controle ontbreekt het vaakst en kost het vaakst geld. Een declaratie die te hoog wordt ingediend omdat het eigen risico van de cliënt in dat jaar nog niet is verrekend, komt terug als afkeur of, vervelender, als navordering achteraf. De informatie staat meestal wel ergens in het systeem, alleen niet op de plek waar de declaratie wordt samengesteld.
Drie controles wil je zonder uitzondering vooraf doen. Volledigheid, dus of alle verplichte velden gevuld zijn. Geldigheid, dus of de prestatiecode en de AGB-code op de uitvoerdatum bestonden en of de zorgverlener in die periode bevoegd was. En dubbelen, dus of dezelfde combinatie van cliënt, prestatie en periode al eerder is ingediend.
De vierde laag is de contractkant: is de cliënt op de uitvoerdatum verzekerd bij deze verzekeraar, is de prestatie gecontracteerd, is er een machtiging nodig en welke vergoeding hoort erbij. Die regels verschillen per verzekeraar en per contractjaar. Het is geen code die je eenmalig schrijft, het is een lijst die iemand eigenaar moet geven. Zet die lijst als losse tabel neer met een ingangsdatum per regel, niet als vertakkingen in de workflow: bij een contractwijziging pas je dan een rij aan in plaats van een proces. Zonder eigenaar veroudert de lijst stil en keurt het systeem op den duur de verkeerde dingen goed.
De jaargrens is waar het misgaat
Een cliënt wisselt per 1 januari van verzekeraar en de prestatie loopt van half december tot half januari. De controle moet die regel splitsen en per datum de juiste verzekeraar gebruiken. Gebeurt dat niet, dan gaat de declaratie naar de oude verzekeraar en volgt een afkeur die je pas ziet als het retourbericht binnenkomt.
Hetzelfde patroon zie je bij waarnemers. Een waarnemend arts of therapeut declareert onder een andere AGB-code dan de vaste kracht. Klopt de koppeling naar de juiste persoon niet, dan is de declaratie technisch compleet en inhoudelijk fout. De detectie is hier het minste werk; het gaat mis bij het bepalen wie de uitzondering oplost.
Een uitzondering die in een algemene queue belandt zonder eigenaar, wordt niet opgelost door de workflow die hem netjes heeft vastgelegd. Wijs per uitzonderingstype een rol aan, met een termijn eraan, en zorg dat de melding de context meeneemt: cliënt, prestatie, welke regel is geraakt en wat er volgens het systeem ontbreekt.
Wat je vastlegt als iemand akkoord geeft
Bij elke fiattering horen vier dingen in het log: wie het deed, wanneer, welke versie van de regelverzameling gold en welke gegevens op dat moment zijn getoond. Zonder die laatste twee kun je later niet uitleggen waarom een declaratie is goedgekeurd, en dat is precies de vraag die bij een controle of geschil terugkomt.
Op privacygebied is de inrichting niet ingewikkeld, maar wel streng. Gezondheidsgegevens vragen om een verwerkersovereenkomst en een grondslag voordat je iets bouwt. Beperk de toegang tot de medewerkers die de declaratie echt behandelen, houd de verwerking binnen de EU en gebruik voor het uitlezen van documenten bij voorkeur een model dat lokaal of in een eigen omgeving draait. Wat je niet nodig hebt, sla je niet op. Een declaratie hoeft zelden de volledige dossierinhoud te bevatten.
Hoe je zo'n spoor inricht staat in Audit trail voor AI-automatisering. Wil je eerst bepalen waar dit binnen de bredere administratie hoort, dan geeft Zorgprocessen automatiseren met AI het overzicht.
Meet afkeur, niet doorvoer
De verleiding is om te rapporteren hoeveel regels er automatisch doorheen gingen. Dat getal zegt weinig over de kwaliteit van je declaraties. Meet het afkeurpercentage per verzekeraar, de tijd die herstelwerk per declaratie kost, de doorlooptijd van prestatie tot indiening en het aantal afkeuren dat je pas na het retourbericht zag. Die laatste is de echte indicator: alles wat daar opduikt, had je vooraf kunnen weten.
Voor het inlezen van prestatieoverzichten en specificaties kun je terecht bij documentverwerking. Loopt de controle over meerdere systemen en teams, dan is werkstroom-orchestratie de laag die het geheel aanstuurt. Meer over automatisering in deze sector staat op de branchepagina AI-automatisering voor de zorg.
Veelgestelde vragen
Moet ik mijn declaratiesoftware vervangen?
Nee, in de meeste opstellingen niet. De controlelaag zet de gecontroleerde declaratie klaar en de bestaande software verstuurt hem. Alleen als dat pakket geen import of API heeft, wordt het een exportbestand met een handmatige stap ertussen. Dat is een beperking van je software, niet van de automatisering.
Wat kost geautomatiseerde declaratieverwerking?
De techniek is zelden de grootste post. Het uitzoeken, documenteren en eigenaar geven van de regelverzameling kost meer tijd, en die kosten lopen door zolang contracten wijzigen. Reken op doorlopend beheer van enkele uren per maand, niet op een eenmalige bouw die daarna klaar is.
Mag een model beslissen of een declaratie wordt ingediend?
Laat dat niet gebeuren. Een model kan signaleren dat een regel afwijkt, maar de indiening hoort een expliciete handeling van een medewerker te zijn die het dossier kan inzien. Leg dat in de inrichting vast als harde stap, ook als het overgrote deel van de regels zonder opmerking doorkomt.
Wat gebeurt er als een verzekeraar halverwege het jaar de voorwaarden aanpast?
Dan moet je met versies werken. Elke regel krijgt een ingangsdatum, en een declaratie wordt getoetst tegen de versie die op de uitvoerdatum gold. Zonder dat mechanisme keur je oude prestaties onterecht af zodra het nieuwe contract ingaat.
Werkt dit ook voor WLZ-declaraties?
De controlelogica is dezelfde, de referentiedata niet. Bij de Wet langdurige zorg loopt de declaratie via het zorgkantoor en gelden andere prestatiecodes dan in de Zorgverzekeringswet. Je bouwt dezelfde controle, maar met een aparte tabel en een apart indieningskanaal.