Page tree
Skip to end of metadata
Go to start of metadata

Samenvatting

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

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 identificatienummer, als half-open data beschikbaar te stellen aan partijen — die dan voor het MedMij Afsprakenstelsel de rol van Dienstverlener vindbaarheid (DVV) spelen, maar in die rol geen Deelnemer zijn — die de ambitie hebben om deze informatie te combineren met andere adressen en kenmerken van Zorgaanbieders (zoals fysieke adressen, telefoonnummers, e-mailadressen, et cetera). Die beschikbaarstelling gebeurt in de vorm van de zogenoemde Aanbiederskoppellijst(AKL). DVV's kunnen de AKL gebruiken voor hun vindbaarheidsdiensten aan PGO's (Dienstverleners persoon) en anderen. Dit bevordert bovendien de zichtbaarheid en het gebruik van MedMij.

MedMij stelt de AKL 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 AKL wordt niet uitgewisseld over het MedMij-netwerk zelf. Een Dienstverlener persoon kan nadrukkelijk ook zelf DVV zijn en hoeft dan voor dergelijke dienstverlening niet gebruik te maken van een derde partij. Zelfs in dat geval echter maakt het gebruik van de AKL geen deel uit van de Deelnemersovereenkomst van deze Dienstverlener persoon, maar van de licentie die aan het gebruik van de AKL is verbonden (zie onder).

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 half-open verspreiden van de AKL. Ervan uitgaande dat 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.

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 AKL kan de hier beschreven betekenis juridisch gezien niet worden ontleend. In de AKL komen bovendien gegevens voor die niet horen bij het doel van de ZAL. En andersom.

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

2. Inhoud van de gegevens

De AKL is een lijst, die elke Zorgaanbiedersnaam die op een zeker moment actief is op het MedMij-netwerk, koppelt aan een standaard identificatienummer van de rechtspersoon die de betreffende Zorgaanbieder-rol speelt. Het identificatienummer is het OIN voor organisaties met een publieke taak, en het HRN voor private partijen. OIN en HRN kennen een overeenkomstige nummersystematiek, waarbij het formaat van de HRN een inperking is van dat van de OIN. Beide komen voor in de PKIoverheid-certificaten. Het OIN wordt uitgegeven door Logius, het HRN door de PKIoverheid TSP. In veel gevallen vormt het RSIN de kern van zowel OIN als HRN.

Bij Logius staat de vraag uit of het OIN inderdaad voor dit doel gebruikt mag worden en er geen in MedMij-context ongewenste bindingen met Digikoppeling ontstaan. Blijkens https://www.logius.nl/diensten/oin/aanvragen staat het (gratis) aanvragen van een OIN open voor "Afnemers" die voldoen aan de volgende definitie: “een publiekrechtelijke of privaatrechtelijke organisatie, of college of een persoon met een publieke taak of bevoegdheid, die voor de uitoefening van die publieke taak elektronisch verkeer met andere overheden en burgers en/of bedrijven wenselijk acht en daarbij gebruik kan en mag maken van één of meer Diensten van Logius.” De formulering "kan en mag" suggereert dat het OIN wel gebruikt mag worden buiten de context van een Dienst van Logius. Er is bovendien een publiek raadpleegbaar register en een API voor het OIN (https://portaal.digikoppeling.nl/registers/). In eerste reactie heeft Logius aangegeven dat het gebruik van OIN niet is gebonden aan het gebruik van DigiKoppeling of andere Logius-diensten. Als vervolgvraag staat nog uit hoe dat gegeven doorwerkt in de voorwaarden die worden toegepast bij de OIN-aanvraag.

We kunnen ervoor kiezen de AKL bij een Zorgaanbiedersnaam ook de Gegevensdiensten te laten bevatten die de betreffende Zorgaanbieder op dat moment aanbiedt. Hiermee kunnen DVV's hun dienstverlening verrijken. Dat gebeurt dan in de vorm van het GegevensdienstId, omdat daarmee de meest precieze en rijen dienstverlening kan worden geboden door Dienstverleners vindbaarheid. Wel hebben zij daarvoor dan de Catalogus nodig, die openbaar is, maar helaas nog de vorm heeft van een spreadsheet.

De endpointadressen uit de ZAL worden in elk geval niet opgenomen in de AKL, 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 AKL bevat dus alleen functionele gegevens, die betekenis hebben voor de gebruiker die Zorgaanbieders wil vinden. Technische adressen blijven erbuiten.

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 afhankelijk zijn van centrale voorzieningen (conform principe 10).

Het staat DVV's 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.

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 AKL hierbij dan hetzelfde OIN of HRN 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.

3. Gebruik van de gegevens

OIN of HRN is de sleutel waarmee de DVV de Zorgaanbiedersnaam kan verbinden aan andere kenmerken (adressen, identificatienummers e.v.a.) van de betreffende rechtspersoon. Voor opname in de AKL worden OIN en HRN betrokken uit de RnA-voorziening, maar niet opgenomen in de Zorgaanbiederslijst, omdat zij voor het functioneren van het MedMij-netwerk overbodig en zelfs nadelig is.

DVV's gebruiken de AKL in overeenstemming met de doelen en principes van het MedMij Afsprakenstelsel, en in overeenstemming met het Zorgaanbiedersnamenbeleid. Dat wordt geregeld met een gebruikslicentie.

Heeft een PGO-gebruiker eenmaal de Zorgaanbieder gevonden aan de hand van de diensten van een DVV (die de PGO-leverancier zelf kan zijn), en de Gegevensdienst van zijn gading gekozen, gebruikt de PGO Server vervolgens de ZAL als vanouds 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 AKL (en van de Zorgaanbiederslijst).

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.

Deze toestemming is in die zin generiek dat zij niet kan discrimineren tussen Dienstverleners vindbaarheid. Daarmee zou de DVV-markt namelijk minder open worden en zouden, omdat Dienstverleners persoon ook Dienstverlener vindbaarheid kunnen zijn, de PGO-markt beïnvloed kunnen worden vanuit het Zorgaanbiedersdomein.

De binding van een DVV aan het MedMij Afsprakenstelsel loopt via een gratis copy-left gebruikslicentie op de AKL, zodat een onbeperkt aantal hergebruiksschakels zich gebonden weten aan relevante aspecten van het MedMij Afsprakenstelsel, tot en met PGO-leveranciers toe. Alle gebruikers van de AKL, ook de indirecte, worden krachtens de licentie DVV's voor het MedMij Afsprakenstelsel. De daarvoor relevante aspecten van het MedMij Afsprakenstelsel worden ondergebracht is een apart deel van het MedMij Afsprakenstelsel, en kunnen dus ook wijzigen. De licentie-overeenkomst is met de Stichting MedMij en:

  • bouwt voort op de Creative Commons Naamsvermelding-GelijkDelen 4.0 Internationaal-licentie;
  • deelt elke (ook indirecte) gebruiker van de AKL of daarvan afgeleide gegevens de rol van DVV toe, zoals bedoeld in de op dat moment verplichte release van het MedMij Afsprakenstelsel;
  • bindt de DVV aan het MedMij Afsprakenstelsel door verwijzing naar een nieuw en apart deel daarvan: Aanvullende licentiebepalingen AKL.

In de Aanvullende licentiebepalingen AKL wordt o.a. bepaald dat:

  • de Stichting MedMij geen verantwoordelijkheid neemt voor de diensten en producten van DVV's, met name niet voor de kwaliteit van de door hen geleverde gegevens;
  • wordt uitgesloten dat DVV's de AKL gebruiken op wijzen die op gespannen voet staan met de doelen en principes van het MedMij Afsprakenstelsel;
  • wordt uitgesloten dat DVV's de AKL gebruikt voor andere doelen waarvoor zij bedoeld is: vindbaarheid van Aanbieders. Met name is routering en technische adressering naar of op het MedMij-netwerk verboden.
  • DVV's de rechten van de Aanbieder inzake hun adressen en kenmerken respecteren wanneer zij Aanbiedersnamen met zulke andere adressen en kenmerken combineren.

De AKL-licentie biedt geen rechten op het voeren van het MedMij-label. Dat blijft geheel voorbehouden aan Dienstverleners persoon en Dienstverleners zorgaanbieder.

Dit juridische arrangement wordt momenteel door een juridische expert beproefd. Tot op heden lijkt het adequaat en haalbaar.

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. Half-open terbeschikkingstelling van de AKL 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 moet MedMij (als bron van adresinformatie) voorlopig als handhaver optreden van de door haar ter beschikking gestelde gegevens. Bij voorkeur is dat tijdelijk en licht. Dus: geen proactief volgen van DVV's, maar wel de mogelijkheid om reactief corrigerend op te treden, op basis van de licentie-overeenkomst.

6. Gebruik van de Zorgaanbiederslijst

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

  • de Zorgaanbiederslijst 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 als Dienstverlener vindbaarheid aanspraak kunnen maken op gebruik van de AKL;
  • 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
  • Er komt een juridische rol Dienstverlener vindbaarheid (DVV) bij, in het externe domein.
  • Een Dienstverlener vindbaarheid is geen Deelnemer, hoeft niet te worden geaccepteerd of enige kwalificatie te verwerven.
  • Er is alleen een relatie tussen de Dienstverlener vindbaarheid en het MedMij-domein, voor Coördinatie. Uitwisseling van de AKL gebeurt buiten het MedMij-netwerk.
  • Op de Processen-en-Informatie-laag is er één use case: UC Ophalen AKL, tussen DVV Beheer en MedMij Beheer.
  • Op de Applicatielaag is er één use case-implementatie: UCI Ophalen AKL, met één interface, tussen DVV Registratie en MedMij Registratie. Geen OAuth.
  • Op de Netwerklaag wordt toegevoegd dat de AKL op een vast endpoint op het open Internet wordt aangeboden.
  • De informatie uit de AKL is al opgenomen in het Metamodel, maar de nieuwe rollen moeten er nog bij.
  • De AKL 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 DVV de AKL kan ophalen, 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 gesteld aan DVV's via de AKL. 
  • Uit het Aanbiedersnamenbeleid kan worden verwijderd dat in Aanbiedersnamen geen persoonsgegevens mogen voorkomen.
  • De AKL wordt aangeboden onder een licentie die
    • voortbouwt op de Creative Commons Naamsvermelding-GelijkDelen 4.0 Internationaal-licentie;
    • die elke (ook indirecte) gebruiker van de AbW of daarvan afgeleide gegevens de rol van DVV geeft in het MedMij Afsprakenstelsel;
    • gebonden wordt aan het MedMij Afsprakenstelsel door verwijzing naar een nieuw en apart deel van het MedMij Afsprakenstelsel: Aanvullende licentiebepalingen AbW. Die verwijzing betreft altijd de op enig moment verplichte versie van het MedMij Afsprakenstelsel;
  • De Aanvullende licentiebepalingen AKL kunnen dus wijzigen terwijl een DVV de AKL in gebruik heeft. Dit kan de DVV altijd een halfjaar van tevoren zien aankomen vanwege het dakpansgewijze releasebeleid van het MedMij Afsprakenstelsel.
  • In het Juridisch kader moet de Databankenwet worden toegevoegd.
  • De gebruiksgrenzen van de Zorgaanbiederslijst moeten een plaats krijgen in het MedMij Afsprakenstelsel.
Impact op rollen
  • Aanbieder (betrokkene inzake de Zorgaanbiedersnaam)
  • Stichting MedMij (producent van de AKL in de zin van de Databankenwet en contractpartij in de licentieovereenkomst)
  • MedMij Beheer (beheerder van de AKL)
  • Personen en Dienstverleners persoon (t.b.v. vindbaarheid van Aanbieders)
  • DVV (nieuwe rol)
Impact op handhavingEr moet (reactief) gehandhaafd gaan worden op de licentiebepalingen.
Impact op beheer

n.t.b.

Impact op RnA

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

Impact op Acceptatie

Geen

Gerelateerd aan (Andere RFCs, PIM issues)
Eigenaar

Paul Oude Luttighuis

Implementatietermijn

Release 1.3.0

Motivatie verkorte RFC procedure (patch)

n.v.t.

Compliance aan principes van MedMij

Principe
Principe

1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal

Positief

11 Stelselfuncties worden vanaf de start ingevuld

Neutraal

2 Dienstverleners zijn transparant over de gegevensdiensten 

Positief

12 Het afsprakenstelsel is een groeimodel

Positief

Dienstverleners concurreren op de functionaliteiten

Positief

13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders

Positief

Dienstverleners zijn aanspreekbaar door de gebruiker

Neutraal

14 Uitwisseling is een keuze

Neutraal

De persoon wisselt gegevens uit met de zorgaanbieder

Neutraal

15 Het MedMij-netwerk is gebruiksrechten-neutraal

Neutraal

MedMij spreekt alleen af wat nodig is

Positief

16 De burger regisseert zijn gezondheidsinformatie als uitgever

Neutraal

De persoon en de zorgaanbieder kiezen hun eigen dienstverlener

Neutraal

17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld

Neutraal

De dienstverleners zijn deelnemers van het afsprakenstelsel

Positief

18 Afspraken worden aantoonbaar nageleefd en gehandhaafd

Neutraal

10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling

Neutraal

19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat

Positief

Uitwerking

N.t.b.

Risico's

Omschrijf de (privacy)risico's die kunnen ontstaan als deze RFC wordt aangenomen. In het onwaarschijnlijke geval dat deze RFC's geen risico's introduceert, geef dat dan wel aan.

DreigingKansImpactMaatregelen
half-open beschikbaarheid van een Zorgaanbiedersnaam die inzake de AVG een persoonsgegeven is of bevat

gemiddeld

laag, omdat de Zorgaanbiedersnaam door de Zorgaanbieder zelf als publieke naam is gekozen
vereisen van toestemming van de Zorgaanbieder voor het verspreiden van de Zorgaanbiedersnaam, zowel binnen MedMij (in de ZAL) als daarbuiten (in de AKL)
Dienstverlener vindbaarheid koppelt verkeerde of onduidelijke kenmerken aan Zorgaanbiedersnaam en OIN, zodat een PGO-gebruiker de verkeerde Zorgaanbieder selecteert en daarmee wil gaan Verzamelen of (vooral) Delen.gemiddeldlaag, omdat de Zorgaanbieder bij Verzamelen of Delen moet vaststellen dat er een toepasselijke behandelrelatie bestaat. Als dat niet slaagt wordt er niet verzameld of gedeeld.
  • In de AKL-licentie vereisen van de Dienstverlener vindbaarheid dat hij aan een gebruiker altijd minimaal de gevelnaam van de Zorgaanbieder presenteert.
  • Wanneer er een aanpalend stelsel voor adresinformatie komt (zie bijlage), daarin kwaliteitskenmerken van deelnemers aan dat stelsel opnemen.

Bijlagen


  • No labels