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.

 

 

 

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.

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!