Overzicht

Het ontwerp van een eHealth infrastructuur

10 april 2018

(Laatst aangepast: 11-04-2018)

Het ontwerp van een eHealth infrastructuur

Wetenschap en innovatie Whitepaper

De ontwikkelingen op het gebied van eHealth gaan snel. Om eHealth in te kunnen zetten moeten er gegevens tussen patiënt en zorgverlener gedeeld kunnen worden. De huidige ICT-infrastructuur van ziekenhuizen is vaak nog niet voorbereid op informatie uitwisseling tussen patiënt en zorgverlener. In dit artikel wordt beschreven voor welke keuzes een organisatie komt bij het maken van ontwerp voor de eHealth infrastructuur vervolgens wordt er een voorbeeld van een ontwerp gegeven.

Inleiding

Patiënten nemen steeds meer regie over hun eigen gezondheid. Eén van de manieren om dit te faciliteren is door het gebruik van eHealth toepassingen. Deze toepassingen zijn vaak gericht op een specifieke doelgroep binnen een bepaald specialisme. Er worden verschillende belemmeringen ervaren bij het inzetten van een eHealth toepassing. In de eHealth monitor 2016 is aan medisch specialisten gevraagd welke belemmeringen zij ervaren bij online contact met patiënten. De belemmeringen die hier het meest genoemd zijn, hebben voornamelijk te maken met de techniek en de integratie van de toepassing in het proces (Krijgsman, et al., 2016), bijvoorbeeld:

 

- Gebrek aan technische support (46%)

- Gebrek aan voldoende beveiligde systemen (42%)
- Onduidelijkheid over de goede manier van inrichten systeem (37%)
- Geen toegang tot de juiste techniek hiervoor (34%)
- Toepassingen zijn niet/slecht geïntegreerd (34%)

 

 

De huidige ICT-infrastructuur in ziekenhuizen is vaak nog niet voorbereid om eHealth toepassingen aan de bestaande systemen te koppelen.

 

In het LUMC is er een ontwerp gemaakt voor de eHealth infrastructuur. Hierbij lag de focus op het koppelen van apps/websites aan de bestaande infrastructuur van het ziekenhuis. De apps/websites staan nu meestal los van het EPD, waarbij de data die door een patiënt verzameld wordt niet gecombineerd kan worden met de data die in het ziekenhuis verzameld zijn. De eHealth infrastructuur moet het mogelijk maken dat eHealth toepassingen aan kunnen sluiten op de infrastructuur van het ziekenhuis, zodat het mogelijk is om data die met apps verzameld wordt te gebruiken in het zorgproces en de hiervoor benodigde informatiestromen te faciliteren. Daarnaast moet het ook mogelijk zijn om data vanuit de ziekenhuissystemen binnen de eHealth toepassing te tonen. In figuur 1 is de scope van het ontwerp van de eHealth infrastructuur weergegeven.  

 

De ontwikkelingen op het gebied van eHealth gaan snel, de beschikbare oplossingen voor de eHealth infrastructuur veranderen daarmee ook snel. In dit artikel wordt beschreven hoe het ontwerpproces er uitziet van een eHealth infrastructuur. Het ontwerpproces en de daarbij behorende keuzes worden beschreven op de lagen van het vijf lagen model voor interoperabiliteit (figuur 2) (Nictiz, 2017). Tot slot wordt het ontwerp van de eHealth infrastructuur in het LUMC beschreven.

 

Figuur 1 Scope van het ontwerp van de eHealth infrastructuur

Figuur 2 Vijf lagen model voor interoperabiliteit

Ontwerpproces eHealth infrastructuur

2.1    Organisatie

 

Op organisatieniveau wordt bepaald wat de strategie ten opzichte van eHealth is. In praktijk starten eHealth initiatieven vaak op een specifieke afdeling uit een idee van één of meerdere zorgverleners. Enerzijds moet de eHealth infrastructuur generiek zijn, zodat de strategie van de organisatie gefaciliteerd wordt, anderzijds moeten ook specifieke use cases gefaciliteerd kunnen worden om de innovatie niet te remmen. Wanneer er geen eHealth infrastructuur is, of er geen afspraken zijn op dit gebied, wordt er per eHealth toepassing naar een oplossing gezocht. Een eHealth infrastructuur draagt eraan bij dat binnen de organisatie bekend is wat de mogelijkheden zijn op het gebied van ICT. 

 

2.2    Proces

 

Bij het ontwerpen van de eHealth infrastructuur is het van belang om te weten welke generieke processen er gefaciliteerd gaan worden met de infrastructuur. Door deze processen zo generiek mogelijk te houden wordt voorkomen dat er een infrastructuur wordt ontworpen die gericht is op specifieke use cases, met als gevolg dat de infrastructuur niet breed inzetbaar is.

 

In het LUMC is de functionele vraag in kaart gebracht en uitgewerkt in zeven scenario’s:

 

-      Scenario 1: Algemene informatie beschikbaar stellen aan patiënten, bijvoorbeeld patiëntfolders.

-      Scenario 2: Patiënt ontvangt informatie op een specifiek moment in de behandeling.

-      Scenario 3: Patiënt kan persoonsgegevens inzien.

-      Scenario 4: Patiënt kan medische gegevens inzien.

-      Scenario 5: Patiënt kan de in het ziekenhuis bekende persoonsgegevens wijzigen.

-      Scenario 6: Zelfmanagement: patiënten verzamelen informatie met als doel om meer inzicht in hun          eigen gezondheid te krijgen. Deze gegevens worden niet met de zorgverlener gedeeld.

-      Scenario 7: Patiënt verzamelt informatie voor diagnose/behandeling.

 

De scenario’s zijn vervolgens vertaald naar de bedrijfsfuncties die met de infrastructuur gefaciliteerd moeten kunnen worden. 

2.3    Informatie

 Met betrekking tot de informatie zijn er twee hoofdvragen die beantwoord moeten worden:

-        Welke informatie moet er verwerkt kunnen worden?

-        Met welke standaarden kan dit?

 

2.3.1           Informatieverwerking

Op basis van de functionele analyse wordt vastgesteld welke informatie er verwerkt moet kunnen worden en uit welke bronsystemen dit komt. Op basis van de scenario’s zijn er vier routes gedefinieerd waarover informatie verwerkt moet kunnen worden in de infrastructuur tabel 2.

 

2.3.2           Informatiestandaarden

Om de informatie uitwisselbaar te maken is het van belang om een keuze voor standaarden te maken. Op alle lagen van het vijf lagen model zijn er standaarden die toegepast kunnen worden. De meest gebruikte standaarden zijn in figuur 3 opgenomen. De standaarden die op de informatie laag het meest relevant zijn voor de eHealth infrastructuur zijn de zorginformatiebouwstenen (zibs) en HL7 FHIR, dit zijn ook de standaarden waarop het MedMij afsprakenstelsel gebaseerd is. Er is bij het ontwerpen van de eHealth infrastructuur dus voor gekozen om de zibs en HL7 FHIR te gebruiken.

 

Zorginformatiebouwstenen (zibs) zijn gegevensmodellen die bestaan uit één of meer gegevenselementen, inclusief hun betekenis, datatypes en onderlinge relaties. Een zib beschrijft een zorginhoudelijk concept. Het doel van een zib is dat zorginformatie eenmalig en eenduidig wordt vastgelegd, zodat het voor andere doeleinden kan worden hergebruikt (Registratie aan de bron, 2017). Door de informatie-uitwisseling via de eHealth infrastructuur zoveel mogelijk naar zibs te modelleren biedt dit in de toekomst meer mogelijkheden voor uitwisseling met andere systemen, onafhankelijk van de leverancier.

 

HL7 FHIR is de informatiestandaard die ontwikkeld is om informatie tussen zorginstellingen uit te wisselen. FHIR staat voor Fats Healthcare Interoperability Resources. HL7 FHIR is ontwikkeld op basis van webstandaarden, zoals JSON, XML en HTTP. JSON is een standaard die door app bouwers veel gebruikt wordt. Daarnaast is het gebruik van bestaande technologieën door HL7 FHIR, zoals RESTful interfaces en SOAP voor ontwikkelaars van eHealth toepassingen laagdrempelig. Dit maakt HL7 FHIR als communicatiestandaard tussen apps en de ziekenhuis infrastructuur zeer geschikt.

 

2.4    Applicatie en infrastructuur

 

Bij het ontwerpen van de eHealth infrastructuur zijn er op het gebied van de applicaties en infrastructuur een aantal uitgangspunten binnen een organisatie waarmee rekening gehouden moet worden. Binnen het LUMC waren er vijf uitgangspunten leidend bij de ontwerpkeuzes:

 

1. Transparantie: Het moet duidelijk zijn waar de webservices worden aangeboden waar de apps op aansluiten, welke data er uitgewisseld wordt tussen welke applicaties en dat dit goed gedocumenteerd wordt. Het doel hiervan is dat de webservices herbruikbaar zijn voor andere applicaties en dat wijzigingen eenvoudig kunnen worden bijgehouden.

 

2. Real time data aanbieden: Bij het aanbieden van data aan patiënten over hun behandeling is het van belang dat het mogelijk is om dit real time te doen.

 

3. Bimodal ontwerp: dit betekent dat de infrastructuur uit twee ‘modes’ bestaat. Mode 1 focust op voorspelbaarheid en heeft stabiliteit als doel. Mode 2 is juist flexibel en geschikt voor innovatieve en explorerende projecten (Mingay & Mesaglio, 2016). Voor de eHealth infrastructuur betekent dit dat er naar buiten toe een eenduidige interface aangeboden wordt die flexibel genoeg is om mee te gaan met de ontwikkelingen op het gebied van eHealth. Aan de andere kant is het doel om de interne infrastructuur zo stabiel mogelijk te houden met een zo goed mogelijke performance.

 

4. Privacy by design: In de Algemene Verordening Gegevensbescherming wordt gesteld dat privacy al zoveel mogelijk in de ontwerpfase beschermd moet worden. Om deze reden wordt en in het ontwerp zoveel mogelijk rekening gehouden met:

 

-          Encryptie van data;

-          Het scheiden van de ziekenhuis infrastructuur en het externe netwerk; 

-          Authenticatie van gebruikers; 

-          Autorisatie: waar worden bevoegdheden geregeld; 

-          Logging van activiteit.

 

5. Legacy: Een deel van het ontwerp staat bij voorbaat al vast, omdat er gebruik gemaakt moet worden van een aantal applicaties die onvermijdelijk zijn, zoals het EPD. 

 

 

Tabel 1 aanpak ontwerpfase eHealth infrastructuurTabel 1 geeft de aanpak weer om tot het ontwerp van de eHealth infrastructuur te komen. De lagen worden vervolgens in meer detail beschreven.

Tabel 2 Routes van informatieverwerking

Figuur 3 Standaarden op het vijf lagenmodel voor interoperabiliteit

Ontwerp van een eHealth infrastructuur

In figuur 4 is het ontwerp dat in het LUMC voor de eHealth infrastructuur gemaakt is op hoofdlijnen weergegeven. De pijlen in het ontwerp laten de informatiestromen zien. De doorgetrokken lijnen zijn de koppelingen die in eerste instantie gemaakt zullen moeten worden om aan de vraag te kunnen voldoen. De stippellijnen zijn informatiestromen die er op termijn bij kunnen komen. De kleuren staan voor de verschillende routes van informatieverwerking, de betekenis van de kleuren is weergegeven in tabel 3.

 

In dit ontwerp zijn er een aantal ontwerpkeuzes gemaakt. Een aantal keuzes heeft effect op alle routes en sommige zijn specifiek. De keuze voor een enterprise service bus (ESB) heeft effect op alle routes. Een ESB is een communicatie broker die services van verschillende applicaties met elkaar kan verbinden. De ESB is dus onafhankelijk van de route van informatieverwerking. De ESB verbindt de bedrijfsservices van de apps met de bedrijfsfuncties binnen het ziekenhuis door één interface naar buiten toe aan te bieden. Deze interface bestaat uit webservices waar apps op kunnen aansluiten. Via de ESB kunnen applicaties onafhankelijk van elkaar informatie uitwisselen (Thomas, 2007). De ESB maakt het mogelijk om een bimodal infrastructuur te ontwerpen. De ESB wordt dan gebruikt om de twee modes (de traditionele en de nieuwe, flexibele infrastructuur) aan elkaar te koppelen. Met de ESB kunnen gegevens in de vorm van webservices worden aangeboden en het maakt transparante gegevensuitwisseling mogelijk. Als webservices aansluiten bij de huidige technieken (RESTful interfaces en/of SOAP), kunnen apps eenvoudiger op de infrastructuur worden aangesloten. De inzet van HL7 FHIR sluit hierop aan. Daarnaast kan een ESB ook autorisatie vastleggen en het dataverkeer regelen, dus informatie uit verschillende bronnen combineren en ontsluiten richting de applicaties die de data mogen ontvangen.

 

Intern wordt er in ziekenhuizen een communicatiebroker gebruikt om applicaties aan elkaar te koppelen, maar mogelijk kan het ook een interface naar buiten toe aanbieden en als ESB fungeren. Daarnaast kan de communicatiebroker worden ingezet om de vertaalslag te maken van HL7 V2 naar HL7 FHIR en andersom.

 

Als er een eHealth infrastructuur is, kunnen app- en web toepassingen aansluiten op de infrastructuur van het ziekenhuis. De apps kunnen in de toekomst ook gekoppeld worden aan een PGO. De app- en webtoepassingen en de PGO zijn als generiek component in het ontwerp opgenomen, omdat de infrastructuur geen specifieke toepassing faciliteert. Het is voor de organisatie van belang om een aantal eisen te stellen aan de toepassingen die mogen aansluiten op de infrastructuur, bijvoorbeeld met betrekking tot authenticatie, dataopslag, standaarden en protocollen.

 


De vier routes van informatieverwerking worden hieronder verder toegelicht.

 

3.1    Data afkomstig uit het EPD

 

Als er realtime data vanuit het EPD nodig is moet er gebruik gemaakt worden van de infrastructuur van het EPD. De ontsluiting van gegevens gaat dan via de communicatieserver van het EPD. De mogelijkheden zijn dan beperkt tot de koppelingen die het ziekenhuis heeft aangeschaft (of zelfgebouwd) of die nog aangeschaft kunnen worden. Het alternatief is om gebruik te maken van een kopie van de EPD-database. In figuur 4 is deze weergegeven als de kopie van de EPD database. Als dit een real time kopie is, is het mogelijk om informatie afkomstig uit het EPD real time beschikbaar te stellen, zonder dat het rechtstreeks uit de EPD-database hoeft te worden gehaald. Daarnaast drukken query’s niet op de performance van het EPD als deze op de kopie van de EPD database uitgevoerd kunnen worden.

 

3.2    Informatie uit andere bronsystemen

 

Naast data uit het EPD wordt er mogelijk ook gevraagd worden om data uit andere systemen, zoals het PACS, pathologie informatiesysteem, laboratorium informatiesysteem of het CMS (de algemene patiënten informatie). Per bron moet er gekeken worden hoe de data er uitgehaald kan worden. Veel van de data uit andere bronsystemen staat ook in het EPD. Het is afhankelijk van de use case of het gewenst is om data rechtstreeks uit het bronsysteem te halen of dat het ook uit EPD gehaald mag worden. Vaak zijn uitslagen in de bronsystemen nog niet door de arts geautoriseerd. In dat geval is het de vraag of het wenselijk is om deze gegevens rechtstreeks met de patiënt te delen of dat ze vanuit het EPD ontsloten worden na autorisatie.

 

Als er geen real time data nodig is kan er ook gebruik gemaakt worden van een datawarehouse. Hier komt de data uit het EPD en andere bronsystemen samen. De data uit het datawarehouse heeft altijd een achterstand. Hoe groot deze achterstand is, is afhankelijk van hoe vaak het datawarehouse gevuld wordt.

 

3.3    Data kunnen of hoeven niet in het EPD te worden weggeschreven

 

Als het niet noodzakelijk en/of mogelijk is dat data in het EPD wordt weggeschreven kan de data in een andere database worden weggeschreven: de database voor externe data. Vanuit het EPD kan er een view op deze database gemaakt worden, zodat het voor de eindgebruiker vanuit één applicatie benaderbaar is.

 

3.4    Data in het EPD wegschrijven

 

De enige mogelijkheid om data in het EPD weg te schrijven is via de route die door de leverancier ondersteund wordt: de communicatieserver. Hierbij moet steeds de vraag gesteld worden of het noodzakelijk is dat data rechtstreeks in het EPD wordt weggeschreven of dat een view voldoende is. Als de thuismeting rechtstreeks in het EPD wordt weggeschreven, moet het voor de arts wel herkenbaar zijn als thuismeting.

 

Figuur 4 ontwerp eHealth infrastructuur

Tabel 3 Routes van informatieverwerking in het ontwerp

Conclusie

De ontwikkelingen op het gebied van eHealth gaan snel, daarom zijn er in de afgelopen tijd alternatieven bij gekomen voor dit ontwerp. De keuzes die in de ontwerpfase gemaakt moeten worden rond het ontwerp van een eHealth infrastructuur veranderen niet. Om een eHealth infrastructuur te kunnen ontwerpen die past bij de organisatie is er input op alle vijf de lagen van het vijf lagenmodel nodig.

 

Grefen, P. (2015). Business Information System Architecture. Eindhoven: Eindhoven University of Technology.

 

Hooghiemstra, T. (2017). Consultatiedocument Persoonlijke gezondheidsomgeving. MedMij.

 

Hooghiemstra, T., Oud, J., Radema, M., Spruit, M., & Wielaard, P. (2016). Onderzoek naar de beveiliging van patiëntgegevens. PBLQ.

 

Krijgsman, J., Swinkels, I., van Lettow, B., de Jong, J., Out, K., Friele, R., et al. (2016). Meer dan techniek - eHealth monitor 2016. Den Haag en Utrecht.

 

LUMC. (2013). LUMC strategie 2018 - merkbare meerwaarde. Beleidsplan, Leiden.

 

LUMC. (2015). LUMC visie op eHealth. Leiden.

 

MEDDEV 2.1/6. (2012). Figure 1. European Commission.

 

MedMij. (2016). Waarom MedMij? Opgehaald van www.medmij.nl: http://www.medmij.nl/waarom-medmij/

 

Mingay, S., & Mesaglio, M. (2016). Deliver on the promise of bimodal. Gartner.

 

Moll, T., & Schmidt, C. (2016). Documentatie/naslag voor eHealth initiatieven. Leiden.

 

Mulesoft. (2009). What is an ESB? Opgeroepen op 05 24, 2017, van Mulesoft: https://www.mulesoft.com/resources/esb/what-esb

 

Nictiz. (2017). Wat is interoperabiliteit? Opgeroepen op April 4, 2018, van www.nictiz.nl: https://www.nictiz.nl/standaardisatie/interoperabiliteitsmodel

 

NVZ. (2016). Zorg voor 2020. Den Haag.

Registratie aan de bron. (2017). De kern van registreren aan de bron. Opgeroepen op 07 25, 2017, van Registratie aan de bron: https://www.registratieaandebron.nl/wat-is-registreren-aan-de-bron/de-kern-van-registreren-aan-de-bron/

 

Registratie aan de bron2. (2017). Zorginformatiebouwstenen. Opgeroepen op 07 25, 2017, van Registratie aan de bron: https://www.registratieaandebron.nl/wat-is-registreren-aan-de-bron/de-kern-van-registreren-aan-de-bron/zorginformatiebouwstenen/

 

Richtlijn medische hulpmiddelen 93/42/EEG. (1993). Art. 1. Raad van de Europese gemeenschappen.

 

Thomas, A. (2007). Enterprise Service Bus: A Definition. Gartner.

 

van 't Wout, J., Waage, M., Hartman, H., Stahlecker, M., & Hofman, A. (2010). The Integrated Architecture Framework Explained: Why, What, How. Dordrecht: Springer.

 

VWS, M. e. (2014). Kamerbrief over e-Health en zorgverbetering . Den Haag: Ministerie van Volksgezondheid, Welzijn en Sport.

Toon alle referenties

Auteur