Erwartetes Fehlerverhalten
Fachliche Fehler
"Fachliche Fehler" umfasst alle Fehlerarten, die in der Regel durch Benutzereingaben verursacht werden.
Fachliche Fehler sollten immer durch einem OperationOutcome kommuniziert werden. In der Endanwendung sollte der Fehlertext (issue.details.text
) dem Benutzer angezeigt werden, damit dieser entsprechend reagieren und z.B. seine Eingabe korrigieren kann.
Wenn sich der Fehler auf eine Einzelanfrage bezieht, sollte der OperationOutcome auf die angefragten Versicherungsdaten referenzieren (über issue.expression
und durch Platzierung in der entsprechenden Response-Composition), damit der Fehler in der Endanwendung an passender Stelle angezeigt werden kann.
Fehler | OperationOutcome |
---|---|
Leistungserbringer (author) ist nicht bekannt | OperationOutcome mit ErrorStatus LeistungserbringerUnbekannt |
Leistungserbringer (author) hat für den AufrufKontext keinen gültigen Vertrag bzw. ist innerhalb des Vertrags für diese Daten nicht berechtigt | OperationOutcome mit ErrorStatus LeistungserbringerKeinVertrag |
Versicherungs-IK des Versicherten ist nicht bekannt, KVNR des Versicherter ist nicht bekannt oder Geburtsdatum ist nicht korrekt | OperationOutcome mit ErrorStatus VersicherterUngueltig |
Versicherter hat keinen aktiven Leistungsanspruch | OperationOutcome mit ErrorStatus VersicherterOhneAnspruch |
sonstige fachliche Fehler | OperationOutcome mit ErrorStatus FachlicherFehler |
Technische Fehler
"Technische Fehler" umfasst Fehlerarten, die nicht direkt von konkreten Inhalten abhängen oder aus unbehandelten Ausnahmen bei der Verarbeitung stammen.
Dazu zählen z.B. Exceptions, Timeouts, Authentifizierungsfehler auf Netzwerkebene, sonstige Netzwerk-Fehler, zeitweise Nichtverfügbarkeit, nicht spezifikationsgerechte Anfragen, zu große Anfragen.
Der Fehler sollte dabei so spezifisch wie möglich in der Response angegeben werden. Das heißt, wenn sich der Fehler auf eine Einzelanfrage zurückführen lässt, sollte ein Bundle mit OperationOutcome erstellt werden, dass auf die Versicherungsdaten der Anfrage referenziert (über issue.expression
und durch Platzierung in der entsprechenden Response-Composition).
Damit soll sichergestellt werden, dass der Fehler passend zum Versicherten-Datensatz angezeigt werden kann und weitere, parallele Anfragen weiter verarbeitet werden können.
Bezieht sich der Fehler auf die gesamte Anfrage und es ist noch eine strukturierte Antwort möglich, dann sollte ein OperationOutcome ohne Referenz verwendet werden. Sollte keine strukturierte Antwort mehr möglich sein, sollten geeignete HTTP-Status-Codes verwendet werden, die Hinweise auf die Ursache geben.
Die Fehlertexte (issue.details.text
) von technischen Fehlern sollen nicht dem Benutzer in der Endanwendung präsentiert werden. Oft sind darin technische Details enthalten, die für Endnutzer nicht vorgesehen sind. Stattdessen sollen diese Fehlertexte für Analysen in Logs festgehalten werden.