Skip to end of banner
Go to start of banner

RFC0067 Scheiden dossier en logging

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Current »

Samenvatting

Waarom is deze RFC nodig?

Versie 1.5 beschrijft in verantwoordelijkheid core.logging.100 dat het dossier zo ingericht moet worden dat deze ook dienst kan doen als logbestand. Dit blijkt, vanuit vragen van deelnemers, lastig te implementeren, daar ook aan bijvoorbeeld NEN-eisen voldaan moet worden. De gegevens in een dossier moeten levenslang bewaard (kunnen) blijven, logbestanden moeten na 36 maanden verwijderd worden. Scheiding van de twee onderwerpen is gewenst, om de implementatievereisten te verduidelijken.

Oplossingsrichting
  • De koppeling tussen dossier en logbestand wordt uit het afsprakenstelsel verwijderd. Dit betekent dat core.logging.100 herschreven moet worden.
  • Logging en portabiliteit worden gescheiden van elkaar beschreven. Nu is dit één hoofdstuk (Logging en portabiliteit) in de verantwoordelijkheden.


RACI
  • Responsible:
    • Lead architect
  • Accountable:
    • Product management
  • 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


Motivatie verkorte RFC procedure (patch)


Uitwerking epic

Uitwerking Epic AF-1373, Inconsistentie bewaarplicht

Wijzigingen afsprakenstelsel

Logging en portabiliteit

Huidige inhoudNieuwe inhoud
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 persoonsgege­vens en door enige Persoon bij enige Dienstverlener aanbieder geplaatste persoonsgegevens.
 Toelichting

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.

core.logging.100

1.
Dienstverlener persoon zal het logbestand inrichten zoals bedoeld in de AVG en NEN 7513:2018, van de door enige Persoon bij enige Dienstverlener aanbieder uitgevoerde functies.
 Toelichting

Met de logging wordt beoogd een betrouwbaar overzicht te kunnen leveren van de gebeurtenissen waarbij gezondheidsgegevens over een Persoon zijn verwerkt.

Dit betreft minimaal de  gebeurtenissen die voortkomen uit de functies:

  • Raadplegen dossier
  • Verzamelen
  • Delen
  • Abonneren
  • Verwijderen gegevens

core.logging.100


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


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.

DreigingKansImpactDreigingsID (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.





Bijlagen

  File Modified
No files shared here yet.

Goedkeuring

BeoordelaarDatumToelichtingBeoordelaarDatumToelichting
Productmanager Stichting MedMij

Productmanager Beheerorganisatie

Leadarchitect Stichting MedMij

Leadarchitect Beheerorganisatie

Ontwerpteam




Deelnemersraad

Eigenaarsraad

  • No labels