De wijziging van de AWBZ rond 2013 was een grote operatie waarbij grote groepen mensen uit een bepaalde vorm van langdurige zorg stroomden naar andere regelingen. Voor zorgverzekeraars betekende dat een ongekende behoefte aan inzicht: wie gaat waar naartoe, wat zijn de financiële en zorginhoudelijke gevolgen, en hoe zorg je dat individuele cliënten niet tussen wal en schip belanden?
Voor zorgverzekeraars heb ik in een team gewerkt aan een applicatie die juist dat inzicht moest leveren. Mijn specifieke verantwoordelijkheid was het ontwerpen en implementeren van het algoritme dat per cliënt bepaalt waar die naartoe gaat — op basis van een gedetailleerde set regels en de actuele cliëntgegevens.
Een algoritme als dit is technisch geen rocket science, maar de complexiteit zit in het feit dat ieder detail telt. Een verkeerde aanname over een leeftijdscategorie of een ontbrekende uitzondering kan tientallen mensen in de verkeerde regeling laten belanden. Dat is niet acceptabel — niet voor de verzekeraar, maar bovenal niet voor de cliënt.
We hebben het algoritme daarom expliciet en goed leesbaar gehouden, dichtbij de regels zoals beleidsmakers ze formuleren. Geen smart shortcuts, geen impliciete aannames; iedere regel was traceerbaar tot zijn bron. Dat maakt het algoritme niet flitsend, maar wel toetsbaar — en juist dat was hier essentieel.
Daarbij hebben we sterk geïnvesteerd in tests en in datasets met realistische randgevallen. We werkten met Java 7 op Spring en Tomcat, en gebruikten OpenCSV voor de data-uitwisseling. Geen exotische stack, maar precies de combinatie die we nodig hadden: stabiel, voorspelbaar en goed toegerust voor stevige batchverwerking met aantoonbare correctheid.
Voor mij was dit project een vroege en duidelijke les dat 'simpele' regelapplicaties in de zorg of overheid een hele eigen vorm van complexiteit hebben. De code is zelden de bottleneck — de bottleneck is begrijpen wat de regels écht betekenen, en die helder en betrouwbaar in code vatten zonder onderweg betekenis te verliezen.