Release 1.1.2 omvat enkele veranderingen waarvoor Dienstverleners persoon en/of Dienstverleners zorgaanbieder hun oplossingen (zeker of eventueel) zullen moeten aanpassen om compatibel te blijven (backwards-incompatible changes). Het gaat allereerst om twee zekere wijzigingen voor Dienstverleners zorgaanbieder.

• De Authorization Server gaat controleren of een Client wel erkend is op de Gegevensdienst waarvoor hij een authorization request doet. Daartoe wordt de OAuthclientlist uitgebreid met, per OAuthclient, de Gegevensdiensten waarop deze erkend is. Het XML-schema van de OAuthclientlist wordt dus aangepast. Gedurende de beperkte invoeringsperiode zijn de huidige en de nieuwe OAuthclientlist beide beschikbaar. Deze wijziging gaat ook de mogelijkheid bieden voor zogenoemde gecontroleerde livegangen.
• In release 1.1.2 gaan Authorization Servers ook access token requests accepteren met een client_id. Indien aanwezig gaan zij die ook controleren. In release 1.1.1 was de client_id  verplicht afwezig in de access token request. Deze stap is een voorbereiding op de uiteindelijke verplichtstelling, in een volgende release, van de client_id in de access token request.

Verder is er één eventuele backwards-incompatible wijziging voor Dienstverleners persoon.

• Ter bestrijding van de "open redirector" kwetsbaarheid wordt het verboden om URI's in de state-parameter op te nemen. Dienstverleners persoon die dat eventueel wel hadden gedaan zullen deze moeten verwijderen.

Daarnaast zijn er vijf backwards-incompatible wijzigingen, één zekere en vier eventuele, voor zowel Dienstverleners persoon als Dienstverleners zorgaanbieder.

• De interfaces voor het ophalen van de Gegevensdienstnamenlijst, OAuthclientlist, Whitelist en Zorgaanbiederslijst zullen geversioneerd worden. Hiermee wordt de invoering van wijzigingen in de XML-schema's van die lijsten vereenvoudigd, omdat tijdens migraties meerdere interfaces (en dus XML-schema's) naast elkaar in gebruik kunnen zijn. De bovenstaande wijziging inzake de OAuthclientlist geldt als eerste voorbeeld. Aan de bevraging van de lijsten zal een query-parameter met een releasenummer toegevoegd worden.
• De state-parameter is verplicht in de authorization request. Dat is in release 1.1.1 ook al zo, maar stond niet helder in de tekst verwoord. Omdat we ermee rekening houden dat daardoor de state-parameter niet overal is opgenomen, zien we het als een change. De kans is evenwel groot dat deze zeer beperkt tot geen aanpassingen gaat vragen.
• Als in de authorization request een ongeldige redirect_uri wordt meegegeven is dat niet alleen een fout, maar moet deze fout bovendien niet via die ongeldige redirect_uri worden teruggemeld, maar direct aan de eindgebruiker. Dit stond nog niet vermeld in release 1.1.1, maar is desondanks bij menige Deelnemer al wel zo geïmplementeerd. We verwachten ook hier daarom beperkte wijzigingen.
• In release 1.1.2 wordt voor alle htpps-verbindingen de daarvoor door IANA aangewezen poort (443) verplicht. In release 1.1.1 bestonden nog mogelijkheden om andere poortnummers te kiezen, ook bijvoorbeeld voor de endpointadressen in de Zorgaanbiederslijst, hoewel daarvan amper of geheel geen gebruik is gemaakt. Waar in release 1.1.2 in de Zorgaanbiederslijst nog poortnummers voorkomen, zal dat altijd het IANA-poortnummer zijn. 
• In april van dit jaar heeft het NCSC een nieuwe versie van haar TLS-richtlijnen gepubliceerd. Het MedMij Afsprakenstelsel volgt deze. Deelnemers kunnen er nu voor kiezen ook TLS 1.3 te implementeren, maar alleen als ook TLS 1.2 nog wordt geboden. Tot zover is deze change backwards-compatible. Sommige TLS-algoritmen hebben in de nieuwe TLS-richtlijnen echter hun classificatie "goed" verloren. Mochten Deelnemers deze in gebruik hebben, moeten zij worden afgevoerd.

Verder zal release 1.1.2 een hoeveelheid veranderingen omvatten die geen aanpassingen vereisen van de oplossingen van Dienstverleners persoon en Dienstverleners zorgaanbieder (backwards-compatible changes). Het gaat om de volgende.

• Het gaat mogelijk worden dat een groep van (minstens één) Dienstverleners persoon en (minstens één) Dienstverleners Zorgaanbieder zich tijdelijk organiseren in een zogenoemde 'gecontroleerde livegang'. Dienstverleners zorgaanbieder betrekken een afgebakende groep Zorgaanbieders, hun klanten. Dienstverleners persoon kunnen naar keuze een afgebakende groep Personen daarbij organiseren. Elke gecontroleerde livegang gaat om één geldige Gegevensdienst, die in de Catalogus staat. In een gecontroleerde livegang kan het aanbieden van die Gegevensdienst door de genoemde Zorgaanbieders beproefd worden op het live MedMij-netwerk, gedurende een korte periode, zodanig dat alleen de deelnemende Dienstverleners persoon deze Gegevensdienst ook van deze Zorgaanbieders kunnen afnemen. Het doel is dat daarna de betreffende Zorgaanbieders volledig live gaan op die Gegevensdienst. Gecontroleerde livegangen worden mogelijk gemaakt zonder enige technische of functionele ingreep, maar enkel door een administratieve ingreep, namelijk door een tijdelijke administratieve kopie te maken van de betreffende Gegevensdienst.
• In release 1.1.2 wordt naast het SAML-koppelvlak ook het CGI-koppelvlak van DigiD toegestaan, onder de kanttekening dat voor DigiD het SAML-koppelvlak de toekomstvast keuze is.
• Op drie punten is de beschrijving van de flow aan het eind van UCI Verzamelen en UCI Delen verbeterd: het is mogelijk om onmiddellijk na ontvangst van een access token tot gebruikersinteractie over te gaan, na optreden van een uitzondering hoeft de herhaling niet onderbroken te worden en er kan sprake zijn van herhaalde resource requests in meer situaties dan oorspronkelijk vermeld.
• De ordening van de verantwoordelijkheden op de Applicatie-laag heeft een ingrijpend nieuwe opzet gekregen, langs de lijnen van interfaces. Dit verbetert het overzicht en opent de mogelijkheid voor versionering van interfaces in de toekomst. Tegelijkertijd zijn de adresseringsverantwoordelijkheden verhelderd.
• In het normenkader:
  • is het toetsingskader nu in de hoofdtekst opgenomen, in plaats van in bijgevoegde documenten. Dat geldt ook voor de aanvullende auditverklaring, die in de hoofdtekst gegenereerd kan worden;
  • zijn drie normen toegevoegd en hebben drie normen toevoegingen gekregen. Bestaande aanvullende auditverklaringen blijven echter van kracht;
  • zijn enkele normen (door opdeling of samenvoeging) herordend;
  • is de tekst van enkele normen verduidelijkt;
• De beschrijving van de (limitatief) toegestane informatie-inhoud van het access token is verbeterd. Toegelicht is bovendien dat, en waarom, OpenID Connect niet wordt toegepast op het koppelvlak van UCI Verzamelen en UCI Delen.
• Toegelicht is dat, en waarom, OCSP Stapling vooralsnog niet wordt toegepast.
• Toegelicht is wat met een "full" redirect_uri wordt bedoeld.
• Een keur aan kleinere tekstuele verbeteringen is doorgevoerd.

Release 1.1.2 wordt op 4 oktober 2019 gepubliceerd. Deelnemers worden geacht de op hen betrekking hebbende wijzigingen door te voeren, niet eerder dan na publicatie en niet later dan op 31 december 2019.

Dienstverleners Zorgaanbieder dragen zelf de verantwoordelijkheid om, wanneer zij eerder dan 31 december 2019 deelnemen aan een gecontroleerde livegang, tijdig de eerste hierboven genoemde wijziging te hebben doorgevoerd: controle van authorization request op basis van nieuwe OAuthclientlist. Zo lopen zijzelf en de andere partijen in die gecontroleerde livegang niet het risico onbedoelde PGO Servers toegang tot de (kopie-)Gegevensdienst van de gecontroleerde livegang te geven.