Hieronder vind je een overzicht van de grootste wijzigingen in het afsprakenstelsel ten opzichte van release %vorige_versie_afsprakenstelsel en een grove schatting van de impact die de wijziging heeft op de deelnemers.

Verplichte wijzigingen	Impact DVP	Impact DVZA
Om de gebruikersvriendelijkheid op een hoger niveau te krijgen, is het mogelijk gemaakt om in één handeling voor meerdere gegevensdiensten autorisatie te verlenen. In de huidige vorm zitten hier wel beperkingen aan. Autorisatie kan gegeven worden voor alle gegevensdiensten die namens een Aanbieder worden aangeboden door een Dienstverlener Aanbieder. Indien gebruik wordt gemaakt van deze optie, moeten de verschillende gegevensdiensten worden meegegeven in de scope van het verzoek. Voorheen mocht hier maar één gegevensdienst worden opgegeven.	Optioneel	Verplicht
De normen A.18.2.3 (1) en A.18.2.3 (2) zijn gewijzigd. De eisen te aanzien van een penetratietest zijn specifieker benoemd. Daarnaast hoeft de test niet altijd meer als whitebox test uitgevoerd te worden, maar kan een greybox test ook volstaan.	Verplicht	Verplicht
De Dienstverlener persoon is verplicht de gehele PGO te beveiligen met Multi Factor Authentication, waarbij de tweede factor bij voorkeur sterker is dan het gebruik van SMS.	Verplicht	Geen
In de Authorization en Token requests moet de `redirect_uri` URL-encoded zijn.	Verplicht	Verplicht
In het Authorization request moet de state parameter voldoen aan de nieuw gestelde eisen. Voorheen was er geen beperking betreffende de lengte.	Verplicht	Verplicht

Optionele wijzigingen	Impact DVP	Impact DVZA
Vrijwillige vertegenwoordiging is als extensie toegevoegd. Als dit door Deelnemers geïmplementeerd wordt, kan een Persoon (Vertegenwoordigde) zich laten vertegenwoordigen door een andere partij / Persoon (Vertegenwoordiger). Voor beide rollen (Dienstverlener persoon en Dienstverlener aanbieder) is het optioneel Vertegenwoordiging te implementeren. Daarom is een aantal uitzonderingen en verantwoordelijkheden gedefinieerd, zodat vermenging van gezondheidsgegevens zo veel als mogelijk wordt voorkomen.	Optioneel	Optioneel

Overige wijzigingen	Impact DVP	Impact DVZA
Herstructurering van 'Architectuur en technische specificaties' Dit onderdeel van het afsprakenstelsel is flink onder handen genomen om de leesbaarheid en bruikbaarheid voor deelnemers te vergroten. Wijzigingen die zijn doorgevoerd: Het afsprakenstelsel is opgedeeld in de (MedMij Afsprakenstelsel 2.2.1) MedMij Core en (MedMij Afsprakenstelsel 2.2.1) MedMij Extensies. De MedMij Core bevat die onderwerpen die essentieel zijn voor het in de regie stellen van Personen over de eigen gezondheidsgegevens. MedMij Extensies vormen een uitbreiding op de Core. De functies (MedMij Afsprakenstelsel 2.2.1) Verzamelen en Delen zijn onderdeel van de (MedMij Afsprakenstelsel 2.2.1) MedMij Core. Daarentegen zijn de functies Abonneren en Notificeren onderdeel van een Extensie, namelijk (MedMij Afsprakenstelsel 2.2.1) Extensie Abonneren. De structuur van de onderwerpen is aangepast naar Rollen, Functies en gegevens, Verantwoordelijkheden. De focus van MedMij is breder dan alleen zorg. Daarom wordt in de (MedMij Afsprakenstelsel 2.2.1) MedMij Core en (MedMij Afsprakenstelsel 2.2.1) MedMij Extensies niet meer gesproken over zorg, maar is dit als een los domein toegevoegd (zie (MedMij Afsprakenstelsel 2.2.1) Zorg). Hiervoor is een aantal wijzigingen doorgevoerd in het rollenmodel van de (MedMij Afsprakenstelsel 2.2.1) MedMij Core en (MedMij Afsprakenstelsel 2.2.1) MedMij Extensies, namelijk: Zorggebruiker → Persoon Zorgaanbieder → Aanbieder Dienstverlener zorgaanbieder → Dienstverlener aanbieder Het rollenmodel is aangepast: De architectuur van het afsprakenstelsel is nu gebaseerd op de drie basislagen van enterprise architectuur, namelijk Business, Applicatie en Technologie. De vierde laag, oftewel de datalaag, wordt gevormd door de afspraken betreffende de gegevensdiensten. De laag Juridica is vervallen in de beschrijvingen, een aantal rollen is overgenomen in de businesslaag Op de businesslaag is een aantal wijzigingen doorgevoerd: Stichting MedMij is generiek beschreven als Eigenaar MedMij. De rollen Uitgever, Bron en Lezer zijn verwijderd. In plaats hiervan wordt gewerkt met de bovenliggende rollen, namelijk Dienstverlener persoon en Dienstverlener aanbieder. De rollen Uitgever, Bron en Lezer zorgden voor discussie en onduidelijkheid. Door deze uit het afsprakenstelsel te halen is getracht de leesbaarheid en bruikbaarheid te verhogen. De verantwoordelijkheden uit de businesslaag (voorheen Proces en Informatie) zijn met een gele achtergrond weergegeven. De verantwoordelijkheden uit de applicatielaag hebben een blauw achtergrond en voor de technologielaag is groen gebruikt. Op de applicatielaag is een aantal wijzigingen doorgevoerd: PGO Presenter, PGO User Agent, OAuth User Agent en Authentication User Agent zijn samengevoegd tot User Agent. De scheiding van deze twee rollen leverde onduidelijkheid bij Deelnemers en de meerwaarde van de scheiding was nihil. PGO Server is hernoemd naar DVP Server. Hoewel DVP en PGO nauw gekoppeld zijn, richt MedMij zich op de DVP-rol en niet op de gehele PGO. Op de technologielaag is een aantal wijzigingen doorgevoerd: Omdat de rol van Internet nergens duidelijk als rol beschreven wordt, is besloten deze niet meer als rol terug te laten komen. Uit verschillende verantwoordelijkheden is te herleiden is dat Internet het achterliggende netwerk is In plaats van MedMij Stelselnode, PGO Node en ZA Node is gekozen voor een opdeling tussen Backchannel Node en Frontchannel Node, om zo meer duidelijkheid te kunnen geven over de verschillen tussen backchannel en frontchannel. PKIoverheid TSP wordt niet meer als rol getoond in het rollenmodel. De reden hiervoor is dat MedMij gebruikmaakt van het stelsel van PKIoverheid, maar dat PKIoverheid zelf als partij geen rol heeft in het afsprakenstelsel. In de verantwoordelijkheden wordt wel verwezen naar PKIoverheid en staat beschreven hoe de certificaten gebruikt moeten worden. Alle verantwoordelijkheden hebben een unieke code gekregen, waarmee eenvoudiger gerefereerd kan worden aan deze verantwoordelijkheden. De mapping van 1.4.0 naar 1.5.0 is in deze changelog te vinden.	Geen	Geen
Omdat Zorg het enige domein is dat op dit moment door het afsprakenstelsel ondersteund wordt, is een aantal onderdelen van het afspraken nog niet herzien. Dit moet uitgevoerd worden zodra een nieuw domein wordt toegevoegd. Het gaat hierbij voornamelijk om juridische onderdelen: (MedMij Afsprakenstelsel 2.2.1) Juridische context (MedMij Afsprakenstelsel 2.2.1) Juridisch kader (MedMij Afsprakenstelsel 2.2.1) Overeenkomsten en rechtsrelaties (MedMij Afsprakenstelsel 2.2.1) Toelichting verwerkingsverantwoordelijkheid (MedMij Afsprakenstelsel 2.2.1) Informatiemodellen (MedMij Afsprakenstelsel 2.2.1) Metamodel (MedMij Afsprakenstelsel 2.2.1) Logische modellen (MedMij Afsprakenstelsel 2.2.1) XML-schema's (MedMij Afsprakenstelsel 2.2.1) XML-bestanden voor lijsten (MedMij Afsprakenstelsel 2.2.1) Communicatie Toestemmingsverklaring (MedMij Afsprakenstelsel 2.2.1) Toestemmingsverklaring, Abonneren Bevestigingsverklaring Beëindigingsverklaring Abonnement (MedMij Afsprakenstelsel 2.2.1) Deelnemersovereenkomsten (MedMij Afsprakenstelsel 2.2.1) Deelnemersovereenkomst Dienstverlener persoon (MedMij Afsprakenstelsel 2.2.1) Deelnemersovereenkomst Dienstverlener aanbieder (MedMij Afsprakenstelsel 2.2.1) Toetreding (MedMij Afsprakenstelsel 2.2.1) Toetredingsbeleid (MedMij Afsprakenstelsel 2.2.1) Intentieverklaringen (MedMij Afsprakenstelsel 2.2.1) Intentieverklaring Dienstverlener persoon (MedMij Afsprakenstelsel 2.2.1) Intentieverklaring Dienstverlener zorgaanbieder (MedMij Afsprakenstelsel 2.2.1) Modelverwerkersovereenkomst	Geen	Geen
Het publiceren van gegevensdiensten wordt zoveel als mogelijk gecombineerd met de release van een nieuwe versie van het afsprakenstelsel.	Geen	Geen
De HTML en CSS-bestanden geven een indicatie over wat de schermen moeten tonen. Beschreven is nu dat het niet verplicht is deze HTML en CSS te volgen.	Geen	Geen

Browser not supported