Healthcare analytics en ML-platform op Google Cloud

Een revalidatiekliniek gespecialiseerd in chronische pijnbehandeling had een wetenschappelijk onderbouwd ML-model dat behandeluitkomsten kon voorspellen. Het model bestond als Python-script op een laptop. De patiëntdata zat opgesloten in een EPD-systeem zonder exportmogelijkheden. Dit is het verhaal van hoe dat een productieplatform werd.

Situatie

De kliniek behandelt patiënten met chronische pijn - een complex ziektebeeld waarbij behandeluitkomsten sterk variëren per patiënt. Een domeinexpert had een machine learning-model ontwikkeld op basis van wetenschappelijk onderzoek. Het model gebruikte 51 patiëntparameters - demografische gegevens, vragenlijstscores, diagnosekenmerken - om een prognose te genereren voor het verwachte behandelresultaat.

Het model werkte. Op een laptop, met handmatig gekopieerde data, als eenmalige exercitie. Maar het was niet schaalbaar, niet reproduceerbaar, en niet bruikbaar in de dagelijkse praktijk.

Tegelijkertijd zat alle patiëntdata opgesloten in het EPD-systeem van de kliniek. Geen API, geen exportfunctie, geen manier om data gestructureerd naar buiten te krijgen. De EPD-leverancier had daar ook geen plannen voor.

De kliniek kwam bij ons met een concreet verzoek: help ons die data ontsluiten. Wat volgde was een samenwerking die uitgroeide van een enkele connector tot een compleet data- en ML-platform.

Uitdaging

De technische uitdagingen waren op drie niveaus:

Data ontsluiten. Het EPD-systeem was een zwarte doos. Geen gedocumenteerde database-structuur, geen officiële exportmogelijkheid. De enige manier om bij de data te komen was via het netwerk van de kliniek zelf.

Data transformeren. Het ML-model had 51 specifieke parameters nodig. Die bestonden niet als kant-en-klare velden in het EPD - ze moesten berekend worden uit ruwe data. Vragenlijstscores moesten geaggregeerd worden, leeftijden berekend, conditionele variabelen afgeleid. Elke berekening moest exact overeenkomen met de wetenschappelijke definitie.

Model naar productie brengen. Een scikit-learn model op een laptop is iets fundamenteel anders dan een model dat dagelijks draait, automatisch nieuwe data verwerkt, en resultaten beschikbaar stelt aan onderzoekers. Daar hoort infrastructuur bij, orchestratie, monitoring, en een rapportagelaag.

Aanpak

We bouwden het platform in fasen, waarbij elke fase direct waarde opleverde.

Fase 1: EPD Connector

De eerste stap was de patiëntdata ontsluiten. We bouwden een EPD Connector: een beveiligde site-to-site VPN-tunnel tussen het klinieknetwerk en Google Cloud, met een Cloud Run-service die dagelijks de relevante tabellen extraheert en naar BigQuery schrijft.

De connector draait elke ochtend vroeg, wanneer de belasting op het bronsysteem minimaal is. Data is beschikbaar vóór 7 uur - wanneer de eerste behandelaren beginnen.

Dit was het keerpunt. Voor het eerst had de kliniek haar eigen kopie van de patiëntdata, in een open, bevraagbaar formaat. Los van de EPD-leverancier.

Fase 2: Dataplatform op BigQuery

Met de EPD-data in BigQuery breidden we het platform uit naar meerdere bronnen. HR-data werd aangesloten voor personeelsanalyses, vragenlijstdata voor behandelevaluaties. BigQuery werd de centrale datastore - één plek waar alle bronnen samenkomen.

Bovenop de ruwe data bouwden we een dbt-transformatielaag. Hier worden de 51 patiëntparameters berekend uit de brondata. Elke transformatie is gedocumenteerd, getest, en versiebeheerd. Wanneer een domeinexpert een parameterdefinitie wijzigt, is de wijziging traceerbaar en reviewbaar.

Fase 3: Datakwaliteitsvalidatie

Dit was het moment dat het project van technisch naar wetenschappelijk kantelde.

Toen we de eerste parameterset berekend hadden, legden we de resultaten naast de uitkomsten van het oorspronkelijke script. Ze kwamen niet overeen.

De analyse die volgde was ontnuchterend:

• 220 patiënten hadden een incorrect berekende leeftijd. Het oorspronkelijke script gebruikte een andere afrondingsmethode dan de wetenschappelijke definitie voorschreef.
• 11 variabelen hadden een foutieve scoreaggregatie. Subtotalen werden anders berekend dan de vragenlijsthandleiding specificeerde.
• Meerdere conditionele variabelen maakten geen onderscheid tussen null en 0. Een patiënt die een vraag niet had beantwoord (null) werd gelijk behandeld als een patiënt die “0” had gescoord - terwijl dat fundamenteel verschillende situaties zijn.

Dit waren geen bugs in ons platform. Dit waren fouten die al in het oorspronkelijke script zaten - onzichtbaar zolang niemand de resultaten systematisch valideerde.

We ontwikkelden een formeel validatieprotocol. Elke parameter werd individueel gevalideerd tegen de wetenschappelijke brondefintie. Pas na goedkeuring door de domeinexpert ging een parameter naar productie.

De les: een ML-model is niet beter dan de data die erin gaat. Zonder rigoureuze validatie van de inputparameters is elke voorspelling onbetrouwbaar.

Fase 4: ML-platform

Met gevalideerde parameters bouwden we het ML-platform. De architectuur:

• scikit-learn modellen verpakt als Cloud Run Jobs - serverless, schaalbaar, en zonder permanente infrastructuurkosten.
• GCP Workflows als orchestratielaag - coördineert de dagelijkse pipeline van data-extractie tot modelvoorspelling.
• Resultaten naar BigQuery - prognoses worden teruggeschreven als tabellen, direct beschikbaar voor analyse.
• Power BI dashboards - onderzoekers benaderen de resultaten via Power BI, dat direct uit BigQuery leest.

Het hele traject - van EPD-extractie tot beschikbare prognose - draait dagelijks, volledig geautomatiseerd, met monitoring en alerting op elke stap.

Fase 5: Monitoring en beheer

Een productieplatform in de zorg moet betrouwbaar zijn. We implementeerden monitoring op meerdere niveaus:

• Pipelinemonitoring: draait de extractie? Komt er data binnen? Kloppen de volumes?
• Datakwaliteitschecks: vallen waarden buiten verwachte ranges? Zijn er onverwachte nulls?
• Modelmonitoring: produceren de modellen output? Wijken de resultaten significant af van historische patronen?

Bij afwijkingen volgt een alert. Niet de volgende dag, maar direct.

Resultaat

Patiëntdata ontsloten. Een EPD-systeem dat jarenlang een zwarte doos was, levert nu dagelijks gestructureerde data aan een centraal dataplatform. De kliniek is niet langer afhankelijk van de EPD-leverancier voor inzicht in eigen data.

ML-model in productie. Een wetenschappelijk model dat op een laptop leefde, draait nu als geautomatiseerde dagelijkse pipeline. Onderzoekers zien elke ochtend actuele behandelprognoses.

51 parameters gevalideerd. De datakwaliteitsvalidatie bracht structurele fouten aan het licht die al jaren in het oorspronkelijke script zaten. Elke parameter is nu individueel getest tegen de wetenschappelijke definitie.

Datagedreven behandelbeslissingen. Onderzoekers gebruiken het platform om behandelbeslissingen te onderbouwen. Niet als vervanging van klinische expertise, maar als aanvulling - een extra datapunt in een complex beslisproces.

Referentiecase voor uitrol. Het platform dient als blauwdruk voor vergelijkbare revalidatieklinieken. De architectuur is generiek genoeg om met andere EPD-systemen en andere ML-modellen te werken.

Van connector naar strategisch partnership. Wat begon als een technisch verzoek - “help ons data uit het EPD halen” - groeide uit tot een breed partnership. We beheren het platform, adviseren over datastrategiee, en denken mee over nieuwe toepassingen. De kliniek beschouwt ons als hun data-afdeling.

Wat dit laat zien

Healthcare data is moeilijk. EPD-systemen zijn gesloten, data is gevoelig, en de afstand tussen een wetenschappelijk model en een productieplatform is groter dan je denkt.

Maar de grootste valkuil zit niet in de techniek. Die zit in de aanname dat de data klopt. Zonder formele validatie - elke parameter, tegen de bron, gecontroleerd door een domeinexpert - bouw je een platform op drijfzand.

De technologie is bijzaak. BigQuery, dbt, Cloud Run, scikit-learn - het zijn gereedschappen. Het verschil zit in de discipline: data valideren voordat je er modellen op loslaat, en een platform bouwen dat niet alleen draait, maar ook betrouwbaar is.