# Package at.chipkarte.client.tsv.soap

Interface und Klassen der Testszenarienverwaltung (TSV).

See: Description

- Interface Summary
  Interface | Description
  --- | ---
  ITsvService | Dieses Service stellt die Funktionalitäten der Testszenarienverwaltung (TSV) Version 4 zur Verfügung.

- Class Summary
  Class | Description
  --- | ---
  Zuordnungsinformation | Von TSV aufgrund der Szenario-Zuordnung erzeugte Zuordnungsinformationen.

## Package at.chipkarte.client.tsv.soap Description

Interface und Klassen der Testszenarienverwaltung (TSV). Dieses Package enthält den SOAP-Endpoint `ITsvService` sowie die dazu notwendigen Klassen.
Inhalt der TSV Package-Beschreibung:

- Allgemein

- Rechte
- Anmeldung
- Online-/Offline-Status
- e-card CardToken

- Funktionalität des TSV Service

- Schulungsszenarien abfragen
- Schulungsszenarien zuordnen
- Schulungsdaten löschen
- Geburtstagsszenario zuordnen

- Informationen bzgl. Schulungsszenarien

# Allgemein

Dieses Service kann ausschließlich von Vertragspartnersoftware-Herstellern verwendet werden.
Das TSV Service steht aus diesem Grund in der Testumgebung (VPSWH) zur Verfügung.

## 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 aufbauen.

## 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 durchgeführt werden um festzustellen, ab wann das Service wieder online ist, sofern 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 (PROD-Instanz) bzw. GET https://services-a.ecard-test.sozialversicherung.at/<service-name>/<versionsnummer>/status (VPSWH-Instanz)
Ist der Server erreichbar, wird die 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 GINO Kartenleser angefordert werden.
Die Dokumentation des REST-Service zur Kommunikation mit dem Kartenleser ist zu finden unter: Swagger Doku Kartenleser.
Bei der Anmeldung eines Test-Patienten kann in Abhängigkeit davon, ob eine e-card vorhanden ist ein, e-card CardToken (SV-Signaturtoken mit e-card) oder ein o-card CardToken (SV-Signaturtoken mit Admin-Karte) ausgestellt werden.
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.
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.

# Funktionalität des TSV Service

Mittels dieses Service können VPSWH ihren Pseudo e-cards verschiedene, vordefinierte Szenarien mit verschiedenen Vorbedingungen zuordnen. Das ermöglicht das Testen von Abläufen und Fehlerfällen der einzelnen Services (z.B. mit mehrfachversicherten SV-Personen oder SV-Personen mit gesperrter e-card).
Folgende Funktionalitäten können durchgeführt werden:

## Schulungsszenarien abfragen:

Die verfügbaren Schulungsszenarien werden ermittelt.

## Schulungsszenarien zuordnen:

Dem mittels e-card CardToken definierten Test-Patienten wird das ausgewählte Szenario zugeordnet. Nach dieser Zuordnung besitzt dieser die Ansprüche bzw. Daten des ausgewählten Szenarios.
Ein bereits zugeordnetes Szenario wird dabei überschrieben und zugehörige Daten (z.B. Konsultationen und ausgestellte e-Rezepte) gelöscht und eine Neuzuordnung vorgenommen.
Hinweis: Bei bestimmten Szenarien können Zusatzinformationen retourniert werden, die bei anderen Services Verwendung finden (z.B. REZID).
Wichtig: Ist einem Test-Patienten bereits ein Szenario mit einer Namensangabe zugeordnet, erfolgt keine automatische Rücksetzung auf den Originalnamen des Test-Patienten bei Zuordnung eines Szenarios ohne Namensangabe.

## Schulungsdaten löschen:

Sind für einen Test-Patienten selbsterstellte Schulungsdaten vorhanden (z.B. selbsterstellte Konsultationen, die nicht vom Szenario gesetzt wurden), werden diese entfernt.
Das ursprüngliche Szenario wird auf den Ursprungsstand des Szenarios zurückgesetzt.
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-Oberfläche unterstützt!

## Geburtstagsszenario zuordnen:

Sind für einen Test-Patienten selbsterstellte Schulungsdaten vorhanden (z.B. selbsterstellte Konsultationen, die nicht vom Szenario gesetzt wurden), werden diese entfernt.
Der Pseudo e-card wird ein Geburtsdatum sowie je nach Eingangsdaten 0-2 eigene oder abgeleitete Anprüche zugeordnet. Das Geburtsdaum wird auch am ZPI Backend gesetzt.
Wichtig: Diese Funktion ist nur an der SS12 Schnittstelle verfügbar.

# Informationen bzgl. Schulungsszenarien

Eine Beschreibung der verfügbaren Szenarien finden Sie in der Szenarienbeschreibung unter www.chipkarte.at/swh (Dokumentation der Testszenarien).