# Package at.chipkarte.client.elgatsv.soap

Interface und Klassen der ELGA-Testszenarienverwaltung (ELGATSV).

See: Description

- Interface Summary
  Interface | Description
  --- | ---
  IElgatsvService | Dieses Service stellt die Funktionalitäten der ELGA Testszenarienverwaltung zur Verfügung.

- Class Summary
  Class | Description
  --- | ---
  EmedIdDeskriptor | Enthält die Information zu einer im Zuge der Szenarienzuordnung angelegten eMedikation.
  SzenarioData | Enthält die Information zu den angelegten eMedikationsdaten (emedSzenarioInfo), dem Patienten (bpk-GH) und dem Vertragspartner (GDA-ID).

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

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

- Allgemein

- Rechte
- Anmeldung
- Zusammenspiel ELGA-TSV und TSV
- CardToken
- Zusammenspiel ELGA-TSV und ELGA-Adapter
- Online/Offline Status

- Funktionalität des ELGATSV Service

- Szenarien abfragen
- Szenario zuordnen
- Testdaten löschen

# Allgemein

Dieses Service dient rein der Verwendung durch Gesundheitsdiensteanbieter (GDA) Softwarehersteller.
Das ELGATSV Service steht aus diesem Grund nur auf GINAs von GDA Softwareherstellern zur Verfügung. Die Zuordnung der GINA zu einer Benutzergruppe (Softwarehersteller oder GDA) kann mittels der GINA Funktion getGinaSoftwareVersion() abgefragt werden.

## Rechte

Für die Funktionen des ELGATSV Service benötigt der GDA für die Durchführung das Recht ELGATSV.CORE.
Wird eine Funktion, welche dieses Recht benötigt, ohne das entsprechende Recht aufgerufen, erhält man die Exception AccessException.MISSING_ELGATSV_CORE.
Mittels der Funktion getBerechtigungen() aus dem BASE Service ist es möglich, die Rechte des GDA abzufragen.

## Anmeldung

Zur Nutzung der ELGATSV Funktionalitäten muss der GDA Softwarehersteller 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.

## Zusammenspiel ELGA-TSV und TSV

Das TSV Service des e-card Systems gibt Ihnen die Möglichkeit zu einer Pseudo e-card Szenarien zuzuordnen, aufgrund derer der SV-Person bestimmte Daten innerhalb des e-card System zugeordnet werden.
Darunter fallen je nach Szenario: Ansprüche, Namensdaten, Konsulationen und so weiter.
Das ELGATSV Service biete die Möglichkeit zu einer Pseudo e-card Szenarien zuzuordnen, aufgrund derer der SV-Person bestimmte Daten in ELGA (eMedikation) zugeordnet werden.
Bei den Zuordnungen gilt:

- Das Zuordnen eines TSV Szenarios legt keine Daten in ELGA (eMedikation) an.
- Das Zuordnen eines ELGA TSV Szenarios legt keine Daten im e-card System an.

Verwenden Sie weiterhin TSV um der SV-Person der Pseudo e-card bei Bedarf entsprechende Ansprüche, Namensdaten oder Konsulationsdaten zuzuordnen. Durch das anschließende Zuordnen eines ELGA-Szenarios zur selben Pseudo e-card werden die von TSV zugeordneten Daten nicht geändert!
Beachten Sie dabei bitte, dass beim Zuordnen von ELGATSV Szenarien die aktuell bekannten Daten der SV-Person aus dem ZP-I verwendet werden (z.B. zum Anlegen einer eMedikation). Wird nach ELGA TSV Szenarien-Zuordnung zur Pseudo e-card ein TSV Szenario zugeordnet mit Änderungen der Personendaten (Name, Alter, Geschlecht), werden diese im e-card System gespeichert. Es findet weder eine Aktualisierung der bereits angelegten ELGA-TSV (eMedikation) Daten statt, noch eine Änderung der im ZP-I gespeicherten Daten zur SV-Person.

## CardToken

Um die Pseudo e-card zu verwenden, muss ein e-card CardToken erstellt werden. Das e-card Cardtoken (SV-Signaturtoken mit e-card) kann mittels die REST Schnittstelle vom LANCCR angefordert werden.
Die Dokumentation des REST-Services zur Kommunikation mit dem Kartenleser ist zu finden unter: Swagger Doku LANCCR.
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 ELGATSV wird nur das e-card Cardtoken unterstützt!

## Zusammenspiel ELGA-TSV und ELGA-Adapter

Berechtigungen eCS
Für die Ausführung der ELGATSV-Funktionen ist wie im Kapitel Rechte beschrieben nur das Recht ELGATSV.CORE notwendig. Es wird nicht auf eventuelle Berechtigungen von ELGA-Adapter Funktionen geprüft.
Das heißt, wird z.B. der Dialog ohne Angabe der ELGA Parameter (elgarolle, GdaMa, prozess) aufgebaut und damit ein Szenario zugeordnet, ist mit dem selben Dialog eine Durchführung von Funktionen aus dem ELGA-Adapter welche das Recht ELGAAD.AUTH benötigen nicht möglich.
Berechtigungen ausserhalb des eCS
Beachten Sie bitte, dass sowohl bei Service ELGATSV als auch beim Service ELGAAD, sowohl der verwendete GDA als auch die Person der Pseudo e-card für ELGA freigeschalten sein muss. Dazu müssen GDAs im GDA-I und Patienten im ZP-I bekannt sein. Bitte kontaktieren Sie den Partnersupport des e-card Systems sofern Sie sich nicht sicher sind, für welche Ihrer Pseudo o-cards und Pseudo e-cards diese Freischaltung erfolgt ist.
Kontakbestätigungen
Durch die Zuordnung eines ELGATSV Szenarios werden wie im Kapitel Zusammenspiel ELGA-TSV und TSV bereits erwähnt keine Daten im e-card System angelegt.
Das bedeutet, dass auch nicht automatisch ein Kontakt zwischen den angemeldeten GDA und den Patienten angelegt wird. Um mittels des Adaperts auf die Daten per SV-Nummer zuzugreifen muss ein Kontakt zwischen den aktuell abfragenden GDA und den Patienten vorhanden sein.
Hierzu haben Sie folgende Möglichkeiten:

- Verwenden Sie direkt in der ELGAAD Funktion die Pseudo e-card
- bei verwendeten GDAs mit Nutzung der KSE:

- Legen Sie mit zu dem abfragenden GDA und der verwendeten SV-Person eine Konsulation (mit gesteckter Pseudo e-card) an
- Ordnen Sie der Pseudo e-card ein TSV Szenario zu bei dem für Sie selbst eine Konsulation vorbelegt wird.
  Hierbei sind folgende Punkte zu beachten:
  - zur TSV Zuordnung und zur ELGAAD Nutzung muss der selbe GDA verwendet werden (in der selben Oridnation und Ausprägung)
  - die Konsultation muss zum GDA selbst erstellt werden
  - die vorbelegte Konsulation muss mit der e-card erstellt (d.h. in der Szenarienbeschreibung steht z.B. "Regelfall mit e-card")
  - die vorbelegte Konsulation darf nicht bereits storniert angelegt sein
  - die vorbelegte Konsulation sollte nicht (zu weit) in der Vergangenheit liegen
  - wie bereits in Kapitel Zusammenspiel ELGA-TSV und TSV erwähnt, kann durch die Zuordnung eine Änderung der Personenstammdaten im e-card System auftreten wodurch die Personendaten in der eMedikation und im e-card System unterschiedlich sind.
  Beispiel für ein TSV Szenario das verwendet werden kann (sofern der GDA einen passenden Vertrag für die Zuordnung besitzt):
  - Szenario 03/A: "Betriebsfall Überweisung mit e-card (Erstkonsultation) wurde von Ihnen selbst erfasst"

- bei verwendeten GDAs mit Nutzung von VDAS:

- führen Sie eine Versichertendatenabfrage mit e-card durch

Szenariodaten
Die Szenarien in ELGATSV ordnen je nach Szenario:

- Rezepte,
- Abgaben oder
- Pharmazeutische Empfehlungen

zu.
Informationen hinsichtlich der Szenariodaten (was wird zugeordnet, mit welchem GDA selbst/fremd, ...) finden Sie in der ELGATSV Szenarienbeschreibung unter www.chipkarte.at (Bereich Softwarehersteller).

## Online/Offline Status

Im laufenden Betrieb kann ein Offline-Zustand bzw. das Auftreten eines Verbindungsproblems dadurch identifiziert werden, dass auf einen Request keine Response erfolgt.
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://elga.ecard.sozialversicherung.at/<service-name>/<versionsnummer>/status
Ist der Server erreichbar, wird der Response HTTP 200 retourniert. Ist der Server nicht erreichbar (Offline), wird keine Response mehr retourniert.

# Funktionalität des ELGATSV Service

Mittels dieses Services können GDA Softwarehersteller ihren Pseudo e-cards verschiedene, vordefinierte Szenarien in ELGA (eMedikation) zuordnen bzw. alle eMedikations-Testdaten des Patienten löschen.

## Szenarien abfragen:

Mittels der Funktion abfragenSzenarien() werden die verfügbaren Szenarien des ELGATSV Sevices ermittelt.
Für jedes ermittelte Szenario wird eine eindeutige emedSzenarioId retourniert.

## Szenario zuordnen:

Mittels der Funktion zuordnenSzenario() wird der Person des angegebenen e-card CardTokens das mittels emedSzenarioId spezifizerte Szenario zugeordnet.
Im Zuge der Zuordnung werden alle eventuell bereits vorhandenen eMedikationsdaten zur SV-Person gelöscht (dies beinhaltet auch mittels des ELGA Adapters bzw. des ELGA Proxys angelegte Daten).
D.h. nach Szenariozuordnung befinden sich für die Person in der eMedikation (nur noch) genau die im Szenario definierten Daten gespeichert.
Als Rückgabe einer erfolgreichen Zuordnung erhalten Sie das Objekt SzenarioData mit folgenden Informationen:

emedSzenarioInfo | Sofern im Zuge der Zuordnung eMedikationsdaten angelegt wurden, erhalten Sie hier für jede angelegte Medikation folgende Information:
emedId | Eindeutige Id der angelegten eMedikation
szenarioRezeptId | Verweis auf das dahinterliegende Rezept
bpkGh | Bereichsspezifisches Personenkennzeichen des Patienten für den Gesundheitsbereich, in e-Medikation eindeutiger Schlüssel eines Patienten. Format: 3 stelliger Präfix "GH:" gefolgt von weitern 28 Stellen (alpahnumerisch), z.B.: GH:XNV5ThCj5OwJR0oOcWmK4WUs5p4
gdaId | Hier wird immer die OID des angemeldeten Vertragspartners aus dem GDA-Index retourniert. Hinweis: Diese nicht der gdaId (OID) innerhalb der angelegten eMedikationsdaten entsprechen. Sehen Sie hierzu die Beschreibung der ELGA-TSV-Szenarien unter www.chipkarte.at - Bereich Softwarehersteller bzgl. des zum Anlegen verwendeten GDAs.

## Testdaten löschen:

Durch Aufruf der Funktion loeschenTestdaten() werden alle in eMedikation vorhandenen Daten zur SV-Person angegebenen e-card CardTokens gelöscht. Dabei werden nicht nur vorbelegte Szenariendaten entfernt, sondern auch alle eventuell nachträglich (mittels ELGA Adapter oder ELGA Proxy) angelegten Daten.