Stel, je bent een groep bevlogen deskundigen bij een GGZ-instelling en je hebt een uitgewerkt plan voor een eHealth toepassing op het gebied van de geestelijke gezondheidszorg, laten we zeggen een app voor kinderen met autisme. De toepassing die je voor ogen hebt is gestructureerd van opzet, gebaseerd op bestaande behandelinzichten uit de praktijk, kent heldere procedures, heeft duidelijke criteria voor de behandelresultaten en voorziet in een behoefte.
Zo op het eerste gezicht lijkt het alsof daarmee het lastigste deel voor de ontwikkeling van zo’n online behandelomgeving met een app achter de rug is. De praktijk is anders. Ontwikkelaars van e-mental health toepassingen krijgen te maken met een grote hoeveelheid uitdagingen, zelfs wanneer ze die app alleen maar in de eigen zorginstelling willen gebruiken.
Persoonlijke gegevens en uitkomsten koppelen met het centrale patiëntendossier (EPD)
Het bouwen van een aantrekkelijk vormgegeven app die werkt op Apple en Android is specialistenwerk. Dat geldt ook voor een robuust online dossier met de behandelresultaten. Vertrouwelijke gegevens moeten veilig worden verstuurd en opgeslagen. Misschien voorziet de toepassing in online videocontact met de patiënt. Behandelaars, assistenten en patiënten moeten ieder met een eigen beveiligingsniveau patiëntgegevens kunnen benaderen. En misschien wel het meest ingewikkeld: de persoonlijke gegevens en uitkomsten moeten op de een of andere manier worden gekoppeld met het centrale patiëntendossier (EPD) van de betreffende instelling. Niet alleen vanwege de patiënt gegevens op zich, maar ook voor de financiële verwerking en een eventuele centrale registratie van kwaliteits-indicatoren.
Explosie van complexiteit
Wanneer je de ambitie hebt om je toepassing te laten gebruiken door andere zorginstellingen explodeert de complexiteit waarmee je te maken krijgt. Zorginstellingen gebruiken immers niet allemaal hetzelfde EPD, dus de koppelingen die je hebt ontwikkelt werken daar niet. In de GGZ-sector zijn tientallen verschillende EPD-systemen in gebruik. Of systemen van dezelfde leverancier, maar in afwijkende versies. Die moet je allemaal ondersteunen en programmeren.
Het kan nog ingewikkelder. Een typische zorginstelling gebruikt niet één app of online toepassing, maar biedt steeds vaker een veel breder palet van online zorg aan, vaak in combinatie met de reguliere behandeling in een zogeheten blended model.
De grens van wat praktisch nog te overzien valt is snel bereikt
Er zijn inmiddels letterlijk honderden apps en online behandelingen voor bijvoorbeeld depressie, verslavingsproblematiek, paniekaanvallen of ADHD. Sommige patiënten zullen meerdere applicaties gebruiken. Wanneer ze voor elk van die toepassingen op een andere manier moeten inloggen, en die toepassing elk op zich op een andere manier met het EPD en met elkaar communiceren, is de grens van wat praktisch nog te overzien valt snel bereikt.
De oplossing: platforms voor e-Hulp apps
Al geruime tijd en vanuit verschillende richtingen ontstaan initiatieven om het ontwikkelaars en GGZ-instellingen gemakkelijker te maken om effectief eHealth toepassingen te kunnen aanbieden zonder de bijbehorende complexiteit. Bedrijven als Minddistrict en Zorgaanbieders Online ontwikkelden samen met voorop lopende GGZ-instellingen zogeheten online platformen. Zorgaanbieders Online deed dat bijvoorbeeld met Altrecht, Mentalshare en Parnassia Bavo Groep. Minddistrict werkt al vanaf 2008 samen met een grote groep zorginstellingen, en is inmiddels ook in andere landen actief. Maar behalve deze twee voorbeelden zijn er inmiddels tientallen kleinere platformen of verzamelplaatsen voor het aanbieden van e-mental health applicaties ontstaan. En daarmee ontstaat er een nieuwe keuze: welk platform kies ik voor het ontwikkelen en het publiceren van mijn app?
De softwarefabriek van Minddisctrict
Hoewel de invalshoek van bijvoorbeeld Zorgaanbieders Online en Minddistrict behoorlijk verschilt, is het achterliggende idee wél hetzelfde: standaard bouwblokken bieden die hergebruikt kunnen worden door afzonderlijke lessen of modules met een specifieke inhoud. Mark Willems, de oprichter en CEO van Minddistrict, legt uit dat eHealth toepassingen weliswaar verschillen in inhoud en type behandeling, maar dat ze op een iets hoger niveau veel dezelfde kenmerken hebben.
"eHealth toepassingen hebben op een iets hoger niveau veel dezelfde kenmerken"
“In verschillende eHealth behandelingen herken je onderdelen als tekstpagina’s, vragenformulieren of layout-kenmerken. Maar elke toepassing heeft ook een bepaalde workflow met stappen en behandelprotocollen. Daarnaast werkt iedere toepassing met berichten, contactmomenten en afspraken, en is er altijd één of andere koppeling met een EPD.” Minddistrict heeft in de afgelopen jaren een succesvolle softwarefabriek voor eHealth toepassingen ontwikkeld. Hiermee kunnen experts uit het veld samen met medewerkers van Minddistrict in relatief korte tijd een volwaardige toepassing ontwikkelen. Daarnaast biedt Minddistrict een online winkel met interventies (toepassingen) waaruit een behandelaar kan kiezen.
Zorgaanbieders Online richt zich met zijn platform juist veel minder op de inhoud van de behandelingen, maar op het beschikbaar maken van een standaard omgeving voor de opslag van gegevens en de communicatie met de andere ICT-systemen van zorginstellingen. Dat is gezien de band met softwaremaker VitalHealth niet verwonderlijk. Men heeft niet de ambitie om ontwikkelaar of uitgever van eHealth content te worden.
Maar Andries Bottema, managing director van Zorgaanbieders Online, constateert dat de opkomst van eHealth toepassingen in de GGZ voor een hele nieuwe set gegevens zorgt. “Het gaat daarbij in ieder geval om gegevens die je ook in het EPD vindt, maar ook om gegevens en communicatie waarin EPD’s nu nog helemaal niet voorzien. Waar sla je een filmpje met een videoconsult op? Waar bewaar je de voortgang van een eHealth behandeling? Waar leg je de rechten vast van alle personen die inzage moeten hebben in de protocollen en uitkomsten? Hoe geef je de patiënt zelf toegang tot diens health record?” Bottema ambieert een standaardomgeving te bieden die alle onderliggende communicatie en dataopslag als bouwstenen aanbiedt aan de makers van eHealth behandelingen.
Wat willen CZ en Geestelijke Gezondheidszorg Eindhoven?
Hoewel deze platformen een probleem oplossen, veroorzaken ze een nieuw probleem als er weer veel uiteenlopende platformen gaan ontstaan. Dat vindt ook Joep de Groot van verzekeraar CZ. “Coöperatie gaat e-health koppelen”, meldden onze collega’s van Skipr eerder deze week. In het bericht viel te lezen dat Zorgverzekeraar CZ via zijn investeringsfonds CbusineZ een half miljoen euro wil investeren in een betere samenwerking tussen aanbieders van eHealth toepassingen. Daartoe begon CBusineZ samen met Geestelijke Gezondheidszorg Eindhoven (GGzE) een coöperatie, waarin ook het Leo Kannerhuis Nederland, Mentaal Beter en GGZ Oost Brabant deelnemen.
"Wij willen graag investeren in de ontwikkeling van een breed gedragen gezamenlijke standaard"
“Het is een complex probleem”, zegt Joep de Groot, bestuurslid van CbusineZ. “Overal in Nederland worden eHealth toepassingen voor de GGZ (geestelijke gezondheid) sector ontwikkeld, maar de makers doen dan in afwijkende systemen, met eigen manieren om de protocollen en gegevens op te slaan. Inmiddels zie je dat er een aantal dominante partijen is opgestaan die platformen hebben ontwikkeld. Dat is een goede ontwikkeling, maar als je een nieuwe eHealth toepassing beschikbaar wilt maken voor alle GGZ-instellingen en aanbieders, zal die dus beschikbaar moeten zijn op de meest gebruikte platformen. Wij willen graag investeren in de ontwikkeling van een breed gedragen gezamenlijke standaard, zodat een app of online programma direct beschikbaar kan komen in de meest gebruikt platformen.” Hij wil dus aan tafel met partijen als Minddistrict en Zorgaanbieders Online, maar ook met spelers als Quli (onderdeel van Ordina) en Jouwomgeving.nl.
Inhoud is niet alles
Mark Willems van Minddistrict staat positief ten opzichte van zo’n initiatief, maar benadrukt dat er naast de technische uitdagingen ook nog een commercieel aspect in zo’n samenwerking aanwezig is. “Wanneer iedere aanbieder al zijn apps inbrengt in een gezamenlijk platform, zullen sommige daar meer dan andere van profiteren, afhankelijk van de breedte van het aanbod dat je nu zelf al kunt bieden. Daarnaast zijn we natuurlijk zelf allemaal commerciële bedrijven die een positie proberen te verwerven in deze markt.” Dat standpunt wordt ook door zijn collega Bottema van Zorgaanbieders Online gedeeld. Beiden geloven overigens dat het wel degelijk mogelijk is om een goede inhoudelijke standaard te gaan gebruiken voor de structurering en bouw van eHealth content, dus gericht op de inhoudelijke kant van de behandeling.
Maar inhoud is niet alles. De platformaanbieders die nu actief zijn onderscheiden zich niet alleen in de inhoud van de behandelmodules, maar vooral ook door de aanvullende functies, vormgeving en ontwikkeltools die ze te bieden hebben aan instellingen.
Vooral de mengvorm van online en offline behandelingen lijkt de toekomst te hebben
Denk ook aan chatfuncties of videoconsulten. Daarbij bieden ze steeds vaker functies die dicht in de buurt komen van de functies van het centrale ICT-systeem van een GGZ-instelling, zoals het maken van afspraken. Door het toegenomen belang van online behandelmodules, vragenlijsten, dagboeken en het eigen gezondheidsdossier krijgt een patiënt steeds vaker als eerste te maken met een eHealth platform in het contact met de GGZ-instelling. Vooral de mengvorm van online en offline behandeling lijkt de toekomst te hebben. Maar naarmate het gebruik en de hoeveelheid patiënt informatie in het eHealth platform toeneemt, neemt ook het belang van een goede koppeling met het centrale EPD-systeem toe.
Communiceren met EPD-software
Johan Vos, business developer bij ICT-dienstverlener E.Novation, zegt dat het ontwikkelen van een nieuwe infrastructuur- en berichtstandaard voor de communicatie tussen eHealth applicaties en het EPD “wel het laatste is wat de coöperatie zou moeten doen.” Volgens hem is dat een heilloze weg. “Voordat je al die leveranciers op één lijn hebt en de standaard ook daadwerkelijk in alle producten verwerkt is ben je jaren verder. "Focus liever op de inhoudelijke informatiestandaard.
"Zorg ervoor dat je vanaf één centrale plaats met al die individuele EPD-software kunt communiceren"
Je moet het praktisch aanpakken. Inventariseer welke koppelfuncties er zijn in alle EPD-producten die in de GGZ worden gebruikt, en zorg ervoor dat je vanaf één centrale plaats met al die individuele EPD-software kunt communiceren. De eHealth toepassingen hoeven dan vervolgens alleen maar met die ene plaats te kunnen communiceren om de gewenste data van A naar B te krijgen. Alle complexiteit van de communicatie met die tientallen systemen die in gebruik zijn scherm je daarmee af voor de ontwikkelaar, die ziet maar één systeem. En de EPD-leverancier hoeft zelf niets aan te passen.”
Of dat een ontwikkeling is waarmee de EPD-leveranciers blij zijn valt overigens nog te bezien. Zij zien hoe een nieuwe generatie aantrekkelijke toepassingen, afkomstig uit de inhoudelijke eHealth kant, steeds meer het gezicht naar cliënten toe worden, en daarbij ook vaker functies gaan bieden die voorheen het domein van het EPD waren. En net als in andere sectoren geldt dat de bezitter van het klantcontact gaandeweg meer invloed zal krijgen. Het is dan ook niet vreemd dat alle grote aanbieders van EPD-software binnen de GGZ de functionaliteit van hun patiëntportalen snel willen uitbouwen. Maar het kunnen aanbieden van een zorg inhoudelijk gedreven ontwikkelplatform voor eHealth zoals Minddistrict en anderen nu hebben, lijkt geen voor de hand liggend scenario voor EPD-aanbieders.
Een (heel) groot probleem met eHealth is dat we van "lelijke" legacy systemen naar hele mooie apps gaan. De "lelijke" legacy systemen konden nooit met elkaar communiceren, maar de nieuwe (veel mooiere-) apps kunnen dat ook niet...
Die "lelijke" apps zijn voorheen vaak gebouwd door backend developers, vandaar dat ze wat minder mooi zijn. Maar wat er nu gebeurd is dat front end developers feitelijk gaan vertellen dat ze weten hoe een backend eruit moet komen te zien. Dit is fundamenteel fout...
Als eerste moet een platform waarop aangesloten kan worden gebouwd worden volgens de juiste blauwdruk, de juiste standaard. Veel bouwers hebben het nu over een beetje NEN7510 t/m 13 en menen daarmee alles opgelost te hebben, De slimmerikken praten zelfs nog een beetje over HL7 (versie 2 of 3). Maar met geen van beide standaarden bouw je een platform waarmee je medische data kunt opslaan en bewerken.
Als we dit met wegenbouw vergelijken praten de huidige (mooie) nieuwe applicaties over het plaatsen van stoplichten en het maken van vluchtstroken: veiligheid (EN7510). Maar wat ze eerst (hadden) moeten doen is infrastructuur ontwerpen: waar komen uberhaupt de wegen en hoe lopen die langs rivieren of boven/onder de riolering of elektriciteit. Het begin van het ontwerp zit hoger in de stack...., op deze manier blijft het falicant fout gaan.
Dus alle geweldige ontwikkelingen ten spijt hou ik toch een beetje mijn hart vast.... Gelukkig gaat de wetgever vanaf januari aanstaande actief handhaven. Hopelijk zal daarmee het eerst kaf van het koren gescheiden kunnen worden.
Jan-Marc Verlinden