TI-Support -

Release Notes. Troubleshooting-Hinweise.

Offizielle Dokumentationen. Hilfreichen Links.

Telematikinfrastruktur im Blick!

Zentrale Anlaufstelle für die _fbeta-TI-Produkte

Inhaltsverzeichnis

TI-Support
- Mögliche Fehlerquellen
- Lösungen
Nützliche Links & Ressourcen
Aktuelle Updates und Release Notes
_ hub: weitere Infos

TI-Support

Störung? – Diese Seite unterstützt Sie dabei, Störungen bei TI-Produkten zu identifizieren und gezielt Unterstützung zu erhalten.
Zudem finden Sie hier Produktinformationen, Release Notes und Anleitungen für Debugging und Informationsbeschaffung.

Die Telematikinfrastruktur (TI) besteht aus verschiedenen Komponenten …

… unterschiedlicher Anbieter. Während der Identity Provider (IDP) von der gematik betrieben wird, stammen Konnektoren und Aktensysteme von TI-Enablern und Systemanbietern wie RISE oder IBM. Eine API – wie beispielsweise die ePA-API von _fbeta –, die die einzelnen TI-Komponenten für den Verbindungsaufbau zur elektronischen Patientenakte (ePA) bündelt, wird beim Primärsystemhersteller betrieben. Treten Störungen in einem der beteiligten Verbindungswege auf, beeinträchtigt dies den gesamten ePA-Verbindungsaufbau.

Mögliche Fehlerquellen

Beim Schreiben in die ePA können Fehler vorkommen. Einen Überblick gibt die nachfolgende Darstellung.

Lösungen

Hier finden Sie Erläuterung zu den Fehlern und Hinweise dazu, was Sie zur Fehleranalyse und -behebung tun können.

1. (_fbeta) ErrorCode: KONNEKTOR_INIT_FAILED

Es kann keine Verbindung vom Backend zum Konnektor aufgebaut werden.

Vorgehen zur Fehleranalyse

Verbindung mit Postman testen
Laden Sie die Postman-Collection herunter (Download Postman-Collection) .
Führen Sie den Aufruf „3.0 – Konnektor-Utils / Konnektor Endpoint“ aus.
Bei einer erfolgreichen Verbindung wird der StatusCode 200 zurückgegeben.

Wenn keine Verbindung hergestellt werden kann

Prüfen Sie, ob Postman korrekt konfiguriert ist.
Ist das PVS.p12-Zertifikat (erhalten mit dem Konnektor) in den Postman-Settings hinterlegt?
Ist der Host zum Zertifikat korrekt konfiguriert?
Beispiel für RISE: konnektor-2.ru.tiaas.rise-ti.de:443

Kontrollieren Sie die Variablen-Einstellungen

Öffnen Sie die Collection „ePA 3.x“ (Root-Ordner).
Wählen Sie den Reiter Variables.
Stellen Sie sicher, dass die Werte für Mandat_ID, Workplace_ID, Clientsystem_ID den Einträgen im Arbeitsplatz-Bereich Ihres Konnektors entsprechen.

Sollten Sie weiterhin nicht den Status 200 erhalten

Prüfen Sie ihr VPN, ist das TI-VPN aktiv? Können die Target-IPs gepingt werden?
Starten Sie VPN, Kartenterminal und Konnektor-UI (TIaaS) neu.
Prüfen Sie ob momentan Störungen in der TI oder bei dem Konnektor Anbieter bestehen. (Nützliche Links & Ressourcen)

Sollte weiterhin keine Verbindung bestehen, dann melden Sie sich bei Ihrem Konnektoranbieter um weitere Supportvorgänge zu erhalten (z.B. RISE oder IBM).

2. (_fbeta) ErrorCode: CARD_OPERATION_ERROR

Das Backend kann zwar eine Verbindung zum Konnektor aufbauen, jedoch wird die SMC-B-Karte nicht erkannt.

Vorgehen zur Fehleranalyse

Karten im Kartenterminal prüfen
Kontrollieren Sie, ob die Karten physisch korrekt eingesteckt sind.
Achten Sie auf das Kartensymbol oben links im Terminal-Display: Leuchtet es blau auf, wenn der entsprechende Kartenplatz belegt ist?

Überprüfung mit Postman (GetCards-Operation)

Nutzen Sie die Postman-Collection aus Schritt (1).
Führen Sie die Operation „GetCards“ aus.
Prüfen Sie im Response-Body, ob <ns6:CardType>SMC-B</ns6:CardType> enthalten ist.
Hinweis: Die „GetCards“-Operation gibt bei bestehender Verbindung immer Statuscode 200 zurück, zeigt aber nicht zwingend die gesteckten Karten an.
Karten-Zuordnung in der Konnektor-UI (TIaaS)

Öffnen Sie die Konnektor-UI.
Gehen Sie zu „Arbeitsplatz“ und prüfen Sie, ob eine SMC-B dem entsprechenden Mandaten zugeordnet ist. Ist keine SMC-B zugeordnet, schlägt die „GetCards“-Operation fehl.

Kartenverfügbarkeit in der Konnektor-UI prüfen

Wechseln Sie in der UI zum Bereich „Karten“.
Falls die Karten dort nicht angezeigt werden:, Warten Sie einige Minuten und versuchen Sie es erneut. Starten Sie ggf. das Kartenterminal, die Konnektor-UI (TIaaS) sowie das VPN neu.

2.5 ErrorCode: CARD_PIN_NOT_VERIFIED

Die _fbeta-ePA-API überprüft im ersten Schritt, ob Ihre SMC-B-Karte aktuell durch Eingabe der PIN verifiziert und freigeschaltet ist, da sonst ein Schreiben in die ePA nicht möglich ist. 
Tritt dieser Fehler auf, wurde zwar eine SMC-B gefunden, diese aber nicht als verifiziert erkannt. Das kann zum Beispiel nach einem Neustart des Kartenterminals oder bei Verbindungsabbrüchen passieren. Bitte geben Sie die PIN erneut über das Kartenterminal oder dessen WebUI ein. 
Werden Karten weiterhin nicht erkannt oder zugeordnet, wenden Sie sich bitte an Ihren Konnektoranbieter.

3. (_fbeta) ErrorCode: VAU_INIT_FAILED

Das Backend kann eine Verbindung zum Konnektor aufbauen, kann die Karten korrekt lesen, es ist aber nicht möglich ein VAU-Kanal aufzubauen.

Vorgehen zur Fehleranalyse

Sicher gehen ob Fehler aus 1 und 2 nicht bestehen.
Prüfen ob am Aktensystem eine Störung besteht: siehe [Monitoring RU] und [News Aktensystembetreiber]

Wenn keine Störung angezeigt wird, dann melden Sie sich bei dem angewählten Aktensystembetreiber für weiterführenden Support.(z.B. RISE oder IBM)

4. (_fbeta) ErrorCode: IDP_REQUEST_ERROR

Das Backend kann eine Verbindung zum Konnektor aufbauen, kann die Karten korrekt lesen, und baut einen VAU-Kanal zum Aktensystem auf, der IDP-Server gibt allerdings beim AuthN/AuthZ-Verfahren ein Fehler zurück (Statuscode 500 – Internal Server Error/403 Unauthorized).

Fehleranalyse

Sichergehen ob Fehler aus 1 und 2 nicht bestehen.
Prüfen ob am IDP-Server eine Störung besteht/gemeldet wurde; siehe [IDP Monitoring].

Falls keine Störung am IDP-Server bekannt ist: Melden sie sich bei uns per Mail: siehe Kontakt & Eskalation.

5. (_fbeta) ErrorCode: DOC_UPLOAD_ERROR

Das Backend kann eine Verbindung zum Konnektor aufbauen, kann die Karten korrekt lesen, und baut einen VAU-Kanal zum Aktensystem auf, der IDP-Server gibt allerdings beim AuthN/AuthZ-Verfahren den Statuscode 200 zurück und authentifiziert die SMC-B bei der ePA, das schreiben in die ePA führt zu einem Fehler (Statuscode 500 – Internal Server Error/403 Unauthorized).

Fehleranalyse

Sichergehen ob Fehler aus 1 und 2 nicht bestehen.
Prüfen ob am Aktensystem eine Störung besteht. Siehe [Monitoring RU] und [News Aktensystembetreiber]
Wenn keine Störung angezeigt wird, dann melden Sie sich bei dem angewählten Aktensystembetreiber für weiterführenden Support.(z. B. RISE oder IBM)

6. (_fbeta) ErrorCode: EPA_NOT_ENTITLED

Das Schreiben auf die ePA erfolgt, ohne dass sämtliche Fehler aus 1 bis 5 aufgetreten sind. Trotzdem wird der Errorcode „EPA_NOT_ENTITLED“ zurückgegeben.

Fehleranalyse

Prüfen ob die KVNR korrekt ist.
Den Besitzer der KVNR darauf hinweisen, die Telematik-ID (letzten 8 Zahlen auf der SMC-B oben rechts) für das Schreiben auf die ePA freizugeben.

Nützliche Links & Ressourcen

Monitoring PU

Offiziell auf dem Fachportal der Gematik: TI-Status
Grafana: PU-Monitoring

Monitoring RU

Grafana: RU-Monitoring
Monitoring TU: Uns ist derzeit kein Monitoring der TU bekannt, als Best Practice verweisen wir auf (R3) die Newsseite der Aktensystem-Betreiber

Anstehende Test-Wochen

Während Testwochen kommt es vermehrt zu Störungen der Infrastruktur.

Weitere Informationen zu den ECC-Testwochen: Informationen zu ECC-Testwochen

ePA3 Beispielimplementierung

GitHub: _fbeta ePA3 Beispielimplementierung

Hinweis: Die Beispielimplementierung steht unter der Creative Commons Attribution-NoDerivatives 4.0 International (CC BY-ND 4.0)-Lizenz. Sie dient ausschließlich als Unterstützung bei der Entwicklung sowie als Referenz für die von _fbeta betreuten und angebotenen ePA3-API.

IDP Monitoring

Grafana: IDP-Monitoring

Grafana: Sektorale-IDPs-Monitoring

Kontakt & Eskalation

Sollten unsere Troubleshooting-Hinweise nicht weiterhelfen, steht Ihnen unser ePA-TI-Team gerne persönlich zur Seite.

Für unsere Kunden: Bitte nutzen Sie die Mailadresse epa@fbeta.de
So können wir Ihr Anliegen schnellstmöglich bearbeiten.

Für Interessierte und Noch-nicht-Kunden: Schreiben Sie uns gerne an info@fbeta.de
Wir kümmern uns um Ihr Anliegen und unterstützen Sie bei Ihren Fragen.

Aktuelle Updates und Release Notes

ePA-Service: Release 1.1

Release 1.1.2

Features

Über die Umgebungsvariable UVICORN_WORKERS kann nun die Anzahl der Uvicorn-Worker als Integer festgelegt werden. Diese bestimmen, wie viele Worker parallel Anfragen an die ePA-API verarbeiten (Default-Wert: 1).¹

API-Änderungen

/send-document/:
Das Antwortfeld details des Dokumenten-Uploads wird jetzt korrekt als JSON formatiert zurückgegeben und nicht mehr als Text. Außerdem wurden die Felder documentEntryEntryUUID und submissionSetEntryUUID hinzugefügt.

Vorher

Response:  {
    "message": "Document upload failed with errors: ...",
    "success": false,
    "details": "{\"http_status\": \"HTTP/1.1 200 OK\", \"headers\": {\"Content-Type\": \"multipart/related; type=\\\"application/xop+xml\\\"; boundary=\\\"uuid:542c89ab-a2e2-45bd-bad8-e75363bc6463\\\"; start=\\\"<root.message@cxf.apache.org>\\\"; start-info=\\\"application/soap+xml\\\"\"}, \"body\": {\"ResponseSlotList\": null, \"RegistryErrorList\": {\"RegistryError\": [{\"_value_1\": null, \"codeContext\": \"urn:uuid:86d14b30-c245-4d97-93dd-f93adfbcd9ed\", \"errorCode\": \"XDSDuplicateDocument\", \"severity\": \"urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error\", \"location\": null}], \"highestSeverity\": \"urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error\"}, \"status\": \"urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure\", \"requestId\": null, \"Status\": {\"Result\": \"Ok\", \"Error\": null}}}"
}

Jetzt

Response:  {
    "message": "Document upload failed with errors: ...",
    "success": false,
    "details": {
        "ResponseSlotList": null,
        "RegistryErrorList": {...},
        "status": "urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure",
        "requestId": null,
        "Status": { ... }
    },
    "documentEntryEntryUUID": "...",
    "submissionSetEntryUUID": "..."
}

Das Feld detail.requestId in Fehlerfällen wurde in detail.entryUUID umbenannt.

/localize-record/:
Das Feld detail.requestId in Fehlerfällen wurde in detail.insurantId umbenannt.
Das Feld errorCode wurde hinzugefügt.

/get-record-status/:
Die Felder errorCode und insurantId wurden hinzugefügt.

Dokumentation

Die Errorcode-Tabelle enthält nun zusätzliche Hinweise, die erläutern, wodurch ein Fehler verursacht wurde, warum er auftritt und wer für die Behebung verantwortlich ist.

Fix

Ein Fehler wurde behoben, bei dem ein Internal Error ausgelöst wurde, wenn die SMC-B im Konnektor ihren Status von Verified zu Verifiable geändert hat. Der Fehler wurde sichtbar, da der Status der SMC-B während der ECC-Testwochen bei einigen RISE-Kunden geändert wurde.