Interface und Klassen der Testszenarienverwaltung (TSV). Dieses Package enthält den SOAP Endpoint
Dieses Service dient rein der Verwendung durch Vertragspartnersoftware-Hersteller.
Das TSV Service steht aus diesem Grund nur auf GINAs von Vertragspartnersoftware-Herstellern zur Verfügung. Die Zuordnung der GINA zu
einer Benutzergruppe (Softwarehersteller oder Vertragspartner) kann mittels der BASE Funktion getGinaSoftwareVersion() abgefragt werden.
Rechte
Für die Funktionen des TSV Service benötigt der Vertragspartner für die Durchführung das Recht TSV.CORE.
Wird eine Funktion, welche dieses Recht benötigt, ohne das entsprechende Recht aufgerufen, erhält man die Exception
AccessException.MISSING_TSV_CORE.
Mittels der Funktion getBerechtigungen() aus dem BASE Service ist es möglich, die Rechte des Vertragspartners abzufragen.
Anmeldung
Zur Nutzung der TSV Funktionalitäten muss der VertragspartnerSoftware-Hersteller einen Dialog auf einer VPSWH GINA aufbauen.
Dieser Dialog kann entweder mittels Pseudo o-card oder einem, für den SW-Hersteller registrierten,
SW-Zertifikat (Enterprise Funktionalität) aufgebaut werden.
Online-/Offline-Status
Im laufenden Betrieb kann ein Offline-Zustand bzw. das Auftreten eines Verbindungsproblems in Abängigkeit der Kommunikationsart mit dem e-card System wie folgt identifiziert werden:
- die Kommunikation erfolgt direkt über die GINA:
Die aufrufende Funktion retourniert eine entsprechende SOAP Exception (ServiceException.CONNECTION_ERROR).
- die Kommunikation erfolgt über den Proxy auf der GINA:
Es wird als Response HTTP 503 retourniert.
- die Kommunikation erfolgt direkt mit dem Serversystem:
Es erfolgt keine Response.
Ob eine Verbindung für ein bestimmtes Service zum e-card-Serversystem besteht, sollte im Normalbetrieb
NICHT abgefragt werden!
Die Abfrage sollte nur dann durchgeführt werden um festzustellen, ab wann das Service
wieder online ist, wenn zuvor Verbindungsprobleme aufgetreten sind.
Die empfohlene Frequenz für die Abfragen liegt in diesem Fall bei
> 1 Minute.
Die Abfrage ist über eine REST Schnittstelle durchzuführen:
Der Aufruf erfolgt mittels:
GET https://<gina-adresse>/<service-name>/<versionsnummer>/status
Ist der Server erreichbar, wird der Response HTTP 200 retourniert.
Ist der Server nicht erreichbar (Offline) und der Request wird über die GINA geschickt (direkt über die GINA bzw. über den GINA Proxy), wird der Response HTTP 503 retourniert.
Hinweis: Erfolgt die Kommunikation mittels GINA Proxy wird im HTTP 503 Response zusätzlich der Text
"Die GINA konnte keine Verbindung zum Serversystem herstellen." im Response-Body befüllt.
Erfolgt die Abfrage direkt auf das Serversystem (nach Entfall der GINA) wird im Offline-Fall keine Response mehr retourniert.
e-card CardToken
Das e-card Cardtoken (
SV-Signaturtoken mit e-card) kann mittels REST Schnittstelle vom LANCCR angefordert werden.
Die Dokumentation des REST-Services zur Kommunikation mit dem Kartenleser ist zu finden unter:
Swagger Doku LANCCR.
Bei der Verwendung eines Test-Patienten kann ein
e-card Cardtoken (SV-Signaturtoken mit e-card) oder ein o-card Cardtoken (SV-Signaturtoken mit Admin-Karte) ausgestellt werden.
Das ausgestellte Cardtoken kann anschließend in den Funktionen der jeweiligen Services anstelle einer (gesteckten) e-card verwendet werden.
Das Stecken der e-card zum Ausführen der jeweiligen Servicefunktion ist nicht mehr notwendig.
Das Cardtoken kann je nach Service für eine bestimmte Dauer nach Ausstellung genutzt werden.
In der Regel ist ein ausgestellter CardToken für 10 Stunden verwendbar.
Welcher Cardtoken vom jeweiligen Service unterstützt wird, ist bei den Services selbst definiert.
In
TSV wird
nur das
e-card Cardtoken unterstützt!
In TSV muss bei folgenden Funktionen ein Cardtoken zwingend angegeben werden:
- setSchulungsszenario()
- deleteSchulungsdaten()
Das Cardtoken muss dabei mit der Pseudo-e-card erstellt worden sein, zu der eine Zuordnung gewünscht ist.
Mittels dieses Services können Vertragspartnersoftware-Hersteller ihren Pseudo e-cards (mittels Angabe des jeweiligen Cardtokens) verschiedene, vordefinierte
Szenarien zuordnen, um die Abläufe und Fehlerfälle der einzelnen Services mit verschiedenen SV-Personen
(mit verschiedenen Vorbedingungen) durchzulaufen und zu testen. So gibt es z.B.
Szenarien bei denen die SV-Person mehrfachversichert ist oder bei denen die e-card der SV-Person als gesperrt gekennzeichnet ist usw.
Folgende Funktionalitäten können durchgeführt werden:
Schulungsszenarien abfragen:
Die verfügbaren Schulungsszenarien werden ermittelt.
Schulungsszenarien zuordnen:
Der mittels angegebenen Cardtoken definierten Pseudo e-card wird das ausgewählte Szenario zugeordnet. Nach dieser Zuordnung
besitzt diese Pseudo e-card innerhalb des TSV Service die
Ansprüche und Daten der SV-Person des ausgewählten Szenarios.
War bereits ein Szenario der Pseudo e-card zugeordnet, wird dieses gelöscht (ebenso wie eventuell vorhandene
Schulungskonsultationen u. ä.) und die neue Zuordnung vorgenommen.
Hinweis: Bei bestimmten Szenarien können Zusatzinformationen retourniert werden, die bei anderen Services Verwendung finden (z.B. REZID).
Wichtig: Ist der Pseudo e-card bereits ein Szenario mit einer Namensangabe zugeordnet, erfolgt keine automatische
Rücksetzung auf den Originalnamen der Pseudo e-card bei Zuordnung eines Szenarios ohne Namensangabe.
Schulungsdaten löschen:
Wurden durch die mittels CardToken angegebene Pseudo e-card am Testsystem Schulungsdaten angelegt (zum Beispiel Konsultationen), werden
diese, sowie vorhandene weitere Daten (wie z.B. AU-Meldungen, ...) entfernt..
Das ursprüngliche Szenario bleibt dabei
weiterhin der Pseudo e-card zugordnet.
Hinweis: Bei bestimmten Szenarien können Zusatzinformationen retourniert werden, die bei anderen Services Verwendung finden (z.B. REZID).
Wichtig:Ist der Pseudo e-card bereits ein Szenario mit einer Namensangabe zugeordnet, erfolgt keine automatische
Rücksetzung auf den Originalnamen der Pseudo e-card beim Löschen der Schulungsdaten über die SS12. Das
Zurücksetzen der Namensdaten wird nur über die e-card WEB-GUI unterstützt!
Eine Beschreibung der verfügbaren Szenarien finden Sie im der Szenarienbeschreibung unter www.chipkarte.at (Bereich Softwarehersteller).