4.7 Risicomatrix

Inleiding

Het volgende template is gebruikt voor de risicomatrix https://medmij.atlassian.net/wiki/x/AgC0D . De tabelindelingen, schaal en ook de categorieën Strategisch, Operationeel, Financieel zijn overgenomen uit dit template.

De volgende informatie staat in de kolommen beschreven:

Categorie van het risico
Detecteerbaarheid: de kans dat iemand dit risico identificeert/ ziet
Kans: kans dat dit risico optreedt
Impact: de impact van het risico wanneer dit optreedt voor de maatschappij, de gebruiker, etc.

De risicomatrix is nog ‘work in progress’ en moet nog verder uitgewerkt worden. In deze risicomatrix staan alleen de risico’s die betrekking hebben op het solution design zelf en het testen en implementeren van het solution design. De projectrisico’s voor de projecten Persoonsgerichte hybride netwerkzorg en KoppelMij staan beschreven in de startnotities.

Overzicht risico’s

Nr	Categorie	Beschrijving	Detecteerbaarheid (1-4)	Kans (1-4)	Impact (1-4)	Toelichting Kans en/of Impact	Totaalrisico (Kans x Impact)
Ra01	Strategisch - Veiligheid & betrouwbaarheid Afsprakenstelsel	Identiteitsverwisseling: De PGO-gebruiker heeft langdurige toestemming gegeven en geeft de inloggegevens van zijn PGO aan een andere persoon. Deze andere persoon logt in op de PGO van de PGO-gebruiker en kan een module starten, hoewel deze persoon hiervoor geen toestemming heeft van de PGO-gebruiker.	2	1	4	De kans bestaat dat PGO-gebruikers een andere Persoon de inloggegevens geven om hulp te krijgen bij hybride zorg. De kans dat die Persoon de de inloggegevens heeft, maar geen toestemming heeft en deze oneigenlijk gebruikt, wordt laag geschat.	4
Ra02	Strategisch - Veiligheid & betrouwbaarheid Afsprakenstelsel	Onveilige modules kunnen mogelijk bij opschaling (na dit project) aangeboden worden aan PGO-gebruikers via de PGO.	4	1	4	Zorgaanbieders hebben verantwoordelijkheid voor het garanderen van de veiligheid van de modules die zij voorschrijven. De verwachting is daarom dat de kans klein is dat dit gebeurt.	4
Ra03	Strategisch - Veiligheid & betrouwbaarheid Afsprakenstelsel	Er zitten fouten in het solution design. Hieronder kunnen er gegevens gestolen worden en misbruikt. is dit risico reëel? is het nog nodig om een security expert naar het solution design te laten kijken of niet nodig?	1	1	4		4
Ra04	Strategisch - Veiligheid & betrouwbaarheid Afsprakenstelsel	Er zitten in onveiligheden in de implementatie van het solution design door de DVA- of PGO-, of module-leverancier. Hieronder kunnen er gegevens gestolen worden en misbruikt.	1	1	4	De kans hierop is naar verwachting klein, zolang het testproces zorgvuldig is ingericht en zorgvuldig wordt doorlopen	4
Ra05	Strategisch - Gebruiksvriendelijkheid Afsprakenstelsel	Gebruikersonvriendelijkheid door meerdere keren inloggen Patiënten moeten nu drie keer inloggen (PGO, zorgaanbieder, module), wat als omslachtig wordt ervaren. Dit kan leiden tot lage adoptie. De VAD (Vertrouwde Authenticatiedienst) zou dit kunnen oplossen, maar is nog niet beschikbaar.	4	4	4		16
Ra06	Strategisch - Gebruiksvriendelijkheid Afsprakenstelsel	De weergave van de module is slecht te lezen in de PGO PGO-leveranciers geven aan geen garantie te kunnen geven over goede weergave, wanneer de weergave van modules niet van te voren getest wordt in de PGO	4	3	4		12
Rb01	Compliance /juridisch	Onjuist gebruik module-gegevens De module waarnaar de PGO verwijst, verzamelt gegevens van de gebruiker voor onderzoek. Zonder dat de gebruiker hiervoor om toestemming wordt gevraagd.	1	1	4	Volgens de huidige wetgeving mogen Zorgaanbieders en module-leveranciers dit niet doen	4
Rb02	Compliance / juridisch	Foutief betrouwbaarheidsniveau van inloggen bij module De module vraagt de gebruiker niet om opnieuw in te loggen. Hoewel in de module privacy gevoelige gegevens ingevoerd worden, die gebruikt worden voor besluitvorming over de behandeling van de gebruiker. En een extra controle van de identiteit van de gebruiker (inloggen) hiervoor eigenlijk wel noodzakelijk is.	1	3	2		6
Rc01	Operationeel - Afhankelijkheden van leveranciers / externe partijen	Identiteitsverwisseling Er is Single Sign On ingericht zodat de PGO-gebruiker niet opnieuw hoeft in te loggen bij de module, als de PGO-gebruiker al ingelogd is in de PGO en toestemming heeft gegeven. De identiteit van de Persoon die de DVA doorgeeft aan de module (klopt dit), is echter de identiteit van een ander Persoon, kan dit?	?	?	?
		Zijn er andere mogelijke oorzaken van Identiteitsverwiseling die we moeten opnemen?
Rc02	Operationeel - Afhankelijkheden van leveranciers / externe partijen	Verstoring van beschikbaarheid De module waarmee (hybride) zorg wordt geleverd, is tijdelijk niet beschikbaar. Omdat de module is uitgevallen en tijdelijk niet beschikbaar is	4	2	4	De kans hierop is afhankelijk van de beschikbaarheidsafspraken tussen Zorgaanbieder en module leverancier De impact is afhankelijk van voor welke zorg de module bedoeld is. Voor dagelijkse monitoring of voor af en toe gebruik om bijvoorbeeld informatiemateriaal te lezen.	8
Rc03	Operationeel - Afhankelijkheden van leveranciers / externe partijen	Verstoring van beschikbaarheid Uitval van de PGO. Als een PGO tijdelijk niet beschikbaar is en de zorgaanbieder hier niet van op de hoogte is of geen alternatieve toegang tot de module aanbiedt, kan de patiënt geen toegang krijgen tot zorgmodules. Dit kan gevolgen hebben voor de continuïteit van zorg.	4	4 2	4		16
Rc04	Operationeel - Afhankelijkheden van leveranciers / externe partijen	Verstoring van beschikbaarheid De DVA is uitgevallen en tijdelijk niet beschikbaar.	4	2	4	De kans hierop is afhankelijk van de beschikbaarheidsafspraken tussen Zorgaanbieder en DVA-leverancier De impact is afhankelijk van het type module (zie oorzaak 2)	8
Rc05	Operationeel - Afhankelijkheden van leveranciers / externe partijen	De standaarden zijn niet goed geïmplementeerd of gemapt, waardoor de oplossing niet werkt: FHIR profiles zijn bijvoorbeeld niet goed gemapt en geïmplementeerd. Hierdoor zitten er fouten in de FHIR profiles die getoond worden in de PGO	4	2	4	De bedoeling is dat verkeerde mapping gedetecteerd wordt tijdens de kwalificatie van leveranciers. Helaas komen niet altijd alle knelpunten naar boven, omdat gewerkt wordt met testdata en de praktijkdata anders kan zijn. Bij latere wijzigingen in de bronsystemen van Zorgaanbieders kunnen soms ook knelpunten in mapping worden geintroduceerd.	8
Rc06	Operationeel - Afhankelijkheden van leveranciers / externe partijen	Een verschillende werkwijze in een PGO voor gebruik van modules, die aangeboden worden door de PGO versus modules die aangeboden worden door zorgaanbieders via de DVA levert verwarring op bij de gebruiker.	4	2	2		4
Rc07	Operationeel - Afhankelijkheden van leveranciers / externe partijen	Het is voor een gebruiker niet mogelijk om dezelfde module tegelijkertijd kunnen ‘gebruiken’ vanuit zowel de PGO als patientenportaal.	4	1	2	De betrokken Zorgaanbieders hebben aangegeven dat het mogelijk moet zijn om de module tegelijkertijd te kunnen gebruiken vanuit een portaal en PGO. Dit risico wordt meegenomen als functionele eis. De eisen voor het solution design hiervoor moeten nog uitgewerkt worden.	2
Rc08	Operationeel - Afhankelijkheden van leveranciers / externe partijen	Niet performante solution door regelmatig ophalen van taken vanuit PGO bij DVA en bij meerdere zorgaanbieders.	4	2	4	Er is in het solution design aandacht hiervoor zie 3.3 Verzamelen aanbiedertaken \| Efficiënte-synchronisatie-(ETag-en-_lastUpdated) . Daarom is de kans op 2 gezet en niet op 4.	8
Rc09	Operationeel - Afhankelijkheden van leveranciers / externe partijen	Statusupdates via module komen niet bij decentraal opgeslagen taken in het XIS. Hierdoor zijn de taakstatussen die getoond worden aan de zorgverlener of PGO-gebruiker (wanneer het XIS als bron voor taken wordt gebruikt voor de DVA) niet actueel	2	1	4	Voor dit probleem is aandacht, zie functionele eisen AMFE038, AMFE041, AMFE021, 2.2 Functionele eisen	4
Rc10	Operationeel - Stakeholdermanagement	Beperkt gebruik van modules via PGO Patiënten blijken de voorkeur te geven aan patiënten portaal of app van module	1	3	3	Als patiënten liever de module of app direct gebruiken in plaats van via de PGO, wordt de nieuwe route mogelijk weinig gebruikt.	9
Rc11	Operationeel Stakeholdermanagement	Beperkt gebruik van modules via PGO Zorgaanbieders adviseren tegen gebruik PGO	1	3 2	3	Omdat zorgaanbieders geen controle hebben over de kwaliteit van PGO’s, kunnen ze patiënten adviseren om het portaal of de app te gebruiken, waar ze wel invloed op hebben via contracten	9
Rd01	Financieel	Opschaling is mogelijk lastig, vanwege niet vergoede ontwikkelkosten bij DVA-leveranciers	4	4	4	Wanneer andere DVA-leverancier dan de deelnemende DVA aan het project, de standaard voor modules niet willen gaan implementeren, kunnen slechts een beperkt aantal zorgaanbieders modules via PGO aanbieden. Dit beperkt de schaalbaarheid van het project. Voor PGO’s is de impact kleiner, omdat alle drie de geselecteerde PGO’s deelnemen.	16
Rd02	Financieel	Opschaling is mogelijk lastig, vanwege niet vergoede ontwikkelkosten bij module-leveranciers en zorgaanbieders?	4	4	4		16
	Aanvullingen?

Risicomatrix

Grote impact (4)

(Risico = 4)

Ra01 Identiteitsverwisseling
Ra02 Onveilige modules
Rb01 Onjuist gebruik module-gegevens
Rc09 Taakstatussen die getoond worden aan de zorgverlener of PGO-gebruiker niet actueel

(Risico = 8)

Rc02 Module niet beschikbaar
Rc04 Uitval van DVA
Rc05 Onjuiste implementatie module-standaard en/of gegevensdienst
Rc08 Niet performante solution door regelmatig ophalen van taken vanuit PGO.

(Risico = 12)

(Risico = 16)

Ra05 Gebruikers-onvriendelijk (aantal keer inloggen)
Rc03 Uitval van PGO
Rd01 en Rd02 Beperkte opschaling door DVA’s en modules

Aanzienlijke impact (3)

(Risico = 3)

(Risico = 6)

(Risico = 9)

Rc10 en Rc11: Voorkeur voor gebruik portaal of app voor toegang modules door patiënten en zorgverleners, en niet PGO

(Risico = 12)

Ra06 Onduidelijke weergave van module in PGO

Beperkte impact (2)

(Risico = 2)

Rc07 niet mogelijk om dezelfde module tegelijkertijd kunnen ‘gebruiken’ vanuit zowel PGO als portaal.

(Risico = 4)

Rc06 Verschillende werkwijze in een PGO voor gebruik van ‘PGO-modules’ versus ‘Zorgaanbieder- modules’

(Risico = 6)

Rb02 Foutieve betrouwbaarheidsniveau van inloggen bij module

(Risico = 8)

Kleine impact (1)

(Risico = 1)

(Risico = 2)

(Risico = 3)

(Risico = 4)

Kleine kans (1)

Beperkte kans (2)

Aanzienlijke kans (3)

Grote kans (4)

Maatregelen

Nr	Categorie	Beschrijving	Maatregelen	Verantwoordelijke
Ra01	Strategisch - Veiligheid & betrouwbaarheid Afsprakenstelsel	Identiteitsverwisseling: De PGO-gebruiker heeft langdurige toestemming gegeven en geeft de inloggegevens van zijn PGO aan een andere persoon. Deze andere persoon logt in op de PGO van de PGO-gebruiker en start een module hoewel deze persoon hiervoor geen toestemming heeft van de PGO-gebruiker.	Net als nu voor client- en patiëntportalen gebeurt: PGO-gebruikers goed informeren dat zij hun inloggegevens niet zo maar moeten delen.
Ra02	Strategisch - Veiligheid & betrouwbaarheid Afsprakenstelsel	Onveilige modules kunnen mogelijk bij opschaling (na dit project) aangeboden worden aan PGO-gebruikers via de PGO	Te onderzoeken of maatregelen nodig zijn bij opschaling.
Ra03	Strategisch - Veiligheid & betrouwbaarheid Afsprakenstelsel	Er zitten fouten in het solution design. Hieronder kunnen er gegevens gestolen worden en misbruikt. is dit risico reëel? is het nog nodig om een security expert naar het solution design te laten kijken of niet nodig?	Technische afstemming is nodig om te bepalen hoe hiermee om te gaan. Dit wordt besproken met betrokken partijen.
Ra04	Strategisch - Veiligheid & betrouwbaarheid Afsprakenstelsel	Er zitten fouten in de implementatie van het solution design door de DVA- of PGO-, of module-leverancier. Hieronder kunnen er gegevens gestolen worden en misbruikt.	Test- en kwalificatie-proces zorgvuldig inrichten en zorgvuldig doorlopen
Ra05	Strategisch - Gebruiksvriendelijkheid Afsprakenstelsel	Gebruikersonvriendelijkheid door meerdere keren inloggen Patiënten moeten nu drie keer inloggen (PGO, zorgaanbieder, module), wat als omslachtig wordt ervaren. Dit kan leiden tot lage adoptie. De VAD (Vertrouwde Authenticatiedienst) zou dit kunnen oplossen, maar is nog niet beschikbaar.	Met de komst van de VAD zal het aantal keer inloggen afnemen. Er zijn op dit moment geen andere maatregelen mogelijk om het aantal keer inloggen te verminderen. Daarnaast zorgt de inzet van langdurige toestemming, dat de gebruiker niet hoeft in te loggen om taken te verzamelen.
Ra06	Strategisch - Gebruiksvriendelijkheid Afsprakenstelsel	De weergave van de module is slecht te lezen in de PGO. PGO-leveranciers geven aan geen garantie te kunnen geven over goede weergave, wanneer de weergave van modules niet van te voren getest wordt in de PGO	Nog verder te bepalen: Voorstel: Modules worden getest op weergave in de PGO. Wanneer de weergave goed leesbaar is, komen ze op een MedMij-lijst te staan, die PGO-leveranciers kunnen raadplegen. PGO-leveranciers kunnen een waarschuwing in de PGO tonen, bij het starten van modules die niet goed leesbaar zijn.
Rb01	Compliance /juridisch	Onjuist gebruik module-gegevens: De module, waarnaar de PGO verwijst, verzamelt gegevens van de gebruiker voor onderzoek. Zonder dat de gebruiker hiervoor om toestemming wordt gevraagd.	MedMij, DVA- en PGO-leveranciers hebben geen zeggenschap over modules en het gebruik van module-gegevens. Mocht dit voorkomen en een PGO-gebruiker, DVA- of PGO-leverancier hierover contact opnemen met MedMij, dan neemt MedMij contact op met de Zorgaanbieder die de module aanbiedt.
Rb02	Compliance / juridisch	Foutieve betrouwbaarheidsniveau van inloggen bij module: De module vraagt de gebruiker niet om opnieuw in te loggen. Hoewel in de module privacy gevoelige gegevens ingevoerd worden, die gebruikt worden voor besluitvorming over de behandeling van de gebruiker. En een extra controle van de identiteit van de gebruiker (inloggen) hiervoor eigenlijk wel noodzakelijk is.	Zie Rb01
Rc01	Operationeel - Afhankelijkheden van leveranciers / externe partijen	Identiteitsverwisseling: Er is Single Sign On ingericht zodat de PGO-gebruiker niet opnieuw hoeft in te loggen bij de module, als de PGO-gebruiker al ingelogd is in de PGO en toestemming heeft gegeven. De identiteit van de Persoon die de DVA doorgeeft aan de module (klopt dit), is echter de identiteit van een ander Persoon, kan dit?
		Zijn er andere mogelijke oorzaken van Identiteitsverwiseling die we moeten opnemen?
Rc02	Operationeel - Afhankelijkheden van leveranciers / externe partijen	Verstoring van beschikbaarheid: de module waarmee (hybride) zorg wordt geleverd, is tijdelijk niet beschikbaar. Omdat de module is uitgevallen en tijdelijk niet beschikbaar is	Juiste beschikbaarheids- afspraken van de module tussen zorgaanbieder en leverancier Wanneer de module niet beschikbaar is, wordt een foutmelding getoond in de PGO,:' De module is niet beschikbaar, neem contact op met uw Zorgaanbieder'.
Rc03	Operationeel - Afhankelijkheden van leveranciers / externe partijen	Verstoring van beschikbaarheid: uitval van de PGO. Als een PGO tijdelijk niet beschikbaar is en de zorgaanbieder hier niet van op de hoogte is of geen alternatieve toegang tot de module aanbiedt, kan de patiënt geen toegang krijgen tot zorgmodules. Dit kan gevolgen hebben voor de continuïteit van zorg.	Zorgaanbieders weten niet welk PGO hun patiënten gebruiken en of zij modules via deze PGO gebruiken. Het is daarom belangrijk dat er altijd een alternatieve toegang beschikbaar is tot de module naast de PGO PGO-gebruikers waarbij de PGO niet beschikbaar is, krijgen een mailtje van de PGO-leverancier wat ze moeten doen als ze een module via de PGO gebruiken. Er komen aanvullende beschikbaarheidsafspraken voor PGO’s die modules ondersteunen, waaraan ze moeten voldoen, om de uitval tot een minimum te beperken
Rc04	Operationeel - Afhankelijkheden van leveranciers / externe partijen	Verstoring van beschikbaarheid: De DVA is uitgevallen en tijdelijk niet beschikbaar.	Juiste beschikbaarheids- afspraken van de DVA tussen zorgaanbieder en leverancier Wanneer de DVA niet beschikbaar is, wordt een foutmelding getoond in de PGO,:' De tussenleverancier (DVA) is niet beschikbaar, neem contact op met uw Zorgaanbieder' MedMij informeert Zorgaanbieders direct wanneer de DVA niet beschikbaar is → is dit nodig, of worden Zorgaanbieders al hierover geïnformeerd door DVA-leverancier?
Rc05	Operationeel - Afhankelijkheden van leveranciers / externe partijen	De standaarden zijn niet goed geïmplementeerd of gemapt, waardoor de oplossing niet werkt: FHIR profiles zijn bijvoorbeeld niet goed gemapt en geïmplementeerd. Hierdoor zitten er fouten in de FHIR profiles die getoond worden in de PGO	DVA’s en PGO’s worden gekwalificeerd. Module-leverancier ook kwalificeren bij Koppeltaal? Navragen
Rc06	Operationeel - Afhankelijkheden van leveranciers / externe partijen	Een verschillende werkwijze in een PGO voor gebruik van modules, die aangeboden worden door de PGO versus modules die aangeboden worden door zorgaanbieders via de DVA levert verwarring op bij de gebruiker.	In de gebruikerstesten is hier aandacht voor. Indien mogelijk en nodig wordt hiervoor iets opgenomen in de toegankelijkheidsrichtlijn.	Business-analist integraal MedMij team, betrokken POP’s
Rc07	Operationeel - Afhankelijkheden van leveranciers / externe partijen	Het is voor een gebruiker niet mogelijk om dezelfde module tegelijkertijd kunnen ‘gebruiken’ vanuit zowel de PGO als patientenportaal.	De betrokken Zorgaanbieders hebben aangegeven dat het mogelijk moet zijn om de module tegelijkertijd te kunnen gebruiken vanuit een portaal en PGO. Dit risico wordt meegenomen als functionele eis
Rc08	Operationeel - Afhankelijkheden van leveranciers / externe partijen	Niet performante solution door regelmatig ophalen van taken vanuit PGO bij DVA en bij meerdere zorgaanbieders.	Er is in het solution design aandacht hiervoor zie 3.3 Verzamelen aanbiedertaken \| Efficiënte-synchronisatie-(ETag-en-_lastUpdated) . Daarom is de kans op 2 gezet en niet op 4.
Rc09	Operationeel - Afhankelijkheden van leveranciers / externe partijen	Statusupdates via module komen niet bij decentraal opgeslagen taken in het XIS. Hierdoor zijn de taakstatussen die getoond worden aan de zorgverlener of PGO-gebruiker (wanneer het XIS als bron voor taken wordt gebruikt voor de DVA) niet actueel	Voor dit probleem is aandacht, zie functionele eisen AMFE038, AMFE041, AMFE021, 2.2 Functionele eisen
Rc010	Operationeel - Stakeholdermanagement	Beperkt gebruik van modules via PGO: Patiënten blijken de voorkeur te geven aan patiëntenportaal of app van module	Het is lastig om hierop maatregelen te nemen, dit hoort bij de keuzevrijheid van de patiënten. Wel kan via algemene communicatie de voordelen van het gebruik van PGO’s bij patiënten belicht worden. En kan onderzocht worden, wanneer dit voorkomt, of er barrières zijn die opgelost kunnen worden.
Rc011	Operationeel Stakeholdermanagement	Beperkt gebruik van modules via PGO: Zorgaanbieders en zorgverleners adviseren tegen gebruik PGO	Zie Rc06
Rd01	Financieel	Opschaling is mogelijk lastig, vanwege niet vergoede ontwikkelkosten bij DVA-leveranciers	Ontwikkelinspanning beperken door goede documentatie en herbruikbare code. Daarnaast onderzoeken of er mogelijkheden voor financiering zijn om bredere implementatie mogelijk te maken.
Rd02	Financieel	Opschaling is mogelijk lastig, vanwege niet vergoede ontwikkelkosten bij module-leveranciers	Zie Rd01
	Aanvullingen?