Mobiel internet is gemeengoed geworden. Dit maakt de weg vrij voor zorg apps om zorg te verbeteren, efficiënt te werken, en patiënten meer service te bieden. Een mooi verhaal, toch? Niet in de praktijk. Zorg apps en epd- software zijn meestal niet te koppelen, vaak onder het mom van de privacy van de patiënt. Die staat toch voorop?
Open systemen waarbij de epd-leverancier zijn front-end met de back-end laat communiceren via een eigen application programmers interface (api), kom ik niet veel tegen. Terwijl ontsluiting van real-time informatie vanuit het epd juist de kracht vormt van goede zorg-apps. De beveiliging moet wel goed geregeld zijn. Dat kan door zorg apps niet direct te koppelen aan de epd-software, maar te laten praten met een ‘service bus’ als api.
Service bus
Een service bus kun je zien als een software schil tussen de beveiligde zorgomgeving en het internet domein. Zolang deze interface ontbreekt, is het lastig om allerlei zorg-apps veilig te koppelen aan je epd-software. Het vergt lef van een epd-softwareleverancier om applicatiebouwers toe te laten als externe partners bij ‘hun’ epd.
De patiënt komt pas echt voorop te staan, als de epd-leverancier, de zorginstelling en applicatiebouwers samenwerken. Vaak is de epd-leverancier een specialist in administratieve toepassingen, maar niet sterk in zorginhoudelijke applicaties. Daar kunnen externe softwareontwikkelaars dan in voorzien. Als zorginstelling wil je vrij beschikken over je data in het epd. Dit moet gewoon beschikbaar zijn. Dat kan dan via de service bus als api.
EPD koppelen
Nadelen zijn er ook. Het bouwen van een service bus op een bestaand systeem is complex. Je hebt grondig inzicht nodig in de epd-software. Het gaat om software code die de leverancier vrijwillig zal moeten openstellen. Ze moeten, net zoals jij, pleitbezorger zijn van vernieuwing in de zorg op een flexibele en prijsbewuste manier. Een win-win is nodig.
De bouw van een aparte interface moet een bewuste keuze zijn. De keten van software wordt immers langer. Winst is dat je snel kunt innoveren met zorg-apps die in de markt zijn.
Bavo Janss, senior app ontwikkelaar bij Senet Applicatiebouwers
Leuke blog en erg herkenbaar een heleboel zaken die je noemt.
Het probleem heeft voor een deel te maken met de standaarden die worden gebruikt in de zorg. Er wordt wel degelijk binnen instellingen gekoppeld, maar veelal op EDI-gebaseerde standaarden (zoals EDIFACT en HL7v2). Het meerendeel wordt gebruikt om bijvoorbeeld vanuit een EPD decentrale systemen aan te sturen – denk bijvoorbeeld aan het synchroniseren van actuele patientgegevens of het uitzetten van orders. Andersom wordt er gekoppeld om onderzoeksresultaten uit een decentraal systeem naar het EPD te sturen. In wezen wordt er geintegreerd om informatie van A naar B te sturen (synchronisatie). Vervolgens is de informatie opgeslagen binnen A en / of B, maar niet of lastig op te vragen voor C.
Een ander deel van het probleem wordt ook veroorzaakt door de positie die veel EPD-leveranciers hebben binnen zorginstellingen. Ze leveren het centrale pakket en hebben er eerder baat bij om nog meer modules te verkopen dan dat ze hun systeem moeten gaan open stellen voor anderen (vendor lock-in). Kleinere en innovatievere spelers zijn daar vaak meer toe geneigd.
Ondertussen vinden er op standaardisatiegebied diverse ontwikkelingen plaats zoals IHE XDS en HL7 FHIR waarmee het wel mogelijk is om op basis van services informatie uit te wisselen. De snelheid waarmee deze ontwikkelingen worden doorgevoerd in de verschillende bestaande zorgsystemen is traag, doordat leveranciers pas iets willen ontwikkelen wanneer een klant hierin ook wil investeren (kip-ei-verhaal).
Het gevolg daarvan is dat zorg-apps zelf wegen proberen te vinden waarmee ze data uit het EPD kunnen halen of wegschrijven. Het zou beter zijn als zorginstellingen een duidelijk beeld vormen van welke services ze nu en in de toekomst nodig gaan hebben en daar actief mee aan de slag gaan. Ze kunnen dan bijvoorbeeld de keus maken om ze te laten implementeren binnen het EPD door hun leverancier of ze zouden zelf services kunnen ontwikkelen op een service bus.
Twee reacties hier op:
Het begrip zorg-app is nog niet echt vastgelegd. Als een arts zou voorschrijven dat je een bepaalde app moet gebruiken als onderdeel van de behandeling, wordt er allerlei certificering vereist van de app-leverancier en de app zelf.
Daarnaast denk ik dat we moeten toegroeien naar een situatie waarbij de mens het koppelvlak zal worden om de ontbrekende verbindingen tussen systemen te leggen. Ben je er niet, dan zijn de gegevens niet gerelateerd en waardeloos. Daarmee ben je altijd in control wie wat met jou gegevens wil.
Mooi artikel met een nieuw onderwerp en ook interessante reacties! TanX
Ik kan me voorstellen dat de epd-leveranciers deze ontwikkeling tegenhouden (vendor lock-in)of zich niet 100% inzetten voor het behalen van deze doelstelling. Security is wel een belangrijk onderwerp maar daar zijn genoeg technisch oplossingen, dus daar ligt het niet aan.
Het aanbieden van je dienst via een app is een must voor de toekomst! Dat toont een stukje van je innovatieve kracht als (epd)leverancier.
Kijk wat Exact had meegemaakt. Ze bleven vast houden aan hun oude software totdat ze ingehaald waren door andere innovatieve leveranciers zoals Afas. Toen werden ze (misschien te laat) wakker en hebben geprobeerd om hun software te “moderniseren”.
De vraag is wie gaat als eerst deze innovatieve stap in het epd-land zetten?
@Leen: Ik snap dit stuk van je reactie niet
“Daarnaast denk ik dat we moeten toegroeien naar een situatie waarbij de mens het koppelvlak zal worden om de ontbrekende verbindingen tussen systemen te leggen……….”
De afnemer van zorg-software realiseert zich vaak niet genoeg dat hij eigenaar is van de data die hij zelf verzameld. Veel van die data hebben echter betrekking op het primaire proces van logistiek en planning in de zorg. Het transparant ontsluiten van deze gegevens via een open specificatie lijkt mij een must-have bij een volgende aanbesteding.
De mens als het koppelvlak om de ontbrekende verbindingen tussen systemen te leggen. Dat doet me denken aan een chronische patient die zelf zijn eigen medisch dossier probeert bij te houden op een USB-stick, zodat hij altijd (voor zover dat mogelijk) is een medisch dossier van zichzelf bij zich heeft wanneer hij op consult moet bij een andere arts in een ander ziekenhuis die hier niet over beschikt.
Ik denk dat dat juist een situatie is die je wilt vermijden en die ontstaat als een eigen oplossing bij gebrek aan beter. Maar hoe je het ook oplost de regie wil je wel bij de patient leggen (uitgezonderd enkele noodgevallen zoals wanneer hij buiten kennis is), zodat die kan aangeven met wie er gegevens mogen worden uitgewisseld en wie er toegang krijgt.
@Reza: sorry was even dagje op pad.
Ik bedoel dat je als mens altijd in control bent als systemen relaties willen leggen tussen gegevens die jou betreffen. Pas als je akkoord geeft door b.v. de ontbrekende sleutel te geven, kunnen die gegevens gerelateerd worden.
Best lasting natuurlijk en vergt nog onderzoek hoe je dat het meest efficiënt kunt doen. Hoe ga je bijvoorbeeld een batchrun uitvoeren?
Dus het antwoord heb ik nog niet concreet, maar de denkrichting is dat je op de één of andere manier altijd weet wanneer organisaties iets met je gegevens willen doen (vooraf) en jij en ik zelfs nodig zijn om de gegevens aan jou te relateren.
Denk niet dat mensen zich op hun gemak voelen als ze hun medisch dossier samen met rekeningen van ziekenhuis en/of specialist in volle trein coupe gaan lezen omdat anderen gewoon mee kunnen lezen.
Om maar te zwijgen dat er nogal wat gratis apps zijn die toch de inhoud van je telefoon door gaan spitten om gevonden interessante gegevens door te sturen naar een partij waarbij het uiteindelijk terecht komt bij een organisatie die daar minder goede bedoelingen mee heeft.
Maw zelfs op je tablet die je altijd thuis hebt liggen zou ik oppassen met dit soort apps.
Ik ben nu benieuwd welke vernieuwende EPD leveranciers in de zorg zich hier zullen uitspreken voor het gebruik van zorg apps. Waarom wel of niet?
Volgens mij gaat het nog niet eens om koppelen van medische gegevens, maar zit de vooruitgang al in praktische informatie die je overal kunt benaderen via mobiel of tablet.
In de GGZ kan ik me voorstellen dat iemand dagelijks zijn stemming invult via een app. En dat die info in het medisch dossier komt. Dat is weer anders dan een app die zelf medische gegevens bevat en te openen is door iedereen die het tablet oppakt.
Ik krijg de kriebels wanneer ik het volgende lees:
“een software schil tussen de beveiligde zorgomgeving en het internet domein”.
Even kort, internet is een onveilige omgeving. Lees de DDos aanvallen, virus en trojaner om nog niet van doelgerichte hackig te praten.
Koppelvlakken zijn per definitie kwetsbaar, dat waren ze 20 jaar geleden en dat zijn ze nog.
Windows is niet het veiligste platform, dat weten we, android is ook niet bepaald een uitblinker op het gebied van beveiliging. Wie beweert dat “apps” (of noemen we het maar weer eens gewoon programma’s) op deze platformen met nog een extra laag software (dus weer 2 koppelvlakken) wel veilg wordt, die droomt.
De hele struktuur van de ziekenhuizen, die als kleine winkeltjes zelfstandig ICT inkopen en de daaruit voortvloeiende versnippering van de ZIS markt, gekoppeld aan de konkurrentiestrijd om bedden, als gevolg van een falende politiek sinds vele vele jaren, heeft de zorg ICT alleen maar kwetsbaarder gemaakt.
Nederland heeft nog ongeveer 100 ziekenhuizen die allemaal een vergelijkbare behoefte aan automatisering hebben, maar niet in staat zijn om samen te werken.
Als patient wil ik daar mijn gegevens eigenlijk helemaal niet bewaard hebben, laat staan dat ze gaan experimenteren met koppelingen, de verzekeraars, die wild zijn op die gegevens, wrijven zich al in de handen.
Op een dag kan het iedereen van ons overkomen, een verzekering accepteert je niet, zonder opgave van redenen. Dat staat ons te wachten als we niet eindelijk beleid gaan voeren met betrekking tot beveiliging van patientengegevens.
@ Bavo Janss
Wel wat open deuren die hier worden ingetrapt. De overtreffende vraag zou moeten zijn…..
Waarom niet?
Dat is eenvoudig te beantwoorden. Incompetentie en Commercie.
We hebben de kwinkslagen van onze, destijds dan, grote voortrekkers gezien waaronder Ab Klink. Er lagen namelijk al scenario’s die vrij en gratis ter beschikking waren gesteld aan de politiek die het beoogde doel haalbaar maakte, een eenvoudig standaard, waarbij met vrijwel alle aspecten (wensen) die men had, rekening was gehouden.
Politieke impotentie
We hebben mogen zien wat commercie en politiek veroorzaakt. Ellenlange discussies, heel veel politieke onzin en gekonkel, veel commerciële vrijerij en slijmelarij tussen politiek en commercie en……….?
Heel goed, de zeer voorspelbare wetmatigheid van IT die zegt, als je oneigenlijk om gaat met IT als materie, wat krijg je dan? Hele hoge rekeningen.
Hoe dan anders?
Tja, misschien zouden politiek en IT professionals eens rustig en heel basaal moeten gaan kijken en zeggen, goh, alle elementen voor een goed EPD zijn er al een aantal jaren. Met enkele aansluitende stappen en een protocol heb je een geloofwaardig en slagvaardig EPD. Vergeet dan even een duidelijk protocol niet en alles kan daar eenvoudig op aansluiten…..
Of misschien is het juist die stap die alle andere stappen, zoals dit artikel publiceert, volkomen overbodig?
Als je er eens even nuchter over na zou willen denken, zou het zomaar kunnen zijn.