...

1.2    Beslis- en discussiepunten

1. Mitz moet aansluiten op TVS, om zo ook gebruik te kunnen maken van de Vertegenwoordigingsregistersen 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.

...

Buiten Mitz en MedMij moet ook Logius betrokken worden, omdat het gebruik TVS/DigiD vermindert. Daarnaast is er sprake van het gebruik van BSNk in de toekomst, dit voor Vertrouwde authenticatiehet onderwerp ‘Vertrouwde authenticatie’.

2.     Toekomstige situatie

2.1    Scope/Afbakening, omgevingsmodel en belangrijkste kaders

In deze alinea wordt beschreven wat wel en niet binnen de scope van het probleem en de oplossing valt: wat wordt wel aangepakt en wat niet. Denk hierbij aan keten, organisatie, programma, project, voorziening.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

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

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

• 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

...