Skip to end of banner
Go to start of banner

RFC0020 Uitbreiding logging eisen over gehele stelsel

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 29 Next »

Samenvatting

Waarom is deze RFC nodig?

Een tweetal incidenten eerder dit jaar heeft geleerd dat de log-bestanden die door de betrokken deelnemers werden geleverd aan de beheerorganisatie ter analyse, te weinig informatie bevatten om te kunnen bepalen welke uitwisselingen er hadden plaats gevonden. Deze RFC doet een aanzet om de bruikbaarheid van de logbestanden van deelnemers voor dit doel te vergroten.

Oplossingsrichting

Logging kan aan drie doelen bijdragen: verantwoording, debugging, (basis voor) monitoring.

MedMij deelnemers dienen NEN7510 gecertificeerd te zijn en daarmee is er een sterke druk om de logging vorm te geven conform NEN7513. Deze aanbeveling wordt ook gegeven aan DVP's op /wiki/spaces/MedMijAfsprakenstelsel120/pages/135103656, verantwoordelijkheid 19a: "Uitgever 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 Zorggebruiker bij enige Bron verzamelde persoonsgege­vens en door enige Zorggebruiker bij enige Lezer geplaatste persoonsgegevens.". 

Vanuit security is de eis gesteld dat door het combineren van de log-bestanden van DVP en DVZA, vastgesteld moet kunnen worden welke informatie is overgedragen tussen DVZA en DVP (of andersom). Dit naar aanleiding van enkele incidenten.

Om aan deze eisen te voldoen zijn een aantal alternatieven omtrent eisen aan de logbestanden beschouwd;

  1. Volledig uitwerken NEN7513 eisen en introduceren van transactie/flow-concept aan het Afsprakenstelsel;
  2. Voorschrijven van het toevoegen van te loggen items, waardoor alle requests en responses op interfaces te bundelen en daarmee tweezijdig (DVP en DVZA kant) terug te vinden zijn.

De NEN7513 geeft een standaard datastructuur voor logging. In MedMij zal de logging conform deze structuur uitgewerkt en voorgeschreven gaan worden. Omdat voor Release 1.3.0 als uitgangspunt gekozen is voor 'implementatierust' zal nu niet voor deze variant gekozen worden. MedMij kent (nog) geen 'transactie-id' of 'gebeurteniscode' die aan DVP en DVZA kant wordt gedeeld en waarmee logregels afkomstig van beide partijen, over meerdere requests heen, gekoppeld kunnen worden. Het toevoegen van een dergelijk concept in het Afsprakenstelsel is op dit moment een te grote ingreep met een te grote impact/implementatielast voor deelnemers. Ook bevat  deze RFC nog geen analyse of uitwerking op het niveau van gegevensdienst/informatiestandaard.

Daarom wordt in deze RFC gekozen voor de minimale manier om aan de eis te kunnen voldoen dat vastgesteld kan worden welke informatie tussen welke partijen is uitgewisseld door het combineren van de log-bestanden van betrokken DVP en DVZA m.b.t. de resource interface.

Naast de aanvullende eisen in de logbestanden, worden enkele eisen explicieter beschreven in het stelsel.

Aanpassing van

Afsprakenstelsel

Impact op rollen

DVZA, DVP

Impact op beheer

Nee, nu niet voorzien

Impact op RnA

Nee, nu niet voorzien

Impact op Acceptatie

Ja, aangescherpte eisen zullen moeten worden meegenomen in testen.

Gerelateerd aan (Andere RFCs, PIM issues)

-

Eigenaar
Implementatietermijn

1.3.0 

Motivatie verkorte RFC procedure (patch)

-

Goedkeuring

BeoordelaarDatumToelichtingBeoordelaarDatumToelichting
Productmanager Stichting MedMij

Productmanager Beheerorganisatie

Leadarchitect Stichting MedMij

Leadarchitect Beheerorganisatie

Ontwerpteam




Deelnemersraad

Eigenaarsraad

Principe's

Principe
Principe

1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal

Neutraal

11 Stelselfuncties worden vanaf de start ingevuld

Neutraal

2 Dienstverleners zijn transparant over de gegevensdiensten 

Neutraal

12 Het afsprakenstelsel is een groeimodel

Neutraal

Dienstverleners concurreren op de functionaliteiten

Positief

13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders

Neutraal

Dienstverleners zijn aanspreekbaar door de gebruiker

Positief

14 Uitwisseling is een keuze

Neutraal

De persoon wisselt gegevens uit met de zorgaanbieder

Positief

15 Het MedMij-netwerk is gebruiksrechten-neutraal

Neutraal

MedMij spreekt alleen af wat nodig is

Negatief

16 De burger regisseert zijn gezondheidsinformatie als uitgever

Neutraal

De persoon en de zorgaanbieder kiezen hun eigen dienstverlener

Neutraal

17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld

Positief

De dienstverleners zijn deelnemers van het afsprakenstelsel

Neutraal

18 Afspraken worden aantoonbaar nageleefd en gehandhaafd

Positief

10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling

Neutraal

19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat

Positief

Uitwerking

Toevoegen aan pagina "Applicatie" onderaan:

Logging

19a. Bij het loggen van verzonden resource requests neemt dOAuth Client ook het MedMij-Request-ID Header Field op in het logbestand.

19b. Bij het loggen van ontvangen resource requests neemt dOAuth Resource Server ook het MedMij-Request-ID Header Field op in het logbestand.

Wijzigen aan pagina "Resource interface":

1a. De OAuth Client gebruikt voor het sturen van het acces token, in de resource request, de methode Authorization Request Header Field, zoals beschreven in sectie 2.1 van RFC6750.


Toelichting

De methode Authorization Request Header Field biedt de beste beveiliging.


1b. De OAuth Client voegt bij het versturen van een resource request een HTTP Header Field toe met de naam MedMij-Request-ID. Het MedMij-Request-ID moet een willekeurige waarde bevatten en dient uniek te zijn binnen het MedMij netwerk. Het kan een integer waarde zijn, of een UUID, maar kan ook volgens een ander geldig identificatiepatroon worden gevuld.


Former user (Deleted) Moet resource server een request zonder ID gaan weigeren? Ja gaan we doen 400.


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
Implementatielast voor deelnemers

Hoog

Hoog

Gezien belang in overleg met deelnemers bepalen wanneer dit ingevoerd moet worden. RFC beperken tot minimum.
Impact op gegevensdienst/informatiestandaardMiddelMiddel
Gezamenlijk optrekken met informatiearchitecten (Nictiz). Kiezen voor generieke oplossing.

Bijlagen

  File Modified
No files shared here yet.


  • No labels