Veelgestelde vragen

Voorafgaand aan de kwalificatie kan een DVZA (kandidaat-)deelnemer zelf testen op Touchstone. Dit kan zonder XIS. Een kwalificatie vindt altijd plaats in combinatie met een XIS. De voorgenomen wijzigingen zijn inzichtelijk per release per informatiestandaard. Bij elk afzonderlijk issue wordt vastgelegd wat de voorgestelde oplossing is en wat de classificatie (patch, mineur, majeur) daarvan is, de impact, en de voorgenomen publicatieversie. Hierin nemen we de inbreng van MedMij-deelnemers nadrukkelijk mee.

Over de kwalificatie naar aanleiding van een backwards incompatibele release communiceren we met de deelnemers. Hierin zal planning een belangrijk onderwerp zijn. In samenspraak met het MedMij Afsprakenstelsel wordt een geldigheidsperiode per gegevensdienst vastgesteld.

Voor de zibs geldt een eigen beheercyclus. Bij nieuwe publicaties van zibs bepalen we met betrokkenen of dit ook in de MedMij-standaarden moet worden verwerkt. Dit kan impact hebben op de kwalificatie.

De Gegevensdiensten worden ontsloten via bijbehorende usecases uit de architectuur van het MedMij Afsprakenstelsel. Zolang nieuwe Gegevensdiensten passen binnen de bestaande usecases, kunnen ze onafhankelijk van een release van het MedMij Afsprakenstelsel worden toegevoegd aan de Catalogus. Mocht voor een Gegevensdienst (een) nieuwe usecase nodig zijn, dan moet eerst deze nieuwe usecase worden toegevoegd volgens het reguliere change- en releaseproces. Pas daarna kan ook deze nieuwe Gegevensdienst worden toegevoegd aan de Catalogus.

Besluiten over de creatie, wijziging en beëindiging van een Gegevensdienst en de wijze waarop een Gegevensdienst wordt opgenomen in de Catalogus worden genomen door het bestuur van Stichting MedMij.

Ja, om die reden moeten zorginstellingen die gegevens uitwisselen via MedMij een DigiD-aansluiting hebben. Zonder deze aansluiting is gegevensuitwisseling niet mogelijk. Vanuit MedMij adviseren we om aan te sluiten op de Toegangsverleningservice (TVS), zie ook dit factsheet. Uitgebreide informatie voor zowel zorgaanbieders als leveranciers is te vinden op de website van DICTU. In bepaalde gevallen kan een bestaande DigiD aansluiting worden hergebruikt. 

Ja. Voor MedMij-deelnemers onderscheiden we verschillende rollen. Als leverancier geef je invulling aan deze rollen. Je zult dan soortgelijke bouwstenen gebruiken om deze rollen in te vullen. Denk hierbij aan autoriseren in de use case verzamelen, het opvragen van de whitelist, de ZAL en de OCL.

Je hoeft niet te concurreren op deze bouwstenen, die voor elke leverancier gelijk zijn. Je kunt versnellen door deze bouwstenen te gebruiken. MedMij is geen eigenaar van deze bouwstenen.

Deze bouwstenen staan je ter beschikking onder AGPLv3 licentie. Deze mag je in je product verwerken en doorontwikkelen, als je de doorontwikkeling (van de bouwsteen) op jouw beurt, weer deelt met de community. Je vindt de bouwstenen hier.

De specificaties van de adressen waar de lijsten opgehaald kunnen worden staan in het afsprakenstelsel bij de interfacebeschrijvingen. Het request zelf is relatief eenvoudig, namelijk een standaard HTTP-request. MedMij vereist wel dat dit via een mutual TLS-tunnel loopt.

Als je dit niet gewend bent, dan vormt dit mogelijk een uitdaging. Helaas is hiervan niet zomaar een voorbeeld te geven.

In essentie ziet een HTTP-request er zo uit:
GET /stelselnode/zorgaanbiederslijst?api=1.1.2 HTTP/1.1
Host: api.provesproject.nl
Connection: keep-alive
Pragma: no-cache
Accept: text/html,application/xhtml+xml,application/xml;
… 

In de architectuur en technische specificaties staat het volgende onder Netwerk.

"Alle certificaathouders verbinden zich aan de op hen toepasselijke eisen van het PKIoverheidstelsel." 

Onderstaande tabel vat samen hoe in de verantwoordelijkheden op deze laag de beveiligingsfuncties beveiliging, authenticatie en autorisatie worden ingericht. Het onderscheid, bij autorisatie, tussen inkomend en uitgaand verkeer is het gevolg van dat in deze twee gevallen de identificatie van de andere Node anders plaatsvindt.

Binnen MedMij worden de PKIoverheid-certificaten onder de private root niet gebruikt, maar hanteren we de standaardversie. Meer informatie vind je hier. (alleen beschikbaar met inlog op het Afsprakenstelsel).