(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.

 

Zie mijn blog op Trendition: Zijn standaarden in de zorg wel zo’n goed idee?

I’ve made a nice overview of available presentations and course modules. All slides available online! Take a look and contact me for tailor-made in-house courses.

Dan Appleman and Jeff Atwood both wrote a blog “Can You Really Rent a Coder?” about coding auctions such as  Elance,  RentACoder and guru.com, which make coders bid on projects worldwide. Typically a lot of small, low-paid projects appear there and those sites have had their share of bad comments.

But they can work, just follow these rules:
– if you live in a rich country, be a buyer, not a bidder;
– subcontract parts of your projects, tell your customer, and tell them you can charge less because of this: they’ll appreciate you for it;
– subcontract technical parts only: a Russian will understand HTTP or XML, but not Dutch law;
– expect to spend a lot of time on specs and communication;
– use a few iterations to polish out parts where your specs were unclear or misinterpreted;
– test a lot and inspect the source code;
– never go for the lower bids: they’re always crap;
– build a longer relationship with coders you have good experience with, give them bonuses and follow-up projects.

The Dutch government [1] is propagating accessible websites – a truly laudable initiative (basically a Dutch application of the Web Content Accessibility Guidelines 1.0). Their website itself though commits one of the worst web design crimes right in the very Web Guidelines themselves: they are available in … not HTML or XHTML as one would expect, but PDF, MS Word and OpenOffice (though there is a short summary in HTML, but that lacks all the details).

Let’s look up some authority such as usability guru Jakob Nielsen‘s Top Ten Mistakes in Web Design. Indeed, in 2007 “PDF files for Online Reading” is still there as Mistake #2. Or to quote some other authority, the Dutch Web Guidelines themselves: “Checkpoint 11.1: Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported.” (Apologies for not being able to link to that Checkpoint, PDF does not allow me to do that.) I don’t think PDF, MS Word or even OO qualify as W3C technology. (X)HTML is perfectly adequate for this publication – one can always provide an alternative PDF for printing if desired. And HTML of course allows linking to, bookmarking, consistent navigation yada yada yada, you know, the stuff that made the Web great.

They do provide the Guidelines in both English and Dutch. But the Dutch version is only in MS Word – sigh…

The initiative is great, especially since it qualifies websites and thus truly propagates accessible web sites. And they have a nice test tool. (My site, which is plain WordPress, scores a meagre 38/45. I’ll have to check that.) But please, do it right next time. Eat your own dogfood and use HTML.

[1] Technically drempelvrij.nl is an independent foundation, in practice the Dutch government is a major stakeholder. For their internal guidelines the government does much better, there they have everything in HTML next to PDF.

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.