Document toolboxDocument toolbox

Afsprakenset release 1.4.0 > Architectuur en technische specificaties > Applicatie > Interfaces > Resource interface

Inleiding

Het resource interface hoort bij de hoofdfunctie Uitwisseling.

Op deze pagina staan alleen de verantwoordelijkheden inzake het resource interface die nog niet genoemd staan in:

  • de OAuth 2-specificatie;
  • de informatiestandaard van de Gegevensdienst die op het resource interface wordt aangesproken.


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.


2. Na ontvangst van een resource request, in UCI Verzamelen of UCI Delen, zal de Resource Server, indien in antwoord daarop een resource response dient te worden gedaan, na maximaal zestig (60) seconden dit resource response ter beschikking stellen aan de PGO Server. Dit gedrag van de Resource Server is gedurende minimaal 98,5% van de tijd beschikbaar.


3. Voor zover er in het verkeer tussen PGO Server en Resource Server in de use case-implementaties UCI Verzamelen en UCI Delen sprake is, in de stuurgegevens, van een gegevenselement dat tot de identiteit van de Zorggebruiker herleid kan worden, gebruiken zij daarvoor niets anders dan de OAuth-gegevens die zij in hun respectievelijke OAuth Client en OAuth Resource Server moeten uitwisselen. PGO Server, Authorization Server en Resource Server treffen goed beveiligde voorzieningen waarmee zij hieruit waar nodig zelf de identiteit van de Zorggebruiker kunnen vaststellen.

Toelichting

Met het oog op het borgen van de privacy en het zo eenvoudig mogelijk houden van de architectuur van het MedMij Afsprakenstelsel, wordt ervoor gekozen de identifier voor de Zorggebruiker onderweg zo betekenisloos mogelijk te houden. Alle betekenis wordt er ter weerszijden aan verbonden door raadpleging van interne registraties. Omdat de PGO Server, Authorization Server en Resource Server samen een OAuth-flow afhandelen, beschikken zij (na authenticatie van de Zorggebruiker) over tokens die de identiteit van de Zorggebruiker vertegenwoordigen, namelijk (eerst) de authorization code en (later) het access token. Buiten deze hoeft en zal er geen identificerende gegevenselementen in het verkeer worden opgenomen. Het FHIR-gegevenselement PatientID wordt niet gebruikt.

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

NummerImplementeert uitzonderingUitzonderingActieMeldingVervolg
Resource interface 1UC Verzamelen 6, UC Delen 6De 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 2UC Verzamelen 6, UC Delen 6Het 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 3UC 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 1 én uitzondering Resource interface 2.

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 InformatiestandaardDe flow mag worden voortgezet.


Het resource interface hoort bij de hoofdfunctie Uitwisseling.

Op deze pagina staan alleen de verantwoordelijkheden inzake het resource interface die nog niet genoemd staan in:

  • de OAuth 2-specificatie;
  • de informatiestandaard van de Gegevensdienst die op het resource interface wordt aangesproken.
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.
2.Na ontvangst van een resource request, in UCI Verzamelen of UCI Delen, zal de Resource Server, indien in antwoord daarop een resource response dient te worden gedaan, na maximaal zestig (60) seconden dit resource response ter beschikking stellen aan de PGO Server. Dit gedrag van de Resource Server is gedurende minimaal 98,5% van de tijd beschikbaar.
3.

Voor zover er in het verkeer tussen PGO Server en Resource Server in de use case-implementaties UCI Verzamelen en UCI Delen sprake is, in de stuurgegevens, van een gegevenselement dat tot de identiteit van de Zorggebruiker herleid kan worden, gebruiken zij daarvoor niets anders dan de OAuth-gegevens die zij in hun respectievelijke OAuth Client en OAuth Resource Server moeten uitwisselen. PGO Server, Authorization Server en Resource Server treffen goed beveiligde voorzieningen waarmee zij hieruit waar nodig zelf de identiteit van de Zorggebruiker kunnen vaststellen.

 Toelichting

Met het oog op het borgen van de privacy en het zo eenvoudig mogelijk houden van de architectuur van het MedMij Afsprakenstelsel, wordt ervoor gekozen de identifier voor de Zorggebruiker onderweg zo betekenisloos mogelijk te houden. Alle betekenis wordt er ter weerszijden aan verbonden door raadpleging van interne registraties. Omdat de PGO Server, Authorization Server en Resource Server samen een OAuth-flow afhandelen, beschikken zij (na authenticatie van de Zorggebruiker) over tokens die de identiteit van de Zorggebruiker vertegenwoordigen, namelijk (eerst) de authorization code en (later) het access token. Buiten deze hoeft en zal er geen identificerende gegevenselementen in het verkeer worden opgenomen. Het FHIR-gegevenselement PatientID wordt niet gebruikt.

4.

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

NummerImplementeert uitzonderingUitzonderingActieMeldingVervolg
Resource interface 1UC Verzamelen 6, UC Delen 6De 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 2UC Verzamelen 6, UC Delen 6Het 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 3UC 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 1 én uitzondering Resource interface 2.

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 InformatiestandaardDe flow mag worden voortgezet.