Maak een keuze:
Zorggebruiker Zorgaanbieder Leverancier

Afsprakenset release 1.1.2

11 september 2019

Voor je ligt release 1.1.2 van het MedMij Afsprakenstelsel. De afsprakenset draagt bij aan veilige, interoperabele en betrouwbare gegevensuitwisseling tussen persoonlijke gezondheidsomgevingen en informatiesystemen van zorgaanbieders. Deze afspraken moeten partijen voldoende vertrouwen en mogelijkheden geven om de onderlinge gegevensuitwisseling in de praktijk tot stand te brengen. De afsprakenset is preconcurrentieel. De afspraken zijn tot stand gekomen in samenwerking met diverse partijen in de zorg, zoals softwareleveranciers, het ministerie van Volksgezondheid, Welzijn en Sport, Patiëntenfederatie Nederland en vertegenwoordigers van zorgaanbieders. Onder andere via werkgroepen op de onderwerpen informatiestandaarden, gegevensuitwisseling/architectuur, juridisch en governance. Partijen die deelnemen aan het MedMij Afsprakenstelsel committeren zich aan de afspraken.

Kenmerken van Release 1.1.2

  1. is de opvolger van release 1.1.1.
  2. vereist geen heracceptatie maar wel aanpassingen. 
  3. Deelnemers kunnen onafhankelijk van elkaar werken aan de doorvoering van de hen betreffende wijzigingen.
  4. Deelnemers hebben tot 31 december 2019 voor de doorvoering van de hen betreffende wijzigingen.
  5. Wijzigingen zijn voor Dienstverleners zorgaanbieder omvangrijker, voor Dienstverleners persoon bescheidener.

De wijzigingen in deze 1.1.2 release moeten doorgevoerd worden door alle Deelnemers, zoals we dit samen hebben afgesproken in de deelnemersovereenkomst, maar vereisen in dit geval geen heracceptatie.

11 september 2019 – Release notes voor release 1.1.2 worden gepubliceerd op medmij.nl
4 oktober 2019 – Publicatie Release 1.1.2
31 december 2019 – Niet eerder dan na publicatie van release 1.1.2 op 4 oktober 2019 en niet later dan op 31 december 2019 worden de Deelnemers geacht de van hen gevraagde wijzigingen door te voeren.

Releasenotes release 1.1.2

Release 1.1.2 zal veranderingen omvatten waarvoor Dienstverleners persoon en/of Dienstverleners zorgaanbieder hun oplossingen (zeker of eventueel) moeten aanpassen om compatibel te blijven. Een eventuele wijziging is een wijziging die niet nodig is voor Deelnemers die het al in release 1.1.1 zo hadden gekozen te implementeren als release 1.1.2 het nu voorschrijft.

Ben je een Dienstverlener Zorgaanbieder (DVZA) ? Dan geldt onderstaande in elk geval:

Het gaat allereerst om twee zekere wijzigingen voor Dienstverleners zorgaanbieder.

  1. De Authorization Server gaat controleren of een Client wel erkend is op de Gegevensdienst waarvoor hij een authorization request doet. Daarom 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 in aankomende releases ook de mogelijkheid bieden voor zogenoemde gecontroleerde livegangen.
  2. 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.

Ben je een Dienstverlener persoon (DVP)? Dan geldt onderstaande wijziging in elk geval:

Er is één eventuele backwards-incompatible wijziging voor Dienstverleners persoon

  1. 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.

Voor alle Deelnemers (DVP en DVZA) gelden onderstaande wijzigingen.

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

  1. 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.
  2. 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 eventuele wijziging. De kans is evenwel groot dat deze zeer beperkt tot geen aanpassingen gaat vragen.
  3. 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.
  4. 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.
  5. In april van dit jaar heeft het NCSC een nieuwe versie van haar TLS-richtlijnen gepubliceerd. Het MedMij Afsprakenstelsel volgt deze. Deelnemers kunnen er u voor kiezen ook TLS 1.3 te implementeren, maar alleen als ook TLS 1.2 nog wordt geboden. Tot zover is deze wijziging 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.

Aanpassingen zonder invloed op Deelnemers in 1.1.2

Release 1.1.2 zal verder een hoeveelheid veranderingen omvatten die geen aanpassingen vereisen van de oplossingen van Dienstverleners persoon en Dienstverleners zorgaanbieder (backwards-compatible wijzigingen). 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.
    Let op: Gecontroleerde livegangen staan onder strikte voorwaarden en controle en zijn tijdelijk.
  • 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 toekomstvaste 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 Applicatielaag 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.
  • Ten aanzien van het normenkader gelden de volgende wijzigingen.
    • In plaats van in bijgevoegde documenten is het toetsingskader nu in de hoofdtekst opgenomen. Dat geldt ook voor de aanvullende auditverklaring, die in de hoofdtekst gegenereerd kan worden.
    • Toevoeging van drie normen en toevoegingen aan twee normen. Bestaande aanvullende auditverklaringen blijven echter van kracht.
    • Herordening (opdeling of samenvoeging) van enkele normen.
    • Verduidelijking van de tekst van enkele normen.
  • 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.

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 zij zelf 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.

Delen