Maak een keuze:
Zorggebruiker Zorgaanbieder Leverancier

Release 1.2.0 MedMij Afsprakenstelsel

09 december 2019

Release 1.2.0 is een major release en kent enkele veranderingen waarvoor Dienstverleners persoon (DVP) en/of Dienstverleners zorgaanbieder (DVZA) hun oplossingen zullen moeten aanpassen om compatibel te blijven (backwards-incompatible changes).

Hieronder een overzicht met de (belangrijkste) wijzigingen.

RFC’s als basis voor Releases

Met Release 1.2.0 introduceren we een nieuwe manier van werken, waarbij releases worden samengesteld op basis van requests for change (RFC). RFC’s zullen in een openbare Confluence space worden uitgewerkt, deelnemers kunnen meekijken naar (mogelijk) toekomstige ontwikkelingen.

Abonneren op Notificaties

Release 1.2.0 bevat een belangrijke uitbreiding met ‘Abonneren op Notificaties’, waardoor de efficiëntie van uitwisselingen beter wordt. Voor zowel DVP’s en DVZA’s is deze functionaliteit optioneel. Deelnemers die ervoor kiezen deze in te bouwen moeten dan wel het ‘aangaan van abonnementen’, het ‘beëindigen van abonnementen’ en het ‘verzenden en ontvangen van notificaties’ inbouwen. Ten behoeve van Abonneren op Notificaties passen we de ZAL- en de OCL-lijsten aan. Hierin zal worden aangegeven welke deelnemers Abonneren op Notificaties ondersteunen.
Abonneren op Notificaties is backwards compatible. DVP’s en DVZA’s die ervoor kiezen deze functionaliteit niet aan te bieden, hoeven geen aanpassingen aan te brengen.

Versiebeheer

Met 1.2.0 worden het versiebeheer en de uitrol van releases in het MedMij-stelsel verder uitgewerkt. Major releases krijgen een geldigheidstermijn van één jaar. Dit betekent dat binnen MedMij altijd twee releases tegelijkertijd geldig zijn en ondersteund moeten worden. Dit biedt deelnemers ruimte om nieuwe releases te implementeren en uit te rollen, zonder dat de uitwisseling ‘breekt’. Consequenties zijn wel dat de interfaces in het stelsel gekoppeld worden aan een specifieke versie, wat zal leiden tot aanpassingen van de ZAL en OCL.

Wijzigingen voor alle deelnemersrollen

Op het gebied van authenticatie wordt er een PROVES-traject met IRMA doorlopen. Op basis van de uitkomsten uit PROVES wordt ruimte gemaakt voor attribuut gebaseerde authenticatie. In volgende releases zal het mogelijk worden voor DVP’s om persoonsattributen door te geven aan DVZA’s over de eindgebruiker. Hiermee bereiken we twee doelstellingen; allereerst ontstaat de mogelijkheid om bij de DVZA authenticatie over te slaan wanneer er veel vertrouwen in de juistheid van de attributen is. Daarnaast kan de DVZA ook controleren dat de informatie verstrekt wordt aan de PGO van de juiste persoon.

Wat betreft het leveren van Managementinformatie waren hiervoor al verplichtingen opgenomen in MedMij voor DVP’s. In versie 1.2.0 worden deze ook verplicht voor DVZA’s en wordt de inhoud én het formaat van deze leveringen gespecificeerd. De leveringen zullen door de beheerorganisatie worden verwerkt in rapportages. Hiervoor zal een voorziening worden ingericht die ook de leveringen controleert en bewaakt.

Wijzigingen voor DVP’s

Zorgaanbieders krijgen de mogelijkheid hun MedMij-zorgaanbiedernaam bekend te maken bij patiënten via een QR code. Een publieke voorlichtingscampagne zal deze functie bekendheid geven. DVP’s kunnen de QR-code inlezen of in laten typen en vervolgens op basis van de code de Zorgaanbieder ‘voor selecteren’ (uit de ZAL). (Deze functionaliteit is optioneel).

DVP’s krijgen dataportabiliteit-functionaliteit die het voor eindgebruikers eenvoudiger maakt meerdere DVP’s naast elkaar te gebruiken en/of over te stappen naar een andere DVP. Een DVP moet een ‘UC lijst’ gaan bijhouden met uitgevoerde use cases bij gegevensdiensten en zorgaanbieders. Deze UC lijst kan geëxporteerd worden en weer geïmporteerd door een volgende DVP. Deze DVP kan door de acties uit de UC lijst opnieuw uit te voeren, het dossier opbouwen of verversen.

De eisen die nu aan de 2-factor authenticatie worden gesteld, worden in 1.2.0 uitgebreid en meer expliciet uitgewerkt.

Wijzigingen voor DVZA’s

In deze release wordt het leveren van Managementinformatie ook verplicht voor DVZA’s (zie hierboven).

Koppelvlakwijzigingen

Naar aanleiding van reacties van deelnemers is onderzoek gedaan naar de invulling van de controle op de geldigheid van certificaten. Op basis van de uitkomsten wordt in 1.2.0 CRL ook toegestaan naast OCSP als mechanisme hiervoor.

In 1.2.0 wordt het gebruik van een client-id in het access token request verplicht, alsook de controle hierop door de Authorisation server. In 1.1.2 is deze wijziging ingezet, deze wordt in 1.2.0 afgerond.

Het Zorgaanbiedernamenbeleid wordt aangepast en verruimd: diakritische tekens en cijfers worden toegestaan.

Bij de afhandeling van uitzondering op de Token interface 1 wordt voor de error code nu verwezen naar de OAuth-standaard in plaats van dat deze voorgeschreven wordt.

Wijziging DVP DVZA Backwards INcompatible Omschrijving
Abonneren op notificaties √* Nieuwe UC
ManagementInformatie Inhoud en schema van levering gespecificeerd.

DVZA’s moeten ook ManagementInformatie leveren.

Dataportabiliteit DVP’s moeten UC lijst kunnen exporteren én importeren.
QR-code in DVP √* QR code kunnen inlezen en/of scannen; daarna op basis van inhoud code zorgaanbieder voorsorteren in user interface.
Eisen aan 2-factor authenticatie Expliciete eisen aan 2-factor authenticatie
Koppelvlakwijzigingen
  • ClientID wordt verplicht in aanroep door DVP en controle op clientID wordt verplicht voor DVZA.
  • CRL wordt toegestaan naast OCSP.

*optionele functionaliteit

Delen