De onzichtbare fundering: Datakwaliteit

Garbage In, Garbage Out.

Het is waarschijnlijk de bekendste uitspraak in ons vakgebied. En ook de meest genegeerde.

Iedereen knikt als je hem noemt. En daarna gaat iedereen gewoon door met wat ze deden. Want GIGO is zo’n waarheid die zo vanzelfsprekend klinkt, dat niemand er echt bij stilstaat wat het in de praktijk betekent.

Wat betekent het als de invoer rammelt? Niet abstract, maar concreet. Welke beslissingen worden er dan genomen op basis van verkeerde informatie? En wie is er eigenlijk verantwoordelijk voor als dat misgaat?

In de zorg is de inzet extra hoog. Een fout in een dashboard is vervelend. Een fout in een medicatiedossier of een kwaliteitsregistratie kan gevaarlijk zijn. En toch gaan we er blind van uit dat de data die erin gaat, klopt. Maar slechte datakwaliteit heeft ook directe gevolgen op de werkvloer, los van rapportages en declaraties. Als de bedbezetting niet klopt, stuur je mensen naar een afdeling die vol blijkt te zijn. Als medicatiegegevens niet kloppen, neemt de verpleegkundige beslissingen op basis van een verkeerd beeld. Als de OK-planning gebaseerd is op onjuiste voorinformatie, loopt de hele dag in de soep. Slechte data is dus niet alleen een probleem voor het management dat wil sturen — het is een probleem voor iedereen die er dagelijks mee werkt.

Welkom bij Data met impact. De podcast over de zin en onzin van data, mensen en techniek. Ik ben Jeroen Buisman, en met InfoReports help ik organisaties die maatschappelijke impact maken — zoals ziekenhuizen — om grip te krijgen op hun informatie. Niet alleen de dashboards en de tools, maar het hele fundament daaronder.

Vandaag gaan we het hebben over datakwaliteit. Niet als technisch begrip, maar als fundament. We kijken naar wat datakwaliteit écht is, waar het misgaat, en — misschien wel het belangrijkste — wie er nu eigenlijk voor verantwoordelijk is. De voorbeelden die ik gebruik komen uit de zorg, want dat is het domein waar ik dagelijks in werk. Maar de principes gelden voor elke organisatie die met data stuurt. Of je nu een ziekenhuis bent, een gemeente, of een commercieel bedrijf: de uitdagingen zijn verrassend universeel.

Want de verantwoordelijkheidsvraag — wie is er eigenlijk verantwoordelijk als data niet klopt — dat is waar het in de meeste organisaties volledig de mist in gaat.

Laten we beginnen met een definitie. Want ‘datakwaliteit’ is zo’n term die iedereen gebruikt, maar die voor iedereen iets anders betekent.

In de meest gangbare technische benadering gaat het om dingen als: zijn er geen lege velden? Zijn de formats consistent? Zitten er geen dubbele records in? Dat zijn valide vragen, maar ze raken slechts de oppervlakte.

De definitie die ik veel nuttiger vind, is: Fitness for Use. Is de data geschikt voor het doel waarvoor je hem gebruikt? Dat klinkt simpel, maar het heeft een enorme implicatie. Het betekent namelijk dat datakwaliteit geen absoluut begrip is. Data kan prima zijn voor het ene doel, en totaal ongeschikt voor het andere.

Neem een voorbeeld. In veel ziekenhuizen wordt bij een opname een hoofddiagnose geregistreerd. Die registratie is bedoeld voor de zorgadministratie en de declaratie. Ze wordt ingevuld door de arts, of soms door de coder achteraf, met de declaratie als doel. Is die registratie van hoge kwaliteit voor het facturatieproces? Waarschijnlijk wel. Is die registratie geschikt om uitspraken te doen over de medische case-mix van een afdeling? Dat is een stuk minder zeker. De data is ingekleurd door het declaratiedoel, niet door het medische doel.

Dit is een belangrijk inzicht: de context van de registratie bepaalt mede de bruikbaarheid van de data. En als je die context niet kent, maak je aannames. En aannames, dat weten we inmiddels, zijn gevaarlijk.

Er zijn een aantal dimensies waarlangs je datakwaliteit kunt beoordelen. Ik noem er drie die ik in de praktijk het meest relevant vind.

De eerste is volledigheid. Staat er alles in wat er in zou moeten staan? Dit gaat niet alleen over lege velden. Het gaat ook over de vraag: registreren we de juiste dingen überhaupt? Als een bepaalde handeling structureel niet wordt vastgelegd, omdat het systeem daar geen plek voor heeft of omdat het proces dat niet vraagt, dan is er een blinde vlek in je data die je nooit ziet.

De tweede is tijdigheid. Is de data actueel genoeg voor het doel? Een rapportage over patiëntveiligheidsincidenten die een maand oud is, heeft beperkte waarde voor sturing. Een bedbezettingsoverzicht dat pas de volgende ochtend beschikbaar is, helpt de nachtdienst niet. Tijdigheid is geen technisch probleem — het is een procesprobleem.

De derde is consistentie. Zegt systeem A hetzelfde als systeem B? Dit is in de zorg een bijzonder hardnekkig probleem. Een patiënt beweegt door meerdere systemen: het EPD, het OK-planningssysteem, het verpleegkundig dossier, de financiële administratie. Al die systemen hebben een eigen registratielogica, eigen codes, eigen tijdstippen. En als je die systemen aan elkaar probeert te koppelen, kom je vrijwel altijd inconsistenties tegen.

Er is één specifiek patroon dat ik in ziekenhuizen keer op keer tegenkom, en dat wil ik wat uitgebreider bespreken. Ik noem het de declaratiebril.

In veel zorginstellingen is datakwaliteit historisch gezien synoniem geworden met declaratiekwaliteit. De zorgadministratie controleert of de registraties kloppen, zodat de zorgverzekeraar geen reden heeft om te weigeren of terug te vorderen. Dat is een legitiem en belangrijk doel. Maar het heeft een bijwerking.

De data wordt geoptimaliseerd voor de factuur. Codes worden aangevuld, gecorrigeerd, soms herschreven. Niet frauduleus, maar wel gericht op één specifiek doel. En het gevolg is dat de ‘administratieve werkelijkheid’ steeds verder af kan komen te staan van de ‘medische werkelijkheid’.

Wat staat er in het EPD? Wat de arts heeft genoteerd, in de taal van de kliniek. Wat staat er in de financiële rapportage? Wat de zorgadministratie heeft gecorrigeerd, in de taal van de DBC. Die twee hoeven niet gelijk te zijn. En als een BI-afdeling een kwaliteitsindicator bouwt op basis van declaratiedata, dan meet die indicator feitelijk de declaratiekwaliteit — niet de zorgkwaliteit.

Dit is, als je het zo bekijkt, een variant op Goodhart’s Law die we in de vorige aflevering bespraken: je optimaliseert voor de maatstaf, in dit geval de declaratie, en raakt daarmee de onderliggende werkelijkheid kwijt.

De vraag die je jezelf moet stellen bij elke databron: waarvoor is deze data oorspronkelijk geregistreerd? Wat was het doel van degene die dit invulde? En sluit dat doel aan op het doel waarvoor ik de data nu gebruik?

Als die twee doelen niet overeenkomen, heb je een kwaliteitsprobleem — ook al zijn alle velden netjes ingevuld en zit er geen spelfout in.

Tot nu toe hebben we het vooral over structurele problemen gehad: de verkeerde bril, de verkeerde definitie. Maar er is ook een tweede categorie fouten in datakwaliteit, en dat zijn de fouten die niemand ziet aankomen.

Ik maak onderscheid tussen twee soorten.

De eerste zijn technische fouten. Bugs in applicaties, migratiefouten uit het verleden, workarounds die een eigen leven zijn gaan leiden. Iets dat in het systeem technisch niet mogelijk leek, maar toch in de database staat. Ik heb in de loop van mijn carrière geleerd: als iemand me zegt dat iets nooit voorkomt in een database, geef me dan vijf minuten. Ik geef je de tegenvoorbeelden.

Registratiesystemen hebben een lange geschiedenis van patches, aanpassingen, versie-upgrades en datamigaties. Elke overgang laat sporen na. Data die in het oude systeem logisch was, kan in het nieuwe systeem raar worden. Codes die werden omgezet, maar niet helemaal goed. Relaties die verloren gingen. Tijdstempels die verschoven.

De tweede categorie is wat ik logische fouten noem, of in het Engels: clinical logic errors. Dit zijn registraties die technisch correct zijn — het veld is ingevuld, het format klopt — maar die inhoudelijk onmogelijk zijn. Een ingreep die alleen bij mannen voorkomt, geregistreerd bij een vrouwelijke patiënt. Een geriatrisch zorgpad gestart bij een kind. Een ontslagdatum die vóór de opnamedatum ligt.

Hoe ontstaan die fouten? Soms is het een tikfout. Soms is het een verkeerde selectie in een keuzelijst. Soms is het een systeemfout bij een koppeling. En soms is het een workaround: een zorgverlener die een veld invult op een manier die het systeem accepteert, maar die inhoudelijk niet klopt, omdat er geen betere optie beschikbaar was.

Het gevaarlijke van beide categorieën is dat ze onzichtbaar zijn als je er niet actief naar zoekt. Een dashboard toont cijfers. Het toont niet welke onderliggende records logisch onmogelijk zijn. Dat moet je zelf uitzoeken.

En dat brengt me bij de kernvraag van deze aflevering: wie doet dat dan?

In veel organisaties is de BI-afdeling het eindstation van de data. De plek waar alle bronnen samenkomen, worden gecombineerd, en worden omgezet in rapportages en dashboards.

En daarmee is de BI-afdeling ook de plek die als eerste ziet wanneer er iets niet klopt. Een veld dat altijd leeg is. Een koppeling die inconsistenties oplevert. Een code die in systeem A bestaat, maar niet in systeem B.

Wat doet een BI-afdeling in zo’n geval? In veel organisaties: het probleem oplossen in het ETL-proces. Dat is de technische stap waarbij data uit de bronnen wordt geladen, getransformeerd en klaargemaakt voor rapportage. Je filtert de onmogelijke records eruit. Je vult lege velden in met een standaardwaarde. Je maakt een vertaaltabel voor de inconsistente codes.

En het dashboard ziet er netjes uit. Het management ziet schone cijfers. Het probleem lijkt opgelost.

Maar het is niet opgelost. Het is weggemoffeld. De fout zit nog steeds in de bronregistratie. De zorgverlener die de verkeerde code invoert, krijgt geen terugkoppeling. Het systeem dat logisch onmogelijke combinaties toestaat, wordt niet aangepast. En de BI-afdeling blijft elke maand dezelfde fouten wegwerken.

Dat is de rol van poetser. En het is een rol waar je als BI-afdeling vroeg of laat in vast komt te zitten als je niet oppast.

De alternatieve rol is die van poortwachter. En die ziet er fundamenteel anders uit.

Een poortwachter lost het probleem niet op in het ETL-proces. Een poortwachter signaleert het probleem, maakt het zichtbaar, en legt het terug bij de bron. Niet om moeilijk te doen, maar omdat dat de enige manier is waarop de kwaliteit structureel verbetert.

Dat vraagt om een andere mindset — en eerlijk gezegd ook om lef. Want het betekent dat je soms een rapportage oplevert met een noot erbij: ‘Dit cijfer klopt niet, omdat we zien dat 12% van de records een logisch onmogelijke waarde heeft. We leggen dit probleem terug bij de afdeling X, zodat het aan de bron kan worden opgelost.’

Dat is een ongemakkelijke boodschap. Maar het is de juiste boodschap. Want als je het wegpoetst, verdwijnt de pijn bij degene die de fout maakt. En zonder pijn is er geen reden om te veranderen.

De poortwachterrol werkt alleen als er goede feedback loops zijn. En dat is precies waar het in de meeste organisaties aan ontbreekt.

Een feedback loop betekent: de persoon die de data invoert, krijgt tijdig te horen of die invoer correct was. Niet maanden later, als de BI-afdeling bij toeval een anomalie ontdekt. Maar bij voorkeur direct, of in ieder geval snel genoeg dat het nog relevant is.

Dat stelt eisen aan zowel het proces als het systeem. Aan het systeem: automatische validatie op het moment van invoer. Als een arts een code invoert die logisch onmogelijk is, geeft het systeem een melding. Niet blokkeren — want dat leidt alleen maar tot meer workarounds — maar signaleren. Vragen: ‘Klopt dit? Want dit combinatie zien we zelden.’

Aan het proces: structurele terugkoppeling vanuit de BI-afdeling naar de werkvloer. Niet in de vorm van een jaarlijkse audit, maar als een reguliere cyclus. Een kort maandelijks overzicht: dit zijn de top-5 datakwaliteitsproblemen die we deze maand hebben gezien, dit is de afdeling of het systeem waar ze vandaan komen.

Er is nog een tweede aspect van de poortwachterrol dat ik wil benoemen, en dat is ketenbewaking. De BI-afdeling is in veel organisaties de enige partij die over alle systemen heen kijkt. De arts kent het EPD. De planner kent het OK-systeem. De controller kent de financiële administratie. Maar wie ziet de relatie tussen die drie?

De BI-afdeling ziet dat. En daarmee heeft ze een unieke positie om inconsistenties te signaleren die voor individuele afdelingen onzichtbaar zijn. Een operatie die in het OK-systeem staat als uitgevoerd, maar in het EPD niet als zodanig is vastgelegd. Een patiënt die in de kliniek ligt, maar waarvan de opname in de financiële administratie nog niet is geregistreerd.

Dat soort inconsistenties zijn niet het probleem van één afdeling. Ze zijn het gevolg van processen die niet goed op elkaar aansluiten. En de BI-afdeling is de aangewezen partij om dat zichtbaar te maken — niet om het zelf op te lossen, maar om het op de agenda te zetten.

Dan komen we bij de vraag die in de meeste organisaties het minst expliciet wordt beantwoord: wie is er eigenlijk verantwoordelijk voor datakwaliteit?

Het antwoord dat ik vaak hoor is: de BI-afdeling, of IT, of de zorgadministratie. Maar dat is een gevaarlijk antwoord. Want als datakwaliteit de verantwoordelijkheid is van een ondersteunende afdeling, dan is het de impliciete boodschap aan de werkvloer dat zij er niet voor verantwoordelijk zijn.

En dat klopt niet. De kwaliteit van de data begint bij de persoon die de data invoert. De arts die de diagnose registreert. De verpleegkundige die het tijdstip van een handeling vastlegt. De planner die een patiënt inboekt. Die mensen zijn de bron. En als de bron rommelig is, is de rest van de keten dat ook.

Dat wil niet zeggen dat de verantwoordelijkheid alleen bij de werkvloer ligt. Integendeel. De organisatie heeft de plicht om systemen te bieden die goede registratie mogelijk maken. Processen die registratie integreren in het werkproces, in plaats van er een extra stap van te maken. En een cultuur waarin het belang van goede data wordt gezien en erkend — niet als bureaucratie, maar als onderdeel van goede zorg en goede bedrijfsvoering.

Datakwaliteit is daarmee geen IT-feestje. Het is een organisatievraagstuk. Het vraagt betrokkenheid van de werkvloer, van het management, van de systeemleveranciers, en van de BI-afdeling als verbindende schakel.

En het vraagt leiderschap. Iemand die het onderwerp eigenaarschap geeft. Die zegt: wij vinden dit belangrijk, wij investeren hierin, en wij koppelen terug als het niet goed gaat.

Zonder dat eigenaarschap blijft datakwaliteit een thema dat iedereen belangrijk vindt en niemand aanpakt.

We komen aan het einde van deze aflevering.

Garbage In, Garbage Out. We begonnen ermee. En het blijft een waarheid die eenvoudiger klinkt dan hij is.

Want GIGO gaat niet alleen over tikfouten en lege velden. Het gaat over de context van registratie, over de bril waarmee data wordt ingevoerd, over de inconsistenties die ontstaan als systemen niet met elkaar communiceren. En het gaat over de keuze die de BI-afdeling elke dag maakt: lossen we dit stilletjes op, of maken we het zichtbaar?

Stop met dweilen in het ETL-proces. Ga naar de kraan. Niet om moeilijk te doen, maar omdat structurele verbetering alleen ontstaat als het probleem daar wordt opgelost waar het begint.

En doe dat niet alleen. Datakwaliteit is een gedeelde verantwoordelijkheid. Van de werkvloer die invoert, van het management dat prioriteert, van de systemen die ondersteunen, en van de BI-afdeling die verbindt en bewaakt.

De mooiste analyses, de meest geavanceerde dashboards, de slimste algoritmes — ze zijn allemaal gebouwd op een fundament. En als dat fundament rot is, bouw je kastelen op drijfzand.

Zorg dat je weet hoe stevig jouw fundament is.

Jeroen: En dat brengt me bij de kern van waar we het in deze podcast steeds over hebben. Data geeft antwoorden. Maar die antwoorden zijn waardeloos als de data zelf niet klopt. Dus voordat je de volgende vraag stelt, stel dan eerst de vraag die eraan voorafgaat: klopt wat erin gaat eigenlijk wel?

Want onthoud: een goed antwoord begint altijd met een betere vraag.

Bedankt voor het luisteren. Vond je deze aflevering waardevol? Abonneer je dan op de podcast, en deel hem met iemand die dit ook zou moeten horen. Wil je weten hoe wij organisaties helpen aan een stevig datafundament? Kijk dan op inforeports.nl. Tot de volgende keer!