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
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:
GET https://services.ecard.sozialversicherung.at/<service-name>/<versionsnummer>/status (Produktions-Instanz)
bzw. GET https://services-a.ecard-test.sozialversicherung.at/<service-name>/<versionsnummer>/status (VPSWH-Instanz)
Ist der Server erreichbar, wird der Response HTTP 200 retourniert. Im Offline-Fall wird keine Response 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).