Vrijdag 23 april 2021 heeft de ministerraad ingestemd met het wetsvoorstel elektronische gegevensuitwisseling in de zorg (Wegiz). Hoewel het voorstel nog een lange weg door de Tweede en Eerste Kamer te gaan heeft, is haar impact nu al zichtbaar. Gegevensuitwisseling en openheid van informatiesystemen in de zorg staan inmiddels prominent op de agenda van alle betrokken spelers.
Wegiz is een kaderwet en geeft de minister de macht om gegevensuitwisselingen te verplichten bij Algemene Maatregel van Bestuur (AMvB). Hoewel een kaderwet een zwaar middel is, biedt ze ook de nodige flexibiliteit ten opzichte van reguliere wetgeving. En die flexibiliteit is belangrijk want juist op het gebied van gegevensuitwisseling in de zorg is het nodig continu bij te kunnen sturen op veranderingen en nieuwe inzichten. Zowel de zorg als de ICT veranderen snel en wetgevings-trajecten duren lang.
In de Wegiz wordt onderscheid gemaakt tussen twee sporen. In spoor 1 wijst de minister gegevensuitwisselingen aan die elektronisch dienen te verlopen. De minister stelt eisen aan de gegevensuitwisseling zoals het voldoen aan algemene normen als de NEN7510, 7512 en 7513. De gegevensuitwisseling zelf is in spoor 1 echter nog niet gestandaardiseerd/ genormaliseerd. In spoor 2 wijst de minister gegevensuitwisselingen aan die elektronisch dienen te verlopen op basis van een daartoe door de NEN ontwikkelde (of te ontwikkelen) norm. Ook het onderscheid tussen de beide sporen biedt de minister de flexibiliteit die hard nodig is binnen het veranderlijke zorg-ICT landschap.
De Wegiz biedt veel flexibiliteit en dat is een groot goed als ze nuttig besteed wordt. In deze blog een aantal suggesties om de verborgen mogelijkheden van de Wegiz optimaal te benutten.
De smalle interpretatie van Wegiz
Het begrip ‘gegevensuitwisseling’ wordt in de Wegiz niet expliciet uitgewerkt. Toch bestaat er bij de meeste mensen een duidelijk beeld bij wat een gegevensuitwisseling is en hoe zij tot stand komt:
Er is sprake van een usecase (uitwisselingsscenario) waarin gegevens tussen twee of meer partijen worden uitgewisseld.
Zowel usecase als uit te wisselen gegevens zijn nauwkeurig gedefinieerd.
De gegevens dienen elektronisch te worden uitgewisseld conform standaarden op het gebied van techniek en informatie.
Het is aan de industrie om deze standaarden te implementeren.
Deze benadering is te zien als top-down innovatie. Top-down innovatie levert een voorspelbaar resultaat want het beoogde einddoel staat vooraf precies vast. In het geval van gegevensuitwisseling is dat de usecase en de uit te wisselen gegevens. Top-down innovatie heeft vooral voordelen indien:
Brede consensus bestaat over probleem en einddoel
Bottom-up innovatie niet of moeizaam van de grond komt en er dus een drukmiddel nodig is
Juist het voorspelbare resultaat is ook de achilleshiel van top-down innovatie. Er is weinig ruimte om het einddoel en de beleving van het probleem bij te stellen wanneer gedurende het project nieuwe inzichten ontstaan. De sterke gerichtheid op een vooraf vastgesteld doel beperkt vaak ook de generieke toepasbaarheid van oplossingen die door top-down innovatie tot stand komen. Tenzij generieke toepasbaarheid een expliciet doel is natuurlijk. Top-down innovatie vraagt om gecentraliseerde besluitvorming en sturing, zoals in het geval van een Wegiz spoor 2 AMvB. Ze vraagt om continue stimulering, bijvoorbeeld door subsidie en sancties (de wortel en de stok).
Bottom-up innovatie begint daarentegen met de notie van een probleem, maar het doel wordt pas in de loop van het proces vastgesteld. Soms wordt gaandeweg het proces ook de beleving van het probleem bijgesteld. Bottum-up innovatie past dan ook beter in situaties waar onzekerheid over probleem en doel bestaat. Zij is geschikt als innovatiestrategie indien er een intrinsieke motivatie bestaat om te innoveren; innovatie hoeft niet te worden afgedwongen. Bottum-up innovatie vraagt om gedecentraliseerde besluitvorming en ze creëert mede daardoor betrokkenheid en eigenaarschap.
In de smalle interpretatie van de Wegiz is er enkel sprake van top-down innovatie: de minister legt aan de markt op dat (en hoe) bepaalde gegevensuitwisselingen moeten worden geautomatiseerd. Deze top-down benadering is ook belangrijk omdat tot voor kort de intrinsieke motivatie om gegevens uit te wisselen leek te ontbreken, vooral bij leveranciers van informatietechnologie-producten en -diensten. Inmiddels is er, mede onder druk van Wegiz en de VIPP-subsidies, sprake van een (voorzichtige?) omslag. Zelfs de grootste concurrenten op de markt zoeken elkaar op om oplossingen voor gegevensuitwisseling te ontwikkelen en op elkaar af te stemmen. Voorbeelden daarvan zijn NUTS, De Taskforce Samen Vooruit (TSV), de samenwerking tussen Epic en ChipSoft en de samenwerking tussen eNovation en Philips. Het is dan ook tijd voor een bredere interpretatie van Wegiz die ook bottum-up innovatie stimuleert. Gelukkig biedt Wegiz daarvoor de ruimte. Maar voordat ik die bredere interpretatie behandel, eerst meer inzicht in de manier waarop standaarden voor gegevensuitwisseling tot stand komen.
Hoe komen standaarden voor gegevensuitwisseling tot stand?
Gegevensuitwisselingen en standaarden komen niet alleen top-down tot stand. De onderstaande figuur toont drie verschillende manieren waarop (defacto) standaarden worden ontwikkeld: Open API’s, Standaard API’s en gegevensuitwisselingen. Zie voor meer informatie over open API’s en Standaard API’s mijn blog ‘Wat zijn API’s?’.
Van belang is dat deze drie verschillende manieren elkaar beïnvloeden:
Open API’s worden vaak, nadat zij al in de praktijk zijn beproefd, ingediend ter standaardisatie. De belangrijkste standaarden die zorgen dat het internet werkt zoals het werkt (zoals tcp/ip) worden op deze manier ontwikkeld. Ze worden ontwikkeld door de industrie of wetenschap, beschreven in een RFC en uiteindelijk als internet draft of internet standard aangewezen door de IETF. Vanuit de Taskforce Samen Vooruit worden op vergelijkbare wijze Technische Afspraken(TA) gepubliceerd en ingediend bij de NEN. Zodoende ontstaan Standaard API’s.
Standaard API’s en informatiestandaarden worden vaak in uitwisselingsscenario’s gecombineerd tot gestandaardiseerde gegevensuitwisseling. Een goed voorbeeld is de manier waarop IHE integratieprofielen standaardiseert. Compositie van gegevensuitwisselingen op basis van standaard API’s (en bestaande informatiestandaarden) leidt tot een hogere consistentie tussen gegevensuitwisselingen dan wanneer iedere gegevensuitwisseling op zichzelf staand wordt ontwikkeld.
Gestandaardiseerde gegevensuitwisselingen leiden tot meer gebruik van API’s en daardoor tot een meer en duidelijker gearticuleerde vraag uit de markt. Dit kan leiden tot meer Open API’s, meer standaard API’s en meer gegevensuitwisselingen.
Bovenstaande ontwikkelingen kunnen ook vanuit een ander perspectief worden bekeken:
Open API’s en Standaard API’s worden (vooral) gebruikt om bronsystemen (EPD, ECD, HIS, AIS, etc) te ontsluiten voor verschillende usecases.
Gestandaardiseerde gegevensuitwisselingen worden (vooral) gebruikt door uitwisselingssystemen (soms onderdeel van een bronsysteem) om gegevens met andere uitwisselingssystemen uit te wisselen, binnen vooraf vastgestelde en nauw omschreven usecases. Zij gebruiken Open API’s of Standaard API’s om bronsystemen te benaderen.
Optimale inzet van de Wegiz zou betekenen dat deze drie ontwikkeltrajecten, open API’s, standaard API’s en gegevensuitwisselingen, parallel worden gestimuleerd.
Een bredere interpretatie van Wegiz
Nu we meer weten over de drie verschillende manieren waarom standaarden tot stand komen, kunnen we met een frisse blik beoordelen hoe Wegiz de ontwikkeling en inzet van standaarden voor gegevensuitwisseling kan versnellen. Hoe kan de Wegiz worden ingezet om (naast de top-down verplichting van gegevensuitwisselingen) ook bottom-up innovatie en het gebruik van open API’s en standaard API’s te stimuleren?
Stimuleren van ontwikkeling en inzet van Open API’s
Spoor 1 is de eerste verborgen parel van Wegiz. De minister kan bij AMvB afkondigen dat een bepaald proces moet worden geautomatiseerd zonder dat daarbij wordt aangegeven hoe dat exact plaats moet vinden. Dit stimuleert bottom-up innovatie en zal via de weg van open API’s leiden tot standaard API’s en mogelijk toekomstige (via spoor 2) gestandaardiseerde gegevensuitwisselingen. Deze aanpak is vergelijkbaar met de aanpak van de PSD2 verordening die open API’s in de bankensector verplicht en heeft geleid tot innovaties als iDeal en Tikkie.
Nu al zien we dat de Wegiz (en andere interventies zoals VIPP, maar ook het programma TWIIN van VZVZ) bottom-up innovatie stimuleert of zelfs forceert. Wegiz biedt een bestendige manier om dit soort bottom-up innovatie blijvend te stimuleren, mits zij ook echt voor dat doel wordt ingezet en er een klimaat van vruchtbare samenwerking tussen publieke en private sector wordt gestimuleerd.
Aan de openheid van API’s kunnen, ook in spoor 1, eisen worden gesteld door te verwijzen naar een door NEN te ontwikkelen norm voor open API’s. Belangrijke aspecten in zo’n norm zijn bijvoorbeeld:
Eisen ten aanzien van kwaliteit en publieke beschikbaarheid van API documentatie
Eisen aan versiebeheer en support
Eisen ten aanzien van aansluitbeleid en het niet willekeurig kunnen uitsluiten van partijen als gebruikers van de open API’s
Eisen ten aanzien van de publieke beschikbaarheid van testomgevingen.
De Open API Architecture Policy van de NHS biedt hiertoe een aardig vertrekpunt.
Stimuleren van ontwikkeling en inzet van standaard API’s
De tweede verborgen parel is de open definitie van het begrip gegevensuitwisseling. Hoewel wij bij gegevensuitwisseling geneigd zijn te denken aan een gestandaardiseerde usecase, waarbij ook de organisatorische rollen van de uitwisselende partijen en de uitwisselingsprocessen zijn gestandaardiseerd, geeft het wetsvoorstel ruimte voor een veel bredere interpretatie.
Dit maakt de weg vrij voor een aanpak die in de Verenigde Staten is gekozen. Het ONC (Office of the National Coordinator for Health Information Technology) heeft gekozen voor de verplichting (en certificering) van het aanbieden van een set van standaard API’s op basis van SMART on FHIR. Het ONC vereist standaard API’s (en dus niet standaard usecases) omdat zij probeert innovatie te stimuleren: Het veld kan op basis van standaard API’s nieuwe creatieve usecases ontwikkelen. Binnen de Wegiz kan de minister bij AMvB een vergelijkbare verplichting introduceren; ieder bronsysteem zou een set van standaard API’s moeten aanbieden die door anderen kan worden gebruikt om slimme innovaties en gegevensuitwisselingen te ontwikkelen.
Parels voor de zwijnen
Wegiz is een instrument om interoperabiliteit en gegevensuitwisseling in de zorg te stimuleren. Hoewel vaak alleen de dwingende top-down benadering van de Wegiz wordt benadrukt, biedt zij ook mogelijkheden om bottom-up innovatie te stimuleren. Het niet gebruiken van die ruimte is als parels voor de zwijnen werpen. Laten we hopen dat de minister de ruimte die de Wegiz biedt ten volle benut en het veld blijvend wordt uitgedaagd om te innoveren zodat de digitale transformatie van zorg in een stroomversnelling raakt.
Commenti