Interface und Klassen der ELGA-Testszenarienverwaltung (ELGATSV). Dieses Package enthält den SOAP Endpoint
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.
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
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
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.
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.