Category: zibs

Posted on

Van BasisGegevensset Zorg naar International Patient Summary

(English version here)

Op de 37e HL7 Working Group Meeting in Phoenix heb ik namens Stichting HL7 Nederland deelgenomen aan de FHIR Connectathon. Mijn doel was onze Nederlandse Basisgegevensset Zorg (BgZ) te vergelijken met de International Patient Summary (IPS). Niet alleen op functioneel niveau maar ook op het echte uitwisselformaat –de IPS in FHIR. Ik neem al enige tijd deel aan de IPS FHIR Working Group en dit was een mooie gelegenheid eens te kijken hoe ver we zijn – of niet natuurlijk.

Nederland gaat voorlopig nog geen gebruik maken van de FHIR IPS. Europees is er vooralsnog gekozen voor de Europese Patient Summary in CDA. Die lijkt veel op de IPS, maar is op details anders. Europa en de USA, en veel andere landen, zijn het er wel over eens dat we moeten op termijn migreren naar een en dezelfde standaard. Dat zal de FHIR IPS worden.

Het goede nieuws: een IPS aanmaken vanuit een BgZ is relatief eenvoudig, en redelijk compleet. Daarbij aangetekend, uiteraard, dat er op detailniveau wel de nodige verschillen zijn. Laten we eens de diepte induiken.

De BgZ versus de IPS

De BgZ is de Nederlandse “Patient Summary”: een samenvatting van de meest relevante medische gegevens van een patiënt. De BgZ is deels gebaseerd op internationale standaarden zoals C-CDA uit de USA en de Europese epSOS Patient Summary. De BgZ is in tegenstelling tot de IPS gebaseerd op Nederlandse zorginformatiebouwstenen (zibs) die internationaal niet veel gebruikt worden. In de praktijk vallen de verschillen mee, maar ze zijn er wel.

Photo by National Cancer Institute on Unsplash

Internationaal staat de wereld ook niet stil. Bovengenoemde C-CDA en de epSOS PS zijn ook gebruikt als uitgangspunt voor de IPS. Dat leidt weer tot de nodige verschillen op detailniveau – voornamelijk verbeteringen door opgedane ervaring met het gebruik. Technisch is er ook een groot verschil: de IPS kent een CDA-variant maar ook een FHIR R4 variant. Die is er voor de Europese PS niet. Onze eigen BgZ kent wel een FHIR variant.

Nictiz heeft een fit-gap analyse gemaakt van de verschillen tussen de BgZ en de Europese PS op functioneel niveau: komen data-elementen en waardenlijsten overeen of niet. Zelf wilde ik een slag dieper kijken: wat zijn de verschillen op FHIR-niveau? Waarbij aangetekend dat mijn analyse verkennend en niet uitputtend is, zoals de fit-gap analyse wel is.

Aanpak

FHIR kent veel open source software, waaronder de HAPI server, die ook publiek toegankelijk is. Vanuit de Nederlandse FHIR projecten hebben we al veel voorbeelden in FHIR R4. Ook voor de BgZ, waarbij van een voorbeeldpatiënt een groot aantal zibs (zorginformatiebouwstenen) beschikbaar zijn als FHIR R4 resources. Deze FHIR-zibs kun je uploaden naar een FHIR server. Ik heb alle FHIR-zibs van de BgZ van een voorbeeldpatiënt met een Python script naar HAPI overgebracht met de FHIR update operation. HAPI controleert daarbij of de inhoud deugdelijk is. Na het uploaden van de voorbeeldpatiënt functioneert de HAPI server dus als een FHIR database waarmee we de patiëntgegevens kunnen bevragen.

Zonder inspanning gaat het niet: het is geen kwestie van uploaden en klaar, Met 2 dagen FHIR Connectathon en zo’n 3 dagen eromheen had ik een BgZ testset omgezet naar een FHIR IPS die zonder errors was, testend met de validatiesoftware van FHIR zelf. Er zijn dus wel aanpassingen nodig aan de BgZ.

Intermezzo: hoe werkt het

HAPI heeft nog niet zo lang de $summary operation: een uitvraag waarbij vanuit de FHIR resources die op de server aanwezig zijn, een IPS wordt gegenereerd. Daarbij wordt de hele documentstructuur van de IPS aangemaakt maar worden ook de narratieve secties gevuld.

IPS secties kennen naast gestructureerde gegevens ook een tekstuele weergave in HTML, die getoond kan worden aan de gebruiker. De IPS viewers die er zijn maken daar vaak gebruik van. Na het aanmaken van de patient op HAPI, kan de IPS dus direct opgehaald worden met:

https://hapi.fhir.org/baseR4/Patient/nl-core-Patient-01/$summary

(De HAPI testserver wordt regelmatig ververst, het is dus goed mogelijk dat dit voorbeeld niet meer te zien is. Het voorbeeld is hier ook te vinden.)

Deze IPS kan direct getoond worden in een IPS viewer. Voor wie dit na wil spelen: klik boven op de pagina op “Raw JSON”, of “Raw”. Kopieer de hele pagina. Ga dan naar: https://www.ipsviewer.com/ en plak de IPS in de tekstbox. Vervolgens kun je de IPS, die is omgezet uit de BgZ, zien in de viewer. De IPS kan getoond worden als FHIR Entries (de gestructureerde gegevens) of als FHIR Narrative (de door HAPI gegenereerde tekst als HTML). Hier een stuk van de BgZ zoals dat te zien is in de IPSviewer.

Een andere viewer is: https://ps-ca-renderer.apibox.ca/

Bevindingen

De structuur van de IPS

De BgZ in Nederland wordt samengesteld met FHIR queries. Kort gezegd: je vraagt bij een bron de allergieën uit, dan de problemen, dan de labuitslagen et cetera en wanneer je klaar bent heb je een complete BgZ. De IPS werkt anders: dat is een FHIR Document, en alles zit daar al in. Het maakt uit bij afwijkende bevindingen, zoals: voor deze patiënt zijn er geen allergieën bekend. In de IPS kan dat toegevoegd worden in het document. En dan niet alleen als “ik heb niks gevonden”, maar ook als positieve uitspraak: “de patiënt is bevraagd door arts X op datum Y, en er zijn geen allergieën bekend”. De BgZ kan dat niet zo eenvoudig. (Het is wel al langer een bekend en openstaand issue.)

Photo by Julia Koblitz on Unsplash

De IPS is – omdat het een document is – ook eenvoudiger te bewaren, en eenvoudiger uit te wisselen over andere infrastructuren, zoals IHE XDS/XCA – appeltje eitje daar een IPS in op te nemen, maar met de huidige BgZ gaat dat niet. De eerlijkheid gebiedt wel te zeggen dat queries en documents beiden voor- en nadelen hebben.

Omdat de IPS een document is, is er ook een manier om een server te vragen: “geef mij een IPS”. Dat heet de $summary operation, en de FHIR server stelt dan een IPS samen op basis van wat er in die server bekend is. De open source HAPI server heeft die operation, en die wordt in het begin van deze blog ook gebruikt om de BgZ om te zetten naar een IPS.

Een ander punt is de tekstuele weergave in de IPS. Een FHIR Document (net als de oudere standaard CDA) kent bij iedere sectie een tekstueel blok, en een blok met gecodeerde gegevens. Dat tekstuele blok is een variant van HTML, en kan gewoon in een webbrowser getoond worden. Makkelijk, want zo kan de arts of patiënt de informatie altijd zien, ook als de applicatie die gebruikt wordt de gecodeerde gegevens niet ondersteund. Maar wanneer je alleen losse FHIR resources hebt die je met queries ophaalt, heb je helemaal geen tekstueel blok per sectie. De HAPI server lost dat op door een tekstblok per sectie te genereren. Dat is dan meestal een tabel met de meest essentiële gegevens uit de gecodeerde gegevens. Het werkt. Misschien zou een lokaal gegenereerd tekstblok per sectie nog beter kunnen zijn, maar eerlijk gezegd: steeds vaker worden die tekstblokken altijd gegenereerd uit de gecodeerde gegevens, ook in Nederland in onze BgZ. Het is dus meer de vraag of de aanpak van CDA en FHIR Documents met altijd-tekstblok-en-gecodeerde-gegevens niet zijn langste tijd gehad heeft.

Extensies en de zibs

In Nederland zijn de zibs de basis van de gegevensuitwisseling in de zorg. In andere landen is dat niet zo. Vaak wordt gewerkt vanuit een “Implementation Guide” voor een specifiek domein, wat in de Engelstalige wereld vaak gebeurt, of vanuit een dataset zoals o.a. in Duitsland. Bij het omzetten van zibs naar FHIR resources blijkt dan ook vaak dat het niet helemaal past: er ontbreken bijvoorbeeld elementen die de zib kent in de FHIR resource. Dat hoeft geen heel groot probleem te zijn: FHIR kent “extensions” waarmee gegevens toegevoegd kunnen worden aan een FHIR resource.

Zie dit voorbeeld van de zib MedischHulpmiddel:

Een onderdeel van de zib is de lateraliteit: links, rechts of beide. Dat zit niet op die manier in de FHIR resource, en daarom wordt er een extensie gebruikt:

Zolang we in Nederland blijven werkt dat prima. Alleen: de IPS, en andere internationale standaarden, kennen die Nederlandse extensies helemaal niet. Dat leidt ertoe dat je de extensie ook helemaal niet ziet in een internationale toepassing op de IPS, en de toevoeging “Rechts” daar wegvalt.

Is dat erg? Dat hangt van de extensie af. In het ene geval gaat vrij essentiële informatie verloren, in het andere geval valt er mee te leven. Soms voegt een extensie alleen een Snomed code toe aan een HL7 code. Een ander mooi voorbeeld is de naam:

In Nederland kennen we een voorvoegsel bij de achternaam. Het FHIR voorbeeld hierboven ziet er prima uit in de IPS:

Maar dit is alleen omdat zowel de hele “family” string gevuld is met de componenten (“van Putten-van der Giessen”). En dat is in Nederland niet verplicht: de “family” string leeg laten en alleen de onderdelen “van”, “Putten” etc. vullen mag. En als je alleen die onderdelen vult, maar niet de samengestelde achternaam, blijft die in een IPS toepassing leeg. Voor het aanmaken van een correcte IPS is dus wel wat te doen: bijvoorbeeld vullen van de samengestelde familienaam als die leeg is uit de componenten, en dito voor veel andere extensies.

Er zitten heel veel extensies in onze Nederlandse FHIR resources, grotendeels het gevolg van het eigen model wat de zibs kennen. Dat biedt voordelen in Nederland. Internationaal betaal je daar weer een prijs voor: deze extensies gaan verloren bij internationale uitwisseling zonder aanvullende maatregelen.

Verschillen in de inhoud

De IPS en de BgZ verschillen ook in inhoud. Nictiz heeft een fit-gap analyse op detailniveau gemaakt. Om een paar punten op te noemen: de BgZ kent een sectie “Alerts”, waarin bijvoorbeeld zaken staan als een MRSA-besmetting (een bacterie die resistent is tegen antibiotica): belangrijk, want zo’n patiënt wil je niet in je ziekenhuis zonder maatregelen, anders hebben spoedig alle patiënten die bacterie. De IPS kent dan weer een sectie “Zwangerschap” die de BgZ niet kent. Die zou relatief eenvoudig toe te voegen zijn, want we hebben in Nederland al uitgebreide standaarden rond geboorte.

Verder is er een belangrijk verschil, ook met de Europese PS: de IPS heeft een subset van Snomed (de Snomed IPS Free Set) beschikbaar gekregen. Snomed CT is een internationaal terminologiestelsel dat o.a. in Nederland veel gebruikt wordt, en essentieel is in onze uitwisselingen. Helaas wordt Snomed niet overal gebruikt en dat heeft er onder andere mee te maken dat Snomed niet gratis beschikbaar is. De Snomed IPS Free Set is dat wel, en die is pas ontstaan na de Europese PS. Die Free Set speelt dus een belangrijke rol in de IPS: veel waardenlijsten bestaan uit concepten uit de Free Set. In de Nederlandse BgZ (en de Europese PS) is daarmee nog geen rekening gehouden en er zitten dan ook verschillen in. Belangrijk is bij aanpassingen in terminologie in de BgZ, altijd goed naar de Free Set te kijken.

Vaak vallen de verschillen in de waardenlijsten tussen de BgZ en de IPS wel mee. Voor TabakGebruik hanteren beide 8 codes, waarvan 6 dezelfde. Voor de ernst van een allergie kent de zib 1 code meer dan de IPS. In dit soort gevallen is een mapping wel te vinden die in de conversie gebruikt kan worden zonder groot verlies van informatie.

Op een dieper niveau zijn er ook verschillen te vinden. Zowel de zibs als de IPS kennen een “Functionele of mentale status”. Bij de zib is ervoor gekozen deze te implementeren als een FHIR Observation. De IPS biedt hier de keuze tussen een FHIR Condition (de zib Probleem) of een FHIR ClinicalImpression. Uiteraard zou het goed zijn hier altijd te kijken naar keuzes die internationaal gemaakt worden. Bij het omzetten van de BgZ naar de IPS gaat de sectie “Functionele of mentale status” dus verloren. Om die te behouden zouden de FHIR Observations in die sectie eerst omgezet moeten worden naar ClinicalImpression of Condition.

Medicatie

Photo by freestocks.org on Unsplash

Een lastig verhaal is medicatie. De BgZ2017 kent drie medicatiebouwstenen: MedicatieAfspraak (wat de arts voorschrijft), Toedieningsafspraak (precieze instructie van de apotheker) en MedicatieGebruik (wat de patiënt echt gebruikt). Het is me in Phoenix bij een aantal medicatiebouwstenen niet gelukt die zodanig in de IPS op te nemen dat er geen foutmeldingen optraden. Op zich niet heel vreemd, ik heb een weekend en wat uurtjes daarna eraan gewerkt, dat is niet veel, en met wat meer tijd en moeite kom je vast verder. Het is wel het enige onderdeel waar ik hier tegen aan liep.

Fundamenteler zijn de extensies in medicatie. In medicatie is er een extensie voor de hele doseerinstructie als tekst: “Vanaf 1 september 2012 gedurende 5 dagen 1x per dag om 8uur 40 mg (=1 st)”. Er zijn nog wel meer extensies in medicatie met nuttige informatie. In een internationale applicatie als de IPSviewer valt het allemaal weg. Ook een narrative (tekstblok) per medicatiebouwsteen helpt niet veel: de IPSviewer (en andere applicaties) laten ofwel de narrative van de hele sectie zien ofwel de gestructureerde inhoud, waarin de Nederlandse extensies dus ontbreken. Voor het internationaal uitwisselen van medicatie met de IPS is nog wel wat werk te verrichten. De aanpak: in een FHIR server stoppen en een IPS genereren alleen is hier niet voldoende. Voor medicatie is het dus nodig de Nederlandse resources met een stukje custom software om te zetten naar de internationale. Dat is op zich niet erg, en het zal op meer plaatsen in de BgZ wel nodig zijn.

En de taal dan?

Hierboven was het al te zien, een doseerinstructie als: “Vanaf 1 september 2012 gedurende 5 dagen 1x per dag om 8uur 40 mg (=1 st)”. Dat zal een arts in Frankrijk of Polen niet zonder meer begrijpen. Veel van de inhoud kan wel “vertaald” worden. De meting “Lichaamsgewicht” is bijvoorbeeld gecodeerd met de LOINC code “29463-7”, en de Engelse vertaling is bekend: “Body weight”. Eigenlijk is alles wat gecodeerd is in principe te vertalen. De zibs, en dus onze BgZ, kennen wel veel tekstuele toelichtingen. Die zijn niet te vertalen op basis van coderingen. Vertaalsoftware op vrije tekst kan steeds meer; wanneer dit gebruikt kan worden hangt van de toepassing af. Voor ingrijpende medische handelingen zal dit nog niet het geval zijn, voor alledaagse hulpverlening waarschijnlijk wel. Maar ook zonder het vertalen van vrije tekst is de IPS al een zeer nuttig overzicht van essentiële medische gegevens in een internationale context.

Conclusie

Er is goed nieuws: zonder bijzonder veel inspanning is, door onze zibs te uploaden in een FHIR server, met de $summary operation een heel behoorlijke IPS te maken. Die is zeker niet perfect, er zijn de nodige hoeken die bijgeschaafd moeten worden maar in wezen is het een overzichtelijke inspanning. Met name voor de secties Medicatie en Functionele en mentale status is nog wel werk nodig. Dat betekent dat internationaal delen van een IPS met standaardsoftware van FHIR, een te overzien aantal aanpassingen, vanuit de BgZ mogelijk is.

Voorlopig ziet het er naar uit dat we daar in Nederland niet direct mee te maken hebben omdat Europa eerst aansluit op de wat oudere Europese PS die nog gebaseerd is op CDA. Maar mijn doel op de HL7 WGM in Phoenix was te kijken hoe ver we afdrijven van het einddoel waar ook Europa naar toe wil: de IPS in FHIR. Dat lijkt mee te vallen. Wel een punt van zorg zijn de vele Nederlandse extensies: die zullen internationaal niet begrepen worden. Er zijn dan twee routes denkbaar: bij conversie naar de IPS die Nederlandse extensies – waar mogelijk – omzetten naar iets wat internationaal wel begrepen wordt. Of dit soort extensies zoveel mogelijk vermijden, in ieder geval in de BgZ. Ook dat vergt een lange adem: voor zibs2017 en zibs2020 kan dat niet meer. Het zou wel een belangrijk punt van aandacht moeten zijn bij latere versies van de zibs.

Posted on

Datasets en zibs mappen

De gegevensuitwisseling in de Nederlandse zorg wordt steeds meer gebaseerd op zibs, bijvoorbeeld in de Basisgegevensset Zorg en MedMij. Maar modelleren van gegevens in een specifieke sector, zoals JGZ, Geboortezorg of eOverdracht, gebeurt met datasets in ART-DECOR. Zibs zijn bouwstenen: componenten als naam, adres, medicatie die in meerdere contexten hergebruikt kunnen worden. Datasets zijn (hiërarchische) lijsten van informatie zoals zorgverleners die in een bepaalde context gebruiken. Zibs zijn dus contextloos tot ze gebruikt worden in een bepaalde use case.

Om zibs en datasets te combineren kunnen zibs “geërfd” worden in een dataset: een techniek waarop ik niet inga. Een andere aanpak is mappen: aangeven waar een element uit een dataset overeenkomt met een zib attribuut. Voor mapping is een eenvoudig tool beschikbaar: de ZIB mapper. De opzet en ideeën achter de ZIB mapper komen van gesprekken die ik met Linda Mook gevoerd heb, en hebben we het eerst uitgeprobeerd in een oncologie project.

Een voorbeeld van een mapping is te zien op het demo project. Elementen uit de dataset kunnen simpel een-op-een (waar van toepassing) op zibs gemapt worden: element gewicht op zib “Lichaamsgewicht”, BSN op Patient.Identificatienummer et cetera.  Maar een complexere mapping is ook mogelijk, bijvoorbeeld bij Probleem.

Hier is een beoordeling van gewicht gekoppeld aan de zib Probleem. Er wordt bovendien aangegeven dat Probleem.ProbleemType altijd “Diagnose” is. In de zib kan het type ook een klacht, symptoom etc. zijn. In deze context wordt dus aangegeven dat het altijd om een diagnose gaat. Van de status van het probleem wordt gezegd dat deze in deze context altijd “Actueel” is. En de ProbleemNaam is de waarde uit de valueSet die bij het concept hoort: dat kan dus “Normaal gewicht”, “Obesitas” etc. zijn. Daar waar de zib Probleem heel veel waarden uit o.a. ICD-10, Snomed CT etc. toestaat, zijn hier maar 4 codes (uit Snomed CT) toegestaan. En van twee items uit Probleem, lateraliteit en anatomische locatie, wordt gesteld dat ze niet van toepassing zijn (NP = not present). Overgewicht is immers niet gebonden aan een specifieke locatie of zijde. Met dit soort informatie kan de ontwerper van een UI er dus voor zorgen dat de zorgverlener irrelevante gegevens niet te zien krijgt, en vaste waarden vooringevuld zijn, zodat de registratie alleen voor de echte in te voeren waarden gebeurt.

Mapping legt dus relaties tussen een dataset en zibs, en brengt context aan. In de mappingtool kan dit met een eenvoudige UI ingevoerd worden.

(Let wel: voor het gebruik van het mappingtool moet een DECOR beheerder op de juiste manier een “Community” aanmaken in ART-DECOR.) Voor de technisch geïnteresseerden is de hele zibmapper te zien op Github.

De zibmapper is een simpel hulpmiddel, en voor complexe projecten misschien te eenvoudig. Maar voor een snelle mapping van zibs op een dataset is het nu al direct in te zetten, zonder veel overhead.

 

 

 





Posted on

De “International Patient Summary” op de HL7 WGM Atlanta

Internationaal uitwisselen van patiëntgegevens komt een stap dichterbij.  De FHIR versie van “International Patient Summary” (IPS) van HL7 gaat naar “Standard voor Trial Use” (STU) status, naar verwachting nog dit jaar. (De CDA variant is al STU.) De laatste oneffenheden worden er op de HL7 Working Group Meeting in Atlanta uitgestreken.  Daarmee wordt het meenemen van medische gegevens bij een vakantie of werk over de grens straks een stuk makkelijker.

Het Marriott Marquis Hotel waar de WGM is.

De IPS heeft een lange geschiedenis achter de rug. Het Europese epSOS project kende al de European Patient Summary. Echt van de grond gekomen is die niet, maar dit project is een van de voorlopers van de IPS, net als diverse Amerikaanse initiatieven. Internationaal uitwisselen van medische gegevens kent eigen valkuilen en problemen. Bijvoorbeeld: in Nederland kennen we voor medicatie onze G-standaard, maar die is in het buitenland niet bekend. Hetzelfde geldt voor ons BSN: buitenlanders in Nederland hebben dit niet.

De IPS wil een minimale maar wel relevante set gegevens zijn. Specialisme-agnostisch en niet gericht op een specifieke aandoening. De voornaamste use case is ongeplande grensoverschrijdende zorg. Een casus die ik me goed voor kan stellen: oudere vakantiegangers, die het fijn vinden ook in het buitenland over basale medische gegevens te kunnen beschikken. Nu is er het medicijnenpaspoort, een papieren overzicht met medicatie.  De IPS bevat daarnaast ook allergieën, klachten, inentingen, ondergane operaties, medische hulpmiddelen zoals implantaten, diverse labuitslagen en meer.

Ik denk dan aan mijn ouders, die een aantal jaren geleden met teruglopende gezondheid nog graag naar Zuid-Frankrijk gingen, maar bezorgd waren dat ze niet de nodige gegevens zouden hebben wanneer dat nodig was. Mijn vader kan redelijk Frans, maar niet goed genoeg om een medisch verhaal uit te leggen. Dat nog los van de vraag of ze uit het geheugen alle details weten te vertellen. Dan zou het prettig zijn dat een Franse arts toegang heeft tot die basale gegevens, zodat het gesprek wat eenvoudiger – en inhoudelijk juister – plaats kan vinden.

De IPS heeft een grote overlap met de Nederlandse Basisgegevensset Zorg (BGZ). Er is dan ook een goede basis voor Nederland om mee te kunnen doen aan b.v. een pilot met een van de Europese landen waar veel Nederlanders werken of met vakantie gaan. Er zijn nog wel de nodige problemen. Zo is de BGZ gebaseerd op FHIR 3 en de IPS op FHIR 4. Dat valt nog wel te converteren. Maar de BGZ wordt op dit moment voornamelijk geïmplementeerd in ziekenhuizen. Nu zijn ziekenhuizen voor mensen die op vakantie gaan of in het buitenland werken meestal niet de houders van de meest recente informatie: dat is in Nederland de huisarts, maar die heeft nog geen BGZ.

Een andere optie is MedMij: gebruik gegevens uit de persoonlijke gezondheidsomgeving (PGO) voor de IPS. In principe haalt MedMij wel de meeste recente gegevens uit meerdere bronnen op. Bij MedMij is er alleen geen “auteur” van het hele IPS. Dat raakt meteen ook een van de laatste discussiepunten van de Working Group Meeting: moet de IPS een “document” zijn dat door een verantwoordelijke zorgverlener is goedgekeurd? Of mag het ook een verzameling zijn uit diverse bronnen, waarbij nooit een mens het geheel heeft beoordeeld? De Working Group heeft besloten dat het per jurisdictie kan verschillen: dus het ene land kan een IPS door de huisarts op laten stellen, het andere land kan de IPS “on the fly” samenstellen. In het IPS moet aangegeven worden of er wel of niet een verantwoordelijke auteur is, maar beide mag.

Hoe dan ook, Nederland loopt voorop, en de IPS  heeft een aantal duidelijke – en zeer nuttige – use cases. Al met al tijd voor een verdere stap vooruit in medische gegevensuitwisseling: de grens over.





Posted on

To ZIB or not to ZIB

De Nederlandse zorginformatie beweegt hard richting ZorgInformatieBouwstenen: de ZIBS. Het idee is eenvoudig: alle zorginformatie die voor hergebruik in aanmerking komt, wordt eenmalig op eenduidige wijze vastgelegd bij de bron, met dezelfde ZIBS. Zo hoeft alles maar een keer ingevoerd te worden. De ZIBS worden vervolgens uitgewisseld, en iedereen maakt gebruik van dezelfde data.

De werkelijkheid is weerbarstiger. Voor de duidelijkheid: ik vind de ZIBS een geweldig idee, en dit is zeker de richting waarin het in de zorg ICT heen moet. Maar tussen de ZIBS en de werkelijkheid zit vaak veel licht. Een paar voorbeelden.

Roken

Er is een zorginformatiebouwsteen ‘Tabakgebruik’:

Tabakgebruik (zibs.nl cc-by-nd)

Hiermee kan in detail het rookgedrag worden vastgelegd. Met “SoortTabakGebruik” wordt vastgelegd wat iemand rookt (sigaretten, sigaren, pijp etc.) en met “TabakGebruikStatus” het rookgedrag (rookt dagelijks, rookt soms, rookte vroeger, niet-roker etc.). Er kan ook een “Hoeveelheid” bij (30 sigaretten per week, 100 gram shag etc.)

Wanneer we de ZIB willen gebruiken in de geboortezorg, lopen we direct tegen een probleem aan. In de geboortezorg wordt al een gegeven “Rookgedrag” uitgewisseld. Daarin zitten waarden als: 1-1o, 11-20. Wat staat er niet bij. Hoe maken we daar een ZIB van? We kunnen wat sjoemelen en 1-10 als “5” in de ZIB opslaan, en 11-20 als “15”. Maar dat suggereert natuurlijk een nauwkeurigheid die de zorgverlener of zwangere nooit heeft geuit. Getallen aan laten passen door software is gewoon niet goed in het primaire proces .

We kunnen ook de knoop doorhakken en helemaal voor de ZIB gaan. Alle leveranciers moeten dan de verloskundige en gynaecologische systemen aanpassen, en we leggen voortaan de ZIB Tabakgebruik vast. Daarbij duikt een ander probleem op. De Rookgedrag lijst van de Geboortezorg kent nog twee categorieën: “gestopt vóór huidige zwangerschap” en “gestopt tijdens huidige zwangerschap”. Relevant bij zwangerschap, maar dit zit niet in de ZIB Tabakgebruik. We kunnen het ergens anders stoppen, buiten de ZIB, alleen is het rookgedrag, wat één handzaam lijstje was, dan opeens over twee lijsten verspreid. Een bijkomend probleem bij overstappen op de ZIB is dat gegevens uit het verleden niet meer goed te vergelijken zijn met het heden, omdat er iets anders wordt vastgelegd.

Scores

In de zorg worden veel scores gebruikt. B.v. de Apgar score voor pasgeboren kinderen. Daar is een ZIB van, en het werkt als volgt: de verloskundige of gynaecoloog geeft een 0, 1 0f 2 voor een aantal observaties van de pasgeborene zoals ademhaling, huidskleur etc. Deze worden opgeteld tot een totaalscore. 7 of hoger is een goede score, bij een lagere is aandacht of ingrijpen nodig. Er staan er 13 in de ZIBS.

Er is een probleem wanneer we scores die niet in de ZIBS staan in een ZIB willen gieten. Zulke scores zijn er heel veel: vele tientallen in de oncologie alleen al. De losse items kunnen we nog wel in de zorginformatiebouwsteen AlgemeneMeting stoppen: die is voor metingen of bepalingen waarvoor geen specifieke ZIB is. Alleen is er met ZIBS geen manier om de totaalscores en de losse bepalingen te groeperen in één Score-ZIB. De relatie tussen de items is dus zoek.

Uitgerekend

Photo by Alex Hockett on Unsplash

Voor laboratoriumbepalingen is – heel terecht – gekozen voor een ZIB met een testcode (uit LOINC, voor de soort test) en een uitslag, en niet voor een ZIB per labtest. Daar zijn er veel te veel van, en er komen regelmatig nieuwe bij. Prima opgelost dus.

Voor niet-laboratoriumbepalingen is er de AlgemeneMeting. Er staat: “Een algemene meting legt de uitkomst vast van een meting of bepaling die bij een patënt is uitgevoerd” en : “Afhankelijk van de soort meting bestaat de uitslag uit een waarde met eenheid of uit een gecodeerde waarde (ordinaal of nominaal) of uit een tekstuele uitslag.” Daar zijn ook een paar problemen mee.

Een paar andere gegevens van een patiënt:

  • Datum laatste menstruatie: belangrijk in de verloskunde. Maar het is geen eenheid of gecodeerde waarde. Moet het dan maar als tekst? Terwijl het een datum is, en niet zomaar tekst? En het is ook geen meting, want de verloskundige meet niets.
  • In de geboortezorg wordt ook vastgelegd of er sprake is van seksueel geweld, of huiselijk geweld. Daar speelt hetzelfde probleem: het is geen “meting”, maar een vraag. Het antwoord is “ja” of “nee”, geen eenheid en geen code. Het past dus niet echt in AlgemeneMeting.
  • A terme datum: dat is de datum waarop de vrouw is “uitgerekend”. Die zit in de ZIB Zwangerschap, maar die is te onnauwkeurig voor geboortezorg. Daar wil men ook weten op basis waarvan de à terme datum bepaald is: de laatste menstruatie, een echoscopie etc. Wanneer we dan een AlgemeneMeting willen gebruiken, lopen we weer tegen het probleem van de scores aan: er is geen manier om twee gegevens (à terme datum en basis bepaling) “samen te voegen” in een ZIB.

Samenvattend: hoewel de AlgemeneMeting een nuttige ZIB is, is deze nog niet breed genoeg. Er is een “Algemene Bevinding” nodig, waarin niet alleen metingen passen maar ook andere bevindingen en vragen. Waar ook datums en ja/nee als antwoord kunnen. En belangrijk: waarin gegevens aan elkaar gerelateerd kunnen worden. Als dat er is, kan het meeste vastgelegd worden als een (specialisatie van) een ZIB.

Gewicht

Photo by i yunmai on Unsplash

Een wat kleiner probleem, maar toch goed om aan te geven hoe complex “verzibben” is. Gewicht, zou men denken, is toch wel een basisgegeven. Maar in de ZIB Lichaamsgewicht is gekozen voor LOINC code 29463-7 : “Body weight”.  In het PWD van de Geboortezorg is gekozen voor LOINC code 3141-9: “Body weight Measured”. Is dit nu hetzelfde? Kunnen we het gewoon in de ZIB stoppen, en de ene LOINC code weggooien en de andere opnemen? Ook hier geldt weer: codes met toch een iets andere betekenis aan laten passen door computers is zelden een goed idee.

Bloedgroep

Iets soortgelijks speelt bij “Bloedgroep”. Daar is geen zorginformatiebouwsteen voor (toch een vrij algemeen gegeven, dus dat zou je wel verwachten). Bij ontbreken van een ZIB kunnen we kiezen uit Labuitslag of AlgemeneMeting. Wanneer er een lab onderzoek gedaan wordt, is LabUitslag natuurlijk logisch. Maar wanneer alleen de bloedgroep A, B of O wordt vastgelegd, is het complexer. Er zijn twee labonderzoeken in de Nederlandse Labcodeset: ABO en ABO+rhesus, en dus twee LOINC codes. In een systeem van de huisarts of verloskundige zal niet staan welke test is uitgevoerd, alleen A, B of O. Dan kunnen we dus geen LabUitslag gebruiken, omdat de LOINC code niet meer te achterhalen is. Rhesus is nog ingewikkelder. Wanneer alleen de rhesus-factor wordt doorgegeven, kan de LOINC-code voor ABO+rh niet gebruikt worden, omdat dan niet duidelijk is of het over ABO of rh gaat. De AlgemeneMeting is een oplossing. Lastig is dan alleen dat we de ene keer een Bloedgroep in de ZIB Labuitslag doen, en de andere keer in AlgemeneMeting. Geen echte standaardisatie.

Conclusie

Nogmaals, de ZIBS zijn een goed idee, en dit is de weg vooruit. Maar bij de praktijk van het omzetten van de huidige zorginformatie naar ZIBS, het “verzibben” zijn nog heel veel obstakels. Even alles nu opeens als ZIBS uitwisselen is niet realistisch. Het vereist een heel andere registratie, en heel veel aanpassingen in systemen. En – zoals betoogd – ook nog wel wat aanpassingen aan de ZIBS.

Is deze blog nuttig? Deel hem via LinkedIn, Twitter of anders!