RFC0039 Toestemming voor meerdere diensten van één aanbieder
Samenvatting
Waarom is deze RFC nodig? | Met deze RFC wordt de gebruiksvriendelijkheid van de MedMij UC Verzamelen voor Personen vergroot. Deze RFC vormt één van de stappen in het vergroten van de gebruiksvriendelijkheid. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Input van deelnemers |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Oplossingsrichting | Requirements:
Voor deze RFC zijn een aantal oplossingsrichtingen overwogen:
Oplossingsrichting 3 is naar voren gekomen als de gewenste richting en wordt hier verder uitgewerkt. Oplossingsrichting 3 - Toestemming voor alle persoons- en gezondheidsgegevens van zorgaanbieder Deze oplossingsrichting maakt een grofmazige toestemming mogelijk. Om een interactie te mogen initieren is een access_token vereist die recht geeft op het gebruik van een Gegevensdienst. Een access_token wordt pas uitgegeven:
Nadere uitwerking:
Bovenstaande flow is hier grafisch uitgebeeld. De weergavenamen van de huidige gegevensdiensten zijn ter info opgenomen in onderstaande tabel.
Gebruik van de ZAL Een DVP mag meerdere gegevensdiensten van een aanbieder combineren in één Authorization Request wanneer (zie ook onderstaande voorbeeld):
Voorbeeld van de ZAL:
Gegevensdiensten 4 en 5, zoals aangeboden door umcharderwijk@medmij mogen in bovenstaand voorbeeld met elkaar worden gecombineerd in één AuthorizationRequest. Voor gegevensdienst 6 zal een afzonderlijk AuthorizationRequest moeten worden verstuurd. Managementinformatie Met het geven van toestemming over meerdere diensten van één aanbieder moet ook rekening worden gehouden bij het vastleggen van Managementinformatie. Voor het registreren van de Managementinformatie betekent dit dat:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Aanpassing van | Authorization flow, toestemmingsverklaring, UC(I) Verzamelen | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Impact op rollen | DVP (optionele functionaliteit), DVA (verplichte functionaliteit). Ook op wijze van telling requests t.b.v. managementinformatie. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Impact op beheer | Nee | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Impact op RnA | Nee | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Impact op Acceptatie | Ja, vereist aanpassingen in acceptatiescripts en testtooling. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Gerelateerd aan (Andere RFCs, PIM issues) | AF-1127 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Eigenaar | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Implementatietermijn | 1.5.0 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Motivatie verkorte RFC procedure (patch) |
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 | Positief |
2 Dienstverleners zijn transparant over de (gegevens)diensten | Positief | 12 Het afsprakenstelsel is een groeimodel | Positief |
3 Dienstverleners concurreren op de functionaliteiten | Positief | 13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders | Positief |
4 Dienstverleners zijn aanspreekbaar door de gebruiker | Positief |