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;
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 behandelen 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