Verslag Ronde Tafel Identity- en Accessmanagement 16 september 2010 Op 16 september jl. organiseerden O&i, SmartAIM en PwC een Ronde Tafelbijeenkomst rondom het thema Identity- en Accessmanagement in de zorg. We bespraken onder andere wat de voorwaarden zijn voor een succesvolle implementatie van Identity- en Accessmanagement. De invoering van een softwarepakket is hierbij niet de oplossing. Sterker nog: dat is slechts 20% van het geheel. De weg naar een succesvolle implementatie wordt vooral bepaald door een goed zicht op de processen met taken, verantwoordelijkheden en bevoegdheden, maar ook de cultuuraspecten in een organisatie spelen een grote rol. De succesvolle implementatie bij het Bronovo Ziekenhuis diende tijdens de bijeenkomst als praktijkcase. Wilfred Reinhard, Informatiemanager bij dit ziekenhuis, vertelde welke elementen de successen en valkuilen bepalen.
1. Aanleiding en doelstelling van de bijeenkomst De drie organiserende partners, SmartAIM (Marco Bergman), O&i (Petra van den Brom) en PwC (Tonne Mulder) wilden graag met zorgprofessionals gedachten en ervaringen uitwisselen over de (invoering van de) NEN7510-normering en in het bijzonder omtrent Identity- en Accessmanagement. In de praktijk blijkt namelijk dat dit thema voor uitdagingen zorgt. Het blijkt met name lastig te zijn om te komen tot een systeem dat zowel aan de organisatorische voorwaarden, alsook aan de eisen vanuit ICT-perspectief en de auditingpraktijk voldoet. De doelstellingen die vooraf zijn gedefinieerd: uuzicht krijgen op de problemen die zich voordoen vanuit de verschillende perspectieven; uupraktische oplossingen en routes (vanuit ervaringen) om de NEN7510-normering in 2011 te kunnen behalen; uuzicht op de struikelblokken en de succesfactoren. 2. Casus invoering Identity- en Accessmanagement-systeem bij Bronovo Ziekenhuis door Wilfred Reinhard, Informatiemanager Situatie in 2000 1 Sinds 2000 bezig met autorisaties, een tien-jarenbeleid opgesteld. Destijds was Novell in huis, wilde als partner meedenken om het personeelssysteem leidend te laten zijn voor ICT. Het idee daarachter was om verantwoordelijkheid voor autorisaties dichter bij de business te krijgen. Een eerste slag is gemaakt met een IAM-systeem dat in ieder geval orde op zaken bracht met de accounts. Dit systeem is direct gekoppeld aan het personeelsmanagement-systeem en daardoor is er nu grip op uitgifte en inname van accounts en het password-beleid. Langzaam maar zeker worden op deze manier de nietpersoonlijke accounts opgeruimd. Aanvankelijk is sterk ingezet op de IT-kant van IAM. Nu wordt meer aansluiting gezocht bij wensen van auditors door de processen bij de business te beleggen en beter inzicht te krijgen in uitzonderingen op basis van risico s. De eerste stappen zijn gemaakt met role based access control. Er worden nu al autorisatiepakketten uitgegeven op basis van afdeling en functies.
Het vaststellen van autorisatiepakketten is echter een moeizaam proces. Dat moet voor alle partijen transparant zijn, anders zie je snel door de bomen het bos niet meer. Met SmartAIM wordt nu tooling geïmplementeerd die dat proces transparanter maakt en daarmee wordt een nieuw hoofdstuk ingeslagen. Op het vlak van remote access is geïnvesteerd in SSLVPN-token toegang voor externe partijen, gekoppeld aan de IAM-infrastructuur. Vooralsnog voldoet dat in de behoefte. Voor single-sign on is gekozen voor een password store-and-replay-oplossing van Imprivata. Anno 2010: verantwoordelijkheid verschuift van PZ naar managers. Novell is afgehaakt (met name technische partner), SmartAIM gevonden. Het systeem is 13 september live gegaan. Nu traject portals naar bedrijfsmanagers. Je merkt dat PZ nu huiverig is om het uit handen te gaan geven. De huiver gold voor de ICT-afdeling... Situatie in 2010 1 Vraag: wat gaat de organisatie tegemoet? Wilfred: overzicht wat er op de payroll staat van bedrijfsmanagers. Zij kunnen autorisatie toekennen conform het functiehuis. Er is een apart traject geweest voor het opstellen van het functiehuis. Ja, het functiehuis wordt momenteel herzien en het aantal functies wordt daarbij drastisch teruggebracht. Er worden echter nog geen autorisaties toegekend door de managers; wel is het plan dat de lijnmanagers autorisatiepakketten gaan toekennen aan hun medewerkers. Deze pakketten/rollen zullen primair worden opgesteld op basis van functies uit het nieuwe functiehuis. Vraag: hoe is omgegaan met medewerkers die niet in loondienst zijn? Wilfred: deze medewerkers zijn opgevoerd in systeem met die specifieke rol. Personeel Niet In Loondienst (PNIL). Wilfred: belangrijk bij de invoering is om te zorgen voor gadgets. Dit vergroot de acceptatie. Denk aan singlesign on, remote access. Het is daarbij ook verstandig om de implementatie van de gadgets te doseren, zodat er steeds weer iets nieuws toegevoegd kan worden. Vraag: zijn er nog algemene accounts, bijvoorbeeld op de OK? Wilfred: we zijn er bijna vanaf, de deadline staat op het einde van het jaar. We gooien deze meteen overboord bij de invoering van het nieuwe systeem. Er zijn alleen nog algemene accounts waar het nieuwe systeem nog niet is ingevoerd. Bijvoorbeeld bij SEH en Heelkunde zijn er nog geen persoonlijke accounts aanwezig, deze komen pas na de verbouwing. De kosten liggen uiteindelijk wel hoger, maar we voldoen dan wel aan de eisen. De invoering vindt achter elkaar plaats en niet tegelijkertijd. Vraag: wanneer zijn jullie dit gaan doen, was dit een idee van PZ zelf? Wilfred: dit is in nauwe samenwerking met PZ tot stand gekomen. Al snel bleek namelijk dat er een grote delta niet opgevoerd was. Vraag: worden medewerkers steeds enthousiaster? Wilfred: het enthousiasme gaat in golven. Door steeds weer een nieuwe gadget toe te voegen, stimuleer je het enthousiasme weer. Vraag: en zijn jullie door de accountantscontrole heen? Wilfred: deze staat over twee weken gepland.
3. Gesprekspunten uude business wil zo weinig mogelijk regeltjes, maar dat staat haaks op wat moet. uubeveiliging is met name nog een papieren exercitie. Er moet nog worden beslist hoe dit moet worden ingericht. De NEN7510 is hierbij een hulpmiddel. uuer zijn regels met betrekking tot risicomanagement, maar hoe bed je die in in het bestaande systeem van de organisatie? uugeïnteresseerd in het evenwicht vinden tussen een werkbare situatie enerzijds en voldoen aan wet- en regelgeving anderzijds. uurollen, bevoegdheden en het functiehuis. Vraag: Bij ons zijn er momenteel een flink aantal rollen gedefinieerd waarvan we nu de TBV s (taken, bevoegdheden en verantwoordelijkheden) aan het uitwerken zijn. In de praktijk blijkt dat rollen veranderen en dat rollen teveel op een functie zijn gericht. Hoe is dat bij jullie?. Wilfred: we zijn uitgegaan van het functiehuis en hebben vanuit dit functiehuis de bevoegdheden gedefinieerd. Zo bleken er voor mijn eigen afdelingen maar drie rollen noodzakelijk. Soms is een tijdelijke rol nodig die niet gekoppeld is aan een functie, hier worden aparte rollen voor gedefinieerd (autorisatie self service). Opmerking: in de praktijk blijkt het lastig om rollen en functies uit elkaar te halen. Wilfred: je hebt een goed kostenmodel nodig. Als iedereen alles nodig heeft, zul je er ook voor moeten betalen en licenties zijn duur. Marco: de ervaring met rollen is dat deze veelal te strak zijn ingericht, waardoor je er vaak teveel hebt. Ik heb gezien dat een organisatie op eigen houtje twee jaar bezig is geweest rollen te definiëren en toen uitkwam op veel teveel rollen. Alle autorisaties in rollen willen stoppen, is vragen om een rolexplosie. De ICT is hierin vaak de politieagent. Mag deze rol wel worden aangepast? Kortom: het afdwingen van filtering op de behandelrelatie in systemen lijkt praktisch onhoudbaar in een algemeen ziekenhuis. Deelnemer: bij ons proberen we dat op te lossen door een roleigenaar toe te kennen die bepaalt of de rol mag worden aangepast. In de praktijk blijkt deze echter nog lastig toe te kennen, omdat sommige rollen overstijgend zijn aan het mandaat van de roleigenaar. Deelnemer: bij ons mogen behandelaren maar beperkt in het EPD kijken. Er zijn wel uitzonderingen mogelijk door middel van noodprocedures. In de praktijk blijkt echter dat daar wel erg vaak gebruik van wordt gemaakt. Wilfred: workflows zijn hierbij belangrijk, evenals hoe belegd is wie en hoe erop gestuurd wordt dat de regels zijn gebroken. Het moet in ieder geval breed ingevoerd worden en niet bij ICT alleen blijven. Petra: goed is om te bekijken wat er, naast autorisaties, nog meer wordt beoogd met het functiehuis. Denk aan kwaliteitssystemen en processturing. Tonne: er moet geredeneerd worden vanuit regels en niet vanuit rollen. Dan kun je tenminste aan de business vragen: wil je dat de regel gebroken wordt? In de basis heeft de business impliciet of expliciet regels. Rollen zijn op zijn best voorverpakte pakketten die consistent zijn aan die regels. Deelnemer: de praktijk is echter dat iemand altijd uitzondering op de regel moet zijn. Tonne: is het transparant voor het gehele management dat de regels gebroken worden? En zo ja, wordt er dan ook op gestuurd? Bepaling van rollen: hoe worden rollen bepaald (wie mag wat doen) Deelnemer: ze zijn gemaakt voor het ziekenhuisinformatiesysteem (ZIS) en min of meer gericht op functies. Er is bepaald wie wat mag zien en het systeem is inmiddels in gebruik. Vroeger was de regel: een verpleegkundige mocht informatie van patiënten zien met wie hij/zij contact had. Nu is het zo dat de verpleegkundige informatie van patiënten mag zien als deze patiënt ergens in het ziekenhuis in behandeling is. De business bepaalt welke rol wat mag.
Wijze van aanpak Deelnemer: er loopt een programma Identitymanagement. De werkvloer is sceptisch: we worden niet gehoord. Eigenlijk zou het vanuit de business moeten worden opgepakt en niet zoals geschetst door Wilfred. Wilfred: er is bij ons altijd iemand van de business aanwezig geweest die ook degene is die test. We hebben sessies gehouden waarbij iedereen was uitgenodigd, bijvoorbeeld de neurologen en de poli waren erg geïnteresseerd. Ze hebben er veel profijt van dat als iemand in dienst is gekomen deze ook meteen aan de slag kan. Deelnemer: men gaat er pas over nadenken als ze iets zien. Fast prototyping is een goede manier. Deelnemer: je zou de data los moeten koppelen van het systeem en gaan behandelen als een archief dat je niet mag veranderen. Beschikbaar stellen als onderdeel van een proces. Wie mag wat in systeem doen? De verantwoordelijkheid ligt bij de arts. Tonne: daarin komt het spanningsveld productie versus projecten/randwerkzaamheden weer terug. Petra: de arts voelt zich niet verantwoordelijk en zal het in de praktijk gaan delegeren. Deelnemer: de arts een gadget geven, is bij het aanklikken van een DBC ook gelukt. Deelnemer: het afsprakenmodel moet aangepast worden, niet meer in silo s denken, bijvoorbeeld: een foto is niet van een radioloog. Petra: betrek de gebruiker erbij, dan ontwikkel je gelijktijdig het draagvlak voor de verandering. Deelnemer: bij de inrichting van systemen wordt compliance vaak niet meegenomen. Petra: juist daar is het spanningsveld het grootst: het bestuur denkt in compliance-vraagstukken, de business denkt in directe toepassingen/belemmeringen. Wilfred: dat is bedrijfscultuur. Tonne: na audit/controle komen vaak reparatieacties en dan wordt functionaliteiten afgepakt. Beter eerst minder geven om dit te voorkomen. Deelnemer: bewustwording rondom security is er, maar helaas maar bij een paar mensen. De praktijk is dat een arts met een verzoek komt en dat wordt ingewilligd. (NB: artsen hebben eigen lokale pc s waarop bijvoorbeeld een cd tje wordt geïnstalleerd). Maar deze geëigende weg kent geen risicoanalyse. Wilfred: er is een aantal zaken dat geregeld moet zijn voordat je met IAM kunt beginnen, bijvoorbeeld standaardisatie van het applicatielandschap. Deelnemer F: RvB moet bepalen wat ze willen en waarom.
Wat te doen bij afwijkingen van de regels? Tonne: eigenlijk zou je vooraf in gesprek moeten gaan: aan welke regels te voldoen?. Daar de discussie over voeren. Belangrijk is dat er een soort vertaler is tussen IT en wat de business wil. Alleen rapporteren over afwijkingen. Deelnemer: bespreekbaar maken dat er gebruik is gemaakt van de noodprocedure en aanspreken op de eigen beroepsethiek, zit er een verhaal bij? Zo ja, dan is het verantwoord om af te wijken van de regels. In de praktijk blijkt het echter lastig, omdat je te maken hebt met productie versus projecten. Deelnemer: de meeste mensen doen knoei -acties, omdat ze hun werk willen doen, bijvoorbeeld e-mail als archief gaan gebruiken, omdat het informatiebeleid stelt dat je niet van buiten naar binnen mag. Tonne: het uitgangspunt zou moeten zijn: wat heb je nodig om je werk te kunnen doen? Inzicht en overzicht In de vragenlijst staat de vraag: bent u op de hoogte van geregistreerde gebruikers?. Het antwoord hierop (drie antwoorden gegeven op dat moment): geen tot matig. Dezelfde invullers geven aan dat de ambitie die zij hierin hebben zeer hoog is. Tussen de gewenste en huidige situatie zit dus een groot verschil. Wilfred: doe het stapje voor stapje, houd het overzichtelijk. Tonne: rollen bouwen, maar dan alleen op basis van wat er nu al gebeurt (huidige processen leidend laten zijn). Gebruik het huidige om het nieuwe te bouwen -> efficiënt organiseren door dat te analyseren. Businesscases en e-health (nieuwe werken) Businesscases zijn lastig. Wilfred: beperken tot tien en steeds terug laten komen, inclusief breedgedragen risicoanalyses. Deelnemer: businesscases zijn altijd financieel en gericht op kostenbesparing, het zou meer kwalitatief moeten gaan over te behalen winst, juist voor de business. Hierin is waarschijnlijk wel een verschil tussen UMC s en algemeen ziekenhuizen. Wilfred: daarom hebben wij een strategische alliantie met LUMC. Zij hebben de slagkracht en het Bronovo kan mankracht leveren voor de pilots. Primaire zorg blijft hierin de issue, we hebben het in de samenwerking zelden over ICT-zaken. ICT is faciliterend, altijd. Deelnemer: er is een bestaande samenwerking tussen xxx (algemeen ziekenhuis) en het EMC. In deze samenwerking worden gezamenlijke diensten gedraaid, IAM is daarbij een issue, dat maakt het er niet gemakkelijker op. Petra: over een paar jaar speelt deze issue ook in de keten, bijvoorbeeld toegang tot het EPD door de huisarts, maar ook andere zorgverleners in de ketenzorg. Deelnemer: nog niet zo lang geleden werd de onafhankelijkheid van de huisarts door de zorgverzekeraar als een probleem ervaren. Daar hebben we toen van alles voor opgetuigd en dat verandert straks weer. De vraag aan de arts wordt om flexibel te worden in tegenstelling tot de patiënt die nu flexibel moet zijn. Denk aan Google Health en Patiënt 2.0. Deelnemer: het probleem is dat wetten tegenstrijdig zijn, bijvoorbeeld privacywetgeving versus informatie verstrekken. Er lijkt geen vertaling te zijn van deze tegenstrijdigheden naar de werkvloer. Het model is niet ingericht op informatieverstrekking aan de patiënt, ook technisch niet. Deelnemer: wij hebben gezien hoe leidinggevenden direct betrokken raken als je ze een lijst geeft van werkelijke autorisaties. Ze beginnen direct te strepen en zetten er desgevraagd hun handtekening onder. Vanaf dat moment heb je ze betrokken en vragen ze om manieren om proactief te kunnen zijn.
4. Succesfactoren en struikelblokken rondom IAM uuallereerst geldt dat autorisatiemanagement voornamelijk een businessvraagstuk is, waarbij ICT-tooling een kleine, noodzakelijke faciliterende factor is (80/20). uuop het businessvlak worden de cultuuraspecten van de organisatie met name benoemd als struikelblok danwel als succesfactor. Het wordt ervaren als een puzzel hoe met IAM aan te sluiten op de organisatiecultuur en wel de bereidheid tot verandering blijvend te motiveren (en dus niet alleen maar op de regeltjes te blijven hangen). De balans tussen techniek en organisatie is hierbij de belangrijkste factor. uuhoe kun je de organisatie eigenaarschap laten nemen voor toegang tot systemen? Het is immers de verantwoordelijkheid van het management en ICT is daarbij faciliterend. uudata loskoppelen en beschikbaar stellen aan het management. Patiënt als stakeholder in het systeem zien en niet als leidend voorwerp. uubelangrijk bij de invoering is om te zorgen voor gadgets. Dit vergroot de acceptatie. Denk aan single sign-on, remote access. Het is tevens verstandig om de implementatie van de gadgets te doseren, zodat er steeds weer iets nieuws toegevoegd kan worden. uude regels zoals gehanteerd door de business zijn leidend bij autorisatievraagstukken. Vaak zie je dat die regels al impliciet zijn verwerkt in rollen en dat er een sterke correlatie is met het functiehuis. Maar je zult die regels wel boven water moeten halen als je je rolmodel wilt (her)definiëren. uude business bepaalt welke rol wat mag. De ICT is hierin vaak de politieagent. Mag deze rol wel worden aangepast? uuhet antwoord hierop kan zijn een roleigenaar toe te kennen die bepaalt of de rol mag worden aangepast. In praktijk blijkt dit echter nog lastig te bepalen, omdat sommige rollen overstijgend zijn en het mandaat van roleigenaar overstijgen. uueen organisatie zou moeten redeneren vanuit regels en niet vanuit rollen. Dan kun je tenminste aan de business vragen: wil je dat deze regel gebroken wordt? uude werkvloer is sceptisch (met betrekking tot identitymanagement): we worden niet gehoord. Eigenlijk zou het vanuit de business moeten worden opgepakt, maar de losse businessregels en afdelingen zijn te veelvormig om in een vastomlijnd en mogelijk geautomatiseerd proces te vervatten. uumen gaat er pas over nadenken als ze iets zien. Fast prototyping is een goede manier. uubelangrijk is dat er soort vertaler is tussen IT en wat de business wil. uuwanneer de regels niet gevolgd worden en er dus afwijkingen optreden, is het acceptabel wanneer daar een verhaal bij is. Daarover kun je de medicus bevragen. Echter de praktijk is vaak weerbarstiger dan dat: je blijft in de spagaat tussen productie en projecten. Er blijft weinig tijd over voor het bevragen van elkaar over afwijkingen van de regels. uubetrek de gebruiker bij de ontwikkeling van het systeem, dan ontwikkel je gelijktijdig het draagvlak voor de verandering. uuer is een aantal zaken dat geregeld moet zijn voordat je met IAM kunt beginnen, bijvoorbeeld standaardisatie van het applicatielandschap. uurvb moet bepalen wat ze willen en waarom en met deze opdracht de business en ICT met een passende oplossing laten komen. Meeting halfway tussen Governancebenadering en bottom-up (business). uuprofessionals zijn zeker, maar niet altijd bekwaam. Je moet ze eerst onzeker maken. Noodzaak en belang moet gevoeld worden. De techniek zijn we aan het verlaten. uuover de streep trekken met gadgets en business medeeigenaar maken. Waar zijn ze mee geholpen? uude vraag aan de arts wordt om flexibel te worden in tegenstelling tot de patiënt die nu flexibel moet zijn. Denk aan Google health en Patiënt 2.0. uuinzicht in hier en nu belangrijk. Wat willen we? uuin het begin zijn humor en gemak erg belangrijk.
Afsluiting en evaluatie van de Ronde Tafel Wilfred: ik neem mee dat het inderdaad niet meer om de techniek gaat. Ik ga Google Health en het maken van online afspraken bekijken. Marco: ik had de verwachting dat er een eenduidigere aanpak vanuit de business naar voren zou komen, maar de complexiteit in de inrichting en cultuur van organisaties is te groot. Wat ik heb geleerd is dat inzicht leidt tot actie en dat actie weer leidt tot governance. Als je zorgt dat leidinggevenden geconfronteerd worden met inzicht in de werkelijk te vergeven autorisaties, dan volgt direct de vraag hoe dit te voorkomen? Het moment dat hiermee bereikt wordt, kan men bovenaf aangrijpen om in te passen in compliance-initiatieven. Deelnemer: soms blijft top-down noodzakelijk in plaats van bottom-up. Een soort van confrontatielijst kan werken om te achterhalen wat echt belangrijk gevonden wordt. Tonne: dat is goed te combineren met prototypes en confrontaties met eigen data. Deelnemer: dat werkt inderdaad goed, bijvoorbeeld SAP-bevoegdheden aan de manager voorleggen. Zij gaan dan direct schrappen. Laat ze er een handtekening onderzetten en de praktijk leert dat ze er daarna niet meer vanaf wijken. Deelnemer: vond het zinvol om te horen welke hobbels door anderen al zijn genomen en waar zij staan. Hij zou dergelijke bijeenkomsten bij anderen aanraden, niet alleen omtrent dit thema, maar op allerlei gebieden. Deelnemer: ik vond de interactie en zelf een bijdrage kunnen leveren prettig, tevens zijn veel zaken herkenbaar. Ik had wel gehoopt dat er meer ingegaan zou worden op de link tussen NEN- en Identitymanagement. IGZ komt binnenkort auditen op 33 punten, onder andere op de toegangsidentificatie en wil daarom graag weten hoe NEN en IAM zich tot elkaar verhouden. Deelnemer: daar zijn sessies voor van NVZ. Wilfred: heeft een verslag van de 33 punten en zal dit onderling delen. Tonne: vaak is het tijdens audit alleen nodig om het proces te kunnen laten zien. Deelnemer: vond het heel interessant. Is blij dat de conclusie is om het samen met de business te doen. Nuttig om kennis te delen over hoe je dit doet. Heeft het gevoel dat het nog in de kinderschoenen staat en er nog veel te leren valt over hoe je de vertaling naar de business kunt maken. Deelnemer: de grootste fout die gemaakt wordt is dat de implementatie van NEN bij ICT wordt gelegd. Heeft zij in de dagelijkse praktijk veel last van. Meer informatie Voor meer informatie kunt u contact opnemen met Petra van den Brom van O&i via p.vandenbrom@oi.nl of (030) 289 56 65.