Iedereen is het erover eens dat een ‘duurzaam informatiestelsel zorg’ of de ‘digitale zorginfrastructuur’ noodzakelijk is om ook in de toekomst betaalbare en hoogwaardige zorg te kunnen blijven leveren. Ondanks dit gedeeld belang is er veel (soms onuitgesproken) onenigheid over de invulling van die digitale zorginfrastructuur. Lees ter illustratie maar eens de reacties op de Wet elektronische gegevensuitwisseling in de zorg (Wegiz). Om te voorkomen dat Henk eindigt in de cloud is een andere kijk op digitale zorginfrastructuur gewenst.
Waarom is een nieuwe kijk nodig?
Het debat over digitale zorginfrastructuur is vooral een debat over technische oplossingen. Een debat over welke standaarden voor gegevensuitwisseling (verplicht) dienen te worden ingebouwd in dossiersystemen. Over welke generieke diensten moeten worden ontwikkeld en geëxploiteerd en wie daarvoor verantwoordelijk is. Over of de digitale zorginfrastructuur een nutsvoorziening is of dat zij door marktpartijen dient te worden ontwikkeld. Over hoe verschillende infrastructuren voor gegevensuitwisseling technisch met elkaar kunnen worden verbonden.
De bedachte en bediscussieerde oplossingen hebben doorgaans onnavolgbare afkortingen meegekregen, zoals CDA (Clinical Document Architecture), XDS (Cross Enterprise Document Sharing), ZIB (Zorg Informatie Bouwsteen) en FHIR (Fast Healthcare Interoperability Resources). Dit soort rare afkortingen lijken nodig om de industrie die rond digitale gegevensuitwisseling is ontstaan te legitimeren. Ze worden alleen begrepen door technisch specialisten, staan soms ver van de zorgpraktijk en leiden tot een gevoel van vervreemding bij zorgbestuurders en zorgprofessionals. En ook bij Henk natuurlijk.
Na bijna 40 jaar nadenken over technische oplossingen en afkortingen lijkt de vooruitgang nog steeds beperkt. Toch is het antwoord op achterblijvende resultaten vreemd genoeg meer van hetzelfde: meer (verplichte) standaarden voor gegevensuitwisseling, meer generieke diensten, meer technische architecturen en meer onnavolgbare afkortingen.
‘Insanity is doing the same thing over and over and expecting different results’ schijnt Albert Einstein ooit te hebben gezegd. Het is daarom tijd om, voordat we toegeven aan de natuurlijke reflex om direct oplossingen te zoeken en nieuwe afkortingen te verzinnen, het probleem vanuit andere invalshoeken te bestuderen. In deze blog doe ik dat door te kijken naar de verschillende manieren waarop zorgaanbieders samenwerken.
Samenwerkingsmodellen als vertrekpunt
Een digitale zorginfrastructuur dient samenwerking tussen zorgaanbieders onderling en met de patiënt te ondersteunen. Voordat we nadenken over oplossingen (technologie, informatiestandaarden, generieke diensten, wetgeving, et cetera) is een goed begrip van de verschillende vormen van samenwerking van belang. Ik onderscheid een aantal samenwerkingsmodellen en hun belangrijkste karakteristieken. Die karakteristieken bepalen in hoge mate welk type digitale oplossingen passen binnen een samenwerkingsmodel.
Het servicemodel
Het servicemodel betreft de samenwerking tussen een aanbieder van diensten en de afnemer van die diensten. Diensten in het servicemodel zijn in hoge mate gestandaardiseerd, waarbij de aanbieder van iedere dienst bijvoorbeeld specificeert:
De levertermijn
Achtergrondinformatie voor de afnemer
Eventueel van toepassing zijnde kwaliteitsstandaarden
De resultaten van de dienst (en eventuele marges)
Eventuele leveringsvoorwaarden
Het servicemodel is uitermate geschikt voor samenwerkingen waar:
De samenwerking het patroon van een order volgt (het bestellen van een dienst door een afnemer bij een aanbieder)
Diensten in hoge mate kunnen worden gestandaardiseerd
De vraag voorspelbaar is
Sprake is van hoge volumes en meerdere (elkaar beconcurrerende) aanbieders.
Dit kunnen diensten en producten zijn die direct aan consumenten worden geleverd (Bol.com, Pieter Pot, Hello Fresh, en vele andere) maar ook diensten die bedrijven onderling leveren in een supply chain.
Veel zorg leent zich goed voor het servicemodel. Een huisarts die diagnostiek aanvraagt bij een laboratorium of een patiënt met pijn op de borst verwijst naar de cardioloog, neemt een dienst af bij een zorgaanbieder. Het laboratorium of de cardioloog levert een dienst die in hoge mate gestandaardiseerd en gespecificeerd is of kan worden. De levertijd (toegangstijd) kan worden aangegeven en eventuele leveringsvoorwaarden kunnen worden gespecificeerd, zoals welke informatie moet worden meegeleverd, of de patiënt nuchter moet zijn maar ook in hoeverre de dienst door de verzekeraar wordt vergoed.
De afnemer van de dienst kan meerdere aanbieders onderling vergelijken, bijvoorbeeld op prijs, kwaliteit of levertermijn, hetgeen transparantie en concurrentie zal doen toenemen. De Bergman kliniek (en veel andere Zelfstandige Behandel Centra) specialiseren zich in zorg die volgens het servicemodel wordt geleverd.
Hoe kan ICT het servicemodel ondersteunen?
ICT kan helpen zorgdiensten ‘vindbaar’ en onderling vergelijkbaar te maken. Daarnaast kan ICT de aanvrager en patiënt helpen om aan de leveringsvoorwaarden te voldoen, zoals het aanleveren van de juiste informatie (een ingevuld labformulier, een dagboek met thuismetingen, actuele medicatiegegevens en andere dossierinformatie). Hierbij geldt dat de zorgaanbieder de zorgdienst specificeert. De zorgaanbieder bepaalt welke informatie nodig is om de zorgdienst te kunnen leveren en gaat daarbij uit van geldende kwaliteitsstandaarden. De aanbieder bepaalt ook de leveringstermijnen en andere ‘beloften’ aan de patiënt en/ of aanvrager.
ICT kan de patiënt en aanvragen helpen om de (voor hem) beste dienst te vinden en meer inzicht te krijgen in bijvoorbeeld:
De voortgang van de dienst: wanneer gebeurt wat en wanneer moet ik waar zijn?
De (tussentijdse) resultaten van de dienst.
De werking van de dienst: een operatie kan al virtueel worden doorleefd voordat ze plaatsvindt
Eventuele keuzes en achtergrondinformatie bij de dienst
Ook kan ICT helpen om ad-hoc communicatie tussen patiënt of aanvrager en zorgaanbieder te faciliteren. De patiënt kan tot slot uitspraken doen over de (ervaren) kwaliteit en deze publiceren zodat andere patiënten en aanvragers daar hun voordeel mee kunnen doen.
Het servicemodel is minder gebaat bij top-down standaardisatie van informatiesets (door NEN of Nictiz). De kracht van het model is juist dat de aanbieder van zorgdiensten (de zorg zelf) bepaalt welke informatie wanneer voor het leveren van een zorgdienst nodig is en welke informatie wanneer wordt verstrekt.
Het servicemodel is wel gebaat bij standaardisatie van techniek en standaardisatie van informatie-elementen, zoals ‘medicatievoorschrift’ en diagnose. Ook is zij gebaat bij codering van zorgdiensten, zodat dezelfde zorg van verschillende aanbieders onderling vergelijkbaar is. Centrale ‘generieke’ componenten als toestemmingsvoorzieningen (Mitz), landelijke indexen (LSP) of een centrale dataomgeving zijn niet nodig. Voor het feitelijke transport van informatie zijn verschillende kanalen denkbaar maar FHIR is een logische kandidaat.
Het servicemodel is in de zorg geïntroduceerd door Plexus Medical Group onder de noemer ‘Leids verwijsmodel’. ZorgDomein is voortgekomen uit het Leids verwijsmodel en biedt bij uitstek ondersteuning voor het servicemodel.
Het solutionshop model
De term ‘solutionshop’ is afkomstig uit het boek ‘The innovators prescription’ van Clayton Christensen. Een solutionshop is een organisatie die complexe ongestructureerde problemen diagnosticeert en oplost. Op voorhand kan niet worden bepaald welke informatie nodig is en ook de uitkomst kan moeilijk worden voorspeld. Voorbeelden zijn consultancy bedrijven en research & development bedrijven.
Veel zorg wordt (vaak onterecht denk ik) gezien als een complexe en ongestructureerde dienst die voldoet aan het solutionshop model van Christensen. In het kader van samenwerkingsmodellen reserveer ik de term voor hoog complexe, laag volume zorg die door slechts enkele gespecialiseerde centra wordt verleend en niet gestandaardiseerd kan worden zoals in het servicemodel. Vaak wordt slechts een bepaald deel van de zorg door de ‘solutionshop’ geleverd en vinden de meer ‘standaard componenten’ elders plaats. Een dergelijke constructie wordt vaak shared care genoemd. Dit vraagt veel samenwerking en communicatie tussen de solutionshop en de shared care partner. Een specifieke vorm van een solutionshop is een regionaal MDO waarin experts afkomstig uit verschillende organisaties gezamenlijk diagnose en behandeling vaststellen. Voorbeelden van solutionshops zijn gespecialiseerde oncologische centra zoals het Prinses Maxima Centrum voor kinderoncologie, klinieken voor transplantatiezorg en de Sint Maartenskliniek die via een 'shop in a shop' model complexe zorg in andere ziekenhuizen levert.
Hoe kan ICT het solutionshop model ondersteunen?
ICT kan helpen om zeer grote hoeveelheden data uit verschillende bronnen samen te brengen binnen één samenwerkingsomgeving en verschillende experts (soms afkomstig van verschillende aanbieders, zoals in het geval van een regionaal MDO) met elkaar en de data in contact te brengen. ICT zal op termijn ook kunnen helpen bij de analyse van data en ondersteuning bieden bij diagnostiek en de selectie van behandelopties.
Het solutionshop model vereist een centrale dataomgeving en samenwerkingsomgeving. Een beetje wat samenwerkingsplatforms zoals Slack en Microsoft Teams bieden maar dan specifiek gericht op samenwerking rond grote hoeveelheden complexe zorgdata. Een centraal model is nodig om geautomatiseerde analyse mogelijk te maken en om te garanderen dat alle experts van de solutionshop (en eventuele zorgaanbieders die samenwerken met de solutionshop, bijvoorbeeld in een shared care setting) naar dezelfde werkelijkheid kijken. De dataomgeving kan dienen als ‘platform’ voor toepassingen die door verschillende partijen ontwikkeld worden, zoals AI-toepassingen en digitale zorgtoepassingen of viewers. Verder vereist het solutionshop model het vermogen om (met toestemming van de patiënt) data uit een verscheidenheid van systemen te ontvangen of extraheren en tot informatie te verwerken. Een hoge mate van flexibiliteit in het ‘koppelen’ van systemen is noodzakelijk.
Vanwege de onvoorspelbaarheid en grote volumes van de benodigde data is top-down standaardisatie (door bijvoorbeeld NEN of Nictiz) van informatiesets, anders dan basisinformatie, moeilijk haalbaar en zal zij voortgang belemmeren. Flexibiliteit en openheid is voor het solutionshop model belangrijker dan standaardisatie van informatie. Het solutionshop model heeft wel veel baat bij standaardisatie van techniek (zoals XDS en FHIR maar ook secure mail) en bij Open API’s.
Vitaly is een voorbeeld van een platform dat ondersteuning biedt voor het solutionshop samenwerkingsmodel. In de regio midden Nederland wordt Vitaly gebruikt als samenwerkingsplatform ten behoeve van regionaal oncologisch MDO (tumor board). Het UMC Utrecht (een typische solutionshop) is initiatiefnemer.
Het netwerkmodel
Waar een solutionshop hooggespecialiseerde en gecentraliseerde zorg levert, kan holistische zorg beter in een geformaliseerd netwerk van samenwerkende (formele en informele) aanbieders worden geleverd. Holistische zorg is gericht op het behouden of verbeteren van gezondheid en welzijn en raakt alle facetten van het menselijk bestaan. Zij is laagcomplex maar wel zeer veelzijdig en in hoge mate gepersonaliseerd. Het volume is hoog. Chronische zorg en palliatieve zorg zijn voorbeelden van holistische zorg die het beste in een netwerk kan worden geleverd. Dit soort zorg vraagt vaak om samenwerking die het zorg domein overstijgen en zich uitstrekken tot het sociaal domein, zoals schuldhulpverlening en aanpassingen in de woonomgeving, op werk of op school.
Hoe kan ICT het netwerkmodel ondersteunen?
Hoewel holistische zorg veelzijdig is, kan vooraf goed voorspeld worden welke informatie benodigd is (en beschikbaar is) om zorg te leveren en te evalueren. Ook het netwerkmodel is gebaat bij een centrale dataomgeving en samenwerkingsomgeving maar de nadruk ligt meer op standaardisatie van processen en informatie en op (langdurige) toegang door de zorgconsument zelf en door informele zorgverleners (mantelzorg, familie). Fijnmazige toegangsverlening (wie mag wat zien en aanpassen) is een belangrijke vereiste.
Het PGO kan een belangrijke component zijn binnen het netwerkmodel, mits zij wordt uitgebreid met een samenwerkingsomgeving voor zorgaanbieders/ zorgverleners. Die samenwerkingsomgeving (of Zorg Netwerk Omgeving) dient naast communicatie en het delen van informatie ook functionaliteit te bieden ten behoeve van populatiemanagement.
Standaardisatie van informatie en techniek ondersteunt het netwerkmodel. Toch zal men zich moeten realiseren dat, juist door de benodigde personalisatie van holistische zorg, veel informatie in ongestructureerde/ ongestandaardiseerde vorm zal worden verzameld en gedeeld.
De HINQ Zorg Netwerk Omgeving en het Caresharing cBoards platform ondersteunen netwerkzorg.
Het ad hoc model
Tussen aanbieders in het ad hoc model bestaat geen andere relatie dan dat zij zich toevallig in dezelfde regio (of hetzelfde land, staat, unie) bevinden. Er is geen sprake van formele samenwerking maar aanbieders hebben behoefte aan het onderling delen van basale informatie ten behoeve van het leveren van veilige zorg. Medicatie, allergieën en diagnoses zijn voorbeelden van belangrijke basale informatie die door meerdere aanbieders gelijktijdig kunnen worden verwerkt, zonder dat zij dat van elkaar weten en zonder dat eenduidige afspraken over informatiemanagement gemaakt zijn.
Het ad hoc model heeft een aantal specifieke eigenschappen:
Regio’s zijn niet sterk afgebakend en hebben de neiging te groeien, bijvoorbeeld doordat zorgconsumenten in hun leven met steeds meer zorgaanbieders te maken krijgen vanwege verhuizing, scheiding en andere demografische factoren. Maar ook door steeds verdergaande specialisatie van zorgaanbieders. Ad-hoc samenwerking is daarom onbegrensd en oplossingen moeten bijzonder schaalbaar, laagdrempelig (ze werken alleen als alle zorgaanbieders meedoen) en fout-tolerant zijn.
Er zijn weinig of geen (eenduidige) afspraken over informatiemanagement, zoals wie verantwoordelijk is voor de productie en distributie van bepaalde informatie.
Hoe groter de regio, hoe groter de kans op informatie-asymmetrie. Informatie-asymmetrie betekent dat verschillende systemen van verschillende aanbieders allemaal een andere werkelijkheid bevatten, bijvoorbeeld een ander beeld van de actuele medicatie. Het destilleren van de werkelijkheid uit al die bronnen blijft handwerk voor de zorgaanbieder/ zorgverlener (zoals medicatieverificatie)
Ad hoc delen van zorginformatie (bijzondere persoonsgegevens) kan alleen op basis van nadrukkelijke toestemming van de patiënt.
Hoe kan ICT het ad hoc model ondersteunen?
Vanwege het hoge privacy risico en omdat er geen formele samenwerking bestaat tussen aanbieders in het ad-hoc model, is een centrale dataomgeving (een privacy-hotspot) geen geschikte oplossing. Anders dan vaak gedacht is ook gegevensuitwisseling ook niet altijd een optimale oplossing. Gegevensuitwisseling kan namelijk niet waarborgen dat alle aanbieders te allen tijde over exact dezelfde weergave van de werkelijkheid beschikken: er is geen single-source-of-truth.
In Nederland bestaat de neiging om van alle oplossingen voor het ad hoc model de slechtste te kiezen: gegevensuitwisseling op basis van een centrale index (LSP). Hier worden de nadelen van een centrale omgeving (privacy-hotspot) gecombineerd met de nadelen van gegevensuitwisseling (geen gegarandeerde single-source-of-truth en dus informatie-asymmetrie).
De persoonlijke gezondheidsomgeving (PGO) is een geschikte oplossing voor het ad-hoc model maar de vereiste grootschalige inzet van het PGO vereist een cultuuromslag die vele jaren in beslag zal nemen, voor zover zij ethisch en politiek al gewenst is. Gedistribueerde technologie (zoals blockchain) kent geen privacy-hotspot en garandeert een single-source-of-truth zonder dat een cultuuromslag benodigd is. Voor veranderlijke gegevens zoals medicatiegebruik is dat noodzakelijk. De 1.2 miljard euro die voor het programma Medicatieoverdracht is begroot, kan daarom beter worden uitgegeven aan een oplossing op basis van gedistribueerde technologie die niet afhankelijk is van het LSP en gegevensuitwisseling.
Oplossingen op basis van gedistribueerde (Blockchain) technologie worden bijvoorbeeld ontwikkeld in Estland.
Afsluitend
Zoals ieder model zijn ook de hier gepresenteerde samenwerkingsmodellen slechts vereenvoudigingen van een weerbarstige werkelijkheid. Veel zorgaanbieders maken deel uit van een verscheidenheid aan samenwerkingen en vaak zijn alle beschreven samenwerkingsmodellen naast elkaar van toepassing.
Uitgaan van samenwerkingsmodellen kan er echter voor zorgen dat oplossingen beter aansluiten bij de zorgpraktijk en kan suboptimale one-size-fits-all oplossingen voorkomen. Creativiteit en innovatie kunnen worden bevorderd door niet direct over (bestaande) technische oplossingen na te denken. Tot slot kan betrokkenheid van bestuurders en zorgprofessionals toenemen door te denken vanuit de zorg en vanuit samenwerking in plaats vanuit de techniek en rare afkortingen.
Uitgaan van verschillende samenwerkingsmodellen kan tot slot ook helpen bij vraagstukken rond opdrachtgeverschap (en eigenaarschap) van de digitale zorginfrastructuur. Zo ligt het voor de hand om digitale zorginfrastructuur onder het ad hoc model als nutsvoorziening te beschouwen, terwijl andere modellen waarschijnlijk beter in opdracht van een zorgaanbieder (solutionshop-model, servicemodel) of coöperatie (netwerkmodel) kunnen worden gerealiseerd.