Samenvatting
| Waarom is deze RFC nodig? | Het MedMij Afsprakenstelsel past een scheiding toe tussen enerzijds de rollen en functionaliteit waarmee de Persoon *afspraken* maakt met een Zorgaanbieder over de uitwisseling van gezondheidsinformatie en anderzijds de *uitvoering* van die afspraken door middel van het uitwisselen van die gezondheidsinformatie. Met deze scheiding zorgt MedMij ervoor dat de Persoon altijd helder kan hebben wanneer hij afspraken aan het maken is (bijvoorbeeld: toestemming geeft of een abonnement aangaat) en ook altijd overzicht kan hebben over welke afspraken hij gemaakt heeft, met wie, en wat de status daarvan is. Zo kan de Persoon goed regie voeren. Deze scheiding is wel op meerdere plaatsen aanwezig in het MedMij Afsprakenstelsel (in de fasering van UC(I) Verzamelen en Delen, en in de beschikbaarheids-/ontvankelijkheidsvoorwaarde), maar niet op één plaats gedefinieerd, noch expliciet zichtbaar in de rest van het MedMij Afsprakenstelsel. Nu abonneren en notificeren ook opgenomen gaat worden in het MedMij Afsprakenstelsel, gaat dit knellen en dreigt deze scheiding onscherp te worden. Deze RFC stelt voor hoe deze scheiding expliciet wordt gemaakt in het MedMij Afsprakenstelsel en gaat dienen als uitgangspunt voor allerlei ontwerpkeuzes, waaronder voor RFC0005. Op de niveaus Processen en Informatie en Applicatie er naast regie en uitwisseling is er nog een derde soort functionaliteit: coördinatie (beheer, publicatie en ophalen van lijsten). Deze RFC geeft met name ook invulling aan principes P1 en P16. |
|---|---|
| Oplossingsrichting |
|
| Aanpassing van |
|
| Impact op rollen | Zie bij oplossingsrichting. |
| Impact op beheer | geen |
| Gerelateerd aan (Jira issues) | veel |
| Eigenaar | Paul Oude Luttighuis |
| Implementatietermijn | Release 1.2.0 |
| Motivatie verkorte RFC procedure (patch) | n.v.t. |
Goedkeuring
| Beoordelaar | Datum | Toelichting | Beoordelaar | Datum | Toelichting |
|---|---|---|---|---|---|
| Productmanager Stichting MedMij | Productmanager Beheerorganisatie | ||||
| Leadarchitect Stichting MedMij | Leadarchitect Beheerorganisatie | ||||
| Ontwerpteam | |||||
| Deelnemersraad | Eigenaarsraad |
Principe's
| Principe | Principe | ||
|---|---|---|---|
1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal | Positief | 11 Stelselfuncties worden vanaf de start ingevuld | Neutraal |
| 2 Dienstverleners zijn transparant over de gegevensdiensten | Neutraal | 12 Het afsprakenstelsel is een groeimodel | Positief |
| 3 Dienstverleners concurreren op de functionaliteiten | Neutraal | 13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders | Neutraal |
| 4 Dienstverleners zijn aanspreekbaar door de gebruiker | Neutraal | 14 Uitwisseling is een keuze | Positief |
| 5 De persoon wisselt gegevens uit met de zorgaanbieder | Positief | 15 Het MedMij-netwerk is gebruiksrechten-neutraal | Positief |
| 6 MedMij spreekt alleen af wat nodig is | Neutraal | 16 De burger regisseert zijn gezondheidsinformatie als uitgever | Positief |
| 7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener | Neutraal | 17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld | Neutraal |
| 9 De dienstverleners zijn deelnemers van het afsprakenstelsel | Neutraal | 18 Afspraken worden aantoonbaar nageleefd en gehandhaafd | Neutraal |
| 10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling | Positief | 19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat | Neutraal |
Uitwerking
Nieuwe pagina maken, onder Architectuur en technische specificaties, met de titel: Coördinatie, Regie en Uitwisseling. Deze vervangt het blok "Regie en uitwisseling" op Architectuur en technische specificaties.
===
Het MedMij Afsprakenstelsel onderkent, op de Processen-en-Informatie-laag en op de Applicatie-laag, drie hoofdfuncties: Regie, Uitwisseling en Coördinatie. Al het gedrag van de betrokken rollen op deze lagen hoort bij één van deze drie hoofdfuncties.
Centraal staat de Regie; hiermee voert de Persoon regie, in interactie met de Zorgaanbieder, over de (uitwisseling van) zijn gezondheidsinformatie. Dat doet hij als uitgever, conform principe 16. Onder deze hoofdfunctie vallen bijvoorbeeld het geven van toestemming van de Persoon aan de Zorgaanbieder, het authenticeren van de Persoon door de Zorgaanbieder, het autoriseren van de PGO door de Zorgaanbieder en het aangaan, beëindigen en onderhouden van abonnementen. Regie leidt steeds tot overeenkomsten tussen Persoon, Zorgaanbieder en Dienstverlener Persoon, en zijn gebaseerd op onderlinge zekerheid over elkaars identiteit. De Dienstverlener Zorgaanbieder is niet betrokken in deze overeenkomsten, omdat deze verwerker is, geen verwerkingsverantwoordelijke zoals wel de Dienstverlener Persoon.
Regie stuurt Uitwisseling. Uitwisseling geeft uitvoering aan de Regie. Deze tweede hoofdfunctie voert het feitelijke verkeer van gezondheidsinformatie uit, van Zorgaanbieder naar PGO (Verzamelen) of andersom (Delen). Alle uitwisseling vindt plaats conform gestandaardiseerde Gegevensdiensten en in het kader van een Regie-overeenkomst.
Regie en Uitwisseling worden, conform principe 10, alleen uitgevoerd door partijen die onder de volledige verantwoordelijkheid vallen van een Dienstverlener Persoon of Dienstverlener Zorgaanbieder. MedMij kent een decentrale uitvoering. MedMij is zelf niet betrokken in de uitvoering van Regie of Uitwisseling. Toch is een rol van MedMij nodig in het tot stand brengen van vertrouwen tussen de Dienstverleners Persoon enerzijds en de Dienstverleners Zorgaanbieder anderzijds, zodat zij van elkaar kunnen weten wat zij kunnen en mogen. Daarvoor is de derde hoofdfunctie: Coördinatie, die wordt uitgevoerd met een Catalogus, die zegt welke Gegevensdiensten op enig moment op het MedMij-netwerk van kracht zijn, en vier lijsten (Gegevensdienstnamenlijst, OAuthclientlist, Whitelist en Zorgaanbiederslijst), die zeggen wat de Deelnemers kunnen en mogen.
===
Risico's
Omschrijf de (privacy)risico's die kunnen ontstaan als deze RFC wordt aangenomen. In het onwaarschijnlijke geval dat deze RFC's geen risico's introduceert, geef dat dan wel aan.
| Dreiging | Kans | Impact | Maatregelen |
|---|---|---|---|
| geen | 100% | 0 | geen |
Bijlagen