Implementation Guide
ePA Common
Version 1.0.5-ballot.1 - draft

Generelle Prinzipien

Seiteninhalt:

Dieser Leitfaden verwendet die Schlüsselwörter MUSS, DARF NICHT, SOLL NICHT und KANN als deutsche Pendants des RFC 2119, um Anforderungen als Ausdruck normativer Festlegungen zu kennzeichnen.

Schnittstellenimplementierung

Der FHIR Data Service MUSS folgende HTTP Status Codes unterstützen:

Code Beschreibung Error Code Anmerkung
200 Successful operation - -
403 Requestor not authorized invalAuth no user session with valid ID-Token available
403 Requestor has no valid entitlement notEntitled -
403 Requestor role is not in the list of allowed user groups invalidOid -
403 Device registration does not exist unregisteredDevice if requestor role is oid_versicherter only
404 Health record is in state UNKNOWN or INITIALIZED noHealthRecord -
409 Health record is in state SUSPENDED statusMismatch siehe 'Wiederholungsintervalle'
500 Any other error internalError siehe 'Wiederholungsintervalle'
Tabelle: HTTP Status Codes für die FHIR-Data-Service-Antwortnachrichten
 Der FHIR Data Service MUSS Error Codes mit dem entsprechenden HTTP Status Code mit dem Media Type application/json nach folgendem Schema zurückgeben: 

    {
      "errorCode": "statusMismatch"
    }

Wiederholungsintervalle

Die folgenden Wiederholungsintervalle werden im Falle einer Fehlerantwort definiert:

  • 409 Conflict (statusMismatch)
    • etwa 24 Stunden
  • 500 Internal Error
    • etwa 10 Minuten

FHIR-spezifische Anforderungen

Eindeutigkeit von FHIR-Ressourcen

Der FHIR Data Service MUSS ausschließlich zeitbasierte Universally Unique IDentifier (UUID) gemäß RFC 4122 für logische IDs (d.h. FHIR-Element Resource.id) verwenden.

Must Support

Die Deklarierung als Must Support wird in der Anzeige der FHIR-Profile durch ein rotes “S” gekennzeichnet. Als Must Support deklarierte Elemente MÜSSEN durch jedes ePA-Client-System, welches diese Spezifikation implementiert, unterstützt werden. Das bedeutet:

Das ePA-Client-System, welches ein FHIR-Profil des FHIR Data Service implementiert, MUSS in der Lage sein, für jedes als Must Support gekennzeichnetes Element Werte einzutragen. Dies ist unabhängig von den Kardinalitäten, welche die entsprechenden Befüllungspflichten ausdrücken. Das ePA-Client-System, welches ein FHIR-Profil des FHIR Data Service implementiert, MUSS in der Lage sein, Instanzen zu verarbeiten, die Must-Support-Elemente enthalten, einschließlich Elemente mit fehlenden Daten, ohne einen Fehler zu erzeugen oder einen Absturz der Anwendung zu verursachen. Ein ePA-Client-System, welches ein FHIR-Profil des FHIR Data Service implementiert, MUSS in der Lage sein, Must-Support-Elemente je nach Anwendungsfall für die menschliche Nutzung anzuzeigen oder diese zu verarbeiten. Es muss dabei nicht jede Kodierung, genauso wie sie in der Instanz dargestellt ist, anzeigen, aber die Information darf nicht verloren gehen.

Serialisierung von FHIR Format-Repräsentationen

Der FHIR Data Service MUSS das FHIR-Format in JSON verarbeiten können. Der FHIR Data Service MUSS für Requests und Responses an den Schnittstellen den Content-Type application/fhir+json unterstützen.

Persistieren der Profilversion

Beim Erzeugen von FHIR-Ressourcen im FHIR Data Service MUSS dieser jede zu speichernde Ressource gegen das dazugehörige aktuelle Profil validieren. Die Information, gegen welches Profil in welcher Version geprüft wurde, MUSS der FHIR Data Service in der jeweiligen Ressource in Meta.profile speichern.