Implementation Guide
ePA Basisfunktionalitäten
Version 1.0.5 - release

Generelle Prinzipien

Seiteninhalt:

Dieser Implementation Guide 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.

Der Audit Event Service MUSS als Ausprägung eines FHIR Data Service sämtliche Anforderungen aus [IG_TICommon#Audit] berücksichtigen.

Schnittstellenimplementierung

Der FHIR Data Service in der ePA 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 in der ePA MUSS Fehlercodes mit dem entsprechenden HTTP-Statuscode im Media Type application/json nach folgendem Schema zurückgeben: 

    {
      "errorCode": "statusMismatch"
    }
 Der FHIR Data Service MUSS für die Fehlermeldung SVC_IDENTITY_MISMATCH den HTTP-Statuscode 403 zurückgeben, wenn die Telematik-ID im ID-Token oder die KVNR im x-insurantid-HTTP-Header nicht mit den FHIR-Daten übereinstimmt.

Wiederholungsintervalle

Die folgenden Wiederholungsintervalle werden im Falle einer Fehlerantwort definiert:

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

Audit Event Service: Schnittstellenimplementierung

Der Audit Event Service MUSS sämtliche FHIR-Schnittstellen unter den folgenden Pfaden verfügbar machen:

  • [base]/epa/audit/api/v1/fhir/
  • [base]/epa/audit/render/v1/pdf
wobei [base] einem gültigen Pfadnamen eines VAU-Kanals nach folgendem Schema entsprechen muss: http://epa4all Der Audit Event Service MUSS die in diesem Implementation Guide definierten Schnittstellen (d.h. Query API: AuditEvent und Render API: PDF Audit) implementieren und dabei die Vorgaben der [FHIR-Spezifikation] berücksichtigen. Der Anbieter des ePA-Aktensystems MUSS die Konformität in einem Zulassungsverfahren nachweisen. Das ePA-Client-System (d.h. Primärsystem Ombudsstelle oder ePA-FdV) MUSS die Nutzung der die in diesem Implementation Guide definierten Schnittstellen (d.h. Query API: AuditEvent und Render API: PDF Audit) implementieren.

FHIR-spezifische Anforderungen

Rückgabewerte

Der Audit Event Service MUSS die Funktion GET [base]/epa/audit/api/v1/fhir/metadata implementieren. Diese Funktionalität stellt sicher, dass bei einem Aufruf von /metadata das FHIR CapabilityStatement mit dem Namen EPAAuditEventServer des Servers zurückgegeben wird. Dieses Capability Statement bietet eine detaillierte Beschreibung der Fähigkeiten des ePA Audit Event Service und ist entscheidend für das Verständnis der unterstützten FHIR-Funktionalitäten.