Wat is ‘Information blocking’ in de zorg en hoe kan het worden voorkomen?

Bijgewerkt op: 1 jul. 2021

Deze week, op 5 april 2021, is de final interoperability rule van het ONC (Office of the National Coordinator for Health Information Technology in de Verenigde Staten) in werking getreden. Deze final rule bevat maatregelen om ‘Information Blocking' te voorkomen. Het ONC definieert Information Blocking als het doelbewust voorkomen of tegenwerken van toegang tot, uitwisselen van, of gebruik maken van elektronische zorg informatie. Het ONC definieert ook situaties waarin geen sprake is van Information Blocking, zoals wanneer de privacy of veiligheid van de patiënt in het geding is.


Onderzoek toont aan dat Information Blocking in de VS veel voorkomt, ondanks de regelgeving. Naast softwareleveranciers maken ook zorgaanbieders en ‘Health Information Exchange' netwerken zich schuldig aan Information Blocking. Dat is een logisch gevolg van de concurrentie op de Amerikaanse zorgmarkt en een waarschuwing voor iedereen die concurrentie tussen zorgaanbieders bepleit.


In het onderzoek worden onredelijk hoge prijzen voor API's en kunstmatige barrières (bijvoorbeeld niet bestaande technische of privacy barrières) als meest voorkomende Information Blocking strategieën van software leveranciers genoemd. Het is bijzonder lastig om beleid te maken dat dit gedrag van leveranciers tegengaat, immers:

  • Hoe bepaal je wat een redelijke prijs voor een API is?

Ik heb de afgelopen jaren meermalen mogen ervaren dat de inspanningen en kosten voor de ontwikkeling en het onderhoud van API’s schromelijk onderschat worden. Daarnaast is de investeringsonzekerheid in Nederland hoog, vanwege de grote hoeveelheid concurrerende initiatieven en op handen zijnde regelgeving (Wegiz). Hoewel dat soms wordt gedacht, bestaan gratis API’s niet. Een ‘gratis API’ betaal je met data of de prijs van de API’s is al verdisconteerd in de totale prijs van het systeem. Wat is een goede prijs voor een API?

  • Hoe bepaal je of iets een kunstmatige barrière is?

Het is lastig vast te stellen dat iemand weet dat hij kunstmatige barrières opwerpt. Daarnaast komt het vaak voor dat leveranciers barrières opwerpen die later alles behalve kunstmatig blijken te zijn. Wanneer is er sprake van een oprecht bezwaar en wanneer van kunstmatige barrière?


Hoewel we het in eigen land niet zo noemen, is Information Blocking ook hier onderwerp van onderzoek. De ACM doet sinds eind 2020 onderzoek naar ICT systemen en gegevensuitwisselingen in de zorg en dan met name naar de ‘technische en commerciële strategieën die marktpartijen hanteren’.


Vooruitlopend op de resultaten van dat onderzoek schets ik een zestal denkrichtingen om Information Blocking te voorkomen, namelijk:

  • Het verplichten van het gebruik van standaarden voor gegevensuitwisseling

  • Het verplichten van Open API’s

  • Het stimuleren van publiek-private samenwerkingen

  • Het wegnemen van door leveranciers ervaren barrières

  • Het stimuleren van digitale autonomie bij zorgaanbieders

  • Het inrichten van een meldpunt


1. Verplichten van het gebruik van standaarden voor gegevensuitwisseling


Zowel het ONC als de Nederlandse wetgever kiezen voor het verplichten van het gebruik van standaarden voor gegevensuitwisseling. In de VS via de final interoperability rules van het ONC en in Nederland via het wetsvoorstel Wegiz. In beide gevallen is er sprake van een verplichting aan zorgaanbieders en een certificering voor leveranciers.


Toch is er een schijnbaar klein maar wel erg belangrijk verschil tussen de aanpak van het ONC en de benadering van VWS. Het ONC verplicht namelijk het aanbieden van generieke API’s voor het benaderen van gespecificeerde zorggegevens (SMART on FHIR), terwijl VWS het accent legt op gegevensuitwisseling. Dat verschil is belangrijk omdat bij generieke API’s de usecases vooraf niet vastliggen; het is aan het veld zelf om innovatieve oplossingen te ontwikkelen op basis van de verplichte generieke API’s. In het geval van een gegevensuitwisseling staat de usecase daarentegen vooraf al wel vast; bijvoorbeeld de verpleegkundige overdracht of het medicatieproces. Dat beperkt de mogelijke innovaties en bemoeilijkt hergebruik van API’s. Uitgaan van gegevensuitwisselingen leidt tot wat ik ‘ad hoc interoperabiliteit' noem in mijn whitepaper over Open standaarden in de zorg. Ad hoc interoperabiliteit leidt tot hogere kosten van interoperabiliteit.


Ik ben voorstander van een doordachte combinatie van beide benaderingen. De benadering van het ONC zal leiden tot meer en snellere innovatie omdat zij de creativiteit van het veld stimuleert. Maar op een verplichte laag van generieke API’s kunnen ook verplichte gegevensuitwisselingen op landelijke schaal worden geïmplementeerd, daar waar een dergelijke schaal wenselijk is.


Gelukkig laat de Wegiz in haar huidige vorm genoeg ruimte om ook de meer generieke aanpak van het ONC via een algemene maatregel van bestuur te implementeren. Het is aan de minister om van die ruimte gebruik te maken. Daarnaast volgen de meeste leveranciers zelf ook zoveel mogelijk een dergelijke benadering; een laag van generieke API’s op basis waarvan specifieke usecases worden geïmplementeerd is een best practice architectuur die onderlinge consistentie van API’s en gegevensuitwisselingen ten goede komt.


Voor de duidelijkheid; zowel de aanpak van het ONC als die in de Wegiz lossen het probleem van de onredelijk hoge prijzen niet op. Het ONC noemt licencing en pricing van API’s expliciet als GEEN voorbeeld van Information Blocking maar stelt wel dat prijzen redelijk moeten zijn. Maar ja…wat is redelijk?



2. Verplichten van Open API's


Een Information Blocking strategie die naar mijn ervaring ook voorkomt is het selectief openstellen van API’s door bijvoorbeeld het gebruik van API’s door een concurrent te weigeren of inderdaad kunstmatige barrières op te werpen. Ook hier geldt dat het maken van beleid op deze strategie lastig is omdat soms toegang tot API’s op terechte gronden geweigerd wordt door een leverancier. Bijvoorbeeld omdat twijfels bestaan over de kwaliteit en patiëntveiligheid van het systeem dat de API’s wil gebruiken, of omdat het doel van gebruik niet in lijn is met de filosofie van de aanbieder van de API’s. Op die gronden weigert Apple ook apps toe te laten met een (door Apple vermeende) pornografische inhoud.


De strategie van het selectief weigeren van toegang tot API’s kan worden bestreden door openheid te vereisen ten aanzien van het API aanbod. In een eerdere blog beschreef ik hoe de NHS in haar Open API architecture policy vereist dat:

  • Voor alle ‘belangrijke’ functionaliteit een API beschikbaar is. Indien mogelijk gestandaardiseerde API’s maar anders bedrijfseigen API’s als geen standaard voorhanden is.

  • Documentatie van alle door een leverancier aangeboden API’s kosteloos en voor iedereen toegankelijk is,

  • Een voor iedereen toegankelijke testomgeving beschikbaar is,

  • Support wordt geleverd op (gebruik van) de API’s,

  • Geen partijen mogen worden uitgesloten van gebruik van de API’s, tenzij op grond van publiekelijk bekend toegangsbeleid. Aan dergelijk toegangsbeleid kunnen eisen en beperkingen worden gesteld zodat kan worden voorkomen dat een leverancier kunstmatige barrières op kan werpen.

Een dergelijke Open API policy heeft daarnaast als voordeel dat:

  • Ze innovatie stimuleert omdat kennis, support en testmogelijkheden publiekelijk toegankelijk zijn.

  • Ze concurrentie stimuleert omdat de interoperabiliteit van systemen makkelijker vergeleken kan worden.

Een Open API policy kan bij wet worden afgedwongen of door inkopers worden bedongen. In dat geval zou een aanpak zoals van de NHS of zoals in de Europese PSD2 verordening is opgenomen verstandig zijn: Benoem op welke gebieden API’s verplicht zijn zonder specifieke standaarden te vereisen EN stel eisen aan de openheid van API’s. Een Open API policy komt niet in plaats van wetgeving als Wegiz, die gestandaardiseerde uitwisseling op specifieke usecases verplicht stelt, maar is aanvullend op dat soort wetgeving.


Interessant is echter dat een toenemend aantal leveranciers uit zichzelf een dergelijke policy implementeren. Wellicht is wetgeving dus niet nodig maar zou op waarde schatten en omarmen van dergelijke initiatieven volstaan.



3. Stimuleren van publiek-private samenwerking


De afgelopen jaren is een forse omslag zichtbaar in de manier waarop leveranciers op de Nederlandse markt gegevensuitwisseling benaderen:

  • ChipSoft en Epic, de grootse concurrenten op de Nederlandse zorg-ICT markt, wisselen de Basis Gegevensset Zorg en diverse ander gestructureerde en semi-gestructureerde documenten uit op basis van internationale standaarden. Een langdurige samenwerking die steeds nieuwe toepassingen en kennis oplevert.

  • Philips ForCare en eNovation, op hun terrein grote concurrenten, slaan de handen ineen en brengen gezamenlijk, daarbij ondersteund door Nexus, Technische Afspraken (TA) in bij de NEN ter verdere normalisatie. De TA gaat uit van dezelfde internationale standaarden als die worden gebruikt door Epic en ChipSoft in het voorgaande voorbeeld.

  • NUTS, een groeiend samenwerkingsverband van leveranciers, ontwikkelt gegevensuitwisselingen op basis van internationale standaarden en decentrale technologieën.

  • Leveranciers verzameld binnen de Taskforce Samen Vooruit werken aan Technische Afspraken op diverse terreinen.

  • En nog vele andere, soms formele en vaak informele samenwerkingen tussen leveranciers die ten minste op deelgebieden elkaars concurrent zijn.

Dit soort initiatieven laten verrassend snel concrete resultaten zien maar vinden tot nog toe ook verrassend weinig gehoor bij politiek en verzekeraars. Daar worden gek genoeg vele tientallen miljoenen per jaar geïnvesteerd in publieke projecten die ten minste ten dele door de industrie al zijn opgelost:

  • Uitwisselen van beelden en verslagen binnen het (concept) TWIIN afsprakenstelsel is gebaseerd op exact dezelfde internationale standaarden als die nu al in de dagelijkse praktijk gebruikt worden door eNovation, Philips ForCare, Epic en ChipSoft, namelijk IHE XCA.

  • De werkgroep verpleegkundige overdracht van de Taskforce Samen Vooruit is naar verwachting in de zomer dit jaar klaar met een eerste versie van een TA voor eOverdracht. In een eerder stadium is door eNovation, Point, ZorgDomein, ChipSoft en diverse leveranciers van ECD’s al een vroege versie van de benodigde uitwisseling geïmplementeerd in het kader van de Inzicht proeftuinen. Deze uitwisseling wordt nu in de praktijk gebruikt en iteratief verbeterd. Allemaal werk dat nu ook binnen het TWIIN programma opnieuw gaat worden uitgevoerd.

De angst dat grote IT-bedrijven nog meer macht krijgen binnen de Nederlandse zorg is diepgeworteld en ook best te begrijpen; er is ten minste de schijn van onredelijk hoge prijzen, prijsmodellen die onzeker zijn en kunstmatige barrières. Maar deze angst staat nu samenwerking te veel in de weg en dat is niet nodig. Binnen een publiek-private samenwerking (PPS) kan de macht van IT bedrijven in de zorgsector worden beheerst maar tegelijkertijd het innovatieve vermogen van de industrie ten volste worden benut. Een paar voorbeelden:

  • Binnen een PPS kunnen bindende afspraken worden gemaakt over open API’s en standaardisatie alsmede over pricing voor een lange periode.

  • Door zoveel mogelijk te opteren voor decentrale en gedistribueerde oplossingen krijgt geen enkele partij macht door data. Binnen een PPS kan (en, naar mijn mening, móet) dit een ontwerpvoorwaarde zijn.

  • Door meer lange termijn zekerheid kunnen leveranciers binnen een PPS investeren in innovatieve oplossingen en nieuwe business modellen.

Ook los van PPS zou de samenwerking tussen industrie en de zorg moeten worden gestimuleerd. Onbekend maakt onbemind; een vertegenwoordiger vanuit de industrie binnen het informatieberaad zou onderling begrip en vertrouwen kunnen doen toenemen. Dit betekent natuurlijk wel dat de industrie met één mond moet spreken en op het terrein van interoperabiliteit gedeeld belang boven eigenbelang laat gaan. Vormen van publieke samenwerking zouden door VWS en het IB, in samenwerking met de industrie, actief moeten worden onderzocht.


Tot slot zouden beleidsmakers en politici zich moeten laten informeren over de voortgang die binnen samenwerkingen tussen leveranciers worden geboekt en zouden ze de door TSV voorgestelde bottom-up standaardisatie (standaardisatie als gevolg van innovatie) moeten omarmen. Dat laatste past prima binnen ‘spoor 1’ van de Wegiz.



4. Wegnemen van door leveranciers ervaren barrières


Door leveranciers wordt al langere tijd aangegeven dat zij barrières ervaren die de ontwikkeling van gegevensuitwisselingen bemoeilijken:

  • Zelfs door van oorsprong Nederlandse leveranciers wordt aangegeven dat de binnen Nederland ontwikkelde standaarden onnodig veel afwijken van hun internationale basis. Dit zorgt voor hogere kosten en marktdrempels voor buitenlandse partijen. De discussie over dit punt krijgt vaak een welles-nietes karakter. Dat is eenvoudig te voorkomen door te vereisen dat iedere afwijking van de internationale standaard wordt gedocumenteerd en verantwoord: comply or explain.

  • Leveranciers geven aan te laat betrokken te worden bij de ontwikkeling van standaarden waardoor onuitvoerbare of suboptimale standaarden ontstaan.

  • Ontwikkeling van standaarden wordt onvoldoende integraal benaderd. Het los ontwikkelen van informatiestandaarden zonder relatie met de onderliggende techniek leidt tot irreële verwachtingen in de markt en tot implementatieproblemen.

  • Onduidelijkheid over (de interpretatie van) privacyregels leidt tot een afwachtende houding in de markt. De onlangs door VWS uitgebrachte ‘factsheet toestemmingen’ werd binnen een maand door juristen van hetzelfde VWS tegengesproken bij de open consultatie van de nieuwe informatiestandaard BGZ: nu is toch nadrukkelijke toestemming nodig indien de BGZ wordt meegestuurd met een verwijzing.

  • Onvoldoende samenhang tussen standaarden voor gegevensuitwisseling en de gebruikte onderliggende technologieën (vergelijk TWIIN met LSP en MedMij en je ziet drie volledig verschillende technologieën die door sommige leveranciers allemaal geïmplementeerd moeten worden). Ook dit leidt tot hogere kosten van ontwikkeling en onderhoud.

Dit is een greep uit de barrières waarvan ik weet dat ze ervaren worden. Het wordt tijd dat deze serieus genomen worden en gezamenlijk naar oplossingen gezocht gaat worden.



5. Stimuleren van digitale autonomie bij zorgaanbieders


Digitale transformatie kan niet van buitenaf worden opgelegd maar is een beweging vanuit organisaties zelf en vanuit de mensen binnen die organisaties. Digitale transformatie is geen ICT aangelegenheid maar gaat over het anders organiseren van werk en het ontwikkelen van nieuwe diensten en producten. Technologie- en standaarden voor gegevensuitwisseling hebben alleen impact als ze geabsorbeerd worden door zorginstellingen en zorgprofessionals en gebruikt worden om werk anders te organiseren en nieuwe vormen van zorg te ontwikkelen. Dat vraagt digitale autonomie van die zorginstellingen en zorgprofessionals; het vermogen om zelf te oordelen en beslissen over welke technologie op welke manier wanneer ingezet gaat worden. Digitale autonomie helpt ook een duidelijke marktvraag en een lange termijn roadmap te definiëren. Voor een individuele zorginstelling of, ik acht dat kansrijker in het versplinterde Nederlandse zorg landschap, in samenwerkingsverband.


Investeren in kennis en instrumentarium is van groot belang voor het ontwikkelen van digitale autonomie zodat zorginstellingen en zorgprofessionals ook daadwerkelijk kunnen profiteren van de mogelijkheden van gegevensuitwisseling en andere digitale technologieën. Nu en in de nabije toekomst. Melius Health Informatics wil daaraan bijdragen door kennis en instrumenten in eenvoudige taal beschikbaar te stellen aan iedereen binnen de zorg. Nu nog vooral via publiek toegankelijke blogs en publicaties, in de loop van het jaar ook via inspiratiesessies en masterclasses.



6. Inrichten van een meldpunt


Een (anoniem) meldpunt helpt zicht te krijgen op de aard en het vóórkomen van Information Blocking. Een dergelijk meldpunt zou door de ACM zelf kunnen worden ingesteld en zou beschikbaar moeten zijn voor zowel zorginstellingen als leveranciers die hinder ondervinden van Information Blocking of van beleid dat Information Blocking in de hand werkt, waaronder te sterke vernederlandsing van standaarden. Uitkomsten van een meldpunt kunnen richting geven aan verder beleid, zoals het instellen van toezicht, maar helpen daarnaast ook de problematiek in het veld zelf makkelijker bespreekbaar te maken en discussies te voeren op basis van feiten.



Afsluitend


Zullen dergelijke maatregelen de in de inleiding genoemde Information Blocking strategieën op korte termijn doen verdwijnen? Ik denk het niet. Maar de genoemde maatregelen zorgen wel voor meer openheid, zekerheid en volwassenheid en dat is nodig voor het goed functioneren van een markt. Zeker van de markt voor zorg-ICT producten en diensten.



533 weergaven