Consolidatie van responses

Consolidatie van n responses naar één FHIR-result

Inleiding

Resource Broker VnC kan een interactie, eventueel na transformatie, uit moeten zetten bij één GBZ-applicatie of bij meerdere GBZ-applicaties.

De volgende situaties worden ondersteund.

Een FHIR client wordt d.m.v. HTTP statuscodes en FHIR OperationOutcomes voorzien van informatie omtrent de afhandeling van verzonden requests. Een FHIR client is hierbij vooral geïnteresseerd informatie over de uiteindelijke afhandeling van haar requests, d.w.z. het daadwerkelijke resultaat. Bijv. een standaard FHIR resource client verwacht als antwoord op een FHIR-create een HTTP 201 statuscode die aangeeft dat de resource succesvol is gecreëerd in een resource server. De door RB VnC geretourneerde statuscode dient derhalve informatie te verschaffen die zo dicht als mogelijk ligt bij het daadwerkelijke resultaat.

• Wanneer een interactie wordt uitgezet bij één GBZ-applicatie, dan wordt de statuscode die RB VnC retourneert volledig gebaseerd op de response van de betreffende GBZ-applicatie.

• Wanneer een interactie wordt uitgezet bij meerdere GBZ-applicaties, dan wordt statuscode van RB VnC gebaseerd op alle ontvangen responses.

Onderstaande regels gelden zowel voor ontvangen statuscodes in de HTTP-response van individuele interacties, als voor geïncludeerde statuscodes in batch-response of transaction-response Bundles bij sets van interacties.

Consolidatieregels

Algemeen geldende regels voor alle interacties

1. Eventueel ontvangen, en na transformatie verkregen, OperationOutcomes worden altijd geïncludeerd in de geconsolideerde response. Voor een interactie die is uitgezet bij meerdere GBZ-applicaties wordt hier ook het appID aan toegevoegd.

2. Wanneer (eventueel na transformatie) een FHIR searchset Bundle wordt verkregen, met een absolute URL in een fullUrl, reference of link element van het type “self”, “first”, “next”, “previous” of “last”, dan dient de FQDN van deze absolute URL overeen te komen met de FQDN van de Resource Server (GBZ-applicatie) die werd bevraagd. Indien dit niet het geval is, dan dient als statuscode van deze response 500 te worden gehanteerd en wordt een OperationOutcome met issue.code "business-rule” en issue.diagnostics “resultaat bevat URL’s die afwijken van FQDN van Resource Server”. Indien de interactie was uitgezet bij meerdere GBZ-applicaties, dan wordt hier ook het appID aan toegevoegd.

Regels voor alle interacties, uitgezonderd $get-aorta-data

1. Wanneer de statuscode die wordt ontvangen van een GBZ-applicatie, afwijkt van de uiteindelijk door RB VnC te retourneren statuscode, dan voegt RB VnC aan de response, een OperationOutcome toe met daarin het appID van de betreffende GBZ-applicatie en de statuscode die daadwerkelijk werd ontvangen van deze GBZ-applicatie.

Verwerking van v3-responses

1. Bij ontvangst van een statuscodes anders dan 200 en/of bij ontvangst van een SOAP-fault, wijzigt RB VnC (d.w.z. de XSG namens RB VnC) de statuscode naar 500 en genereert hierbij een v3-foutcode RTEDEST. De Transformatie Server zet de v3-foutcode vervolgens om in een FHIR OperationOutcome.

2. RB VnC includeert alle, na transformatie verkregen OperationOutcomes, in de geconsolideerde response. Vervolgens wordt de te hanteren statuscode voor deze response als volgt vastgesteld: 

   1. wanneer het resultaat na transformatie een OperationOutcome bevat met issue.code "suppressed", dan dient als statuscode van deze response 403 te worden gehanteerd..

   2. wanneer het resultaat na transformatie tenminste één OperationOutcome oplevert, en geen OperationOutcome met issue.code "suppressed" bevat, en géén reguliere resource-instanties bevat, dan dient als statuscode van deze response 500 te worden gehanteerd.

   3. in alle overige gevallen wordt een 2xx gehanteerd, d.w.z.

      1. wanneer de response een antwoord is op een FHIR-create interactie, dan wordt de statuscode 201

      2. wanneer de response een antwoord is op een ander type FHIR interactie, dan wordt de statuscode 200

Verwerking van (na transformatie verkregen) FHIR-responses

Afhandeling van (na transformatie verkregen) FHIR-response bij een FHIR-interactie die is uitgezet naar één GBZ-applicatie:

1. RB VnC retourneert de statuscode die het ontvangt, inclusief ontvangen OperationOutcomes en inclusief ontvangen AORTA-Version , WWW-Authenticate en voor FHIR relevante HTTP response headers (bijv. Location). Uitzonderingen:

   1. wanneer een 4xx statuscode wordt ontvangen, waarvan zeker is dat ze wordt veroorzaakt door RB VnC zelf, dan dient als statuscode van deze response 500 te worden gehanteerd.  Dit geldt voor statuscodes 400 en 401.

   2. wanneer een 5xx statuscode wordt ontvangen, dan krijgt de te retourneren statuscode altijd de waarde 500.

2. Wanneer de response een OperationOutcome bevat met issue.code "suppressed", en een statuscode 403 wordt geretourneerd, dan dient ook een WWW-Authenticate HTTP response header, met als auth-scheme "Bearer" en een error attribuut met waarde "access_denied", te worden geretourneerd.

Afhandeling van (na transformatie verkregen) FHIR-responses bij ontvangen FHIR-search die is doorgezet naar meerdere GBZ-applicaties (organisatie-search):

1. Indien gegevens zijn opgeleverd: 200 gaat boven 4xx (zodat gegevens die wel werden verkregen kunnen worden geretourneerd)

2. Indien geen gegevens zijn opgeleverd: 4xx gaat boven 200 (nu melden aan client dat zij een fout heeft gemaakt)

3. 2xx gaat boven 5xx (zodat eventueel verkregen gegevens kunnen worden geretourneerd)

4. 4xx gaat boven 5xx (zodat de client weet dat zij een fout heeft gemaakt)

5. Wanneer verschillende 4xx codes worden ontvangen, dan wordt dit beschouwd als een fout, en wordt de statuscode 500 geretourneerd

6. Wanneer alle GBZ-applicaties een statuscode 5xx retourneren, dan wordt als statuscode 500 geretourneerd, ongeacht of de ontvangen statuscodes allemaal gelijk zijn aan elkaar of niet

7. Wanneer de geconsolideerde response een OperationOutcome bevat met issue.code "suppressed", en een statuscode 403 wordt geretourneerd, dan dient ook een WWW-Authenticate HTTP response header, met als auth-scheme "Bearer" en een error attribuut met waarde "access_denied", te worden geretourneerd.

Afhandeling van (na transformatie verkregen) FHIR-responses bij ontvangen $get-aorta-data die is vertaald naar één of meerdere FHIR-search interacties gericht aan één of meerdere GBZ-applicaties:

1. De statuscode die wordt ontvangen van een GBZ-applicatie wordt door RB VnC, middels een OperationOutcome met daarin het appID van de betreffende GBZ-applicatie en de statuscode die werd ontvangen, toegevoegd aan de response.

2. Ontvangst van een 4xx wordt beschouwd als een succesvol uitgevoerde search bij de betreffende GBZ-applicatie.

3. Ontvangst van een 5xx wordt beschouwd als een succesvol uitgevoerde search bij de betreffende GBZ-applicatie.

4. Een timeout of verbindingsfout wordt beschouwd als een succesvol uitgevoerde search bij de betreffende GBZ-applicatie.

5. Indien tenminste één search als succesvol kon worden beschouwd, dan wordt een 200 geretourneerd.

6. Indien geen enkele search als succesvol kon worden beschouwd dan wordt een 500 geretourneerd.

Wanneer een feitelijk, door resource server, geretourneerde statuscode moet worden toegevoegd aan een response, dan wordt dit gedaan in een OperationOutcome met:

• voor statuscode 2xx: issue.severity=information, issue.code=processing. en issue.diagnostics="<appID van resource server>:<statuscode van resource server>", OF

• anders: issue.severity=warning, issue.code=processing. en issue.diagnostics="<appID van resource server>:<statuscode van resource server>".

Search-results die worden ontvangen dienen als volgt te worden geconsolideerd tot één search-result:

1. Het systeem stopt het alle Entries die zijn ontvangen, in één nieuwe Bundle en retourneert deze ene Bundle. Naast de ontvangen Entries bevat de te retourneren Bundle de volgende attributen:

   1. type = "searchset"

   2. total (het totaal aantal Entries dat conform de FHIR specificaties moet worden meegeteld)

Voorbeelden

Voorbeelden voor consolidatie van statuscodes bij opvragen van gegevens zijn opgenomen in onderstaande tabel.

Transformatie van FHIR-results naar v3-responses

Onderstaande tabel toont de transformatie.