Project Start Architectuur Dienstverlener toestemmingen (PSA)
Als Persoon geef ik toestemming dat alle Aanbieders gegevens die zij over mij hebben mogen delen met PGO’s die ik gebruik.
Opdracht, resultaat en beoogd effect
Toestemmingen worden bij de Dienstverlener aanbieder opgeslagen (op moment van schrijven geldt versie 2.1.0 van het afsprakenstelsel als optionele versie). Hoewel er al gebruikgemaakt kan worden van langdurige toestemmingen, moet een Persoon nog steeds minimaal één keer per Aanbieder toestemming geven. Hierbij moet elke keer met TVS/DigiD worden ingelogd. Als een de systemen van een Aanbieder worden ontsloten door meerdere Dienstverleners aanbieder, moet de Persoon voor deze Aanbieder ook meerdere toestemmingen geven. Natuurlijk heeft langdurige toestemming de situatie al enorm verbeterd, maar het is nog verre van ideaal.
Door een Dienstverlener toestemmingen als rol aan het afsprakenstelsel toe te voegen, zorgen we ervoor dat toestemmingen centraler vastgelegd kunnen worden. Per aangesloten domein moet bepaald worden aangesloten kan worden op een bestaande Dienstverlener toestemmingen, of dat er een eigen implementatie moet zijn.
Voor Aanbieder-Aanbieder-gegevensuitwisseling is Mitz aangewezen als gemeenschappelijke voorzieningen. Op 30 november 2020 door het Informatieberaad en ook de politiek bekrachtigt deze keuze, bijvoorbeeld in de kamerbrief van 12 december 2023.
Voor MedMij betekent dit dat we Mitz gebruiken als Dienstverlener toestemmingen, in ieder geval voor het zorgdomein. Dit heeft de volgende voordelen:
Toestemmingen voor de uitwisseling van zorggegevens worden op één plek opgeslagen. Hiermee gaat de gebruiksvriendelijkheid omhoog, omdat de Persoon altijd dezelfde applicatie gebruikt voor het geven en beheren van toestemmingen;
Toestemmingen kunnen generiek worden gegeven. Als Persoon geef je in één keer toestemming aan alle Aanbieders waarmee jij een zorgrelatie hebt, om gegevens uit te wisselen met een bepaalde Dienstverlener persoon (oftewel en bepaalde Persoonlijke gezondheidsomgeving). Dit zorgt ervoor dat uitwisseling met deze PGO direct mogelijk is voor alle Aanbieders waarmee de Persoon een zorgrelatie heeft.
Implementatie bij de Dienstverleners aanbieder wordt versimpeld, doordat zij zelf geen schermen meer hoeven te tonen. In de huidige situatie tonen Dienstverleners aanbieder schermen in het autorisatieproces. In het nieuwe proces worden deze schermen overgenomen door de Dienstverlener toestemmingen. De communicatie tussen Dienstverleners persoon en Dienstverleners aanbieder is alleen nog op het backchannel niveau.
Naast deze directe voordelen is ook van belang dat:
de Persoon minder vaak te maken krijgt met TVS/DigiD. De verwachting is dat hierdoor de huidig gemeten uitval van 40% teruggebracht wordt. De communicatie tussen Dienstverlener persoon en Dienstverlener aanbieder gaat minder vaak fout, doordat het autorisatieproces uitgekleed wordt. Alleen de token-interface en resource-interface zijn hierbij nog van belang. Wel moeten beide partijen schakelen met de Dienstverlener toestemmingen.
Opdrachtgever en opdrachtnemer
De opdrachtgever van dit onderwerp zijn Jeroen Bos (Product Manager MedMij) en Casper van der Harst (Lead Architect MedMij). De opdracht zal uitgevoerd worden door Team Ontwikkeling afsprakenstelsel voor het MedMij deel en door het team van Mitz voor hun deel. Dit gaat in samenwerking met Team Acceptatie en ketenregie, beiden onderdeel van MedMij Beheer.
Beslis- en discussiepunten
Mitz en MedMij sluiten op elkaar aan, zodat de toestemmingen voor gegevensuitwisseling tussen Aanbieders en een PGO centraal worden opgeslagen.
Dienstverleners aanbieder slaan zelf geen toestemmingen meer op, maar kunnen gebruikmaken van de toestemmingen die in Mitz zijn opgeslagen.
De Persoon kan in Mitz de toestemmingen beheren. Dit betekent toestemming geven, toestemming beheren, toestemming intrekken.
De Persoon geeft in één keer toestemming aan alle Aanbieders om zijn/haar gegevens uit te wisselen met een bepaalde PGO.
Om de juiste PGO te hebben in Mitz, moet d Persoon bij deze PGO vandaan komen, of er moet een mogelijkheid in Mitz komen om te kiezen voor een MedMij PGO.
In de plaatjes voor de generieke inzagefunctie, etc spraken we over een Dienstverlener toestemmingen en een toestemmingenaanbieder. Is deze splitsing handig en nodig?
Gemaakt keuzes
We gaan bij de uitwerkingen uit van het ontbreken van Vertrouwde authenticatie.
De gebruiker moet bij Mitz voor iedere nieuwe sessie inloggen. Voor de betrouwbaarheid van het stelsel is het noodzakelijk dat de identiteit niet buiten sessies wordt onthouden.
1.3Â Â Â Aanpak, werkwijze
Gedurende de maand januari wordt dit document opgesteld. In februari willen we hiervoor goedkeuring krijgen, zodat de teams zo snel mogelijk aan de slag kunnen.
1.3.1Â Betrokken bij totstandkoming
Hier staat aangegeven wie vanuit zijn of haar functie heeft meegewerkt aan totstandkoming van de PSA.
Persoon | Functie | Soort bijdrage |
Casper van der Harst | Lead architect MedMij | Schrijver |
Albert Vlug | Lead architect Mitz | Schrijver |
Jeroen Bos | Product manager MedMij | Reviewer |
Martijn Mallie | Product manager Mitz | Reviewer |
1.3.2Â Relaties met andere projecten
Buiten Mitz en MedMij moet ook Logius betrokken worden, omdat het gebruik van TVS vermindert. Daarnaast is er sprake van het gebruik van BSNk in de toekomst, dit voor het onderwerp ‘Vertrouwde authenticatie’.
Toekomstige situatie
Scope/Afbakening, omgevingsmodel en belangrijkste kaders
Mitz en MedMij sluiten op elkaar aan om voor elkaar van functionele waarde te zijn. De MedMij-toestemmingen, toestemmingen waarmee de gegevensuitwisseling tussen Aanbieders en een PGO worden vastgelegd, worden in Mitz opgeslagen. Dienstverleners aanbieders zijn niet meer verantwoordelijk voor de opslag van de toestemmingen.
In scope
Aanpassing van de functie Toestemmingen beheren als primaire functie binnen het afsprakenstelsel. Dienstverlener aanbieder vervangen door Dienstverlener toestemmingen.
Toestemming geven
Toestemmingen beheren
Toestemmingen intrekken
Toestemmingen inzien (vanuit de PGO)
Toestemmingen controleren (bij gebruik van bijvoorbeeld een DVA)
Toestemmingen moeten gegeven worden volgens de principes/eisen van de AVG beschreven staan, te weten: vrijelijk gegeven, ondubbelzinnig, geïnformeerd, specifiek. De Persoon geeft zelf (authenticatie) zonder dwang (vrijelijk gegeven) toestemming voor de uitwisseling van gegevens tussen Aanbieders en een specifiek PGO (ondubbelzinnig en specifiek), waarbij PGO en Mitz vooraf de Persoon goed informeren over de betekenis hiervan.
Beschrijving van de rol Dienstverlener toestemmingen, inclusief bijbehorende verantwoordelijkheden. Een uitbreiding van het rollen model is hiervoor noodzakelijk en tevens toevoegen van verantwoordelijkheden in de MedMij Core.
Beschrijving van een Toestemmingenregister dat door de Dienstverlener toestemmingen in het stelsel geboden wordt, inclusief bijbehorende verantwoordelijkheden. Een uitbreiding van het rollen model is hiervoor noodzakelijk en tevens toevoegen van verantwoordelijkheden in de MedMij Core.
Aanpassingen van de functie Autorisatie.
Authorization interface van de Dienstverlener aanbieder wordt verwijderd. Dienstverlener aanbieder hoeft hier niet meer in te voorzien. Hiermee vervallen ook de koppelingen tussen Dienstverlener persoon en Dienstverlener aanbieder en tussen Dienstverlener aanbieder en Dienstverlener authenticatie.
Token interface van de Dienstverlener aanbieder moet bij de Dienstverlener toestemmingen opvragen of er toestemming is en voor welk BSN.
Onderzoek of de koppeling tussen Dienstverlener toestemmingen en Dienstverlener authenticatie, en hiermee de gehele rol van Dienstverlener authenticatie, beschreven moet blijven. Mogelijk dat alleen eisen aan het gebruik van BSN en vertegenwoordiging voldoende is.
Out of scope
Vertrouwde authenticatie: omdat het onzeker is wanneer vertrouwde authenticatie gebruikt kan worden, is bij deze uitwerking uitgegaan van het niet hebben van vertrouwde authenticatie. Hierdoor krijgt de Dienstverlener toestemmingen geen identiteit van de PGO en moet deze zelf vaststellen.
Het kunnen beheren van toestemmingen vanuit de PGO. Voor de betrouwbaarheid van toestemmingen moet men ervan kunnen uitgaan dat de toestemming door de Persoon is gegevens, volgens de principes/eisen die in de AVG beschreven staan.
Vrijelijk gegeven
Ondubbelzinnig
Geïnformeerd
Specifiek
Lokalisatie: Toestemming is nodig voor de uitwisseling van gegevens, inclusief locatiegegevens. Locatiegegevens zullen ook door Mitz geleverd worden, maar vallen buiten de scope van dit onderwerp. De gegevens toestemming moet wel zo verwoord zijn dat ook locatiegegevens uitgewisseld mogen worden.
Doelgroepen: Stakeholders
Stichting MedMij, in de rol van Eigenaar
MedMij deelnemers, in de rol van Dienstverlener persoon of Dienstverlener aanbieder
VWS, in de rol van Dienstverlener authenticatie en wellicht Dienstverlener toestemmingen
MedMij beheer, In de rol van beheerder R&A
Acceptatie
Regie
Leveranciersmanagement
Directie VZVZ
Oplossingsrichting
Toestemmingen voor de uitwisseling tussen het zorgdomein (Aanbieder en daarmee Dienstverlener aanbieder) en het persoonsdomein (PGO en daarmee Dienstverlener persoon) worden vastgelegd in een toestemmingenregister. Een toestemmingenregister wordt per domein beschreven en gekozen. In het zorgdomein is door het ministerie van VWS gekozen Mitz te gebruik als toestemmingenregister. De Persoon kan bij Mitz de toestemmingen beheren, nadat de Persoon is geauthenticeerd. Dit betekent dat de Persoon toestemming kan geven, beheren en intrekken.
Zonder vertrouwde authenticatie
Als geen gebruikgemaakt kan worden van vertrouwde authenticatie, is de wens nog steeds dat de toestemming gebruikt kan worden zonder bij de aanbieder in te loggen. Hiervoor geeft Mitz een bewijs van de toestemming door aan een PGO.
2.4Â Â Â Relevante ontwikkelingen (gedurende realisatie en implementatie)
De ontwikkelingen waarmee gedurende de realisatie en implementatie van de oplossing rekening gehouden dient te worden en de reden daarvoor worden benoemd. Ook wordt kort het verdere verloop van het architectuurproces tijdens de uitvoering van het project beschreven.
3.    Kader
In dit hoofdstuk wordt aangegeven welke (architectuur-)kaders zijn toegepast. Dit sjabloon is samengesteld op basis van PSA's uit verschillende organisaties en geeft als het ware een 'grootste gemene deler' weer. Dat betekent dat iedere organisatie vrij is in de wijze waarop ze de PSA inricht/de inhoud ordent. Naast dit NORA-sjabloon zijn op de pagina over het PSA-sjabloon ook voorbeelden te vinden van uitgewerkte PSA's en PSA-sjablonen uit de praktijk van verschillende organisaties, die tot uitdrukking brengen dat de inrichting/ordening heel verschillend kan zijn.
3.1Â Â Â Toe te passen wet- en regelgeving
In deze alinea staat een schets van relevante wet- en regelgeving (zie onder andere http://wetten.overheid.nl/zoeken ).
Â
Wets/beleidsdocument | Impact |
Wet Bescherming Persoonsgegevens (WBP) | Â |
... | Â |
3.2Â Â Â Toe te passen standaarden
Hier wordt onderbouwd met welke standaarden rekening wordt gehouden. Hiervoor kan gebruik gemaakt worden van de pas-toe-of-leg-uit lijst van het College Standaardisatie, sector-/keten-/organisatie-specifieke lijsten van verplichte standaarden, en overzichten van standaarden die voor dit project nuttig zijn.
Indien van toepassing wordt ook aangegeven waar wordt afgeweken van de standaarden, de reden hiervoor en de maatregelen om negatieve consequenties te voorkomen. Deze verklaring kan worden gebruikt in de jaarrapportage voor compliancy aan open standaarden.
Zie voor een actuele lijst van de pas-toe-of-leg-uit standaarden: http://noraonline.nl/wiki/PSA_%28Project_Startarchitectuur%29/Sjabloon_standaarden
Â
Standaard | Impact |
Webrichtlijnen | Â |
... | Â |
Â
3.3Â Â Â Toe te passen Referentiearchitecturen: NORA en dochters
De oplossing moet voldoen aan de NORA. In deze alinea staat beschreven hoe wordt voldaan aan de basisprincipes van NORA (Zie http://noraonline.nl/wiki/Basisprincipes ).
Â
Basisprincipe NORA | Impact |
BP01: Proactief (Afnemers krijgen de dienstverlening waar ze behoefte aan hebben.) | Â |
BP02: Vindbaar (Afnemers kunnen de dienst eenvoudig vinden.) | Â |
BP03:Toegankelijk (Afnemers hebben eenvoudig toegang tot de dienst.) | Â |
BP04: Standaard (Afnemers ervaren uniformiteit in de dienstverlening door het gebruik van standaardoplossingen.) | Â |
BP05: Gebundeld (Afnemers krijgen gerelateerde diensten gebundeld aangeboden.) | Â |
BP06: Transparant (Afnemers hebben inzage in voor hen relevante informatie.) | Â |
BP07: Noodzakelijk (Afnemers worden niet geconfronteerd met overbodige vragen.) | Â |
BP08: Vertrouwelijk (Afnemers kunnen erop vertrouwen dat informatie niet wordt misbruikt.) | Â |
BP09: Betrouwbaar (Afnemers kunnen erop vertrouwen dat de dienstverlener zich aan afspraken houdt.) | Â |
BP10: Ontvankelijk (Afnemers kunnen input leveren over de dienstverlening.) | Â |
Â
In de bijlage staat beschreven hoe aan de geldende afgeleide principes invulling wordt gegeven in deze PSA. Door het realiseren van deze afgeleide principes, worden de strategische doelen voor burger, bedrijf en overheid gerealiseerd die staan beschreven in de basisprincipes van NORA.
Afhankelijk van de oplossing en de omgeving moet de oplossing ook voldoen aan de dochters van NORA (Zie http://noraonline.nl/wiki/NORA_dochters ). In de bijlage wordt in dat geval beschreven wat de impact van de principes uit de betreffende architecturen is op de oplossing, of anders gezegd: hoe wordt omgegaan met de principes.
3.4Â Â Â Toe te passen Domein- en Ketenarchitecturen
Naast NORA en de NORA-dochters dient deze architectuur eveneens rekening te houden met domein- en ketenarchitecturen en (afhankelijk van de oplossing en de omgeving) andere architecturen. In deze alinea wordt beschreven wat de impact van de principes uit de betreffende architecturen is op de oplossing, of anders gezegd: hoe wordt omgegaan met de principes.Â
3.5Â Â Â Relatie met Visie op Dienstverlening
Hier wordt beschreven hoe in het project invulling wordt gegeven aan de Visie op Dienstverlening (zie http://e-overheid.nl/images/stories/over_het_NUP/overheidsbrede_visie_op_dienstverlening2011.pdf).
3.6Â Â Â Overige kaders
In deze alinea wordt beschreven welke andere kaders dan de eerder genoemde zijn gehanteerd en wat de impact daarvan is op de oplossing. Denk daarbij aan beleidsuitspraken die zijn gedaan, uitgangspunten, richtlijnen en principes die zijn geformuleerd, visies die bijvoorbeeld zijn geuit in beleidsdocumenten, visiestukken, strategische notities en doelarchitecturen.
4.    Referenties
NORA:
Â
5.    Terminologie
NORA | Nederlandse Overheid ReferentieArchitectuur |
... | Â |
Â
6.    Appendix
6.1Â Â Â A. Principes
6.2Â Â Â A.1 Afgeleide principes uit NORA
De afgeleide principes uit NORA worden op de volgende wijze gerealiseerd in deze architectuur.
Â
NORA afgeleid principe | ID | Stelling | Toepassing in project |
Diensten zijn herbruikbaar | AP01 | De dienst is zodanig opgezet, dat andere organisaties deze in eigen diensten kunnen hergebruiken | Â |
Ontkoppelen met diensten | AP02 | De stappen uit het dienstverleningsproces zijn ontsloten als dienst. | Â |
Diensten vullen elkaar aan | AP03 | De dienst vult andere diensten aan en overlapt deze niet | Â |
Positioneer de dienst | AP04 | De dienst is helder gepositioneerd in het dienstenaanbod. | Â |
Nauwkeurige dienstbeschrijving | AP05 | De dienst is nauwkeurig beschreven. | Â |
Gebruik standaard oplossingen | AP06 | De dienst maakt gebruik van standaard oplossingen | Â |
Gebruik de landelijke bouwstenen | AP07 | De dienst maakt gebruik van de landelijke bouwstenen e-overheid | Â |
Gebruik open standaarden | AP08 | De dienst maakt gebruik van open standaarden | Â |
Voorkeurskanaal internet | AP09 | De dienst kan via internet worden aangevraagd | Â |
Aanvullend kanaal | AP10 | De dienst kan, behalve via internet, via minimaal één ander kanaal voor persoonlijk contact worden aangevraagd. |  |
Gelijkwaardig resultaat ongeacht kanaal | AP11 | Het resultaat van de dienst is gelijkwaardig, ongeacht het kanaal waarlangs de dienst wordt aangevraagd of geleverd. | Â |
Eenmalige uitvraag | AP12 | Afnemers wordt niet naar reeds bekende informatie gevraagd | Â |
Bronregistraties zijn leidend | AP13 | Alle gebruikte informatieobjecten zijn afkomstig uit een bronregistratie. | Â |
Terugmelden aan bronhouder | AP14 | Bij gerede twijfel aan de juistheid van informatie, meldt de dienstverlener dit aan de verantwoordelijke bronhouder | Â |
Doelbinding (AP) | AP15 | Het doel waarvoor informatie wordt (her)gebruikt is verenigbaar met het doel waarvoor deze oorspronkelijk is verzameld. | Â |
Informatie-objecten systematisch beschreven | AP17 | De aan de dienst gerelateerde informatieobjecten zijn systematisch beschreven en op passende wijze gemodelleerd. | Â |
Ruimtelijke informatie via locatie | AP18 | De dienst ontsluit ruimtelijke informatie locatiegewijs. | Â |
Perspectief gebruiker | AP19 | De gebruiker staat aantoonbaar centraal gedurende het (door-)ontwikkelen van diensten en ondersteunende systemen. | Â |
Persoonlijke benadering | AP20 | De dienst benadert geïdentificeerde afnemers op persoonlijke wijze. |  |
Bundeling van diensten | AP21 | De dienst wordt gebundeld met verwante diensten zodat deze samen met één aanvraag afgenomen kunnen worden. |  |
No wrong door | AP22 | Overheidsloketten verwijzen gericht door naar de dienst | Â |
Automatische dienstverlening | AP23 | De dienst wordt na bepaalde signalen automatisch geleverd. | Â |
Proactief aanbieden | AP24 | De dienst ondersteunt proactiviteit van dienstverleners binnen en buiten de organisatie | Â |
Transparante dienstverlening | AP25 | Afnemers worden geïnformeerd over de stand van zaken bij de gevraagde dienst. |  |
Afnemer heeft inzage | AP26 | De afnemer heeft inzage in de eigen informatie en het gebruik er van | Â |
Een verantwoordelijke organisatie | AP27 | Eén organisatie is verantwoordelijk voor de dienst |  |
Afspraken vastgelegd | AP28 | Dienstverlener en afnemer hebben afspraken vastgelegd over de levering van de dienst | Â |
De dienstverlener voldoet aan de norm | AP29 | De dienstverlener draagt zelf de consequenties wanneer de dienst afwijkt van afspraken en standaarden. | Â |
Verantwoording dienstlevering mogelijk | AP30 | De wijze waarop een dienst geleverd is, kan worden verantwoord | Â |
PDCA-cyclus in besturing kwaliteit | AP31 | De kwaliteit van de dienst wordt bestuurd op basis van cyclische terugkoppeling. | Â |
Sturing kwaliteit op het hoogste niveau | AP32 | Sturing op de kwaliteit van de dienst is verankerd op het hoogste niveau van de organisatie | Â |
Baseline kwaliteit diensten | AP33 | De dienst voldoet aan de baseline kwaliteit. | Â |
Verantwoording besturing kwaliteit | AP34 | De dienstverlener legt verantwoording af over de mate van control, in overleg met de afnemer. | Â |
Onweerlegbaar | AP40 | De onweerlegbaarheid van berichtenuitwisseling wordt gegarandeerd door wederzijdse authenticatie en door versleuteling van elektronische handtekeningen. | Â |
Beschikbaarheid | AP41 | De beschikbaarheid van de dienst voldoet aan de met de afnemer gemaakte continuïteitsafspraken. |  |
Integriteit | AP42 | De dienstverlener waarborgt de integriteit van gegevens en systeemfuncties. | Â |
Vertrouwelijkheid | AP43 | De dienstverlener verschaft alleen geautoriseerde afnemers toegang tot vertrouwelijke gegevens. | Â |
Controleerbaarheid | AP44 | De dienstverlener zorgt ervoor dat de beoogde toegang tot gegevens en de juiste werking van zijn systemen continu alsook achteraf te controleren is. | Â |
Â
De NORA afgeleide principes met implicaties zijn ook te vinden op: Http://www.noraonline.nl/wiki/PSA_(Project_Startarchitectuur)/Sjabloon_principes
6.3Â Â Â A.2 Afgeleide principes uit <referentie-architectuur>
Â
Â