...
001. Foutafhandeling moet informatie bevatten die geschikt is voor de volgende doelgroepen (zie ook ERR 006):
a. de eindgebruiker die een korte beschrijvend bericht nodig heeft;
b. de applicatie ontwikkelaar die gedetailleerde informatie nodig heeft om de applicatie te kunnen debuggen;
c. de applicatie gebruiker die een foutcode (HTTP-statuscode) nodig heeft voor eventuele foutherstelacties en;
d. de ondersteuning die gedetailleerde informatie en/of trefwoorden nodig heeft uit de berichten of interactie, waarop ondersteuning kan worden gegeven
002. Voeg geen stack-traces toe in meldingen.
003. Gebruik bestaande HTTP-statuscode op een correcte manier:
a. retourneer NIET alleen de HTTP-statuscode 200 (OK), ongeacht of het succesvol dan wel een fout betreft
b. gebruik de range 2xx, wanneer een aanvraag (volledig) verwerkt en geslaagd is.
c. gebruik de range 3xx, wanneer de client aanvullende acties moet ondernemen (omleiding) om een bepaalde aanvraag te voltooien. De vereiste actie kan worden uitgevoerd zonder interactie met de gebruiker, als het tweede verzoek een GET of HEAD is.
d. gebruik de range 4xx, wanneer de aanvraag niet (volledig) slaagt en de client deze aanvraag kan laten slagen door de aanvraag aan de client kant aan te laten passen.
e. gebruik de range 5xx, wanneer de aanvraag niet (volledig) slaagt door een interne foutmelding aan de server kant
004. Bij authenticatie-, autorisatie-, verificatie en omleiding fouten moet de dienstverlener zo min mogelijk informatie weggeven. Het retourneren van te veel informatie kan details over de toegang blootleggen die NIET naar cliënten gecommuniceerd mogen worden.
005.Als de fout niet onder het vorige punt (4) valt, neem zoveel mogelijk context op in de melding en wees beschrijvend.
...
# | Eis | FHIR Resource service | Bron-applicatie | Domein |
|---|---|---|---|---|
| 001 | De FHIR resource service implementeert de FHIR API en volgt zoveel mogelijk de HTTP status codes zoals in deze API worden vastgelegd. | x | ||
| 002 | Foutcodes moeten uitgebreid en goed beschrijvend zijn, met uitzondering van fouten bij de foutstatus 401 Unauthorized en 403 Forbidden. | x | ||
| 003 | De FHIR api geeft in het response een status code mee. Deze status codes staan niet vast, de FHIR resource service mag tot bepaalde hoogte zelf bepalen welke code in welke situatie van toepassing is. Wel moet de FHIR resource service rekening houden met de ranges:
| x | ||
| 004 | Uitzondering op de vorig regel zijn autorisatiefouten: hiervoor geldt:
| x | ||
| 005 | De FHIR OperationOutcome FHIR resource kan geretourneerd worden bij 4xx- en/of 5xx-reactie, maar dit is niet vereist |
...
a. issue.severity (verplicht)
b. issue.code (verplicht)
c. issue.details (optioneel in FHIR, maar indien aangegeven in onderstaande tabel verplicht te vullen conform de aangegeven valueset)
d. issue.diagnostics (optioneel in FHIR, optioneel binnen Koppeltaal, waarbij altijd de beveiliging van de FHIR Resource Provider in ogenschouw moet worden genomen).
...
| . | x | |||
| 006 | Een client applicatie die FHIR resources van de FHIR resource service ophaalt (zelfstandig of na een update vanuit een abonnement) en deze niet goed kan verwerken in de eigen systemen ZOU hiervoor een AuditEvent voor moeten aanmaken. DIt AuditEvent informeert de andere applicaties in de infrastructuur dat de applicatie de gegevens niet goed heeft verwerkt. | x | ||
| 007 | Het AuditEvent dat door de client applicatie wordt aangemaakt dient als waarde voor X-Correlation-Id (extension.correlation-id) de originele X-Request-Id in te voeren, indien aanwezig. De waarde voor de X-Trace-Id (extension.trace-id) dient overgenomen te worden van de originele X-Trace-Id. | x | ||
| 008 | In het AuditEvent wordt onderscheid gemaakt tussen verschillende type fouten, zie onderdeel 'Het fouttype' ter referentie. | x | ||
| 009 | Er vind eerst controle plaats op Authenticatie, daarna mag de Resource gecontroleerd worden op fouten | x |