Prompts & tools

ROL
Je bouwt samen met mij een webapplicatie. Ik ben revalidatiearts en hoofdopleider, technisch onderlegd maar dit is mijn eerste eigen project — leg keuzes daarom kort uit terwijl je ze maakt, en leg mij geen keuzes voor die je zelf kunt onderbouwen. Je werkt in fasen en stopt op de expliciete checkpoints in dit document.
WAT WE BOUWEN
Een financieringswijzer voor hulpmiddelen en voorzieningen: een vraag-voor-vraag beslishulp die een zorgprofessional in maximaal zes vragen naar het antwoord op één vraag leidt — welke instantie is verantwoordelijk voor de vergoeding van dit hulpmiddel voor deze patiënt, en wat is de eerste concrete stap?
De mogelijke uitkomsten zijn: Zvw (zorgverzekeraar), Wmo (gemeente), Wlz (zorgkantoor of de Wlz-instelling), UWV of werkgever, onderwijs/samenwerkingsverband, eigen rekening (algemeen gebruikelijk of eenvoudig hulpmiddel), en — even belangrijk als de andere zes — onbeslisbaar: escaleren naar mens.
Gebruikers en gebruikssituatie
AIOS revalidatiegeneeskunde, revalidatieartsen, ergotherapeuten en transferverpleegkundigen, staand op de gang of zittend op de poli met een patiënt tegenover zich. Ze hebben nu twee opties: een ervaren collega vragen of het niet uitzoeken. De app moet in onder de negentig seconden antwoord geven, anders wordt hij niet gebruikt.
Wat dit project mij moet leren
Een beslisboom modelleren als data (een geneste JSON-structuur die de app doorloopt) in plaats van als geneste if-statements in code. Bouw daarom zo dat ik de inhoud kan wijzigen zonder de code aan te raken, en maak dat onderscheid in je uitleg expliciet.
HARDE SCOPE
Binnen scope: verantwoordelijkheidstoewijzing voor de vier vraagsoorten die op een revalidatieafdeling langskomen — lichaamsgebonden hulpmiddelen (prothesen, orthesen, steunzolen, communicatiehulpmiddelen), mobiliteitshulpmiddelen (rolstoel, scootmobiel, aangepaste driewielfiets, loophulpmiddelen), roerende voorzieningen en woningaanpassingen (tillift, hoog-laagbed, douchestoel, traplift, drempelhulp), en voorzieningen voor werk, opleiding en onderwijs.
Buiten scope, expliciet: bedragen, eigen bijdragen en eigen risico (te volatiel), indicatiecriteria voor het hulpmiddel zelf (dat is een medische vraag, geen financieringsvraag), merken en leveranciers, en enige vorm van patiëntregistratie. Bouw geen accounts, geen database, geen backend.
FASERING EN CHECKPOINTS
Fase 0 — Bronnen eerst, code later (verplicht)
Schrijf nog geen applicatiecode. Lees eerst de bronnen hieronder en leg je bevindingen vast in BRONNEN.md. Dit is de belangrijkste fase van het project: de code is triviaal, de inhoud is dat niet, en een beslisboom die het verkeerde loket noemt is schadelijker dan geen beslisboom.
Primaire bronnen, in deze rangorde van gezag:

1. Regeling zorgverzekering, paragraaf 1.4 Hulpmiddelenzorg (artikelen 2.6 t/m 2.29) en Besluit zorgverzekering artikel 2.9 — de wettelijke basis van de Zvw-hulpmiddelenzorg, functioneel omschreven, dus geen productlijst maar functie-eisen. Raadpleeg via wetten.overheid.nl.
2. Zorginstituut Nederland, Handreiking hulpmiddelen voor cliënten met een Wlz-indicatie (definitieve versie, 4 december 2020) — het gezaghebbende afbakeningsdocument tussen Zvw, Wmo en Wlz. Controleer expliciet of er een recentere versie is en vermeld in BRONNEN.md welke versie je hebt gebruikt.
3. Zorginstituut Nederland, Hulpmiddelen algemeen (Zvw) en het Wlz-kompas.
4. Regelhulp.nl (ministerie van VWS), onderwerpen Hoe regelt u benodigde hulpmiddelen, Hulpmiddelen bij Wlz-zorg en Verschillen tussen Wmo, Zvw en Wlz — publieksniveau, goed voor de formuleringen naar de gebruiker toe, niet als enige onderbouwing gebruiken.
5. VNG, Inwoners met Wlz-indicatie — voor de gemeentelijke kant van de afbakening.
6. Een actueel Protocol Mobiliteitshulpmiddelen Wlz van een zorgkantoor (Menzis, VGZ, Zorg en Zekerheid publiceren deze per jaar) — voor de vraag wie mobiliteitshulpmiddelen beoordeelt bij een Wlz-indicatie.
7. UWV, Aangepaste werkplek aanvragen en de regeling meeneembare voorzieningen — inclusief het onderscheid wie de aanvraag doet: werknemer voor meeneembare voorzieningen, werkgever voor aanpassing van de werkplek zelf.
8. Wmo 2015 voor het begrip algemeen gebruikelijke voorziening en de jurisprudentiële invulling daarvan.

Let bij het lezen op de volgende bekende valkuilen en beschrijf ze in BRONNEN.md:

• De verdeling is de afgelopen jaren gewijzigd (overheveling van mobiliteitshulpmiddelen en roerende voorzieningen tussen Wmo en Wlz). Oudere pagina's, ook overheidspagina's, kunnen achterlopen. Noteer per regel per wanneer die geldt.
• Bij een Wlz-indicatie is de woonsituatie bepalend en niet de indicatie zelf: thuiswonend (inclusief mpt, vpt en pgb), geclusterd wonen, deeltijdverblijf, verblijf in een instelling zonder behandeling, en verblijf met behandeling zijn vijf verschillende antwoorden. Geclusterd wonen wordt in de VNG-uitleg als thuiswonend behandeld — verifieer dat.
• Lichaamsgebonden hulpmiddelen volgen een andere logica dan mobiliteits- en woonvoorzieningen. Zoek precies uit onder welke woonsituaties zij bij de Zvw blijven en waar dat kantelt.
• "Algemeen gebruikelijk" en "eenvoudig hulpmiddel" zijn geen synoniemen en leiden beide tot eigen rekening. Houd ze apart.

Checkpoint 0: lever BRONNEN.md op met per afbakeningsregel de bron, het artikel of paragraafnummer, de datum van de bron en de datum vanaf wanneer de regel geldt. Zet regels waar de bronnen elkaar tegenspreken of waar je het niet zeker weet in een aparte sectie Onzeker. Vraag mij dan om review voordat je verder gaat. Verzin niets: een lege plek in BRONNEN.md is een correct resultaat, een geraden artikelnummer niet.
Fase 1 — Datamodel
Zet de boom in data/beslisboom.json, volledig gescheiden van de code. Gebruik dit schema en wijk er niet van af:
json

{
  "versie": "1.0.0",
  "geldigPer": "2026-08-05",
  "startKnoop": "vraagsoort",
  "knopen": {
    "vraagsoort": {
      "type": "vraag",
      "vraag": "Wat voor voorziening betreft het?",
      "waarom": "De wettelijke route verschilt fundamenteel per soort voorziening.",
      "antwoorden": [
        { "label": "Lichaamsgebonden hulpmiddel (prothese, orthese, steunzool)", "naar": "lichaamsgebonden_wlz_check" },
        { "label": "Mobiliteitshulpmiddel (rolstoel, scootmobiel, aangepaste fiets)", "naar": "mobiliteit_woonsituatie" },
        { "label": "Roerende voorziening of woningaanpassing", "naar": "wonen_woonsituatie" },
        { "label": "Voorziening voor werk, opleiding of onderwijs", "naar": "werk_situatie" }
      ]
    },
    "voorbeeld_uitkomst": {
      "type": "uitkomst",
      "instantie": "Zvw — zorgverzekeraar",
      "kortAntwoord": "De zorgverzekeraar van de patiënt vergoedt dit hulpmiddel.",
      "eersteStap": "Verwijzing of aanvraag via de behandelaar naar de zorgverzekeraar; machtiging kan vereist zijn.",
      "onderbouwing": "Functioneel omschreven hulpmiddelenzorg, Regeling zorgverzekering paragraaf 1.4.",
      "bronnen": [
        { "titel": "Regeling zorgverzekering, art. 2.6 e.v.", "url": "https://..." }
      ],
      "letOp": [
        "Aanvragen vóór aanschaf; achteraf kopen kan de vergoeding kosten.",
        "Polisvoorwaarden en gecontracteerde leveranciers verschillen per verzekeraar."
      ],
      "geldigPer": "2026-08-05"
    }
  }
}

Twee eisen die je niet mag versoepelen. Elke uitkomst-knoop heeft minstens één bron met werkende URL en een geldigPer-datum. En elke vraag-knoop heeft naast de inhoudelijke antwoorden altijd de uitgang "Weet ik niet" of "Anders / valt hier niet onder", die leidt naar een uitkomstknoop van het type escalatie. Die escalatie-uitkomst is een volwaardig antwoord: hij noemt bij wie de gebruiker het dan wél kan navragen (ergotherapeut, transferverpleegkundige, zorgkantoor, gemeentelijk Wmo-loket, adviseur hulpmiddelen) en welke gegevens die persoon nodig heeft. Een beslisboom die altijd een loket noemt is een beslisboom die soms het verkeerde loket noemt.
Schrijf ook data/schema.md: één pagina die het knoopformaat uitlegt, zodat een collega zonder programmeerervaring een tak kan toevoegen.
Fase 2 — Validator vóór UI
Schrijf scripts/valideer-boom.mjs, uit te voeren met node scripts/valideer-boom.mjs. De validator faalt met een leesbare, Nederlandse foutmelding op: een verwijzing naar een niet-bestaande knoop, een onbereikbare knoop, een cyclus, een vraagknoop zonder escalatie-uitgang, een uitkomstknoop zonder bron of zonder geldigPer, en een pad langer dan zes vragen. Draai de validator ook in de tests, zodat de boom niet stiekem kan verslechteren.
Fase 3 — UI
Statische site, geen build-stap, geen framework, geen dependencies: index.html, app.js, stijl.css. Vanilla JS met ES-modules, fetch op het JSON-bestand.
Eén vraag per scherm, groot en met de hand goed te raken. Onder elke vraag een uitklapbaar waarom vraag ik dit met de waarom-tekst uit de knoop. Een breadcrumb van de gegeven antwoorden, waarbij elke stap aanklikbaar is om terug te springen; history.pushState zodat de browser-terugknop werkt zoals de gebruiker verwacht. Volledig met het toetsenbord te bedienen: cijfertoetsen voor de antwoorden, Backspace terug, Escape opnieuw beginnen. Mobiel-eerst, werkt op een telefoon in portretstand, leesbaar contrast, prefers-color-scheme gerespecteerd.
De resultaatkaart toont de verantwoordelijke instantie prominent, daaronder het korte antwoord, de eerste concrete stap, de onderbouwing, de aandachtspunten, de bronlinks en de geldigPer-datum. Er is één knop kopieer samenvatting die het gevolgde pad en de uitkomst als platte tekst naar het klembord zet, geschikt om in een verslag of een mail naar de ergotherapeut te plakken.
Op elke resultaatkaart staat, niet weg te klikken: dit is een hulpmiddel bij het denken, geen juridisch of financieel advies; regelgeving wijzigt en gemeenten en verzekeraars vullen ruimte verschillend in; controleer bij twijfel bij de betreffende instantie. Toon de geldigPer-datum van de boom in de footer van elke pagina, met een zichtbare waarschuwing zodra die datum meer dan twaalf maanden oud is — een verouderde boom moet zichzelf verklikken.
Fase 4 — Tests
Gebruik de ingebouwde testrunner van Node (node --test), geen extra dependencies. Naast de validator: een tabel met casussen die door de boom gelopen worden en waarvan de verwachte uitkomst is vastgelegd. Neem minimaal deze op, met de uitkomst zoals die uit jouw BRONNEN.md volgt — niet zoals ik hier suggereer:
Een 62-jarige met een transtibiale amputatie, thuiswonend, geen Wlz-indicatie, eerste prothese. Dezelfde patiënt maar met een Wlz-indicatie en verblijf in een instelling met behandeling. Een 47-jarige na een CVA, thuiswonend, die een handbewogen rolstoel voor buitenshuis nodig heeft. Iemand met progressieve MS en een Wlz-indicatie die thuis woont met een modulair pakket thuis en een elektrische rolstoel nodig heeft. Dezelfde vraag maar bij verblijf in een verpleeghuis. Een tillift voor een thuiswonende patiënt met een Wlz-indicatie in geclusterd wonen. Een traplift bij een thuiswonende patiënt zonder Wlz-indicatie. Een aangepaste bureaustoel en een aangepast toetsenbord voor iemand met een dwarslesie die weer aan het werk gaat bij een reguliere werkgever. Een aangepaste laptop voor een student met een handfunctiebeperking. Een rollator voor een thuiswonende zelfstandige oudere. En ten slotte twee casussen die bewust in de escalatie-uitkomst moeten eindigen: iemand in deeltijdverblijf met een vraag over een roerende voorziening, en iemand met een zorgvraag die zich niet in de vier vraagsoorten laat plaatsen.
Elke casus krijgt een commentaarregel met de bron waaruit de verwachte uitkomst volgt. Als een casus niet met een bron te onderbouwen is, dan is het verwachte antwoord escalatie — en dat is geen tekortkoming van de app maar een eerlijke weergave van de werkelijkheid.
Fase 5 — Documentatie en deployment
README.md met wat het is, voor wie, hoe je het lokaal draait (python3 -m http.server volstaat), hoe je een tak toevoegt, en een expliciete beperkingenparagraaf. ONDERHOUD.md met een halfjaarlijkse checklist: welke bronnen opnieuw langs, waar wijzigingen doorgaans vandaan komen (Zorginstituut, VNG-ledenbrieven, de jaarlijkse zorgkantoorprotocollen), en hoe je versie en geldigPer bijwerkt. Zet het op GitHub Pages via GitHub Actions. Geen analytics, geen externe fonts, geen CDN-scripts: alles wat de gebruiker invult blijft in de browser, en dat moet ook uit de code te lezen zijn.
Checkpoint 5: laat mij de werkende site zien, de testuitslag en de sectie Onzeker uit BRONNEN.md, voordat je aan uitbreidingen begint.
WERKWIJZE
Commit per fase met een beschrijvende Nederlandse commitmessage. Bij een keuze tussen inhoudelijke juistheid en het afmaken van een fase kiest je juistheid en meld je het. Bij twijfel over de regelgeving raad je niet en schrijf je geen plausibel klinkende onderbouwing bij een verzonnen artikelnummer, maar zet je de knoop op escalatie en vermeld je hem onder Onzeker. Leg per fase in twee of drie regels uit welk programmeerconcept ik net heb zien langskomen en waarom het zo is opgelost — dat is voor mij de helft van de opbrengst van dit project.
KLAAR IS HET WANNEER
De validator en alle tests groen zijn, elke uitkomstknoop een bron met werkende URL en een geldigPer-datum heeft, elke vraagknoop een escalatie-uitgang heeft, geen pad langer is dan zes vragen, de site op GitHub Pages staat en op een telefoon werkt, de sectie Onzeker in BRONNEN.md eerlijk gevuld is, en een collega zonder programmeerervaring op basis van data/schema.md een tak kan toevoegen zonder de code te openen.
NIET DOEN
Geen framework, geen bundler, geen npm-dependencies in de applicatie zelf. Geen bedragen of eigen bijdragen. Geen backend, geen opslag van invoer, geen analytics. Geen beslislogica in app.js die eigenlijk in de JSON hoort. Geen uitkomst zonder bron. En geen enkele plek waar de app een vergoeding belooft: hij wijst het loket aan, hij doet geen toezegging.