# Package at.chipkarte.client.ebs.soap

Interface und Klassen des elektronischen Kommunikationsservice (eKOS).

See: Description

- Interface Summary
  Interface | Description
  --- | ---
  IEbsService | Dieses Service stellt die Funktionalitäten des elektronischen Bewilligungs- und Antragsservice (EBS) Version 9 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 (eKOS). Enthält den SOAP-Endpoint `IEbsService` sowie die dazu notwendigen Klassen.
Inhalt der eKOS Package-Beschreibung:

- Allgemein

- eKOS vs. eBS
- 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 eKOS

- 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, u.a.)

- Funktionalität des eKOS

- 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

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

## Wording

### eBS vs. eKOS

Die fachlich korrekte Bezeichung des Service ist eKOS - "elektronisches Kommunikationsservice". Aus historischen Gründen wird das Service schnittstellenseitig als "eBS" (elektronisches Bewilligungs- und Antragsservice) bezeichnet.
Als Anzeigetext in der Vertragspartner-Software ist folgendes Wording zu verwenden:

- Kurztext: eKOS
- Langtext: elektronisches Kommunikationsservice

### Bewilligungsakt vs. Antrag

Die Funktionen zur Erfassung und Abfrage retournieren das Objekt bewilligungsakt. Auf der Benutzer-Oberfläche der Software ist das Wording "Antrag" zu verwenden.

### Antragstyp vs. Leistungsart

Auf der Benutzer-Oberfläche der Software ist anstatt "Antragstyp" das Wording "Leistungsart" zu verwenden.

## Rechte

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

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

Funktionen | benötigte Rechte | Fehlermeldung bei Aufruf ohne den benötigten Rechten
--- | --- | ---
Antrag stornieren Auf Evidenzmeldung antworten Antrag mittels Code abfragen Eigene Anträge abfragen Anlagen eines Antrags herunterladen eKOS relevante Träger abfragen eKOS 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

Mittels 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, welche 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 die Fehlermeldung CL-2090045 (eBSInvalidParameterException.ANTRAGSTYP_INVALID2).
Das Recht EBS.U2 dient zur Nutzung der Antragstypen ROET und ROEU. Da die Leistungsarten Röntgen und Sonographie, sowie Röntgentherapie derzeit in eKOS noch nicht freigeschalten sind, hat das Recht EBS.U2 aktuell noch keine Auswirkung. Informationen zum Start des Pilotbetriebs und flächendeckenden Rollout der U2-Leistungsarten können beim SVC Partnersupport erfragt werden.

## 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 angebotenen Methoden ermittelt werden:

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

## Online-/Offline-Status

Ob eine Verbindung für ein bestimmtes Service zum e-card System 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.

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

Bei eKOS Funktionen mit Kartenunterstützung gibt es folgende Eingabevariante zur Identifikation des Patienten:

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

Der e-card CardToken (SV-Signaturtoken mit e-card) kann mittels REST-Schnittstelle vom GINO angefordert werden.
Die Dokumentation des REST-Service zur Kommunikation mit dem Kartenleser ist zu finden unter: Swagger Doku Kartenleser.
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. Der 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 eKOS wird nur der 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 eKOS 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 CardToken verwendet wurde. Ein EKVK-Patient muss mittels den EKVK-Daten angegeben werden. Eine Angabe der EKVK-Nummer gemeinsam mit der SV-Nummer oder einem e-card CardToken ist nicht zulässig.

## Prinzipielle Erklärungen und Ablauf für die Verwendung von eKOS:

### Prinzipieller Ablauf

eKOS stellt aktuell die Erfassung von Anträgen für 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 e-card System 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 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.
Es gibt im Gegensatz zu ABS keine zeitliche Vorgabe innerhalb derer ein eKOS 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. Wurde bei der Erfassung angegeben, dass der Patient ebenfalls eine Verständigung erhalten will, wird 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 beliebigen Leistungserbringer gehen. Mittels Antragscode und SV- bzw. EKVK-Nummer erhält dieser Zugriff auf die Antragsdaten. Somit ist es dem 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 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 (Kennzeichnung der Leistungserbringung). Die Leistungsübernahme kann unabhängig von einer Terminvereinbarung erfolgen.

Abweichungen zum Standardfall:
Der verordnende Arzt stellt die Verordnung nicht elektronisch aus.
Der Verordner untersucht einen Patienten und stellt fest, dass dieser weitere Untersuchungen benötigt. Der Antrag wird jedoch in diesem Fall nicht durch den Verordner elektronisch im e-card System 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 "MeineSV" nacherfassen.
- zum KV-Träger gehen um den Antrag von einem Sachbearbeiter nacherfassen zu lassen.

Eine Nacherfassung durch einen anderen Vertragspartner wird in der Regel durch einen Leistungserbringer vorgenommen; d.h. der Patient geht mit der Verordnung zum leistungerbringenden Institut bzw. Arzt seiner Wahl. Dort wird der Antrag für den Patienten elektronisch nacherfasst.
Prinzipiell hat jeder Vertragspartner mit dem Recht EBS.ANTRAG die Möglichkeit, einen papierschriftlichen Antrag für einen Patienten nachzuerfassen, sofern er die notwendigen Berechtigungen zur Verwendung des gewünschten Antragstypen besitzt. Beispiel: Bei Ausstellung der papierschriftlichen Verordnung durch einen Facharzt kann die Nacherfassung auch durch den Hausarzt vorgenommen werden, sofern dieser die entsprechenden Rechte hat.
Hinweis: Bei einer Nacherfassung erfolgt die Überprüfung, ob der Originalverordner zur Ausstellung der papierschriftlichen Verordnung zum Verordnungsdatum berechtigt gewesen wäre. Zusätzlich erfolgt eine Überprüfung des ursprünglichen Verordnungsdatums. Die Nacherfassung einer papierschriftlichen Verordnung ist nur immerhalb eines Monats zulässig.
Bei der Nacherfassung muss der Originalverordner angegeben und die Original-Verordnung als eingescanntes Attachment hinzugefügt werden. Der Antrag wird, wie im Standardfall, im e-card System 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 im e-card System 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 KV-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, 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 e-card Messaging der Erfasser, sowie der Verordner informiert. In diesem Fall enthält der Antrag bei der Abfrage der Detaildaten das Objekt Evidenzdaten, in dem die Evidenzmeldung mit der entsprechenden Fragestellung durch den KV-Träger enthalten ist. Jeder Vertragspartner, der Zugriff auf den Antrag hat (Antragscode und SV- bzw. EKVK-Nummer bekannt), kann auf die Evidenzmeldung antworten. Somit kann auch ein zukünftiger Leistungserbringer auf die Evidenzmeldung antworten.
Hinweis: Die Beantwortung ist auch durch den Patienten über "MeineSV" möglich.
Die Beantwortung ist mittels der Übermittlung einer Freitext-Antwort und/oder 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 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ützte KV-Träger
Mittels der im Kapitel Dynamische Ermittlung von Parameterwerten des e-card-Regelwerks angeführten Funktionen können u.a. eKOS relevanten KV-Träger, sowie eKOS Antragstypen ermittelt werden.
Die Liste der Antragstypen enthält u.a. folgende Informationen:

- Codewert
- Anzeigetext
- 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, die in der Software angezeigt wird, soll abhängig von den Rechten des angemeldet Vertragspartner eingeschränkt werden. (Die Rechte eines Vertragspartners können mit der BASE-Funktion getBerechtigungen() abgefragt werden.) Durch die Verwendung der retournierten Werte aus der Liste der eKOS 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 einer Nacherfassung
Die aktuelle Erfassung ist nur durch den Verordner selbst möglich:
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ähltem Antragstyp das spezifische Antragstyp-Recht. Bei der aktuellen Erfassung muss ein Fachgebiet angegeben werden. Es werden nur Fachgebiete unterstützt, zu denen der Vertragspartner mit dem Standort des aktuellen Dialogs einen kurativen Vertrag besitzt. Im Zuge der Erfassung wird geprüft, ob laut des leistungszuständigen KV-Trägers des Patienten das angegebenen Fachgebiet für den gewählten Antragstypen zur Erfassung zulässig ist.
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" laut eKOS.
Ist das Fachgebiet zulässig und handelt es sich um keinen passenden Vertrag zum leistungszuständigen KV-Träger des Patienten, erfasst der Vertragspartner den Antrag mit dem Partnerstatus "Wahlpartner" laut eKOS. 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).
Die Nacherfassung eines Antrags ist nur für Vertragspartner ungleich dem Verordner möglich (als VPNR des Originalverordners kann nicht die eigene VPNR verwendet werden).
Der nacherfassende Vertragspartner benötigt zur Erfassung das Recht EBS.ANTRAG und je nach ausgewähltem 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.
Eine Nacherfassung ist nur möglich, wenn der Originalverordner zur Ausstellung der Verordnung (fachlich) berechtigt war.
Bei der Antragserfassung sind die gewünschten Leistungen zu erfassen.
Innerhalb eines Antrags muss mindestens eine Leistung angegeben werden. Es können max. zehn Leistungen mittels eines Antrags erfasst werden.
Die gewünschten Leistungen eines Antrags können entweder mittels eines Leistungskatalogs gewählt 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 (RoeuAntragsdaten). Das Indiaktionsobjekt 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 des Indiaktionsobjekts:

- 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 Bezeichnung der Dateien ist dabei ident zu den tatsächlichen Dateien anzugeben (Berücksichtigung von Groß-, Kleinschreibung der Dateien notwendig).
Im Zuge der Nacherfassung ist die Angabe der Originalverordnung zwingend notwendig. Es muss zum einen das Objekt AttachmentInfo mit mindestens einer Dateiinfo für die Originalverordnungsdatei mit dem Namen der Datei und dem Dateiinhaltstyp gleich "V" enthalten sein. Zum anderen muss ein ZIP-Archiv mit mindestens einer Datei übergeben werden.
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 (SVNR oder EKVK-Kennnummer der Karte) eindeutig. Der Antragscode dient gemeinsam mit dem Personenidentifikator als

- Zugriffsmöglichkeit auf den Antrag bei den meisten Aktionen innerhalb von eKOS
- 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()
   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 gibt 20 Katalogleistungen und vier Kategorien. Jeweils fünf Leistungen verweisen auf dieselbe Kategorie. Mittels Auswahl einer Kategorie kann die Auswahl der Leistungen auf die fünf verknüpften Leistungen eingeschränkt werden; z.B. Kategorie "Extremitäten" mit zugeordneten Leistungen "Arm", "Hand", "Bein", u.a.
   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 → Austrian PACS Procedure Code zur Leistung (optional)
2. Durch explizite Abfrage des Katalogs und Verwaltung durch die VPSW
   Die Ermittlung findet mit folgenden Funktionen statt:
   - abfrageVokVersionen()
   - abfrageVokDaten()
   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.
   Je nachdem, ob auf einen Antragstyp eingeschränkt wurde oder nicht, werden 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 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 dieser 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 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. Sonographie ist anhand des Anzeigetextes möglich. Je nachdem, 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 geben 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.
Ob der Antrag übernehmbar ist, kann anhand folgender Daten im Antrag festgestellt werden:

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

Ist der Antrag übernehmbar, wird anhand der angegebenen Parameter geprüft, ob der Vertragspartner einen kurativen Vertrag mit einem für diesen Antragstyp berechtigten Fachgebiet zum zuständigen KV-Träger des Patienten besitzt.
Ein Antrag kann immer nur eine aktive Terminvereinbarungsbekanntgabe besitzen, welche jedoch vom Vertragspartner der Bekanntgabe auch 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 Auswirkung auf eine Antragsübernahme.

### Informationen zur Antragsübernahme

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

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

Sind alle Bedingungen erfüllt, kann der Vertragspartner im Zuge der Übernahmefunktion angeben, welche Leistungen er erbracht hat und übernehmen will.
Um die Übernahme positiv abschließen zu können, benötigt der Vertragspartner einen kurativen Vertrag mit einem berechtigten Fachgebiet zum 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 und die Übernahme erneut gemeldet werden.
Die Übernahme von Leistungen sperrt den Antrag; er kann nicht von einem anderen Vertragspartner übernommen werden.

### Informationen zur Antragsabfrage

Detaildaten eines Antrags können immer nur unter Angabe des Antragscodes und der SV- bzw. EKVK-Nummer abgefragt werden.
Es ist auch möglich, den QR-Code des Ausdrucks zu scannen. Dieser beinhaltet die Informationen, die für die Abfrage mittels Code benötigt werden:
<Servicekennung>^<Version>^<Antragscode>^<Patientenidentifikator>
Die Servicekennung ist immer mit eKOS versorgt.
Bei einem Antrag für einen SV-Patienten ist die Version gleich 11 und im Patientenidentifikator die SV-Nummer enthalten:
eKOS^11^<Antragscode>^<SVNR>
Beispiel: eKOS^11^W9RSKL^1866030395
Bei einem Antrag für einen EKVK-Patienten ist die Version gleich 12 und im Patientenidentifikator die EKVK-Nummer enthalten:
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 anderem 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 e-card System erfasst.
- Antragsverordner
  Der Vertragspartner ist im Antrag als Verordner eingetragen. Bei aktueller Erfassung über das e-card System ist der Antragsersteller immer auch der Antragsverordner. Bei Nacherfassung über das e-card System ist der Ersteller ungleich dem Verordner. Wird bei Nacherfassung der Verordner mittels VPNR angegeben und die VPNR ist im e-card System bekannt, wird die VPNR auch technisch mit dem Antrag verknüpft. Der referenzierte Vertragspartner kann somit, obwohl er selbst den Antrag nicht elektronisch erfasst hat, den Antrag mittels der Abfrage der eigenen Anträge abrufen.
- Leistungserbringer
  Der Vertragspartner hat die Leistungserbringung von Leistungen mittels Antragsübernahme elektronisch über das e-card System gemeldet.

Zusätzlich werden neben den "eigenen" Anträgen 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 mittels Abfrage der Detaildaten nur eingesehen werden, wenn der Vertragspartner vom Patienten dazu berechtigt wird (durch Bekanntgabe der Antragscodes und die SVNR bzw. EKVK-Nummer). Die Abfrage der Detaildaten liefert den kompletten Antrag zurück.
Wichtig: Durch die Bekanntgabe einer Terminvereinbarung wird der betroffene Antrag nicht zu einen "eigenen" Antrag.
Ist oder war der Antrag zumindet einmal im Status "In Evidenz", 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 möglichen Attachments im Antrag retourniert.
Man unterscheidet zwischen Antragsattachments und Evidenzattachments.
Die Informationen zu den Antragsattachments werden direkt im Bewilligungsakt, die der Evidenzattachments in den Evidenzdaten retourniert.
Grundsätzlich 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 der Funktion herunterladenAttachments 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 ein ZIP-Archiv mit den gewählten Anlagen retourniert. Dabei wird der Name der Dateien jeweils um die DateiID (vorangestellt) erweitert 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 die Originalverordnung automatisch mitgeliefert.
Wichtig: Wenn mehr als ein Antragsattachment vorhanden ist, sind im Objekt AttachmentInfo alle Attachments aufgelistet. Es wird nur das 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 System eine Fotoinformation retourniert, so ist der im Parameter enthaltene String dem Vertragspartner anzuzeigen.

## Generelle Hinweise (Druckaufbereitung, Fehlerhandling)

### Hinweis Druckaufbereitung

eKOS liefert im Objekt bewilligungsakt den fertig aufbereiteten Druck als PDF.
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 nachgestellte Leerzeichen (leading and trailing whitespaces) entfernt.

### Hinweis Fehlermeldungen

Zur Vereinfachung des Fehlerhandlings seitens Vertragspartnersoftware sind in eKOS die Fehlermeldungen der Validierung, die einem Parameter zugeordnet werden können, nach folgendem Schema gestaltet und benannt: 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 eKOS 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 (z.B. numerische Zeichen erlaubt) | 3
Wertebereichfehler (z.B. Wertebereich 0-99 oder ungültige Konstante) | 4
Zusätzliche Bedingungen (z.B. keine Angabe erlaubt, wenn Unfall ungleich "Ja") | 5 6 7 8
Verknüpfte Bedingungen (z.B. 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 eKOS

Die Integration des eKOS 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()).
Bei diesen Funktionen soll mittels Parameter aktuell angegeben werden, welche Art der Erfassung nachfolgend durchgeführt wird.
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 dem 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". Für den Parameter soll bei Nichtangabe der Defaultwert "true" verwendet werden (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, trägerabhängigen Leistungskatalog zu ermitteln.
Für weitere Informationen bzgl. der Antragserfassung siehe auch Kapitel Informationen zur Antragserfassung.
Die Funktion retourniert - sofern kein Fehler aufgetreten ist - das Objekt bewilligungsaktFoto. Dieses enthält den fertigen Bewilligungsakt, sowie ggf. eine Fotoinformation.
Im Bewilligungsakt sind die beantragten und eventuell die entschiedenen Leistungen versorgt. weitere Informationen 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 das e-card System 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 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 durch einen anderen Vertragspartner.
Als Basis für die Erfassung dient die auf Papier vorliegende Originalverordnung. Diese ist bei der Nacherfassung zwingend als Attachment mitzusenden.
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ässige, trägerabhängige Leistungskatalog ermittelt, 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. Dieses enthält den fertigen Bewilligungsakt, sowie ggf. eine Fotoinformation.
Im Bewilligungsakt sind die beantragten Leistungen und die eventuell entschiedenen Leistungen versorgt. weitere Informationen 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 das e-card System 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 storniert werden, solange 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 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

## Antwort auf Evidenzmeldung

Die Funktion beantwortenEvidenzmeldung() dient der Beantwortung einer Evidenzmeldung des zustängigen KV-Trägers.
weitere Informationen 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 Erfasser, Verordner noch Leistungserbringer ist), sowie der Detaildatenabfrage von eigenen Anträgen. Es wird dabei immer der komplette Antrag retourniert.
weitere Informationen hinsichtlich der Abfrage siehe Kapitel Informationen zur Antragsabfrage.

##### 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.
weitere Informationen hinsichtlich der Abfrage siehe Kapitel Informationen zur Antragsabfrage.

## Anlagen eines Antrags herunterladen

Die Funktion herunterladenAttachments() dient dem Herunterladen von Attachements eines Antrags.
Dabei können sowohl Antrags- als auch Evidenzattachments heruntergeladen werden. weitere Informationen hinsichtlich Attachment-Download 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.
Die 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 das e-card System der Parameter fotoinformation versorgt, so ist der darin enthaltene String dem Vertragspartner anzuzeigen.
weitere Informationen 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 Leistungserbringer.
Weitere Informationen 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 das e-card System der Parameter fotoinformation versorgt, so ist der darin enthaltene String dem Vertragspartner anzuzeigen.
Weitere Informationen 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 Leistungserbringer bzw. für eine erneute Übernahme durch den ausführenden Vertragspartner.
Weitere Informationen 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().
Weitere Informationen hinsichtlich der Abfrage der Verordnungskatalogdaten siehe Kapitel Informationen zur Katalogabfrage.