1. Inleiding

De Aanbieder heeft een rol in het MedMij netwerk, de Aanbieder is namelijk verwerkingsverantwoordelijke van de gegevens over de Persoon. Deze rol/verantwoordelijkheid is minimaal verankerd in het afsprakenstelsel. Het wordt benoemd, maar verder is er geen relatie tussen MedMij en de Aanbieders. Hierdoor kan er vanuit MedMij geen handhaving plaatsvinden op het niveau van de aanbieder. MedMij kan de Aanbieder niet direct aanspreken bij mogelijke problemen, omdat er geen overeenkomst is. Dit verloopt via de partijen waarmee MedMij wel een overeenkomst heeft, in dit geval met de Dienstverlener aanbieder. De Dienstverlener aanbieder is wel in direct contact met de Aanbieder.

2. Gekoppeld aan Epic

Deze uitwerking is gekoppeld aan Epic AF-1264.

3. Problemen

De volgende problemen worden ondervonden, waar de rol van de Aanbieder onderdeel van uitmaakt. In al deze gevallen kan MedMij schakelen met de verantwoordelijke Dienstverlener aanbieder, maar het is daarna aan de Dienstverlener aanbieder om dit ook bij de (zorg)Aanbieder neer te leggen. Dit wordt door een aantal Dienstverleners aanbieder ervaren als een onwenselijke afhankelijkheid.

3.1. Identiteit / Authenticiteit van de Aanbieder

In het gebruikte 4-corner model, hebben de Persoon en Aanbieder geen direct contact met elkaar betreffende de gegevensuitwisseling. In plaats hiervan wordt er gebruikgemaakt van Dienstverlener persoon en de Dienstverlener aanbieder. Door dit model kunnen Persoon en Aanbieder elkaar niet authenticeren, maar zijn zij aangewezen op de betrouwbaarheid van tussenliggende partijen.

3.2. Aansluitingsproces Aanbieder-gegevensdienst

Een Dienstverlener aanbieder kan een combinaties van Aanbieders en gegevensdiensten beschikbaar stellen, zonder dat de Aanbieder hier zelf weet van heeft. Om dit te voorkomen moet de Dienstverlener aanbieder een bewijs kunnen overleggen namens de Aanbieder te mogen werken. Hier wordt niet altijd op gecontroleerd.

3.3. Functioneel gebruik minimaal aan te sturen

Doordat alleen de Dienstverleners (persoon en aanbieder) deelnemer zijn bij MedMij, kan er vooral gestuurd worden op de technische implementatie van interfaces. Hiermee wordt bewezen dat uitwisseling technisch haalbaar is, maar is daadwerkelijk gebruik van de mogelijkheden tot uitwisseling niet gegarandeerd. In de huidige vorm heeft MedMij minimale mogelijkheden om het functioneel gebruik te stimuleren. De vraag is of de rol van de Aanbieder moet worden uitgebreid, zodat MedMij meer handvatten krijgt om de stimulans vorm te geven.

3.4. Technische beschikbaarheid achterliggende systemen

Verstoringen in de systemen van de Aanbieder resulteren in een beperking van gegevensuitwisseling op het MedMij netwerk. Doordat MedMij geen direct contact heeft met de Aanbieder, is het in de huidige vorm aan de Dienstverlener aanbieder om dit op te merken, hierover te communiceren en de Aanbieder op de disfunctie te wijzen. MedMij heeft hierop geen inzicht en ook geen mogelijkheden het probleem bij de bron aan te pakken. Voor dit probleem is geen uitzondering beschreven, waardoor vanuit het MedMij afsprakenstelsel niet duidelijk is hoe met deze situaties om te gaan.

3.5. Functionele beschikbaarheid gegevens

De huidige verantwoordelijkheden geven ruimte aan een Dienstverlener aanbieder om een combinatie van aanbieder en gegevensdienst op de aanbiederslijst te plaatsen, terwijl de Aanbieder gegevensuitwisseling weigert. De Aanbieder kan bijvoorbeeld in zijn xIS per patiënt kiezen om gegevensuitwisseling weigeren. Als een Aanbieder uitwisseling voor alle patiënten weigert, is in theorie uitwisseling mogelijk. In de praktijk blijkt echter altijd dat de voorgelegde toestemmingsverklaring niet wordt afgegeven. De Dienstverlener aanbieder is gekwalificeerd en geaccepteerd, maar in productie blijkt dat door toedoen van de Aanbieder gegevensuitwisseling niet niet tot stand komt. De Dienstverlener aanbieder zal de Dienstverlener persoon laten weten dat het verzoek tot uitwisseling niet wordt ingewilligd en de flow wordt gestopt.

3.6. Datakwaliteit

3.6.1. Foutief gebruik

Door foutief gebruik van velden in de XIS, of onvoldoende inzichtelijk is hoe en welke gegevens nu ook met PGO-gebruikers worden gedeeld, kunnen datalekken ontstaan. Zo is bijvoorbeeld al een privételefoonnummer bij patiënten terecht gekomen. De aanbieder had een privénummer als calamiteitennummer opgegeven. Waar eerder alleen andere aanbieders inzage hadden in dit gegeven, werd dit nu ook naar de patiënten gestuurd. Hoewel het de vraag is of MedMij hier verantwoordelijk voor is, wil MedMij graag de mogelijkheid hebben dit bij de Aanbieder te escaleren. MedMij heeft echter geen escalatiekanaal bij de aanbieder en daarmee geen directe mogelijkheid dit soort misstanden te melden.

3.6.2. Onvoldoende kwaliteit

Als de gegevens in een XIS van een onvoldoende kwaliteit zijn, worden gegevens mogelijk onbruikbaar voor de persoon of andere aanbieder. Uitwisseling is in dit geval wel mogelijk, maar de toepasbaarheid van gegevens is laag. MedMij kan de aanbieder hier nu niet op aanspreken. Hoewel het de vraag is of MedMij hier verantwoordelijk voor is, wil MedMij graag de mogelijkheid hebben dit bij de Aanbieder te escaleren. MedMij heeft echter geen escalatiekanaal bij de aanbieder en daarmee geen directe mogelijkheid dit soort misstanden te melden.

4. Eerste ideeën

4.1. Verantwoordelijkheid blijft bij de Dienstverlener aanbieder

4.1.1. Alles blijft hetzelfde

Hoewel de situatie door een aantal partijen als problematisch wordt gezien, kan gekozen worden niets te veranderen. In dit geval blijft de Dienstverlener aanbieder voor MedMij en haar Deelnemers het aanspreekpunt richting de Aanbieders. Indien contact met een Aanbieder gewenst is, moet MedMij dit via de Dienstverlener aanbieder spelen.

Voordelen:

Huidige situatie, en daarmee de rollen in het MedMij afsprakenstelsel, blijven onaangepast. De verantwoordelijkheden blijven gelijk.
MedMij heeft contact met een beperkt aantal partijen, namelijk de Dienstverleners. Contact tussen MedMij en Aanbieders verloopt via de Dienstverlener aanbieder.

Nadelen:

Extra communicatielijn naar de Aanbieders, terwijl soms snelle communicatie gewenst is.
Aanbieders hebben geen overeenkomst met MedMij en daarom geen verantwoordelijkheden binnen het afsprakenstelsel. MedMij kan Aanbieders dan ook niet aanspreken op bepaalde verantwoordelijkheden.

4.1.2. Nieuwe mogelijkheden directe communicatie met aanbieder

Voor bepaalde zaken is het gewenst dat MedMij direct kan schakelen met Aanbieders in plaats van met de Dienstverlener aanbieder. Hiervoor heeft MedMij bepaalde contactgegevens nodig bij een aangeboden gegevensdienst. Hoewel er geen overeenkomst met de Aanbieders is, en daarmee dus geen verantwoordelijkheden volgens MedMij, kan MedMij de Aanbieder wel attenderen op bijvoorbeeld het disfunctioneren van de systemen. Hiervoor moet MedMij wel de juiste contactgegevens krijgen betreffende de Aanbieder. De Dienstverlener aanbieder krijgt de verantwoordelijkheid deze gegevens op te geven. Misschien is het mogelijk de Aanbieder zaken te laten verifiëren.

Voordelen:

Rollen en bestaande verantwoordelijkheden worden niet aangepast / verlegd naar een andere rol.
MedMij krijgt de mogelijkheid te escaleren via de juiste kanalen.
MedMij kan contact met de Aanbieder opnemen, op het moment dat een gegevensdienst wordt geregistreerd. Bijvoorbeeld door een e-mail te sturen ter verificatie. Een e-mail waarin de Aanbieder wordt gevraagd te reageren als de gegevens niet kloppen.

Nadelen:

Nieuwe verantwoordelijkheden voor de Aanbieder.
Veel communicatie gaat nog steeds via de Aanbieder.

4.2. Certificering van de aanbieder

Naast de huidige certificering kunnen ook Aanbieders gecertificeerd worden, of eigenlijk de gegevensdienst die voor een Aanbieder op de Aanbiederslijst staat. Bijvoorbeeld als in productie wordt bewezen dat er voldaan wordt aan minimale eisen voor uitwisseling, krijgt de combinatie tussen Aanbieder en gegevensdienst een certificaat. Om dit na te gaan kan gebruikgemaakt worden van monitoring en/of gebruiksrapporten. Deze moeten zo ingericht worden dat de vereisten gemeten kunnen worden. Gegevensdiensten die langere (nog af te spreken) tijd niet aan de eisen voldoen, worden van de Aanbiederslijst afgehaald.

Voordelen:

In één oog opslag wordt gezien of een gegevensdienst (van een aanbieder) succesvolle uitwisseling heeft of niet.
Aanbieders krijgen geen grotere rol in het afsprakenstelsel, maar kunnen wel laten zien dat zij uitwisseling ondersteunen betreffende MedMij.
MedMij krijgt de mogelijkheid te sturen op daadwerkelijke uitwisseling.

Nadelen:

Monitoring moet goed ingeregeld worden, waarbij de verkregen data van een hoog betrouwbaarheidsniveau is.

4.3. Aanbieder als deelnemer van MedMij

Om de Aanbieder echt verantwoordelijkheden te kunnen geven en hierop te sturen, moet de Aanbieder een grotere rol krijgen in het afsprakenstelsel. Bijvoorbeeld de rol van Deelnemer. Maar, wat dit betekent voor de andere rollen in het afsprakenstelsel, moet breder onderzocht worden. Dit is meer een strategische vraag.

5. Breder perspectief

Naast de genoemde problemen raakt dit onderwerp ook andere zaken.

5.1. De aanbieder bij modules

Zoals beschreven in RFC0026 Modules wordt er een onderverdeling gemaakt in drie typen modules, waarbij het eerste type bestaat uit aanbiedermodules. Dit type modules bestaat uit functionaliteiten die door aanbieders wordt geleverd aan de (zorg)gebruikers, waarbij de rol van de aanbieder verandert. In de basis is de aanbieder bijvoorbeeld de zorgaanbieder, maar nu wordt deze partij ook de aanbieder van digitale functionaliteiten. Een voorbeeld is het portaal van een ziekenhuis. Vanuit dit portaal biedt het ziekenhuis bepaalde functionaliteiten, die ook vanuit een PGO opgestart kunnen worden.

Zorgaanbieder is een specialisatie op de algemene rol aanbieder. Met modules wordt moduleaanbieder mogelijk de tweede specialisatie van aanbieder. Een nieuwe, op zichzelf staande, rol die eigen verantwoordelijkheden krijgt.

5.2. Samenwerkingsverbanden

Steeds vaker hebben we te maken met samenwerkingsverbanden tussen verschillende zorgaanbieders, die gezamenlijk in één achterliggend systeem werken. Dus kunnen modules zijn, maar vaak hebben we te maken met het gezamenlijke gebruik van een XIS. De gegevens worden door meerdere aanbieders tezamen beheerd, waardoor niet direct duidelijk is waar de gegevens verzameld moeten worden. Hierbij kan gedacht worden aan een nieuwe specialisatie van de rol aanbieder in het afsprakenstelsel, met eigen verantwoordelijkheden, die nauw verwant zijn aan die van de huidige rol aanbieder. Een samenwerkingsverband wordt in dit geval zelf gezien als aanbieder en kan zo via een DVA de gegevensdiensten aanbieden. Een persoon hoeft dan niet bij de individuele zorgaanbieders gegevens te verzamelen, maar kan dit in één keer doen bij het samenwerkingsverband. Dit onderwerp moet verder worden uitgewerkt.

5.3. Architectuur volgens Twiin

Bij Twiin zijn Aanbieders deelnemer van het afsprakenstelsel en kunnen leveranciers gecertificeerd worden. Een andere manier van werken, waarbij de rol van de aanbieder wordt vergroot.

Browser not supported