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
Het gaat (zie commentaar jan) om de definitie van een zorg-app. Wat is dat? Voor toegang tot patient gegevens dient er een zogenaamde behandel relatie te zijn met de betreffende patiënt. Daarbij zit er nog een hierachter in de behandelrelatie, ben je verplegend, behandeld arts, specialist, allemaal zaken waarvoor je de toegang moet regelen. De services bus is een algemeen middel en de veel ziekenhuizen hebben een servicebus in huis, inderdaad gebaseerd op HL7.
De uitdaging zit hem dus in het autheticeren van de gebruiker van de zorg-app voor het juiste level van de behandelrelatie. Daarbij zou je ook nog de locatie als afhankelijke willen stellen, binnen of buiten het ziekenhuis en binnen hert ziekenhuis binnen de OK of andere gebieden.
Er zijn overigens een aantal leveranciers die HTML-5 compatible systemen leveren, helaas is het aantal beperkt en dan kan je op een andere manier de data aanbieden. Je hebt dan een app nodig die samenwerkt met een web applicatie, dat maakt het leven weer wat eenvoudiger. Dit is ook de richting waarin zorg apps zich ontwikkelen.
Een zorg-app in combinatie met een servicebus, in elkaar geknutseld zou ik een zorgelijke ontwikkeling willen noemen.
Beste Bavo, bedankt voor je artikel.
Aan de TU/e hebben we een platform ontwikkeld dat de controle omwisselt m.b.t. data uitwisseling in een app development context: zie https://sites.google.com/site/myphrmachines/. Het simpele maar radicaal nieuwe idee is dat data nooit naar de remote servers van app developers gestuurd wordt. De app code moet aangeboden worden in de MyPHRMachines trusted cloud. Binnen in die cloud wordt de data veilig samengebracht met de app code, op een manier dat enkel de patient en diens kring erbij kunnen (artsen die toestemming krijgen, mantelzorgers die toestemming krijgen, …)
De aanpak is erg generiek omdat er gebruik wordt gemaakt van virtuele machines (VMs) als executie containers. Het is mogelijk om in een VM API middleware te gebruiken, maar dat is optioneel. In http://dx.doi.org/10.1109/JBHI.2013.2257821 wordt de basisprincipes van MyPHRMachines uitgelegd maar binnenkort wordt een vervolg artikel gepubliceerd waarin specifiek de link naar health apps besproken wordt.
Mvg,
Pieter Van Gorp
Senet bedankt iedereen voor de reacties tot nu toe. Leuk dat we snel een ontmoeting hebben met één van de betrokkenen, en dat dankzij Computable.
Ik vraag me af in hoeverre EPD leveranciers dit gat gaan vullen, als ze het al zouden doen dan heb je nog steeds iets nodig om de zaken samen te brengen. Ook wij zijn al een tijdje bezig met het bouwen en een esb platform waarop bv apps kunnen worden ontwikkeld (Finalist Zorgbus). @Pieter, interessant model, ik ben benieuwd naar het volledige artikel.