Van voorspelling tot verantwoordelijke actie: onzekerheid ontwerpen in Femtech AI

Bij vrouwengezondheid is nauwkeurigheid noodzakelijk, maar het is slechts de eerste laag van productveiligheid. Het is belangrijk dat het systeem weet wanneer een voorspelling sterk genoeg is om op te handelen en dat het is ontworpen om te zeggen wanneer het niet zo is.

Open de meeste fertility- of cycle-tracking-apps en u ziet een schoon resultaat: ovulatie op dag 15, een hoog-fertiliteitslabel, een vertrouwensscore van 78%. Het nummer ziet er precies uit. De biologie eronder is dat niet.

Een periodedatum is iets dat de gebruiker heeft waargenomen. Ovulatie is een latent evenement dat geen consumentenapparaat rechtstreeks meet. Het wordt afgeleid van proxies. Huidtemperatuur weerspiegelt niet alleen progesteron, maar ook slaap, alcohol, ziekte, omgevingscondities en waar de sensor die nacht zat. Een symptoominvoer mengt fysiologie met perceptie, geheugen en de beslissing van de gebruiker om het in te voeren. Tegen de tijd dat al dit in “Dag 15, 78%” wordt omgezet, zijn verschillende soorten onzekerheid stil in één zelfverzekerde zin samengeperst.

In de producten waar ik aan heb gewerkt in de vrouwengezondheid, is het harde probleem niet nauwkeurigheid. Het patroon dat ik steeds terugkom is beslissingsintegriteit. Nauwkeurigheid vertelt u hoe goed een model voorspelt. Het zegt niets over of het product weet wanneer een voorspelling sterk genoeg is om op te handelen. In een domein waar hetzelfde resultaat zowel voor casual planning als voor een anticonceptiebeslissing kan worden gebruikt, is dat de kloof waar vertrouwen wordt gewonnen of verloren.

Mijn argument is dus dat Femtech AI niet in de eerste plaats betere voorspellingen nodig heeft. Het heeft beter ontwerp van onzekerheid nodig. En onzekerheidsontwerp is geen disclaimer die voor de lancering wordt bevestigd; het is een architectuur. Ik structuur het in zes lagen die een signaal van ruwe invoer naar een actie die het systeem kan rechtvaardigen en auditen, dragen. Ik pas een zeslaagse versie van de Gecorrigeerde Beslissing-tot-Actie Product Methode toe, ontworpen om te reguleren hoe onzekere gezondheidssignalen worden omgezet in toegestane en verantwoordelijke acties. De methode omvat gegevenskwalificatie, inferentiekalibratie, consequentiekaart, controlebeleid, workflowuitvoering en een verantwoordingslus. De regulerende route begint met gezondheidsgegevens, die leiden tot beslissingsarchitectuur en culmineren in verantwoordelijke actie.

1. Kwalificeer de gegevens voordat u ze vertrouwt

De eerste laag beslist wat het systeem eigenlijk weet. Femtech-producten trekken uit zeer verschillende bronnen. Het kan dingen omvatten die de gebruiker rechtstreeks heeft waargenomen, zoals periodedata of subjectieve rapporten zoals pijn of stemming, evenals draagbare functies zoals huidtemperatuur en hartslagvariabiliteit, en variabelen die het model zelf heeft gegenereerd. Het behandelen van deze als uitwisselbare invoer is de oorspronkelijke zonde.

Elk signaal heeft een herkomst die het systeem kan lezen: waar het vandaan komt, wanneer, hoe vaak het wordt bemonsterd, wat het beïnvloedt en hoe het zich verhoudt tot het ding dat u eigenlijk voorspelt. Ovulatie is het evenement. Temperatuur, cervicale slijm, LH en cyclusedata zijn bewijs over dat evenement, elk met zijn eigen vertraging en zijn eigen fout.

Ontbrekende gegevens verdienen speciale aandacht, omdat ze in gezondheidstracking zelden willekeurig zijn. Mensen loggen meer wanneer ze bezorgd zijn en stoppen wanneer ze zich goed voelen, dus een lacune kan evenveel informatie dragen als een invoer. In een echte analyse van meer dan 600.000 ovulatiecycli, kon ovulatie niet worden gedetecteerd in 665.603 van de 1,4 miljoen cycli die eerst werden overwogen. Driekwart daarvan had geldige temperatuurmetingen op minder dan de helft van de dagen in de cyclus. Gegevensvolledigheid was een belangrijke beperkende factor in wat de algoritme kon afleiden. Een product dat in die situatie een helder fertiliteitslabel uitgeeft, is niet zelfverzekerd. Het fabriceert precisie die het niet heeft.

2. Kalibreer de inferentie naar het bewijs

Een enkele vertrouwensscore kan niet vertegenwoordigen wat er echt gebeurt, omdat deze systemen verschillende onderscheiden bronnen van onzekerheid tegelijkertijd tegenkomen. Deze omvatten biologische variabiliteit in het proces zelf, meetkwaliteit, ontbrekendheid van zelftracking, modelonzekerheid van dunne trainingsgegevens en distributieshift wanneer de huidige gebruiker niet lijkt op de populatie waarop het model werd gevalideerd.

In diezelfde analyse waren slechts 13% van de cycli exact 28 dagen lang, en de gemiddelde folliculaire fase liep 16,9 dagen over een bereik dat breed genoeg was om elke vaste “dag 14”-aanname misleidend te maken. De Apple Women’s Health Study vond dat cyclusp lengte en binnenpersoonlijke variabiliteit geassocieerd waren met leeftijd, zelfgerapporteerde etniciteit en lichaamsmassaindex. Personalisatie kan dus niet betekenen dat een populatiegemiddelde wordt ingeruild voor een enkel persoonlijk punt. Het betekent het produceren van een distributie die strakker wordt naarmate het bewijs accumuleert.

Overweeg twee AI-gebaseerde voorspellingen die beide “75%” lezen. Eén rust op een jaar geschiedenis en dichte metingen, en de onzekerheid is voornamelijk echte biologie. De andere rust op twee cycli, vijf temperatuurmetingen, recente reizen en onbekende medicatie. Hier is de onzekerheid voornamelijk te wijten aan ontbrekende gegevens. Dezelfde nummer. Het product mag niet op dezelfde manier op beiden reageren. Dit is ook waarom kalibratie binnen subgroepen moet worden gecontroleerd – geaggregeerde prestaties kunnen een model verhullen dat oververzekerd is, vooral voor onregelmatige cycli of perimenopauzale gebruikers. De klinische-AI-literatuur scheidt nu discriminatie, kalibratie en beslissingsnut voor precies dit doel. Een model kan gebruikers goed rangschikken en nog steeds onjuiste waarschijnlijkheden voor echte beslissingen produceren.

3. Kaart de consequentie van verkeerd zijn

De derde laag vraagt wat er gebeurt wanneer het systeem verkeerd is, en koppelt de toegestane reactie aan die kosten. Een cyclussamenvatting, een vruchtbare-vensterinschatting, een laag-fertiliteitslabel dat als anticonceptieadvies wordt gelezen, en een symptoominterpretatie die beslist of iemand zorg zoekt, zijn niet hetzelfde product, zelfs wanneer het model erachter identiek is.

Ik sorteert uitvoer in vier lagen naar consequentie: informatief, gedragsmatig, reproductief en klinisch. Elk krijgt zijn eigen bewijsdrempel, toegestane taal en escalatiepad. Een 70%-waarschijnlijkheid kan voldoende zijn om te raden wanneer een periode zal beginnen en nergens in de buurt van genoeg om iemand te geruststellen die probeert niet zwanger te worden.

Dit is waar ontwerp ontmoet regelgeving. Of software overgaat in medisch-apparatuurterritorium hangt af van de beoogde gebruik en de rol van de uitvoer in een gezondheidsbeslissing. De huidige FDA-Clinical Decision Support Software-richtlijn, bijgewerkt in januari 2026, is expliciet dat functies die zijn bedoeld voor patiënten en verzorgers de definitie van een apparaat kunnen vervullen. Regelgevingspositionering is geen juridische herziening aan het einde. Het is ingebed in uw drempels, uw woording en uw escalatielogica vanaf de eerste dag.

4. Zet onzekerheid om in een controlebeleid

Een algemene “resultaten kunnen onnauwkeurig zijn” geeft het hele interpretatieprobleem terug aan de gebruiker. Een controlebeleid doet het tegenovergestelde. Voor een bepaalde bewijsstaat beslist het of het systeem een observatie toont, een begrensde reeks aanbiedt, om een andere meting vraagt, naar een clinicus wijst of weigert om antwoord te geven. Abstinente is een productmogelijkheid, geen falen. “We weten het nog niet” moet een ontworpen staat zijn met een volgende stap, geen foutscherm.

Concreet, in plaats van “Ovulatie: Dag 15, 78%”, produceert de architectuur iets anders. Het markeert de temperatuurgegevens als schaars en slaapbeïnvloed. Het genereert een distributie over verschillende kandidaatdagen in plaats van één. Het past een zachte drempel toe voor cyclusbewustzijn, maar een striktere voorwaarde als de uitvoer zwangerschapsvoorkoming raakt. Het biedt een bereik plus de volgende nuttige meting. En het slaat de hele bewijsstaat op zodat de beslissing later kan worden gereconstrueerd. Dezelfde onderliggende model en een heel ander product.

5. Ondersteun de actie die de uitvoer impliceert

Zelfs een consumentenapp creëert een workflow: log een andere meting, herhaal een test, blijf observeren, exporteer gegevens, bel een clinicus. Het systeem moet weten welke actie elke reactie naar verwijst en of het die actie veilig kan ondersteunen.

De grens tussen productbegeleiding en medisch advies leeft hier, en het is geen vaste lijn. Onderwijsinhoud die uitlegt wat een signaal algemeen betekent, zit veilig aan de begeleidingszijde. Het product verplaatst zich naar een hoger-risicogebied zodra het de gegevens van één persoon interpreteert als ziekte, behandeling richt of geruststelling biedt die echte klinische waarde draagt. Die grens moet bij elke interactie worden gehandhaafd, niet alleen in de voorwaarden.

6. Sluit de verantwoordingslus

De laatste laag beoordeelt het hele systeem, niet alleen het model. Standaardmodelmetriek is nog steeds belangrijk en richt zich op discriminatie, kalibratie, subgroepprestaties, externe en temporele validatie. Maar productniveaumetriek is net zo belangrijk. We moeten vragen hoe vaak het systeem voldoende invoer had om te handelen, hoe vaak het afzag. Plus de ene die ik zou aandringen is een vals-geruststellingspercentage, wat betekent hoe vaak het iemand vertelde dat alles in orde was op basis van bewijs dat de claim niet kon ondersteunen.

Elke gevolgrijke reactie moet achteraf te reconstrueren zijn. Regulatoren, standaardorganisaties en wereldwijde gezondheidsbeheersorganisaties nemen deze levenscyclusvisie steeds vaker over. De IMDRF’s good machine learning practice-principes behandelen betrouwbaar medisch AI als een totale levenscyclusverantwoordelijkheid die ontwerp, implementatie en monitoring omvat, wat de WHO’s richtlijn voor AI voor gezondheid weerspiegelt.

Hoe de architectuur er in de praktijk uitziet

Stel dat een product drie maanden aan periodedata, zes nachten aan temperatuur, één positieve LH-test, een verspreiding van symptoominvoer en een week slechte slaap heeft. Het model met de hoogste ovulatiekans landt op dag 15. Een puntgeschatte app toont “Ovulatie: Dag 15, Vertrouwen 78%”.

De architectuur produceert iets anders. Het markeert de temperatuurgegevens als schaars en slaapbeïnvloed. Het genereert een distributie over verschillende kandidaatdagen in plaats van één. Het past een zachte drempel toe voor cyclusbewustzijn, maar een striktere voorwaarde als de uitvoer zwangerschapsvoorkoming raakt. Het biedt een bereik plus de volgende nuttige meting. En het slaat de hele bewijsstaat op zodat de beslissing later kan worden gereconstrueerd. Dezelfde onderliggende model en een heel ander product.

Het recht om te handelen

Femtech-systemen worden alleen maar gegevensrijker, met apps, wearables, thuistests, medische dossiers en conversatielagen gestapeld. Meer gegevens kunnen de inferentie scherper maken, maar ze vergroten ook het oppervlak voor vals precisie. De teams die vertrouwen verdienen, zullen niet degene zijn met de schoonste vertrouwensscore. Ze zullen degene zijn wiens producten weten wat ze niet weten en zijn ontworpen om dat te zeggen.

Nauwkeurigheid beschrijft de kwaliteit van een voorspelling. Beslissingsintegriteit beslist of het product het recht heeft verdiend om op basis daarvan te handelen.