# Package at.chipkarte.client.ebs.soap

Interface und Klassen des elektronischen Kommunikationsservice (eBS).

See: Description

- Interface Summary
  Interface | Description
  --- | ---
  IEbsService | Dieses Service stellt die Funktionalitäten des elektronischen Bewilligungs- und Antragsservice (EBS) zur Verfügung.

- Class Summary
  Class | Description
  --- | ---
  AbfragenAntragMitCodeErgebnis | Enthält die Rückgabewerte der Funktion `abfragenAntragMitCode`.
  Adressdaten | Dient der Ein- und Ausgabe der Daten von Adressdaten.
  AntragstypDetail | Dient der Ausgabe des möglichen Antragstyps und die dafür notwendigen Rechte.
  AttachmentInfo | Dient der Ein- und Ausgabe von Informationen zu einem Attachment.
  BeantragteLeistung | Dient der Ausgabe von beantragten Leistungen.
  Bewilligungsakt | Dient der Ausgabe des kompletten Bewilligungsakts.
  BewilligungsaktFoto | Enthält die Bewilligungsakt-Referenz, sowie bei Bedarf die Informationen bezüglich eines benötigten Fotos.
  BewilligungsaktReferenz | Dient der Ausgabe von Bewilligungsakt-Abrissen.
  BewilligungsaktReferenzFoto | Enthält den erstellten bzw. übernommenen Bewilligungsakt, sowie bei Bedarf die Informationen bezüglich eines benötigten Fotos.
  CtAntragsdaten | Dient der Ein- und Ausgabe der spezifischen medizinischen Daten für einen CT-Antrag.
  DateiInfo | Dient der Ein- und Ausgabe von Informationen zu einer Datei.
  EkvkPatient | Dient der Ein- und Ausgabe der Daten von EKVK-Patienten.
  EntschiedeneLeistung | Dient der Ausgabe von entschiedenen Leistungen.
  EvidenzBeantwortung | Dient der Ausgabe einer Evidenzbeantwortung.
  EvidenzDaten | Dient der Ausgabe von Evidenzdaten.
  EvidenzMeldung | Dient der Ausgabe einer Evidenzmeldung.
  GenerelleMedizinischeAntragsdaten | Dient der Ein- und Ausgabe genereller medizinischer Daten eines Antrages (diese Parameter sind in jedem Antrag vorhanden).
  GewuenschteLeistung | Dient der Eingabe einer beantragten Leistung.
  HumAntragsdaten | Dient der Ein- und Ausgabe der spezifischen medizinischen Daten für einen HUM-Antrag.
  IndikationMammographie | Dient der Ein- und Ausgabe der Indikation Mammographie.
  Katalogdaten | Enthält die abgefragten Verordnungskatalog-Daten eines bestimmten Antragstyps (siehe `abfrageVokDaten`).
  Kataloginfo | Enthält Informationen über die zur Verfügung stehenden Verordnungskatalogdaten-Versionen (siehe `abfrageVokVersionen`).
  Katalogleistung | Dient der Ausgabe der Parameter der einzelnen Katalogleistungen.
  Kategorie | Dient der Ausgabe der Parameter der einzelnen Kategorien.
  KdmAntragsdaten | Dient der Ein- und Ausgabe der spezifischen medizinischen Daten für einen KDM-Antrag.
  KontaktdatenVerordner | Dient der Ein- und Ausgabe von Kontaktdaten des Verordners.
  KvtAntragstypen | Dient der Ausgabe der vom eBS relevanten KV-Träger unterstützten Antragstypen.
  LeistungsantragAktuell | Dient der aktuellen Erfassung von Anträgen mittels der Funktion erfassenVerordnerAntrag.
  LeistungsantragNacherfassen | Dient der Nacherfassung von Anträgen mittels der Funktion nacherfassenAntrag.
  Leistungsbezieher | Dient der Ausgabe der Daten des Patienten.
  Leistungsinformation | Im Zuge der Verordnungskatalogdaten-Abfrage ermittelte Katalogleistung, inklusive der Information über eine eventuell vorhandene Fachgebietsabhängigkeit und der Zuordnung von welchen KV-Trägern diese Katalogleistung unterstützt wird.
  Leistungskatalog | Dient der Ausgabe von Informationen zu den ermittelten Leistungskatalog.
  Leistungsverordner | Dient der Ausgabe der Daten des Verordners.
  MedizinischeDatenerweiterung | Enthält weitere medizinische Informationen die aufgrund unterschiedlicher SS12 bzw.
  MrAntragsdaten | Dient der Ein- und Ausgabe der spezifischen medizinischen Daten für einen MR-Antrag.
  NukAntragsdaten | Dient der Ein- und Ausgabe der spezifischen medizinischen Daten für einen NUK-Antrag.
  Partnerdaten | Dient der Ausgabe der Daten mittels VPNR angegebener Verordner.
  PruefenAdministrativeAntragsdatenErgebnis | Enthält die Rückgabewerte der Funktion `pruefenAdministrativeAntragsdaten`.
  RoetAntragsdaten | Dient der Ein- und Ausgabe der spezifischen medizinischen Daten für einen ROET-Antrag.
  RoeuAntragsdaten | Dient der Ein- und Ausgabe der spezifischen medizinischen Daten für einen ROEU-Antrag.
  VerordnerInformation | Dient der Ein- und Ausgabe der Freitextdaten des Originalverordners.
  Verstaendigung | Dient der Ein- und Ausgabe der Patienten Verständigung.

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

Interface und Klassen des elektronischen Kommunikationsservice (eBS). Enthält den SOAP-Endpoint `IEbsService` sowie die dazu notwendigen Klassen.
Inhalt der EBS package-Beschreibung:

- Allgemein

- eBS vs. eKOS
- Rechte
- Dynamische Ermittlung von Parameterwerten des e-card-Regelwerks
- Online-/Offline-Status
- SV-Nummer vs. e-card CardToken vs. EKVK-Daten
- Prinzipielle Erklärungen und Ablauf für die Verwendung des eBS (EKOS) Service

- Prinzipieller Ablauf
- Informationen zur Antragserfassung
- Informationen zu den Leistungen im Antrag/Bewilligungsakt
- Informationen zur Katalogabfrage
- Informationen zur Terminvereinbarung
- Informationen zur Antragsübernahme
- Informationen zur Antragsabfrage

- Fotoinformation
- Generelle Hinweise (Druckaufbereitung, Fehlerhandling, ...)

- Funktionalität des eBS-Service

- Administrative Antragsdaten prüfen
- Antragserfassung durch den Verordner
- Originalverordner-VPNR prüfen
- Nacherfassung durch einen anderen Vertragspartner
- Antrag stornieren
- Auf Evidenzmeldung antworten
- Antrag mittels Code abfragen
- Eigene Anträge Abfragen
- Anlagen eines Antrags herunterladen
- Terminvereinbarung für einen Antrag bekanntgeben
- Terminvereinbarung widerrufen
- Leistungen eines Antrags übernehmen
- Leistungsübernahme eines Antrags widerrufen
- Verordnungskatalogdaten abfragen

# Allgemein

Das Service bietet die Möglichkeit Anträge für Leistungen aus dem Bereich der Untersuchungen elektronisch zu erfassen. Die Anträge werden zwecks Bewilligung an den zuständigen Träger weitergeleitet und können im Falle einer Bewilligung durch einen berechtigten Leistungserbringer übernommen werden (Kennzeichnung der Leistungserbringung).

## eBS vs. eKOS

Das Service wird an der SS12 weiterhin als "eBS" bezeichnet.
An der Oberfläche ist statt eBS folgendes Wording zu verwenden:

- Kurztext: eKOS
- Langtext: elektronisches Kommunikationsservice

## Rechte

Mittels der Funktion getBerechtigungen() aus dem BASE-Service ist es möglich, die Rechte des Vertragspartners abzufragen.
Funktionsrechte
Das eBS unterscheidet auf Funktionsebene folgende drei Rechte:

- EBS.CORE
- EBS.ANTRAG
- EBS.UEBERNAHME

Funktionen | benötigte Rechte | Fehlermeldung bei Aufruf ohne die benötigten Rechte
--- | --- | ---
Antrag stornieren Auf Evidenzmeldung antworten Antrag mittels Code abfragen Eigene Anträge Abfragen Anlagen eines Antrags herunterladen eBS relevante Träger abfragen eBS Servicestatus abfragen Terminvereinbarung widerrufen Antragstypen ermitteln Mammographie-Indikationen ermitteln Verordnungskatalogdaten abfragen | EBS.CORE | AccessException.MISSING_EBS_CORE
Administrative Antragsdaten prüfen Antragserfassung durch den Verordner Originalverordner-VPNR prüfen Nacherfassung durch einen anderen Vertragspartner | EBS.CORE EBS.ANTRAG | AccessException.MISSING_EBS_ANTRAG
Terminvereinbarung für einen Antrag bekanntgeben Leistungen eines Antrags übernehmen Leistungsübernahme eines Antrags widerrufen | EBS.CORE EBS.UEBERNAHME | AccessException.MISSING_EBS_UEBERNAHME

Antragstyp-Rechte
Zusätzlich werden für die Verwendung der verfügbaren Antragstypen folgende Rechte unterschieden:

- EBS.U1
- EBS.U2

Mittesl der im Kapitel Dynamische Ermittlung von Parameterwerten des e-card-Regelwerks angeführten Funktion "antragstypenErmitteln()" können alle verfügbaren Antragstypen abgefragt werden (inkl. der Information welches der Rechte für die Verwendung des jeweiligen Antragstyps notwendig ist).
Wird ein Antragstyp verwendet zu dem der Vertragspartner nicht das passende Recht besitzt, wird keine AccessException retourniert sondern eine Fehlermeldung aus der aufgerufenen Funktion (eBSInvalidParameterException.ANTRAGSTYP_INVALID2 (CL-2090045)).
Das Recht EBS.U2 dient zur Nutzung der neu hinzugekommenen Antragstypen (ROET und ROEU). Mit der Release R18b/R20a wurde das Service strukturell und funktional für die Nutzung der neuen Antragstypen erweitert. Der Einsatzzeitpunkt wird im eCS per Stichtag verwaltet. Erst wenn das Datum erreicht ist, wird das neue Recht eBS.U2 vergeben und erst dann ist eine Nutzung der neuen Antragstypen möglich. Informationen zum Produktiven Stichtag entnehmen Sie den jeweiligen Releaseinformationen.

## Dynamische Ermittlung von Parameterwerten des e-card-Regelwerks

Für das Service relevante Parameterwerte des e-card-Regelwerks müssen dynamisch mindestens einmal pro Dialog mit den an der Vertragspartnersoftware-Schnittstelle angebotenen Methoden ermittelt werden:

Liste aller Fachgebiete ermitteln | FDAS-Methode: getFachgebiete()
erlaubte Fachgebiete für die angemeldete Ordinationsadresse und den gemeldeten Tätigkeitsbereich | BASE-Methode: getFachgebieteByOrdId()
Liste aller Krankenversicherungsträger die am e-card-System teilnehmen ermitteln | FDAS-Methode: getSVTs()
Liste der Staaten | FDAS-Methode: getStaatenISO3166alpha2()
Liste der Antragstypen | EBS-Methode: antragstypenErmitteln()
Liste aller Krankenversicherungsträger die am eBS teilnehmen ermitteln (inkl. der Information der unterstützten Antragstypen) | EBS-Methode: abfragenEbsRelevanteTraeger()
Liste der Indikationen zur diagnostischen Mammographie | EBS-Methode: mammographieIndikationenErmitteln()

Permanente Abfragen dieser Parameterwerte vor jedem Server-Request sind nicht verboten, aber technisch nicht notwendig. Durch das dynamische Caching der Parameter auf der GINA, ermittelt nur der erste Request der Parameterfunktionen (bezogen auf den Dialog) die Daten direkt aus dem Rechenzentrum – jede Folgeanfrage wird aus den gespeicherten Daten auf der GINA automatisch beantwortet.

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

## SV-Nummer vs. e-card CardToken vs. EKVK-Daten

Bei den eBS Funktionen mit Kartenunterstützung unterscheidet man folgende Unterschiedliche Eingabevarianten zur Identifikation des Patienten:

- SV-Nummer und/oder e-card Cardtoken oder EKVK-Daten

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 Anmeldung des 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 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 eBS wird nur das e-card Cardtoken unterstützt!
Für die Angabe innerhalb der Funktionen gilt:
SV-Nummer und/oder e-card Cardtoken oder EKVK-Daten
Darunter fallen folgende eBS Funktionen:

- pruefenAdministrativeAntragsdaten
- erfassenVerordnerAntrag()
- nacherfassenAntrag()

Ein SV-Patient kann mittels SV-Nummer oder mittels e-card Cardtoken angegeben werden. Werden beide Parameter angegeben, muss die SV-Nummer zum Patienten gehören dessen e-card zur Ausstellung des e-card Cardtokens verwendet wurde. Ein EKVK-Patient muss mittels den EKVK-Daten angegeben werden. Eine Angabe der EKVK-Nummer gemeinsam mit der SV-Nummer oder einen e-card Cardtoken ist nicht zulässig.

## Prinzipielle Erklärungen und Ablauf für die Verwendung des eBS:

### Prinzipieller Ablauf

Das eBS Service stellt aktuell die Erfassung von Anträgen für die Gruppe der Untersuchungen zur Verfügung.
Darin enthalten sind folgende Antragstypen:

Codewert | Anzeigetext | Kurztext
--- | --- | ---
CT | Computertomographie | CT
HUM | Humangenetische Untersuchungen | HUM
KDM | Knochendichtemessung | KDM
KPD | Klinisch-psychologische Diagnostik | KPD
MR | Magnetresonanztomographie | MR
NUK | Nuklearmedizinische Untersuchungen | NUK
ROET | Röntgen-Therapie | RÖ-T
ROEU | Röntgen / Sonographie | RÖ/SO

Standardfall:
Im Zuge einer ärztlichen Untersuchung wird festgestellt, dass der Patient eine der oben angeführten Untersuchungen benötigt. Der Vertragspartner erfasst, sofern er die notwendigen Berechtigungen zur Verwendung des gewünschten Antragstypen besitzt, als Verordner einen Antrag auf bestimmte Leistungen für den Patienten.
Der Antrag wird im eCS gespeichert und dabei gemeinsam mit der SV-Nummer bzw. der EKVK-Nummer (Kennnummer der Karte - Feld 8 auf der EKVK) ein eindeutiger Code erzeugt. Die Kombination aus Code und SV- bzw. EKVK-Nummer (Kennnummer der Karte - Feld 8 auf der EKVK) dient als eindeutiger Schlüssel um auf die Antragsdaten zuzugreifen. Zusätzlich wird bereits bei der Erstellung eine druckbare Information zur Zuweisung erzeugt.
Der erzeugte Antrag wird an den zuständigen KV-Träger (der KV-Träger des Patienten) zwecks Bearbeitung weitergeleitet. Der KV-Träger beantwortet den Antrag, dabei stehen für die Leistungen folgende Möglichkeiten zur Auswahl:

- bewilligt
- abgelehnt
- geändert bewilligt
- bewilligungsfrei

Hinweis: Die Leistungsstatuswerte "bewilligt", "bewilligungsfrei" und "geändert bewilligt" werden nur bei Einsichtnahme in den Antrag durch den elektronisch verknüpften Verordner angezeigt. Bei Einsichtnahmen in einen bereits beantworteten Antrag durch einen anderen Akteur (z.B. durch den Leistungserbringer) werden stattdessen die Leistungsstatuswerte "freigegeben" (anstelle von "bewilligt" / "bewilligungsfrei") bzw. "geändert freigegeben" (anstelle von "geändert bewilligt") angezeigt.
Wichtiger Hinweis: Es gibt im Gegensatz zu ABS keine zeitliche Vorgabe innerhalb derer ein eBS Antrag durch den KV-Sachbearbeiter bearbeitet werden muss.
Wurde der Antrag durch den KV-Träger beantwortet und ist mindestens eine der beantragten Leistungen bewilligt, bewilligungsfrei oder geändert bewilligt kann der Antrag durch einen Leistungserbringer übernommen werden.
Der Verordner wird bei Einlangen der Antwort durch das e-card System verständigt (äquivalent dem Eintreffen einer ABS Antwort). Wurde bei der Erfassung angegeben, dass auch der Patient eine Verständigung erhalten will, wird auch dieser entsprechend informiert (per SMS bzw. E-Mail).
Hinweis: Bei der Erfassung ist zwingend anzugeben ob der Patient eine Verständigung wünscht. Bei Anträgen für SV-Patienten ist eine Verständigung per SMS und/oder E-Mail möglich, wobei die SMS-Zustellung nur für österreichische Nummern zulässig ist. Bei Anträgen für EKVK-Patienten ist eine Verständigung nur per E-Mail möglich.
Der Patient kann jederzeit nach Ausstellung des Antrags zu einem möglichen Leistungserbringer gehen. Mittels Antragscode und SV- bzw. EKVK-Nummer (Kennnummer der Karte - Feld 8 auf der EKVK) erhält dieser Zugriff auf die Antragsdaten. Somit ist es dem möglichen Leistungserbringer möglich den aktuellen Status des Antrags einzusehen. Solange noch keine Beantwortung vorliegt, kann weder eine Terminvereinbarung bekannt gegeben werden noch eine Übernahme durchgeführt werden.
Wurde der Antrag beantwortet und dabei mindestens eine Leistung zur Erbringung freigegeben, hat der Leistungserbringer folgende Möglichkeiten:

- Bekanntgabe einer Terminvereinbarung
  Sofern aktuell keine Termine für die Leistungserbringung frei sind, kann der Leistungserbringer eine Terminvereinbarung bekanntgeben. Dabei wird nur bekanntgegeben, dass ein Termin ausgemacht wurde, nicht der Termin selbst. Durch die Terminvereinbarung sehen andere mögliche Leistungserbringer, dass für den Antrag bereits ein Termin vereinbart wurde.
  Eine Terminvereinbarung gilt jedoch nicht als Antragsreservierung! D.h. eine Leistungsübernahme durch einen anderen Vertragspartner ist auch trotz bestehender Terminvereinbarung möglich!
- Leistungserbringung und Melden der Übernahme
  Der Vertragspartner erbringt die Leistung und meldet dem e-card System die Übernahme. Die Leistungsübernahme kann unabhängig einer Terminvereinbarung erfolgen.

Abweichungen zum Standardfall:
Der verordnende Arzt stellt die Verordnung nicht elektronisch aus.
Ebenfalls wie im Standardfall wird eine entsprechende Untersuchung durch den Verordner vorgenommen und festgestellt, dass der Patient entsprechende Untersuchungen durchführen soll. Der Antrag wurde jedoch in diesem Fall nicht durch den Verordner elektronisch im eCS erfasst, sondern nur per Zuweisungsschein papierschriftlich erstellt. Der Patient kann in diesem Fall entweder

- zu einem anderen Vertragspartner gehen um den Antrag elektronisch nacherfassen zu lassen
- den Antrag selbst über das eSV-Portal nacherfassen
- zum KV-Träger gehen um einen Sachbearbeiter den Antrag nacherfassen zu lassen

Eine Nacherfassung durch einen anderen Vertragspartner wird in der Regel durch einen möglichen Leistungserbringer vorgenommen. D.h. der Patient geht mit der Verordnung zum durchzuführenden Institut bzw. Arzt seiner Wahl und dieser kümmert sich für den Patienten um eine Bewilligung indem er den Antrag elektronisch nacherfasst.
Prinzipiell hat jedoch jeder Vertragspartner mit dem EBS.ANTRAG Recht die Möglichkeit einen papierschriftlichen Antrag für einen Patienten nachzuerfassen (d.h. bei Ausstellung der papierschriftlichen Verordnung durch einen Facharzt kann theoretisch die Nacherfassung auch z.B. durch den Hausarzt vorgenommen werden), sofern er die notwendigen Berechtigungen zur Verwendung des gewünschten Antragstypen besitzt. Es erfolgt jedoch eine Überprüfung ob der Originalverordner zur Ausstellung der papierschriftlichen Verordnung berechtigt gewesen wäre. Zusätzlich erfolgt eine Überprüfung des angegebenen Original-Verordnungsdatums (das von der papierschriftlichen Originalverordnung abzulesen ist). Die Nacherfassung einer papierschriftlichen Verordnung ist nur immerhalb eines Monats zulässig!
Bei der Nacherfassung muss der Originalverordner angegeben werden und die Original-Verordnung als eingescanntes Attachment hinzugefügt werden. Der Antrag wird wie im Standardfall im eCS gespeichert und an den zuständigen KV-Träger übermittelt.
Beim Einlangen der Antwort wird bei nacherfassten Anträgen der nacherfassende Vertragspartner informiert (sowie der bei der Erfassung angegebene Verordner, sofern dieser eindeutig genug im eCS identifiziert werden konnte um ihn an den Antrag zu koppeln). Die Verständigung des Patienten per SMS bzw. E-Mail wird äquivalent zur aktuellen Erfassung nur vorgenommen wenn dies bei der Antragserfassung entsprechend erfasst wurde.
Bei der Abfrage eines Antrages wird die Information mitgeliefert ob der Antrag durch einen Vertragspartner, den Patienten oder den KVT Sachbearbeiter erfasst wurde.
Der KV-Träger kann aufgrund der übermittelten Antragsdaten den Antrag nicht beantworten.
Der Antrag wird an den zuständigen KV-Träger übermittelt. Dort wird der Antrag durch einen Sachbearbeiter anhand der im Antrag enthaltenen Daten bearbeitet. Reichen diese Daten nicht zur Entscheidungsfindung aus, muss der Antrag nicht automatisch abgelehnt werden und durch den Erfasser ein neuer Antrag gestellt werden. Stattdessen hat der Sachbearbeiter die Möglichkeit den Antrag in den Status "In Evidenz" zu setzen und damit weitere Informationen anzufordern.
Wird der Antrag in den Status "In Evidenz" gesetzt, werden über das eCS Messaging wiederum der Erfasser, sowie der Verordner informiert. Der Antrag enthält bei der Abfrage der Detaildaten in diesem Fall das Objekt Evidenzdaten in dem die Evidenzmeldung mit der entsprechenden Fragestellung durch den KV-Träger enthalten ist. Prinzipiell kann jeder Vertragspartner auf die Evidenzmeldung antworten wenn er Zugriff auf den Antrag hat - d.h. wenn der Antragscode und die SV- bzw. EKVK-Nummer (Kennnummer der Karte - Feld 8 auf der EKVK) bekannt ist. D.h. auch der mögliche Leistungserbringer kann auf die Evidenzmeldung antworten.
Hinweis: Die Beantwortung ist auch durch den Patienten über das eSV-Portal möglich.
Die Beantwortung ist mittels der Übermittlung einer Freitext-Antwort und/oder von Attachments möglich.
Hinweis: Jede Antwort wird den Evidenzdaten hinzugefügt und ist bei Abruf der Antragsdaten einsehbar.
Das Senden der Antwort ist nur möglich solange der Status des Antrags "In Evidenz" ist. Wechselt der Antrag danach in den Status "Beantwortet" ist keine Übermittlung von Antworten mehr möglich. Die bereits vorhandenen Evidenzdaten verbleiben jedoch im Antrag.

### Informationen zur Antragserfassung

Antragstypen und unterstütze KV-Träger
Mittels der im Kapitel Dynamische Ermittlung von Parameterwerten des e-card-Regelwerks angeführten Funktionen zur Ermittlung der Liste der Antragstypen und der Liste der relevanten KV-Träger besteht die Möglichkeit sowohl die Liste der KV-Träger als auch die Liste der Antragstypen auf unterstütze Werte einzuschränken.
Die Liste der Antragstypen enthält folgende Informationen:

- Codewert
- Anzeigetext
- Information ob der Wert nur für die Anzeige verwendbar ist
- Kurztext
- Information welches Recht benötigt wird

Die Liste der relevanten KV-Träger enthält folgende Informationen:

- Codewert des KV-Trägers
- Liste von Antragstypen die von diesem KV-Träger unterstützt werden

Die Auswahlliste der Antragstypen ist durch die Software auf die Antragstypen einzuschränken zu denen der Vertragspartner das entsprechende Recht besitzt (im angemeldeten Dialog). Wird in einer Funktion mit Eingabemöglichkeit des Antragstyp ein Antragstyp verwenden zu dem der Vertragspartner nicht das passende Recht besitzt, wird die Funktion mit einer Fehlermeldung abgebrochen. Durch die Verwendung der retournierten Werte aus der Liste der eBS relevanten KV-Träger können zusätzliche Einschränkungen bzw. Prüfungen vor der Erfassung durchgeführt werden.
Man unterscheidet zwischen der aktuellen Antragserfassung und der Nacherfassung eines Antrags
Die aktuelle Erfassung ist nur durch den Verordner selbst möglich:
D.h. der Vertragspartner der Erstellung wird automatisch als Verordner des Antrags gespeichert.
Der Verordner benötigt zur Erfassung das Recht EBS.ANTRAG und je nach ausgewählten Antragstyp das spezifische Antragstyp-Recht. Bei der aktuellen Erfassung muss ein Fachgebiet angegeben werden. Es werden nur Fachgebiete unterstützt zu denen der Vertragspartner an der angemeldeten Kombination aus Tätigkeitsbereich und Ordination einen kurativen Vertrag besitzt. Im Zuge der Erfassung wird geprüft ob laut dem leistungszuständigen KV-Träger des Patienten das angegebenen Fachgebiet für den gewählten Antragstypen zulässig zur Erfassung ist.
Ist das Fachgebiet nicht zulässig, ist keine Erfassung mit diesem Fachgebiet für den gewählten Antragstypen zum KV-Träger des Patienten möglich. Ist das Fachgebiet zulässig und es handelt sich um einen passenden Vertrag zum leistungszuständigen KV-Träger des Patienten, erfasst der Vertragspartner den Antrag mit dem Partnerstatus "Vertragspartner (im Sinne des eBS)".
Ist das Fachgebiet zulässig und es handelt sich um keinen passenden Vertrag zum leistungszuständigen KV-Träger des Patienten, erfasst der Vertragspartner den Antrag mit dem Partnerstatus "Wahlpartner (im Sinne des eBS)". Dies ist jedoch nur möglich wenn der KV-Träger des Patienten Wahlpartnererfassungen zulässt.
Hinweis: Der Partnerstatus hat Auswirkungen auf die Angabe-Bedingungen bei einigen Parametern. So darf z.B. der Parameter Empfohlen im Objekt CtDaten nicht angegeben werden, wenn kein passender Vertrag vorliegt (Wahlpartner im Sinne des eBS Service).
Die Nacherfassung eines Antrags ist nur für Vertragspartnr ungleich dem Verordner möglich:
Der nacherfassende Vertragspartner benötigt zur Erfassung das Recht EBS.ANTRAG und je nach ausgewählten Antragstyp das spezifische Antragstyp-Recht. Der nacherfassende Vertragspartner ist nicht der Verordner! Ein anderer Vertragspartner erfasst aufgrund der vorliegenden Papierverordnung den Bewilligungsantrag elektronisch nach (diese muss als Attachment mitübermittelt werden).
Der Originalverordner muss bei der Nacherfassung entweder mittels VPNR oder mittels Angabe der Personen- und Adressdaten angegeben werden. Es gilt hierbei, dass eine Nacherfassung durch den Verordner selbst NICHT möglich ist. D.h. als VPNR des Originalverordners kann nicht die eigene VPNR verwendet werden.
Eine Nacherfassung ist nur möglich wenn der Originalverordner zur Ausstellung der Verordnung prinzipiell (fachlich) berechtigt war.
Bei der Antragserfassung sind die gewünschten Leistungen zu erfassen
Innerhalb eines Antrags muss mindestens eine Leistung angegeben werden. Maximal können zehn Leistungen mittels eines Antrags erfasst werden.
Die gewünschten Leistungen eines Antrags können entweder mittels eines Leistungskatalogs gewählt werden oder mittels Freitext angegeben werden.
Der jeweils zu verwendende Leistungskatalog kann im Zuge der Antragserfassung durch die Prüfung der administrativen Daten jeweils aktuell abgerufen werden! Alternativ ist es auch möglich den Leistungskatalog explizit zu ermitteln und selbst in der Software aufzubereiten. Siehe hierzu den Abschnitt Informationen zur Katalogabfrage.
Wird eine Leistung mittels Freitext angegeben (d.h. nicht mittels einer der Leistungen im Leistungskatalog) muss zwingend der Grund für die Freitextangabe angegeben werden.
Indikationsangabe zur diagnostischen Mammographie (Röntgen / Sonographie)
In der Katalogleistung existiert das Feld "Indikationsangabe". Dieses kann aktuell nur den Wert "M" annehmen und ist nur bei Anträgen des Antragstyps "Röntgen / Sonographie" relevant.
Ist bei einer Katalogleistung dieses Feld mit "M" versorgt, bedeutet dies, dass die Angabe des Indikationsobjektes möglich ist. Das Indiaktionsobjekt ist Bestandteil des entsprechenden Antragsdatenobjektes (RoueAntragsdaten). Für die Angabe des Indiaktionsobjektes gelten folgende Vorgaben:

- darf nur dann angegeben werden, wenn mindestens eine Katalogleistung im Antrag angegeben wurde, bei der das Feld "Indikationsangabe" gleich "M" ist

Zusätzlich gelten noch folgende Bedingungen bzgl. optionaler oder Pflichtangabe:

- muss angegeben werden, wenn es sich um eine Patientin handelt und eine aktuelle Erfassung vorgenommen wird
- kann angegeben werden, wenn es sich um einen Patienten handelt oder eine Nacherfassung vorgenommen wird

Wird die Indikation angegeben, so gilt diese für alle Leistungen innerhalb eines Antrags die mittels Katalogleistung erfasst wurden bei denen Indikationsangabe gleich "M" ist.
Dem Antrag können Attachments hinzugefügt werden
Die Attachments selbst sind als ZIP Archiv mittels MTOM anzugeben. Die Summe aller Dateien im ZIP Archiv (ungepackt) darf dabei max. 3 MB (3245728 Byte / 3,095 MByte) groß sein, keine Unterverzeichnisse besitzen und max. 10 Dateien enthalten.
Erlaubte Dateiextensions sind: bmp, jpeg, jpg, png, gif, tiff, tif, pdf und xml.
Das ZIP Archiv muss mit UTF-8 Encoding erstellt werden!
Generelle Informationen hinsichtlich der Übermittlung des Anhangs (SOAP-Attachment mittels MTOM) siehe Abschnitt "Attachments" in Overview .
Zusätzlich zum ZIP-Archiv ist das Objekt AttachmentInfo anzugeben. Dieses stellt den Kontext zwischen den Dateien im ZIP Archiv und deren Bedeutung in der Applikation her.
Im Objekt ist mittels dem Unterobjekt Dateiinfo jede im ZIP Archiv enthaltene Datei mittels Namen und Extension anzugeben inkl. der Information um welche Art von Attachment es sich dabei handelt (z.B. Befund oder Originalverordnung). Die Angabe der Dateien ist dabei ident zu den tatsächlichen Dateien anzugeben (d.h. Berücksichtigung von Groß-, Kleinschreibung der Dateien notwendig).
Im Zuge der Nacherfassung ist die Angabe der Originalverordnung zwingend notwendig. D.h. es muss ein ZIP Archiv übergeben werden mit mindestens einer Datei, sowie das Objekt AttachmentInfo. In diesem muss mindestens eine Dateiinfo für die Originalverordnungsdatei enthalten sein mit dem Namen der Datei und dem Dateiinhaltstyp gleich "V".
Beim Speichern des Antrags als Bewilligungsakt werden eindeutige Identifikatoren auf Bewilligungsakt-Ebene für die Übernahme und die Abfrage erzeugt
Beim Erstellen des Antrags wird eine eindeutige 17 stellige Antragsreferenz erzeugt. Diese ist für den Übernahmeprozess (Übernahme/Widerruf) und die Abrechnung der übernommenen (erbrachten) Leistungen relevant.
Weiters wird ein Antragscode erzeugt. Dieser ist gemeinsam mit dem Personenidentifikator (VSNR oder EKVK - Kennnummer der Karte) eindeutig. Der Antragscode dient gemeinsam mit dem Personenidentifikator als Zugriffsmöglichkeit auf den Antrag bei den meisten Aktionen innerhalb des eBS Service und als einzige Möglichkeit die Detaildaten eines Bewilligungsakts abzufragen.

### Informationen zur Katalogabfrage

Es gibt zwei Möglichkeiten wie der Leistungskatalog ermittelt werden kann:

1. Im Zuge der Funktion pruefenAdministrativeAntragsdaten()
   Die Ermittlung des Leistungskatalogs findet in diesem Fall zu den angegebenen und ermittelten Daten der Abfrage statt. Als Ergebnis wird ein Leistungskatalog retourniert der nur noch die Leistungen enthält die aufgrund der angegebenen und ermittelten Daten (Antragstyp, KV-Träger des Patienten, Fachgebiet des Originalverordners) zulässig für die Angabe im Antrag sind. Der Leistungskatalog enthält die ermittelten möglichen Katalogleistungen, sowie (sofern vorhanden) Kategorien zum Einschränken der Katalogleistungen. Die Verknüpfung der einzelnen Katalogleistungen zu den Kategorien erfolgt im Objekt der Katalogleistung im Parameter kategorienummer.
   Beispiel: Es sind 20 Katalogleistungen vorhanden und 4 Kategorien. Jeweils 5 Leistungen verweisen auf dieselbe Kategorie. Mittels Auswahl einer Kategorie kann die Auswahl der Leistungen auf die 5 verknüpften Leistungen eingeschränkt werden. Z.B.: Kategorie "Extremitäten" mit zugeordneten Leistungen "Arm", "Hand", "Bein", ...
   Zusätzlich zur Information ob die Leistung mit einer Kategorie verknüpft ist, enthält das Objekt folgende Daten:
   - leistungsposition - ID der Leistung, zu verwenden in gewuenschteLeistung bei Erfassung der Leistung mittels Katalogleistung
   - anzeigetext - Anzuzeigender Text der Leistung
   - Seitenangabe - Information ob die Leistung die Angabe einer Seite in gewuenschteLeistung unterstützt
   - Indikationsangabe - Information ob die Leistung die Angabe einer gewissen Indikationsangabe unterstützt (siehe hierzu auch Indikationsangabe zur diagnostischen Mammographie (Röntgen / Sonographie)
   - APPC - der Leistung zugeordneter Austrian PACS Procedure Code (optional, nicht immer versorgt)
2. Durch explizite Abfrage des Katalogs und Verwaltung durch die VPSW
   Die Ermittlung findet mittels der Funktionen:
   - abfrageVokVersionen()
   - abfrageVokDaten()
   statt.
   Mittels der Abfrage der Versionen kann ermittelt werden welche Version aktuell in Verwendung ist bzw. ob bereits eine zukünftige Version zur Abfrage vorhanden ist.
   Mittels der Abfrage der Verordnungskatalog(Vok)-Daten erfolgt die Abfrage der gewünschten Version des Katalogs.
   Die Abfrage kann mittels folgender Parameter eingeschränkt werden:
   - Antragstyp - Es werden nur die Daten zum angegebenen Anragstyp retourniert.
   - KVT - Es werden nur Leistungen retourniert die vom angegebenen KVT unterstützt werden.
   Es werden je nachdem ob auf einen Antragstyp eingeschränkt wurde oder nicht 1..n Katalogdaten retourniert.
   Die Katalogdaten enthalten den Antragstyp zu dem die ermittelten Leistungsinformationen gehören und die Katagorien zur Einschränkung der Leistungen.
   Eine Leistungsinformation beinhaltet eine Katalogleistung (Beschreibung und Verknüpfung zur Kategorie ist oben beschrieben) und zusätzlich folgende Informationen:
   - Fachgebiete (0..n)
     Besteht für die Leistung eine Einschränkung welches Fachgebiet der Originalverordner besitzen muss, um diese Leistung verordnen zu dürfen, werden an diser Stelle die möglichen Fachgebiete retourniert.
     Achtung beim Nacherfassen: Die Prüfung erfolgt bei der Speicherung auf die Fachgebiete des Originalverordners und nicht auf die des erfassenden Vertragspartners!
   - KVTs (1..n)
     Liste der KV-Träger die diese Leistung unterstützen. Wurde die Funktion auf einen KVT eingeschränkt, wird hier nur immer genau ein KV-Träger retourniert.

Hinweis zu den Katalogleistungen für den Antragstyp "ROEU" (Röntgen / Sonographie):
Die Katalogdaten für den Antragstyp "ROEU" (Röntgen / Sonographie) enthalten die Leistungen für Röntgen und für Sonographie. Eine Einschränkung auf die entsprechenden Leistungen für Röntgen bzw. Sonsographie ist anhand des Anzeigetextes möglich. Jenachdem ob es sich um eine Röntgen oder eine Sonographie Leistung handelt sind die ersten Zeichen des Anzeigetextes gleich "RÖ - " oder "SO - " (gefolgt vom Leistungstext).

### Informationen zur Terminvereinbarung

Um für einen Antrag eine Terminvereinbarung bekannt gegeben zu können, muss die Antragsreferenz bekannt sein.
Eine Terminvereinbarung kann nur dann erfolgreich bekanntgegeben werden, wenn der meldende Vertragspartner auch eine Leistungsübernahme durchführen kann.
Die generelle Feststellung ob der Antrag übernehmbar ist, kann anhand folgender Daten im Antrag festgestellt werden:

- Der Antrag muss beantwortet sein (Antragsstatus "BEA") und
- das Gültigkeitsdatum darf noch nicht abgelaufen sein.
- Es darf noch keine Leistung übernommen (Leistungsstatus "U") oder abgerechnet (Leistungsstatus "R) sein.
- Die zu übernehmenden Leistungen dürfen nicht abgelehnt (Leistungsstatus "A") sein.

Sofern der Antrag generell übernehmbar ist, wird anhand der angegebenen Parameter geprüft, ob der Vertragspartner einen kurativen Vertrag mit einem für den Antragstyp des Antrags berechtigten Fachgebiet zum aktuell zuständigen KV-Träger des Patienten besitzt.
Ein Antrag kann immer nur eine aktive Terminvereinbarungsbekanntgabe besitzen, welche jedoch vom Vertragspartner der Bekanntgabe auch wieder widerrufen werden kann.
Im Zuge der Abfrage eines Antrags mit Code wird retourniert, ob eine Terminvereinbarung vorliegt. Sofern bereits eine Terminvereinbarung vorliegt wird zusätzlich retourniert, ob diese selbst oder durch einen anderen Vertragspartner bekanntgegeben wurde.
Wichtig: Eine Terminvereinabrung hat keine Auswirkungen auf eine Antragsübernahme!

### Informationen zur Antragsübernahme

Um einen Antrag übernehmen zu können, muss die Antragsreferenz bekannt sein.
Die generelle Feststellung ob der Antrag übernehmbar ist, kann anhand folgender Daten im Antrag festgestellt werden:

- Der Antrag muss beantwortet sein (Antragsstatus "BEA") und
- das Gültigkeitsdatum darf noch nicht abgelaufen sein.
- Es darf noch keine Leistung übernommen (Leistungsstatus "U") oder abgerechnet (Leistungsstatus "R) sein.
- Die zu übernehmenden Leistungen dürfen nicht abgelehnt (Leistungsstatus "A") sein.

Sind alle diese Bedingungen erfüllt, kann der Vertragspartner im Zuge der Übernahmefunktion angeben welche Leistungen er erbracht hat und somit übernehmen will.
Um die Übernahme positiv abschließen zu können, benötigt der Vertragspartner einen kurativen Vertrag mit einem berechtigten Fachgebiet zum aktuell zuständigen KV-Träger des Patienten.
Ein Antrag kann nur einmal übernommen werden. Wurden die falschen Leistungen zur Übernahme gemeldet (oder eine Leistung vergessen), muss die Übernahme widerrufen werden und die Übernahme erneut gemeldet werden.
Die Übernahme von Leistungen sperrt den Antrag vor der Übernahme durch einen anderen Vertragspartner.

### Informationen zur Antragsabfrage

Detaildaten eines Antrags können immer nur unter Angabe des Antragscodes und der SV- bzw. EKVK-Nummer (Kennnummer der Karte - Feld 8 auf der EKVK) abgefragt werden.
Mittels Scanner ist es auch möglich den QR-Code am Ausdruck einzucannen. Dieser beinhaltet die Informationen die man für die Abfrage mittels Code benötigt im folgenden Format:
<Servicekennung>^<Version>^<Antragscode>^<Patientenidentifikatior>
Die Servicekennung ist immer Fix mit eKOS versorgt.
Bei einem Antrag für einen SV-Patienten ist die Version gleich 11 und im Patientenidentifikatior ist die SV-Nummer enthalten.
D.h.: eKOS^11^<Antragscode>^<VSNR>
Beispiel: eKOS^11^W9RSKL^1866030395
Bei einem Antrag für einen EKVK-Patienten ist die Version gleich 12 und im Patientenidentifikatior ist die EKVK-Nummer enthalten.
D.h.: eKOS^12^<Antragscode>^<EKVK-Nummer>
Beispiel: eKOS^12^W9RSKL^4587452123654754521459631
Für "eigene" Anträge gibt es die Möglichkeit die Überblicksdaten abzufragen (die unter anderen auch den Antragscode und den Patienten beinhalten). Ein Antrag wird dann als "eigener" Antrag definiert wenn der abfragende Vertragspartner mindestens eines der folgenden Kriterien erfüllt:

- Antragsersteller
  Der Vertragspartner hat den Antrag über das eCS erfasst.
- Antragsverordner
  Der Vertragspartner ist im Antrag als Verordner eingetragen. Bei aktueller Erfassung über das eCS ist der Antragsersteller IMMER auch der Antragsverordner. Bei Nacherfassung über das eCS ist der Ersteller ungleich dem Verordner. Wird bei Nacherfassung der Verordner mittels VPNR angegeben und die VPNR ist im eCS bekannt, wird die VPNR auch technisch mit dem Antrag verknüpft. Der Vertragspartner dieser VPNR kann somit, obwohl er selbst den Antrag nicht elektronisch erfasst hat, den Antrag mittels der Abfrage der eigenen Anträge abfragen.
- Leistungserbringer
  Der Vertragspartner der die Leistungserbringung von Leistungen mittels Antragsübernahme elektronisch über das eCS gemeldet hat.

Zusätzlich werden bei der Abfrage der "eigenen" Anträge des Vertragspartners auch Anträge zurückgeliefert die keine der oben definierten Kritieren erfüllen. Dazu muss ein Antrag durch den Vertragspartner bereits einmal mittels Antragscode abgefragt worden und aktuell noch gültig sein. Solche Anträge werden nur dann bei der Suche zusätzlich retourniert, wenn bei der Suche keine explizite Einschränkung bzgl. der Rolle vorgenommen wurde.
Anträge bei denen der Vertragspartner keine der oben beschriebenen Rollen einnimmt (und die noch nie mittels Antragscode abgefragt wurden), können mittels der Suche nach eigenen Anträgen nicht ermittelt werden.
In diesem Fall handelt es sich um einen fremden, noch nicht eingesehenen bzw. eingesehenen aber abgelaufenen Antrag. Diese können nur eingesehen werden, wenn der Vertragspartner vom Patienten dazu berechtigt wird, indem der Patient den Antragscode und die VSNR bzw. EKVK (Kennnummer der Karte - Feld 8 auf der EKVK) für die Abfrage weitergibt. Es erfolgt in diesem Fall eine Abfrage der Detaildaten. Diese Abfrage liefert immer den kompletten Antrag zurück.
Wichtig: Durch die Bekanntgabe einer Terminvereinbarung wird der betroffene Antrag nicht zu einen "eigenen" Antrag!
Ist der Antrag aktuell im Status "In Evidenz" oder war zumindest einmal in diesem Status werden in den Detaildaten ebenfalls die Evidenzdaten retourniert. Diese beinhalten die Evidenzmeldungen des KV-Trägers, sowie alle Antworten auf die Evidenzmeldung.
Im Zuge der Detaildatenabfrage werden ebenfalls alle Informationen zu eventuell zum Antrag angegebenen Attachments retourniert.
Generell unterscheidet man zwischen den Antragsattachments und den Evidenzattachments.
Die Informationen zu den Antragsattachments werden direkt im Bewilligungsakt, die der Evidenzattachments in den Evidenzdaten retourniert.
Mit einer Ausnahme werden bei der Abfrage mittels Code keine Attachments selbst retourniert, sondern nur die Informationen zu den Attachments. Mittels DateiIds in den Attachmentinformationen (Objekt AttachmentInfo im Bewilligungsakt bzw. das entsprechende Objekt in den Evidenzbeantwortungen) können die gewünschten Attachments mittels einer eigenen Funktion heruntergeladen werden.
Es gilt äquivalent zur Attachmentangabe, dass die Summe aller Attachments 3 MB nicht überschreiten darf und max. 10 Dateien auf einmal heruntergeladen werden dürfen. Es wird dabei ein einziges ZIP Archiv mit den gewählten Anlagen retourniert. Dabei wird der Name der Dateien jeweils um die DateiID erweitert (diese wird vorangestellt) um evenutell ident heißende Dateien innerhalb des ZIP-Archivs mit einem eindeutigen Namen zu versehen.
Hinweis:Das ZIP Archiv wird durch das e-card System mit UTF-8 Encoding erstellt.
Die einzige Ausnahme bei der ein Attachment für Anlagen des Antrags direkt im Zuge der Abfragefunktion retourniert wird, ist bei bestimmten nacherfassten Anträgen. In diesem Fall wird genau die Originalverordnung automatisch mitgeliefert.
Wichtig: Wenn mehr als ein Antrags-Attachment vorhanden ist, sind im Objekt Attachment-Info alle diese Attachments aufgelistet. Es wird NUR das eine Attachment der Originalverordnung retourniert!

### Fotoinformation

Im Zuge folgender Funktionen ist die Übermittlung einer Fotoinformation möglich:

- Antragserfassung durch den Verordner - erfassenVerordnerAntrag()
- Nacherfassung durch einen anderen Vertragspartner - nacherfassenAntrag()
- Terminvereinbarung für einen Antrag bekanntgeben - bekanntgebenTerminvereinbarung()
- Leistungen eines Antrags übernehmen - uebernehmenAntragsleistungen

Wird in einer dieser Funktionen vom e-card Server eine Fotoinformation retourniert, so ist der im Parameter enthaltene String dem Vertragspartner anzuzeigen!

## Generelle Hinweise (Druckaufbereitung, Fehlerhandling)

### Hinweis Wording

#### eKOS vs. eBS

Wie bereits am Anfang der Service-Beschreibung erwähnt, sind folgende Bezeichnungen für das Service zu verwenden:
Auf der Oberfläche ist für "eBS "das Wording "eKOS" zu verwenden bzw. für "elektronisches Antrags- und Bewilligungsservice" als Wording "elektronisches Kommunikationsservice"!

#### Antrag vs. Bewilligungsakt
Die Funktionen zur Erfassung und Abfrage retournieren das "bewilligungsakt"-Objekt. Auf der Oberfläche ist das Wording "Antrag" zu verwenden!

#### Leistungsart vs. Antragstyp

Auf der Oberfläche ist für den "Antragstyp" das Wording "Leistungsart" zu verwenden!

### Hinweis Druckaufbereitung

Das EBS Service liefert im Objekt Bewilligungsakt den fertig aufbereiteten Druck im PDF Format mit.
Die Übermittlung erfolgt über die Schnittstelle als SOAP-Attachment mittels MTOM.

### Hinweis Konvertierung

Bei allen übermittelten Werten, die aus einer Benutzereingabe stammen, werden für die weitere Verarbeitung führende und folgende Leerzeichen entfernt.

### Hinweis Fehlermeldungen

Zur Vereinfachung des Fehlerhandlings auf Seiten der Vertragspartnersoftware sind im EBS-Service die Fehlermeldungen der Validierung, die einem Parameter zugeordnet werden können, nach folgendem Schema gestaltet und benannt worden: Sie setzen sich jeweils aus der Servicenummer, der ParameterID (Parameter, der den Fehler verursacht hat) sowie einer Nummer, die die Fehlerursache charakterisiert, zusammen.
Die Servicenummer für EBS ist "20".
Die Zuordnung der ParameterID zu den jeweiligen Parametern findet man in den Javadoc-Kommentaren der Objektbeschreibungen bei den einzelnen Parametern.
Fehlerursachen und dazugehörige Nummer:

Fehlerursache | Nummer
--- | ---
Pflichtfeld | 1 2
Formatfehler (Bsp.: Nur numerische Zeichen erlaubt) | 3
Wertebereichfehler (Bsp.: Wertebereich 0-99 oder ungültige Konstante) | 4
Zusätzliche Bedingungen (Bsp.: Keine Angabe erlaubt wenn Unfall ungleich "Ja" belegt ist.) | 5 6 7 8
Verknüpfte Bedingungen (Bsp.: Es muss entweder der eine oder der andere Parameter angegeben werden) | 0

Beispiel:
Bei der Erfassung eines CT-Antrags kann angegeben werden ob ein Unfall stattgefunden hat. In diesem Fall ist der Parameter Unfall im Objekt CtAntragsdaten mit "Ja" anzugeben. Für den Parameter Unfalldatum gilt die Bedingung: Muss angegeben werden wenn Unfall gleich "Ja" angegeben wurde. Der Parameter Unfalldatum besitzt für einen CT-Antrag die ParameterID 1107.
Wurde Unfall mit "Ja" angegeben, aber Unfalldatum nicht tritt die Exception EbsInvalidParameterException.CT_UNFALLDATUM_REQUIRED auf.
Diese enthält folgende Informationen:

- code: CL-2011071
- errorCode: 17
- message: Unfalldatum ist ein Pflichtfeld. (Unfall ist mit "Ja" belegt.)
- fieldCode: 201107

Der fieldCode beinhaltet die Servicenummer und die ParameterID und gibt an, um welchen Parameter es sich handelt:

20 | 1107
Servicenummer | ParameterID des Parameters Unfalldatum im Objekt CtAntragsdaten

Der Parameter code setzt sich zusammen aus:

- Kennzeichen für Client (CL-) oder Server (ZS-) Fehler,
- dem fieldCode und
- der Information welche Prüfung fehlgeschlagen ist (laut der oberen Tabelle "Fehlerursache und dazugehörige Nummer")

CL- | 20 | 1107 | 1
KZ für Client-Fehler | Servicenummer | ParameterID des Parameters Unfalldatum im Objekt CtAntragsdaten | Pflichtfeldverletzung
fieldCode

# Funktionalität des EBS-Service

Die Integration des eBS-Service in die Vertragspartnersoftware ist optional.

- Administrative Antragsdaten prüfen
- Antragserfassung durch den Verordner
- Originalverordner-VPNR prüfen
- Nacherfassung durch einen anderen Vertragspartner
- Antrag stornieren
- Auf Evidenzmeldung antworten
- Antrag mittels Code abfragen
- Eigene Anträge Abfragen
- Anlagen eines Antrags herunterladen
- Terminvereinbarung für einen Antrag bekanntgeben
- Terminvereinbarung widerrufen
- Leistungen eines Antrags übernehmen
- Leistungsübernahme eines Antrags widerrufen
- Verordnungskatalogdaten abfragen

## Administrative Antragsdaten prüfen

Die Funktion pruefenAdministrativeAntragsdaten() dient der Überprüfung der Patientendaten und der Erfüllung der leistungs- und vertragsrechtlichen Kriterien zur Antragserfassung.
Die leistungs- und vertragsrechtlichen Kriterien sind unterschiedlich in Abhängigkeit davon ob der Antrag direkt durch den Verordner (Funktion erfassenVerordnerAntrag) erfasst wird oder durch einen anderen Vertragspartner nacherfasst wird (Funktion nacherfassenAntrag()).
Geben Sie daher bereits in dieser Funktion mittels dem Parameter Aktuell an welche Art der Erfassung nachfolgend durchgeführt werden soll.
Aktuell gleich "Ja" bedeutet, dass die Ermittlung für die Erfassung durch den Verordner durchgeführt wird (Funktion erfassenVerordnerAntrag).
Aktuell gleich "Nein" bedeutet die nachfolgende Erfassung durch einen anderen Vertragspartner (Funktion nacherfassenAntrag()).
Bei Nacherfassung ist zusätzlich der Originalverordner anzugeben. Die Angabe kann mittels VPNR oder Verordner-Freitext-Angabe (Name und Adresse) erfolgen. Bei Angabe der VPNR wird geprüft ob der Originalverordner zur Ausstellung der Originalverordnung fachlich berechtigt gewesen ist. Weiters ist bei der Nacherfassung keine Fachgebietsangabe erlaubt.
Zusätzlich zu den Patientendaten und den zuständigen KV-Träger wird in dieser Funktion sofern gewünscht der zulässige Leistungskatalog für die weitere Antragserfassung ermittelt. Die Katalogdaten können auch selbstständig ermittelt und verwaltet werden (siehe Katalogdaten abfragen). Die Steuerung ob pruefenAdministrativeAntragsdaten() auch den Leistungskatalog ermitteln soll, erfolgt in der Funktion mittels des Parameters "keineVokErmittlung". Bitte beachten Sie, dass für den Parameter bei Nichtangabe der Defaultwert "true" verwendet wird (und somit KEIN Katalog ermittelt wird).

##### Szenario 5 - Administrative Antragsdaten prüfen

## Antragserfassung durch den Verordner

Die Funktion erfassenVerordnerAntrag() dient der Erfassung eines Antrags direkt durch den Verordner.
Das Verordnungsdatum des Antrags ist immer der aktuelle Tag der Erfassung.
Zur Durchführung muss zuerst ein Aufruf der Funktion pruefenAdministrativeAntragsdaten() unter Angabe von Aktuell gleich "Ja" erfolgen um den aktuell für den Patienten zulässigen Leistungskatalog zu ermitteln (Trägerabhängig).
Für weitere Informationen bzgl. der Antragserfassung siehe auch Kapitel Informationen zur Antragserfassung.
Die Funktion retourniert sofern kein Fehler aufgetreten ist das Objekt BewilligungsaktFoto. In diesem ist der fertige Bewilligungsakt, sowie unter Umständen eine Fotoinformation.
Im Bewilligungsakt sind die beantragten Leistungen und eventuell die entschiedenen Leistungen versorgt. Weiter Information hinsichtlich der Leistungen siehe Kapitel Informationen zu den Leistungen im Bewilligungsakt. Zusätzlich ist im Bewiligungsakt die Druckaufbereitung als PDF enthalten.
Fotoinformation:
Wird im Rückgabeobjekt BewilligungsaktFoto durch den e-card Server der Parameter Fotoinformation versorgt, so ist der darin enthaltene String dem Vertragspartner anzuzeigen.

##### Szenario 5 - Antragserfassung durch den Verordner

## Originalverordner-VPNR prüfen

Die Funktion pruefenOriginalverordnerVpnr() dient der Überprüfung der Originalverordner-VPNR.
Es wird dabei geprüft ob zu der angegebenen VPNR Daten ermittelt werden können. Ist eine Ermittlung möglich kann diese VPNR als VPNR des Originalverordners in der Funktion nacherfassenAntrag() verwendet werden.
Nachdem es nicht zulässig ist einen Antrag unter Angabe der eigenen VPNR als Originalverordner-VPNR nachzuerfassen, ist auch in dieser Funktion die Angabe der eigenen VPNR (des Dialogaufbaus) nicht zulässig.

##### Szenario 5 - Originalverordner-VPNR prüfen

## Nacherfassung durch einen anderen Vertragspartner

Die Funktion nacherfassenAntrag() dient der Nacherfassung eines Antrags direkt durch einen anderen Vertragspartner.
Als Basis für die Erfassung dient die auf Papier vorliegende Originalverordnung. Diese ist bei der Nacherfassung zwingend als Attachment anzugeben.
Zur Durchführung muss zuerst ein Aufruf der Funktion pruefenAdministrativeAntragsdaten() unter Angabe von Aktuell gleich "Nein" und der Angabe des Originalverordners erfolgen. Dadurch wird einerseits der aktuell für den Patienten zulässigen Leistungskatalog zu ermittelt (Trägerabhängig) sowie geprüft ob der Originalverordner zur Ausstellung der Originalverordnung fachlich berechtigt war (bei Angabe der VPNR des Originalverordners).
Für weitere Informationen bzgl. der Antragserfassung siehe auch Kapitel Informationen zur Antragserfassung.
Die Funktion retourniert sofern kein Fehler aufgetreten ist das Objekt BewilligungsaktFoto. In diesem ist der fertige Bewilligungsakt, sowie unter Umständen eine Fotoinformation.
Im Bewilligungsakt sind die beantragten Leistungen und eventuell die entschiedenen Leistungen versorgt. Weiter Information hinsichtlich der Leistungen siehe Kapitel Informationen zu den Leistungen im Bewilligungsakt. Zusätzlich ist im Bewiligungsakt die Druckaufbereitung als PDF enthalten.
Fotoinformation:
Wird im Rückgabeobjekt BewilligungsaktFoto durch den e-card Server der Parameter Fotoinformation versorgt, so ist der darin enthaltene String dem Vertragspartner anzuzeigen.

##### Szenario 5 - Nacherfassung durch einen anderen Vertragspartner

## Antrag stornieren

Die Funktion stornierenAntrag() dient der Stornierung des Antrags.
Ein Antrag kann solange storniert werden wie folgende Bedingungen erfüllt sind:

- es wurden noch keine Leistungen im Antrag übernommen oder abgerechnet
- der Antrag ist noch nicht storniert
- der Antrag ist noch nicht abgelaufen

Die Stornierung des Antrags mittels der SS12 kann durch folgende Akteure des Antrags vorgenommen werden:

- dem Erfasser
- dem Verordner

Zur Stornierung muss der Antragscode bekannt sein. Es muss außerdem mittels stornogrund angegeben werden, warum der Antrag storniert wird.
Der Antrag kann auch direkt durch den Patienten oder den KV-Sachbearbeiter storniert werden. Wird mittels der Detaildatenabfrage ein stornierter Antrag abgefragt, wird im Parameter rolleStornierung die Information retourniert ob die Stornierung durch den abfragenden Vertragspartner durchgeführt wurde. Ist der Wert gleich "true" enthält der Parameter stornokennung den Wert "VP". Ist rolleStornierung gleich "false" ist der Parameter stornokennung wie folgt zu interpretieren:

- VP - Storno durch einen anderen Vertragspartner
- KV - Storno durch den KV-Sachbearbeiter
- VS - Storno durch den Patienten

## Auf Evidenzmeldung antworten

Die Funktion beantwortenEvidenzmeldung() dient der Beantwortung einer Evidenzmeldung des zustängigen KV-Trägers.
Weiter Information hinsichtlich Evidenzmeldungen siehe Kapitel Prinzipieller Ablauf - Abschnitt "Abweichung zum Standardfall / Der KV-Träger kann aufgrund der übermittelten Antragsdaten den Antrag nicht beantworten". Sollte auch aufgrund der eingelangten Evidenzantworten keine Beantwortung durch den KV-Träger möglich sein, kann der Sachbearbeiter eine erneute Evidenzmeldung erzeugen (d.h. den Antrag von "In Evidenz" erneut in den Status "In Evidenz" setzen.

## Antrag mittels Code abfragen

Die Funktion abfragenAntragMitCode() dient einerseits der Abfrage von fremden Anträgen (bei denen der ausführende Vertragspartner weder die Rolle des Erfassers, des Verordners, noch des Leistungserbringers im Antrag hat), sowie der Detaildatenabfrage von eigenen Anträgen. Es wird dabei immer der komplette Antrag retourniert.
Weiter Information hinsichtlich der Abfrage siehe Kapitel Informationen zur Antragsabfrage.
Hinweis: Jede Abfrage durch einen Vertragspartner wird im eCS protokolliert.

##### Szenario 5 - Antrag mittels Code abfragen

## Eigene Anträge Abfragen

Die Funktion abfragenEigeneAntraege() dient der Abfrage der Anträge bei denen der abfragende Vertragspartner eine der Rollen "Verordner", "Erfasser" oder "Leistungserbringer" inne hat bzw. von Anträgen die durch den abfragenden Vertragspartner bereits einmal mittels Antragscode abgefragt wurden (sofern diese noch nicht abgelaufen sind).
Es werden in diesem Fall nur Überblicksdaten der gefundenen Anträge retourniert. Sofern die Abfrage des kompletten Bewilligungsakts notwendig ist, sind die Detaildaten mittels der Funktion abfragenAntragMitCode() abzurufen.
Weiter Information hinsichtlich der Abfrage siehe Kapitel Informationen zur Antragsabfrage.

## Anlagen eines Antrags herunterladen

Die Funktion herunterladenAttachments() dient dem Herunterladen von Attachements die mit dem Antrag verbunden sind.
Dabei können sowohl Antrags- als auch Evidenzattachments heruntergeladen werden. Weiter Information hinsichtlich dem Herunterladen von Attachments siehe Kapitel Informationen zur Antragsabfrage.

##### Szenario 5 - Anlagen eines Antrags herunterladen

## Terminvereinbarung für einen Antrag bekanntgeben

Die Funktion bekanntgebenTerminvereinbarung() dient der Bekanntgabe, dass der leistungserbringende Vertragspartner und der Patient des Antrags einen Termin vereinbart haben.
Die Funktion fordert als Eingangsparameter neben dem KV-Träger und dem Fachgebiet, die Antragsreferenz, sowie die Information welche Leistungen übernommen werden sollen.
Eine Bekanntgabe einer Terminvereinbarung ist nur möglich wenn der Vertragspartner einen passenden kurativen Vertrag zum KV-Träger des Patienten zum Zeitpunkt der Bekanntgabe der Terminvereinbarung besitzt.
Fotoinformation:
Wird im Rückgabeobjekt BewilligungsaktReferenzFoto durch den e-card Server der Parameter Fotoinformation versorgt, so ist der darin enthaltene String dem Vertragspartner anzuzeigen.
Weiter Information hinsichtlich der Terminvereinbarung siehe Kapitel Informationen zur Terminvereinbarung.

##### Szenario 5 - Terminvereinbarung für einen Antrag bekanntgeben

## Leistungsübernahme eines Antrags widerrufen

Die Funktion widerrufenTerminvereinbarung() dient dem Widerruf einer Terminvereinbarung.
Durch Ausführung der Funktion wird eine bekanntgegebene Terminvereinbarung storniert. Der Antrag ist somit wieder offen für die Bekanntgabe einer Terminvereinabrung durch andere mögliche Leistungserbringer.
Weiter Information hinsichtlich der Terminvereinbarung siehe Kapitel Informationen zur Terminvereinbarung.

## Leistungen eines Antrags übernehmen

Die Funktion uebernehmenAntragsleistungen() dient der Übermittlung, dass der Leistungserbringer Leistungen des Antrag erbracht (übernommen) hat.
Vor Übernahme muss eine Abfrage der Detaildaten erfolgt sein. Nur mittels dieser Abfrage können die später benötigten Ids ermittelt werden. Die Funktion fordert als Eingangsparameter neben dem KV-Träger und dem Fachgebiet, die Antragsreferenz, sowie die Information welche Leistungen übernommen werden sollen.
Wird der Parameter alleUebernehmen mit "Ja" angegeben, dürfen keine spezifischen Leistungen mittels der Entscheidungspositionen angegeben werden. In diesem Fall werden bei der Übernahme alle übernehmbaren Leistungen übernommen. Wird der Parameter mit "Nein" angegeben, müssen die zu übernehmenden Leistungen mittels deren Entscheidungspositionen im Antrag angegeben werden.
Eine Übernahme ist nur möglich wenn der Vertragspartner einen passenden kurativen Vertrag zum KV-Träger des Patienten zum Zeitpunkt der Übernahme besitzt.
Fotoinformation:
Wird im Rückgabeobjekt BewilligungsaktFoto durch den e-card Server der Parameter Fotoinformation versorgt, so ist der darin enthaltene String dem Vertragspartner anzuzeigen.
Weiter Information hinsichtlich der Übernahme siehe Kapitel Informationen zur Antragsübernahme bzw. Kapitel Informationen zu den Leistungen im Antrag/Bewilligungsakt bzgl. den Entscheidungspositionen der zu übernehmenden Leistungen.

##### Szenario 5 - Leistungen eines Antrags übernehmen

## Leistungsübernahme eines Antrags widerrufen

Die Funktion widerrufenUebernahme() dient dem Widerruf der Leistungsübernahme eines Antrags.
Durch Ausführung der Funktion werden bei allen übernommenen Leistungen die Übernahmeinformationen widerrufen. Der Antrag ist somit wieder offen für andere mögliche Leistungserbringer bzw. für eine erneute Übernahme durch den ausführenden Vertragspartner.
Weiter Information hinsichtlich der Übernahme und dem Widerruf siehe Kapitel Informationen zur Antragsübernahme.

## Verordnungskatalogdaten abfragen

Mittels der Funktion abfrageVokVersionen() wird ermittelt welche Version aktuell in Verwendung ist bzw. ob bereits eine zukünftige Version zur Abfrage vorhanden ist.
Die Abfrage der Daten selbst erfolgt mittels der Funktion abfrageVokDaten().
Weiter Information hinsichtlich der Abfrage der Verordnungskatalogdaten siehe Kapitel Informationen zur Katalogabfrage.