Changelog versie 2.0.0

Onderstaande is bedoeld ter vervanging van de changelog voor versie 2.0.0. De oude versie kan daarmee volledig worden verwijderd.

• Overzicht

• Verplichte wijzigingen

• Optionele wijzigingen

• Overige wijzigingen

• Verplichte wijzigingen

  • Duiding van fouten

  • Langdurige toestemmingen

  • Verplichting controle op uniciteit uitgegeven authorization codes, access tokens en refresh tokens

  • Logging-monitoring en rapporteren

  • Schermen uitwerken in Core en Extensies (en Domeinen)

• Optionele wijzigingen

  • 0 tot en met 11 jaar verwerken in afsprakenstelsel

  • Aanscherping aanbieder zonder behandelrelatie

  • Aanbieders in het afsprakenstelsel (fase 1)

  • Aanpassing Uitzondering Resource Interface 1

1. Overzicht

Hieronder vind je een overzicht van de wijzigingen in het afsprakenstelsel die zijn doorgevoerd in het kader van release 2.0.0. Ook is aangegeven op welke deelnemers de wijziging impact heeft. Onder het overzicht staat voor de verplichte en optionele wijzigingen uitgebreider beschreven wat de wijzigingen inhouden.

5. Verplichte wijzigingen

5.1. Duiding van fouten

5.1.1. Gewenste resultaat

De Persoon wordt beter ingelicht over de alternatieve flows die in het proces gevolgd worden. Alternatieve flows worden bijvoorbeeld gevolgd op het moment dat er iets fout gaat in het proces. In de oude situatie lichtte de Dienstverlener aanbieder de Dienstverlener persoon in, maar de Dienstverlener aanbieder mocht geen informatie geven over de opgetreden fout waardoor de Dienstverlener persoon geen inhoudelijke informatie kon geven aan de Persoon.

5.1.2. Aanpassing

Het proces is uitgetekend en uitgeschreven, hieruit is gebleken dat de Persoon bij de meeste alternatieve flows kan worden ingelicht door de Dienstverlener aanbieder. Hierdoor hoeft er niet meer informatie naar de Dienstverlener persoon en beschikt de Persoon wel over de benodigde informatie. Onderstaand overzicht bevat een overzicht van de mogelijk schermen, waarbij de linker schermen de happy flow vormen.

In dit overzicht is een tweetal foutschermen te zien dat door de Dienstverlener aanbieder geïmplementeerd moet worden. Ten eerste kan er in de aanroep van de Authorization Interface (bij 1) iets mis zijn met de client_id en/of de redirection_uri. Zoals in sectie 4.1.2.1 van IETF RFC 6749 gespecificeerd is, moet de Authorization server in dit geval een foutmelding tonen. Bij problemen met het inloggen bij DigiD (2A) wordt de DVA foutpagina 3B getoond. Bij onsuccesvolle authenticatie weet de Persoon zo wat er is misgegaan en kan dan kiezen voor een bepaalde vervolgstap.

De verantwoordelijkheden zijn in een vernieuwde vorm opgesteld voor de schermen die door de Dienstverleners aanbieder geïmplementeerd moeten worden. Voorheen bevatte het afsprakenstelsel een HTML en CSS bestand, deze zijn verwijderd. Er zijn voorbeelden van de schermen toegevoegd en in de verantwoordelijkheden is beschreven waaraan sowieso voldaan moet worden. Deze schermen en verantwoordelijkheden zijn te vinden via Schermen (User interface), Core.

In het geheel missen we nog een scherm. Indien authenticatie wel is gelukt, maar de toestemming wordt niet binnen 15 minuten gegeven, moet de Dienstverlener aanbieder ook een foutscherm tonen. De Persoon wordt in dit geval niet direct teruggestuurd naar de PGO, maar krijgt de optie opnieuw in te loggen. De wijzigingen die voor dit scherm noodzakelijk zijn worden uitgewerkt en later aan het afsprakenstelsel toegevoegd.

5.2. Langdurige toestemmingen

5.2.1. Gewenste resultaat

De persoon kan per Dienstverlener aanbieder voor langere tijd toestemming geven, waardoor identificatie en authenticatie niet meer bij iedere uitwisseling noodzakelijk zijn. Indien er sprake is van een langdurige toestemming kunnen Dienstverlener persoon en Dienstverlener aanbieder vanuit deze langdurige toestemming met elkaar uitwisselen.

5.2.2. Aanpassing

In het afsprakenstelsel zijn veel pagina’s geraakt door deze wijziging, maar voor de Dienstverlener persoon en de Dienstverlener aanbieder betekent dit vooral dat op het moment dat de Persoon langdurige toestemming heeft gegeven dat binnen de OAuth 2.0 flow gebruikgemaakt moet worden van refresh-tokens. Het proces kent hierdoor een aantal afslagen die door de partijen geïmplementeerd dienen te worden.

5.2.2.1. Keuze van de Persoon

Of er gebruikgemaakt wordt van langdurige toestemming is een keuze van de Persoon, daarom moet de Dienstverlener aanbieder de Persoon vragen of toestemming gegeven wordt voor de lange duur). Dit gebeurt tijdens de toestemmingenverklaring. Er is een voorbeeldscherm beschikbaar in het afsprakenstelsel.

Let wel, toestemmingen worden per Dienstverlener aanbieder vastgelegd. Als een Aanbieder met meerdere Dienstverleners aanbieder werkt, dan moet de Persoon per Dienstverlener aanbieder toestemming geven.

5.2.2.2. Scope

Voorheen werd per gegevensdienst toestemming gegeven en bevatte de scope een verzameling van aanbieder-gegevensdienst combinaties. Vanaf versie 2.0.0 wordt toestemming gegeven aan een aanbieder, waarbij geen onderscheid meer gemaakt wordt in gegevensdiensten. De scope bevat alleen nog een identificerend kenmerk (MedMij aanbiedernaam). Met deze toestemming kunnen op ieder moment de beschikbare gegevens worden opgehaald.

5.2.2.3. Uitwisseling van tokens

Voorheen was het verboden te werken met refresh-tokens, nu is dit verplicht voor alle deelnemers. Als de Persoon toestemming geeft voor lange duur, dan wordt door de Dienstverlener aanbieder een access-token en een refresh-token uitgegeven. De maximale leeftijd van dit refresh-token is 6 maanden. Binnen deze periode kan de Dienstverlener persoon het refresh-token inwisselen voor een nieuw access-token en een nieuw refresh-token. Dit gebeurt op de token-interface en deze wordt in plaats van een authorization-code meegestuurd. Een refresh-token is eenmalig te gebruiken, dus bij gebruik moet de Dienstverlener aanbieder deze direct vervangen voor een nieuwe. Refresh-tokens zijn maximaal 6 maanden geldig. Na het verlopen van deze termijn moet de Persoon opnieuw inloggen en toestemming geven. Informatie over de uitwisseling van de code en de tokens is te vinden in hoofdstuk autorisatie in de Core van het afsprakenstelsel en in de beschrijvingen van de Authorization interface.

5.2.2.4. Automatische uitwisseling

De Dienstverlener persoon mag de Persoon automatische uitwisseling aanbieden. De Persoon hoeft zelf de functie niet meer te starten, maar kan dit overlaten aan de Dienstverlener persoon. Idealiter wordt dit gedaan vanuit een verkregen notificatie, waarbij de functie abonneren nodig is. Omdat dit nog beperkt wordt aangeboden, is ervoor gekozen dat de Dienstverlener persoon periodiek gegevens mag ophalen. Hiervoor zijn nieuwe verantwoordelijkheden opgesteld, waardoor de Dienstverlener persoon beperkt wordt in de mogelijkheden. Deze verantwoordelijkheden zijn te vinden in het hoofdstuk gegevensuitwisseling in de Core van het afsprakenstelsel.

Automatische uitwisseling mag alleen plaatsvinden op actieve accounts. Daarom is toegevoegd dat een DVP account de status ‘inactief' moet krijgen, zodra deze een half jaar niet is gebruikt. Voor accounts met de status ‘inactief’ mag geen gebruikgemaakt worden van langdurige toestemmingen. De Dienstverleners persoon moeten voldoen aan deze nieuwe verantwoordelijkheden, zoals beschreven in het hoofdstuk Account bij de Dienstverlener persoon in de Core van het afsprakenstelsel.

5.2.2.5. Beheer van de toestemmingen

De Persoon moet toestemmingen kunnen intrekken, dit gebeurt via een beheerscherm. De Persoon krijgt op de landingspagina bij de Dienstverlener aanbieder twee opties, ‘toestemming geven' en ‘toestemming aanpassen’. Als de Persoon kiest voor 'toestemming aanpassen’ dan toont de Dienstverlener aanbieder de Overzichtspagina toestemmingen (na inloggen). Hier ziet de Persoon de uitgegeven toestemmingen voor deze Dienstverlener aanbieder. Deze toestemmingen kunnen worden ingetrokken. Om er zeker van te zijn dat de Persoon de toestemming wil intrekken toont de Dienstverlener aanbieder eerst de Beëindigingsverklaring langdurige toestemming. Na het intrekken van de toestemming kan het eerder uitgegeven refresh-token niet meer ingewisseld worden voor een access-token. Bij een nieuwe uitwisseling moet de Persoon opnieuw toestemming geven.

5.3. Verplichting controle op uniciteit uitgegeven authorization codes, access tokens en refresh tokens

5.3.1. Gewenste resultaat

Gebleken is dat deelnemers niet unieke codes en/of tokens uitgaven. Hierdoor bestaat het risico dat meerdere Personen dezelfde code of token ontvingen en elkaars gegevens konden inzien. Dit mag niet (meer) gebeuren.

5.3.2. Aanpassing

In het normenkader is toegevoegd dat een code review uitgevoerd moet worden door de auditor om te controleren of codes en tokens aan de uniciteitseisen voldoen. Dit betekent niet dat alle code van de deelnemers gecontroleerd moet worden, maar alleen het deel dat verantwoordelijk is voor de uitgifte van codes en tokens. De eis dat tokens en codes uniek moeten zijn, staat beschreven in verantwoordelijkheid core.autorisatie.208.

5.4. Logging-monitoring en rapporteren

5.4.1. Gewenste resultaat

Voorheen werd van deelnemers verwacht dat zij middels hun eigen logging en monitoring zicht hadden op verstoringen in hun eigen applicatie . Daarnaast dienden zij ook zicht te hebben op de verstoringen van de deelnemers waarmee ze communiceren. Echter werden verstoringen van schakels in de keten niet altijd of soms laat gesignaleerd en/of gemeld. Het doel van de wijzigingen is erop gericht om regie te realiseren in de MedMij keten.

Oftewel: weten, signaleren en acteren op de kwantiteit en kwaliteit van de gegevensuitwisseling tussen de schakels van de MedMij keten. Zodat de persoon veilig en betrouwbaar kan uitwisselen via een zelfgekozen PGO.  

5.4.2. Aanpassing

Om ervoor te zorgen dat MedMij Beheer regie kan voeren is ervoor gekozen om de deelnemers bepaalde activiteiten te laten loggen en alle logs centraal te analyseren. Hiervoor is in het afsprakenstelsel beschreven aan welke eisen de logregels moeten voldoen en is er voorbereid op de benodigde wijzigingen in het netwerk voor het verzamelen van deze logregels. De vereisten aan de logregels kunnen worden gevonden in Logginginterface.

5.5. Schermen uitwerken in Core en Extensies (en Domeinen)

5.5.1. Gewenste resultaat

Voor alle deelnemers, en vooral voor de Dienstverleners aanbieder, is duidelijk wat verwacht wordt van de te implementeren schermen.

5.5.1.1. Aanpassing

Op de pagina Schermen (User interface), Core en onderliggende pagina’s is beschreven aan welke eisen de schermen moeten voldoen en zijn van alle schermen voorbeelden getoond. Er is ruimte om van de voorbeelden af te wijken. Voorheen bevatte het afsprakenstelsel HTML en CSS bestanden, omdat dit te beperkend was en niet alle deelnemers maken gebruik van webinterfaces is gekozen deze bestanden in hun geheel te verwijderen. De voorbeeldschermen kunnen worden aangehouden, waarbij de deelnemers zelf verantwoordelijk zijn voor de juiste schaling.

6. Optionele wijzigingen

6.1. 0 tot en met 11 jaar verwerken in afsprakenstelsel

6.1.1. Gewenste resultaat

Tot en met versie 1.6.0 van het afsprakenstelsel konden alleen volwassenen (vanaf 16 jaar en ouder) gegevens verzamelen. Maar ook de gegevens van kinderen moeten kunnen worden verzameld, zodat deze kinderen of hun ouders het overzicht hebben dat zij verdienen. Daarmee komen de kinderen en hun ouders ook voor deze leeftijdscategorie in de regie.

6.1.1.1. Aanpassing

De Extensie Vertegenwoordiging is zo aangepast dat vertegenwoordiging nu ook kan worden toegepast voor de leeftijdscategorie van 0 tot en met 11 jaar. Om hiervan gebruik te maken moet vanuit DigiD een register worden gebruikt waarin de gezaghebbende van de kinderen staan geregistreerd, zodat bepaald kan worden wie verantwoordelijk is voor het kind. Als hiervoor gekozen is, moet de beschikbaarheidstoets controleren of het kind inderdaad onder de 12 jaar is.

Voor de leeftijd van 12 tot 16 (tot en met 15) kan dit helaas niet worden ingezet, omdat in dit geval juridisch gezien de toestemmingen van ouder en kind noodzakelijk zijn. Dit wordt nog verder onderzocht en wordt later ook mogelijk gemaakt.

6.2. Aanscherping aanbieder zonder behandelrelatie

6.2.1. Gewenste resultaat

Vanuit het Addendum aanbieder zonder behandelrelatie kan een partij die geen Zorgaanbieder is onder de beschreven omstandigheden deelnemen aan MedMij. Het is gewenst dat in het netwerk duidelijk is dat het om een aanbieder zonder behandelrelatie gaat.

6.2.1.1. Aanpassing

In de Zorgaanbiederslijst wordt een attribuut toegevoegd waarin te vinden is of het om een aanbieder zonder behandelrelatie gaat. Dienstverleners aanbieder kunnen hiervan gebruikmaken, maar voor de meesten zal er niets veranderen.

6.3. Aanbieders in het afsprakenstelsel (fase 1)

6.3.1. Gewenste resultaat

De verantwoordelijkheden die een Dienstverlener aanbieder nu uit naam van de Aanbieder invult moeten ook echt de verantwoordelijkheid van de Aanbieder worden. Er wordt geanalyseerd wat dit betekent voor het afsprakenstelsel, maar op korte termijn moeten de eerste stappen gezet worden.

6.3.1.1. Aanpassing

MedMij zal een register bieden van alle via MedMij benaderbare Aanbieders en de gegevensdiensten die zij leveren. Dit register zal te vinden zijn via register.medmij.nl en bevat de MedMij naam, Identificerende kenmerken die bijvoorbeeld ook door ZORG-AB worden gebruikt, bij de aanbieder behorende gegevensdiensten en de uitwisselingsstatus per Aanbieder en per gegevensdienst van diezelfde Aanbieder. Dit register krijgt in de loop van 2023 vorm en wordt zo snel mogelijk gepubliceerd.

6.4. Aanpassing Uitzondering Resource Interface 1

6.4.1. Gewenste resultaat

Vanuit acceptatie is aangegeven dat de uitzondering niet uitgevoerd kan worden. Partijen uit het netwerk geven aan dat hun libraries alleen 400 kunnen teruggeven, andere geven aan alleen 401 terug te kunnen geven. Beiden moeten geaccepteerd worden.

6.4.1.1. Aanpassing

In samenspraak met Aorta is besloten beide foutcodes te accepteren.