Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Opmerking vooraf

Enkele van de in deze RFC gebruikte termen zijn kandidaat voor aanpassing, als gevolg van RFC0021 en RFC0026. In de tekst van deze RFC gebruiken we niettemin vooralsnog de termen uit release 1.2.0 van het MedMij Afsprakenstelsel. Het gaat om bijvoorbeeld:

  • Zorgaanbieder (en nog niet Aanbieder)
  • Zorgaanbiedersnaam (en nog niet Aanbiedersnaam)
  • Zorgaanbiedersnamenbeleid (en nog niet Aanbiedersnamenbeleid)
  • Zorgaanbiederslijst (en nog niet Aanbod)
  • Gegevensdiensten (en nog niet Diensten, inclusief Modulediensten)

Deze tekst is aangepast op de opmerkingen die gemaakt zijn in de consultatiesessie van 10 juli 2020.

Waarom is deze RFC nodig?

PGO-gebruikers hebben behoefte aan het goed kunnen vinden van de Zorgaanbieders waarvan zij gezondheidsinformatie willen verzamelen of waarmee zij gezondheidsinformatie willen delen. In het MedMij Afsprakenstelsel is de Zorgaanbiedersnaam het enige kenmerk van een Zorgaanbieder waarmee zij dat kunnen. Ook al bevordert het Zorgaanbiedersnamenbeleid de herkenbaarheid van de Zorgaanbieder in diens Zorgaanbiedernaam, toch spreekt de Zorgaanbiedersnaam niet zomaar vanzelf voor de Persoon. Om te kunnen vaststellen dat een Zorgaanbiedersnaam inderdaad staat voor de Zorgaanbieder die zij zoeken, hebben PGO-gebruikers behoefte om Zorgaanbieders te kunnen herkennen op andere kenmerken dan het MedMij Afsprakenstelsel biedt.

Vindbaarheid is om te beginnen een verantwoordelijkheid van de partij die gevonden moet en wil worden, in dit geval dus de Zorgaanbieder. Zoals in elk netwerk (e-mail, telefoon, het Web, bankrekeningen, fysiek verkeer, e.v.a.), is het aan de te vinden partij om diens op het netwerk toepasselijke adres vindbaar te maken bij diens afnemers. Dat geldt ook in MedMij: de Zorgaanbieders zijn verantwoordelijk zich met hun Zorgaanbiedersnaam kenbaar te maken aan de Dienstverleners persoon en hun gebruikers, de Personen. Dat laat onverlet dat het de MedMij Beheerorganisatie is die een Zorgaanbiedersnaam vaststelt.

De Zorgaanbieder kan meerdere kanalen inzetten om zijn Zorgaanbiedersnaam kenbaar te maken. Hij kan zijn Zorgaanbiedersnaam noemen op gangbare uitingen zoals zijn website, naast telefoonnummer en fysiek adres. Hij kan ook de Persoon op de hoogte brengen van de Zorgaanbiedersnaam in de context van de behandeling, bijvoorbeeld door uitingen in de wachtkamer. MedMij ontwikkelt momenteel een concept dat Zorgaanbieders daarbij kan helpen; dat is echter geen onderdeel van deze RFC.

Een volgende kanaal is via de MedMij Beheerorganisatie; zij voert immers een actuele registratie van alle Zorgaanbieders die Gegevensdiensten aanbieden op het MedMij-netwerk. Als zij deze, met toestemming van de betreffende Zorgaanbieders, ter beschikking zou stellen aan haar omgeving, biedt dat aan partijen de mogelijkheid om overzicht te creëren over alle Zorgaanbieders op MedMij en dat overzicht te combineren met andere kenmerken van Zorgaanbieders. Denk daarbij allereerst aan PGO-leveranciers, of zij nu als Dienstverlener persoon al deelnemen aan MedMij of nog niet. Maar denk ook aan de diensten van derden zoals Zorgkaart Nederland, het LRZA, het Zorgaanbiedersadresboek of, als willekeurige voorbeelden, KNGF of SportscholenCheck. Deze diensten kunnen, op hun beurt en desgewenst, ook aan PGO-leveranciers worden aangeboden. Deze RFC wil een brede maar beheerste verspreiding en bekendheid van koppelbare Zorgaanbiedersnamen mogelijk maken, ook buiten de groep van actuele Deelnemers. Dat bevordert bovendien de adoptie van MedMij bij zowel Zorgaanbieders als Personen.

Buiten deze RFC valt ook de mogelijke wens tot authenticatie van Zorgaanbieders tijdens de use cases Verzamelen, Delen en Abonneren: hoe weet de Persoon voldoende zeker dat hij de juiste Zorgaanbieder tegenover zich heeft? Vooral bij de use case Delen zou aanvullende zekerheid daarvoor gewenst kunnen zijn en wellicht geboden kunnen worden in combinatie met het geven van de Bevestigingsverklaring. Dat is in deze RFC echter niet aan de orde.

Oplossingsrichting

Tijdens het uitwerken van deze RFC zijn we tot de conclusie gekomen dat het introduceren van de nieuwe rol DienstVerlener Vindbaarheid (DVV) een grote impact heeft op het afsprakenstelsel (zowel jurisch als technisch). Deze aanpassingen zijn niet realistisch om mee te nemen in Release 1.3.0.
Er is echter wel noodzaak vanuit de Deelnemers om tot een oplossing te komen voor wat betreft de vindbaarheid van een zorgaanbieder binnen het MedMij netwerk.
Er is een praktische oplossing voorhanden als generieke voorziening die vanuit het Informatie Beraad wordt aanbevolen: de Zorg-AB oplossing
Het afsprakenstelsel zal zodanig worden aangepast dat er een generiek koppelvlak wordt aangeboden naar oplossingen als Zorg-AB, zonder nu al de nieuwe rol van DVV te introduceren. Dit biedt de Deelnemers de gelegenheid om de vindbaarheid voor zorggebruikers te verbeteren.


Om diensten mogelijk te maken die PGO-gebruikers (maar ook anderen) hun Zorgaanbieders laten vinden, stelt deze RFC voor om MedMij's Zorgaanbiedersnamen, gekoppeld aan een of meerdere identificerende kenmerken, als open data beschikbaar te stellen; ook aan partijen die geen Deelnemer zijn. Afnemers kunnen deze informatie combineren met andere adressen en kenmerken van Zorgaanbieders (zoals fysieke adressen, telefoonnummers, e-mailadressen, et cetera). De beschikbaarstelling gebeurt in de vorm van de zogenoemde Zorgaanbiederskoppellijst(ZKL). Afnemers kunnen de ZKL gebruiken voor hun vindbaarheidsdiensten aan PGO's (Dienstverleners persoon) en anderen. Dit bevordert bovendien de zichtbaarheid en het gebruik van MedMij.  

MedMij stelt de ZKL dus ter beschikking aan de brede omgeving, om innovatie en competitie op dienstverlening maximaal de ruimte te bieden. Dit past bij MedMij's netwerk-benadering en bij principes 3 en 6. De ZKL wordt niet uitgewisseld over het MedMij-netwerk zelf. Een Dienstverlener persoon kan nadrukkelijk ook zelf de ZKL afnemen en toepassen en hoeft dan voor dergelijke dienstverlening niet gebruik te maken van een derde partij. Ookin dat geval echter maakt het gebruik van de ZKL geen deel uit van de Deelnemersovereenkomst van deze Dienstverlener persoon.

Aan deze behoefte gerelateerd is de wens om het mogelijk te maken dat Zorgaanbiedersnamen wél persoonsgegevens bevatten. Vooralsnog is dat uitgesloten in het Zorgaanbiedersnamenbeleid, omdat de AVG (artikel 4, lid 1) in een beperkt aantal gevallen een bedrijfsnaam aanwijst als persoonsgegeven. Jurisprudentie ontbrak vooralsnog op dit punt. Omdat de Zorgaanbiedersnaam breed wordt verspreid in MedMij, en omdat de Stichting MedMij niet de juridische relatie had met de Zorgaanbieder om toestemming ervoor te regelen, is er destijds voor gekozen in het Zorgaanbiedersnamenbeleid persoonsgegevens uit de Zorgaanbiedersnaam te weren. Ondertussen echter bestaat er al een bescheiden juridische relatie tussen Stichting MedMij en Zorgaanbieder, inzake de Zorgaanbiederslijst: een entry in de Zorgaanbiederslijst is van de Zorgaanbieder, niet van de Dienstverlener zorgaanbieder. Bij opnemen van zo'n entry verklaart de Zorgaanbieder dat hij verwerkingsverantwoordelijkheid neemt voor het aanbieden van de betreffende Gegevensdienst. Deze verklaring kan eenvoudig worden uitgebreid met een toestemming voor het verspreiden van de Zorgaanbiedersnaam die de Zorgaanbieder voor zich laat gebruiken. Deze toestemming is ook nodig voor het  verspreiden van de ZKL. Omdat een dergelijke verklaring een voldoende juridische grondslag is voor deze verspreiding binnen en buiten MedMij, kan ook het beleid gestopt worden om persoonsgegevens uit Zorgaanbiedersnamen te weren. Het moet daarbij wel mogelijk blijven dat een Zorgaanbieder wel toestemming geeft voor gebruik van zijn Zorgaanbiedersnaam in de ZAL, maar niet in de ZKL.

1. Scheiding van doelen

De identificatie van Zorgaanbieders door Personen, bij gebruik van hun PGO, moet gescheiden worden van de identificatie van Zorgaanbieders op het MedMij-koppelvlak tussen Dienstverlener persoon en Zorgaanbieder. Deze twee hebben een wezenlijk andere reikwijdte en vertrouwenscontext en moeten daarom ook verschillende oplossingen krijgen. Deze RFC gaat alleen over het eerste. Voor het tweede, en alleen voor het tweede, is de Zorgaanbiederslijst (ZAL) als vanouds bedoeld. De ZAL wordt niet geraakt door deze RFC. Voor deze RFC beschouwen we gegevens die weliswaar een relatie hebben met die uit de ZAL, maar daarvan gescheiden zijn.

Een Zorgaanbieder-Gegevensdienst-combinatie in de ZAL betekent dat de betreffende Zorgaanbieder inhoudelijke verantwoordelijkheid neemt voor de aangeboden Gegevensdienst. Voor deze betekenis blijft de ZAL de enige autoritatieve bron, die verplicht wordt gebruikt in MedMij-verkeer op het koppelvlak tussen Dienstverlener persoon en Zorgaanbieder. Ook hiervoor geldt dus: registratie aan de bron. Aan de ZKL kan de hier beschreven betekenis juridisch gezien niet worden ontleend. In de ZKL komen bovendien gegevens voor die niet horen bij het doel van de ZAL; en andersom.

ZAL en ZKL zijn inhoudelijk gerelateerd (via de Zorgaanbiedersnamen), maar nadrukkelijk gescheiden qua doel, strekking en inhoud.

2. Inhoud van de gegevens

De ZKL is een lijst, die elke Zorgaanbiedersnaam die op een zeker moment actief is op het MedMij-netwerk, koppelt aan één of meerdere identificerende kenmerken die de Zorgaanbieder hanteert binnen het zorgdomein. De toegestane  identificerende kenmerken zijn:

Eén rechtspersoon kan ervoor kiezen in MedMij meerdere Zorgaanbieder-rollen te spelen, elk met zijn eigen Zorgaanbiedersnaam. Omdat dan de twee Zorgaanbieder-rollen door dezelfde rechtspersoon worden gespeeld, zal de ZKL hierbij dan hetzelfde identificerend kenmerk vermelden. In dat geval kunnen de twee Zorgaanbiedersnamen synoniem genoemd worden. Van belang blijft evenwel dat het om twee Zorgaanbieder-rollen gaat, die op het MedMij-netwerk niet verwisseld kunnen worden. Ook hier wordt het belang duidelijk van de scheiding die onder punt 1 is benoemd: de synonymie is niet aan de orde op het MedMij-koppelvlak, maar alleen op het user interface voor de Persoon.

De keuze voor OIN/HRN houdt MedMij open voor zoveel mogelijk Nederlandse rechtspersonen om op het MedMij-netwerk Gegevensdiensten te gaan aanbieden. Het voorkomt bovendien dat identificatienummers met beperktere (bijvoorbeeld sectorale) reikwijdte, of bedoeld voor specifiekere doeleinden en toepassingen, courant worden op het MedMij-netwerk. Dat zou binnen de gelederen van MedMij tot expliciete of impliciete benadeling of uitsluiting van bepaalde groepen Deelnemers of Zorgaanbieders kunnen leiden en het all-to-all-principe (principe 7) riskeren. Zie ook RFC0021. Bovendien zou dat MedMij onnodig afhankelijk maken van de (even specifieke) beheerders van nummers en registraties, en hun governance-structuur. Ook inzake identificatie en adressen moet MedMij niet by-design afhankelijk zijn van centrale voorzieningen (conform principe 10).

Daarnaast bevat de ZKL bij een Zorgaanbiedersnaam de Gegevensdiensten die de betreffende Zorgaanbieder op dat moment aanbiedt. Dat gebeurt dan in de vorm van het GegevensdienstId en de Weergavenaam. Aan de hand daarvan kan de Dienstverlener vindbaarheid de Catalogus raadplegen voor nadere informatie over de geboden Gegevensdiensten. In het kader van RFC0023 Harmonisering Register van Informatiestandaarden en Catalogus: informatiemodellen zal de Catalogus ook beschikbaar komen in een machine readable formaat.

De endpointadressen uit de ZAL worden in elk geval niet opgenomen in de ZKL, omdat die te allen tijde uit de ZAL moeten worden betrokken, door Dienstverleners persoon als Deelnemers in het MedMij Afsprakenstelsel. Beheer ervan buiten de specifieke MedMij-context zou de betrouwbaarheid van het functioneren van het MedMij-netwerk bedreigen. De ZKL bevat dus alleen functionele gegevens, die betekenis hebben voor de gebruiker die Zorgaanbieders wil vinden. Technische adressen blijven erbuiten.

Het staat partijen echter vrij om in hun eigen dienstverlening, maar dan buiten MedMij, alsnog het verband met zulke specifiekere identificatienummers te leggen, zeker als zij hun diensten richten op specifiekere doelgroepen waarbinnen specifiekere identificatienummers of kenmerken gangbaar zijn. Maar dergelijke keuzes en krachten horen niet op het MedMij-netwerk thuis.

3. Gebruik van de gegevens

Met behulp van de identificerende kenmerken kan de DVP of externe afnemer de Zorgaanbiedersnaam verbinden aan andere kenmerken (adressen, locaties, e.v.a.) van de betreffende rechtspersoon. Voor opname in de ZKL  worden de identificerende kenmerken betrokken uit de RnA-voorziening.

DVP's gebruiken de ZAL als vanouds én kunnen op basis van de toegevoegde identificerende kenmerken van een Zorgaanbieder externe registers raadplegen om PGO-gebruikers te ondersteunen bij het vinden van hun Zorgaanbieder.

Heeft een PGO-gebruiker eenmaal de Zorgaanbieder gevonden en de Gegevensdienst van zijn gading gekozen, gebruikt de PGO Server vervolgens de ZAL  voor het bepalen van de endpointadressen waarop die Zorgaanbieder die Gegevensdienst laat ontsluiten.

4. Juridische aspecten

In de zin van de Databankenwet, artikel 1a, is Stichting MedMij producent van de ZKL (en van de Zorgaanbiederslijst). Daarmee is de Stichting MedMij beschermd tegen het zonder diens toestemming systematisch opvragen (van niet-substantiële delen) en hergebruik (van een een substantieel deel). Voor gebruik van de ZKL moet de Dienstverlener Vindbaarheid een licentie aangaan met de Stichting MedMij.

In de zin van de AVG is de erdoor benoemde Zorgaanbieder de betrokkene bij een Zorgaanbiedersnaam, voor zover deze een persoonsgegeven is of bevat. Deze Zorgaanbieder moet, bij opname van een entry in de Zorgaanbiederslijst, toestemming geven voor de verspreiding door Stichting MedMij, binnen en buiten het MedMij-netwerk, van de Zorgaanbiedersnaam. Dat moet altijd, ook als de Zorgaanbiedersnaam geen persoonsgegevens betreft of bevat. De betrokkenheid van een Zorgaanbieder bij diens Zorgaanbiedersnaam is voor MedMij niet alleen een persoonlijke, maar ook een zakelijke betrokkenheid.

5. Context en toekomst

Bij de filosofie van MedMij past het concept van een Zorgadresinformatiestelsel (naast, niet onder MedMij). Zie voor een schets van zo'n stelsel de bijlage bij deze RFC. Open terbeschikkingstelling van de ZKL anticipeert op de totstandkoming van een dergelijk stelsel, maar is daarvan niet afhankelijk. In de bijlage staat op bladzijde 5 (voetnoot 10) al de voorziene rol van MedMij in een dergelijk stelsel, zo snel het er zou zijn, verwoord: in de rol van bron. Het handhaven van de gebruikseisen van de adresinformatie is uiteindelijk geen taak van de bron, maar van zo'n stelsel. Bij voorlopige ontstentenis van zo'n stelsel neemt MedMij (als bron van adresinformatie) voorlopig een in haar ogen geoorloofd risico door haar de gegevens open, zonder voorwaarden vooraf, ter beschikking te stellen. De problematiek rond vindbaarheid van Zorgaanbieders rechtvaardigt volgens MedMij deze keuze.

6. Gebruik van de Zorgaanbiederslijst

De verspreiding van de ZKL naar Dienstverleners vindbaarheid roept ook scherpere vragen op over de gebruiksgrenzen van de Zorgaanbiederslijst, vanwege de inhoudelijke overlap met de ZAL. In het MedMij Afsprakenstelsel moet worden opgenomen dat:

  • de Zorgaanbiederslijst (ZAL) alleen gebruikt mag worden door Dienstverleners persoon, en bovendien alleen voor doelen die direct voortvloeien uit hun verantwoordelijkheden jegens MedMij;
  • andere partijen binnen of buiten MedMij geen gebruik mogen maken van de Zorgaanbiederslijst, maar desgewenst gebruik kunnen maken van de Zorgaanbiederkoppellijst (ZKL);
  • dit onverlet laat dat een Zorgaanbieder zijn Zorgaanbiedersnaam en bijbehorende Gegevensdiensten naar eigen wens voor andere doelen kan verwerken, voor zover dat niet in strijd is met het MedMij Afsprakenstelsel;
  • dit onverlet laat dat een Dienstverlener zorgaanbieder zijn endpointadressen naar eigen wens voor andere doelen kan verwerken, voor zover dat niet in strijd is met het MedMij Afsprakenstelsel.
Aanpassing van
  • Uitgaande van het gelijktijdig — dat wil zeggen, in release 1.3.0 — verwerken van RFC0021, zullen de volgende nieuwe namen moeten worden gebruikt:
    • Aanbieder i.p.v. Zorgaanbieder
    • Aanbiedersnaam i.p.v. Zorgaanbiedersnaam
    • Aanbiedersnamenbeleid i.p.v. Zorgaanbiedersnamenbeleid
    • Aanbod i.p.v. Zorgaanbiederslijst
    • Diensten i.p.v. (alleen) Gegevensdiensten
  • Uitwisseling van de ZKL gebeurt buiten het MedMij-netwerk.
  • Op de Netwerklaag wordt toegevoegd dat de ZKL op een vast endpoint op het open Internet wordt aangeboden.
  • De informatie uit de ZKL is al grotendeels opgenomen in het Metamodel; er is voor nu gekozen om het Metamodel voor nu nog niet uit te breiden met de identificerende kenmerken. Dit om de impact op korte termijn beheersbaar te houden.
  • De ZKL moet worden opgenomen in het logische model en een technisch model (XML-schema en wellicht ook Atom en JSON) krijgen.
  • Er moet een endpoint op de MedMij Stelselnode komen waarop de ZKL kan worden opgehaald, met performancebeloften. Dat endpoint moet worden geïmplementeerd bij de MedMij Beheerorganisatie.
  • In het MedMij Afsprakenstelsel (Operationele processen) moet geregeld worden dat, als een Aanbieder zo'n combinatie laat opnemen in het Aanbod, hij er ook mee instemt dat die combinatie ter beschikking wordt via de ZKL. 
  • Uit het Aanbiedersnamenbeleid kan worden verwijderd dat in Aanbiedersnamen geen persoonsgegevens mogen voorkomen.
  • In het Juridisch kader moet de Databankenwet worden toegevoegd.
  • De gebruiksgrenzen van de Zorgaanbiederskoppellijst moeten een plaats krijgen in het MedMij Afsprakenstelsel.
Impact op rollen
  • Aanbieder (betrokkene inzake de Zorgaanbiedersnaam)
  • Stichting MedMij (producent van de ZKL in de zin van de Databankenwet en contractpartij in de licentieovereenkomst)
  • MedMij Beheer (beheerder van de ZKL)
  • Personen en Dienstverleners persoon (t.b.v. vindbaarheid van Aanbieders)
Impact op handhavingEr moet (reactief) gehandhaafd gaan worden op de licentiebepalingen.
Impact op beheer

De DVZA moet een iets uitgebreidere verklaring van de Zorgaanbieder overleggen

Impact op RnA

De ZKL moet beheerd worden. Er moet een publieke API voor de ZKL komen. 

Impact op Acceptatie

Geen, gebruik van ZKL is geen onderdeel voor deelnemers.

Gerelateerd aan (Andere RFCs, PIM issues)
Eigenaar
Implementatietermijn

Release 1.3.0

Motivatie verkorte RFC procedure (patch)

n.v.t.

...