Samenvatting

Waarom is deze RFC nodig?	In de ZAL worden in resource endpoints soms in plaats van de base URL van de FHIR-server ook ook de naam van een resources opgegeven. Het AS (b)lijkt daar nog niet voldoende stellig voor te schrijven dat dit alleen de base URL moet zijn. Deze eis komt voor uit het bewaken van de grens tussen het endpoint-adres enerzijds en de Gegevensdienst-specifieke pats-uitbreiding anderzijds.
Oplossingsrichting	Duidelijker aangeven dat alleen de base URL mag worden gebruikt in een endpoint.
Aanpassing van	Afsprakenstelsel
Impact op rollen	DVP, DVZA
Impact op beheer	NvT
Gerelateerd aan (Jira issues)
Eigenaar
Implementatietermijn	1.2.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	Neutraal
2 Dienstverleners zijn transparant over de gegevensdiensten	Positief	12 Het afsprakenstelsel is een groeimodel	Neutraal
3 Dienstverleners concurreren op de functionaliteiten	NvT	13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders	Neutraal
4 Dienstverleners zijn aanspreekbaar door de gebruiker	NvT	14 Uitwisseling is een keuze	Neutraal
5 De persoon wisselt gegevens uit met de zorgaanbieder	Neutraal	15 Het MedMij-netwerk is gebruiksrechten-neutraal	Neutraal
6 MedMij spreekt alleen af wat nodig is	Neutraal	16 De burger regisseert zijn gezondheidsinformatie als uitgever	Neutraal
7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener	Neutraal	17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld	NvT
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	Neutraal	19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat	Neutraal

Uitwerking

Op pagina Applicatie toevoegen/aanpassen:

10d. Bron en MedMij Registratie zorgen ervoor dat URL's in de ZAL alleen verwijzen naar de basis url van een Gegevendienst (het hoofdniveau van de interface). URL's in de ZAL bevatten geen elementen zoals parameters, verwijzingen of informatie in het path die Gegevensdienst-inhoudelijke zaken aanduiden. De DVZA bewaakt de grens tussen het endpoint-adres en de Gegevensstandaard-specifieke-uitbreiding.

Op pagina Interfaces toevoegen/aanpassen:

..
2b. Voor het samenstellen van alle adressen van het authorization request, het token request en het resource request, betrekt de OAuth Client de eerste onderdelen van de URI, namelijk host en path, uit de Zorgaanbiederslijst, op basis van de van toepassing zijnde Zorgaanbieder en hetzij Gegevensdienst (wanneer geadresseerde OAuth Authorization Server is) of Systeemrol (wanneer geadresseerde OAuth Resource Server is). Andere elementen van de algemene URI-syntax, zoals user, password, query en fragment, zijn afwezig in de adressen.
Toelichting
Met de eis dat host noch path op een / mag eindigen, wordt mogelijk gemaakt dat de URI, vooral op het resource interface, wordt aangevuld met Gegevensdienst-specifieke URL-eindstukken, zonder dat de grens met het generieke MedMij-beginstuk onherkenbaar wordt.
NB: Het path mag daarom geen verwijzingen bevatten naar de inhoud van de Gegevensdienst (conform verantwoordelijkheid 10d bij Applicatie).
De Zorgaanbiederslijst wordt dus gebruikt door de OAuth Client om het endpoint te kennen dat past bij de van toepassing zijnde Zorgaanbieder, Gegevensdienst en, voor het resource endpoint, Systeemrol. Daarom moet er uit één zo'n setje één endpoint-adres volgen. Andersom echter is dat geen eis. Het is mogelijk om, in elke door de Dienstverlener Zorgaanbieder gewenste combinatie, endpointadressen te hergebruiken voor meerdere van zulke setjes.

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
Nvt

Bijlagen

	File	Modified

No files shared here yet.

Browser not supported