Toestemming: puzzel in de zorg

Privacy en zorg: het is al jaren een moeizame relatie. Kwam de overheid een paar jaar geleden met een plan om de controle over toegang tot medische gegevens bij de patiënt te leggen, onlangs meldde de minister dat deze “Gespecificeerde Toestemming Structureel” (GTS) niet doorgaat. De uitwerking van de wet die eraan ten grondslag ligt leidde tot een totaal van 160 keuzemogelijkheden voor patiënten. Een simpeler oplossing met 28 keuzes is nog steeds te complex, en het is maar de vraag of dit wel conform de wet is. Onwerkbaar, volgens het Adviescollege Toetsing Regeldruk. GTS van de baan dus.

Tijd om te kijken naar alternatieven: kluisjes bij de huisarts of patiënt, tot EPD-toegang en “just-in-time” toestemming.

Photo by Carlos Muza on Unsplash

Wat is het probleem?

Maar eerst: wat is het probleem precies? De minister schrijft in de kamerbrief:

“Deze gespecificeerde toestemming geldt nadrukkelijk alleen voor die situaties waarin gegevens beschikbaar worden gesteld voor nog onbekend later gebruik … Terwijl het zorgproces daar helemaal niet om vraagt. In vrijwel alle gevallen gaat het immers om een behandelrelatie waarbinnen gegevens gewoon mogen worden uitgewisseld.”

Dat laatste klopt: de Wet op de Geneeskundige Behandelovereenkomst stelt dat een arts geen medische gegevens  mag verstrekken zonder toestemming van de patiënt. Die toestemming kan expliciet zijn (dat wilde GTS regelen) of impliciet: als een huisarts een patiënt doorverwijst naar b.v. een cardioloog, mag de huisarts uitgaan van toestemming van de patiënt. Als de patiënt dat niet wil, moet deze dat zelf aangeven.

De minister wil uitgaan van impliciete toestemming: “…de meeste zorg (is) geplande zorg is. Bij geplande zorg kunnen zorgverleners bewust kiezen welke gegevens ze moeten delen, en met wie.”

Er zijn wel uitzonderingen. Ten eerste ongeplande zorg, zoals een spoedopname. Daarvoor komt de minister met een oplossing. Ten tweede kan een arts bijvoorbeeld oudere beelden in willen zien: als de longarts ziet een vlekje ziet, is het van belang om te weten of dat vlekje er al langer zit. Zat er een jaar geleden niets, dan levert dat een andere beoordeling op dan wanneer precies datzelfde vlekje er een jaar geleden ook zat, en niet veranderd is.

Zulke oudere beelden kunnen bij een heel ander ziekenhuis liggen. Opvragen mag dan alleen met (gespecificeerde) toestemming van de patiënt. Een algemene toestemming (“iedere arts mag alles opvragen”) voldoet niet aan de wet. Wat staat de minister voor ogen:

” (ik) vind dat er andere infrastructurele keuzes moeten worden gemaakt. Namelijk voor systemen die niet werken met beschikbaarstelling vooraf, maar met het uitwisselen in de behandelrelatie zelf.”

Hopeloos optimistisch

De visie van de minister lijkt hopeloos optimistisch. De meeste medische gegevens kúnnen helemaal niet gedeeld worden in een behandelrelatie die in geplande zorg ontstaat, omdat die gegevens dan simpelweg niet voorhanden zijn. Oudere beelden zijn maar één voorbeeld.

Laboratoriumuitslagen liggen bij het laboratorium. De huisarts heeft wel een kopie, maar met eigen (NHG) coderingen, niet de originele uitslagen zoals het lab die heeft. En alleen voor onderzoeken die de huisarts zelf heeft aangevraagd. Bij laboratoriumuitslagen speelt precies hetzelfde issue als bij beelden: bij een afwijkende bloedwaarde is het relevant te weten of die recent is of langer bestaat. Niet alle patiënten zijn gelijk. Sommigen hebben probleemloos jarenlang vrij hoge waarden voor een specifieke test. Bij anderen is er een plotselinge piek: dat is een ander beeld, en relevant voor de beoordeling.

Medicatie ligt bij de apotheek. Ook hier heeft een huisarts wel voorschriften, maar de originele bron van de verstrekkingen is de huisarts niet.

Photo by freestocks.org on Unsplash

Bij een zwangerschap liggen de gegevens van de voorgaande zwangerschappen vaak bij een andere verloskundige of gynaecoloog dan de huidige. Kortom: dat medische gegevens buiten de huidige geplande zorg liggen is geen uitzondering. Het is de regel. Hopen dat het probleem weggaat bij geplande zorg is wensdenken.

Maar wat doen we dan wel? Ik schets hier zes alternatieven. Sommige wild, andere niet realiseerbaar. Ik sta er zelf misschien niet eens achter. Maar op dit moment is het beter buiten de doos te denken dan op een dood spoor verder rijden.

Alle gegevens bij de huisarts

Een manier om bij de geplande zorg van de minister aan te sluiten, is zorgen dat alle gegevens wél aanwezig zijn in dat traject. Dat kan wanneer we alle gegevens in een kluisje stoppen bij een preferentiële zorgverlener, zoals de huisarts (het kan natuurlijk ook een andere arts zijn, bijvoorbeeld bij patiënten in een verpleeghuis of instelling voor langdurige zorg). Daar moet dan alles in zitten: oude beelden, alle laboratoriumuitslagen, medicatie, zwangerschappen et cetera. De beherende arts kan dan de benodigde informatie uit het kluisje delen met volgende partijen in de geplande zorg, die het zo nodig weer verder kunnen delen (bijvoorbeeld bij doorverwijzing naar een academisch ziekenhuis).

De huisarts ligt voor de hand omdat veel gegevens relevant zijn voor de huisarts. Desalniettemin: misschien wil een patiënt niet dat een huisarts verslagen van de psychiater kan zien. Daarnaast is nodig dat de patiënt aangeeft wie de zorgverlener is die de gegevens mag beheren. Al met al is dit een model dat aansluit bij het idee van geplande zorg, maar ook haken en ogen kent.

Power to the Patient!

Een verdere stap: stop alle gegevens in een kluisje bij de patiënt. Die regelt dan dat zorgverleners die geplande zorg verlenen bij de gegevens kunnen. Bij bijvoorbeeld een verwijzing naar een KNO-arts bij een ziekenhuis kan de KNO-afdeling bij het maken van een afspraak de patiënt een verzoek tot toegang kunnen sturen. De patiënt logt dan in bij de eigen kluis, ziet een verzoek van de inmiddels bekende KNO-afdeling, en verleent toestemming. Met het programma MedMij is veel van de nodige infrastructuur al aanwezig. PGO’s zijn nu niet bedoeld voor zorg-naar-zorg uitwisseling, maar dat kan uiteraard veranderen.

Een nadeel is dat niet alle patiënten even digitaal vaardig zijn: de populatie patiënten bestaat voor een groot deel uit ouderen, maar ook voor andere patiënten kan zoiets een uitdaging zijn. Een valkuil in dit soort trajecten is altijd dat we een oplossing bedenken die prima bij onszelf, digitaal vaardige burgers, past maar anderen in de kou laat staan.

Uiteraard sluiten deze opties elkaar niet uit: een kluisje beheerd door de patiënt wanneer die dat wil, en uitbesteed aan de huisarts voor patiënten die dat liever zien. Voor spoedeisende hulp zou de patiënt zelf aan kunnen geven of SEH-artsen en huisartsenposten er wel of niet bij mogen.

De oplossingen met één centraal kluisje per patiënt waar alle informatie in zit, lossen het probleem van vooraf beschikbaar stellen op. Daarbij moet wel gezegd worden dat het deels een schijnoplossing is: is er nu zo’n groot verschil tussen een ziekenhuis dat via een uitwisselsysteem toegang geeft, mits er toestemming is, en een kluisje ergens dat ook toegankelijk is, mits er toestemming is? In beide gevallen ben je afhankelijk van een veilige implementatie en controle op toestemming.

Kijk in elkaars EPD

De Federatie Medisch Specialisten kwam onlangs met een ander idee: laat artsen in elkaars EPD kijken. Gewoon door ze een inlog te geven. In ieder geval voorlopig, tot het beter geregeld is. Er gaan immers mensen dood omdat gegevens niet beschikbaar zijn. De minister gaat erover denken maar verwacht wel “haren in de soep qua privacy”.

Nu zitten er aan het idee van de FMS natuurlijk twee uitersten. Alle specialisten toegang geven tot alle EPD’s is een no-go. Maar dat bij verwijzing van een oncoloog uit de regio naar een oncoloog in een academisch ziekenhuis die tweede toegang heeft tot de relevante gegevens van de eerste, is minder vreemd. Ook bij spoedopname in een regio is inzage binnen die regio misschien wenselijk.

Het idee van de FMS gaat er wel van uit dat iedere specialist in ieder EPD zomaar de weg weet te vinden. Dat is niet altijd een uitgemaakte zaak. Wellicht kan het voorstel van de FMS in specifieke situaties een oplossing bieden. Wanneer ziekenhuizen fuseren, wat regelmatig gebeurt, is het qua privacy natuurlijk van de ene op de andere dag geregeld. Stellen dat het nooit kan is dan wat vreemd.

Just-in-time toestemming

Photo by Sonja Langford on Unsplash

Het hele idee van vóóraf toestemming specificeren is natuurlijk vreemd. Dat leidt tot vragen als: verwacht ik eerder kanker te krijgen of dement te worden? En als ik kanker krijg, wat moet die oncoloog dan zien? Medicatie, oké, maar arbeidsconflicten, een burn-out, seksuele problematiek? Nee, dat niet. Hoewel: als het nu kanker aan de geslachtsorganen is… Afijn, dit voorleggen aan een gezonde patiënt vereist nogal wat mentale gymnastiek.

Kunnen we niet in plaats van alles vooraf te regelen, dat pas doen wanneer het nodig is? Als ik een specifieke klacht heb, en een specifieke arts verzoekt om gegevens, is dat een eenvoudige vraag. Toestemming wordt dan niet vooraf geregeld, maar bij het maken van een afspraak voor geplande zorg. Er gaat dan een (veilig) bericht naar de patiënt die op dat moment een specifieke toestemming verleent.

Dit veronderstelt uiteraard nog steeds dat de gegevens vooraf beschikbaar gesteld worden voor artsen die toestemming hebben, maar het hele probleem van de 160 keuzemogelijkheden wordt omzeild. Ook een uitzondering voor spoedeisende hulp past bij deze uitwerking. Bij een presentatie over Mitz, een nieuwe dienst voor toestemmingen, werd ook langs deze lijnen gedacht.

Volg de behandelrelatie

We kunnen ook de behandelrelatie volgen. Bij een verwijzing kan de huisarts dan toestemming geven aan een KNO-afdeling. Een specifieke afdeling, of regio wanneer de patiënt zelf een ziekenhuis uit wil zoeken (er is immers nog steeds het recht op vrije artsenkeuze). Daarbij kan de huisarts die toestemming bij de verwijzing registreren in een centraal register. Dat toestemmingenregister moet uiteraard geen antwoord geven op de vraag: wie heeft een behandelrelatie met patiënt Jansen? Dat is te privacygevoelig. Maar de vraag beantwoorden: heeft arts X of instelling Y toegang tot deze gegevens, waarbij die arts of instelling geauthenticeerd is, en het antwoord een simpel ja of nee is, lijkt me haalbaar.

De KNO-afdeling kan dan bij doorverwijzing weer verder toestemming geven: de KNO-arts heeft dan immers zelf een behandelrelatie. Wanneer advies van een MDL-arts nodig is, kan de toestemming doorgegeven worden om gegevens in te zien. Ook hier worden gegevens wel vooraf beschikbaar gesteld, maar zijn ze alleen toegankelijk na toestemming.

Sex and drugs and rock ‘n roll

Je kunt je ook afvragen wélke gegevens privacygevoelig zijn. Alle medische gegevens uiteraard, maar niet in gelijke mate. Informatie over seksuele geaardheid of aandoening, over psychiatrie, over middelengebruik, over arbeidsgerelateerde aandoeningen is veel vertrouwelijker dan dat gebroken been van die skivakantie, of het amandelen knippen toen je zes was. Toestemming kan gekoppeld worden aan het privacy-aspect van een gegeven. GTS gaat bijvoorbeeld uit van een hele categorie gegevens, zoals medicatie. Maar ibuprofen is niet hetzelfde als PrEP, methadon of de morning-after pil.

Toestemming per vertrouwelijkheidscategorie zal beter aansluiten bij de behoefte van de meeste burgers.

Hoe vooruit?

De minister heeft al aangegeven met een nieuw voorstel te komen. Voor de zomer. Feitelijk is dit de situatie waar we al jaren in zitten: wachten op een oplossing. Ik heb hier een aantal scenario’s geschetst. Ik denk dat deze oplossingen redelijk in lijn zijn met de wetgeving zoals WGBO en AVG (en de delen van de Wabvpz die doorgaan). Al geldt hier zeker: the devil is in the details. Feit is wel dat dit een moment is om breed na te denken. We kunnen niet blijven wachten op een goede oplossing voor dit urgente probleem.

Verder lezen?

De kamerbrief is hier te vinden:

https://www.rijksoverheid.nl/documenten/kamerstukken/2019/10/04/kamerbrief-over-gespecificeerde-toestemming-structureel

Voor degenen die niet de hele wet willen lezen, maar wel de essentie is er het uitstekende kennisdocument van OTV/GTS:

https://www.programma-otv.nl/nieuws/20191009-nieuwsbericht/

Over toegang tot EPD’s voor artsen:

https://www.medischcontact.nl/nieuws/laatste-nieuws/nieuwsartikel/bruins-wil-meedenken-over-toegang-artsen-tot-epds.htm

Over Mitz:

https://www.vzvz.nl/actueel/borgen-van-toestemming-patient-met-mitz

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.

 

 

 

Klinische genetica op de HL7 WGM Atlanta

Een van de meest actieve HL7 Working Groups is die rond “Clinical Genomics”.  Niet vreemd natuurlijk, sinds het Human Genome Project in 2003 het volledige menselijk genoom in kaart bracht, heeft DNA sequencing een grote vlucht genomen.  Voor een paar tientjes kun je privé al je DNA laten analyseren om de Neanderthaler in jezelf te ontdekken (ongeveer 2%). Ook de medische toepassing neemt toe – het is een kwestie van tijd voor een genetische analyse standaard wordt voor zelfs de meest eenvoudige aandoeningen.

PLoSBiol3.5.Fig7ChromosomesAluFish

Klinische genetica draagt ook bij aan de belofte van “precision medicine”:  per persoon op maat gemaakte optimale behandelingen. Genetische gegevens spelen daarbij uiteraard een belangrijke rol. Het gaat dan niet alleen om genetische data, maar ook de familie-anamnese (welke familieleden hadden welke ziektes of afwijkingen) en individuele fenotypische eigenschappen: genetische data hebben pas relevantie wanneer ze (kunnen) leiden tot een probleem voor de mens.

De FHIR implementatie van Clinical Genomics gaat uit van een Diagnostic Report. Daarin worden genetische bevindingen opgenomen:

Heel kort: een Sequence is een weergave van een stukje DNA van een mens (of ander levend wezen – in dit artikel richten we ons op mensen). Op zich is dit niet meer dan een reeks betekenisloze ATCG-letters. Een Variant is een bekende variatie in het menselijk genoom – een allel. Een Haplotype is een aantal allelen (of SNP’s, puntmutaties) die normaliter samen overerven. Een verzameling Haplotypen beschrijft het Genotype van een mens. Dit zijn allemaal GenomicFindings, en dat is weer een specialisatie van een FHIR Observation. Uiteraard is dit een vogelvluchtperspectief ,  voor details zie de FHIR pagina van Clinical Genomics.

Een ander onderwerp op de WGM was het informatiemodel van Clinical Genomics. Hierin worden het domein geanalyseerd en beschreven in UML. Bovenstaand plaatje is een klein deel daarvan. Daarbij gaat het om verschillende manieren om een stuk genoom te lokaliseren (coördinaten versus cytoband), introns, exons, et cetera. Het is een terugkerend thema in meerdere HL7 werkgroepen: de behoefte een aan abstract informatiemodel, waarbij het onderliggende domein beschreven wordt zonder aan concrete syntax als FHIR, CDA of HL7v2 te hoeven denken.

Een ander onderwerp was de aanstaande integratie van Phenopackets. Phenopackets is een standaard voor het uitwisselen van fenotypische informatie, bijvoorbeeld Microtia (een onderontwikkeld oor). De fenotypische abnormaliteiten worden (meestal) gecodeerd met de Human Phenotype Ontology (HPO).

Met phenopackets wordt informatie over fenotypische afwijkingen, familie en afstamming, genetische informatie en diagnose gebundeld. Phenopackets is geen HL7 standaard, maar van onder andere de Global Alliance for Genetics & Health, het Monarch Initiative (HPO) en Orphanet (zeldzame ziekten). Er is al een (draft) FHIR specificatie van phenopackets. Op de WGM is besloten integratie van deze draft met de FHIR specificatie van Clinical Genomics op te pakken. Een flinke uitbreiding van het bestaande model met fenotypische informatie en het belooft een integraal genetisch en fenotypisch, klinisch relevant, model voor uitwisseling.

Clinical Genomics is een van de meest dynamische gebieden in medische informatica en HL7. De ontwikkelingen volgen is meer dan de moeite waard. HL7 en FHIR lopen – met andere organisaties – voorop op dit gebied.

Kankerregistratie en mCode op de HL7 WGM in Atlanta

Op de HL7 Working Group Meeting in Atlanta was veel aandacht voor de “minimal Common Oncology Data Elements” (mCode) en het verwante Codex. mCode is een van de “FHIR Accelerators” – initiatieven waar in de VS extra geld en moeite in gestoken wordt om FHIR verder uit te rollen.

mCode is een project om een minimale set gegevens die alle kankersoorten gemeen hebben te specificeren en uit te wisselen, om zo tot betere zorg en beter onderzoek te komen. Het gaat dus niet om gegevens specifiek voor borstkanker of darmkanker, maar om die gegevens deze en andere soorten gemeen hebben. Een vereenvoudigd visueel datamodel geeft weer om welke gegevens het gaat:

mCode overzicht data model
mCode overzicht data model (klik voor vergroting)

 

Van de minimale gegevensset is een FHIR specificatie gereed. Meteen maar het slechte nieuws: mCode is een Amerikaans initiatief, en dat betekent dat centrale gegevens zijn gebaseerd op “us-core” componenten, waar we in Nederland “nl-core” hebben. Denk daarbij aan namen (tussenvoegsels), adressen (huisnummer toevoeging) en dergelijke: zaken die in Nederland nodig zijn, maar in de VS anders liggen.  Gelukkig is er veel overlap: Amerikaanse kankers kunnen net als de Nederlandse links-of rechtszijdig zijn,, Amerikaanse genen worden hetzelfde vastgelegd als Nederlandse genen, en de TNM-score wordt ook gebruikt. Daarnaast is vanuit het mCode Initiative aangegeven dat men geïnteresseerd is in internationalisering: een kans dus om aan te haken. Het Codex project maakt extensies boven op de minimale set van mCode.

De FHIR implementatie van mCode loopt voor op wat we in Nederland hebben. Zo is er een specificatie voor IKNL (ik ben een van de auteurs). Deze was gebaseerd op de kennis en stand van zaken van enkele jaren terug: toen was er internationaal nog niets. Ook in regionale netwerken als Oncozon en initiatieven van het Citrienfonds wordt gewerkt aan uitwisseling van oncologische gegevens.

Een goed moment dus om aan te sluiten bij mCode,  en in ieder geval te (her)gebruiken wat ook in de Nederlandse context past.

 

 

 

 

 

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.

Laat in gegevensuitwisseling in de zorg vervuiler betalen

Digitaal gegevens uitwisselen in de zorg komt maar traag op gang. Zorgverleners wijzen naar de ICT-leveranciers. Regelmatig hoor je op congressen boze sprekers: waarom wordt het niet gewoon goed geregeld! De leveranciers wijzen terug naar de zorg: investeringen in ICT staan niet erg hoog op het prioriteitenlijstje vergeleken met andere sectoren. Minister Bruins heeft in een brief aangegeven meer regie te gaan nemen: minder vrijblijvendheid, meer verplichting. Maar waarom gaat die gegevensuitwisseling in de zorg zo stroperig? Wanneer we geen inzicht hebben in de achterliggende redenen, heeft spierballenpolitiek weinig zin.

Gegevensuitwisseling in de zorg komt moeilijk op gang omdat de zorgsector asynchroon en versnipperd is. Eerst zullen we zien wat dat betekent, en vervolgens hoe het opgelost kan worden.

De zorg is asynchroon

Laten we eens kijken naar een sector waar wel volop digitaal wordt gecommuniceerd: de financiële sector. Banken communiceren bijna alleen maar digitaal, zowel met elkaar als met de consument. Wat maakt nu dat bij banken wel lukt wat in de zorg maar mondjesmaat slaagt? Simpel: banken doen feitelijk allemaal hetzelfde. En wanneer ze zaken met elkaar doen, betekent dat dat de digitale transacties twee kanten uit hetzelfde zijn.

Dit plaatje simplificeert het natuurlijk wel omdat banken meer doen dan overboeken, maar in wezen doet de ABN Amro geen ander werk dan de Rabobank of de ING. En dat maakt uitwisseling eenvoudig: wanneer gegevensuitwisseling digitaal gaat, profiteren alle partijen. Iedereen kan digitale overboekingen ontvangen, die direct in de computersystemen ingevoerd kan worden. Geen handmatig overkloppen van faxen en brieven meer. Iedereen wint. De zorg is niet zo netjes synchroon.

Een apotheek stuurt geen voorschriften naar een huisarts, een huisarts geen verstrekkingen naar een apotheek. Zelfs ziekenhuizen onderling communiceren niet gelijkwaardig: een regionaal ziekenhuis zal een complexe patiënt naar een academisch ziekenhuis verwijzen, niet andersom. Bij de overgang van verpleeghuis naar ziekenhuis, van huisarts naar laboratorium, van verloskundige naar echoscopist is het al net zo: wat er naartoe gaat, is niet wat eruit komt.

Dat is een van de oorzaken dat digitaliseren in de zorg langzaam op gang komt. Bij het automatiseren van één specifieke transactie, bijvoorbeeld een laboratoriumorder of een medicijnverstrekking, is het meestal zo dat de ene partij de inspanning levert, en de andere profijt heeft. Het maken van een digitaal document of bericht kost tijd en moeite. Systemen moeten aangepast worden, de infrastructuur geregeld, alles moet getest en beheerd worden. Ieder systeem kan zo een PDF of een tekstdocument opleveren, dat via (veilige) mail of fax verzonden kan worden. Een goed digitaal verwerkbaar document is niet zo makkelijk.

De voordelen liggen echter niet bij de maker, die de investering doet, maar bij de verwerker. Daar hoeft niets meer overgetypt te worden. Uiteraard moet er ook geïnvesteerd worden om de systemen zo aan te passen dat er digitaal ingelezen wordt, maar met de bonus van snelle en foutvrije verwerking is dat geen moeilijke keuze.  Uiteraard kun je samen afspreken een verwijzing én een ontslag te digitaliseren: maar dat is twee keer inspanning, dat zijn twee trajecten, en dat loopt niet twee keer synchroon. Wanneer een op zich nuttige exercitie wel kosten met zich meebrengt, maar weinig concrete opbrengsten, is het niet vreemd dat andere prioriteiten telkens bovenaan het lijstje komen. Het is geen onwil, het is een structureel probleem.

De zorg is versnipperd

Nu is het niet zo dat overal waar transacties asynchroon verlopen, digitalisering ook achterloopt. Vroeger heb ik kort in de “fast moving consumer goods” gewerkt met een FMCG expert. Dat zijn goederen als voeding, toiletartikelen, wasmiddelen et cetera. Een fascinerende wereld.

Photo by NeONBRAND on Unsplash

Hier gaat het om handel naar de consument. Die doet zijn inkopen bij de supermarkt. De supermarkten doen hun inkopen weer bij vele honderden toeleveranciers, sommige groot, velen klein. Die toeleveranciers hebben zelf weer toeleveranciers, en zo gaat de keten door tot ruwe grondstoffen en agrarische producten. Het is geen zachtzinnige wereld: een paar grote supermarkten maken de dienst uit, en zij bepalen de prijzen en de condities. Dat geldt ook voor de gegevensuitwisseling. De supermarktketen zegt: voortaan gebruiken we ons elektronisch inkoopsysteem. Punt. Niet meedoen is niet meedoen. Dat kan door de machtspositie van de grote supermarkten, die die medewerking kunnen afdwingen. Een toeleverancier kan zich eenvoudig niet veroorloven Albert Heijn of Jumbo als klant te verliezen.  Vergelijk dat eens met de zorg.

Bij de supermarkten maken de grote 4 (AH, Jumbo, Lidl, Aldi) driekwart van de markt uit. Bij de banken doen de grote 3 (Rabo, ING, ABN Amro) dat ruim. Ziekenhuizen? De grootste 10 halen nog geen kwart van de markt. Bij huisartsen en apotheken is de versnippering nog veel groter. Bij sommige zorgonderdelen (zoals kraamzorg en ouderenzorg) zie je wel grotere landelijke partijen, maar dat zijn niet de partijen met het meeste budget en doorzettingsmacht. Kortom, in de zorgsector ontbreken partijen die de digitale uitwisseling naar hun hand kunnen zetten.

Asynchroon en versnipperd, wat nu?

Nu betekent een asynchrone en versnipperde sector niet dat er niets van de grond kan komen. Er zijn nog heel veel gebieden die wel degelijk asynchroon en versnipperd zijn maar toch gedigitaliseerd. Denk bijvoorbeeld aan vakanties.

Photo by roman raizen on Unsplash

Er zijn heel veel vliegmaatschappijen, hotels, vakantiehuizen en knusse restaurantjes, en toch kost het ondanks deze veelheid aan partijen geen enkele moeite om via het web snel iets te boeken. En de andere kant van deze digitale uitwisseling is nog veel versnipperder: dat zijn wij: alle consumenten. De reden dat digitale uitwisseling hier wel werkt, ondanks asynchroniteit en versnippering is natuurlijk heel eenvoudig: vliegmaatschappijen en hoteliers en restauranthouders verdienen hun geld met het verkopen van stoelen, bedden en couverts. Het is core business. Hoe beter het digitale aanbod, hoe meer verkoop. Voor de zorg is het uitwisselen van digitale documenten niet de core business: dat is (gelukkig) de zorg voor de patiënt. Digitale uitwisseling kan die zorg beter maken, maar het is een hulpmiddel, niet de essentie. (Niet toevallig is een organisatie als Zorgdomein die onder andere vraag een aanbod in de zorg digitaal bij elkaar brengt, wel succesvol.)

Laat de vervuiler betalen

Digitaal uitwisselen van gegevens zou tegenwoordig de norm moeten zijn. Op papier, via de fax, of via een niet digitaal verwerkbaar document (Word, PDF) uitwisselen moet gezien worden als een vorm van vervuiling: de gegevens moeten bij de ontvanger opnieuw ingevoerd worden, met vertraging en kopieerfouten tot gevolg. Dat is digitale vervuiling.

Zorg dus dat ook in de zorg de baten bij de investeerder liggen. Bepaal voor iedere overdracht van gegevens een prijs. Dat is niet moeilijk, want er zijn voldoende bedrijven die papieren gegevens digitaliseren, en daarvoor betaald worden. En ook de kosten van het implementeren en onderhouden van een digitale gegevenslevering zijn prima in kaart te brengen. En stel dan de volgende simpele regels in:

  • als er geen goed gedefinieerde standaard voor digitale uitwisseling is, betaal de vergoeding aan de ontvanger, die immers kosten heeft om de gegevens te verwerken;
  • en als er wel zo’n standaard is, betaal dan de leverancier van de gegevens, die immers geïnvesteerd heeft (of daarvoor kan kiezen) om digitaal te kunnen leveren.

(Hier moet ik een belangenverstrengeling melden: als ZZP’er verdien ik een deel van mijn geld met het opstellen van zulke standaarden – maar ik denk dat iedereen het erover eens zal zijn dat gegevensuitwisseling niet gaat werken zonder gestandaardiseerd digitaal stopcontact.)

Photo by Hans Ripa on Unsplash

Wanneer er een reële prijs staat op iedere overdracht van gegevens (gegevens in de zorg volgen over het algemeen de patiënt op diens reis door de instellingen), kunnen zorgbestuurders reële keuzes maken. Wanneer er een digitale standaard is, en gegevens op papier leveren dus geld kost, is er een motief om te digitaliseren. Misschien gaat dit jaar een nieuwe MRI-scanner voor, maar op termijn is op papier blijven leveren duur. Kortom: bij een prijs per dossieroverdracht kunnen er normale bedrijfsmatige beslissingen genomen worden over digitalisering, liggen de baten bij de partij die investeert en de kosten bij de partij die dat niet doet. Die kosten kunnen in rekening worden gebracht via zorgverzekeraars, via wetgeving, of gewoon via onderlinge afspraken in de regio. Dat is niet zo spannend.

Nu zijn er tal van vergoedingen in de zorg, soms ook voor administratieve handelingen, maar veelal niet systematisch gekoppeld aan het gedigitaliseerd aanleveren van gegevens. De zorg is wel asynchroon en versnipperd, maar met een adequate financiële prikkel gaat digitale uitwisseling ineens met rugwind in plaats van tegenwind. Kortom, laat de vervuiler betalen en beloon partijen die investeren.

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

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!

Blockchain in de zorg is grootste hype sinds uitvinding van Internet

(Oorspronkelijk gepubliceerd op smarthealth.nl: Blockchain in de zorg is grootste hype sinds uitvinding van Internet)

Blockchain in de zorg is grootste hype sinds uitvinding van Internet

Je kunt nog steeds geen medisch informatie-congres bezoeken zonder tegen ‘blockchain in de zorg’ aan te lopen. “Blockchain gaat de zorg compleet veranderen.” “De meest ontwrichtende technologie sinds de uitvinding van het Internet.” Helaas, het zijn sprookjes voor degenen die erin willen geloven. Blockchain gaat helemaal geen revolutie in de zorg ontketenen. De profeten van de blockchain vergeten een essentieel punt: de zorg is niet te vergelijken met gebieden waarin de blockchain wel alles overhoop gaat halen. Blockchain in de zorg is een hype, misschien wel de grootste op het gebied van medische informatievoorziening sinds we internet hebben.

Wat is de blockchain?

Om te beginnen: wat is blockchain? Dat is niet zo moeilijk uit te leggen. Blockchain, de technologie achter de bitcoin, is een manier om digitale goederen uit te kunnen wisselen zonder dat een Trusted Third Party (TTP) nodig is. Bij traditioneel betalingsverkeer is een bank nodig omdat anders twee partijen niet zeker weten dat een fraai papier met cijfers erop, of een digitaal verzonden afschrift wel écht geld vertegenwoordigt. Een bank verifieert dat de betaler over de benodigde fondsen beschikt en maakt de betaling over naar de rekening van de ontvanger.

Met blockchain kan dat zonder een TTP zoals de bank. De betaler maakt direct een digitaal goed (bijvoorbeeld een bitcoin) over naar de ontvanger, en de blockchain-technologie zorgt er met digitale technieken voor dat de ontvanger, ook zonder TTP, 100% zeker weet dat het overgemaakte ook echt is.

Blockchain is zonder twijfel een ingenieuze technologie en zal zeker veel ontwrichten. De financiële wereld gaat overhoop. En overal waar gewerkt wordt, of kan worden, met digitale goederen – zoals aandelen, handel, de zakenwereld in brede zin – kan men de borst nat maken. Maar niet in de zorg. De ‘goederen’ waar de zorg in wezen om draait zijn niet digitaal: patiënten, medicijnen, hulpmiddelen. En voor goederen die niet digitaal zijn werkt de blockchain veel minder goed.

Een voorbeeld: blockchain is op zich geschikt om eigendomsbewijzen (bijvoorbeeld van onroerend goed) in de vorm van smart contracts op te slaan. Bij onroerend goed gaat het echter niet om het bezit van het eigendomsbewijs, maar om het feitelijke bezit van het huis. Alleen iets opslaan in de blockchain heeft dan geen zin: pas als de rechter het eigendomsbewijs in de blockchain ook ziet als het uiteindelijke eigendomsbewijs, werkt de blockchain voor onroerend goed. Het probleem is dat je het huis zelf niet op kunt slaan in de blockchain, maar alleen een bewijsstuk met een lossere of vastere relatie met het huis. Bij de bitcoin is dat anders: de eigenaar van de bitcoin is altijd de eigenaar die is geregistreerd in de blockchain, en niemand anders.

Alle medische gegevens in de blockchain?

Wat zijn nu eigenlijk de problemen die spelen in informatie-uitwisseling in de zorg? Ten eerste is een probleem dat heel veel medische gegevens niet uitgewisseld kunnen worden omdat ze helemaal niet beschikbaar worden gesteld. De trieste werkelijkheid is dat de meeste EPD’s (Elektronische Patiënten Dossiers) gesloten silo’s zijn. De grote partijen die de EPD’s bouwen hebben er helemaal geen belang bij open te zijn. De medische gegevens zijn potentieel veel geld waard – waarom dat dan gratis openstellen zodat anderen de vruchten kunnen plukken? De oorzaak is niet dat de techniek om gegevens uit te wisselen er niet is, maar de wil ontbreekt. De blockchain zal dat niet veranderen. Dat is een extra techniek, maar de oorzaak van dit probleem is niet technisch.De trieste werkelijkheid is dat de meeste EPD’s gesloten silo’s zijn

Een ander probleem is de betrouwbaarheid van de medische gegevens. Precies iets waar blockchain goed in is, zou je denken. Helaas. Wanneer we kijken naar bijvoorbeeld medicatiegegevens zijn de problemen anders. Apothekers en leveranciers die ik sprak (in het kader van het project Patiëntparticipatie Medicatieveiligheid) hadden de ervaring dat opgevraagde gegevens (via het LSP) zelden kloppen. Waarom? Er spelen veel problemen wanneer apotheek A gegevens uitvraagt van apotheek B. Een patiënt heeft een middel gekregen met de instructie dat het “zo nodig” tweemaal daags ingenomen mag worden. Het middel is allang op – maar dat weet de apotheek B nog niet, dus die stuurt de medicatie bij opvraag op naar apotheek A. Ook komt het vaak voor dat een patiënt wel medicatie heeft opgehaald, maar deze helemaal niet slikt.

Nog een probleem is dat patiënten bij iedere apotheek apart aan moeten geven of ze toestemming geven voor uitwisseling van gegevens. Wanneer de patiënt apotheek C wel toestemming heeft gegeven, maar apotheek B niet, mag apotheek B helemaal geen gegevens (via het LSP) aan opvragende apotheek A geven – ze mogen zelfs niet zeggen dat ze wel gegevens hebben. Er speelt nog veel meer: patiënten kopen zelfzorgmiddelen bij de drogist, en slikken die. Of ze hebben medicatie gehad in het buitenland, waar het LSP helemaal geen toegang heeft. En tenslotte, veel vaker dan je lief is: de registratie van apotheek B klopt helemaal niet. Een medicijn staat bijvoorbeeld geregistreerd als verstrekt, maar het ligt nog gewoon op de plank, omdat de patiënt het nooit heeft opgehaald, of andersom.

Digitale goederen en echte zaken

Al deze problemen gaat de blockchain niet oplossen. Het enige wat de blockchain je kan vertellen is dat een gegeven wat je van apotheek B krijgt, ook echt zo opgeslagen is in de registratie van apotheek B (door opeenvolgende medicatieverstrekkingen, of tokens daarvan, in blockchain op te slaan). Maar het probleem is niet dat apotheek B via het LSP zaken meldt die niet in de eigen registratie staan: het probleem is dat de registratie niet klopt met de werkelijkheid! Patiënten kunnen we niet in de blockchain stoppen. Medicijnen evenmin. De zorg gaat in wezen niet over digitale goederen, maar over tastbare zaken. Het helpt dan niet zeker te weten wat er geregistreerd staat: het gaat erom zeker te weten wat er echt aan de hand is.Bewust gegevens vervalsen of manipuleren is niet een van de centrale problemen in de zorg

Een probleem dat blockchain wel degelijk op zou kunnen lossen is juist het enige dat in al die gesprekken niet genoemd werd: dat apotheek B rommelt met de gegevens, of dat iemand anders ermee sjoemelt. Dat is wat blockchain belooft op te lossen: een malafide tussenpersoon die opzettelijk met gegevens rommelt valt door de mand. Maar bewust gegevens vervalsen of manipuleren is niet een van de centrale problemen in de zorg. De enige manier om zeker te weten wat er echt speelt, is met een zorgverlener en patiëntgegevens op te vragen en nog eens goed na te lopen. Gelukkig gebeurt dat ook steeds meer. Weinig revolutionair, wel effectief.

Alles op een rijtje

Het wordt nog duidelijker wanneer we kijken naar een mogelijke toepassing van blockchain: wanneer een medisch dossier (of tokens daarvoor, vanwege privacy en omvang) in de blockchain opgeslagen wordt, zou dat ongeveer als volgt gaan: een huisarts zet maandag in de blockchain dat een patiënt een klacht heeft, en dat een medicijn is voorgeschreven. Een apotheek noteert dinsdag als volgende transactie dat de patiënt het medicijn heeft opgehaald. De thuiszorg zet er donderdag in dat de patiënt verzorging heeft gekregen. Et cetera. Alles netjes achter elkaar, want zo werkt de blockchain: het is een keten van transacties, en eenmaal opgeslagen kan er niets meer veranderd worden of tussen gezet worden. Er kunnen enkel nieuwe transacties achter geplaatst worden. En dat is een probleem: wanneer de patiënt op woensdag bij de spoedeisende hulp is geweest vanwege een hoofdwond wil je dat uiteraard wél in de blockchain zetten. Alleen kan dat er niet achteraf tussen gefrommeld worden: dat staat de blockchain niet toe.

Een gebeurtenis is niet hetzelfde als het registreren ervan, en die registratie is niet altijd precies op tijd. Uiteraard kun je op vrijdag alsnog in de blockchain zetten dat de patiënt op woensdag op de SEH was. Alleen wordt dan de blockchain weer een reeks van losse beweringen, zonder dat je weet of deze compleet is, en in willekeurige volgorde. Bij digitale goederen is dat niet zo: de volgorde van de transacties in de blockchain is altijd waar. Er is geen onderliggende werkelijkheid die ervan af kan wijken. Het probleem wat hier speelt is hetzelfde: zorg gaat niet over digitale goederen, maar over mensen.

Dit speelt bij de hele kern waar de zorg om draait. Operaties, behandelingen, hulpmiddelen, klachten, ziekten, wonden verzorgen of steunkousen aantrekken: blockchain hiervoor inzetten lijkt weinig waarde toe te voegen. Het probleem met informatie-uitwisseling in de zorg is ofwel dat de informatie helemaal niet beschikbaar is, ofwel dat de beschikbare informatie niet klopt met wat er echt gebeurd is. Het probleem is niet dat malafide partijen stiekem sjoemelen met de medische informatie, en die gecorrumpeerde informatie dan als echt proberen te slijten. Blockchain in de zorg lost een non-probleem op.

Wat kan blockchain in de zorg wel?

Kortom: de problemen die blockchain op kan lossen, zijn helemaal niet de problemen die in de zorg spelen. Zorg gaat in wezen over mensen, gebeurtenissen en fysieke goederen. Dat alles past niet in de blockchain. Uiteraard gaat de zorg deels ook over digitale goederen. Ik heb interessante ideeën gehoord over gebruik van de blockchain voor declaraties of patiënttoestemmingen. Dat zijn digitale zaken, en daar kan de blockchain voor revolutionaire veranderingen zorgen. Maar in de zorg is dat niet de core business: dat zijn patiënten, en gezondheid. Blockchain kan de financiële en verzekeringswereld ontwrichten. Ook de zorg draait niet zonder geld, dus de impact van blockchain op dat deel zal zeker groot zijn. Daar waar het om mensen en behandelingen gaat, zal de impact beperkt zijn.

Voor wie moet besluiten om wel of niet blockchain in te zetten in de zorg is hier een goede vuistregel. Blockchain maakt het mogelijk elkaar te vertrouwen zonder TTP. Vraag je dus af: is een bestaande TTP een obstakel voor vooruitgang? Of: is het ontbreken van een TTP een probleem en zou een TTP iets toe kunnen voegen? Is het antwoord op een van deze vragen ja, overweeg dan blockchain in te zetten. Maar is het antwoord op beide vragen nee, spaart u de duiten! Blockchain zal alleen complexiteit toevoegen en niet bijdragen aan een echte oplossing.

 

AMOQR: Een Actueel Medicatieoverzicht in je portemonnee

Een actueel medicatieoverzicht (AMO) is essentieel voor goede zorg. Bij een opname in een ziekenhuis bijvoorbeeld wordt je gevraagd eerst een AMO op te halen bij je apotheek. Dan wordt, met een medewerker van de apotheek, gekeken of de medicijnen zoals die in het systeem van de apotheker staan, nog kloppen: of je alles nog slikt wat erop staat, misschien gestopt bent met “zo nodig” middelen, of wellicht ook nog iets bij de kruidenier om de hoek hebt gekocht en inneemt. Dat krijg je mee op een of twee A4’tjes. Handig, want zo weet de specialist precies wat je neemt. Alleen: die A4’tjes neem je alleen mee wanneer je ze nodig hebt. Is het niet veel makkelijker een AMO te hebben dat je altijd mee kunt nemen?

Open space

Pas was ik op de Open Space Werkconferentie Medicatieoverdracht. Een inspirerende middag in de mooie Janskerk in Utrecht.

Wie gedacht had een middagje rustig te kunnen gaan zitten luisteren had het mis. De dames van meeuwenroos hebben ons aan het werk gezet, en alsof dat niet genoeg was mochten we een opdracht aan onszelf op een gefrankeerde kaart zetten. Over een maand krijgen we die in onze eigen brievenbus om te zien wat we ervan terecht hebben gebracht. (Anne, Helen, Elline, bij deze: die van mij mogen jullie houden. Opdracht voltooid.)

Een van de ideeën in de groepen was dat ophalen en meenemen van die A4’tjes, of ophalen van medicatie uit het Landelijk Schakelpunt omslachtig is. Iedereen (die dat wil) moet gewoon een actueel medicatieoverzicht bij zich kunnen hebben. In de binnenzak. Altijd. Mobieltje, en apps, werd meteen geroepen. Nu ben ik daar als ICT’er helemaal voor, maar het kan ook laagdrempeliger. Op een visitekaartje. Ik had me voorgenomen uit te zoeken of dat met een QR code ook kan.

Een Actueel Medicatieoverzicht (AMO)

Wanneer je een AMO ophaalt bij je apotheek ziet dat er zo uit:

amo

Je patiëntgegevens staan erop, de apotheker met wie het besproken is wordt genoemd, evenals huidige en recent beëindigde medicatie, eventuele labwaarden (bijvoorbeeld bloedwaarden) en andere zaken die van belang kunnen zijn zoals allergieëen. Tot slot, belangrijk: wie er naar gekeken heeft. De praktijk wijst uit dat het medicatieoverzicht dat de apotheker in het syteem heeft staan vaak niet up to date is, en apothekers die ik sprak zeggen me dat gegevens uit het LSP veel te vaak ook niet volledig zijn. De patiënt zelf weet het beste wat zij of hij slikt (of soms de mantelzorger), dus die moet meekijken om tot een echt AMO met de A van Actueel te komen. (Zie de richtlijn medicatieoverdracht voor de details van het AMO.)

En nu de portemonnee in!

Dat A4’tje past niet zo makkelijk in de portemonnee. En dit overzicht afdrukken op het formaat van een bankpasje levert ook geen leesbaar document op. Een QR-code kan dat wellicht oplossen.

wwwmdg

Hoeveel gegevens passen er eigenlijk in een QR code? Er zijn meerdere formaten (“versions”) met aantal blokjes (“modules”) van 21×21 (version 1) tot 177×177 (version 40). Hoe meer blokjes, hoe meer informatie. Daar komen nog zaken als foutcorrectie en dergelijke bijdie de hoeveelheid informatie beïnvloeden. Een paar rekensommen. Een visitekaartje is 55 mm hoog. Om een QR code heen moet wat witruimte zitten, er blijft dus zo’n 5 centimeter over. Scannen hoeft niet van een billboard, maar kan van dichtbij, dus we kunnen rustig voor een lage foutcorrectie gaan. Dan moet daar een QR code version 27 van 125×125 blokjes met zo’n 2100 alfanumerieke tekens in passen.

Dat lijkt genoeg. Maar ik wil het ook in de praktijk proberen. Ik maak dus een medicatieoverzicht met de patiëntgegevens van mij, zes medicatieregels en één contra-indicatie. Met wat passen en meten worden het 1425 tekens. Alles conform de richtlijn medicatieoverdracht, alleen de layout pas ik wat aan. Die tabellen werken niet goed samen met QR codes, en de icoontjes die in het AMO zitten passen er ook niet in. Dit zijn twee van de zes regels (met fictieve medicatie, aan een glas rode wijn op zijn tijd heb ik voldoende):

-------------------
KENACORT A 40 INJECTIESUSPENSIE 40MG/ML FLACON 5ML
verstrekking
van 1-3-2016 tot 5-6-2016
afgeleverd tot 5-6-2016
1 maal per week 15 milliliter
Dr. Dokter,06010859
-------------------
TRUSOPT OOGDRUPPELS 20MG/ML FLACON 5ML
verstrekking
van 1-3-2016 tot ---
afgeleverd tot 1-6-2016
2 maal per dag 1 druppel
Dr. Dokter,06010859 
-------------------

Met een van de vele onlineapps maak ik een QR code van de 1425 tekens, en download die. Die print ik met mijn huis-tuin-en-keukenprinter op visitekaartformaat. Ik download een QR app op mijn Samsung S4 Mini. Het werkt prima: bij scannen van mijn AMO-visitekaartje staan de gegevens van “mijn” AMO er weer.

20160531_181105

Voor patiënten die erg veel medicatie nemen, of voor het opnemen van labuitslagen zal het printje iets groter worden dan een visitekaartje. Het maximum van een QR code is 4296 tekens, dat is driemaal zoveel informatie als in mijn AMO met patiëntgegevens, zes medicatieregels en één contra-indicatie. Dat zal in de meeste gevallen wel voldoende zijn.

Uiteraard is er niets meer geheim aan dit kaartje wanneer ik mijn portemonnee kwijtraak. Datzelfde geldt overigens voor het papieren AMO in mijn binnenzak. Maar medicatie in een app op de telefoon, die beter beveiligd is, heeft ook nadelen. Wanneer ik een ongeluk krijg, en niet meer aanspreekbaar ben, kan de ambulance of de SEH ook niet meer bij mijn medicatie. Uiteindelijk blijft het een keuze voor iedere burger of ze een AMO met alle informatie bij zich willen dragen of niet. Iemand die medische risico’s loopt, zal het eerder doen, anderen zullen de medische gegevens liever achter slot en grendel laten. Geen reden uiteraard deze keuze niet aan de burger zelf aan te bieden.

AMO everywhere!

Het is natuurlijk geen enkel probleem dit AMOQR af te drukken op het “gewone” AMO. Daar is voldoende ruimte voor. Even uitknippen en in de portemonnee. Afdrukken bij de apotheek op een kartonnen kaartje, of sealen in een plastic hoesje is natuurlijk nog mooier. Altijd het laatste AMO op zak. Welke apotheek komt als eerste met deze extra service voor de patiënt?

amo4

Update 9-6-2016: Vandaag een interessant gesprek gehad met Bart Luiken van 112QR. Ze hebben een vergelijkbare implementatie, i.s.m.  o.a. MS Fonds en Epilepsie Vereniging Nederland. Een kaartje op zak. Niet met een statische QR, maar een dynamische die op een veilige manier toegang geeft tot je kritische gegevens op een website. Geïnteresseerden kunnen daar ook eens kijken naar de mogelijkheden.