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.

 

SOAP over REST

Suppose I want to order 100,000 pieces of your newest, ultra-sleek geek gadgets. We negotiate the price etc., and you send me a proposed contract. I agree, and return the contract. Blessed with a healthy skepticism towards all new technologies, we decide to transfer all documents on paper, and since the contract is very important to both of us, I return it using the most trusted courier service available, with parcel-tracking and armored trucks and all. Yet I do not sign the contract. Will you honor it and send me the goods? I doubt it. Yet this is the level of protection HTTPS offers.

With REST, based on the workings of the Web, HTTPS is the standard choice for safe transport. Yet HTTPS only secures the transport, the pipe. Once a message is delivered on the other end, it is simple text, or xml, or whatever format we choose again. Of the signatures used to establish the secure session, nothing remains with the message. We can use client certificates, so both server and client authenticate themselves, but is still only for the pipe, not for the messages. What you want for real contracts are message signatures.

There are several options in REST to solve the problem. One of them is to simply hijack the WS-Security spec of the WS-* stack. Add a soap:Envelope element with the appropriate wss headers to the contract message, and send the resulting xml in a RESTful way to the other party. Maybe this is not 100% WS-Security compliant and there are some dependencies on SOAP or WSDL or other WS-* specs which we do not honor (and maybe not, I haven’t combed the spec for it), but hey, if we squint enough that shouldn’t be much of a practical problem.

Such a coupling of REST and appropriate WS-* specs does seem promising – unless one is tightly in the WS-*-is-evil-by-default camp. It has an immediate consequence: there is almost nothing WS-* can do and REST cannot do – safe travel over non-HTTP connections and a few others. Bill de hÓra wrote: “And do not be surprised to see specific WS-* technologies and ideas with technical merit, such as SAML and payload encryption, make an appearance while the process that generated them is discarded.”

There is a general lesson to be extracted as well: if something belongs with the payload, store it in the payload. HTTP headers are fine for transport, eh, transfer headers but not for anything which inherently belongs with the message payload. HTTP headers should be discardable after the HTTP method completes. Rule of thumb: if you want to keep it after reception, payload header. If not, HTTP header.

When REST advantages weigh less…

There are two interesting posts by Stefan Tilkov WS-* Advantages and Stuart Charlton What are the benefits of WS-* or proprietary services? on when to use WS-* instead of REST.

Stu writes: “When you want a vendor independent MOM for stateful in-order, reliable, non-idempotent messages, and don’t have time or inclination to make your data easily reused… ”

We could reverse this argument: when do the advantages of REST (caching, linking and bookmarking to name some) matter less? For one of my customers I design part of the Dutch national healthcare exchange, which is used to exchange patient data between care providers. Nearly all messages involved include the patient id: therefore most messages are pretty unique, and tied to a particular care context: say a patient visits his GP, or collect medication from his apothecary. In such exchanges, caching doesn’t matter at all. It is possible some data (a patients medication history) is retrieved twice when the patient visits two doctors after another, but in general in such an infrastructure it’s better to simple turn off caching, GET the data twice in the outlier cases and not be bothered by the overhead involved in caching.

It seems to me a lot of business exchanges (say order/invoice such as UBL does) share this property of mostly unique messages, whereas cases such as Google or Amazon APIs clearly will benefit a lot from caching. The distinction is between messaging (sending letters) and publishing (newspapers).
I’m not advocating REST or WS-* here for any particular application, but thinking about where the benefits of REST matter most is another way of thinking choosing technologies. For publishing, REST with all the optimizations of GET is the option to look at first. For messaging it’s less obvious where to start.