Page Comparison

Dienstverlener persoon biedt aan Persoon, in het kader van de toepasselijke Dienstverleningsovereenkomst, een geautomatiseerde rol ter gebruik, hier genoemd: DVP Server. Eén Dienstverlener persoon biedt één of meerdere DVP Servers en elke DVP Server wordt door één Dienstverlener persoon geboden.

Dienstverlener aanbieder biedt een geautomatiseerde rol Authorization Server, voor het namens Aanbieders uitwisselen van gezondheidsinformatie met DVP Server. Deze rol wordt altijd gecombineerd met een Resource Server .

Als MedMij-verkeer is gedefinieerd: al het gegevensverkeer in het kader van enige functie-implementatie, onmiddellijk tussen twee verschillende van de vier volgende soorten rollen, namelijk:

• ten eerste DVP Server,
• ten tweede User Agent,
• ten derde Authorization Server of Resource Server en
• ten vierde MedMij Registratie,

met dien verstande dat:

• in deze rollen telkens begrepen zijn de door hen eventueel verzorgde respectievelijke Autorisatie-rollen, 
• van deze rollen telkens uitgesloten zijn de door hen eventueel verzorgde Authenticatie-rollen, en
  
• in deze rollen, met betrekking tot de functie-implementaties, telkens inbegrepen zijn de Nodes waarop zij functioneren.

Authorization Server valideert elke nieuwe verkregen OAuth Client List (OCL)tegen het XML-schema van de OAuth Client List.

De OAuth Client realiseert de volgende beveiligingsmaatregelen, conform RFC 6819:

De OAuth Authorization Server realiseert de volgende beveiligingsmaatregelen, conform RFC 6819:

1

Deelnemers richten de logbestanden in zoals beschreven bij Logging interface, de AVG en NEN 7513:2018.

2

De bewaartermijnen voor de verschillende soorten loggegevens staan beschreven op de pagina A.12.4.1 Gebeurtenissen registreren van het Normenkader.

Na afloop van de bewaartermijn van loggegevens moeten Deelnemers de loggegevens vernietigen.

3

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.

4

Bij het loggen van ontvangen resource requests 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.

De vastgelegde logregels worden near-realtime (kleine logbestanden, maar met hoge frequentie) of in grotere logbestanden (minimaal eenmaal per uur) aangeleverd. Maximaal één uur na het vastleggen van de gebeurtenis moet de logregel zijn aangeleverd bij MedMij.

Logregels die met MedMij gedeeld worden mogen geen inhoudelijke gegevens over de Persoon bevatten, niet direct herleidbaar zijn naar de Persoon en mogen alleen metagegevens over de gebeurtenissen bevatten.

De aangeboden logbestanden dienen te bestaan uit niet eerder succesvol aangeleverde logregels. Het aanbieden van duplicaat regels/logbestanden dienen door de deelnemer tot een minimum te worden beperkt.

core.logging.104

Aanbevolen wordt om de logregels en logbestanden die niet succesvol aangeleverd kunnen worden alsnog aan te bieden op het eerst volgende moment nadat de uitdaging is verholpen.

Aanbevolen wordt dat in het geval dat er in het tijdsbestek van één uur na het leveren van een logbestand geen nieuwe gebeurtenissen worden vastgelegd, de deelnemer gedurende het voortbestaan van deze situatie minimaal één keer (1x) per uur een leeg logbestand aanlevert.

core.logging.106

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.

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.

De Resource Server:

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.

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

Voordat de door de deelnemer aangeleverde logregels worden ontvangen door de loggingscomponent wordt een technische toetsing uitgevoerd op deze logregels. Krijgt de deelnemer een code 200 terug van de Logging Interface dan is het aanleveren van logregels geslaagd en is de data opgeslagen. Bij elke andere code was het aanleveren onsuccesvol en moet de batch opnieuw aangeleverd worden.

De endpoint van de Logging interface heeft op jaarbasis een beschikbaarheid van minimaal 99,5%. MedMij laat, na het niet beschikbaar raken van de MedMij Logging interface, maximaal 43 kantooruren (2580 minuten) verstrijken voordat het weer beschikbaar is.

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.