GCP als fundament voor healthcare analytics: architectuurkeuzes die ertoe doen

Wanneer een zorgorganisatie dagelijks 43 miljoen rijen data verwerkt voor analytische rapportages, wordt elke architectuurkeuze een financiële en operationele beslissing. Dit is het verhaal van hoe we een healthcare analytics platform bouwden op Google Cloud - en wat we onderweg leerden.

Waarom BigQuery als fundament

De keuze voor BigQuery was geen moeilijke. Drie eigenschappen maken het ideaal voor healthcare analytics:

Serverless. Geen clusters beheren, geen capaciteitsplanning. Data erin, queries erop, klaar. Voor een organisatie die zich moet focussen op zorgprocessen - niet op infrastructuur - is dat essentieel.

Schaalbaarheid zonder plafond. De dataset groeide van 8 miljoen naar 43 miljoen rijen in zes maanden. BigQuery merkte het verschil niet. Geen herindexering, geen partitie-aanpassingen, geen nachtelijke onderhoudsjobs.

Directe Power BI integratie. De eindgebruikers werkten al in Power BI. Via de BigQuery ODBC-connector konden analisten hun eigen rapporten bouwen zonder tussenkomst van ons. Dat is belangrijk: een platform dat afhankelijkheid creëert is geen goed platform.

Cloud Run Jobs boven Cloud Functions

Voor de batchverwerking van ML-modellen kozen we bewust voor Cloud Run Jobs in plaats van Cloud Functions. De reden is simpel: betrouwbaarheid bij langlopende taken.

Cloud Functions hebben een maximale timeout van 9 minuten (2e generatie: 60 minuten). Onze ML-batchjobs duren soms 20-40 minuten, afhankelijk van datavolume. Cloud Run Jobs ondersteunen timeouts tot 24 uur en bieden betere controle over geheugen en CPU-allocatie.

Daarnaast: Cloud Run Jobs draaien als container. Dat betekent dat we lokaal exact dezelfde omgeving kunnen reproduceren voor debugging. Bij Cloud Functions ben je afhankelijker van logging en trial-and-error. Voor een healthcare-context waar je resultaten moet kunnen verantwoorden, is reproduceerbaarheid geen luxe.

Orchestratie met GCP Workflows

Een pipeline is meer dan losse componenten. De EPD-export moet klaar zijn voordat dbt transformeert. dbt moet klaar zijn voordat het ML-model draait. En het ML-model moet klaar zijn voordat Power BI refresht.

GCP Workflows bleek hiervoor precies het juiste niveau van complexiteit. Het is geen Airflow - je hebt geen DAG-server nodig, geen scheduler te beheren, geen Python-code te schrijven voor je orchestratie. Het is een YAML-definitie die stappen sequentieel of parallel uitvoert, met ingebouwde retry-logica en foutafhandeling.

Een typische workflow bij ons:

1. Cloud Run Job: EPD-data exporteren naar BigQuery
2. Wacht op voltooiing - Workflows pollt de jobstatus
3. dbt run: transformaties en tests uitvoeren
4. Cloud Run Job: ML-model draaien op getransformeerde data
5. Resultaten schrijven naar BigQuery-resultatentabellen

Als stap 3 faalt, draait stap 4 niet. Klinkt triviaal, maar zonder orchestratie is dit precies waar pipelines stilletjes fout gaan.

De ORDER BY les: kosten die je niet verwacht

Een kleine anekdote. Een BigQuery-query die data leverde aan Power BI bevatte een ORDER BY-clausule op 43 miljoen rijen. In de testomgeving werkte dat prima. Maar in productie, gecombineerd met een aantal views, liep de query vast. Te veel compute, te veel tijd.

De oplossing was simpel: de ORDER BY eruit. Power BI gebruikt immers zijn eigen sortering bij het importeren van data. De sortering in BigQuery was overbodig werk.

De les: aannames die in een testomgeving onzichtbaar zijn, worden in productie een probleem. En optimalisatie begint met de vraag: welk werk is daadwerkelijk nodig?

Monitoring: Cloud Logging als vangnet

Bij healthcare data is een stille fout erger dan een luide crash. Als een EPD-export faalt maar niemand het merkt, werken analisten met verouderde data - zonder het te weten.

We implementeerden monitoring op drie niveaus:

• Exportvalidatie: Cloud Run Jobs loggen het aantal geexporteerde rijen. Een afwijking van meer dan 10% ten opzichte van de vorige run triggert een alert.
• dbt test failures: elke dbt-run bevat data quality tests. Failures gaan direct naar ons monitoringkanaal.
• Workflow-niveau: als een stap in de Workflow faalt, krijgen we binnen 2 minuten een notificatie via Cloud Logging + alerting policies.

De investering in monitoring betaalde zich binnen twee weken terug. Een wijziging in het EPD-bronssysteem veroorzaakte een schema-mismatch die we binnen een uur detecteerden - in plaats van na drie dagen wanneer een analist had gevraagd waarom de cijfers niet klopten.

Architectuurkeuzes als strategie

De keuzes die we hier beschrijven - BigQuery, Cloud Run Jobs, GCP Workflows, Cloud Logging - zijn geen technologische voorkeuren. Het zijn antwoorden op concrete vragen: hoe schalen we zonder operationele last? Hoe garanderen we betrouwbaarheid bij langlopende taken? Hoe voorkomen we stille fouten?

Voor organisaties in de gezondheidszorg die analytics willen opschalen op Google Cloud & Azure: begin bij de orchestratie en de monitoring. De compute en opslag lossen zichzelf op. De fouten die niemand ziet, niet.