Van Lotus 123 tot Lovable: 30 jaar zorgsoftware bouwen

1995: Lotus 123 als zorgdossier

In 1995 werd ik directeur van een klein woonzorgcentrum. Het personeel werkte hard, de regelgeving was zwaar, en de hoeveelheid documentatie die je dagelijks moest bijhouden voor inspecties en interne controles was, vriendelijk gezegd, aanzienlijk.

Wat er aan software bestond? Een boekhoudprogramma. Lotus 123. Vroege versies van Office. Voor een financieel adviseur of een controller misschien voldoende. Voor wie elke ochtend zes verschillende registraties moest doen voor de inspectie, voor wie de medicatieronde wilde plannen, voor wie de roosters van zorgkundigen wilde synchroniseren met de payroll: van geen enkel nut.

Boekhoudsoftware paste op de werkvloer van een verpleegkundige als een tang op een varken. Andere termen, andere logica, ander ritme. Je vraagt een verpleegkundige niet om voor elke medicatieregistratie een journaalpost in te boeken; de hele structuur van de tool werkt tegen haar in plaats van met haar mee.

Er was geen kant-en-klaar alternatief. Dus moest ik het zelf bouwen.

Hoe je dat in 1995 deed

Je begon met Microsoft Access. Tabellen, queries, formulieren. Je luisterde eerst goed naar wat een hoofdverpleegkundige nodig had, wat een zorgkundige verwachtte, hoe een kinesist dacht over rapportering. Een formulier moet er op deze manier uitzien. De gegevens moeten in die volgorde verschijnen. Het rapport voor de inspectie moet die layout volgen, met die kleuren, op dat papierformaat.

Je luisterde, en je vertaalde. Naar tabelstructuren. Naar formulier-componenten. Naar exportscripts richting de payroll. Stap voor stap groeide er een zorgdossier, een medicatiebeheer, een planning-module.

Een jaar of twee werkte Access voldoende. Daarna botste het tegen z'n grenzen: te traag, niet performant genoeg voor meerdere gelijktijdige gebruikers. We zijn overgeschakeld op een web-based applicatie met eigen servers en een eigen portaal. De medicatieronde, de zorgplanning, het personeelsrooster, de output naar payroll, de samengevatte rapporten voor de inspecties: allemaal in één omgeving. De administratieve last voor inspecties bracht ik tot een minimum terug, omdat alles intern al gestructureerd zat zoals de inspecties het vroegen.

De rol van vertaler

Dit is het stukje dat me het meest geleerd heeft over zorg-IT van de laatste dertig jaar: ik werd een vertaler. Tussen wat op de werkvloer écht nodig was en wat in code, in technische ontwerpkeuzes, in workflows belandde.

De hoofdverpleegkundige weet exact wat haar registratiestroom moet zijn. Ze kan haar pijnpunt beschrijven met een precisie die geen extern consultant ooit haalt. Maar ze kent geen tabelstructuren of API-calls. Ze hoeft die ook niet te kennen.

Dus was er iemand nodig die luisterde en doorvertaalde. Iemand die kon zeggen: "Ah, je hebt het over een één-op-veel-relatie tussen het zorgdossier en de gebeurtenissenlijst, en je vraagt eigenlijk om een filter op gebeurtenistype, gesorteerd op datum, met een uitzondering voor de medicatieregels." Iemand die er vervolgens een Access-formulier of een webpagina van maakte.

Ik heb die rol jarenlang gespeeld. Niet altijd zelf met de code in handen, soms aan een externe ontwikkelaar uitgelegd wat er moest gebeuren. Maar wel die rol van bemiddelaar tussen werkvloer en techniek.

En toen veranderde de fundering

In de laatste paar jaar zie ik die rol verdampen. Niet omdat de werkvloer plots zelf code begon te schrijven, maar omdat de tools veranderd zijn.

Lovable, Base44, Cursor, Bolt, Replit. Je beschrijft in gewoon Nederlands of Engels wat je tool moet doen. Een AI-systeem vertaalt dat naar werkende code. De hoofdverpleegkundige die in 1995 mij nodig had om haar registratieformulier te kunnen automatiseren, kan vandaag dat formulier zelf opzetten.

Ik merk het in elke begeleidingssessie die ik geef. Mensen op de werkvloer, zonder enige programmeerachtergrond, pakken die tools binnen een uur op. Binnen een namiddag staat er een werkend prototype. Op één werkdag heb je een tool die volgende week op een echte (niet-patiëntgebonden) use case getest kan worden.

Dat is fundamenteel nieuw. Niet alleen omdat het sneller gaat; vooral omdat de tussenpersoon is verdwenen. De verpleegkundige beschrijft haar workflow niet meer aan mij; ze beschrijft hem aan de AI. En de AI maakt er de tool van.

Eerlijk over de grenzen

Hier moet ik wel een kanttekening bij maken, anders verkoop ik een halve waarheid.

Wat vibecoding goed kan: tools maken voor privégebruik, voor kleine teams, voor lokale workflows die op één laptop draaien. Een dokter die zijn eigen brief-herformulator bouwt om patiëntcommunicatie in B1-taal aan te leveren. Een kinesist die een eigen oefeningenkennisbank automatiseert. Een teamcoach die een eigen briefing-template bouwt voor multidisciplinair overleg. Allemaal volledig haalbaar.

Wat vibecoding nog niet goed kan, zonder vakkundig nazicht en herwerking: productie-omgevingen waarin honderden gebruikers werken, waar patiëntdata in worden bewaard, waar GDPR-vereisten van toepassing zijn, waar audit-trails en toegangscontrole steekhoudend moeten zijn. Voor dat soort applicaties heb je nog steeds professionele software-engineering nodig. Vaak een complete overhaul van het oorspronkelijke prototype.

Het onderscheid is essentieel. Wie het verwart, verkoopt zichzelf vroeg of laat een teleurstelling.

Twee plekken waar dit nu al verschil maakt

Twee opportuniteiten die direct werkbaar zijn:

1. Privépraktijken en kleine teams. Hier was de keuze tot voor kort: ofwel kies je een generieke commerciële tool en plooi je je workflow eromheen, ofwel betaal je een agency om iets op maat te bouwen. De eerste optie frustreert; de tweede is voor de meeste praktijken financieel niet haalbaar. Vibecoding geeft een derde weg: bouw het zelf, leer de tool al doende kennen, en pas hem aan zodra je inzicht groeit.

2. De ontwerpfase voor grotere applicaties. Wie een professionele developer of een agency inhuurt, weet hoe duur de eerste ontwerpfase is. Vergaderingen, mockups, iteraties op specs die altijd net niet lijken op wat de werkvloer bedoelde. Met vibecoding kan een zorgprofessional zelf een werkend prototype bouwen, dat prototype testen met collega's, en pas dán naar een agency stappen met een veel scherpere brief: "Bouw deze workflow productie-rijp." Een ontwerpfase die vroeger weken duurde, krimpt tot dagen.

Wat we op 3 oktober doen

Clinical Build Day is geen abstract event over technologie. Het is een concrete dag waarop zorgprofessionals leren wat ik dertig jaar geleden alleen door pure noodzaak heb moeten leren. Tools gebruiken om hun eigen workflow te automatiseren. Het verschil tussen "speelgoed-prototype" en "productie-rijp" leren herkennen. Een werkend prototype meenemen naar huis dat ze die maandag aan hun collega's kunnen tonen.

Het is ook een poging om iets door te geven dat ik destijds, in 1995, in mijn eentje heb moeten uitvinden: dat de werkvloer haar eigen software-pijnpunten het beste begrijpt. Dat externe consultants en standaard-pakketten nooit helemaal aansluiten. Dat iemand op de werkvloer, gewapend met de juiste tools, op een specifiek probleem een betere oplossing kan bouwen dan een agency die van buitenaf komt.

In 1995 had ik daar maanden voor nodig. Vandaag, een dag.

Schrijf je in op de waitlist via careandcode.be. 3 oktober 2026, België. We kijken ernaar uit.

— Bart