Bitte prüfen Sie, ob im Konsolenfenster Fehlermeldungen ausgegeben werden, welche den Text „java.net.BindException: Address already in use: bind“ enthalten. Ist dies der Fall, so prüfen Sie bitte ob die konfigurierten Ports (Oberfläche => Einstellungen) frei sind (z.B. unter Windows mit „netstat -an -p TCP“). Die Standardports 80 bzw. 443 können auch schon von anderen Anwendungen belegt sein. Sie können die Standardports in der Oberfläche ändern. Bitte prüfen Sie nach der Änderung wieder das Puppetry Konsolenfenster auf Fehlermeldungen. Tritt keine Fehlermeldung mit dem Text „java.net.BindException: Address already in use: bind“ auf, so ist Puppetry richtig konfiguriert.
Dem Testfall liegen folgende Anforderungen aus gemILF_PS zugrunde:
TIP1-A_4962 Nutzung von TLS-Authentisierungsmethoden
Das Primärsystem SOLL gemäß TLS Version 1.1 die TLS-Authentisierungsmethoden der Stufen 2 oder 4 aus den Tabellen 1 und 2 verwenden – das heißt: TLS mit Server-Authentisierung mit oder ohne Client-Authentisierung. Das PS KANN auch TLS Version 1.2. unterstützen.
TIP1-A_4963 Authentifizierung gegenüber Dienstverzeichnisdienst
Das Primärsystem SOLL in der Lage sein, den Service-Endpunkt des Konnektordienstverzeichnisdienstes mit einer Transportsicherungsmethode (TLS deaktiviert, HTTPS Basic Authentication oder HTTPS mit Client Authentication) anzusprechen, die sich ggf. von der Transportsicherungsmethode der weiteren Dienste unterscheidet.
In dem Testfall wird auf die stärkste Absicherung (4) überprüft – in der Annahme, dass dann auch alle schwächeren Methoden auf Primärsystemseite konfigurierbar sind.
Sollte eine Implementierung der Zertifikatsbasierten TLS-Verbindung mit Clientauthentisierung nicht umsetzbar sein, so geben sie bitte mit dem Prüfbericht eine entsprechende Erklärung ab.
Dem Verhalten der Testsuite liegt folgende Anforderung aus gemILF_PS zugrunde:
TIP1-A_4959 Konfigurierbarkeit von Kontext-Parametern
Innerhalb des Primärsystems MUSS eine Konfigurationsverwaltung vorhanden sein, welche die Parameter MandantId, ClientSystemId, WorkplaceId und UserId entsprechend Abb_LFPS_01_Element Context gemäß ConnectorContext.xsd” abbildet. Die Parameter sind alphanumerisch und haben eine Maximallänge von 64 Zeichen.
Die Überprüfung dieser MUSS Anforderung erfolgt, indem die Clientparameter in den Testfällen fest hinterlegt sind und nicht verändert werden können.
Bitte vergewissern Sie sich, dass alle im Test-schritt „Screenshots anhängen“ beschriebenen Prüfpunkte wirklich mit Screenshots belegt sind.
Es wird eine Fehlermeldung mit den folgenden Aussagen erwartet:
„Der Typ der Karte ist unbekannt.
Mögliche Fehlerursachen können sein:
Im Fall einer "alten" EGK besteht kein gültiger Leistungsanspruch. Bitte beim Versicherten nachfragen, ob diese Karte seine aktuelle eGK ist. Nur wenn der Versicherte keine aktuellere eGK besitzt, soll er an seine Krankenkasse verwiesen werden.“
Die angezeigte Fehlermeldung muss auch die Fehlerursache anzeigen, d.h. dass keine unterstützte Version für die Services vorliegt.
Nach einem VSD-Update muss auch eine Veränderung bezüglich der besonderen Personengruppe und / oder des DMP Merkmals angezeigt werden.
Sind die Daten auf der eGK inkonsistent (EF.StatusVD inkonsistent), so muss die Fehlermeldung auch einen Hinweis an den Nutzer enthalten, die Online-Prüfung zu wiederholen, damit die Aktualisierung der Daten erfolgreich abgeschlossen werden kann.
Eine fehlgeschlagene Onlineprüfung (z.B. bei Nichterreichbarkeit der TI oder eines Fachdienstes) darf das Lesen der eGK nicht verhindern. Das Primärsystem muss das Speichern der Versichertenstammdaten und des Prüfungsnachweises auch in diesem Fall ermöglichen.
Die Fehlermeldung zu Fehlercode 105 muss einen Hinweis enthalten wie „Die eGK ist fehlerhaft / defekt. Bitte setzen Sie sich mit der Krankenkasse in Verbindung.“
Im Falle einer gesperrten PIN (nach mehrfacher Falscheingabe der PIN) muss das Primärsystem zur Eingabe der PUK auffordern (und nicht der PIN!).
