5. Data-extractie en datamodel

5.1 Voor inferentieziekenhuizen: data-extractie voor het toepassen van het dagopnamenmodel

Om het model van AI ondersteuned coderen te trainen en toe te passen in verschillende ziekenhuizen is het van belang dat de data in alle ziekenhuizen in hetzelfde format worden aangeleverd.

Om deze reden wordt in dit hoofdstuk de data extractie en controles op data kwaliteit en volledigheid beschreven. Daarnaast wordt het datamodel uitgelicht waarin verwacht wordt dat de data wordt aangeleverd, zodat er geen problemen onstaan in het verwerken en trainen van data. Zo kan er uiteindelijk het beste resultaat uit het model gehaald worden.

5.1.1 Data-extractie voor toepassen dagopnamenmodel uit Chipsoft Hix

Met dank aan het Maasstad ziekenhuis kunnen we een script delen waarmee in het Maasstad Ziekenhuis (dat gebruik maakt van Chipsoft Hix 6.1 Standaard content) de extractie van de data heeft plaatsgevonden. Dankzij Diakonessenhuis Utrecht en Ziekenhuis Rijnstate is dit script ook herschreven voor Chipsoft Hix 6.2 en 6.3. De scripts zijn beschikbaar in bijlage F bij het draaiboek, op te vragen via ai-coderen@dhd.nl.

Elk extractiescript draait op de productiedatabase van HiX. Als het ziekenhuis gebruik maakt van Chipsoft HiX, dan zou dit script de data-extractie een stuk moeten kunnen vergemakkelijken. Het is echter geen garantie dat het automatisch de juiste gegevens uit het ZIS extraheert, dus een zorgvuldige controle (in samenwerking met een medisch codeur) blijft nodig. Het script stelt de tabellen samen die hieronder worden beschreven.

5.1.2 Data-extractie voor toepassen dagopnamenmodel uit Epic

Epic biedt sinds kort een functionaliteit aan die ziekenhuizen in staat stelt om de brongegevens die nodig zijn voor het gebruik van het dagopnamenmodel uit het ZIS te exporteren. Neem a.u.b. contact op met Epic voor meer informatie.

5.2 Voor trainingsziekenhuizen: data-extractie voor trainen van het dagopnamenmodel

Voor de training van het algoritme wordt gebruik gemaakt van de gegevens van 5 jaar aan dagopnamen. In samenspraak met de medisch codeurs van enkele deelnemende ziekenhuizen hebben we de volgende gegevens geselecteerd voor het trainen van het AI-model:

Gestructureerde gegevens

Behandelend specialisme
ICD-10 hoofddiagnose van de dagopname
De DBC-diagnosetypering die is vastgelegd bij het subtraject waarbinnen de dagopname is gedeclareerd
Leeftijd van de patiënt op het moment van opname
Opnamedatum
Opnametijd
Ontslagtijd
Geslacht van de patiënt
De zorgactiviteiten die tijdens de opname zijn uitgevoerd Ongestructureerde gegevens:
Ontslagbrieven
Polibrieven
Operatie (OK) verslagen
PA-verslagen
PCI/CAG verslagen
Scopie-verslagen

Het is de bedoeling dat alle trainingsziekenhuizen deze gegevens in gepseudonimiseerde vorm beschikbaar maken op hun trainingsserver.

Hoe pak ik de bronselectie aan?

Stap 1: De selectie van de dagopnamen

Allereerst is het van belang de juiste opnamen te selecteren. Hierbij kan worden uitgegaan van de geregistreerde zorgactiviteiten in de financiële administratie van het ziekenhuis. Selecteer alle patiëntnummers en subtraject-nummers waarvoor in de periode van 1-1-2015 tot en met 31-12-2021 zorgactiviteit 190090 (dagverpleging) is geregistreerd, de (Vektis) code voor het behandelend specialisme (bijvoorbeeld 0313 voor interne geneeskunde) en de datum waarop de dagverpleging heeft plaatsgevonden. De resulterende lijst met patiëntnummers, subtraject-nummers, specialismen en verrichtingsdatums geeft aan welke patiënten op welke datum in het ziekenhuis zijn geweest voor een dagopname. Het totale aantal dagopnamen op deze lijst kan worden vergeleken met het totale aantal dagopnamen in de LBZ, zodat kan worden nagegaan of de basis-selectie compleet is. Neem alsjeblieft contact op met het team AI-coderen bij DHD (ai-coderen@dhd.nl) als jullie hierover vragen hebben.

Stap 2: De selectie van de verdere benodigde gegevens uit de financiële administratie

In stap 1 is een lijst gemaakt van patiëntennummers, subtraject-nummers, verrichtingsdatums en uitvoerende specialismen. In stap 2 dient deze lijst te worden uitgebreid met de overige informatie die uit de financiële administratie kan worden gehaald: De ICD-10 code en de DBC diagnosetypering van het subtraject waarbinnen de dagopname is gedeclareerd, het geslacht van de patiënt, de leeftijd van de patiënt en de verrichtingen die tijdens de dagopnamen zijn uitgevoerd. Aan de hand van het nummer van het subtraject waarbinnen zorgactiviteit 190090 is vastgelegd kan het subtraject (de DBC / het zorgproduct) worden teruggevonden waarbinnen de dagopname is gedeclareerd bij de zorgverzekeraar. Bij elk gedeclareerd subtraject wordt het geslacht en de leeftijd van de patiënt en een ICD-10 en DBC-diagnosecode vastgelegd.

De ICD-10 code begint altijd met een letter, gevolgd door twee cijfers, en meestal eindigend op een punt en nog een cijfer (bijvoorbeeld H25.9). De ICD-10 code, de leeftijd en het geslacht van de patiënt dienen toegevoegd te worden aan de data export. De resulterende tabel (de opnametabel) bevat dan de volgende informatie:

Patiëntnummer
Subtraject-nummer
Verrichtingdatum (van verrichting 190090, dit is dus de opnamedatum)
Behandelend specialisme
ICD-10 code van het subtraject
De DBC-diagnosetypering van het subtraject
Geslacht van de patiënt
Leeftijd van de patiënt

Vervolgens dienen alle verrichtingen (zorgactiviteiten) te worden geselecteerd die tijdens de dagopname bij de patiënt zijn uitgevoerd. Om dit te bereiken dienen alle zorgactiviteitcodes te worden geselecteerd die op de opnamedatum bij de patiënt zijn uitgevoerd. Omdat dit er meerdere zijn per dagopname dienen deze in een aparte tabel te worden opgeslagen. Deze tabel (de verrichtingen tabel) bevat een regel per combinatie van patiëntennummer, opnamedatum en zorgactiviteitcode.

Stap 3: Verdere aanvulling van de opnametabel

De opnametabel is nu bijna compleet. We missen nu alleen nog de ICD-10 hoofddiagnosecode van de dagopnamen en de opname- en ontslagtijd. De hoofddiagnosen worden handmatig door de medisch codeurs vastgelegd. Het is voor dit project van zeer groot belang dat de juiste hoofddiagnosen (dat wil zeggen: de hoofddiagnosen die door de medisch codeur worden vastgelegd) in de data extractie worden meegenomen. Aan de hand van deze diagnosen willen we per slot van rekening het algoritme gaan trainen. De hoofddiagnosen kunnen aan de hand van het patiëntnummer en de opnamedatum worden gekoppeld aan de dagopnamen in de selectie die we in stap 1 hebben gemaakt.

Het uiteindelijke resultaat van stap 1 tot en met stap 3 bestaan uit twee tabellen: De opnametabel bevat 1 regel per dagopname. Hieronder staat een overzicht van de kolommen:

Patiëntennummer
Opnamenummer
Subtraject-nummer
Verrichtingdatum (van zorgactiviteit 190090, dit is dus de opnamedatum)
Opnametijd
Leeftijd van de patiënt
Geslacht van de patiënt
Behandelend specialisme (bij voorkeur de vektis code)
De DBC-diagnosetypering van het subtraject
ICD-10 code van het subtraject
ICD-10 hoofddiagnose van de dagopname

De verrichtingentabel bevat 1 regel per zorgactiviteit, per dagopname. Hieronder staat een overzicht van de kolommen:

Patiëntennummer
Opnamenummer
Verrichtingdatum (van zorgactiviteit 190090, dit is dus de opnamedatum)
Zorgactiviteitcode

Stap 4: De ongestructureerde gegevens

Medisch codeurs gebruiken in hun werk over het algemeen informatie die als vrije tekst wordt vastgelegd. Op basis van overleg met medisch codeurs uit enkele van de deelnemende ziekenhuizen en enkele steekproefsgewijze controles van de gebruikte broninformatie door de medisch codeurs, hebben we de belangrijkste “vrije tekst” bronnen geïdentificeerd. Dit zijn: (1) De ontslagbrieven; (2) de polibrieven; (3) de operatieverslagen; (4) en de PA-verslagen. Om voldoende informatie te hebben om het algoritme te trainen hebben we voor elke dagopname de beschikbare ontslagbrieven, polibrieven, operatie- en PA verslagen nodig. Naar aanleiding van de bevindingen in fase 2 van het project zijn daaraan toegevoegd 5) de scopie-verslagen voor het specialisme MDL en 6) de PCI en CAG verslagen voor het specialisme Cardiologie. Deze gegevens dienen te worden aangevuld met de informatie die nodig is om de brieven en verslagen te kunnen koppelen aan de opnamen: het patiëntennummer en de publicatiedatum van het document en het specialisme dat het document heeft gepubliceerd (of het onderzoek heeft aangevraagd, in het geval van de PA verslagen). We vragen de ziekenhuizen alle documenten in hun data extractie op te nemen die voldoen aan de volgende voorwaarden:

Het documenttype is ontslagbrief, polibrief, PA-verslag, OK-verslag, scopie-verslag, PCI-verslag of CAG-verslag.
Het document hoort bij een patiënt die voorkomt in de tabel met dagopnamen die is Stap 1 is samengesteld.
De publicatiedatum van het document ligt in de periode van 1 jaar voor de eerste opname van de patiënt in de dataset tot 8 weken na de laatste opname van de patiënt in de dataset.

De tabel met resultaten bevat één regel per document en de volgende kolommen:

Patiëntnummer
Opnamenummer
Type document (bv. “ontslagbrief” of “OK-verslag”)
Het specialisme dat het document heeft gepubliceerd (bij voorkeur de vektis code), of, in het geval het document een PA-verslag is, dan het specialisme dat het PA-onderzoek heeft aangevraagd.
Publicatiedatum van de brief of het verslag
Tekst van de brief of het verslag.

Uiteindelijk is het dus de bedoeling dat de data-extractie 3 tabellen oplevert: Een tabel met gegevens op het niveau van de individuele opname (met 1 regel per opname), een tabel met zorgactiviteiten (met 1 regel per zorgactiviteit) en een tabel met documenten (met 1 regel per document).

5.3 Controles op datakwaliteit en -volledigheid

Voor het slagen van het project is het van groot belang dat de data-extractie van de ongestructureerde brongegevens juist en volledig is. Met andere woorden, het is belangrijk dat we zeker weten dat 1) alle relevante dagopnamen en verrichtingen op de juiste manier in de data-extractie zijn opgenomen, 2) dat de ontslagbrieven, polibrieven, operatieverslagen en PA-verslagen in de data-extractie zijn gekoppeld aan de juiste patiënten en 3) dat er geen ontslagbrieven (etc.) ten onrechte niet in de data-extractie zijn opgenomen.

5.3.1 Controle van de gestructureerde gegevens in de data-extractie

De informatie in de tabellen met gestructureerde brongegevens (de opname- en verrichting tabellen) is ook aanwezig in de LBZ. Het is daardoor mogelijk om deze tabellen te controleren door ze te vergelijken met de gegevens in de LBZ. Neem contact op met het team AI-coderen bij DHD (ai-coderen@dhd.nl) als jullie behoefte hebben aan een vergelijking met de LBZ bij de controle van de opnamen en verrichtingen tabellen.

5.3.2 Controle van de ongestructureerde gegevens in de data-extractie

Aangezien de LBZ geen ongestructureerde gegevens bevat is het niet mogelijk om de extractie van de ontslag- en polibrieven en operatie- en PA-verslagen te controleren door middel van een vergelijking met de LBZ. Gelukkig hebben ziekenhuizen experts in dienst, die de analisten en IT’ers die de extractie hebben gedaan kunnen helpen bij de controle van hun werk: De medisch codeurs. Wij raden jullie sterk aan van hun expertise gebruik te maken bij deze controles. Medisch codeurs hebben binnen hun codeermodule toegang tot alle ongestructureerde gegevensbronnen die we binnen dit project gebruiken. Een controle van een steekproef van ongeveer 50 opnamen zou voldoende moeten zijn. Hierbij wordt gecontroleerd of alle brieven en verslagen die binnen de selectie zouden moeten vallen ook daadwerkelijk in de data-extractie zijn opgenomen.

5.4 De data-pseudonimisatie

Voordat de data aangelverd kan worden dient deze gepseudonimiseerd te worden. Pseudonimiseren betekent: het minimaliseren van herleidbaarheid van persoonsgegevens met zo min mogelijk verlies van relevante klinische informatie, maar waarbij de mogelijkheid om gegevens terug te herleiden wel blijft bestaan.

Zie ook de Pseudonimisatie - Explainer: Pseudonimisatie - Explainer.pdf

Waarom is pseudonimisatie van de gegevens belangrijk?

Voorkomen dat verwerkers van data (DHD in dit geval) onnodige informatie zien, bijv. bij analyses van de resultaten.
Voorkomen dat identificeerbare gegevens bij trainen van AI modellen worden gebruikt om te leren (alleen relevant voor trainingsziekenhuizen).
Impact van eventuele data-lekken minimaliseren (Noot: voor AI ondersteund coderen geldt dat door federatief werken data nooit het ziekenhuis verlaat!).

Goed om te weten

Er worden door DHD (nog) geen automatische checks gedaan op pseudonimisatie bij elke nieuwe aanlevering door een ziekenhuis.
Alleen bij de eerste aanlevering (eerste keer het AI-model toepassen) wordt gecontroleerd of de pseudonimisatie afdoende gedaan is.
Het ziekenhuis is dus in beginsel zelf verantwoordelijk voor adequate pseudonimisatie.
Trainingsdata worden vaker en uitgebreider door DHD gecontroleerd (alleen relevant voor trainingsziekenhuizen).

Algemene vereisten voor pseudonimisatie

Er zijn 4 soorten gegevens om te bekijken bij pseudonimiseren:

Direct identificerende gegevens:
- Gegevens die op zichzelf voldoende uniek zijn om een persoon direct te identificeren, zoals naam, adres, geboortedatum of BSN.
- Deze gegevens dienen verwijderd te worden of vervangen te worden door algemene tekst, bijv. [naam], [bsn] etc.
Indirect identificerende gegevens:
- Gegevens die in combinatie met andere informatie tot een persoon te herleiden zijn, zoals patiëntnummer, opnamenummer of IP-adres.
- Deze gegevens dienen gegeneraliseerd, versluierd of verwijderd te worden (bijv. postcode alleen eerste 3 cijfers, alleen geboortejaar ipv geboortedatum etc.)
Gestructureerde data
- Gegevens in vaste, vooraf gedefinieerde vormen zoals kolommen en tabellen, waarbij de structuur duidelijk is en elke variabele op een consistente plek staat (bijv. geboortedatum‑kolom, patiëntnummer‑kolom).
- Identificeerbare gegevens dienen verwijderd te worden of vervangen te worden door algemene tekst (bijv. [naam], [adres] etc.) Eventueel wordt 1 kolom versleuteld om re-identificatie mogelijk te maken.
Ongestructureerde data
- Vrije tekst zonder vaste structuur, zoals brieven, verslagen of notities, waarin informatie in doorlopende tekst voorkomt en identificerende gegevens handmatig of via algoritmes moeten worden opgespoord.
- Identificeerbare gegevens dienen verwijderd te worden, of vervangen door algemene tekst (bijv. [naam], [telnr] etc.). Eventueel wordt 1 gegeven versleuteld om re-identificatie mogelijk te maken.

Welke gegevens moeten worden bewerkt binnen AI ondersteund coderen?

Concreet betekent dit dat voor de aan te leveren data de volgende gegevens gepseudonimiseerd dienen te worden door het ziekenhuis:

Gegevens die verplicht bewerkt dienen te worden

Type Identifier	Vervangen door
voornaam, achternaam, roepnaam, voorletter	[naam]
woonplaats, straat	[adres]
telefoonnummer	[telnr]
emailadres	[email]
BSN-nummer	[bsn]
geboortedatum	[gebdatum]
patientnummer	[patnr]
achternaam, roepnaam, voornaam, geboortedatum etc. ouder, partner, kind	[ouder]

Gegevens die bewerkt kunnen worden, maar niet verplicht zijn:

Type Identifier	Vervangen door
gegevens huisarts (achternaam, roepnaam, voornaam)	[huisarts]
gegevens ondergetekende/arts (achternaam, roepnaam, voornaam)	[schrijver]

Ondersteunende scripts

De data-extractiescripts van het Maasstad ziekenhuis, Diakonessenhuis Utrecht en Ziekenhuis Rijnstate voorzien ook in de pseudonimisatie van de brongegevens en zou in de ziekenhuizen die gebruik maken van Chipsoft HiX zonder veel wijzigingen moeten werken. Ook is er een pseudonimisatiescript beschikbaar voor EPIC ziekenhuizen, gemaakt door het ETZ. Voor ziekenhuizen met een andere EPD leverancier kan het script dienen als voorbeeld bij het schrijven van het eigen pseudonimisatiescript. In de overeenkomst is vastgelegd dat training- als inferentieziekenhuizen hun data moeten pseudonimiseren voordat deze op de train- of inferentieserver wordt geplaatst.

Risico’s en aanbevelingen

Het is belanrgijk om te beseffen dat de methodes en algoritmes in bovengenoemde scripts krachtig zijn, maar niet waterdicht. Er is altijd een risico op fouten, vooral bij complexe of onverwachte tekst. Handmatige controle, verfijnde patronen en goede testcases zijn belangrijk om deze risico’s te beperken.

Daarom de volgende aanbevelingen:

Voer een validatie uit op een steekproef. Hoe goed presteert de gekozen methode, hoeveel en welke fouten worden gemaakt?
Voer een risicoanalyse uit op herleidbaarheid. Welke indirecte gegevens kunnen samen tot identificatie leiden? Hoeveel en welke fouten vinden we acceptabel?
Documenteer het pseudonimisatieproces. Welke stappen zijn gevolgd, hoe is de validatie gedaan?
Als het foutenpercentage te hoog gevonden wordt: combineer regex/stringbased methodes met methodes die ook naar context kijken, bijvoorbeeld Named Entity Recognition (NER; NLP-gebaseerd) om persoonsnamen, locaties en datums robuuster te detecteren. Dit zijn echter behoorlijk bewerkelijke methodes om in te richten.

Mocht er behoefte zijn aan contact over het pseudonimisatieproces, neem contact op met ai-coderen@dhd.nl.

5.5 Inlezen, verwerken en aanleveren in Epic en Chipsoft HiX (6.3)

Om het gebruik van het codeermodel optimaal te faciliteren, hebben we implementatieafspraken gemaakt met de twee grootste ZIS-leveranciers. Epic en ChipSoft (vanaf Hix 6.3) hebben het mogelijk gemaakt de output van het model in te lezen en automatisch de ICD-10-codes over te nemen die met een hoge mate van zekerheid gecodeerd konden worden. Voor de opnamen die het model niet eenduidig kan coderen, genereert het model codeersuggesties. Deze ontwikkelingen besparen de codeur veel tijd. Bovengenoemde functionaliteit is een standaard onderdeel van Epic. Bij Chipsoft wordt dit aangeboden als een aparte dienst. Geïnteresseerde ziekenhuizen kunnen contact opnemen met de accountmanager Chipsoft om een offerte op te vragen.

Naast ziekenhuizen die ChipSoft en EPIC als EPD leverancier hebben zijn er ook Nexus ziekenhuizen aangesloten bij AI ondersteund coderen.

5.6 Datamodel

5.6.0 Opnametabel

Bestandsnaam: opnames.csv

Veldnaam	Definitie van variabele	Format	Lengte	Classificatie	Verplicht	Missing	Onbekend	Range	Controles
patient_id	Binnen de instelling waar de zorg is verleend gepseudonymiseerde/versleutelde unieke identificatie van de patiënt	Alfanum	32		Ja	nvt	nvt
admission_id	Binnen de instellingen waar de zorg is verleend gegenereerd opnamenummer	Alfanum	32		Ja	nvt	nvt
subtraject_id	Per instelling en organisatie onderdeel unieke identificatie van het subtraject	Alfanum	15		Ja	nvt	nvt
admission_date	Datum van start opname	JJJJ-MM-DD	10		Ja	nvt	nvt
discharge_date	Datum van ontslag opname	JJJJ-MM-DD	10		Ja	nvt	nvt
admission_time	Tijd van start opname	HH:MM	5		Opt	nvt		[00-23]:[00-59]	Moet voldoen aan range
discharge_time	Tijd van ontslag	HH:MM	5		Opt	nvt		[00-23]:[00-59]	Moet voldoen aan range
age	Leeftijd in jaren van de patiënt op het moment van opname	Numeriek	3		Ja	nvt	nvt
gender	Geslacht van de patiënt	Numeriek	1	COD046- VEKT (zie: https://www.vektis.nl/standaardisatie/codelijsten/COD046-NEN)	Ja	nvt	nvt	0 = onbekend; 1 = mannelijk; 2 = vrouwelijk; 3 = overig	Moet voldoen aan codelijst
specialty_code	DBC typerende specialismecode	Alfanum	4	Elektronische Typeringslijst (zie: https://puc.overheid.nl/nza/doc/PUC_639938_22/1/)	Ja	nvt	nvt
dbc_diagnosis_code	DBC typerende diagnose	Alfanum	10	Elektronische Typeringslijst (zie: https://puc.overheid.nl/nza/doc/PUC_639938_22/1/)	Ja	nvt	nvt		Combinatie met behandeld specialisme (specialty_code) moet voorkomen in elektronische typeringslijst.
icd10_subtraject_code	ICD-10 diagnose code van het subtraject	Alfanum	7	ICD-10 NL (Zie: https://terminologie.nictiz.nl/art-decor/claml?collection=icd10-nl-data)	Ja	nvt	nvt		Moet voldoen aan codelijst
icd10_main_code	Hoofd icd10-diagnose van de dagopnamen	Alfanum	10	ICD-10, versie 2014	Nee*	nvt	nvt		*Bij trainingsdata is het wel verplicht

5.6.1 Verrichtingentabel

Bestandsnaam: verrichtingen.csv

Veldnaam	Definitie van variabele	Format	Lengte	Classificatie	Verplicht	Missing	Onbekend	Controles
patient_id	Binnen de instelling waar de zorg is verleend gepseudonymiseerde/versleutelde unieke identificatie van de patiënt	Alfanum	32		Ja	nvt	nvt
admission_id	Binnen de instellingen waar de zorg is verleend gegenereerd opnamenummer	Alfanum	32		Ja	nvt	nvt
procedure_date	Datum waarop de verrichting is gestart c.q. de datum waarop de patiënt de OK ruimte is binnengekomen	JJJJ-MM-DD	10		Ja	nvt	nvt
za_code	Zorgactiviteit code van de uitgevoerde verrichting	Alfanum	10	Zie: https://opendisdata.nza.nl/#zorgactiviteit	Ja	nvt	nvt	Moet voldoen aan codelijst

5.6.2 BrievenVerslagen

Bestandsnaam: documenten.csv

Veldnaam	Definitie van variabele	Format	Lengte	Classificatie	Verplicht	Missing	Onbekend	Range	Controles
patient_id	Binnen de instelling waar de zorg is verleend gepseudonymiseerde/versleutelde unieke identificatie van de patiënt	Alfanum	32		Ja	nvt	nvt
admission_id	Binnen de instellingen waar de zorg is verleend gegenereerd opnamenummer indien beschikbaar	Alfanum	32		Opt	nvt
document_type	Het type document, bijv. ontslagbrief of OK-verslag	Alfanum	32		Ja	nvt	nvt	“ontslag”, “ok”, “poli”, “pa”, “scopie”	Moet voldoen aan range
publication_specialty	Het specialisme dat het document heeft gepubliceerd, of het specialisme wat PA-onderzoek heeft aangevraagd	Numeriek	6	COD016- VEKT (zie: https://www.vektis.nl/standaardisatie/codelijsten/COD016-VEKT)	Ja	nvt	nvt		Moet voldoen aan codelijst
publication_date	De publicatiedatum van de brief of het verslag	JJJJ-MM-DD	10		Ja	nvt	nvt
text	De tekst van de brief / verslag	Alfanum	50000		Ja	nvt	nvt