Wat MDR IIb betekent voor hoe wij bouwen bij Delphyr

In deze blogserie, Delphyr Engineering, delen we praktische inzichten over het ontwikkelen van een AI-platform voor de zorg. In deze blog vertelt engineer Tim ons wat het streven naar MDR klasse IIB concreet betekent voor zijn dagelijkse werk.

MDR, in het kort

MDR (Medical Device Regulation) is het EU-kader dat software die in de zorg wordt gebruikt indeelt in risicoklassen, gebaseerd op het beoogde gebruik en de bijbehorende risico's. Bij de indeling wordt onder meer gekeken naar mate van invasiviteit, gebruiksduur en mogelijke schade aan patiënten of gebruikers, wat samen de risicoklasse bepaalt. Klasse IIb bevindt zich aan de hogere kant van dat spectrum, passend bij het soort klinische beslisondersteuning dat Delphyr voor ogen heeft.

Compliance is geen papierwerk, het is de manier van werken

Bij MDR denken de meeste mensen aan een checklist: bouw een feature, en vink daarna wat vakjes af voordat die live gaat. Oftewel: een stempel van goedkeuring, achteraf erop geplakt. Zo werkt het in de praktijk niet. MDR toetst niet alleen wat je hebt gebouwd. Het verandert fundamenteel de manier waarop je dingen bouwt, en welke vragen je onderweg verplicht bent te stellen. Voor het engineering team van Delphyr raakt dit vooral drie werkwijzen: hoe ze bijhouden waar informatie vandaan komt, hoe ze omgaan met klantfeedback, en wat er nodig is voordat een feature het label 'af' krijgt. 

Dat is geen toeval. Het hangt samen met waarom Delphyr voor klasse IIb kiest in plaats van een lichtere classificatie: die klasse stelt een hogere eis aan het bewijs dat de software daadwerkelijk werkt, en dat bewijs moet ook na lancering blijven komen, niet alleen ervoor. 

Klantfeedback heeft een deadline

De eerste grote verschuiving zit in hoe feedback van klanten wordt afgehandeld. Als een klant iets meldt, heeft Delphyr 30 dagen om te reageren of actie te ondernemen. Dit houdt in dat we altijd het gesprek aangaan over wat er is gemeld. Dit valt onder een breder MDR-vereiste genaamd post-market surveillance: de verplichting om actief te blijven monitoren hoe een gecertificeerd product presteert zodra het daadwerkelijk in gebruik is, niet alleen op het moment van certificering.

"We ontwikkelen oplossingen samen met klanten, in plaats van dat we gokken wat ze ongeveer nodig hebben." - Tim de Boer, AI Engineer bij Delphyr

In de praktijk betekent dit dat feedback niet iets is waar het team passief op wacht. Delphyr's producten zijn zo gebouwd dat feedback geven zo laagdrempelig mogelijk is, en het team haalt die feedback ook actief zelf op. Bijvoorbeeld door met clinici in gesprek te gaan over hoe een feature voor hen daadwerkelijk werkt, in plaats van alleen te kijken naar feedback die wordt ingestuurd via een feedbackformulier. 

We moeten van elk stukje informatie weten waar het vandaan komt

De tweede verschuiving zit in hoe informatie gemanaged wordt. Neem als voorbeeld het gebruik van AI om klinische richtlijnen te checken. Voordat zo'n richtlijn bruikbaar is voor een zorgprofessional, moet die worden gedownload, opgeslagen en omgezet naar een format waarmee het AI-model binnen het Delphyr-platform kan werken. Onder MDR laat elk van die stappen een spoor achter: wanneer de richtlijn is gedownload, hoe die is geconverteerd, waar die zich bevindt, en welke versie van Delphyr's code de conversie heeft uitgevoerd, en wanneer.

Waarom is dit detailniveau belangrijk? Omdat richtlijnen versie-updates krijgen, en code ook verandert. Als later blijkt dat een conversie gebrekkig was en gerepareerd moet worden, moet het team precies kunnen aanwijzen welk document en welke code het probleem heeft veroorzaakt. Een richtlijn die vandaag live staat in het product is dus niet zomaar "de huidige versie" die daar staat, het is het eindpunt van een keten die je, in theorie, stap voor stap terug zou kunnen volgen: document voor document, codewijziging voor codewijziging.

Datzelfde principe geldt breder dan alleen richtlijnen. Alle code die iets raakt dat onder MDR valt, moet eerst te herleiden zijn tot twee dingen: het risico dat het beheerst, en de klantbehoefte die het dient. Pas als dat vaststaat, stelt het team de meer vertrouwde engineering vraag: werkt het ook daadwerkelijk?

Het live zetten van een feature is waar het echte werk begint

De derde verschuiving gaat over testen, en die verandert wat 'af' eigenlijk betekent. Hierbij markeert het lanceren van een feature niet het einde van het werk. Het is eerder een startschot. Zodra iets live staat, begint het pas: nauwlettend volgen hoe het presteert in de praktijk, en nauw contact houden met de mensen die het gebruiken.

In de praktijk begint dit bij het vaststellen van de risico's die het team al heeft gedocumenteerd. Vanuit die risico's bepalen ze vervolgens wat het systeem daadwerkelijk moet kunnen (de functional requirements). Vandaar wordt het nog concreter: er worden acceptatiecriteria opgesteld, gedetailleerd genoeg beschreven om precies aan te geven wat de code stap voor stap moet doen. Die criteria worden vervolgens omgezet in tests.

Voor veel software is dat een schoon, voorspelbaar proces. Als een gebruiker inlogt, moet het systeem dat opslaan. Het gebeurt, of het gebeurt niet. Dat soort software is deterministisch: geef dezelfde input, en je krijgt altijd dezelfde output.

De AI van Delphyr is anders. Die is namelijk gebouwd op large language models, die probabilistisch zijn in plaats van deterministisch: in plaats van een vaste set regels te volgen naar één gegarandeerd antwoord, genereren ze een reactie op basis van waarschijnlijkheden. Concreet betekent dit dat als je tien keer dezelfde vraag stelt, je technisch gezien tien licht verschillende antwoorden kunt krijgen. Eén enkele slaag-of-faal-test vertelt je dus niet echt of het systeem werkt.

In plaats daarvan bouwt het team wat een 'eval' wordt genoemd: in essentie een grote, gestructureerde test die uit veel realistische voorbeelden bestaat, in plaats van één. Voor een requirement als "als een gebruiker een vraag in het Nederlands stelt, moet het systeem in het Nederlands antwoorden", kan dat betekenen dat er een dataset van duizend synthetische Nederlandse vragen wordt gebouwd, ontworpen om situaties te weerspiegelen die zich realistisch gezien kunnen voordoen bij Delphyr's klanten, en dat gecontroleerd wordt of het systeem het in minstens 95% van de gevallen goed doet. Die drempelwaarde, niet het slagen of falen van één enkele test, bepaalt of het gedrag betrouwbaar genoeg wordt geacht om te lanceren.

Ook hier staat niets op zichzelf. Een falende eval is helemaal terug te herleiden via dezelfde keten als al het andere: naar de acceptatiecriteria, naar de klantfeedback die deze vormgaf, naar het onderliggende risico dat ermee moest worden aangepakt.

Alles bij elkaar

Deze drie hierboven beschreven verschuivingen zijn niet echt losse werkwijzen. Het is één loop, en ze steunen op elkaar.

Stel dat een clinicus meldt dat een op een richtlijn gebaseerd antwoord vreemd overkomt. Dankzij de hierboven beschreven traceerbaarheid kan het team precies terughalen wat er is gebeurd: welke versie van de richtlijn live stond, welke versie van de code die heeft verwerkt, en wanneer. Die reconstructie is alleen mogelijk omdat elke stap een spoor heeft achtergelaten.

Van daaruit begint de klantfeedback-klok te lopen: Delphyr heeft 30 dagen om het uit te zoeken en te reageren. Begrijpen wat er daadwerkelijk is gebeurd, is wat een vaag signaal omzet in iets bruikbaars. Een risico dat gedocumenteerd moet worden, een requirement dat bijgewerkt moet worden, of een casus die wordt toegevoegd aan een eval-dataset zodat de fix voortaan tegen realistische voorbeelden getest kan worden, niet alleen tegen het ene gemelde geval.

Traceerbaarheid gaat dus niet alleen over het verklaren van het verleden. Het is wat de feedbackloop überhaupt mogelijk maakt, en het is wat nieuwe casussen voedt aan het testen. Het spoor van een richtlijn leidt naar een feedbackgesprek, dat leidt naar een risicobeoordeling, die leidt naar een test.

Waar het uiteindelijk om gaat

Niets hiervan draait echt om de regelgeving zelf. Het is eerder een manier van werken (en niet alleen voor engineering). Diezelfde principes lopen door hoe het hele bedrijf opereert: begrijpen wat mensen daadwerkelijk nodig hebben, dat omzetten naar iets concreets, testen of het echt doet wat het beoogde, en de loop sluiten met de mensen die het gebruiken.

MDR heeft die discipline niet uitgevonden. Maar het maakt het wel verplicht, en dat blijkt op zichzelf waardevol: het geeft iedereen bij Delphyr een gedeelde, niet-onderhandelbare lat om tegen te bouwen, in plaats van een standaard die voor elke feature opnieuw bevochten moet worden. Voor een team dat AI bouwt die bedoeld is om in echte klinische workflows te functioneren, is dat minder een beperking om omheen te werken en meer een basis die het werk juist makkelijker maakt: iedereen weet al wat goed eruit moet zien, voordat er ook maar één regel code wordt geschreven.