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.

Datakwaliteit

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.

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.

Eerste ideeën

Verantwoordelijkheid blijft bij de Dienstverlener aanbieder

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.

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.

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.

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.

Breder perspectief

Naast de genoemde problemen raakt dit onderwerp ook andere zaken.

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.

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. 

Architectuur volgens Twiin

Kladblok

Aansluitvoorwaarden DVA voor aansluiten Aanbieders

uitwerken van aansluitvoorwaarden door DVA voor aanbieders te hanteren en opnemen in DAP - 

Verwijderen Aanbieders zonder gegevensuitwisseling

Scenario's

Scenario 1

Scenario 2

Scenario 3