Tijdens de expertsessie en veldraad zijn twee kanttekeningen gemaakt bij het voorstel:
De wens blijft bestaan dat partijen opslag bieden zodat personen een levensloopdossier kunnen opbouwen. Er bestaat een zorg dat er geen partijen opslag van het dossier gaan bieden waardoor een “levensloopdossier” niet meer is op te bouwen door de gebruiker. MedMij onderzoekt de mogelijkheden om borgen dat deze mogelijkheid blijft bestaan. Overigens heeft MedMij geen signalen dat een significant deel van de huidige PGO’s wil stoppen met het bieden van opslag. Wel is het zo dat er PGO’s zijn die hier meer vrijheid in willen hebben.
Mogelijk geeft de wijziging een extra belasting op de DVA omdat PGO’s alle informatie opnieuw ophalen.
Daarom zal MedMij deze wijziging als Release Candidate publiceren om in pilotsetting ervaring op te doen met deze wijziging. Zo kunnen we zien in hoeverre deelnemers er gebruik van willen maken en wat het effect is op de DVA’s. Tevens kan de pilot beeldbeschikbaarheid starten op basis van deze specificaties.
Omschrijving Changelog, met daarin:
De pagina’s die verplichte dossiervoering beschrijven zijn gewijzigd:
Zodat dossiervoering in de basis optioneel is.
Voor functionaliteiten en samenhangende functionaliteiten waarbij dossiervoering verplicht is, behouden we de verplichting.
Impact op:
DVP
DVA
Geen van beiden
Te informeren Stakeholders
Acceptatie
R&A beheer
Regie
CCDA
Security
Relatiebeheer
Communicatie
MM Loket
Stichting MM
Nictiz
Moeten afbeeldingen/mockups aangepast worden?
Ja
Nee
Aan te passen versies afsprakenstelsel
V2.2.6
Classificatie
Patch
Minor
Major
N.v.t i.v.m. Catalogus
Implementatie Termijn
Gerelateerde tickets (o.a. ticket van deze ticket)
Status
Staat klaar voor release in afsprakenstelsel
Verwerkt in afsprakenstelsel
Akkoord bevonden door
Product owner Afsprakenstelselteam
Architect afsprakenstelselteam
Releasemanager
MT
Uitwerking
Zet bij de locatie (en indien van toepassing bij de “In te voegen links (optioneel)”) de link naar de confluence space (bijv. MedMij Afsprakenstelsel 2), zet hier niet de link naar scroll view pagina. Is het een tabel benoem dan bij de locatie ook de rij.
Kopieer voor de oude en de nieuwe tekst ook de regel voor en na de aan te passen zin.
In de kolom “Oude tekst”, maak de verwijderde of gewijzigde stukken rood en streep ze door In de kolom “Nieuwe tekst”, geef de nieuwe stukken hebben deze blauwige/groenige kleur.
Wil je een link toevoegen maak het woord paars in de kolom “Nieuwe tekst” en zet de link in de kolom “In te voegen links (optioneel)”.
Op deze pagina staan de diagrammen behorende bij de functie Verzamelen. De oranje banen horen (conform de MedMij-huisstijl) tot het Persoonsdomein, de blauwe tot het Aanbiedersdomein.
Businesslaag
In elke voltrekking van de in het diagram beschreven flow is steeds sprake van één van elk van de genoemde rollen.
De totale procesgang van de functie Verzamelen kent de volgende stappen:
De Persoon kiest expliciet de Aanbieder, waarbij hij de informatie wenst te verzamelen uit de lijst die door Dienstverlener persoon wordt aangeboden. Het verzoek gaat naar de passende Dienstverlener aanbieder. Indien de Aanbieder gebruikmaakt van meerdere Dienstverleners Aanbieder, moet dit kenbaar gemaakt worden aan de Persoon en zal de flow per Dienstverlener Aanbieder doorlopen moeten worden .
De Dienstverlener aanbieder ontvangt een verzoek van de Persoon.
De Dienstverlener aanbieder laat de Persoon zich authenticeren en geeft autorisatie af aan de Dienstverlener persoon.
Uiterlijk na de ontvangst van het verzoek zal de Dienstverlener aanbieder ervoor instaan dat de Aanbieder voor de betreffende Gegevensdienst(en) überhaupt gezondheidsinformatie van die Persoon beschikbaar heeft, of anders de happy flow afbreken.
Bij ontvangst slaat de Dienstverlener persoon die informatie op in het persoonlijke dossier.
Mocht een Gegevensdienst waartoe de Dienstverlener persoon is geautoriseerd uit meerdere Transacties bestaan (zie hiervoor de Catalogus), dan bevraagt de Dienstverlener persoon de Dienstverlener aanbieder daarna mogelijk opnieuw voor de nog resterende Transacties. Hetzelfde geldt wanneer de Dienstverlener persoon is geautoriseerd voor meerdere Gegevensdiensten van de betreffende Aanbieder.
Bij de informatie wordt ook de meta-informatie opgeslagen die wordt bedoeld in verantwoordelijkheid core.logging.100 en core.logging.101.
Uitzonderingen op de Happy flow van de functie Verzamelen
In onderstaande tabel staan de uitzonderingssituaties beschreven. Alle worden door de Dienstverlener aanbieder ontdekt. Ten alle tijden moet voorkomen worden dat de Dienstverlener persoon informatie over het bestaan van behandelrelaties verkrijgt zonder dat daarvoor (al) toestemming is gegeven.
Op de Applicatielaag zullen, bij de implementatie van Verzamelen, deze uitzonderingen opnieuw ter sprake komen, maar nu ook met hun precieze implementatie en formaat van de foutmeldingen.
nr.
uitzondering
actie
vervolg
Verzamelen 1
Dienstverlener aanbieder vindt een ontvangen verzoek ongeldig.
Dienstverlener aanbieder informeert Dienstverlener persoon over deze uitzondering. Dienstverlener persoon informeert daarop Persoon hierover
of:
Dienstverlener aanbieder informeert de Persoon over de technische fout, zonder de Persoon automatisch te redirecten.
Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering.
Verzamelen 2
Dienstverlener aanbieder stelt op enig moment vast dat van Persoon bij Aanbieder geen gezondheidsinformatie voor die Gegevensdienst beschikbaar is. Zie de toelichting op Beschikbaarheids- en ontvankelijkheidsvoorwaarde.
Dienstverlener aanbieder informeert de Persoon dat diens verzoek geen voortgang kan vinden en noemt daarbij behorende reden.
Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering.
Verzamelen 3
Dienstverlener aanbieder kan, zelfs na autorisatie, de gezondheidsinformatie alsnog niet ter beschikking stellen aan de Dienstverlener persoon.
Dienstverlener aanbieder informeert Dienstverlener persoon over deze uitzondering. Dienstverlener persoon informeert daarop Persoon hierover, met opgave van oorzaak.
Mocht de gezondheidsinformatie deels wel (geautoriseerd) ter beschikking staan, dan kan de flow dat nog verzorgen.
Applicatielaag
Verantwoordelijkheden inzake uitzonderingen op de happy flow zijn opgenomen bij de respectievelijke interface, waar de uitzonderingen bij de functies zijn genoemd.
Opens image in full screenOpen
In elke voltrekking van de in het diagram beschreven flow is steeds sprake van één van elk van de bovenaan genoemde rollen.
De flow kent de volgende stappen:
De DVP Server start de flow door in de User Agent van de Persoon de mogelijkheid te presenteren gegevens bij een zekere Aanbieder te verzamelen. Uit de Aanbiederslijst weet de DVP Server welke Gegevensdiensten door een Aanbieder aangeboden worden en of de Aanbieder gebruik maakt van één of meerdere DVA's.
De Persoon maakt expliciet zijn selectie van Aanbieder en laat de User Agent een authorization request sturen naar de Authorization Server. Het adres van het authorization endpoint komt uit de Aanbiederslijst. De redirect_uri geeft aan waarnaartoe de Authorization Server de User Agent verderop moet redirecten (met de authorization-code). Binnen het autorisatieproces valt ook het eerst mogelijke moment waarop de Dienstverlener aanbieder moet instaan dat voor de Gegevensdienst waartoe een verzoek behoort de Aanbieder de gezondheidsgegevens beschikbaar heeft.
Nadat de Dienstverlener aanbieder een autorisatie heeft afgegeven aan de Dienstverlener persoon is de DVP Server gereed om één of meerdere verzoeken om de gezondheidsinformatie naar de Resource Server te sturen. Het adres van de juiste resource endpoints haalt hij uit de Aanbiederslijst. Hij plaatst telkens het access-token in het bericht en zorgt ervoor dat in het bericht geen BSN is opgenomen.
De Resource Server controleert bij ieder verzoek of het ontvangen token recht geeft op de gevraagde resourcesen verleent autorisatie aan de Resource Server. Dan breekt het tweede mogelijke verplichte moment aan waarop de Resource Server ervoor moet instaan dat voor de Gegevensdienst waartoe een verzoek behoort de Aanbieder de gezondheidsgegevens beschikbaar heeft. Is dat zo, dan verstuurt de Resource Server deze in een resource response naar de DVP Server.
De DVP Server bewaart de ontvangen gezondheidsinformatie in het persoonlijke dossier. De DVP Server bevraagt de Resource Server daarna mogelijk opnieuw, eventueel na nieuwe interactie met de Persoon. Zolang het access-token geldig is, kan dat.
In de regel worden bij een eenmalig gebruik van Verzamelen het authorization interface, het token interface en het resource interface allemaal aangesproken, in die volgorde. Mocht de DVP Server echter nog beschikken over een nog niet verlopen access-token voor de betreffende Aanbieder-Gegevensdienst-combinatie, dan kan het onmiddellijk het resource interface aanspreken. Bij het aanwezig zijn van een geldig refresh-token kan de DVP Server deze direct inruilen voor een access-token en hoeft de authorization interface niet aangeroepen te worden.
Bij de implementatie van de voorwaarde op beschikbaarheid bij de Aanbieder voor de te verzamelen gezondheidsgegevens is het zaak rekening te houden met privacy-vereisten. Wanneer de Dienstverlener aanbieder ten behoeve van de beschikbaarheidsvoorwaarde nieuwe gegevensverzamelingen zou aanleggen, vindt een verwerking altijd onder de verantwoordelijkheid van één Aanbieder plaats. Het combineren van verwerkingen of het onvoldoende segregeren moet worden vermeden. Afwijking hiervan is alleen mogelijk onder expliciete instructie van de Aanbieder(s) en vereist een zorgvuldige voorafgaande afweging, vanwege de daaraan verbonden privacyrisico's.
Verzamelen
Inleiding
Op deze pagina staan de diagrammen behorende bij de functie Verzamelen. De oranje banen horen (conform de MedMij-huisstijl) tot het Persoonsdomein, de blauwe tot het Aanbiedersdomein.
Businesslaag
Blokje “bewaar de gegevens, optioneel”
In elke voltrekking van de in het diagram beschreven flow is steeds sprake van één van elk van de genoemde rollen.
De totale procesgang van de functie Verzamelen kent de volgende stappen:
De Persoon kiest expliciet de Aanbieder, waarbij hij de informatie wenst te verzamelen uit de lijst die door Dienstverlener persoon wordt aangeboden. Het verzoek gaat naar de passende Dienstverlener aanbieder. Indien de Aanbieder gebruikmaakt van meerdere Dienstverleners Aanbieder, moet dit kenbaar gemaakt worden aan de Persoon en zal de flow per Dienstverlener Aanbieder doorlopen moeten worden .
De Dienstverlener aanbieder ontvangt een verzoek van de Persoon.
De Dienstverlener aanbieder laat de Persoon zich authenticeren en geeft autorisatie af aan de Dienstverlener persoon.
Uiterlijk na de ontvangst van het verzoek zal de Dienstverlener aanbieder ervoor instaan dat de Aanbieder voor de betreffende Gegevensdienst(en) überhaupt gezondheidsinformatie van die Persoon beschikbaar heeft, of anders de happy flow afbreken.
Bij ontvangst slaat dekan deDienstverlener persoon die informatie op opslaan in het persoonlijke dossier.
Mocht een Gegevensdienst waartoe de Dienstverlener persoon is geautoriseerd uit meerdere Transacties bestaan (zie hiervoor de Catalogus), dan bevraagt de Dienstverlener persoon de Dienstverlener aanbieder daarna mogelijk opnieuw voor de nog resterende Transacties. Hetzelfde geldt wanneer de Dienstverlener persoon is geautoriseerd voor meerdere Gegevensdiensten van de betreffende Aanbieder.
Bij de informatie wordt ook deDe meta-informatie,opgeslagen die wordt bedoeld in verantwoordelijkheid core.logging.100 en core.logging.101, wordt opgeslagen.
Uitzonderingen op de Happy flow van de functie Verzamelen
In onderstaande tabel staan de uitzonderingssituaties beschreven. Alle worden door de Dienstverlener aanbieder ontdekt. Ten alle tijden moet voorkomen worden dat de Dienstverlener persoon informatie over het bestaan van behandelrelaties verkrijgt zonder dat daarvoor (al) toestemming is gegeven.
Op de Applicatielaag zullen, bij de implementatie van Verzamelen, deze uitzonderingen opnieuw ter sprake komen, maar nu ook met hun precieze implementatie en formaat van de foutmeldingen.
nr.
uitzondering
actie
vervolg
Verzamelen 1
Dienstverlener aanbieder vindt een ontvangen verzoek ongeldig.
Dienstverlener aanbieder informeert Dienstverlener persoon over deze uitzondering. Dienstverlener persoon informeert daarop Persoon hierover
of:
Dienstverlener aanbieder informeert de Persoon over de technische fout, zonder de Persoon automatisch te redirecten.
Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering.
Verzamelen 2
Dienstverlener aanbieder stelt op enig moment vast dat van Persoon bij Aanbieder geen gezondheidsinformatie voor die Gegevensdienst beschikbaar is. Zie de toelichting op Beschikbaarheids- en ontvankelijkheidsvoorwaarde.
Dienstverlener aanbieder informeert de Persoon dat diens verzoek geen voortgang kan vinden en noemt daarbij behorende reden.
Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering.
Verzamelen 3
Dienstverlener aanbieder kan, zelfs na autorisatie, de gezondheidsinformatie alsnog niet ter beschikking stellen aan de Dienstverlener persoon.
Dienstverlener aanbieder informeert Dienstverlener persoon over deze uitzondering. Dienstverlener persoon informeert daarop Persoon hierover, met opgave van oorzaak.
Mocht de gezondheidsinformatie deels wel (geautoriseerd) ter beschikking staan, dan kan de flow dat nog verzorgen.
Applicatielaag
Verantwoordelijkheden inzake uitzonderingen op de happy flow zijn opgenomen bij de respectievelijke interface, waar de uitzonderingen bij de functies zijn genoemd.
Opens image in full screenOpen
Onderdeel “bewaar in dossier, optioneel”
In elke voltrekking van de in het diagram beschreven flow is steeds sprake van één van elk van de bovenaan genoemde rollen.
De flow kent de volgende stappen:
De DVP Server start de flow door in de User Agent van de Persoon de mogelijkheid te presenteren gegevens bij een zekere Aanbieder te verzamelen. Uit de Aanbiederslijst weet de DVP Server welke Gegevensdiensten door een Aanbieder aangeboden worden en of de Aanbieder gebruik maakt van één of meerdere DVA's.
De Persoon maakt expliciet zijn selectie van Aanbieder en laat de User Agent een authorization request sturen naar de Authorization Server. Het adres van het authorization endpoint komt uit de Aanbiederslijst. De redirect_uri geeft aan waarnaartoe de Authorization Server de User Agent verderop moet redirecten (met de authorization-code). Binnen het autorisatieproces valt ook het eerst mogelijke moment waarop de Dienstverlener aanbieder moet instaan dat voor de Gegevensdienst waartoe een verzoek behoort de Aanbieder de gezondheidsgegevens beschikbaar heeft.
Nadat de Dienstverlener aanbieder een autorisatie heeft afgegeven aan de Dienstverlener persoon is de DVP Server gereed om één of meerdere verzoeken om de gezondheidsinformatie naar de Resource Server te sturen. Het adres van de juiste resource endpoints haalt hij uit de Aanbiederslijst. Hij plaatst telkens het access-token in het bericht en zorgt ervoor dat in het bericht geen BSN is opgenomen.
De Resource Server controleert bij ieder verzoek of het ontvangen token recht geeft op de gevraagde resourcesen verleent autorisatie aan de Resource Server. Dan breekt het tweede mogelijke verplichte moment aan waarop de Resource Server ervoor moet instaan dat voor de Gegevensdienst waartoe een verzoek behoort de Aanbieder de gezondheidsgegevens beschikbaar heeft. Is dat zo, dan verstuurt de Resource Server deze in een resource response naar de DVP Server.
De DVP Serverbewaartkan de ontvangen gezondheidsinformatie in het persoonlijke dossier bewaren. De DVP Server bevraagt de Resource Server daarna mogelijk opnieuw, eventueel na nieuwe interactie met de Persoon. Zolang het access-token geldig is, kan dat.
In de regel worden bij een eenmalig gebruik van Verzamelen het authorization interface, het token interface en het resource interface allemaal aangesproken, in die volgorde. Mocht de DVP Server echter nog beschikken over een nog niet verlopen access-token voor de betreffende Aanbieder-Gegevensdienst-combinatie, dan kan het onmiddellijk het resource interface aanspreken. Bij het aanwezig zijn van een geldig refresh-token kan de DVP Server deze direct inruilen voor een access-token en hoeft de authorization interface niet aangeroepen te worden.
Bij de implementatie van de voorwaarde op beschikbaarheid bij de Aanbieder voor de te verzamelen gezondheidsgegevens is het zaak rekening te houden met privacy-vereisten. Wanneer de Dienstverlener aanbieder ten behoeve van de beschikbaarheidsvoorwaarde nieuwe gegevensverzamelingen zou aanleggen, vindt een verwerking altijd onder de verantwoordelijkheid van één Aanbieder plaats. Het combineren van verwerkingen of het onvoldoende segregeren moet worden vermeden. Afwijking hiervan is alleen mogelijk onder expliciete instructie van de Aanbieder(s) en vereist een zorgvuldige voorafgaande afweging, vanwege de daaraan verbonden privacyrisico's.
De verantwoordelijkheden die in de MedMij Core staan beschreven, zijn ook van toepassing op deze extensie. Daarnaast gelden de hieronder (vervangende) verantwoordelijkheden. Net als in de MedMij Core zijn de volgende kleuren voor de verantwoordelijkheden op de verschillende lagen gebruikt:
Geel voor de businesslaag;
Blauw voor de applicatielaag;
Groen voor de technologielaag.
Rollen
Functies & gegevens
Algemeen
Dossier
Dienstverlener persoon neemt maatregelen om te voorkomen dat in een dossier van de Vertegenwoordigde gezondheidsinformatie van een andere Persoon wordt geplaatst.
ext.vert.dossier.100
Dienstverlener persoon biedt Vertegenwoordiger de functie Verzamelen om bij Dienstverlener aanbieder gezondheidsinformatie te verzamelen van Aanbieder, indien deze die informatie beschikbaar stelt, die op de Vertegenwoordigde betrekking heeft en laat deze in een persoonlijk gezondheidsdossier (kortweg Dossier) van Vertegenwoordigde bewaren. Bij deze functie betrokken rollen gebruiken hiertoe het betreffende stroomdiagram. Dit dossier bevat informatie van precies één Persoon.
ext.vert.dossier.101
Dienstverlener persoon biedt Vertegenwoordiger de functie Raadplegen dossier om het persoonlijk gezondheidsdossier van de Vertegenwoordigde te raadplegen.
ext.vert.dossier.102
Gegevensdiensten
Autorisatie
Authenticatie
Logging
Verantwoordelijkheden, Vertegenwoordiging
Inleiding
De verantwoordelijkheden die in de MedMij Core staan beschreven, zijn ook van toepassing op deze extensie. Daarnaast gelden de hieronder (vervangende) verantwoordelijkheden. Net als in de MedMij Core zijn de volgende kleuren voor de verantwoordelijkheden op de verschillende lagen gebruikt:
Geel voor de businesslaag;
Blauw voor de applicatielaag;
Groen voor de technologielaag.
Rollen
Functies & gegevens
Algemeen
Dossier
Dienstverlener persoon neemt maatregelen om te voorkomen dat in een dossier van de Vertegenwoordigde gezondheidsinformatie van een andere Persoon wordt geplaatst.
ext.vert.dossier.100
Dienstverlener persoon biedt Vertegenwoordiger de functie Verzamelen om bij Dienstverlener aanbieder gezondheidsinformatie te verzamelen van Aanbieder, indien deze die informatie beschikbaar stelt, die op de Vertegenwoordigde betrekking heeft en laat kandeze in een persoonlijk gezondheidsdossier (kortweg Dossier) van Vertegenwoordigdelaten bewaren. Bij deze functie betrokken rollen gebruiken hiertoe het betreffende stroomdiagram. Dit dossier bevat informatie van precies één Persoon.
ext.vert.dossier.101
Dienstverlener persoon biedt Vertegenwoordiger de functie Raadplegen dossier om het persoonlijk gezondheidsdossier van de Vertegenwoordigde te raadplegen.
De interpretatie door een Persoon van zorg- en gezondheidsinformatie die hij heeft verzameld bij een Aanbieder, en de interpretatie door een Aanbieder van zulke informatie die met hem/haar gedeeld is door een Persoon, hangt niet alleen af van de inhoud van die informatie, maar ook van de partij die de betreffende informatie oorspronkelijk heeft geregistreerd. De oorspronkelijke herkomst van de gegevens (de auteur) kent geen rol in het MedMij afsprakenstelsel. Dat betekent niet alleen dat er binnen de grenzen van het MedMij Afsprakenstelsel momenteel geen basis is om auteursauthenticiteit (met bijvoorbeeld certificaten) te arrangeren, maar het brengt ook met zich mee dat informatie over de auteur, hoe wezenlijk ook, voor het MedMij Afsprakenstelsel een gegevens-inhoudelijke aangelegenheid is. Die informatie wordt immers ook gebruikt voor de interpretatie van de gedeelde zorg- en gezondheidsinformatie. Omdat, conform principe 1, het MedMij Afsprakenstelsel gegevensneutraal wil zijn, wordt de auteursinformatie een onderdeel geacht van de inhoud van een Gegevensdienst.
Algemeen
Dossier
Dienstverlener persoon biedt Persoon de functie Verzamelen om bij Dienstverlener aanbieder gezondheidsinformatie te verzamelen van Aanbieder, indien deze die informatie beschikbaar stelt, die op deze Persoon betrekking heeft en laat deze in een persoonlijk gezondheidsdossier (kortweg Dossier) van Persoon bewaren. Bij deze functie betrokken rollen gebruiken hiertoe het betreffende stroomdiagram.
Toelichting
Deze verantwoordelijkheid introduceert ook de notie van een persoonlijk gezondheidsdossier. Voor het voldoen aan deze regel is het dus niet voldoende aan de Persoon alleen inkijk in gezondheidsinformatie te bieden. Hij/zij moet het ook kunnen opslaan en beheren. Omdat deze functie zich over verschillende functionele rollen uitstrekt, is om interoperabiliteitsredenen de specificatie van het stroomdiagram aangehaald.
core.dossier.101
Dienstverlener persoon mag de Persoon de functie Automatisch verzamelen aanbieden, mits uitgevoerd vanuit een gegeven langdurige toestemming, het doel is de gebruiksvriendelijkheid (performance) voor de Persoon te verbeteren of dat dit ten dienste staat van analytische oplossingen waarbij de afhankelijkheid van de Persoon de dienstverlening belemmert. De Dienstverlener persoon moet hier afspraken over opnemen in de Gebruikersovereenkomst die hij met de Persoon afsluit.
core.dossier.107
Dienstverlener persoon biedt Persoon de functie Delen om bij Dienstverlener aanbiederten behoeve van eenPersoon, indien deze daartoe ontvankelijk is, gezondheidsinformatie te plaatsen die op deze Persoon betrekking heeft en die afkomstig is uit het Dossier. Bij deze functie betrokken rollen gebruiken hiertoe het betreffende stroomdiagram.
core.dossier.101
Dienstverlener persoon draagt ervoor zorg dat in het Dossier bij alle bij Dienstverlener aanbieder in het kader van een Gegevensdienst verzamelde informatie onlosmakelijk deze Dienstverlener aanbieder en Gegevensdienst als bron en verzamelcontext worden aangetekend. Dienstverlener persoon draagt ervoor zorg dat, in geval van het delen van informatie met een (andere) Aanbieder deze bron- en context-informatie wordt meegeleverd aan de Dienstverlener aanbieder. Voor de benoeming van de bron wordt daarbij gebruik gemaakt van de Aanbiedersnaam. Voor de benoeming van de context wordt daarbij gebruik gemaakt van de betreffende Gegevensdienstnaam uit de Gegevensdienstnamenlijst.
Toelichting
Hiermee wordt geborgd dat bij de uitgewisselde zorg- en gezondheidsinformatie altijd duidelijk is bij welke bron (Dienstverlener aanbieder) en in welke context (Gegevensdienst) deze is verzameld. Een ontvanger van deze informatie kan deze meta-informatie gebruiken voor een betere interpretatie van de betreffende informatie. Mochten hieruit alsnog interpretatievragen komen, kan de ontvanger zich vervoegen bij betreffende bron.
core.dossier.102
Dienstverlener persoon biedt Persoon de functie Raadplegen dossier om het persoonlijk gezondheidsdossier te raadplegen.
Toelichting
Omdat deze functie zich niet over meerdere domeinen uitstrekt, is zij niet nader gespecificeerd in een stroomdiagram. Het is aan de vrijheid van de Deelnemer om deze naar behoefte van haar klanten in te richten. Maar zij mag niet ontbreken, omdat dan de Persoon geen Regie over het dossier zou kunnen voeren.
core.dossier.103
In het kader van de functie Raadplegen dossier zal Persoon te allen tijde moeten kunnen nagaan:
welke inhoud van het Dossier wel, en welke niet, via MedMij-verkeer van Dienstverlener aanbieder is betrokken van welke Aanbieder, en sindsdien niet is veranderd;
welke inhoud van het Dossier wel, en welke niet, via MedMij-verkeer bij Dienstverlener aanbieder is geplaatst ten behoeve van welke Aanbieder.
Toelichting
Toelichting
Hiermee is het voor de Persoon duidelijk op welk deel van de inhoud van zijn dossier hij de aan het MedMij Afsprakenstelsel verbonden vertrouwen kan verbinden. Het is immers goed mogelijk dat een PGO alleen op bepaalde onderdelen deelneemt, en dus voldoet, aan het MedMij Afsprakenstelsel.
core.dossier.104
Dienstverlener persoon biedt Persoon de functie Verwijderen gegevens, waarmee Persoon gegevens, die via de MedMij Functie Verzamelen zijn verkregen, uit het persoonlijk gezondheidsdossier kan verwijderen.
core.dossier.105
In het kader van de functie Verwijderen gegevens zal Persoon te allen tijde worden geïnformeerd:
Welke verzamelde gegevens precies verwijderd worden.
Dat verwijderen alleen in het PGO plaats vindt (en niet in enig bron systeem)
Dat verwijderde gegevens in een later stadium mogelijk niet meer opgevraagd kunnen worden uit de bron systemen (bv bij het verlopen van de beschikbaarheidstermijn)
De gepresenteerde Informatie ondersteunt de gebruiksvriendelijkheid door gebruik te maken van taalniveau B1.
Met de gepresenteerde informatie is het voor de Persoon duidelijk op welk deel, van de inhoud van zijn dossier, de functie verwijderen gegevens wordt toegepast. En is duidelijk wat hiervan de mogelijke consequenties zijn.
core.dossier.106
De Aanbieder, en daarmee de Dienstverlener aanbieder, moet de aanwezige langdurige toestemmingen beëindigen bij overlijden van de Persoon.
core.dossier.108
Verantwoordelijkheden, Core
Inleiding
Rollen
Functies & gegevens
De interpretatie door een Persoon van zorg- en gezondheidsinformatie die hij heeft verzameld bij een Aanbieder, en de interpretatie door een Aanbieder van zulke informatie die met hem/haar gedeeld is door een Persoon, hangt niet alleen af van de inhoud van die informatie, maar ook van de partij die de betreffende informatie oorspronkelijk heeft geregistreerd. De oorspronkelijke herkomst van de gegevens (de auteur) kent geen rol in het MedMij afsprakenstelsel. Dat betekent niet alleen dat er binnen de grenzen van het MedMij Afsprakenstelsel momenteel geen basis is om auteursauthenticiteit (met bijvoorbeeld certificaten) te arrangeren, maar het brengt ook met zich mee dat informatie over de auteur, hoe wezenlijk ook, voor het MedMij Afsprakenstelsel een gegevens-inhoudelijke aangelegenheid is. Die informatie wordt immers ook gebruikt voor de interpretatie van de gedeelde zorg- en gezondheidsinformatie. Omdat, conform principe 1, het MedMij Afsprakenstelsel gegevensneutraal wil zijn, wordt de auteursinformatie een onderdeel geacht van de inhoud van een Gegevensdienst.
Algemeen
Dossier
Dienstverlener persoon biedt Persoon de functie Verzamelen om bij Dienstverlener aanbieder gezondheidsinformatie te verzamelen van Aanbieder, indien deze die informatie beschikbaar stelt, die op deze Persoon betrekking heeft en laatkan deze in een persoonlijk gezondheidsdossier (kortweg Dossier) van Persoonlaten bewaren. Bij deze functie betrokken rollen gebruiken hiertoe het betreffende stroomdiagram.
Toelichting
Deze verantwoordelijkheid introduceert ook de notie van een persoonlijk gezondheidsdossier. Het opslaan in een persoonlijk gezondheidsdossier is optionele functionaliteit in het afsprakenstelsel. Wanneer deze functionaliteit wordt aangeboden moet ook het beheer worden aangeboden. Voor het voldoen aan deze regel is het dus niet voldoende aan de Persoon alleen inkijk in gezondheidsinformatie te bieden. Hij/zij moet het ook kunnen opslaan en beheren. Omdat dedeze functie verzamelen zich over verschillende functionele rollen uitstrekt, is om interoperabiliteitsredenen de specificatie van het stroomdiagram aangehaald.
core.dossier.101
Dienstverlener persoon mag de Persoon de functie Automatisch verzamelen aanbieden, mits uitgevoerd vanuit een gegeven langdurige toestemming, het doel is de gebruiksvriendelijkheid (performance) voor de Persoon te verbeteren of dat dit ten dienste staat van analytische oplossingen waarbij de afhankelijkheid van de Persoon de dienstverlening belemmert. De Dienstverlener persoon moet hier afspraken over opnemen in de Gebruikersovereenkomst die hij met de Persoon afsluit.
core.dossier.107
Dienstverlener persoon biedt Persoon de functie Delen om bij Dienstverlener aanbiederten behoeve van eenPersoon, indien deze daartoe ontvankelijk is, gezondheidsinformatie te plaatsen die op deze Persoon betrekking heeft en die afkomstig is uit het Dossier. Bij deze functie betrokken rollen gebruiken hiertoe het betreffende stroomdiagram.
core.dossier.101
Dienstverlener persoon draagt ervoor zorg dat in het Dossier bij alle bij Dienstverlener aanbieder in het kader van een Gegevensdienst verzamelde informatie onlosmakelijk deze Dienstverlener aanbieder en Gegevensdienst als bron en verzamelcontext worden aangetekend. Dienstverlener persoon draagt ervoor zorg dat, in geval van het delen van informatie met een (andere) Aanbieder deze bron- en context-informatie wordt meegeleverd aan de Dienstverlener aanbieder. Voor de benoeming van de bron wordt daarbij gebruik gemaakt van de Aanbiedersnaam. Voor de benoeming van de context wordt daarbij gebruik gemaakt van de betreffende Gegevensdienstnaam uit de Gegevensdienstnamenlijst.
Toelichting
Hiermee wordt geborgd dat bij de uitgewisselde zorg- en gezondheidsinformatie altijd duidelijk is bij welke bron (Dienstverlener aanbieder) en in welke context (Gegevensdienst) deze is verzameld. Een ontvanger van deze informatie kan deze meta-informatie gebruiken voor een betere interpretatie van de betreffende informatie. Mochten hieruit alsnog interpretatievragen komen, kan de ontvanger zich vervoegen bij betreffende bron.
core.dossier.102
Dienstverlener persoon biedt Persoon de functie Raadplegen dossier om het persoonlijk gezondheidsdossier te raadplegen.
Toelichting
Omdat deze functie zich niet over meerdere domeinen uitstrekt, is zij niet nader gespecificeerd in een stroomdiagram. Het is aan de vrijheid van de Deelnemer om deze naar behoefte van haar klanten in te richten. Maar zij mag niet ontbreken, omdat dan de Persoon geen Regie over het dossier zou kunnen voeren.
core.dossier.103
In het kader van de functie Raadplegen dossier zal Persoon te allen tijde moeten kunnen nagaan:
welke inhoud van het Dossier wel, en welke niet, via MedMij-verkeer van Dienstverlener aanbieder is betrokken van welke Aanbieder, en sindsdien niet is veranderd;
welke inhoud van het Dossier wel, en welke niet, via MedMij-verkeer bij Dienstverlener aanbieder is geplaatst ten behoeve van welke Aanbieder.
Toelichting
Toelichting
Hiermee is het voor de Persoon duidelijk op welk deel van de inhoud van zijn dossier hij de aan het MedMij Afsprakenstelsel verbonden vertrouwen kan verbinden. Het is immers goed mogelijk dat een PGO alleen op bepaalde onderdelen deelneemt, en dus voldoet, aan het MedMij Afsprakenstelsel.
core.dossier.104
Dienstverlener persoonbiedt kan Persoon de functie Verwijderen gegevens bieden, waarmee Persoon gegevens, die via de MedMij Functie Verzamelen zijn verkregen, uit het persoonlijk gezondheidsdossier kan verwijderen.
core.dossier.105
In het kader van de functie Verwijderen gegevens zal Persoon te allen tijde worden geïnformeerd:
Welke verzamelde gegevens precies verwijderd worden.
Dat verwijderen alleen in het de PGO plaats vindt (en niet in enig bron systeem)
Dat verwijderde gegevens in een later stadium mogelijk niet meer opgevraagd kunnen worden uit de bron systemen (bv bij het verlopen van de beschikbaarheidstermijn)
De gepresenteerde Informatie ondersteunt de gebruiksvriendelijkheid door gebruik te maken van taalniveau B1.
Met de gepresenteerde informatie is het voor de Persoon duidelijk op welk deel, van de inhoud van zijn dossier, de functie verwijderen gegevens wordt toegepast. En is duidelijk wat hiervan de mogelijke consequenties zijn.
core.dossier.106
De Aanbieder, en daarmee de Dienstverlener aanbieder, moet de aanwezige langdurige toestemmingen beëindigen bij overlijden van de Persoon.
core.dossier.108
JavaScript errors detected
Please note, these errors can depend on your browser setup.
If this problem persists, please contact our support.
