Hoe prototypes helpen om complexe databeschikbaarheid concreet te maken
Soms kom je er pas achter wat je eigenlijk bedoelt, als je iets werkends ziet. Dat klinkt misschien onhandig voor een architectuurtraject. We zijn gewend om eerst te analyseren, dan te ontwerpen, dan te specificeren en pas daarna te bouwen. Maar bij complexe databeschikbaarheid werkt dat niet altijd zo netjes. Begrippen lijken op papier helder, totdat je ze moet uitvoeren. Een rol, datamodel of beveiligingseis wordt pas scherp als je bepaalt hoe die in de praktijk werkt.
Van architectuur naar gedrag
Bij CumuluZ gebruiken we prototypes daarom niet alleen als demo, maar ook als manier om de doelarchitectuur scherper te krijgen. Ik noem dat: Prototype-First Specification. Het idee is simpel: bouw eerst iets werkends om aannames zichtbaar te maken. Gebruik dat gedrag daarna om betere specificaties te schrijven.
Zodra iets werkt, verandert het gesprek
In het eerste bredere CumuluZ-prototype werd de hele keten concreet. Niet alleen als plaat met blokken, maar als gedrag: hoe stel je de vraag, hoe ziet de data eruit, welke component brengt bronnen bij elkaar, welke generieke functies zijn nodig en hoe kunnen we datakwaliteit zichtbaar maken? Pas toen dat ging lopen, werd de doelarchitectuur echt bespreekbaar. De visualisatie werd geen losse architectuurplaat, maar een samenvatting van werkend gedrag.
Waar abstractie ophoudt: translatie
Hetzelfde zie je bij het prototype translatie waarin we voor die functie echt de diepte in gingen. Iedereen kan zeggen dat zorgdata vertaald moet worden naar een gemeenschappelijk model. Maar de echte vragen ontstaan pas als je het probeert. Waar vindt de vertaling plaats? Wat doe je met lokale codes? Welke informatie gaat verloren? Door brondata, logische tussenmodellen, doelprofielen en validatie naast elkaar te zetten, zie je welke betekenis behouden blijft, welke verandert en waar een expliciete ontwerpkeuze nodig is.
Secundair gebruik wordt pas concreet als je het doet
Voor secundair gebruik geldt hetzelfde. ‘We moeten patiëntdata in grote volumes beschikbaar kunnen maken’ klinkt overzichtelijk, totdat je het concreet maakt. Dan gaat het over cohortselectie, databronnen, herleidbaarheid, pseudonimisatie, minimalisatie, logging, toestemming en wat een datagebruiker terugkrijgt. Het prototype voor secundair gebruik helpt om dat gesprek te voeren vanuit werkend gedrag: kunnen we veel data bij elkaar krijgen, waar moet filtering plaatsvinden, en wanneer is data voldoende beschermd?
AI-agents versnellen het ontwerpproces
AI-agents versnellen dit proces enorm. Daarmee bedoel ik niet een chatbot die alleen tekstsuggesties geeft, maar software-assistenten die met een duidelijke opdracht code kunnen lezen, testdata kunnen maken, varianten kunnen bouwen, tests kunnen draaien en documentatie kunnen bijwerken. Daarmee wordt ook het ontwerpproces zelf AI-agent-ondersteund. Niet doordat de agent de architectuur kiest, maar doordat ontwerp, prototype, test en specificatie dichter bij elkaar komen te liggen. Je kunt een ontwerpkeuze formuleren, laten uitwerken in een klein experiment, de gevolgen bekijken en daarna de specificatie scherper maken.
Waarom dit juist voor zorg-IT belangrijk is
De mens bepaalt de richting en neemt de ontwerpbeslissingen. Maar AI-agents maken de iteratie korter. Het gesprek verschuift sneller van ‘zou dit kunnen?’ naar ‘dit is wat er gebeurt, vinden we dit het juiste gedrag?’ Dat is voor zorg-IT belangrijk. Discussies over databeschikbaarheid blijven vaak hangen in begrippen: interoperabiliteit, standaardisatie, privacy, regie, governance. Die worden pas scherp als je ziet hoe ze uitpakken in een concrete gegevensstroom.
Een prototype is geen eindpunt
Een prototype is daarbij geen eindantwoord. Het is een manier om betere vragen te krijgen. Geen afkorting om specificatie over te slaan, maar een instrument om specificatie serieuzer te nemen. Na het prototype begint het echte werk: de specificaties zelf uitschrijven en toetsen, API-afspraken, informatiestandaarden, beveiligingseisen, testscenario's, beheerafspraken en governance.
De kern
Voor mij is dat de kern van Prototype-First Specification. Werkend gedrag is de snelste manier om architectuur bespreekbaar en toetsbaar te maken. Niet omdat code belangrijker is dan ontwerp. Maar omdat ontwerp zonder uitvoering te lang abstract kan blijven. Prototype-first betekent dan niet: sneller code schrijven om de discussie te vermijden. Het betekent: sneller iets werkends maken, zodat de juiste discussie eerder kan beginnen.
Bekijk hier de demo van het prototype:
