...

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.

...

• 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

1. Mitz en MedMij sluiten op elkaar aan, zodat de toestemmingen voor gegevensuitwisseling tussen Aanbieders en een PGO centraal worden opgeslagen.

2. Dienstverleners aanbieder slaan zelf geen toestemmingen meer op, maar kunnen gebruikmaken van de toestemmingen die in Mitz zijn opgeslagen.

3. De Persoon kan in Mitz de toestemmingen beheren. Dit betekent toestemming geven, toestemming beheren, toestemming intrekken.

4. De Persoon geeft in één keer toestemming aan alle Aanbieders om zijn/haar gegevens uit te wisselen met een bepaalde PGO.

   1. 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.

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

...

1. 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

1. We gaan bij de uitwerkingen uit van het ontbreken van Vertrouwde authenticatie.

2. 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.

...

Buiten Mitz en MedMij moet ook Logius betrokken worden, omdat het gebruik van TVS /DigiD 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.

Binnen Scope:

MedMij

...

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.Aanpassing van de functie Toestemmingen beheren als primaire functie binnen het afsprakenstelsel. Dienstverlener aanbieder vervangen door Dienstverlener toestemmingen

  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

  .
  

• Interfaces aanpassen volgens de gedachte dat toestemmingen bij Mitz belegd worden. Dit betekent minimaal dat:

  • de Dienstverlener aanbieder geen Authorization interface meer aanbiedt;

...

2.2    Doelgroepen: Stakeholders

In deze alinea worden de stakeholders benoemd, met beschrijving van rol en soort betrokkenheid (actief, adviserend, beslissend, etc.) die een belang hebben bij de realisatie van de oplossing. Indien mogelijk wordt verwezen naar waar in deze PSA dit belang wordt geadresseerd. Ook worden de eisen en wensen benoemd ten aanzien van de te realiseren oplossing en zijn componenten. Denk daarbij ook aan leveranciers, gebruikers en afnemers.

2.3    Oplossingsrichting

...

• 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

1. Stichting MedMij, in de rol van Eigenaar

2. MedMij deelnemers, in de rol van Dienstverlener persoon of Dienstverlener aanbieder

3. VWS, in de rol van Dienstverlener authenticatie en wellicht Dienstverlener toestemmingen

4. MedMij beheer, In de rol van beheerder R&A

5. Acceptatie

6. Regie

7. Leveranciersmanagement

8. 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)

...