Ter voorbereiding van het publieke informatieberaad van 19 april 2021 is een notitie opgesteld met de naam ‘Versnelling & verbetering digitale communicatie in de zorg’. In de notitie worden mogelijke oorzaken beschreven voor gebrekkige voortgang binnen veel focusprogramma’s en VIPP programma’s. Penvoerder van de notitie is Zorgverzekeraars Nederland. Voor zover mij bekend is de notitie niet publiekelijk beschikbaar maar ze is wel breed, zonder embargo, gedeeld.
De notitie is om meerdere redenen lezenswaardig en zal zowel herkenning als verbazing oproepen, afhankelijk van het perspectief van de lezer. Eén van de thema’s die de notitie benoemt als oorzaak van onvoldoende concrete vooruitgang van digitale communicatie in de zorg is ‘onvoldoende ZIB-compliancy van systemen’. Een belangrijk thema, mede gezien de hoofdrol voor Zorg Informatie Bouwstenen (ZIB’s) in de Nederlandse pogingen tot standaardisatie van zorginformatie. Ondanks onvoldoende uitwerking van het begrip ‘ZIB-compliancy’ herken ik het beeld dat ZN schetst: ZIB’s worden door leveranciers niet of niet eenduidig geïmplementeerd in hun systemen. Ik herken het beeld maar verbaas mij over de teleurstelling. Zagen we dit echt niet aankomen?
In deze blog leg ik uit wat een ZIB is, wordt ingegaan op het begrip ‘ZIB-compliancy’ en wordt uitgelegd waarom brede (niet usecase specifieke) ZIB-compliancy binnen de huidige uitgangspunten onhaalbaar en zelfs onwenselijk is.
Wat is een ZIB
Een Zorg Informatie Bouwsteen is een zeer nauwkeurige beschrijving van een voor de zorg belangrijk uniek concept, zoals een patiënt, een bloeddruk of een probleem. Zij beschrijft de verschillende attributen van het concept (zoals onderdruk en bovendruk en positie van de patiënt in het geval van een bloeddruk) en de eisen waaraan die attributen moeten voldoen, zoals het gegevenstype (tekst, code, getal, etc.) en welke waarden wel en niet zijn toegestaan. Ieder uniek concept wordt als Zorg Informatie Bouwsteen beschreven, los van de andere al bestaande ZIB’s.
De beschrijving is zo precies dat zij door een programmeur zou kunnen worden gebruikt om software te maken die gegevens opslaat en presenteert of communiceert. Het idee zou kunnen ontstaan dat als iedereen software maakt volgens de ZIB specificaties, alle systemen de betreffende concepten op dezelfde manier opslaan, presenteren en communiceren. Wellicht dat de bedenkers van de ZIB’s die verwachting hadden over hoe leveranciers de ZIB’s in hun systemen inbouwen: de ZIB’s als specificatie voor software en opslagstructuren. Die verwachting is echter niet in overeenstemming met hoe software werkt en wordt gemaakt.
Beperkingen in de ZIB methodiek
Voor de ontwikkeling van software volstaat het niet om ieder individueel concept op zichzelf te specificeren en losstaand te programmeren. Software die op die manier wordt ontwikkeld is onsamenhangend en zal al snel niet meer aan de eisen van eindgebruikers voldoen. Stel dat verschillende teams los van elkaar software maken voor het concept ‘bloeddruk’ en het concept ‘polsfrequentie’, dan zal dit leiden tot:
Aparte opslag (zoals database tabellen) voor bloeddruk en polsfrequentie.
Op twee plekken software voor het vastleggen van eigenschappen die beide concepten gemeen hebben, zoals de auteur, patiënt en meetdatum / -tijd.
Op twee plekken software voor het ontwikkelen van configuratie, zoals hoe ongeldige of gevaarlijke waarden getoond worden en hoe grafieken getoond worden.
Op twee plekken software voor de presentatie (en invoer en validatie) van gegevens en de communicatie van gegevens.
Als gevolg van het bovenstaande i.g.v. wijzigingen in de definitie van een ZIB onbeheersbare wijziging in de versplinterde software en opslagstructuren.
Het aantal ZIB’s dat men kan bedenken is enorm, zodat de beschreven problemen exponentieel zullen groeien. Deze aanpak leidt tot zeer hoge kosten omdat veel gelijkvormige onderdelen steeds opnieuw moeten worden geprogrammeerd en onderhouden. Maar ook slecht of traag functionerende systemen door de versplinterde opslag van gegevens over verschillende tabellen in databases, is een reële consequentie. En het zal leiden tot inflexibele systemen waarbij steeds een programmeur nodig is om gegevens uit verschillende ZIB’s in samenhang uit de database op te halen en te presenteren aan de eindgebruiker of te verzenden naar een ander systeem.
De aanpak van software engineers
De software engineering discipline buigt zich al decennia lang over dit soort problemen. Om de beschreven versnippering te voorkomen worden samenhangende architecturen ontwikkeld. Vaak bestaan dit soort architecturen uit meerdere lagen:
Een in hoge mate abstract informatiemodel dat wordt gebruikt om de daadwerkelijke software en opslagstructuren te ontwikkelen. In een dergelijk model komen begrippen als ‘bloeddruk’ en ‘polsfrequentie’ niet voor, maar wel begrippen als ‘observatie’ en ‘evaluatie’ en ‘actie’. Of nog abstracter, begrippen als ‘item’ en ‘waarde’.
Een mechanisme om specificatie van concrete informatieobjecten, zoals bloeddruk en polsfrequentie, in te brengen in het systeem via programmacode en/ of configuratie, zodanig dat concrete concepten altijd in overeenstemming zijn met het abstracte informatiemodel uit laag 1 en dus volgens eenduidige regels wordt opgeslagen (en opgevraagd), gepresenteerd en gecommuniceerd.
De benadering van software-engineers kan worden getypeerd als ‘architectuurbenadering’. Ze heeft als voordeel dat gemeenschappelijke kenmerken van verschillende concepten door de software ook als gemeenschappelijk worden gezien. Door ‘bloeddruk’ en ‘polsfrequentie’ te zien als een uitdrukking van het abstracte concept ‘observatie’ hebben beide concepten onder andere een auteur, een observatiedatum en -tijd, een verwijzing naar het gebruikte protocol, een tekstuele opmerking, een status en een context (werd de meting thuis uitgevoerd, klinisch of bij een poliklinisch consult bijvoorbeeld). Niet alleen kenmerken van concepten maar ook relaties tussen concepten worden op deze manier eenduidig in de software ingebracht. Een observatie heeft een relatie met een zorgmoment, zoals een opname of consult of zelfzorgmoment. Die relatie geldt voor alle typen observaties, dus ook voor polsfrequentie en bloeddruk.
De benadering van ZIB-ontwerpers kan daarentegen worden getypeerd als ‘adhoc’ benadering. Ieder individueel concept wordt los van de andere concepten gemodelleerd. Onderlinge relaties en relaties met zorglogistiekzoals opname en consult en de gemeenschappelijke kenmerken van concepten zijn niet of onvoldoende eenduidig vormgegeven.
Deze twee benaderingen, (de architectuurbenadering van software-engineers en de adhoc benadering van ZIB-ontwerpers), zijn moeilijk met elkaar in overeenstemming te brengen en vormen de belangrijkste reden waarom systemen niet ZIB compliant zijn en dat ook nooit zullen worden. Tenzij bij het ontwerp van ZIB’s een andere benadering wordt gekozen en kennis en methodiek uit de software engineering discipline wordt ingebracht.
Wat is ZIB compliancy?
Om redenen zoals hierboven beschreven gebruiken leveranciers van bronsystemen de ZIB’s niet als specificatie bij de ontwikkeling van hun software. Leveranciers hanteren hun eigen modellen en maken nieuwe software om hun eigen model te mappen op de ZIB’s. Dat is een niet aflatende inspanning omdat zowel de eigen modellen als de ZIB’s aan verandering onderhevig zijn. Leveranciers doen dit daarom bij voorkeur alleen wanneer er een specifieke usecase of duidelijk geuite klantwens bestaat. Hierbij worden ZIB’s gemapped op het informatiemodel van de leverancier voor zover relevant voor de usecase, waardoor situationele ZIB compliance ontstaat: de data die wordt uitgewisseld in deze specifieke usecase voldoet aan de ZIB specificaties.
Echte ZIB-compliancy zou vragen dat alle data die wordt verwerkt door een bronsysteem altijd voldoet aan de ZIB specificaties, zodat situationele mapping niet langer nodig is. Dit betekent bijvoorbeeld dat opslagstructuren van systemen en logica in systemen moeten worden aangepast zodat zij aan de ZIB specificaties voldoen. De adhoc benadering van ZIB-ontwerp vormt daarvoor onvoldoende solide basis voor software ontwikkeling. Ze is als schieten op een bewegend en gefragmenteerd doel omdat steeds nieuwe (versies van) ZIB’s worden ontworpen, allemaal losstaand van elkaar.
Verschillen in compliancy tussen leveranciers
De grote informatiesystemen in de zorg hebben allemaal hun bedrijfseigen informatiemodellen en opslagstructuren. Deze modellen en structuren zijn doorgaans in de loop van vele tientallen jaren gegroeid en zijn niet meer eenvoudig aan te passen. Ook deze systemen bevatten veel ‘adhoc’ ontwerp en daardoor minder samenhang, waardoor wijzigingen vaak complex en ingrijpend zijn.
Situationele ZIB-compliancy vraagt, zoals we zagen, mapping van die bedrijfseigen modellen en structuren op de ZIB specificaties. Hierbij ontstaan genuanceerde interpretatieverschillen tussen leveranciers die casus voor casus zullen moeten worden opgelost. Ook de situationele ZIB-compliancy is dus moeilijk haalbaar. Kortom, de vaststelling in de notitie van ZN is herkenbaar maar niet onverwacht.
Hoe kan ZIB-compliancy wel bereikt worden?
Algemene ZIB-compliancy is alleen onder de volgende voorwaarden haalbaar:
1. Realistische verwachtingen van leveranciers en systemen Ongeacht de gekozen aanpak zal algemene ZIB-compliancy veel tijd in beslag nemen en met hoge kosten gepaard gaan. Systemen moeten worden aangepast, gegevens geconverteerd (soms met verlies van betekenis, soms is conversie niet mogelijk) en eindgebruikers moeten worden overtuigd en opgeleid. Voor leveranciers is het lastig om de met dergelijke grootschalige aanpassingen gepaard gaande kosten terug te verdienen; de eindgebruiker merkt er in zijn dagelijks werk te weinig van. Omdat risico’s en kosten groot zijn zal bij leveranciers veel weerstand ontstaan.
2. Een radicaal andere aanpak van ZIB ontwikkeling Geen adhoc ontwikkelde ZIB’s meer die niet als specificatie voor echt werkende software kunnen dienen, maar een architectuurbenadering die aansluit bij moderne software engineering principes. Hiermee is in de ZIB release van september 2020 een voorzichtig begin gemaakt met de introductie van ‘blauwdruk-ZIB’s’. Het probleem wordt dus wel onderkend door het ZIB-ontwerpcentrum maar veel verdergaande stappen zijn nodig om te komen tot een samenhangend en implementeerbaar model van ZIB’s.
Iedere roadmap naar ZIB-compliancy zal in ieder geval aan deze twee voorwaarden moeten voldoen. Daarnaast moet meer aandacht uitgaan naar generieke methoden om gegevens in bronsystemen te benaderen, los van usecases of specifieke gegevensuitwisselingen. In mijn eerdere blog ‘De verborgen parels in de Wegiz’ doe ik, met dat doel voor ogen, een aantal suggesties voor het stimuleren van open API’s en generieke standaard API’s.
Afsluitend
De Nederlandse aanpak roept bij veel mensen, waaronder bij mij, verbazing op. Er is een internationale standaard (de OpenEHR standaard) beschikbaar voor de ontwikkeling van ‘ZIB’s’ (archetypes genoemd binnen openEHR) die voldoet aan de in deze blog bedoelde software engineering principes. Een standaard die steeds meer ook door HL7 wordt omarmd (zie bijvoorbeeld het ‘HL7 CIMI’ project) en waarvoor mapping naar HL7 CDA en FHIR bestaat. Op basis van de OpenEHR standaard zijn (veelal opensource) ontwikkelomgevingen beschikbaar, die door zorgverleners zelf kunnen worden gebruikt om ZIB’s te ontwikkelen. Binnen de community die verantwoordelijk is voor de standaard is een internationale repository van (peer reviewed) ZIB’s beschikbaar gesteld. Langzaam maar zeker beginnen op openEHR gebaseerde systemen te ontstaan (ook in eigen land en soms open source) die fundamenteel ‘ZIB compliant’ zijn. Voor huidige én toekomstige ZIB’s.
Ik pleit hier expliciet niet voor een openEHR revolutie waarbij alle bestaande bronsystemen op de schop moeten en aangepast aan de OpenEHR standaard. Ik pleit wel voor een ZIB-ontwikkelproces dat aansluit op internationale standaarden en op hoe moderne software wordt ontwikkeld. ZIB-compliancy is dan in ieder geval technisch en economisch (niet uitsluitend Nederlands in een inmiddels internationale markt) haalbaar. OpenEHR is daarvoor de beste kandidaat.