RFC0020 Uitbreiding logging eisen over gehele stelsel

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 persoonsgegevens 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; Volledig uitwerken NEN7513 eisen en introduceren van transactie/flow-concept aan het Afsprakenstelsel; 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	Former user (Deleted) (in opdracht van schmidt (Unlicensed))
Implementatietermijn	1.3.0
Motivatie verkorte RFC procedure (patch)	-

Goedkeuring

Beoordelaar	Datum	Toelichting	Beoordelaar	Datum	Toelichting
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
3 Dienstverleners concurreren op de functionaliteiten	Positief	13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders	Neutraal
4 Dienstverleners zijn aanspreekbaar door de gebruiker	Positief	14 Uitwisseling is een keuze	Neutraal
5 De persoon wisselt gegevens uit met de zorgaanbieder	Positief	15 Het MedMij-netwerk is gebruiksrechten-neutraal	Neutraal
6 MedMij spreekt alleen af wat nodig is	Negatief	16 De burger regisseert zijn gezondheidsinformatie als uitgever	Neutraal
7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener	Neutraal	17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld	Positief
9 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 de OAuth Client ook het MedMij-Request-ID Header Field op in het logbestand.

19b. Bij het loggen van ontvangen resource requests neemt de OAuth 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.

4. OAuth Resource Server en OAuth Client handelen uitzonderingssituaties inzake het resource interface af volgens onderstaande tabel.

Nummer

Implementeert uitzondering

Uitzondering

Actie

Melding

Vervolg

Resource interface 1 UC Verzamelen 6, UC Delen 6 De validatie van het access token door Resource Server faalt. Resource Server informeert PGO Server over deze uitzondering. PGO Server informeert daarop Zorggebruiker hierover. als OperationOutcome conform FHIR-specificatie, analoog aan uitzondering Resource interface 2, maar met issue type "security" of "suppressed". Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering.

Resource interface 2 UC Verzamelen 6, UC Delen 6 Het resource request bevat geen of een ongeldig MedMij-Request-ID. Resource Server informeert PGO Server over deze uitzondering. PGO Server informeert daarop Zorggebruiker hierover. Conform HTTP specificatie met met status code 400 "Foute aanvraag". Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering.

Resource interface 3

UC Verzamelen 5, UC Delen 5

Resource Server kan in de request niet, niet geheel of niet tijdig voorzien, om redenen anders dan uitzondering Resource interface 2 of uitzondering Resource interface 3.

Zie ook de toelichting op Beschikbaarheids- en ontvankelijkheidsvoorwaarde.

Resource Server informeert PGO Server over deze uitzondering. PGO Server informeert daarop Zorggebruiker hierover.

conform de specificatie van de gebruikte Informatiestandaard

De flow mag worden voortgezet.

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
Implementatielast voor deelnemers	Hoog	Hoog		Gezien belang in overleg met deelnemers bepalen wanneer dit ingevoerd moet worden. RFC beperken tot minimum.
Impact op gegevensdienst/informatiestandaard	Middel	Middel		Gezamenlijk optrekken met informatiearchitecten (Nictiz). Kiezen voor generieke oplossing.

Bijlagen

	File	Modified

No files shared here yet.