Document toolboxDocument toolbox

MO-123 Logging-monitoring en rapporteren

 Samenvatting

Waarom is deze RFC nodig?

MO-52 moet worden verwerkt in het MedMij Afsprakenstelsel.

Oplossingsrichting

Verwerken aanpassingen in release 2305

RACI
  • Responsible:
    • Team Ontwikkeling, Lead Architect
  • Accountable:
    • Productmanagement
  • Consulted
    • Ontwikkelteam (ontwikkeling@medmij.nl)
    • Security Management (secmgt@medmij.nl)
    • Acceptatie (acceptatie@medmij.nl)
    • Stichting MedMij
    • Acceptatie
    • R&A
    • CCDA
    • Stelselregie
    • Deelnemers (Expertgroepsessie)
  • Informed
    • Communicatie
    • Loket (info@medmij.nl)
    • Leveranciersmanagement


Aanpassing van

MM Optioneel 2.0.0

Impact op rollen

Beheer & Acceptatie

Impact op beheerHet uitbreiden van logging en het analyseren van de data en acteren op de uitkomsten hiervan zorgt voor extra werk voor ketenregie.


Impact op RnAN.v.t


Impact op AcceptatieDoordat logging wordt opgenomen in het afsprakenstelsel moeten deelnemers ook voldoen aan de gestelde eisen. Hierdoor moet acceptatie zijn acceptatieproces aanpassen.


PIA noodzakelijkNee
Gerelateerd aan (Andere RFCs, PIM issues)

MO- 14 langdurige toestemmingen

Implementatietermijn

release 2305

Motivatie verkorte RFC procedure (patch)

N.v.t.

Uitwerking

  • Aanpassingen doorvoeren op MM optioneel (2.0.0).


Locatie wijzigingHuidige tekstAanpassingen
Verantwoordelijkheden, Corezie onderstaande tabelzie 2e onderstaande tabel
.Performancebeleid v2.0.0_202305

De totale performance van het MedMij-netwerk hangt af van de individuele prestaties van deelnemers en MedMij Registratie. Aangezien de persoon binnen MedMij de regie voert over de uitwisseling van gegevens, initieert de Dienstverlener persoon bij de functies Verzamelen en Delen de interacties en reageert de Dienstverlener aanbieder. Om die reden zijn er afspraken over de beschikbaarheid en reactietijd van Dienstverleners aanbieder (zie Token interface en Resource interface). Bij de overige usecases voor het opvragen van de lijsten initiëren deelnemers en reageert MedMij Registratie. Daarom zijn er afspraken over de beschikbaarheid van MedMij Registratie (zie Interfaces lijsten). 

Wanneer deelnemers bij elkaar constateren dat de performance achterblijft of dat er fouten ontstaan in de onderlinge interacties, dan wordt van hen naar redelijkheid verwacht dat ze inspanning verrichten om dit onderling aanhangig te maken en te kijken of het daarmee opgelost kan worden. Stichting MedMij kan hierbij faciliteren en mediëren (zie ook Samenwerkings- en escalatiebeleid). Deelnemers gebruiken alle aanwezige logging, naar redelijkheid, om een probleem te helpen oplossen.


Mochten de prestaties van een deelnemer achterblijven en/of een deelnemer toont onvoldoende inzet om problemen op te lossen, dan treedt het Nalevingsbeleid in werking.

Beleid> Performancebeleid

Locatie

Verantwoordelijkheden, Core

Aanpassingen hoofdstuk Logging

1.

Dienstverlener persoon zal het Deelnemers richten de logbestanden inrichten zoals bedoeld in beschreven bij Logging interface, de AVG en NEN 7513:2018., van de door enige Persoon bij enige Dienstverlener aanbieder uitgevoerde functies.


 Click here to expand...

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:

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

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.

 Click here to 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 deelnemers en 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.

core.logging.101

3.

Deelnemers moeten gebeurtenissen lokaal in logregels vastleggen op het moment dat deze plaatsvinden. De vastgelegde logregels worden met een zo hoog mogelijke frequentie (maar minimaal eenmaal per uur) in batches aangeleverd bij MedMij.

Het endpoint waarnaar de batches verstuurd moeten worden, is niet beschikbaar bij de eerste publicatie van versie 2.0.0 van het afsprakenstelsel. Zodra deze wel beschikbaar is moeten Deelnemers deze gaan gebruiken.

core.logging.102
4.Logregels die met MedMij gedeeld worden, mogen geen inhoudelijke gegevens over de Persoon bevatten, niet herleidbaar zijn naar de Persoon en mogen alleen metagegevens over de gebeurtenissen bevatten.core.logging.103
5.

De DVP Server logt:

  1. in de rol van OAuth Client elk verzoek aan en antwoord van de OAuth Authorization Server, ook het Authorization request dat vanuit de User Agent wordt gestuurd;
  2. in de rol van Resource Client elk verzoek aan en antwoord van de Resource Server;
  3. elke technische storing bij het uitvoeren van de MedMij functies.
core.logging.202
6.

De Authorization Server logt:

  1. in de rol van OAuth Authorization Server elk verzoek van en antwoord aan de OAuth Client;
  2. het versturen van de pagina's naar de User Agent;
  3. in de rol van Authentication Client elk verzoek naar en antwoord van de Authentication Server;
  4. het resultaat van het uitvoeren van de beschikbaarheids- (Verzamelen en Abonneren) en ontvankelijkheidstoets (Delen);
  5. de door de Persoon teruggestuurde toestemmings- (Verzamelen en Abonneren) en bevestigingsverklaring (Delen);
  6. elke technische storing bij het uitvoeren van de MedMij functies.
core.logging.203
7.

De Resource Server logt:

  1. elk verzoek van en antwoord aan de Resource Client;
  2. het resultaat van het uitvoeren van de beschikbaarheids- (Verzamelen en Abonneren) en ontvankelijkheidstoets (Delen);
  3. het resultaat van de verzamelde gegevens;
    1. elke technische storing bij het uitvoeren van de MedMij functies.
core.logging.204
8.

Logregels worden in het JSON-formaat bij MedMij aangeleverd, zoals gespecificeerd bij Logging interface, op het door MedMij hiervoor beschikbaargestelde endpoint.

Het endpoint waarnaar de logging verstuurd moet worden, is niet beschikbaar bij de eerste publicatie van versie 2.0.0 van het afsprakenstelsel. Zodra deze wel beschikbaar is moeten Deelnemers deze gaan gebruiken.

core.logging.205
9.De endpoint van de Logging interface heeft op jaarbasis een beschikbaarheid van minimaal 99,9%. MedMij laat, na het niet beschikbaar raken van de MedMij Logging interface, maximaal acht kantooruren (480 minuten) verstrijken voordat het weer beschikbaar is.
core.logging.206
10.De DVP Server maakt voor het versturen van een Authorization Request, of in het geval van langdurige toestemming voor het versturen van een Token Request, een trace-id aan dat gedurende het hele proces door alle rollen wordt gebruikt bij het vastleggen van bijbehorende logregels. Dit om de logregels van verschillende partijen in een proces aan elkaar te kunnen correleren.core.logging.207
12.Bij het loggen van verzonden resource requests neemt de OAuth Client ook het MedMij-Request-ID Header Field op in het logbestand als ID attribuut van het request object.

core.logging.200

13.Bij het loggen van ontvangen resource requests neemt de nemen de OAuth Authorization Server en de OAuth Resource Server ook het MedMij-Request-ID Header Field op in het logbestand als ID attribuut van het request object.

core.logging.201

14.Bij het loggen van de verschillende gebeurtenissen tijdens het proces nemen OAuth Client, de OAuth Authorization Server en de OAuth Resource Server het X-Correlation_ID op in het logbestand als trace_id attribuut van het request object.core.logging.208

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


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
N.v.t

N.v.t

N.v.t
N.v.t
N.v.t

Bijlagen

  File Modified
No files shared here yet.

Goedkeuring

BeoordelaarDatumToelichtingBeoordelaarDatumToelichting
Productmanager Stichting MedMij

Productmanager Beheerorganisatie

Leadarchitect Stichting MedMij

Leadarchitect Beheerorganisatie

Ontwerpteam




Deelnemersraad

Eigenaarsraad