In ontwikkeling
Verantwoordelijkheden, Core
Inleiding
In de MedMij Core zijn verschillende rollen beschreven, die met elkaar de verschillende functies uitvoeren en gegevens uitwisselen. Hierbij gelden de verantwoordelijkheden, zoals in dit hoofdstuk benoemd. De verantwoordelijkheden worden beschreven op de drie lagen van de architectuur, waarbij verantwoordelijkheden op de: Iedere verantwoordelijkheid heeft een unieke code, die achter de regel wordt getoond. Verwijzingen naar de verantwoordelijkheid worden uitgevoerd vanuit deze unieke codes. De code is opgebouwd uit verschillende onderdelen.
Rollen
1. | Eigenaar MedMij neemt de functionele rol van MedMij Beheer op zich. Er is één Eigenaar MedMij die één MedMij Beheer speelt. | core.rollen.100 |
2. | Een Deelnemer neemt de functionele rol van Dienstverlener persoon en/of Dienstverlener aanbieder op zich. Hierbij speelt één Deelnemer één of meerdere dienstverleners en wordt elke dienstverlener gespeeld door één Deelnemer. | core.rollen.101 |
3. | Dienstverlener persoon biedt aan Persoon, in het kader van de toepasselijke Dienstverleningsovereenkomst, een geautomatiseerde rol ter gebruik, hier genoemd: DVP Server. Eén Dienstverlener persoon biedt één of meerdere DVP Servers en elke DVP Server wordt door één Dienstverlener persoon geboden. | core.rollen.200 |
4. | Dienstverlener aanbieder biedt een geautomatiseerde rol Authorization Server, voor het namens Aanbieders uitwisselen van gezondheidsinformatie met DVP Server. Deze rol wordt altijd gecombineerd met een Resource Server . | core.rollen.201 |
5. | Dienstverlener aanbieder biedt een geautomatiseerde rol Resource Server, voor het namens Aanbieders uitwisselen van gezondheidsinformatie met DVP Server. Eén Dienstverlener aanbieder biedt één of meer combinaties van één Authorization Server en één Resource Server en elke combinatie van één Authorization Server en één Resource Server wordt door één Dienstverlener aanbieder geboden. | core.rollen.202 |
6. | Persoon gebruikt één geautomatiseerde rol User Agent voor toegang tot de functionaliteit van DVP Server en Authorization Server. User Agent presenteert de functionaliteit aan Persoon, spreekt DVP Server aan en verwijst de Persoon naar de Authorization Server. | core.rollen.203 |
7. | MedMij Beheer ontsluit ten behoeve van alle betrokkenen een geautomatiseerde rol, hier genoemd: MedMij Registratie. | core.rollen.204 |
8. | Ten behoeve van het authenticeren van Persoon, zal de betrokken Authorization Server, in de rol van Authentication Client, gebruikmaken van de Authentication Server van een Dienstverlener authenticatie. | core.rollen.205 |
9. | Ten behoeve van het autoriseren van DVP Server voor toegang tot Resource Server, in het kader van de functies Verzamelen en Delen, zullen de betrokken User Agent, DVP Server, Authorization Server en Resource Server gebruik maken van OAuth 2.0, waarbij als grant type gebruik wordt gemaakt van Authorization Code en waarbij:
| core.rollen.206 |
10. | Als MedMij-verkeer is gedefinieerd: al het gegevensverkeer in het kader van enige functie-implementatie, onmiddellijk tussen twee verschillende van de vier volgende soorten rollen, namelijk:
met dien verstande dat:
| core.rollen.207 |
11. | In het MedMij-netwerk functioneert:
| core.rollen.300 |
12. | Op één Node functioneert hetzij één Authorization Server, hetzij één Resource Server, hetzij een combinatie van voorgaande rollen. | core.rollen.301 |
Functies & gegevens
De interpretatie door een Persoon van zorg- en gezondheidsinformatie die hij heeft verzameld bij een Aanbieder, en de interpretatie door een Aanbieder van zulke informatie die met hem/haar gedeeld is door een Persoon, hangt niet alleen af van de inhoud van die informatie, maar ook van de partij die de betreffende informatie oorspronkelijk heeft geregistreerd. De oorspronkelijke herkomst van de gegevens (de auteur) kent geen rol in het MedMij afsprakenstelsel. Dat betekent niet alleen dat er binnen de grenzen van het MedMij Afsprakenstelsel momenteel geen basis is om auteursauthenticiteit (met bijvoorbeeld certificaten) te arrangeren, maar het brengt ook met zich mee dat informatie over de auteur, hoe wezenlijk ook, voor het MedMij Afsprakenstelsel een gegevens-inhoudelijke aangelegenheid is. Die informatie wordt immers ook gebruikt voor de interpretatie van de gedeelde zorg- en gezondheidsinformatie. Omdat, conform principe 1, het MedMij Afsprakenstelsel gegevensneutraal wil zijn, wordt de auteursinformatie een onderdeel geacht van de inhoud van een Gegevensdienst.
Algemeen
1. | MedMij Beheer onderhoudt een archief van alle ooit verspreide versies van de Aanbiederslijst, de OAuth Client List, de Whitelist en de Gegevensdienstnamenlijst. De bewaartermijn, gerekend vanaf het einde van de geldigheid van de betreffende versie, is niet korter dan die van de logbestanden als bedoeld in verantwoordelijkheid core.logging.101. | core.algemeen.100 |
Dossier
1. | Dienstverlener persoon biedt Persoon de functie Verzamelen om bij Dienstverlener aanbieder gezondheidsinformatie te verzamelen van Aanbieder, indien deze die informatie beschikbaar stelt, die op deze Persoon betrekking heeft en laat deze in een persoonlijk gezondheidsdossier (kortweg Dossier) van Persoon bewaren. Bij deze functie betrokken rollen gebruiken hiertoe het betreffende stroomdiagram. | core.dossier.100 |
2. | Dienstverlener persoon mag de Persoon de functie Automatisch verzamelen aanbieden, mits uitgevoerd vanuit een gegeven langdurige toestemming, het doel is de gebruiksvriendelijkheid (performance) voor de Persoon te verbeteren of dat dit ten dienste staat van analytische oplossingen waarbij de afhankelijkheid van de Persoon de dienstverlening belemmert. De Dienstverlener persoon moet hier afspraken over opnemen in de Gebruikersovereenkomst die hij met de Persoon afsluit. | core.dossier.107 |
3. | Dienstverlener persoon biedt Persoon de functie Delen om bij Dienstverlener aanbieder ten behoeve van een Persoon, indien deze daartoe ontvankelijk is, gezondheidsinformatie te plaatsen die op deze Persoon betrekking heeft en die afkomstig is uit het Dossier. Bij deze functie betrokken rollen gebruiken hiertoe het betreffende stroomdiagram. | core.dossier.101 |
4. | Dienstverlener persoon draagt ervoor zorg dat in het Dossier bij alle bij Dienstverlener aanbieder in het kader van een Gegevensdienst verzamelde informatie onlosmakelijk deze Dienstverlener aanbieder en Gegevensdienst als bron en verzamelcontext worden aangetekend. Dienstverlener persoon draagt ervoor zorg dat, in geval van het delen van informatie met een (andere) Aanbieder deze bron- en context-informatie wordt meegeleverd aan de Dienstverlener aanbieder. Voor de benoeming van de bron wordt daarbij gebruik gemaakt van de Aanbiedersnaam. Voor de benoeming van de context wordt daarbij gebruik gemaakt van de betreffende Gegevensdienstnaam uit de Gegevensdienstnamenlijst. | core.dossier.102 |
5. | Dienstverlener persoon biedt Persoon de functie Raadplegen dossier om het persoonlijk gezondheidsdossier te raadplegen. | core.dossier.103 |
6. | In het kader van de functie Raadplegen dossier zal Persoon te allen tijde moeten kunnen nagaan:
| core.dossier.104 |
7. | Dienstverlener persoon biedt Persoon de functie Verwijderen gegevens, waarmee Persoon gegevens, die via de MedMij Functie Verzamelen zijn verkregen, uit het persoonlijk gezondheidsdossier kan verwijderen. |
core.dossier.105 |
8. | In het kader van de functie Verwijderen gegevens zal Persoon te allen tijde worden geïnformeerd:
De gepresenteerde Informatie ondersteunt de gebruiksvriendelijkheid door gebruik te maken van taalniveau B1. Met de gepresenteerde informatie is het voor de Persoon duidelijk op welk deel, van de inhoud van zijn dossier, de functie verwijderen gegevens wordt toegepast. En is duidelijk wat hiervan de mogelijke consequenties zijn. |
core.dossier.106 |
9. | De Aanbieder, en daarmee de Dienstverlener aanbieder, moet de aanwezige langdurige toestemmingen beëindigen bij overlijden van de Persoon. | core.dossier.108 |
Opvragen gegevensdienstnamenlijst
1. | MedMij Beheer beheert en publiceert de Gegevensdienstnamenlijst. Deze beschrijft welke gebruikersvriendelijke namen horen bij welke Gegevensdiensten. De Gegevensdienstnamenlijst voldoet aan wat over haar is bepaald in de Informatiemodellen. | core.gnl.100 |
2. | MedMij Beheer biedt aan Deelnemers de functie Opvragen Gegevensdienstnamenlijst om de actuele versie van die Gegevensdienstnamenlijst op te vragen. Betrokken rollen gebruiken hiertoe het betreffende stroomdiagram. | core.gnl.101 |
3. | MedMij Registratie, DVP Server en Authorization Server implementeren de functie Opvragen Gegevensdiensnamenlijst, door middel van het bepaalde inzake het Gegevensdienstnamenlijstinterface op Interfaces lijsten. Zij gebruiken hiervoor het betreffende stroomdiagram. | core.gnl.200 |
4. | DVP Server en Authorization Server betrekken minstens elke vijftien minuten (900 seconden) de meest recente Gegevensdienstnamenlijst van MedMij Registratie. | core.gnl.201 |
5. | DVP Server en Authorization Server valideren elke nieuwe verkregen Gegevensdienstnamenlijst tegen het XML-schema van de Gegevensdienstnamenlijst. | core.gnl.202 |
Opvragen Aanbiederslijst
1. | MedMij Beheer beheert en publiceert een Aanbiederslijst, namens de deelnemende Dienstverlener aanbieder. De gepubliceerde Aanbiederslijst bevat steeds en slechts alle actuele entries, en beschrijft van elke Aanbieder:
Zie core.gegevensdiensten.201 voor de verantwoordelijkheden betreffende technische adressen. | core.alst.100 |
2. | MedMij Beheer beheert en publiceert, in de Aanbiederslijst, unieke en gebruikersvriendelijke namen van Aanbieders, van het formaat | core.alst.101 |
3. | MedMij Beheer biedt aan Dienstverleners persoon een functie (Opvragen Aanbiederslijst) om de actuele versie van die Aanbiederslijst op te vragen. Betrokken rollen gebruiken hiertoe het betreffende stroomdiagram. | core.alst.102 |
4. | MedMij Registratie en elke DVP Server implementeren de functie Opvragen Aanbiederslijst, door middel van het bepaalde inzake het Aanbiederslijstinterface op Interfaces lijsten. Zij gebruiken hiertoe het betreffende stroomdiagram. | core.alst.200 |
5. | DVP Server betrekt minstens elke vijftien minuten (900 seconden) de meest recente Aanbiederslijst van MedMij Registratie. | core.alst.201 |
6. | DVP Server valideert elke nieuw verkregen Aanbiederslijst tegen het XML-schema van de Aanbiederslijst. | core.alst.202 |
Opvragen Whitelist
1. | MedMij Beheer beheert en publiceert een actuele Whitelist, namens de deelnemende Dienstverleners aanbieder en Dienstverleners persoon. De Whitelist beschrijft welke Nodes in MedMij-verkeer mogen deelnemen. De Whitelist voldoet aan wat over haar is bepaald in de Informatiemodellen. | core.whl.100 |
2. | MedMij Beheer biedt aan Deelnemers de functie Opvragen Whitelist om de actuele versie van die Whitelist op te vragen. Betrokken rollen gebruiken hiertoe het betreffende stroomdiagram. | core.whl.101 |
3. | De MedMij Stelselnode biedt aan Nodes de functie Opvragen Whitelist om de actuele versie van de Whitelist op te vragen. Betrokken rollen gebruiken hiervoor het betreffende stroomdiagram. | core.whl.300 |
4. | Het aandeel van de MedMij Stelselnode in de functie Opvragen Whitelist is voor minstens 99,9% van de tijd beschikbaar. MedMij Registratie laat, na het niet beschikbaar raken van het aandeel van MedMij Stelselnode in de usecase, maximaal acht uren (480 minuten) verstrijken voordat het weer beschikbaar is. | core.whl.301 |
5. | Nodes betrekken minstens elke vijftien minuten (900 seconden) de meest recente Whitelist van MedMij Registratie. | core.whl.302 |
6. | MedMij Registratie heeft | core.whl.303 |
7. | Nodes valideren elke nieuw verkregen Whitelist tegen het XML-schema van de Whitelist. Alle hostnames op de Whitelist zijn fully-qualified domain names, conform RFC3696, sectie 2. | core.whl.304 |
8. | Ten behoeve van de technische beveiliging van het gegevensverkeer, dat zich voltrekt in het kader van de functie Opvragen Whitelist, maken betrokken rollen gebruik van Versleuteling, Server Authentication en Server Authorization. | core.whl.305 |
9. | Backchannel Nodes laten, elk hunnerzijds, backchannel-verkeer over het MedMij-netwerk dan en alleen dan doorgang vinden, nadat zij hebben vastgesteld dat de hostname van de andere Node, waarmee verbinding gemaakt zou worden, op de meest actuele Whitelist voorkomt. | core.whl.306 |
10. | De Node die
| core.whl.307 |
11. | Voor zover de Dienstverlener aanbieder ervoor kiest de controle tegen de Whitelist na afloop van de TLS-handshake uit te voeren, is deze controle logisch gescheiden van de bedoelde eerstvolgende stap. De vereiste volgordelijkheid kan worden aangetoond door middel van code-inspecties, penetratietesten en inspecties van logs. | core.whl.308 |
12. | Indien een Whitelist-controle, in het kader van verantwoordelijkheid core.whl.307 en core.whl.308, niet kan worden uitgevoerd, of een negatief resultaat oplevert, breekt dit de voortgang af van de uitvoering van de functie en stellen de betrokken Applicatie-rollen elkaar hiervan niet op de hoogte. | core.whl.309 |
Opvragen OAuth Client List
1. | MedMij Beheer beheert en publiceert een actuele OAuth Client List, namens de deelnemende Dienstverleners persoon. De gepubliceerde OAuth Client List bevat steeds en slechts alle actuele entries, en beschrijft van elke OAuth Client:
| core.ocl.100 |
2. | De OAuth Client List voldoet aan wat over haar is bepaald in de Informatiemodellen. | core.ocl.101 |
3. | MedMij Beheer biedt aan Deelnemers de functie Opvragen OAuth Client List om de actuele versie van die OAuth Client List op te vragen. Betrokken rollen gebruiken hiertoe het betreffende stroomdiagram. | core.ocl.102 |
4. | MedMij Registratie en Authorization Server implementeren de functie Opvragen OAuth Client List, door middel van het bepaalde inzake het interface voor OAuth Client List op Interfaces lijsten. Zij gebruiken hiervoor het betreffende stroomdiagram. | core.ocl.200 |
5. | Authorization Server betrekt minstens elke vijftien minuten (900 seconden) de meest recente OAuth Client List (OCL) van MedMij Registratie. | core.ocl.201 |
6. | Authorization Server valideert elke nieuwe verkregen OAuth Client List (OCL) tegen het XML-schema van de OAuth Client List. | core.ocl.202 |
7. | De OAuth Client List bevat voor elke DVP Server alleen die Node waarmee de betreffende DVP Server het frontchannelverkeer afhandelt. | core.ocl.300 |
Opvragen Aanbiedersregister
1. | Stichting MedMij publiceert het Aanbiedersregister op een publiek toegankelijke locatie. MedMij beheer publiceert uiterlijk 31 oktober 2023 de eerste versie van het Aanbiedersregister op de publiek toegankelijke locatie. | core.reg.100 |
2. | Het Aanbiedersregister is voor mensen begrijpelijk (human readable) weergegeven. | core.reg.101 |
3. | Het Aanbiedersregister bevat de gebruiksvriendelijke namen van aangesloten aanbieders, de bijbehorende identificerende gegevens, de bijbehorende gegevensdiensten en de uitwisselingsstatus. Het Aanbiedersregister bevat alleen de gegevens van aanbieders die voldoen aan de eisen en normen die in de DAP beschreven staan. De DAP wordt in de maanden na de eerste publicatie van versie 2.0.0 aangepast en mogelijk voorzien van bijlagen. Deelnemers hoeven daarom pas aan deze eisen te voldoen zodra 2.0.0 de verplichte versie is van het afsprakenstelsel. | core.reg.102 |
4. | Aanbieders zijn zelf verantwoordelijk voor de kwaliteit van de informatie die in het register staat. Gewenste wijzigingen kunnen worden doorgegeven aan MedMij Beheer of worden doorgevoerd via de geboden interfaces. | core.req.103 |
5. | MedMij Beheer kan als enige partij de uitwisselingsstatus van een aanbieder of de bij de Aanbieder behorende gegevensdiensten aanpassen. MedMij Beheer baseert de keuze tot wijziging op de normen die in de DAP of specifieke bijlagen beschreven staan. | core.req.104 |
6. | MedMij Beheer biedt aan Deelnemers de functie Opvragen Aanbiedersregister om de actuele versie van het Aanbiedersregister op te vragen. | core.reg.105 |
7. | MedMij Registratie en DVP Server implementeren de functie Opvragen Aanbiedersregister, door middel van het bepaalde inzake het Aanbiedersregisterinterface op Interfaces lijsten en register. | core.reg.200 |
8. | Het Aanbiedersregister is gebaseerd op de inhoud van technische lijst(en) die in JSON-formaat wordt aangeboden. MedMij beheer levert uiterlijk 31 oktober 2023 de eerste versie van de lijst waarop het Aanbiedersregister gebaseerd is. | core.reg.201 |
9. | Het Aanbiedersregister is voor minstens 99,9% van de tijd beschikbaar. Onbeschikbaarheid duurt maximaal acht uren (480 minuten). | core.reg.300 |
Account bij Dienstverlener persoon
1. | Voor het inrichten van een MedMij dossier en voor het gebruikmaken van de verschillende MedMij functies moet de Persoon een actief account hebben bij de Dienstverlener persoon. | core.account.100 |
2. | De Dienstverlener persoon geeft een account de status 'inactief' zodra een account 6 maanden lang niet gebruikt is door de Persoon. | core.account.101 |
3. | De dienstverlener persoon geeft een inactief account de status 'actief' zodra de Persoon weer gebruikmaakt van het account. | core.account.102 |
4. | De Dienstverlener persoon moet de Persoon notificeren per e-mail of (als de DVP dit aanbiedt) per SMS van het feit dat het account de status 'inactief' heeft gekregen en indien van toepassing geen gebruikmaakt van aanwezige langdurige toestemmingen, totdat de Persoon opnieuw inlogt. | core.account.103 |
Gegevensuitwisseling
1. | De Dienstverlener persoon mag alleen de functie Automatisch verzamelen aanbieden indien het doel is de performance voor de Persoon te verbeteren. Daarnaast kan gebruikgemaakt worden van automatisch verzamelen ten dienste van analytische oplossingen, zoals AI modules en andere technische toepassingen, waarbij de afhankelijkheid van de gebruiker een bottleneck is voor de te leveren dienst. | core.gegevensuitwisseling.100 |
2. | De Dienstverlener persoon mag alleen gebruik maken van automatisch verzamelen bij een uitdrukkelijke opdracht van de Persoon. | core.gegevensuitwisseling.101 |
4.. | De Dienstverlener persoon mag slechts één keer per 24 uur geautomatiseerd gegevens verzamelen bij een Dienstverlener aanbieder. | core.gegevensuitwisseling.102 |
5. | De Dienstverlener persoon mag alleen geautomatiseerd gegevens verzamelen voor actieve accounts. | core.gegevensuitwisseling.103 |
6. | De Dienstverlener persoon is verplicht de Persoon van succesvolle automatische uitwisseling te notificeren op een door de Persoon gewenste manier. Dit kan bijvoorbeeld in de app/browser, per e-mail of per SMS. Ook andere denkbare varianten zijn mogelijk. | core.gegevensuitwisseling.104 |
9. | Indien uitwisseling van gegevens binnen een langdurige toestemming 48 uur of langer niet mogelijk is, is de DVP verplicht de Persoon te notificeren op een door de Persoon gewenste manier. Dit kan bijvoorbeeld in de app/browser, per e-mail of per SMS. Ook andere denkbare varianten zijn mogelijk. | core.gegevensuitwisseling.105 |
10. | Bij geautomatiseerd verzamelen moet bij het request gelogd worden dat het om een automatische opvraging gaat. | core.gegevensuitwisseling.200 |
11. | Batch-gewijs geautomatiseerd verzamelen voor meerdere Personen mag alleen in het tijdslot van 23.00 uur tot 6.00 uur en niet allemaal op hetzelfde tijdstip. | core.gegevensuitwisseling.201 |
Gegevensdiensten
1. | Dienstverlener persoon laat Persoon gezondheidsinformatie verzamelen bij een Dienstverlener aanbieder of, ten behoeve van een Aanbieder, plaatsen bij een Dienstverlener aanbieder. | core.gegevensdiensten.100 |
2. | Elke Dienstverlener aanbieder ontsluit op elk moment minstens één Gegevensdienst. | core.gegevensdiensten.101 |
3. | MedMij Beheer zal alleen in de Aanbiederslijst opnemen dat een zekere Gegevensdienst door een zekere Aanbieder via een Dienstverlener aanbieder, wordt aangeboden, indien zij (Stichting MedMij) heeft vastgesteld dat de Dienstverlener aanbieder voldoet aan de specifiek op die Gegevensdienst toepasselijke eisen en de normen die staan beschreven in de DAP en aanverwante documenten. De DAP wordt in de maanden na de eerste publicatie van versie 2.0.0 aangepast en mogelijk voorzien van bijlagen. Deelnemers hoeven daarom pas aan deze eisen te voldoen zodra 2.0.0 de verplichte versie is van het afsprakenstelsel. | core.gegevensdiensten.102 |
4. | Voor elke Gegevensdienst waarvan de Aanbiederslijst aangeeft dat een zekere Aanbieder deze aanbiedt, zal een Dienstverlener aanbieder ervoor zorgdragen dat die Gegevensdienst ook geleverd wordt. Daarbij wordt geen enkel onderscheid gemaakt tussen Dienstverleners persoon, tenzij het MedMij Afsprakenstelsel daartoe uitdrukkelijk verplicht. Dit geldt ook voor de mogelijke andere Gegevensdienst(en) die in de /wiki/spaces/MMCatalogus/overview staan genoemd als Vereist bij eerstgenoemde Gegevensdienst. | core.gegevensdiensten.103 |
5. | Het in verantwoordelijkheid core.gegevensdiensten.103 bepaalde is ook van toepassing zolang de geldigheid van de toepasselijke vermelding in de Aanbiederslijst niet langer dan één uur (3600 seconden) geleden is verstreken. | core.gegevensdiensten.104 |
6. | In aansluiting op verantwoordelijkheid core.gegevevendiensten.102 heeft Stichting MedMij het recht registraties van Aanbieder-gegevensdienst-combinaties te verwijderen als blijkt dat uitwisseling voor deze combinatie niet mogelijk is, of dat voor deze combinatie niet wordt voldaan aan de normen die staan beschreven in het Ketennormenbeleid. | core.gegevensdiensten.105 |
7. | Als een Dienstverleners persoon een zekere Gegevensdienst ontsluit ten behoeve van zijn Personen en daartoe laat leveren door een Dienstverlener aanbieder, zullen de DVP Server van die Dienstverlener persoon en de Authorization Server en Resource Server van die Dienstverlener aanbieder daarvoor de bij de Gegevensdienst horende functie implementeren en de bij de Gegevensdienst horende Systeemrollen gebruiken, zoals deze in de Catalogus zijn opgenomen, en zich daarbij te conformeren aan de specificaties van die Systeemrollen zoals die zijn gepubliceerd op de plaats(en) waarnaar de Catalogus verwijst met Functionelespecificatieverwijzing en Technischespecificatieverwijzing. | core.gegevensdiensten.200 |
8. | Voor iedere gegevensdienst moet de Dienstverlener aanbieder unieke endpoints voor de Resource Server registreren in de MedMij Registratie. | core.gegevensdiensten.201 |
Autorisatie
1. | Dienstverlener aanbieder vergewist zich ervan, elke keer opnieuw voordat hij Persoon gezondheidsinformatie van Aanbieder laat verzamelen door middel van de functie Verzamelen, dat deze Persoon uitdrukkelijk Toestemming heeft gegeven aan Aanbieder om de in de Gegevensdienst betrokken gezondheidsinformatie aan Dienstverlener persoon ter beschikking te laten stellen. De vraag om Toestemming heeft een vaste formulering, die is opgenomen in de functie Autoriseren. Deze Toestemming is:
| core.autorisatie.100 |
2. | Dienstverlener aanbieder vergewist zich ervan, elke keer opnieuw voordat hij Persoon gezondheidsinformatie ten behoeve van Aanbieder laat plaatsen, dat deze Persoon uitdrukkelijk heeft bevestigd om de in de Gegevensdienst betrokken gezondheidsinformatie aan Aanbieder ter beschikking te willen stellen. De vraag om Bevestiging heeft een vaste formulering, die is opgenomen in de functie Delen. Deze bevestiging geldt niet buiten één doorloping van de functie Delen. | core.autorisatie.101 |
3. | In de implementatie van de functies Verzamelen en Delen handelen DVP Server enerzijds en Authorization Server en Resource Server anderzijds, hun onderlinge verkeer af conform de standaard OAuth 2.0. | core.autorisatie.200 |
4. | Van de vier soorten authorization grants die OAuth 2.0 biedt, beperken de OAuth-rollen zich tot Authorization Code Grant. | core.autorisatie.201 |
5. | De OAuth Client en OAuth Resource Server zullen slechts tokens van het type Bearer-token uitwisselen, conform RFC6750. | core.autorisatie.202 |
6. | Hoewel het technisch mogelijk is om meerdere scopes mee te geven, maakt de OAuth Client gebruik van één scope tegelijk. Hierin staat de MedMij-naam van de Aanbieder, waarbij autorisatie wordt gevraagd, genoemd. De OAuth Authorization Server genereert authorization-codes en access-tokens met een enkelvoudige scope die gelijk is aan de scope in het verzoek van de OAuth client. | core.autorisatie.203 |
7. | De OAuth Authorization Server stelt van elke uitgegeven authorization-code en elk uitgegeven access-token de geldigheidsduur op exact 15 minuten (900 seconden). | core.autorisatie.204 |
8. | De OAuth Authorization Server stelt van elk uitgegeven refresh-token de geldigheidsduur op 6 maanden. Hierbij geldt de dag waarop het refresh-token uitgegeven wordt als eerste dag. | core.autorisatie.211 |
9. | De OAuth Authorization Server genereert authorization-codes, access-tokens en refresh-tokens zodanig, dat de kans op het raden ervan niet groter is dan 2-128 en de daarvoor gebruikte random number generators cryptografisch veilig zijn. | core.autorisatie.205 |
10. | In de authorization-codes, access-tokens en refresh-tokens is het desgewenst toegestaan één of meer van de informatie-elementen uit de volgende limitatieve lijst op te nemen:
| core.autorisatie.206 |
11. | Geen andere informatie dan de in core.autorisatie.206 genoemde mag voorkomen in de authorization-code, het acces-token of het refresh-token, ook niet versleuteld. Er mogen t.a.v. informatie-inhoud van het token verschillende keuzes gemaakt worden tussen authorization-code, access-token of het refresh-token. De OAuth Client mag de inhoud van het token niet interpreteren. | core.autorisatie.207 |
12. | Met betrekking tot zowel authorization-codes als access-tokens en refresh-tokens, draagt de OAuth Authorization Server die hen uitgeeft ervoor zorg, dat daarvan nooit twee dezelfde geldige in omloop zijn. | core.autorisatie.208 |
13. | Access-tokens worden alleen uitgegeven na controle van de client_id, de opgegeven autorisatie-code (of het refresh-token) en de Common name van het in de TLS verbinding gebruikte certificaat. De controles worden uitgevoerd conform:
Controle certificaat optioneel De controle van het in de TLS verbinding gebruikte certificaat is vooralsnog optioneel. De implementatie van deze controle wordt sterk aangeraden, zodat met een hogere mate van zekerheid de verzoekende partij kan worden vastgesteld. | core.autorisatie.209 |
14. | Het OAuth-client type van de OAuth Client is confidential. | core.autorisatie.210 |
Authenticatie
1. | Dienstverlener aanbieder draagt ervoor zorg dat de onder core.gegevensdiensten.103, core.gegevensdiensten.104, core.autorisatie.100 en core.autorisatie.101 bedoelde vraag om Toestemming, respectievelijk bevestiging, slechts plaatsvinden wanneer hij de identiteit van de Persoon met passende zekerheid heeft vastgesteld. | core.authenticatie.100 |
Adressering
1. | De OAuth Client stelt conform RFC 3986 de URI samen waarmee hij zichzelf, de Authorization Server en de Resource Server adresseert. | core.adressering.200 |
2. | De URI's een hostname die een fully-qualified domain name is, conform RFC3696, sectie 2, en heeft het patroon scheme://host path , waarbij:
| core.adressering.201 |
3. | In alle adressering op het authorization interface, het token interface en het resource interface is het gebruik van het voor | core.adressering.202 |
4. | Voor het samenstellen van alle adressen van het authorization request en het token request, betrekt de OAuth Client de eerste onderdelen van de URI, namelijk host en path , uit de Aanbiederslijst, op basis van de van toepassing zijnde Aanbieder, Interfaceversie en Gegevensdienst. Andere elementen van de algemene URI-syntax, zoals user , password , query en fragment , zijn afwezig in de adressen.Voor het samenstellen van alle adressen van het resource request, betrekt de OAuth Client de base url (het onderdeel van de URI dat is aangeduid als [base] in de specificaties van de Transactie die behoort bij de van toepassing zijnde combinatie Aanbieder, Gegevensdienst en Systeemrol), uit de Aanbiederslijst, op basis van de van toepassing zijnde Aanbieder, Interfaceversie, Gegevensdienst en Systeemrol. Wanneer de specificaties een request identificeren maar geen [base] aanduiden, mag de OAuth Client het resource request alleen indienen als de volledige, absolute URI van het resource request begint met de volledige ResourceEndpointuri zoals die is verkregen uit de Aanbiederslijst, op basis van de van toepassing zijnde Aanbieder, Interfaceversie, Gegevensdienst en Systeemrol. | core.adressering.203 |
5. | MedMij Registratie wordt in de functies Opvragen Aanbiederslijst, Opvragen OAuth Client List en Opvragen Gegevensdienstnamenlijst geadresseerd met de hostname stelselnode.medmij.nl . | core.adressering.204 |
Beveiliging
1. | In het gegevensverkeer voor de functies Verzamelen, Delen, Beheren toestemmingen, Opvragen Aanbiederslijst, Opvragen OAuth Client List en Opvragen Gegevensdienstnamenlijst, maken betrokken rollen gebruik van de functies Versleuteling, Server Authentication en Server Authorization, zoals beschreven onder TLS en certificaten. | core.beveiliging.200 | |||||||||||||||||||||||||||||||||||||||||||
2. | De OAuth Client en OAuth Authorization Server gebruiken voor al hun onderlinge verkeer PKI-certificaten, en wel servercertificaten, ten behoeve van de authenticatie van de andere server in een uitwisseling. | core.beveiliging.201 | |||||||||||||||||||||||||||||||||||||||||||
3. | De OAuth Client realiseert de volgende beveiligingsmaatregelen, conform RFC 6819:
| core.beveiliging.202 | |||||||||||||||||||||||||||||||||||||||||||
4. | De OAuth Client realiseert de volgende beveiligingsmaatregelen, conform RFC 6819:
| core.beveiliging.203 | |||||||||||||||||||||||||||||||||||||||||||
5. | De OAuth Authorization Server realiseert de volgende beveiligingsmaatregelen, conform RFC 6819:
|