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.

3D Printing Myself – or: Do we have a Free Will?

I intend to read two books on free will soon, Samuel Harris’ ‘Free Will’ (which argues that free will is an illusion) and Julian Baggini’s ‘Freedom Regained’ (which argues free will is possible). Before reading those two (on which I will get back here), I wanted to pen down my own ideas on free will, to see whether reading the books will make me change my own views. The problem of free will has bothered me since I studied philosophy (or possibly before), since it seems to lead to either inconsistencies or world views which I find very implausible.

Free will – the idea that we choose our actions voluntarily, based on our own judgment, and that we could have chosen otherwise if we wanted – presupposes the idea of choice: that what we have done in the past could have been otherwise, and our future is not given by the circumstances, but a least partially decided by our own choices. So the question: do we have a free will is dependent on another question: do we have a choice at all. A thought experiment will help to highlight the essence of the problem.

Imagine a perfect 3D printer, capable of copying dead matter as well as living beings. If I were to copy myself, Marc-the-copy would be a perfect copy of Marc-the-original. Marc-the-copy would contain the same molecules, in the same places, the same strands of DNA, the same RNA, the same blood cells, intestinal lining and brain. The same neurons, intertwined in the same way, with the same amounts of neurotransmitter in the same spots, connected with the same axons to the same nerves. If there is still an idea of an ‘original’ and a ‘copy’, where the copy would not be ‘the same’, since there is only one original, we could assume that the original’s molecules would be split evenly amongst both copies, and that the 3D printer would supply each of both copies with the missing molecules, according to the blueprint – the now-gone original.

Next, assume that the 3D printer would print both Marc-copies to identical rooms, again perfect copies of each other. The same table with some coffee and some sandwiches, the same vase of identical roses underneath the same copy of a Vermeer’s Milkmaid. The same bright lightning, the same anonymous waiting room music on the same radio.

Now, what would both copies do? Would they do the same thing or not? Would both pick the ham sandwich, or might one go for ham and the other for tuna? Is it possible that one would skip the sandwiches and go straight for coffee, while the other would have a sandwich first and a coffee later? Could one tune the radio to Adele’s ‘Someone like you’, while the other copy would prefer Chopin’s Nocturnes? And, if you go for the same choice, would both copies do the same thing always? Again and again and again, as long as the environment is exactly the same? So basically: given the exact same material make-up of both individual and environment, would it be possible to have different outcomes when the individual is faced with a choice, or is the outcome of the choice always determined? This is not about determinism ‘light’, where we are bound by our genes and circumstances to be obese, or smart et cetera. That would still allow both copies to sometimes make different choices. This thought experiment is about a very strong determinism: is different action possible at all for both copies?

Let’s go down the possible scenarios, and see the repercussions of each scenario on the possibility of free will.

They would do the same.

That is, always the same. The world we’ve chosen is completely deterministic, at least where human choices are involved. All choices are contained in the material circumstances, and given those, the outcomes are fixed.

This view has some paradoxical consequences. The things we do often seem to make sense. If I want to drive to Paris, and I don’t know the way by heart, I will follow the road signs (or my navigation system nowadays). So if I’m near Brussels, and I see a sign ‘Paris’ with an arrow to an exit on my right hand, I will most likely take that exit. Now, in a deterministic universe, the road signs wouldn’t matter. I would take the right exit anyway, regardless of what the signs say, since my driving choices are predetermined. So whether the sign would point to the left exit for Paris or the right wouldn’t matter. Nothing said or written would matter at all, it seems. I do like to read a novel in the evening, and if the story is good, it gives me a sense of satisfaction. Now, in a deterministic universe, I could read a random collection of letters, a totally nonsensical whole of arbitrary non-words, and still have the same sense of satisfaction if the material circumstances dictated such.
Of course the two universes – one with the sign Paris to the right, and the other to the left, aren’t exactly the same, since at least the paint on both signs is applied differently. The point is this difference cannot explain my taking the right exit. The connection ‘sign to the right’ – ‘taking the right exit’ does only make sense if we suppose that I see the sign, read it, and make a decision based on that information – a decision which could have been otherwise. But exactly this free decision is impossible in a deterministic universe, since there is no choice. So we cannot say things sense because signs to the right trigger human decisions to go to the right, since humans cannot make such decisions.

So why does it all make sense? What are the possible answers to that in a deterministic universe?

It doesn’t make sense

This idea of sense is all an illusion. The road signs don’t influence where I go, nor does the novel I read induce my sense of happiness. That is all an illusion. In fact, many road signs do point to the left while I go right, and what I read is garbage (not in the sense of literary criticism, but in the sense that I do really read random collections of meaningless signs). In a deterministic universe we don’t need consistency between signs and actions, and there is in fact none.

This world view is maybe consistent in itself, but not very consistent with experience. We do feel we take the right exit because of the sign, and we enjoy the novel because of the content. So this view has some explaining left to do, and is very counterintuitive. And it needs explaining why we have the illusion of consistency.

It cannot not make sense

For some reason, a deterministic universe where road signs to Paris would point to the left, while people heading to Paris go right is not possible.
Of course such an observation is very intuitive. It seems most logical that if road signs point to the right, we would go right. But this only an explanation when we do have some degree of choice. It presumes we go right because we see the road sign, and decide to go right. Without that decision, what could possible cause the coherence between road signs and directions taken? If we do not have choices, the road sign to the right could not be the cause of our choice of taking the right exit.
So our choosing so cannot be the explanation of correspondence between signs and actions in a deterministic universe. Let’s see what could be, and what determines the outcomes of our actions.

Matter decides the outcomes

Matter (on a macroscopic level anyway) decides what happen, or at least our actions. Given a powerful enough computer, all our action could be calculated in advance. (Of course we needn’t assume a Newtonian universe. Matter may behave according to the quantum-mechanical uncertainty principle, but this doesn’t influence human behavior. It was only the choice of the two copies which was deterministic in our thought experiment, not necessarily the entire universe.)

But if it is matter that decides the deterministic outcomes of our choices, it is nearly impossible to see why things make sense. We must assume some law of nature which excludes nonsensical combinations, i.e. road signs to Paris to the left and cars heading for Paris going to the right. And this must be the weirdest kind of law possible, different from all laws of nature that we know.

Something else decides the outcomes

You may believe that it is not matter which decides the outcomes, but something else. An omnipotent god, or a universal non-material principle. This is more consistent. It all makes sense because god, (or the universal principle) has decided that things should make sense.

So in this universe we have no free will. Thus universe does make sense. Something (god, a non-material principle) makes it make sense. And this something also decides everything we do, the outcome of all our apparent choices. This universe is still somewhat counterintuitive since we do feel we make the choice to take the right exit ourselves, but this idea of freedom of choice may be an illusion. There are more known illusions of a similar nature. Assuming a god or principle doesn’t explain much: the question goes from ‘why does it all make sense’ to ‘why does a god make it make sense’ – but the world view is consistent in itself.

They would not do the same.

Now if we assume both copies of Marc would not (always) do the same thing, what could cause the difference in behavior?

Something material

We’ve already assumed the copies are the same, as are the rooms they’re in. So where could a material cause for different choices come from?

Something outside the individual

Maybe one could say that both copies are influenced by the universe at large, and they can’t both occupy the same space in that universe. This is a bit tweaking with the assumptions of the argument, which stated that both copies would have the same environment. And of course one can say that that simply is not possible. Still, if something material outside the copies would decide the difference in outcome, then this would be a deterministic universe. Each of the copies could not make another choice, since the outcomes are determined by something material outside. So saying ‘something outside’ makes the choices differ, still doesn’t really allow choice. We’re back at the deterministic world view, only the room has become larger.

Chance events

Maybe our brains are wired in such a way that they contain ‘quantum-mechanical coins’. In each of the two copies, the coins are flipped and one may land heads up, while the other goes for tails. The differences are pure chance. No influence of the individual.

This is a nondeterministic universe, albeit with only random ‘freedom’. There is no pre-determination, but also no real choice – just chance events. Things could have been otherwise, but only through random events. And randomness still doesn’t explain choice. If we flip a coin which decides whether we go right (heads up) or left (tails) and the coin lands heads up, we can say we’ve chosen to flip a coin, but we would never say we’ve chosen to go right. So the quantum-mechanical coin in our heads could explain variation in behavior, but we couldn’t really call it choice. It might explain why things appear to make sense – it the road signs say ‘Turn right for Paris’, our mental make-up might be so that the coin is much, much more likely to flip so that we do turn right.

Non-chance events

This seems hard to imagine. Both copies are the same, materially spoken. They don’t make the same choices. This difference is caused by something material. And this material cause is not a chance event, no throw of the dice.
It’s hard to imagine how pure matter (since in this universe, nothing but matter decides the difference in choice between Marc A. and Marc B.) could lead to any but random differences. Apparently in this universe, matter has some properties which are nondeterministic, but not chance either. It seems this universe assumes some hitherto undetected properties of matter. This is of course not impossible, but not very plausible too. We simply would assume some ‘choice’ of ‘free will’ property of matter itself, to explain our free will.

Something immaterial

Another assumption, if both copies of Marc do not make the same choice, is that the difference in behavior is caused by something nonmaterial.

Something immaterial in the individual

We can assume we have a (nonmaterial) mind, or a soul, or immaterial ‘spirit’. This spirit can make choices, and this causes the different outcomes for both copies of Marc. But how does this spirit influence the matter? This is basically Descartes’ problem. There is nothing in the material theories we have which allows such an interaction between an immaterial spirit and our material body. Somewhere there would need to be a connection, where the immaterial can trigger the material. This is not logically impossible, but still, given what we know, it’s hard to fathom where and how this would happen.

Something immaterial outside the individual.

If a god, or something else immaterial decides the different outcomes, the individual is apparently not free to choose. So, like the case where ‘outside matter’ decides the different outcomes, in this case there is no real choice either, since it is coming from outside. Once the ‘outside’ has made up its mind, there is no possibility for the individual to choose anything other than that what already had been decided outside. Taking a god as the cause of different actions of the two Marc copies does raise the same question as the spirit: where does this god interact with matter? (Note that a deterministic universe does not have this problem: a god could have created this universe from the start so that all outcomes are decided in advance, and wouldn’t need to interact with it after creation.)

Other solutions

We’re not smart enough

Maybe language, and human thought, is not capable of understanding the very concepts we are researching. Maybe ‘free will’ is simply not a consistent concept, and we cannot reason with it in the same way as we can with concepts such as cars, forces of nature, road signs or sandwiches.

An open question is why there is a universe at all – why isn’t there just nothing? I haven’t read any satisfactory answers to this question. The answers fall in two categories. The first assumes something else, god or a law of nature, which needs explaining as well – why is there a god instead of nothing, why is there a law of nature at all? The second does not assume something else, but doesn’t really move beyond the big bang. I believe it is possible that the concept of ‘nothing’ may just not make sense enough to reason with it. We never perceive ‘nothing’, only the absence of other stuff – no light, no people, no planets. But it is not a given that a combination of absences leads to a ‘nothing’ with which we can reason as if it were something. So maybe ‘nothing’ just isn’t a coherent enough concept, and the question ‘why isn’t here nothing’ just doesn’t make sense like ‘why isn’t there coffee’ because ‘nothing’ is not as coherent a concept as ‘coffee’.

In the same way, ‘free will’ may be a concept that’s not coherent enough to allow the kind of reasoning I’ve done with it in this paper. So instead of getting an answer, we must conclude that the question was wrong all the time. I do like this answer, but I have no proof of it either. There is no ‘grand theory’ explaining which concepts can be reasoned with, and which ones cannot. So saying ‘free will’ is an inconsistent concept does amount to assuming something to make the problem go away.

Yet other solutions

There might simply be more than we know. I’ve contrasted ‘material’ versus ‘immaterial’ stuff and more, but there may be more than we know of. I’ve touched upon the possibility of properties of matter yet unknown, and there may simply be stuff (material or not) constituting the universe that we do not know of yet. So maybe there is a free will, in a sensible way, be we still need to discover how or what makes it possible.

(Not a) conclusion

So far, for me, there is no satisfactory conclusion in the free will debate. A deterministic universe, were a god (or universal principle) has planned everything in advance, a has taken care that the world we live in appears to be a sensible one, is – at least – internally consistent.

So is a universe where we do have choice, but the choices are just random events. That’s not enough to constitute what we would normally call ‘free will’, but maybe that’s just how it is. There needn’t be a free will just because we think it’s nice if there is.

A universe with real choices, either chosen by our nonmaterial spirit, or a god, needs to explain how this nonmaterial thing interacts with matter ‘on the go’ – i.e. not from the start of the universe, but to allow for real choices once the material conditions are given. What we know of physics doesn’t offer any real possibilities here – but our knowledge of physics might be incomplete here.

And the question could be wrong because the concept of ‘free will’ is not consistent – but why would it, and how could we decide which concepts are consistent and which ones not?

Code Generation Strategies for ART DECOR

Last time I wrote about code generation using ART DECOR. This time we’ll look a some more code generation, and then consider various strategies for code generation.

In the previous post we saw how to generate HTML for a user interface for a transaction in ART DECOR. We can do the same for database code.

SQL

    --DROP TABLE vs_measured_by CASCADE;
    CREATE TABLE vs_measured_by (
        vs_measured_by_id int NOT NULL PRIMARY KEY,
        code varchar(255) NOT NULL,
        codeSystem varchar(255) NOT NULL,
        displayName varchar(255) NOT NULL
        );
        
    INSERT INTO vs_measured_by (vs_measured_by_id, code, codeSystem, displayName)
    VALUES (1, 'P', '2.16.840.1.113883.3.1937.99.62.3.5.1', 'Patient');
        
    INSERT INTO vs_measured_by (vs_measured_by_id, code, codeSystem, displayName)
    VALUES (2, 'T', '2.16.840.1.113883.3.1937.99.62.3.5.1', 'Home care provider');
        
    INSERT INTO vs_measured_by (vs_measured_by_id, code, codeSystem, displayName)
    VALUES (3, 'H', '2.16.840.1.113883.3.1937.99.62.3.5.1', 'GP');
        
    INSERT INTO vs_measured_by (vs_measured_by_id, code, codeSystem, displayName)
    VALUES (4, 'M', '2.16.840.1.113883.3.1937.99.62.3.5.1', 'Personal network');
        
    --DROP TABLE measurement_message CASCADE;
    CREATE TABLE measurement_message (
          measurement_message_id int NOT NULL PRIMARY KEY
        );
        
    --DROP TABLE measurement CASCADE;
    CREATE TABLE measurement (
          measurement_id int NOT NULL PRIMARY KEY
        , measurement_message_id int NOT NULL  REFERENCES measurement_message(measurement_message_id)
        , weight float
        , weight_unit char(96) NOT NULL
        , weight_gain boolean
        , length float
        , length_unit char(96)
        , datetime timestamp
        , measured_by int REFERENCES vs_measured_by(vs_measured_by_id)
        , comments varchar(255)        
    );
    
    --DROP TABLE weight_gain_data CASCADE;
    CREATE TABLE weight_gain_data (
          weight_gain_data_id int NOT NULL PRIMARY KEY
        , measurement_id int NOT NULL REFERENCES measurement(measurement_id)
        , size_weight_gain float
        , size_weight_gain_unit char(96)
        , cause_weight_gain varchar(255)        
    );
    
    --DROP TABLE person CASCADE;
    CREATE TABLE person (
          person_id int NOT NULL PRIMARY KEY
        , measurement_message_id int NOT NULL  REFERENCES measurement_message(measurement_message_id)
        , name varchar(255) NOT NULL
        , bsn varchar(255) NOT NULL
        , date_of_birth varchar(255)
        , number_of_children varchar(255)        
    );

XSL

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema" exclude-result-prefixes="xs" version="2.0" >
    
    <xsl:output method="text" indent="no"/>
    
    <xsl:template match="/">
        <xsl:apply-templates select="//valueSet"/>
        <xsl:apply-templates select="@*|node()"/>
    </xsl:template>
    
    <xsl:template match="dataset">
    --DROP TABLE <xsl:value-of select="@shortName"/> CASCADE;
    CREATE TABLE <xsl:value-of select="@shortName"/> (
          <xsl:value-of select="@shortName"/>_id int NOT NULL PRIMARY KEY
        );
        <xsl:apply-templates/>        
    </xsl:template>

    <xsl:template match="concept[@type='group']">
    --DROP TABLE <xsl:value-of select="implementation/@shortName"/> CASCADE;
    CREATE TABLE <xsl:value-of select="implementation/@shortName"/> (
          <xsl:value-of select="implementation/@shortName"/>_id int NOT NULL PRIMARY KEY
        <xsl:if test="local-name(..) = 'dataset'">, <xsl:value-of select="../@shortName"/>_id int NOT NULL  REFERENCES <xsl:value-of select="../@shortName"/>(<xsl:value-of select="../@shortName"/>_id)</xsl:if>
        <xsl:if test="local-name(..) = 'concept'">, <xsl:value-of select="../implementation/@shortName"/>_id int NOT NULL REFERENCES <xsl:value-of select="../implementation/@shortName"/>(<xsl:value-of select="../implementation/@shortName"/>_id)</xsl:if>
        <xsl:apply-templates select="concept[@type='item']"/>        
    );
    <xsl:apply-templates  select="concept[@type='group']"/>        
    </xsl:template>

    <xsl:template match="concept[@type='item']">
        , <xsl:value-of select="implementation/@shortName"/>
        <xsl:choose>
            <xsl:when test="valueDomain/@type='code'"> int REFERENCES <xsl:value-of select="translate(valueSet/@name, '-', '_')"/>(<xsl:value-of select="translate(valueSet/@name, '-', '_')"/>_id)</xsl:when>
            <xsl:when test="valueDomain/@type='boolean'"> boolean</xsl:when>
            <xsl:when test="valueDomain/@type='decimal'"> float</xsl:when>
            <xsl:when test="valueDomain/@type='datetime'"> timestamp</xsl:when>
            <xsl:when test="valueDomain/@type='quantity'"> float
        , <xsl:value-of select="implementation/@shortName"/>_unit char(96)</xsl:when>
            <xsl:otherwise> varchar(255)</xsl:otherwise>
        </xsl:choose>
        <xsl:if test="@isMandatory='true'"> NOT NULL</xsl:if>
    </xsl:template>

    <xsl:template match="valueSet">
    --DROP TABLE <xsl:value-of select="translate(@name, '-', '_')"/> CASCADE;
    CREATE TABLE <xsl:value-of select="translate(@name, '-', '_')"/> (
        <xsl:value-of select="translate(@name, '-', '_')"/>_id int NOT NULL PRIMARY KEY,
        code varchar(255) NOT NULL,
        codeSystem varchar(255) NOT NULL,
        displayName varchar(255) NOT NULL
        );
        <xsl:for-each select="conceptList/concept">
    INSERT INTO <xsl:value-of select="translate(../../@name, '-', '_')"/> (<xsl:value-of select="translate(../../@name, '-', '_')"/>_id, code, codeSystem, displayName)
    VALUES (<xsl:value-of select="@localId"/>, '<xsl:value-of select="@code"/>', '<xsl:value-of select="@codeSystem"/>', '<xsl:value-of select="name"/>');
        </xsl:for-each>
    </xsl:template>

    <xsl:template match="@*|node()">
        <xsl:apply-templates select="@*|node()"/>
    </xsl:template>
</xsl:stylesheet>

XML

<dataset id="2.16.840.1.113883.3.1937.99.62.3.1.1" effectiveDate="2012-05-30T11:32:36" statusCode="draft" versionLabel="" transactionId="2.16.840.1.113883.3.1937.99.62.3.4.2" transactionEffectiveDate="2012-09-05T16:59:35" shortName="measurement_message"><!--
 This is a view of the transaction view of Measurement message containing DECOR specifications for a transaction or dataset in a single, hierarchical view. 
 All inheritances are resolved, for transactions the dataset is filtered for those concepts occurring in the transaction.
 Valuesets are contained within the concept for easy reference. 
 Xpaths are calculated on a best effort basis. The should be considered a starting point for application logic, not an endpoint. -->
    <name language="en-US">Measurement message</name>
    <desc language="en-US">Measurement message test</desc>
    <concept minimumMultiplicity="0" maximumMultiplicity="*" isMandatory="false" id="2.16.840.1.113883.3.1937.99.62.3.2.1" statusCode="cancelled" effectiveDate="2012-05-30T11:32:36" type="group">
        <name language="en-US">Measurement</name>
        <desc language="en-US">Measurement of body weight on a specific date</desc>
        <implementation shortName="measurement">
            <templateLocation></templateLocation>
        </implementation>
        <concept minimumMultiplicity="1" maximumMultiplicity="1" conformance="M" isMandatory="true" id="2.16.840.1.113883.3.1937.99.62.3.2.3" statusCode="cancelled" effectiveDate="2011-01-28T00:00:00" type="item">
            <name language="en-US">Weight</name>
            <desc language="en-US">Weight measurement</desc>
            <implementation shortName="weight">
                <templateLocation></templateLocation>
            </implementation>
            <valueDomain type="quantity">
                <property unit="kg" minInclude="25" maxInclude="240"></property>
            </valueDomain>
            <terminologyAssociation conceptId="2.16.840.1.113883.3.1937.99.62.3.2.3" code="27113001" codeSystem="2.16.840.1.113883.6.96" displayName="Body weight"></terminologyAssociation>
        </concept>
        <concept minimumMultiplicity="0" maximumMultiplicity="1" isMandatory="false" id="2.16.840.1.113883.3.1937.99.62.3.2.13" statusCode="cancelled" effectiveDate="2011-01-28T00:00:00" type="item">
            <name language="en-US">Weight gain</name>
            <desc language="en-US">Is there a weight gain?</desc>
            <implementation shortName="weight_gain">
                <templateLocation></templateLocation>
            </implementation>
            <valueDomain type="boolean"></valueDomain>
        </concept>
        <concept minimumMultiplicity="0" maximumMultiplicity="1" conformance="C" isMandatory="false" id="2.16.840.1.113883.3.1937.99.62.3.2.18" statusCode="cancelled" effectiveDate="2011-01-28T00:00:00" type="group">
            <name language="en-US">Weight gain data</name>
            <desc language="en-US">Weight gain data</desc>
            <implementation shortName="weight_gain_data">
                <templateLocation></templateLocation>
            </implementation>
            <condition minimumMultiplicity="1" maximumMultiplicity="1" conformance="M" isMandatory="true">Bij gewichtstoename</condition>
            <condition minimumMultiplicity="" maximumMultiplicity="" conformance="NP" isMandatory=""></condition>
            <concept minimumMultiplicity="0" maximumMultiplicity="1" isMandatory="false" id="2.16.840.1.113883.3.1937.99.62.3.2.19" statusCode="cancelled" effectiveDate="2011-01-28T00:00:00" type="item">
                <name language="en-US">Size weight gain</name>
                <desc language="en-US"></desc>
                <implementation shortName="size_weight_gain">
                    <templateLocation></templateLocation>
                </implementation>
                <valueDomain type="quantity">
                    <property unit="gram"></property>
                </valueDomain>
            </concept>
            <concept minimumMultiplicity="0" maximumMultiplicity="1" isMandatory="false" id="2.16.840.1.113883.3.1937.99.62.3.2.20" statusCode="cancelled" effectiveDate="2011-01-28T00:00:00" type="item">
                <name language="en-US">Cause weight gain</name>
                <desc language="en-US"></desc>
                <implementation shortName="cause_weight_gain">
                    <templateLocation></templateLocation>
                </implementation>
                <valueDomain type="string"></valueDomain>
            </concept>
        </concept>
        <concept minimumMultiplicity="0" maximumMultiplicity="1" isMandatory="false" id="2.16.840.1.113883.3.1937.99.62.3.2.15" statusCode="cancelled" effectiveDate="2011-01-28T00:00:00" type="item">
            <name language="en-US">Length</name>
            <desc language="en-US">Body length</desc>
            <implementation shortName="length">
                <templateLocation></templateLocation>
            </implementation>
            <valueDomain type="quantity">
                <property unit="m" minInclude="0" maxInclude="3" fractionDigits="2"></property>
                <property unit="cm" minInclude="0" maxInclude="300" fractionDigits="0!"></property>
            </valueDomain>
        </concept>
        <concept minimumMultiplicity="0" maximumMultiplicity="1" isMandatory="false" id="2.16.840.1.113883.3.1937.99.62.3.2.2" statusCode="cancelled" effectiveDate="2011-01-28T00:00:00" type="item">
            <name language="en-US">Datetime</name>
            <desc language="en-US">Date of the measurement</desc>
            <implementation shortName="datetime">
                <templateLocation></templateLocation>
            </implementation>
            <valueDomain type="datetime"></valueDomain>
            <terminologyAssociation conceptId="2.16.840.1.113883.3.1937.99.62.3.2.2" code="DM" codeSystem="2.16.840.1.113883.3.1937.99.62.3.5.2" displayName="Datum meting"></terminologyAssociation>
        </concept>
        <concept minimumMultiplicity="0" maximumMultiplicity="1" isMandatory="false" id="2.16.840.1.113883.3.1937.99.62.3.2.5" statusCode="cancelled" effectiveDate="2011-01-28T00:00:00" type="item">
            <name language="en-US">Measured by</name>
            <desc language="en-US">Person who performed the measurement</desc>
            <implementation shortName="measured_by">
                <templateLocation></templateLocation>
            </implementation>
            <valueDomain type="code">
                <conceptList id="2.16.840.1.113883.3.1937.99.62.3.2.5.0">
                    <concept id="2.16.840.1.113883.3.1937.99.62.3.2.5.1">
                        <name language="en-US">Patient</name>
                    </concept>
                    <concept id="2.16.840.1.113883.3.1937.99.62.3.2.5.2">
                        <name language="en-US">Home care provider</name>
                    </concept>
                    <concept id="2.16.840.1.113883.3.1937.99.62.3.2.5.3">
                        <name language="en-US">GP</name>
                    </concept>
                    <concept id="2.16.840.1.113883.3.1937.99.62.3.2.5.4">
                        <name language="en-US">Personal network</name>
                    </concept>
                </conceptList>
            </valueDomain>
            <valueSet id="2.16.840.1.113883.3.1937.99.62.3.11.5" effectiveDate="2012-07-25T15:22:56" name="demo1-meting-door" displayName="demo1-meting-door" statusCode="draft">
                <terminologyAssociation conceptId="2.16.840.1.113883.3.1937.99.62.3.2.5.0" valueSet="demo1-meting-door"></terminologyAssociation>
                <conceptList id="2.16.840.1.113883.3.1937.99.62.3.2.5.0">
                    <concept localId="1" code="P" codeSystem="2.16.840.1.113883.3.1937.99.62.3.5.1" displayName="Patiënt" level="0" type="A">
                        <name language="en-US">Patient</name>
                    </concept>
                    <concept localId="2" code="T" codeSystem="2.16.840.1.113883.3.1937.99.62.3.5.1" displayName="Thuiszorg" level="0" type="S">
                        <name language="en-US">Home care provider</name>
                    </concept>
                    <concept localId="3" code="H" codeSystem="2.16.840.1.113883.3.1937.99.62.3.5.1" displayName="Huisarts" level="0" type="D">
                        <name language="en-US">GP</name>
                    </concept>
                    <concept localId="4" code="M" codeSystem="2.16.840.1.113883.3.1937.99.62.3.5.1" displayName="Family care" level="0" type="L">
                        <name language="en-US">Personal network</name>
                    </concept>
                </conceptList>
            </valueSet>
            <terminologyAssociation conceptId="2.16.840.1.113883.3.1937.99.62.3.2.5" code="MD" codeSystem="2.16.840.1.113883.3.1937.99.62.3.5.2" displayName="Meting door"></terminologyAssociation>
        </concept>
        <concept minimumMultiplicity="0" maximumMultiplicity="*" isMandatory="false" id="2.16.840.1.113883.3.1937.99.62.3.2.17" statusCode="cancelled" effectiveDate="2012-09-09T16:06:28" type="item">
            <name language="en-US">Comments</name>
            <desc language="en-US"></desc>
            <implementation shortName="comments">
                <templateLocation></templateLocation>
            </implementation>
            <valueDomain type="text"></valueDomain>
        </concept>
    </concept>
    <concept minimumMultiplicity="1" maximumMultiplicity="1" conformance="M" isMandatory="true" id="2.16.840.1.113883.3.1937.99.62.3.2.6" statusCode="draft" effectiveDate="2012-05-30T14:18:23" type="group">
        <name language="en-US">Person</name>
        <desc language="en-US">Person</desc>
        <implementation shortName="person">
            <templateLocation></templateLocation>
        </implementation>
        <concept minimumMultiplicity="1" maximumMultiplicity="1" conformance="M" isMandatory="true" id="2.16.840.1.113883.3.1937.99.62.3.2.4" statusCode="draft" effectiveDate="2012-05-30T14:18:23" type="item">
            <name language="en-US">Name</name>
            <desc language="en-US">Name of the person</desc>
            <implementation shortName="name">
                <templateLocation></templateLocation>
            </implementation>
            <valueDomain type="complex"></valueDomain>
        </concept>
        <concept minimumMultiplicity="1" maximumMultiplicity="1" conformance="M" isMandatory="true" id="2.16.840.1.113883.3.1937.99.62.3.2.7" statusCode="draft" effectiveDate="2012-05-30T14:18:23" type="item">
            <name language="en-US">BSN</name>
            <desc language="en-US">Dutch Social Security Number</desc>
            <implementation shortName="bsn">
                <templateLocation></templateLocation>
            </implementation>
            <valueDomain type="identifier"></valueDomain>
        </concept>
        <concept minimumMultiplicity="0" maximumMultiplicity="1" isMandatory="false" id="2.16.840.1.113883.3.1937.99.62.3.2.8" statusCode="draft" effectiveDate="2012-05-30T14:18:23" type="item">
            <name language="en-US">Date of birth</name>
            <desc language="en-US">Date of birth of the person</desc>
            <implementation shortName="date_of_birth">
                <templateLocation></templateLocation>
            </implementation>
            <valueDomain type="date"></valueDomain>
        </concept>
        <concept minimumMultiplicity="0" maximumMultiplicity="1" isMandatory="false" id="2.16.840.1.113883.3.1937.99.62.3.2.14" statusCode="deprecated" effectiveDate="2012-05-30T14:18:23" type="item">
            <name language="en-US">Number of children</name>
            <desc language="en-US">Number of children</desc>
            <implementation shortName="number_of_children">
                <templateLocation></templateLocation>
            </implementation>
            <valueDomain type="count"></valueDomain>
        </concept>
    </concept>
</dataset>

Like in the HTML generation, the XSLT used to generate the code operates on the output of RetrieveTransaction, and is rather small itself. And, like before, this is not a complete code generator yet: not all datatypes are included etc., so only use this as the start for your own code generators. This generated SQL (tested on PostgreSQL) implements the following database model:

 ada-codegen-dbEach concept group becomes a table, value sets (vs-measured-by) get their own table, which is populated by the rows in the value set.

vs-table

If we hook up some middleware, which can be pretty generic, the middleware, the HTML UI and the database would be a complete application.

Some caveats for real-world usage:

  1. It’s probably better to derive the SQL datatypes from the HL7v3 datatypes in RetrieveTransaction (only possible when HL7v3 is the target, and specs are complete). For more information on generating SQL from HL7v3 datatypes, see RIMBAA_MGRID_HL7v3_Datatypes.pdf for a thorough approach.
  2. Value sets here get their own table. Another approach is to have one table for all value sets, with extra columns for value set name or id. Take care: the approach I’ve chosen uses artificial primary keys in de value set table (with values 1, 2, 3…). This works well for a single version, but what’s constant over several versions of a message is the combination of code and codeSystem. So if you follow my approach, make sure to keep the primary keys constant over time.
  3. I simply generated a separate table for each concept group. It’s easy to improve over that approach: groups which are 0..1 or 1..1 do not need their own table. Basically, the generated database is split in more tables than necessary.

The next question is what the best strategies for code generation along the lines I’ve sketched are. Of course it’s possible to generate an entire application, but that would be suboptimal. ART DECOR (usually, not necessarily) models interchange, so messaging between applications, and not static information models. The requirements for a database are as a rule not covered by interchange models. So while this approach is possible, it would probably need an augmented underlying model.

A better approach is to use code generation as a messaging layer between your own application and the outside world. Parse incoming messages and store them in temporary tables. RetrieveTransaction already contains XPath expressions which point to the right locations in the incoming XML (not 100% complete though, so use as a starting point). Then populate your own DB from the temporary tables, and empty the latter.

strategy-1

This is a very flexible model: when there is a new version of the messaging standard, simply re-generate the insulating layer with generated tables. This will enable you to read new messages without too much ado. The conversion to the proprietary DB will need some updating, of course: there is a new version of the message, so things will have changed. Still, the prorietary DB will be insulated from many changes to the messaging format itself, and the logic which needs updating will be minimized.

Another strategy is to use code generation to generate form parts which do not have corresponding fields in your own database. Such a strategy would involve:

  • generate an HTML form from RetrieveTransaction;
  • prepopulate the form with all the data which already is in your own database;
  • present the form to the user (embedded within your own application);
  • have the user complete the information which is not in your database;
  • generate a message, and send it.

This strategy corresponds well to cases where for instance generic patient data are already in your database, but additional information is needed for some report which needs to be sent. Again, if a new version of the report and message is coming along, this approach ensures only minimal changes to the underlying logic.

Code generation is already used in many projects in the Netherlands, both to generate UI and database logic, as well as for data extraction. All in all, ART DECOR provides all the tools needed to leverage your applications with code generation, and thus implement exchanges in a quick and robust fashion.

Mijn medisch dossier is van mij! Of toch niet?

Je hoort het met enige regelmaat. “Het is eigenlijk heel simpel: het dossier van een patiënt is eigendom van die patiënt! En niet van anderen, zoals de zorgverlener.” Maar zo eenvoudig is het niet.

Om te beginnen bestaat er in Nederland geen “eigendom” van intellectuele gegevens. Op het fysieke dossier kan wel eigendomsrecht rusten, maar in deze tijd van digitale dossiers is dat vrij betekenisloos geworden. Een digitaal dossier is dus niemands juridische eigendom. (Zie ook: ‘Van wie is het dossier’, Anton Ekker, Nictiz 2010.) Er is hoogstens sprake van auteursrecht, maar daarop wordt bij medische dossiers zelden of nooit een beroep gedaan. Prima, zal de tegenwerping zijn, misschien klopt dat in technische zin wel, maar dat is juridische haarkloverij. Moreel gezien is er maar één iemand eigenaar van het dossier, en dat is de patiënt! Maar nee, ook dat klopt niet.

Neem een simpel voorbeeld. Mijn arts schrijft mij een recept uit voor 30 keer 75 mg Nortrilen. Dat recept maakt deel uit van mijn medisch dossier. Maar mag ik nu naar eigen inzicht dat recept wijzigen, en die 30 veranderen in 300? De Wet op de Geneesmiddelenvoorziening stelt dat een recept door een arts ondertekend moet zijn. Wat ik dus ook zelf aanpas in een dossier, een recept is het daarna niet meer. Zo zal een arts ook niet willen dat ik in “mijn” dossier de diagnose obstipatie aanpas wanneer ik vermoed dat er toch wel wat ernstigers dan dat aan de hand zal zijn. (Wanneer een patiënt het niet eens is met een diagnose, heeft deze wel het recht een eigen verklaring aan het dossier toe te laten voegen.) En wanneer ik een bloedwaarde in een laboratoriumuitslag aanpas, is dat geen laboratoriumuitslag meer, maar gewoon een kladje waarin ik zelf wat gerommeld heb. Wat is dat nog voor “eigenaarschap”, wanneer ik de gegevens niet aan mag passen?

Zelfs het (laten) verwijderen van gegevens uit mijn dossier mag niet altijd. Meestal heb ik dat recht wel, maar niet als een aanmerkelijk belang van een derde zich daartegen verzet. Zo’n  belang kan bijvoorbeeld de arts zelf hebben. Wanneer ik een klacht over de arts indien bij een tuchtcollege, kan de arts zijn dossier nodig hebben om zich te verdedigen, en hoeft het zolang de zaak loopt, niet te vernietigen wanneer ik daarom vraag.

Kortom, ik heb het recht niet “mijn” dossier naar eigen inzicht te wijzigen, en onder omstandigheden kan ik het zelfs niet verwijderen. Wat voor een eigendom is dat? De feitelijke situatie is natuurlijk anders. Juridisch is er geen sprake van eigendomsrechten, en in lossere zin is het eigendom gedeeld:  de zorgverlener heeft het deels geschreven, en de medische inhoud is de verantwoordelijkheid van de zorgverlener.

Uiteraard kan ik prima spreken over “mijn medisch dossier”, maar dan in de zin van “over mij”, niet “van mij”. De essentie van “mijn dossier” is dan ook ten eerste dat ik mag bepalen wat ermee gebeurt: wie het in mag zien, wat er uit verwijderd wordt (met een klein voorbehoud om anderen te beschermen), en uiteraard: dat ik er zelf bij mag! Niet een beetje, niet een deel, maar helemaal. Dat is in Nederland in de praktijk nog niet altijd goed geregeld. Daarover een andere keer meer.