1. Samenvatting
Waarom is deze RFC nodig? | Versie 1.5 van het afsprakenstelsel bevat onder verantwoordelijkheden het kopje Logging en portabiliteit. Dit zorgt voor een koppeling tussen twee onderwerpen met elk een eigen doel. Het onderwerp portabiliteit moet in de toekomst worden aangepakt, daar de huidige beschrijving niet toekomstvast lijkt te zijn. Om wijzigingen van het onderwerp portabiliteit voor te bereiden, moeten de onderwerpen logging en portabiliteit alvast gescheiden worden. |
---|
Oplossingsrichting | Twee losse onderwerpen bij de verantwoordelijkheden, elk met een eigen kopje en eigen verantwoordelijkheden |
---|
RACI | Responsible: Accountable: Consulted Ontwikkelteam (ontwikkeling@medmij.nl) Security Management (secmgt@medmij.nl) Acceptatie (acceptatie@medmij.nl) Stelselregie Deelnemers (Expertgroepsessie)
Informed Communicatie Loket (info@medmij.nl) Leveranciersmanagement
|
---|
Aanpassing van | core.logging.100 |
---|
Impact op rollen | DVP |
---|
Impact op beheer | - |
---|
Impact op RnA | - |
---|
Impact op Acceptatie | - |
---|
PIA noodzakelijk | - |
---|
Gerelateerd aan (Andere RFCs, PIM issues) | |
---|
Implementatietermijn | 1.6.0 |
---|
2. Uitwerking epic
Uitwerking Epic AF-1373, Inconsistentie bewaarplicht
3. Wijzigingen afsprakenstelsel
3.1. Logging en portabiliteit
Huidige inhoud | Nieuwe inhoud |
---|
Logging en portabiliteit 1. | Dienstverlener persoon zal het Dossier zo inrichten dat deze ook dienst kan doen als logbestand, zoals bedoeld in de AVG en NEN 7513:2018, van de door enige Persoon bij enige Dienstverlener aanbieder verzamelde persoonsgegevens en door enige Persoon bij enige Dienstverlener aanbieder geplaatste persoonsgegevens. Expand |
---|
| Met de logging wordt beoogd een betrouwbaar overzicht te kunnen leveren van de gebeurtenissen waarbij gezondheidsinformatie over een Persoon zijn verwerkt. Die gebeurtenissen kunnen zich over verschillende plaatsen en tijden uitstrekken. Het beoogde overzicht is dus alleen mogelijk als de loggegevens uit verschillende bronnen kunnen worden gecombineerd. Ook zonder direct een virtueel wereldwijd en levenslang patiëntdossier als doel te stellen is duidelijk dat gestandaardiseerde logging een voorwaarde is om het overzicht voor de betreffende Persoon mogelijk te maken. Op 18 mei 2018 is een revisie verschenen van de 2010-versie van NEN 7513. Deze norm, met het nummer NEN 7513:2018, is onderdeel van het Normenkader informatiebeveiliging van het MedMij Afsprakenstelsel. In hoofdstuk 5 van de gereviseerde norm staan de informatiebehoeften, zowel de algemene als die vanuit het specifieke perspectief van cliënten, zorginstellingen en toezichthouders. Hoofdstuk 6 vertaalt deze behoeften naar een overzicht van te loggen gebeurtenissen en hoofdstuk 7 biedt een model van de te loggen gegevens. De voorgaande versie (NEN 7513:2010) is ingetrokken. De term NEN 7513 in het Besluit elektronische gegevensverwerking door zorgaanbieders wordt daarom geacht naar de 2018-versie te verwijzen. |
| Anchor |
---|
| core.logging.100 |
---|
| core.logging.100 |
---|
| core.logging.100
| 2. | De bewaartermijn van de logbestanden is ten minste 24 maanden en niet meer dan 36 maanden. Na de bewaartermijn van de logbestanden moeten deze vernietigd worden. Expand |
---|
| Het maximum van de bewaartermijn is bepaald voor logging binnen de scope van MedMij-verkeer ter voorkoming van onnodige opslag van gegevens en ter bescherming van de privacy van de gebruiker. Deze minimale en maximale bewaartermijnen van logbestanden passen binnen de uitersten die daartoe door NEN7513 (paragraaf 8.5) zijn bepaald. |
| Anchor |
---|
| core.logging.101 |
---|
| core.logging.101 |
---|
| core.logging.101
| 4. | Dienstverlener persoon biedt Persoon de mogelijkheid om een Portabiliteitsrapport te verkrijgen. Daarmee kan Persoon geautomatiseerd een lijst exporteren, genaamd het Portabiliteitsrapport, van alle keren, gedurende een zekere periode, dat Persoon deze Dienstverlener persoon bij een Aanbieder gezondheidsinformatie volgens een zekere Gegevensdienst heeft verzameld. | Anchor |
---|
| core.logging.102 |
---|
| core.logging.102 |
---|
| core.logging.102
| 5. | Dienstverlener persoon biedt Persoon pro-actief de export van een Portabiliteitsrapport aan: | Anchor |
---|
| core.logging.103 |
---|
| core.logging.103 |
---|
| core.logging.103
| 6. | Dienstverlener persoon beperkt Persoon niet in het gebruik van de Portabiliteitsrapport in de relatie van Persoon met mogelijke andere en/of latere Dienstverlener persoon. | Anchor |
---|
| core.logging.104 |
---|
| core.logging.104 |
---|
| core.logging.104
| 7. | Het Portabiliteitsrapport voldoet aan hetgeen daarover bepaald is in de Informatiemodellen en heeft de technische vorm van een XML-document, dat voldoet aan het XML-schema dat op de pagina XML-schema's te vinden is. Expand |
---|
| Met het Portabiliteitsrapport krijgt Persoon een middel in handen om een belangrijk deel van de gezondheidsinformatie die hij in het Dossier in zijn PGO heeft verzameld, naar believen ook in andere PGO's onder te brengen (portabiliteit, overdraagbaarheid). Ook dat draagt bij aan de Regie van de Persoon over zijn gezondheidsinformatie, aan zijn voortdurend vrije keuze tussen Dienstverlener persoon (principe 7) en aan het beperken van het nadeel dat hij zou ondervinden wanneer zijn Dienstverlener persoon haar activiteiten zou staken. Er is geen garantie dat een Portabiliteitsrapport geautomatiseerd door een andere PGO dan die het rapport heeft gemaakt zou kunnen worden 'afgespeeld', al is het maar doordat niet alle gebruikte Gegevensdiensten nog als geldig in de Catalogus hoeven te staan. Het Portabiliteitsrapport geeft in dat soort gevallen nog steeds precieze en menselijkerwijs enigszins leesbare informatie waarmee de nieuwe PGO alsnog, desnoods, handmatig gevuld kan worden. Dienstverlener persoon kunnen hun dienstverlening aan Persoon kracht bij zetten door een importfunctie voor Portabiliteitsrapporten aan te bieden. Dit is echter niet verplicht en moet gezien worden in het licht van principe 3. Een zwaarder middel voor portabiliteit zou een uitwisselstandaard tussen PGO's zijn. Dit zou echter een flinke complexiteit en kosten met zich meebrengen, niet in het minst doordat het rekening zou moeten houden met alle voormalige versies van het MedMij Afsprakenstelsel en met Gegevensdiensten die ondertussen niet meer als geldig in de Catalogus staan. |
| Anchor |
---|
| core.logging.105 |
---|
| core.logging.105 |
---|
| core.logging.105
| 8. | Bij het loggen van verzonden resource requests neemt de OAuth Client ook het MedMij-Request-ID Header Field op in het logbestand. | Anchor |
---|
| core.logging.200 |
---|
| core.logging.200 |
---|
| core.logging.200
| 9. | Bij het loggen van ontvangen resource requests neemt de OAuth Resource Server ook het MedMij-Request-ID Header Field op in het logbestand. | Anchor |
---|
| core.logging.201 |
---|
| core.logging.201 |
---|
| core.logging.201
|
| Logging 1. | | Anchor |
---|
| core.logging.100 |
---|
| core.logging.100 |
---|
| core.logging.100
| 2. | De bewaartermijn van de logbestanden is ten minste 24 maanden en niet meer dan 36 maanden. Na de bewaartermijn van de logbestanden moeten deze vernietigd worden. Expand |
---|
| Het maximum van de bewaartermijn is bepaald voor logging binnen de scope van MedMij-verkeer ter voorkoming van onnodige opslag van gegevens en ter bescherming van de privacy van de gebruiker. Deze minimale en maximale bewaartermijnen van logbestanden passen binnen de uitersten die daartoe door NEN7513 (paragraaf 8.5) zijn bepaald. |
| Anchor |
---|
| core.logging.101 |
---|
| core.logging.101 |
---|
| core.logging.101
| 3. | Bij het loggen van verzonden resource requests neemt de OAuth Client ook het MedMij-Request-ID Header Field op in het logbestand. | Anchor |
---|
| core.logging.200 |
---|
| core.logging.200 |
---|
| core.logging.200
| 4. | Bij het loggen van ontvangen resource requests neemt de OAuth Resource Server ook het MedMij-Request-ID Header Field op in het logbestand. | Anchor |
---|
| core.logging.201 |
---|
| core.logging.201 |
---|
| core.logging.201
|
Portabiliteit 1. | Dienstverlener persoon biedt Persoon de mogelijkheid om een Portabiliteitsrapport te verkrijgen. Daarmee kan Persoon geautomatiseerd een lijst exporteren, genaamd het Portabiliteitsrapport, van alle keren, gedurende een zekere periode, dat Persoon deze Dienstverlener persoon bij een Aanbieder gezondheidsinformatie volgens een zekere Gegevensdienst heeft verzameld. | Anchor |
---|
| core.portabiliteit.100 |
---|
| core.portabiliteit.100 |
---|
| core.portabiliteit.100
| 2. | Dienstverlener persoon biedt Persoon pro-actief de export van een Portabiliteitsrapport aan: | Anchor |
---|
| core.portabiliteit.101 |
---|
| core.portabiliteit.101 |
---|
| core.portabiliteit.101
| 3. | Dienstverlener persoon beperkt Persoon niet in het gebruik van de Portabiliteitsrapport in de relatie van Persoon met mogelijke andere en/of latere Dienstverlener persoon. | Anchor |
---|
| core.portabiliteit.102 |
---|
| core.portabiliteit.102 |
---|
| core.portabiliteit.102
| 4. | Het Portabiliteitsrapport voldoet aan hetgeen daarover bepaald is in de Informatiemodellen en heeft de technische vorm van een XML-document, dat voldoet aan het XML-schema dat op de pagina XML-schema's te vinden is. Expand |
---|
| Met het Portabiliteitsrapport krijgt Persoon een middel in handen om een belangrijk deel van de gezondheidsinformatie die hij in het Dossier in zijn PGO heeft verzameld, naar believen ook in andere PGO's onder te brengen (portabiliteit, overdraagbaarheid). Ook dat draagt bij aan de Regie van de Persoon over zijn gezondheidsinformatie, aan zijn voortdurend vrije keuze tussen Dienstverlener persoon (principe 7) en aan het beperken van het nadeel dat hij zou ondervinden wanneer zijn Dienstverlener persoon haar activiteiten zou staken. Er is geen garantie dat een Portabiliteitsrapport geautomatiseerd door een andere PGO dan die het rapport heeft gemaakt zou kunnen worden 'afgespeeld', al is het maar doordat niet alle gebruikte Gegevensdiensten nog als geldig in de Catalogus hoeven te staan. Het Portabiliteitsrapport geeft in dat soort gevallen nog steeds precieze en menselijkerwijs enigszins leesbare informatie waarmee de nieuwe PGO alsnog, desnoods, handmatig gevuld kan worden. Dienstverleners persoon kunnen hun dienstverlening aan Persoon kracht bij zetten door een importfunctie voor Portabiliteitsrapporten aan te bieden. Dit is echter niet verplicht en moet gezien worden in het licht van principe 3. Een zwaarder middel voor portabiliteit zou een uitwisselstandaard tussen PGO's zijn. Dit zou echter een flinke complexiteit en kosten met zich meebrengen, niet in het minst doordat het rekening zou moeten houden met alle voormalige versies van het MedMij Afsprakenstelsel en met Gegevensdiensten die ondertussen niet meer als geldig in de Catalogus staan. |
| Anchor |
---|
| core.portabiliteit.103 |
---|
| core.portabiliteit.103 |
---|
| core.portabiliteit.103
|
|
4. Principe's
Principe |
| Principe |
|
---|
1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal | | 11 Stelselfuncties worden vanaf de start ingevuld | |
2 Dienstverleners zijn transparant over de gegevensdiensten | | 12 Het afsprakenstelsel is een groeimodel | |
3 Dienstverleners concurreren op de functionaliteiten | | 13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders | |
4 Dienstverleners zijn aanspreekbaar door de gebruiker | | 14 Uitwisseling is een keuze | |
5 De persoon wisselt gegevens uit met de zorgaanbieder | | 15 Het MedMij-netwerk is gebruiksrechten-neutraal | |
6 MedMij spreekt alleen af wat nodig is | | 16 De burger regisseert zijn gezondheidsinformatie als uitgever | |
7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener | | 17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld | |
9 De dienstverleners zijn deelnemers van het afsprakenstelsel | | 18 Afspraken worden aantoonbaar nageleefd en gehandhaafd | |
10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling | | 19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat | |
Toelichting |
|
5. 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.
Dreiging | Kans | Impact | DreigingsID (intern) | Maatregelen |
---|
Metagegevens worden op meerdere locaties opgeslagen, waardoor er een hoger risico is op een datalek. | Klein | Klein |
| Deelnemers dienen de loggegevens goed beveiligd op te slaan, waardoor het risico op een datalek verkleind wordt. |
|
|
|
|
|
6. Bijlagen
7. Goedkeuring
Beoordelaar | Datum | Toelichting | Beoordelaar | Datum | Toelichting |
---|
Productmanager Stichting MedMij |
|
| Productmanager Beheerorganisatie |
|
|
Leadarchitect Stichting MedMij |
|
| Leadarchitect Beheerorganisatie |
|
|
Ontwerpteam |
|
|
|
|
|
Deelnemersraad |
|
| Eigenaarsraad |
|
|