Software-as-a-Service in de zorg

Software-as-a-Service in de zorg

eHEALTH ICT Datum 3 september 2010

ID nummer KA10032

Auteur(s) Marc Lankhorst

Software-as-a-Service (SaaS) is een model voor het leveren van software via het internet. Doordat een aanbieder van een SaaSapplicatie deze aan meerdere klanten levert, biedt dit schaalvoordeel en daarmee lagere kosten. In de zorg vindt dit model langzamerhand ook zijn weg. Wat zijn nu de vooren nadelen en aandachtspunten bij invoering hiervan? Is dit veilig genoeg, wat vraagt het van de ICT-organisatie en past het in de architectuur van een zorgorganisatie?

1

Samenvatting Bij het toepassing van SaaS in primaire zorgprocessen zijn privacy- en beveiligingsaspecten belangrijk. Hoewel er geen fundamentele juridische bezwaren zijn, moet een dergelijke toepassing voldoen aan dezelfde strenge normen die voor de interne systemen en organisatie gelden. Hierbij geeft het gebruik via internet, de koppeling met interne systemen en de rol van externe leveranciers extra complexiteit, zeker in grotere organisaties. Dit vraagt een hoog niveau van professionaliteit van de eigen IT-organisatie en een sterk management van de relatie met de SaaSleverancier. Vanwege de complexiteit en risico’s is het verstandig om eerst ervaring met SaaS op te doen in ondersteunende processen, bijvoorbeeld HRM, voor deze in de primaire zorg toe te passen.

Creative Commons Naamsvermelding-Gelijk delen 3.0 Nederland Licentie is van toepassing op dit werk (http://creativecommons.org)

Introductie

De uitdaging

Nederland is een dienstenland bij uitstek. Internationaal bekleedt ons land een vooraanstaande positie in onder meer handel, logistiek, financiële dienstverlening, zorg-op-maat en ICT-diensten. De dienstensector is daarbij volop in beweging. Organisaties zijn zich in toenemende mate aan het herbezinnen op hun strategie en businessmodel.

Het inhuren van softwareservices op afstand maakt deel uit van deze trend naar specialisatie en focus op kerncompetenties. Als alternatief voor het zelf ontwikkelen of kopen van bedrijfssoftware kunnen bedrijven er voor kiezen software als dienst op afstand, via het internet, “te huren”.

Dit zien we ook in de zorgsector, in het bijzonder in grote instellingen zoals ziekenhuizen waarop dit artikel zich vooral richt. Steeds meer worden zorginstellingen door de consument benaderd als commerciële dienstverleners waar men zorg kan inkopen. Patiënten vragen steeds vaker zorg op maat, en liefst ook nog thuis. Het traditionele model van ziekenhuizen wordt steeds meer verlaten en maakt plaats voor een decentraal zorgmodel, waar patiënten voor een groot deel zichzelf verzorgen met geschikte hulpmiddelen of zich individueel of kleinschalig laten verzorgen. Het is een brede trend dat organisaties, ook in de zorgsector, zich steeds meer op hun kerncompetenties concentreren en andere activiteiten uitbesteden. Een goed voorbeeld is C&A, dat niet zelf een internetwinkel is begonnen, maar hierin samenwerkt met Wehkamp. Outsourcing is ook in de financiële wereld aan de orde van de dag. Dit gaat verder dan IT en betreft in toenemende mate ook de bedrijfsprocessen, bijvoorbeeld schadetaxaties of hypothekenadministratie.

Een dergelijke ontwikkeling is al een flink aantal jaren geleden ingezet. Eerst ging het om eenvoudige hosting van applicaties, waarbij alleen de technische infrastructuur door een externe dienstverlener werd geleverd. Vervolgens kwam “Application Service Provisioning” (ASP) op, waarbij ook het applicatiebeheer door een externe partij werd uitgevoerd. Bijvoorbeeld in de markt voor huisartsinformatiesystemen (HIS) wordt het ASP-model toegepast. Dit model is echter niet breed doorgebroken, omdat het is gebaseerd op een directe koppeling tussen applicatie en afnemer: voor elke klant wordt een eigen exemplaar van de software geïnstalleerd. Die software is vaak niet ontwikkeld voor meerdere gebruikers tegelijk of voor levering via het web, wat de schaalvoordelen beperkt.

Wat is SaaS? Nieuwere modellen voor het leveren van software, onder de noemer “Software as a Service” (SaaS), gaan er vanuit dat verschillende afnemers prima gebruik kunnen maken van dezelfde software-installatie, mits die software daarop is ingericht en deze gebruikers en hun gegevens strikt gescheiden blijven. Hierdoor kan een aanbieder schaalvoordelen behalen, schaarse expertise beter inzetten en daarmee lagere kosten aan zijn afnemers berekenen. SaaS maakt deel uit van de bredere trend naar “cloud computing”, waarbij ICT-voorzieningen steeds meer via het internet (de “cloud”) wor-

2


den aangeboden. Andere concepten die hieronder vallen zijn “Infrastructure-as-a-Service” (IaaS), voor het op afstand leveren van technische infrastructuur zoals opslag, rekenkracht en netwerkvoorzieningen, en “Platform-as-aService” (PaaS), waarbij de dienstverlener een platform (hardware, besturingssystemen e.d.) biedt waarop de afnemer zijn zelf ontwikkelde applicaties kan uitvoeren. Naast volledig publieke cloud-oplossingen zoals bedrijven als Amazon en Google die aanbieden, is het ook mogelijk je eigen “private cloud” in te richten of een “community cloud” van samenwerkende organisaties te gebruiken. Zo werkt de Amerikaanse overheid aan een eigen “government cloud”. Een praktisch voordeel van SaaS is dat de uitrol van de software bij de leverancier gebeurt. Daarmee is de implementatie van een nieuwe toepassing vooral een kwestie van de juiste koppelingen leggen met de eigen applicaties. Dat is weliswaar niet altijd eenvoudig, maar veel minder werk dan een volledige uitrol van eigen soft- en hardware. SaaS-oplossingen zijn ook beter schaalbaar: het is eenvoudig om meer gebruikers of locaties te ondersteunen of groeiende hoeveelheden gegevens op te slaan, zonder zelf bijvoorbeeld hardwarecapaciteit bij te hoeven plaatsen. Een nadeel van SaaS is de beperkte flexibiliteit. Het is voor de aanbieder niet rendabel om alle verschillende wensen van klanten met specifieke oplossingen te ondersteunen. SaaS is een “one size fits all” oplossing en daarin zit ook het schaalvoordeel en de besparing voor de leverancier. Eigen functionele wensen of maatwerkkoppelingen met andere applicaties zijn niet altijd mogelijk.

gebruikers, gegevens of locaties bijkomen omdat er geen extra investeringen in bijvoorbeeld hardware of licenties nodig zijn. De aanbieder vangt dit op via de “wet van de grote getallen”: de pieken van verschillende afnemers vallen zelden op hetzelfde moment. De afnemer hoeft zo vooraf een veel lagere investering in hard- en software te doen. Dit beperkt bovendien de financiële risico’s; iedereen kent de voorbeelden van mislukte investeringen in interne IT-projecten. In de praktijk blijkt overigens de flexibele kostenstructuur van SaaS soms tegen te vallen. Veel leveranciers werken met vaste abonnementen per gebruiker en rekenen geen “tikken” af. Net als bij conventionele software leidt dit soms tot ongebruikte licenties en abonnementen.

Netwerk SaaS-oplossingen zijn van nature ingericht op toegang via het internet. In een zorgsector waar keten- en netwerkzorg een groeiend belang hebben, is het “altijd en overal” toegang hebben tot de juiste diensten en gegevens voor zorgverleners steeds belangrijker. SaaS-oplossingen kunnen zo bijdragen aan een verbetering van processen, een efficiëntere organisatie, betere planning en coördinatie tussen betrokkenen, en een reductie van overhead. Die genetwerkte aard van SaaS-toepassingen is niet alleen een voordeel. Doordat er veel tussenschakels en complexe verbanden zijn tussen gebruiker en software, zijn er meer verstoringen mogelijk en is de analyse van de betrouwbaarheid niet eenvoudig. In de praktijk blijkt die betrouwbaarheid echter vaak zeker zo goed als van “on premise” software.

Betalen naar gebruik Een belangrijke belofte van SaaS is dat de afnemer betaalt voor het gebruik van de software en eenvoudig op kan schalen wanneer er

3


De werkwijze Bij het beoordelen van de mogelijkheden van SaaS in de zorg, in het bijzonder in ziekenhuizen, moeten we allereerst een onderscheid maken tussen de ICT-ondersteuning van primaire zorgprocessen, hieraan direct gerelateerde processen (bijv. declaratieverkeer of inkoop) en ondersteunende processen (bijv. kantoorautomatisering of personeelsadministratie). Voor die laatste categorie is een ziekenhuis sterk vergelijkbaar met andere organisaties. De eerste twee categorieën zijn veel specifieker waar het gaat om de inhoud van de ICT-toepassingen zelf. Bovendien vereist de inzet in primaire zorgprocessen bijzondere waarborgen om continuïteit en privacy te waarborgen. In dit artikel gaan we dan ook in het bijzonder in op deze zorgspecifieke aspecten. Een voor de hand liggende toepassing van SaaS is in elektronische patiëntendossiers (EPD’s). Het gaat daar immers per definitie al om een online toepassing die door verschillende partijen gebruikt moet kunnen worden. In de geestelijke gezondheidszorg wordt bijvoorbeeld gewerkt aan een EPD in SaaS-vorm (zie kader), maar dit is slechts een van de vele voorbeelden. Huisartsen gebruiken al op grote schaal HIS’en die via SaaS en (vooral) ASP worden geleverd. In sommige landen is ook al ervaring met het gebruik van ziekenhuisinformatiesystemen (ZIS’en) via SaaS. Een voorbeeld is Wipro, dat in India de applicatie HIS Lite levert aan verschillende kleine ziekenhuizen. Het genetwerkte karakter van SaaS past ook in de trend dat zorgconsumenten zelf meer actief betrokken zijn in diverse processen in de zorg en niet alleen als “passief patiënt” worden behandeld. De toenemende focus op preventie, welzijn en kwaliteit van leven gaat gepaard met een groeiende ondersteuning

4

door online ICT-diensten op tal van terreinen, zoals de selectie van zorgaanbieders, het helpen bij een gezondere levensstijl, telemonitoring van ambulante patiënten, communicatiemogelijkheden zoals video-interactie, enzovoort. De opkomst van personal health records (PHR’s) zoals Microsoft HealthVault en Google Health, waarin de zorgconsument zijn eigen zorgdata beheert, past hier ook bij. Al deze online diensten zijn te beschouwen als verschillende verschijningsvormen van SaaS. EPD in de GGZ GGZ-instellingen gebruiken, net als andere zorgpartijen EPD’s, die hun werkprocessen moeten ondersteunen. Op die manier draagt het bij aan de kwaliteit en efficiency van de zorg. GGZ Nederland heeft een Referentiemodel voor een EPD (REPD) voor de GGZ ontwikkeld. Dit bevat een beschrijving van de zorgprocessen in de GGZ en een definitie van de ICT-ondersteuning die daarbij hoort. Mede op basis hiervan is begin 2010 een aanbesteding voor een gezamenlijk EPD voor de GGZ gestart [1], waarin expliciet is gevraagd zo mogelijk verschillende vormen van dienstverlening (aanschaf, ASP of SaaS) uit te werken. Verschillende leveranciers hebben op deze aanbesteding gereageerd, waaronder consortia die een volledig webgebaseerd systeem op basis van SaaS aanbieden. Na een test met 8 proofs of concept is in juli 2010 geconcludeerd dat geen van de leveranciers op dit moment aan de eisen voldoet en is besloten hen meer tijd te gunnen om begin 2011 een nieuwe proof of concept fase in te gaan.

SaaS-diensten lenen zich ook goed in combinatie met dienstverlening aanpalend aan de zorg. Hierbij kunnen we denken aan gemeentelijke dienstverlening, zoals het aanbod aan sport en cultuur dat de gemeente subsidieert of WMO-faciliteiten waarvan de patiënt zich mogelijk niet bewust is. Ook verzekeraars bieden tal van diensten, zoals informatie over preventieprogramma’s, zorgaanbieders, vergoedingen, en soortgelijke dienstverlening.


Business case Om een gefundeerde keuze voor een SaaSoplossing te maken, zal elke organisatie eerst een business case moeten opstellen. Hierin moeten kosten, baten en risico’s goed tegen elkaar worden afgewogen. Voor de financiële kant van de business case kunnen de gebruikelijke instrumenten worden ingezet, zoals een berekening van de total cost of ownership van een traditionele oplossing versus de kosten van integratie en gebruik van een SaaS-toepassing. Dergelijke analyses zijn niet wezenlijk anders dan voor een afweging tussen een eigen of een geleased wagenpark, of tussen een gebouw in eigendom of huur. Wel zullen de integratiekosten van een SaaSoplossing goed in kaart gebracht moeten worden. Bij het toepassen van SaaS voor een systeem dat met veel andere systemen is gekoppeld, kunnen de kosten en risico’s van die integratie wel eens een struikelblok vormen.

Risico’s In primaire zorgprocessen gaat het enerzijds letterlijk om mensenlevens en anderzijds om zeer privacygevoelige gegevens. Een goede risicoanalyse en bijbehorende maatregelen zijn dus van het grootste belang wanneer SaaS in die primaire zorg wordt toegepast. Omdat een SaaS-oplossing via een netwerk geleverd wordt, moet ook de betrouwbaarheid van tussenliggende schakels in deze analyse worden meegenomen. Certificering van systemen en leveranciers, zoals elders in dit artikel besproken, zal noodzakelijk zijn bij toepassing in de primaire zorgprocessen. En natuurlijk zijn regelmatige audits nodig om te garanderen dat de door de leveranciers beloofde zekerheidsniveaus daadwerkelijk gehaald worden. Inzet van SaaS in secundaire processen zoals de salarisadministratie is minder risicovol. Wanneer een organisatie zoals een ziekenhuis

5

voor het eerst met SaaS wil gaan werken, verdient het dan ook aanbeveling om te starten met een dergelijke minder kritieke toepassing. Maar ook daar is een heldere afweging van voors en tegens noodzakelijk. Ondanks goede afspraken met leveranciers kan het onverhoopt toch mis gaan. Zo is er het gevaar van afhankelijkheid en lock-in: hoe migreert u ooit nog naar een andere aanbieder? Het verdient aanbeveling om contractueel vast te leggen dat eventuele migratie naar een andere aanbieder door de leverancier actief zal worden ondersteund: laat uw data niet “opsluiten”. Een organisatie dient zich dan ook in te dekken tegen rampscenario’s (die er natuurlijk ook al moeten zijn voor de uitval van eigen ICT-voorzieningen). Dat betekent onder meer het zorgen voor uitwijkvoorzieningen, desnoods met handmatige processen en papieren patiëntendossiers. Een andere maatregel is zogenaamde “escrow” van de software, waarbij een derde partij de broncode beheert en deze in geval van een faillissement kan vrijgeven. Zo voorkomt u dat het wegvallen van de leverancier uw gegevens en systemen onbruikbaar maakt.

IT-organisatie Wanneer er in een grote organisatie zoals een ziekenhuis sprake is van een complex ITlandschap met meerdere SaaS-aanbieders en talloze eigen applicaties, is de beheersbaarheid en strategische ontwikkeling hiervan een groot aandachtspunt. Een voldoende professionele IT-organisatie is dan ook een voorwaarde voor de succesvolle toepassing van SaaS. Uitbesteding, en dus ook SaaS, vraagt een professionele inrichting van de eigen demandorganisatie, om op een gelijkwaardig niveau met leveranciers te kunnen samenwerken. Dit vereist dat:


er een duidelijke en samenhangende visie is op de organisatiestrategie en het ITbeleid, en de verantwoordelijkheden voor realisatie hiervan zijn belegd; vanuit deze visie de huidige en gewenste bedrijfs-, informatie en IT-architectuur goed in beeld is en er een goede regie wordt gevoerd om deze toekomstvisie te realiseren; bedrijfsprocessen organisatiebreed helder zijn en waar mogelijk op een gelijksoortige manier worden ingericht, zodat een SaaSoplossing breed kan worden ingezet; eilandautomatisering wordt doorbroken en applicaties worden geconsolideerd en gestandaardiseerd, zodat schaalvoordelen behaald kunnen worden; het eigenaarschap van applicaties helder is en de verantwoordelijkheid voor uitwisselafspraken, SLA’s, koppelvlakken e.d. helder is belegd; de eigen ICT-processen professioneel zijn ingericht. Denk bijv. aan vendor- en contractmanagement, auditprocessen, incident management et cetera. Voor de inrichting van een ICT-organisatie zijn verschillende methoden en standaarden beschikbaar, zoals ITIL [2]. Deze kunnen een goede leidraad vormen bij deze professionalisering. Belangrijk is vooral ook het inkoopproces; daarvoor kan bijvoorbeeld het CMMI for Acquisition [3] volwassenheidsmodel goede diensten bewijzen.

Relatie met aanbieder Als de keuze voor SaaS is gemaakt, is het belangrijkste de zorgvuldige selectie van een aanbieder. Omdat het gaat om een langeretermijn relatie en (bij gebruik in het primaire zorgproces) om zeer gevoelige informatie, is de ervaring, betrouwbaarheid, stabiliteit en levensvatbaarheid van die aanbieder cruciaal, en zelfs belangrijker dan de specifieke functionaliteiten die zijn SaaS-oplossing te bieden

6

heeft. In die relatie staat het maken van goede afspraken centraal. Niet alleen technische “service level agreements” (SLA’s) over zaken als performance en uptime, maar vooral ook dat wat vanuit de eigen primaire processen en gebruikers belangrijk is; denk bijvoorbeeld aan zaken als de efficiëntie van zorgprocessen, een betere inplanning van patiënten, of grotere tevredenheid van patiënten door online beschikbare informatie. Daarbij is het goed meten van de afgesproken prestatie-indicatoren ook van groot belang, zodat hierover geen discussie kan ontstaan. Regionale functie Voor sommige organisaties, bijvoorbeeld ziekenhuizen met een belangrijke regionale functie, kan er een rol zijn als SaaS-leverancier aan andere zorgpartijen in dezelfde regio. Voorbeelden hiervan zijn onder meer in de VS te vinden, zoals Fletcher Allen, een academisch ziekenhuis in Vermont dat artsen en kleinere ziekenhuizen in de regio toegang tot zijn EPD geeft, en de Cleveland Clinic in Ohio die een EPD-oplossing levert aan artsen die regelmatig patiënten naar hen doorverwijzen.

Bij meerdere aanbieders, en in een grote organisatie als een ziekenhuis is dat al gauw het geval, zal ook de samenwerkingsbereidheid van aanbieders een grote rol moeten spelen. Verder is er bij dergelijke complexe en langdurige projecten vrijwel altijd sprake van voorschrijdend inzicht. Een leverancier die hierin actief meedenkt en een goede procedure voor bijvoorbeeld meerwerk zijn onontbeerlijk.

Architectuur Het inpassen van SaaS in de architectuur van een ziekenhuis is geen sinecure. Als bijvoorbeeld een compleet ZIS via SaaS zou worden geleverd, zijn er zeer veel afhankelijkheden op technisch en applicatieniveau, maar ook in de bedrijfsprocessen, omdat een ZIS als spin in het web met allerlei andere systemen is gekoppeld. Vervanging daarvan wordt wel vergeleken met een hart-long-levertransplantatie.


Architecturen kennen vaak een gelaagde opbouw, waarin een onderscheid gemaakt wordt tussen bijvoorbeeld de organisatie en bedrijfsprocessen, informatie, applicaties en technische infrastructuur (zie de figuur). Op elk van die niveaus kan SaaS impact hebben.

door nieuwe informatiestromen. In de informatielaag van de architectuur moet, bijvoorbeeld door gebruik van standaarden, worden afgezekerd dat er geen begripsverwarring kan ontstaan, zoals ook besproken in het kennisartikel over interoperabiliteit [4].

Zoals besproken kan een SaaS-toepassing vaak minder goed worden aangepast, omdat diezelfde applicatie ook door andere organisaties wordt gebruikt. De organisatie en bedrijfsprocessen moeten zich dus mogelijk meer aan het systeem aanpassen dan andersom; niet ideaal, en een mogelijke oorzaak van weerstand bij medewerkers. Invoering van een SaaStoepassing vraagt dus ook om een goede begeleiding van het organisatorische veranderproces en is niet alleen een “IT-feestje”.

De impact op de applicatielaag is ook groot. Verschillende systemen moeten goed kunnen worden gekoppeld. Dit is des te complexer wanneer sommige van die systemen door andere partijen beheerd worden. De integratie met eigen systemen is dan vaak lastiger, want even snel iets erbij bouwen is geen optie. Het gebruik van open standaarden en goede interfaces is dan ook van groot belang bij het kiezen van SaaS-toepassingen die met andere systemen moeten samenwerken, zeker bij meerdere SaaS-leveranciers.

Met SaaS komen sommige gegevens buiten de eigen muren te berusten. Er ontstaan daar-

Applicaties

Informatie

Organisatie & Processen

Door het gebruik van SaaS is er in de infrastructuurlaag minder beAndere Verzekeraars Leveranciers ... hoefte aan servercapaciteit. zorgpartijen patiënten Opschalen van het aantal gebruikers heeft minder huisartsen impact, omdat de SaaSOndersteunende specialisten leverancier dit grotendeels processen voor zijn rekening neemt. verplegend personeel Anderzijds zal vooral de conZorgprocessen Beheerprocessen nectie met het internet ondersteunend personeel zwaarder worden belast en worden de performance en PatiëntenAfspraken Declaraties Voorraden Bestellingen ... beschikbaarheid hiervan dossiers belangrijker. Specifieke applicaties stellen hierbij hun eigen eisen, bijvoorbeeld Callcenter Portaal ERP ... ZIS “medical imaging” toepassingen, die met grote datavoBeeldverwerking Tracking & Planning EPD Lab (PACS) tracing lumes en hoge bandbreedtes werken.

Infrastructuur

Identiteitsen toegangsbeheer

Documentbeheer

PC’s

Servers

7

Digitaal archief

Mobiele devices

Virtuele werkplek

Interne netwerken

LSP

...

Externe netwerken, internet

In de infrastructuur vinden we ook identiteitsbeheer en toegangscontrole, waarop we nu nader ingaan.


Privacy en beveiliging Een zeer belangrijk aandachtspunt bij het toepassen van SaaS is de beveiliging. In een recent onderzoek van KPMG [5] onder 125 bedrijven en overheidsinstellingen in Nederland wordt dit als grootste probleem genoemd. In de zorg betreft dit vooral de privacy van de patiënt. Het College Bescherming Persoonsgegevens (CBP) heeft onlangs in een brief aan Minister Klink van VWS gewaarschuwd dat op dit moment de toepassing van ASP en SaaS in de zorg onvoldoende helder is geregeld. Het CBP is van mening dat de onduidelijkheid rondom het beroepsgeheim en de rol van ICTdienstverleners opgelost moet worden door nieuwe regelgeving of zelfregulering. Er zijn echter geen fundamentele bezwaren, mits de juiste waarborgen in acht genomen worden [6]: “Vanuit de algemene principes van gegevensbescherming bestaan geen principiële bezwaren tegen de uitbesteding van verwerking van patiëntgegevens, indien en voor zover het medisch beroepsgeheim daarbij wordt gerespecteerd. Dit laatste betekent in concreto dat waarborgen dienen te worden geboden voor een veilige en discrete verwerking bij de dienstverlener. Hierbij kan met name worden gedacht aan toepassing van de normen NEN 7510/7511/7512, aangevuld met specifieke normen die zien op de verhouding zorgverlener – ASP, bijvoorbeeld ten aanzien van de zeggenschap van de zorgverlener over de uitbestede verwerking en de bij de ASP aanwezige persoonsgegevens.” Het centrale vraagstuk in de beveiliging van een SaaS-toepassing is gebruikers- en toegangsbeheer (“identity management”): wie krijgt toegang tot welke gegevens en hoe worden die identiteiten beheerd? Ten eerste moet worden voorkomen dat een SaaS-leverancier zelf identiteitsinformatie opslaat. Zeker wanneer bijvoorbeeld dezelfde gebruikersnamen en wachtwoorden worden

8

gebruikt voor toegang tot verschillende systemen (“single sign-on”), zou een beveiligingsprobleem bij een externe leverancier kunnen overslaan op andere systemen. Een oplossing hiervoor is gefedereerd identity management, waarbij een zogenaamde “identity provider” (bij voorbeeld het ziekenhuis zelf of een andere sterk vertrouwde partij) de toegangscontrole uitvoert en de SaaSleverancier hiermee koppelt. Als een andere partij dit doet namens de zorginstelling wordt dit ook wel Identity-as-a-Service (IDaaS) genoemd. Het UZI-pas systeem is hier een voorbeeld van, waarin het CIBG de rol van vertrouwde partij speelt. Ten tweede moet de levenscyclus van een identiteit en hun rechten goed worden beheerd (“identity provisioning”): het toevoegen van mensen en het verstrekken van toegangsrechten, maar vooral ook het weer verwijderen en van de mensen en het intrekken van die rechten. Dit vraagstuk speelt ook al sterk binnen elke grote organisatie, waarin mensen tot veel verschillende systemen toegang moeten krijgen. Dit vereist een goede koppeling met bijvoorbeeld HR-systemen, en een goed overzicht van wie welke rechten heeft. Bij de toekenning van toegangsrechten gelden, net als voor alle andere toegang tot patiëntgegevens, de Wet op de Geneeskundige Behandelovereenkomst (GBO) en de Wet op de Beroepen in de Individuele Gezondheidszorg (BIG). Bij gebruik van SaaS-oplossingen is het belangrijk om zowel de lifecycle van identeiten als het overzicht van hun rechten goed te blijven regelen. Hiervoor kan een gefedereerde aanpak worden gebruikt zoals hiervoor beschreven, al dan niet in combinatie met een automatische (de)provisioning oplossing. Dat laatste kan ook een oplossing bieden voor het probleem dat een gebruiker soms eerst in een systeem bekend moet zijn voordat hem of haar de juiste rechten kunnen worden toegekend.


Bij selectie van een SaaS-oplossing zal dus de manier waarop identiteiten worden beheerd een belangrijk criterium zijn. Op dit moment is dit speelveld echter nog sterk in ontwikkeling en zijn er nog weinig breed gedragen oplossingen beschikbaar waarmee SaaSoplossingen al standaard kunnen samenwerken. Een standaard zoals SAML 2.0 lijkt hierin wel verandering te kunnen brengen, met name als het gaat om het single sign-on stuk en om te voorkomen dat voormalige werknemers rechten houden. Vanzelfsprekend zijn ook alle beveiligings- en beheernormen die gelden voor een intern systeem van toepassing op een SaaSoplossing. Voor de zorg zijn dit onder meer de ook door het CBP aangehaalde NEN-normen voor informatiebeveiliging in de zorg [7]. Net als bij een EPD zijn bij een SaaS-applicatie ook de eisen aan netwerkverbindingen van belang. Een “gewone” internetconnectie zal hieraan niet voldoen. Minimaal is versleuteling van berichtenverkeer via een virtual private network (VPN) vereist om voldoende veiligheid te bieden. Daarnaast zijn eisen aan de beschikbaarheid en betrouwbaarheid van een netwerkverbinding niet met een gewone internet-verbinding te realiseren, omdat die alleen op basis van “best effort” wordt geleverd. Ook daar zijn aanvullende maatregelen gewenst. Verder gelden ook in een SaaS-context de gebruikelijke maatregelen van informatiebeveiliging, zoals functiescheiding, het “need to know” principe en compartimentering, om te voorkomen dat een schending van de beveiliging van één systeem gevolgen heeft voor andere systemen. De aanbieder moet hierover transparant zijn en inzicht geven in de gehanteerde procedures, een goede rapportage van incidenten garanderen en de juiste mogelijkheden voor auditing bieden.

9

Conclusies SaaS biedt veel mogelijkheden en potentiële voordelen in tal van sectoren. Lagere investeringskosten en grotere schaalbaarheid zijn de belangrijkste, maar ook de lagere behoefte aan schaarse IT-kennis speelt een rol. Omdat het in primaire zorgprocessen enerzijds letterlijk om leven en dood gaat en anderzijds om zeer privacygevoelige gegevens, gelden hier zeer sterke eisen aan betrouwbaarheid en gegevensbescherming, ook voor de SaaS-dienst. Veel organisaties zullen er daarom voor kiezen om dergelijke toepassingen toch “on premise” uit te voeren, hoewel er goede technische mogelijkheden zijn om betrouwbaarheid en veiligheid te realiseren. Het is verstandig eerst ervaring met SaaS op te doen in secundaire processen. Zo zijn er tal van voorbeelden van het gebruik in personeels- en salarisadministratie, binnen en buiten de zorg. Tegelijk kan dan de professionaliteit van de eigen IT-organisatie op peil worden gebracht om als gelijkwaardige partner met SaaS-leveranciers te kunnen samenwerken. Een goede business case en duidelijke afspraken met leveranciers zijn voorwaarden voor succes, evenals aandacht voor risico’s, beveiliging en het voldoen aan wet- en regelgeving. SaaS-oplossingen moeten passen in de langere-termijn strategie en architectuur van de organisatie. SaaS gaat verder dan alleen een technische oplossing, maar vraagt om een goede afweging tussen de flexibiliteit van een interne oplossing en voordelen als schaalbaarheid en kostenbeheersing bij SaaS. Het vervangen van interne eilandautomatisering door SaaS-eilandjes is niet verstandig en leidt tot onbeheersbare integratieproblemen. Beter is te kiezen voor een groeistrategie waarin SaaS-toepassingen geleidelijk worden uitgerold over de organisatie.


Dankwoord Dit artikel is mede tot stand gekomen dankzij aanwijzingen, bijdragen en inspiratie van Fred Smeele (Nictiz), Maarten Wegdam (Novay), prof. Hans Wortmann (RuG) en het ICT Innovatieplatform SaaS (IIP-SaaS, www.iipsaas.nl).

Verwijzingen 1.

2. 3.

4. 5.

6.

7.

10

Factsheet Aanbesteding EPD GGZ, http://www.ggznederland.nl/informatiebeleid /factsheet-aanbesteding-epd-ggz-dec2009.pdf IT Infrastructure Library, http://www.itilofficialsite.com CMMI for Acquisition, Version 1.2, http://www.sei.cmu.edu/library/abstracts/rep orts/07tr017.cfm Paul Oude Luttighuis, Interoperabiliteit in de zorg, Nictiz kennisartikel KA10001, april 2010. KPMG IT Advisory, From Hype to Future, KPMG’s 2010 Cloud Survey. http://www.kpmg.nl/Docs/Corporate_Site/Pu blicaties/From_Hype_to_Future.pdf CBP, ASP’s in de zorg, brief aan de Minister van VWS, 15 december 2009. http://www.cbpweb.nl/Pages/med_20100219 _uitbesteding_verwerking_pati%C3%ABntgege vens.aspx Steunpunt NEN 7510, http://www.nen7510.org/

Nictiz is het landelijke expertisecentrum dat ontwikkeling van ICT in de zorg faciliteert. Met en voor de zorgsector voorziet Nictiz in mogelijkheden en randvoorwaarden voor elektronische informatieuitwisseling voor en rondom de patiënt. Wij doen dit ter bevordering van de kwaliteit en doelmatigheid in de gezondheidszorg. Nictiz Oude Middenweg 55 2491 AC Den Haag Postbus 19121 2500 CC Den Haag T 070 317 3409 E [email protected] www.nictiz.nl


Software-as-a-Service in de zorg

Recommend Documents