# Package at.chipkarte.client.dbas.soap

Interface und Klassen des Dokumentationsblattannahme-Service (DBAS).

See: Description

- Interface Summary
  Interface | Description
  --- | ---
  IDbasService | Dieses Service stellt die Funktionalitäten des Dokumentationsblatt Annahme Service (DBAS) zur Verfügung.

- Class Summary
  Class | Description
  --- | ---
  Betreuung | Diese Klasse hält die Daten eines Betreuungsverhältnisses, an das das entsprechende Datenblatt zugeordnet werden kann.
  CreateDatenblattErgebnis | Enthält das Ergebnis der Funktionen `createDatenblattAllgemeinesProgramm`, `createDatenblattDmpDm2`.
  DatenblattAllgemeinesProgramm | Enthält die Eingangsdaten zum Aufruf der Funktion createDatenblattAllgemeinesProgramm.
  DatenblattDmpDm2 | Enthält die Eingangsdaten zum Aufruf der Funktion createDatenblattDmpDm2.
  DatenblattKoloskopie | Enthält die Eingangsdaten zum Aufruf der Funktion createDatenblattKoloskopie beziehungsweise der Funktion createDatenblattQZKoloskopie.
  DatenblattKoloskopieUntersuchungsergebnisse | Enthält die Ergebnisse der Untersuchung zum DatenblattKoloskopie ParameterID: 120560.
  DatenblattPapAbstrich | Enthält die Eingangsdaten zum Aufruf der Funktion createDatenblattPapAbstrich.
  DmpData | Enthält das Ergebnis der Funktion `searchDmpData`.
  KonsultationData | Enthält das Ergebnis der Funktion `searchKonsultationData`.
  KonsultationInfo | Diese Klasse hält die Daten einer Konsultation, an die das entsprechende Datenblatt zugeordnet werden kann.
  PatientInfo | Enthält das Ergebnis der Funktion `searchDmpData`.
  Quittung | Empfangsbestätigung der Funktionen `createDatenblattAllgemeinesProgramm`, `createDatenblattPapAbstrich`, `createDatenblattKoloskopie`, `createDatenblattQZKKoloskopie`, `createDatenblattDmpDm2`.
  QuittungSearchCriteria | Enthält die Daten zur Einschränkung der Datensätze im Zuge der Funktion `searchQuittungen`.

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

Interface und Klassen des Dokumentationsblattannahme-Service (DBAS). Enthält den SOAP-Endpoint `IDbasService` sowie die dazu notwendigen Klassen.
Inhalt der DBAS package-Beschreibung:

- Allgemein

- Rechte
- Dynamische Ermittlung von Parameterwerten des e-card-Regelwerks
- Online-/Offline-Status
- SV-Nummer vs. e-card CardToken
- Prinzipielle Erklärungen und Ablauf für die Verwendung des Dokumentationsblattannahme-Service

- Funktionalität des DBAS

- Fachdaten abfragen
- Datenblatt übermitteln
- Empfangsbestätigungen abfragen

## Allgemein

Vertragspartner haben die Möglichkeit zu durchgeführten Vorsorge- bzw. DMP-Untersuchungen Dokumentations-/Befundblätter elektronisch an die auswertenden Stellen zu übermitteln.

### Rechte

Für die Funktionen des DBAS benötigt der Vertragspartner für die Durchführung das Recht DBAS.CORE.
Wird eine Funktion, welche dieses Recht benötigt, ohne das entsprechende Recht aufgerufen, erhält man die Exception AccessException.MISSING_DBAS_CORE.
Für die Übermittlung eines Befundblattes für eine Koloskopie im Rahmen des Qualitätszertifikats wird das Recht DBAS.QZK benötigt.
Wird die Übermittlungsfunktion ohne das Recht aufgerufen, erhält man die Exception AccessException.MISSING_DBAS_QZK.
Mittels der Funktion getBerechtigungen() aus dem BASE-Service ist es möglich, die Rechte des Vertragspartners abzufragen.
Welches Recht für welche Funktion benötigt wird, ist zusätzlich den Funktionsbeschreibungen der Javadoc zu entnehmen (jeweils in den Vorbedingungen).

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

KVTs ermitteln |  | FDAS-Methode: getSVTs
Fachgebiete ermitteln |  | FDAS-Methode: getFachgebiete

### Online-/Offline-Status

Ob eine Verbindung für ein bestimmtes Service zum e-card-Serversystem besteht, sollte im Normalbetrieb NICHT abgefragt werden! Die Abfrage sollte nur dann durchgeführt werden um festzustellen, ab wann das Service wieder online ist, wenn zuvor Verbindungsprobleme aufgetreten sind.
Die empfohlene Frequenz für die Abfragen liegt in diesem Fall bei > 1 Minute.
Die Abfrage ist über eine REST Schnittstelle durchzuführen:
GET https://services.ecard.sozialversicherung.at/<service-name>/<versionsnummer>/status (Produktions-Instanz) bzw. GET https://services-a.ecard-test.sozialversicherung.at/<service-name>/<versionsnummer>/status (VPSWH-Instanz)
Ist der Server erreichbar, wird der Response HTTP 200 retourniert. Im Offline-Fall wird keine Response retourniert.

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

Bei den DBAS Funktionen unterscheidet man folgende Unterschiedliche Eingabevarianten zur Identifikation des Patienten:

- SV-Nummer und/oder e-card Cardtoken

Das e-card Cardtoken (SV-Signaturtoken mit e-card), sowie das o-card Cardtoken (SV-Signaturtoken mit o-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) Karte verwendet werden.
Das Stecken der Karte 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 DBAS wird nur das e-card Cardtoken unterstützt!
Für die Angabe innerhalb der Funktionen gilt:
SV-Nummer und/oder e-card Cardtoken
Darunter fallen folgende DBAS Funktionen:

- searchKonsultationData()
- searchDmpData()
- createDatenblattAllgemeinesProgramm()
- createDatenblattPapAbstrich()
- createDatenblattKoloskopie()
- createDatenblattQZKoloskopie()
- createDatenblattDmpDm2()

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

### Prinzipielle Erklärungen und Ablauf für die Verwendung des Dokumentationsblattannahme-Service:

Man unterscheidet zwischen folgenden verschiedenen Dokumentations-/Befundblättern:

- Allgemeines Befundblatt der Vorsorgeuntersuchung (VU)
- Dokumentationsblatt PAP-Abstrich
- Befundblatt Koloskopie
- Befundblatt Koloskopie im Rahmen des Qualitätszertifikats
- Dokumentationsbogen Therapie Aktiv DM2

Zum einfacheren Verständnis wird in dieser Dokumentation einheitlich der Begriff Datenblatt (verwendeter SS12-Syntax) verwendet, auch wenn es sich um ein Befundblatt, ein Dokumentationsblatt oder einen Dokumentationsbogen handelt.

#### Datenblatt-Gruppen:

Die einzelnen Datenblätter lassen sich zusätzlich noch in drei Gruppen unterteilen:
Datenblätter mit KSE-Abhängigkeit

Datenblatt | KSE-Abhängigkeit
Allgemeine Vorsorgeuntersuchung | Erfasste Konsultation(en) mit Behandlungsfall "VN" durch den Vertragspartner
PAP-Abstrich | Erfasste Konsultation(en) mit Behandlungsfall "VP" durch den Vertragspartner bzw. erfasste Konsultation(en) mit Behandlungsfall "VG" durch den Vertragspartner Hinweis: Bei jedem Krankenversicherungsträger ist für das PAP-Datenblatt eine Konsultation mit Behandlungsfall "VP" zulässig. Je nach Krankenversicherungsträger kann jedoch auch eine Konsultation mit Behandlungsfall "VG" erlaubt sein. Beim Abruf der Fachdaten wird dieser Umstand berücksichtig und alle zulässigen Konsultationen für den Patienten und den Vertragspartner retourniert. Beispiele (mit fiktiven Werten): Bsp. 1: Patient besitzt einen Anspruch beim KV-Träger 11 Der Träger erlaubt nur eine Datenblattübermittlung des PAP-Blattes, wenn eine Konsultation mit Behandlungsfall "VP" vorliegt. Eine Konsultation mit Behandlungsfall "VG" kann nicht verwendet werden. Bsp. 2: Patient besitzt einen Anspruch bei KV-Träger 19 Der Träger erlaubt eine Datenblattübermittlung des PAP-Blattes für Konsultationen mit Behandlungsfall "VP", als auch für Behandlungsfall "VG".
Koloskopie | Erfasste Konsultation(en) mit Behandlungsfall "VK" durch den Vertragspartner Hinweis: Bei einer Vorsorgeuntersuchung-Koloskopie muss der Parameter "Patientenzustimmung" zwingend angegeben werden. Bedeutung des Parameters: Der Patient muss sich bei der VU-Koloskopie entscheiden, ob er seine Zustimmung zur Übermittlung von Personenbezogenen Daten aus der Krankengeschichte zum Zweck der Qualitätsüberprüfung der durchgeführten Untersuchung an die Österreichische Gesellschaft für Gastroenterologie und Hepatologie (ÖGGH) zustimmt. Hierfür wird von der ÖGGH eine Zustimmungserklärung zur Verfügung gestellt (siehe hierzu auch die Homepage der ÖGGH www.oeggh.at bzw. die Seite www.vorsorgekoloskopie.at). Wird diese vom Patienten unterzeichnet, ist der Parameter Patientenzustimmung mit "Ja" anzugeben, anderenfalls mit "Nein". Dieser Parameter darf nicht automatisch gesetzt werden, sondern ist manuell durch den Vertragspartner in Abhängigkeit der Patientenentscheidung anzugeben.

Ein Vertragspartner kann nur solche Datenblätter übermitteln, zu denen er auch die jeweilige Konsultation erfassen kann.
Bsp.: Ein Facharzt für Chirurgie erfasst eine Konsultation mit dem Behandlungsfall "VK". Somit kann er auch das Datenblatt Koloskopie übermitteln. Der Vertragspartner kann jedoch keine Konsultation mit Behandlungsfall "VP" erfassen, hierfür würde er ein anderes Fachgebiet benötigen. Eine Übermittlung eines Datenblattes für den PAP-Abstrich ist daher nicht möglich (siehe hierzu Fachdaten - Konsultationen abfragen).
Weitere Informationen zur Erfassung von Konsultationen mittels des KSE-Service entnehmen Sie bitte der Package-Beschreibung des KSE-Service bzw. im KA-Bereich zusätzlich der beigefügten Beschreibung zu der "Enterprise Funktionalität".
Datenblätter mit bedingter KSE-Abhängigkeit

Datenblatt | bedingte KSE-Abhängigkeit
Koloskopie im Rahmen des Qualitätszertifikats | Erfasste Konsultation(en) mit Behandlungsfall "VK" durch den Vertragspartner Hinweis: Die Angabe des Parameters Patientenzustimmung ist im Falle einer Koloskopie im Rahmen des Qualitätszertifikats nicht zulässig, da die Dokumentation einer Koloskopie im Rahmen des Qualitätszertifikats generell nur dann zu erfassen ist, wenn eine unterschriebene Zustimmungserklärung des Patienten zur Übermittlung von Personenbezogenen Daten aus der Krankengeschichte zum Zweck der Qualitätsüberprüfung der durchgeführten Untersuchung an die Österreichische Gesellschaft für Gastroenterologie und Hepatologie (ÖGGH) vorliegt. Liegt keine Zustimmung vor ist keine Dokumentation über das e-card-System zu erfassen.

Ein Vertragspartner kann ein Datenblatt der Qualitätszertifikats-Koloskopie (QZ-Koloskopie) auch ohne passender "VK"-Konsultation erfassen. Es wird allerdings trotzdem geprüft, ob eine passende "VK"-Konsultation vorhanden ist. Ist dies der Fall wird die Fehlermeldung DbasException.MATCHING_KONSULTATION_FOUND retourniert. In diesem Fall muss entschieden werden, ob trotzdem eine QZ-Koloskopie übermittelt werden soll (mittels gesetztem Parameter "forcedQZ" gleich "true" in den Eingangsdaten) oder ein Umstieg auf das Datenblatt Koloskopie mit der gefundenen "VK"-Konsultation durchgeführt werden soll. Die Entscheidung bzgl. dem Setzen des Parameters "forcedQZ" kann bereits nach Abfrage der Konsultationsfachdaten erfolgen (siehe hierzu Fachdaten - Konsultationen abfragen).
Datenblätter mit DMP-Abhängigkeit

Datenblatt | DMP-Abhängigkeit
Therapie Aktiv DM2 | Betreuungsverhältnis zwischen Vertragspartner und Patient für das DM-Programm "Diabetes mellitus Typ 2" zum Zeitpunkt der Untersuchung (Untersuchungsdatum).

Hinweis: Für die Programme Demenz (DEM) und Postmyokardinfarkt (PMI) sind keine Datenblattübermittlungen möglich.
Das bedeutet: Ein Vertragspartner kann nur dann ein Datenblatt für das jeweilige Disease Management übermitteln, wenn der Vertragspartner ein DMP-Arzt für das jeweilige Programm ist und für den Zeitpunkt der Untersuchung (Untersuchungsdatum im jeweiligem Datenblatt, max. drei Jahre in die Vergangenheit) ein passendes Betreuungsverhältnis vorliegt (siehe hierzu Fachdaten - DMP-Daten abfragen).

#### Beispielhafte Abläufe zur Verwendung des DBAS:

Die folgenden Abläufe sollen vereinfacht darstellen, wie das DBAS verwendet werden kann und bieten einen Anhaltspunkt für eine mögliche Implementierung in die Vertragspartnersoftware.
Es werden dabei als Beispiel folgende Abläufe durchgeführt:
Ablauf 1: Ein Vertragspartner übermittelt ein Dokumentationsblatt mit KSE-Abhängigkeit
Ablauf 2: Ein Vertragspartner übermittelt ein Dokumentationsblatt mit DMP-Abhängigkeit
Bei Ablaufschritten vom Typ "Vertragspartner (Verwendung des DBAS)" können durch formal fehlerhafte Eingaben Fehler auftreten. Der Vertragspartner kann in diesem Fall die Eingangsdaten prüfen und die Anfrage nochmals über das DBAS durchführen.

#### Hinweis Druckaufbereitung

Das DBAS stellt ab DBAS SS12 Version 11 für folgende Datenbllätter eine Druckaufbereitung zur Verfügung:

- Allgemeine Vorsorgeuntersuchung
- Therapie Aktiv DM2

Für diese Datenblätter wird nach Übermittlung der Daten zusätzlich zur Quittung die Druckaufbereitung als PDF retourniert. Das PDF wird als MTOM Attachment retourniert. Für generelle Informationen hinsichtlich dem Attachmenthandling (SOAP-Attachment mittels MTOM) siehe Abschnitt "Attachments" in Overview .
Für alle weiteren Datenblätter innerhalb des DBAS wird keine Funktionalität zur Druckaufbereitung zur Verfügung gestellt. Eine eventuell gewünschte Aufbereitung (Ausdrucken der Datenblätter zur Aushändigung an den Patienten bzw. Archivierung beim Vertragspartner) muss von der Vertragspartnersoftware selbst vorgenommen werden. Als Unterstützung finden Sie hierzu für jeden Datenblatttyp ohne PDF-Druckaufbereitung durch das eCS eine Beispieldruckansicht im HTML-Format.
Wichtig:
Für Datenblätter mit Druckaufbereitung im eCS: Wird vom eCS eine Druckaufbereitung retourniert, ist dieses zu verwenden.
Für Datenblätter ohne Druckaufbereitung im eCS: Die mitgelieferten Druckansichten im HTML-Format für Datenblätter OHNE Druckaufbereitung innerhalb der Funktion sind nicht als Formatvorgabe zu betrachten, sondern dienen als Beispiel für die vorhandenen Datenfelder und Gruppierungsmöglichkeiten. Die Druckansicht der Vertragspartnersoftware muss nicht dieselbe Optik verwenden. Es muss jedoch garantiert werden, dass die fachlich relevanten medizinischen Felder/Daten in der Druckansicht wiederzufinden sind.

#### Hinweis Fehlermeldungen:

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

Fehlerursache | Nummer
Pflichtfeld | 1
Pflichtfeld | 2
Formatfehler (Bsp.: Nur numerische Zeichen erlaubt) | 3
Wertebereichfehler (Bsp.: Wertebereich 0-99 oder ungültige Konstante) | 4
Zusätzliche Bedingungen (Bsp.: Parameter darf nicht befüllt werden, wenn Patient ein gewisses Alter nicht erreicht hat) | 5 6 7 8
Verknüpfte Bedingungen (Bsp.: Es muss entweder der eine oder der andere Parameter angegeben werden) | 0

#### Hinweis Array-Behandlung:

Wenn Eingabefelder Arrays sind, wird stets geprüft ob diese

- keine Werte enthalten, die 'null' sind und
- keine zwei identischen Werte enthalten

Sind diese Bedingungen verletzt, wird ein Wert-Fehler ausgegeben (Endziffer 4, Fehlertext: "Der Wert in 'Datenfeld' ist nicht zulässig."). Die Fehlermeldung für fehlende Pflichtfelder (Endziffer 1) kommt in diesem Fall nur, wenn das Array insgesamt 'null' ist.

## Funktionalität des DBAS

Die Integration des DBAS in die Vertragspartnersoftware ist optional. Wird das DBAS integriert, müssen alle DBAS-Funktionalitäten implementiert werden:
Fachdaten abfragen:

- Abfrage der Konsultationen, an die das jeweilige Datenblatt gebunden werden kann
- Abfrage der DMP-Einschreibung für das jeweilige Datenblatt

Datenblatt übermitteln:

- KSE-abhängige Datenblätter

- Übermittlung des Datenblattes "Allgemeines Befundblatt der VU"
- Übermittlung des Datenblattes "Dokumentationsblatt PAP-Abstrich"
- Übermittlung des Datenblattes "Befundblatt Koloskopie"

- bedingt KSE-abhängige Datenblätter

- Übermittlung des Datenblattes "Befundblatt QZ-Koloskopie"

- DMP-abhängige Datenblätter

- Übermittlung des Datenblattes "Dokumentationsbogen Therapie Aktiv DM2"

Empfangsbestätigungen abfragen:

- Suche und Abfrage der Empfangsbestätigungen

Wichtiger Hinweis bzgl. der unterstützten Datenblattversionen:
Eine SS12-Version des DBAS unterstützt jeweils definierte Datenblattversionen. Kommt es bei einem Releasewechsel zu einer neuen Datenblattversion, ist die vorherige Datenblattversion nur noch über die alte SS12 übertragbar und die neue Datenblattversion nur noch über die neue SS12.
Fiktives Beispiel: Datenblatt XX kann in der SS12-Version 2.0 in der Version 1.0 übertragen werden. In Folge einer neuen Release mit DBAS-Inhalten wird die Versionsnummer für das Datenblatt XX um 1 erhöht und ebenso die SS12-Version. Bei der neuen SS12-Version 3.0 kann das Datenblatt XX nur in der Version 2.0 übertragen werden. Alte Datenblätter in der Version 1.0 müssen mit der alten SS12-Version 2.0 übertragen werden.
Mit der SS12-Version 12.0 des DBAS sind folgende Datenblattversionen übermittelbar:

Datenblatt | Datenblattversion
Allgemeines Befundblatt der VU | 4.0
Dokumentationsblatt PAP-Abstrich | 3.0
Befundblatt Koloskopie | 4.0
Befundblatt QZ-Koloskopie (entspricht der Version von Befundblatt Koloskopie) | 4.0
Dokumentationsbogen Therapie Aktiv DM2 | v05

WichtigerHinweis bzgl. der (ehemaligen) Datenblätter MAM und PMI:
In der Schnittstellenversion 12 sind die Funktionen zur Übermittlung der Datenblätter MAM und PMI nicht mehr vorhanden. Ebenso wurden die Konstanten der beiden Datenblätter auf der neuen Schnittstellenversion entfernt.
Auf der alten SS12 Version (Version 11) sind die Funktionen zwar prinizipiell noch vorhanden, können jedoch nicht mehr aufgerufen werden.
Ein Aufruf der create-Funktionen für MAM und PMI wird mit der Fehlerkonstante ServiceException.INTERNAL_ERROR, mit dem Fehlermeldungscode CL-A0050 und den Fehlermeldungstext "Die aufgerufene Funktion steht nicht mehr zur Verfügung.", beendet.
Ein Aufruf von Funktionen mit Eingabemöglichkeit des Datenblatttyps erzeugt auf der Schnittstellenversion 11 bei Verwendung der Konstanten MAM und PMI den Fehlerzustand: DbasInvalidParameterException.DATENBLATT_TYP_INVALID mit dem Fehlermeldungscode CL-1290024 und den Fehlermeldungstext "Der Wert in Datenblatttyp ist nicht zulässig."

### Fachdaten abfragen

Wie bereits in Kapitel Prinzipielle Erklärungen und Ablauf für die Verwendung des Dokumentationsblattannahme-Service erwähnt, besitzen die verschiedenen Datenblatttypen Abhängigkeiten (zu einer im Konsultationssystem erfassten Konsultation oder zu einer DMP-Einschreibung bzw. eine bedingte Abhängigkeit wie im Falle der QZ-Koloskopie).
Nur wenn die bestimmte Abhängigkeit erfüllt ist, kann auch tatsächlich das entsprechende Datenblatt übermittelt werden.
Mittels der Fachdatenabfragen "Konsultationen abfragen" bzw. "DMP-Daten abfragen" besteht die Möglichkeit zu prüfen, ob die Abhängigkeit (Vorbedingung) für den bestimmten Patienten und das Datenblatt erfüllt ist.

#### Fachdaten - Konsultationen abfragen:

Die Funktion searchKonsultationData() ermittelt in Abhängigkeit des gewählten Datenblatttyps alle Konsultationen, die für eine Zuordnung zu dem entsprechenden Datenblatt zur Verfügung stehen.
Hinweis: Es werden nur Konsultationen gefunden die mit derselben TätigkeitsbereichID (beim Dialogaufbau angegeben) erstellt wurden, die im aktuell verwendeten Dialog gesetzt wurde.
Bsp.: Datenblatttyp = KOL für Datenblatt Koloskopie. Es werden alle Konsultationen mit dem Behandlungsfall "VK" ermittelt, die durch den ausführenden Vertragspartner für den Patienten erstellt wurden.
Bsp.: Datenblatttyp = PAP für Datenblatt PAP-Abstrich. Es werden alle Konsultationen mit dem Behandlungsfall "VP" bzw. alle Konsultationen mit dem Behandlungsfall "VG", bei denen der eingetragene verrechnungszuständige Krankenversicherungsträger den Behandlungsfall "VG" für das Datenblatt PAP-Abstrich als gültig angegeben hat, ermittelt, die durch den ausführenden Vertragspartner für den Patienten erstellt wurden.
Bsp.: Datenblatttyp = QZK für Datenblatt QZ-Koloskopie. Es werden alle Konsultationen mit dem Behandlungsfall "VK" ermittelt, die durch den ausführenden Vertragspartner für den Patienten erstellt wurden. Wird keine passende Konsultation gefunden, so kann das Datenblatt QZK ohne setzen des Parameters "forcedQZ" übermittelt werden. Wird eine Konsultation retourniert, muss der Vertragspartner entscheiden, ob ein Datenblatt QZK oder ein Datenblatt KOL übermittelt werden soll. In Abhängigkeit der getroffenen Entscheidung ist die eine oder die andere Übermittlungsfunktion zu verwenden.
Für Datenblätter mit KSE-Abhängigkeit gilt: Ein Datenblatt kann nur übermittelt werden, wenn eine passende Konsultation gefunden wird.
Für Datenblätter mit bedingter KSE-Abhängigkeit gilt: Ein Blatt kann auch dann übermittelt werden, wenn keine passende Konsultation gefunden wird.

##### Szenario 5 - Konsultationen abfragen:

#### Fachdaten - DMP-Daten abfragen:

Die Funktion searchDmpData() ermittelt, ob es zwischen dem Vertragspartner und dem Patienten für das bestimmte Disease Management Programm gültige Betreuungsverhältnisse gibt bzw. gegeben hat. D.h.: es werden alle Einschreibungen (Betreuungsverhältnisse) zwischen dem Vertragspartner und dem Patienten zu dem ausgewählten DM-Programm innerhalb der letzten drei Jahre berücksichtigt. Es muss hierfür kein aktuell gültiges Betreuungsverhältnis vorliegen.
Wird ein Rückgabeobjekt geliefert, wurde der Patient durch den Vertragspartner zumindest einmal für das entsprechende Disease Management Programm eingeschrieben und der Vertragspartner kann das Datenblatt dafür übermitteln, sofern das Untersuchungsdatum im Zeitraum der (gewählten) Betreuung liegt (siehe auch Übermittlung von Datenblättern mit DMP-Abhängigkeit).
Hinweis:
Das zurückgelieferte Objekt enthält alle gefundenen Betreuungsverhältnisse die innerhalb der letzten drei Jahre gültig waren. Jedes gefundene Bereuungsverhältnis wird als Betreuungsobjekt mit folgenden Daten im DmpData-Objekt zurückgeliefert:

BvId | eindeutige ID der Betreuung, muss im Datenblatt angegeben werden
Ausschreibedatum | Datum der Ausschreibung aus dem Programm, nur versorgt wenn es sich um eine bereits beendete Betreuung handelt
Antragsdatum | Datum des Betreuungsantrages (ist meistens gleich dem Datum der Einschreibung), Datum des frühesten Untersuchungsdatums
Fachgebiet-Code | Fachgebiet der Betreuung
Svt-Code | Krankenversicherungsträger der Betreuung

Wird kein Rückgabeobjekt geliefert, ist dem e-card-System keine Einschreibung des Patienten zu dem Vertragspartner und dem Programm bekannt bzw. liegt die Ausschreibung aus dem Programm länger als drei Jahre in der Vergangenheit. In diesem Fall wird eine entsprechende Exception geliefert und das Datenblatt kann nicht übermittelt werden.
Hinweis bezüglich DMP-Einschreibungen:
Die Entscheidung der DMP-Administration über Annahme oder Ablehnung der Einschreibung kann längere Zeit in Anspruch nehmen, da vor der endgültigen Aufnahme des Patienten in das DM-Programm ein Briefwechsel zwischen Patient und DMP-Administration stattfindet, welcher mit der Unterschrift des Patienten (Zustimmung zur Aufnahme) endet. Erst nach dieser Bestätigung erfolgt die Rückmeldung der DMP-Administration an das e-card-System über die Aufnahme (gemeldete Einschreibung). D.h. erst ab diesem Zeitpunkt ist die Einschreibung im System bekannt. Die gemeldete Einschreibung enthält dabei das Antragsdatum (von der DMP-Administration gemeldet). Das bedeutet, die Betreuung ist zwar unter Umständen erst ab einem gewissen Zeitraum im System bekannt, das Datum des ersten möglichen Untersuchungsdatums liegt jedoch unter Umständen davor.

##### Szenario 5 - DMP-Daten abfragen:

### Datenblatt übermitteln

Es gibt folgende Funktionen zur Übermittlung:

- mit KSE-Abhängigkeit:

- createDatenblattAllgemeinesProgramm()
- createDatenblattPapAbstrich()
- createDatenblattKoloskopie()

- mit bedingter KSE-Abhängigkeit:

- createDatenblattQZKoloskopie()

- mit DMP-Abhängigkeit:

- createDatenblattDmpDm2()

Mit diesen Funktionen hat der Vertragspartner die Möglichkeit das befüllte Datenblatt an das e-card-System zu übermitteln. Dabei wird das Datenblatt auf Vollständigkeit geprüft, verschlüsselt und an die jeweils zuständige Stelle weitergeleitet.
Konnte die Funktion erfolgreich durchgeführt werden, wird in Abhängigkeit des übermittelten Datenblattes wie folgt reagiert:

- Datenblatt "AMP", "DM2": Es wird in der Response das Objekt CreateDatenblattErgebnis retourniert. Dieses beinhaltet einerseits die Quittung, sowie die Druckaufbereitung als MTOM Attachment.
- Datenblatt "KOL", "PAP": Es wird in der Response die Quittung retourniert.

Die retournierten Daten sind von der Vertragspartnersoftware entsprechend zu verwalten.
Wichtiger Hinweis zur Angabe des manuellen Geburtsdatums in den Datenblättern:
Wird beim Abruf der jeweiligen Fachdaten kein Geburtsdatum des Patienten retourniert, ist aufgrund der Prüfabhängigkeiten zu diesem, das Geburtsdatum manuell vom Vertragspartner zu erfassen. D.h. das Feld Geburtsdatum in den jeweiligen Datenblättern ist ein bedingtes Feld, das angegeben werden muss, wenn keines vom e-card-System zurückgeliefert wird und ansonsten leer bleiben kann.
Ist kein Geburtsdatum im e-card-System bekannt und wird auch keines manuell angegeben, wird eine entsprechende Fehlermeldung ausgegeben.
Zur Vereinfachung ist es auch möglich das Geburtsdatum über die Vertragspartnersoftware-Schnittstelle immer anzugeben (z.B. direkt aus der internen Patientenverwaltung). Es ist jedoch darauf zu achten, dass im Falle einer Rückmeldung eines Geburtsdatums in den Fachdaten, das rückgemeldet und das über die Vertragspartnersoftware-Schnittstelle im Datenblattobjekt versorge Geburtsdatum ident sein müssen. Ist dies nicht der Fall wird eine entsprechende Fehlermeldung zurückgegeben.

#### Datenblatt mit KSE-Abhängigkeit übermitteln:

Um ein Datenblatt für eine Vorsorgeuntersuchung zu übermitteln, muss eine passende Konsultation dazu existieren. Für die Abfrage der Konsultationen siehe Fachdaten - Konsultationen abfragen.
Nur wenn eine Konsultation vorhanden ist, kann das entsprechende Datenblatt übermittelt werden. Wird mehr als eine passende Konsultation gefunden, muss der Vertragspartner eine Konsultation auswählen, an die das Datenblatt gebunden werden soll.
Die ID der ausgewählten Konsultation des Patienten ist im jeweiligen Datenblatt-Objekt anzugeben.
Wichtig:
Siehe Wichtiger Hinweis bzgl. der unterstützten Datenblattversionen für die unterstützten Datenblattversionen bei dieser SS12-Version des DBAS.
Alte Datenblattversionen können unter Umständen nur mit der vorherigen SS12-Version übertragen werden.
Siehe Wichtiger Hinweis zur Angabe des manuellen Geburtsdatums in den Datenblättern für die Vorgehensweise, wenn für den Patienten kein Geburtsdatum retourniert wird.

##### Szenario 5 - Übermittlung eines Datenblattes mit KSE-Abhängigkeit ohne Retournierung der Druckaufbereitung:

##### Szenario 5 - Übermittlung des AMP Datenblattes (mit KSE-Abhängigkeit und Retournierung der Druckaufbereitung):

Optional für den Vertragspartnersoftware-Hersteller:
Zusätzlich zu bereits bestehenden Abhängigkeiten der Attribute in den Datenblatt-Objekten (Muss-Felder und bedingte Muss-Felder) sind einige Attribute an die Parameter der ausgewählten Konsultation, der Patientendaten und der Ordinationsdaten des Vertragspartners gekoppelt.
Es gelten folgende Abhängigkeiten:

- Alters des Patienten zum Zeitpunkt der Behandlung

- Behandlungsdatum aus Objekt KonsultationInfo
- Geburtsdatum aus Objekt PatientInfo

- Geschlecht des Patienten

- Geschlechtscode aus Objekt PatientInfo

- Bundesland in der die Ordination des Vertragspartners liegt

- Bundeslandcode aus Objekt Ordination (verwendet beim Dialogaufbau)

Diese Faktoren können bewirken, dass ein Eingabefeld:

- befüllt werden muss (Muss-Feld),
- befüllt werden kann (Kann-Feld),
- nicht befüllt werden darf.

Die besonderen Bedingungen zur Befüllung eines Feldes sind in den jeweiligen Objekt-Definitionen in der Javadoc zu finden. Mit Hilfe dieser Bedingungen kann die Vertragspartnersoftware die benötigten Eingabeparameter für die Eingabe durch den Vertragspartner aufbereiten.

#### Datenblatt mit bedingter KSE-Abhängigkeit übermitteln:

Zur Übermittlung eines Datenblattes mit bedingter KSE-Abhängigkeit ist keine passende Konsultation notwendig. Existiert jedoch eine passende Konsultation muss der Vertragspartner entscheiden, ob er ein Datenblatt ohne oder mit Konsultationsbindung übermitteln will.
Momentan fällt in die Kategorie der Datenblätter mit bedingter KSE-Abhängigkeit nur das Datenblatt der QZ-Koloskopie. Wird bei der Fachdatenabfrage oder direkt bei der Übermittlung eine mögliche Konsultation gefunden, kann in weiterer Folge zwischen den Funktionen zur Übermittlung des Datenblattes "Koloskopie" oder "QZ-Koloskopie" gewählt werden.
Das Datenblatt Koloskopie und das Datenblatt QZ-Koloskopie sind von den fachlichen Parametern ident. Um einen Umstieg zwischen den beiden Übermittlungsfunktionen einfach zu halten, arbeiten beide Funktionen mit dem Objekt datenblattKoloskopie.
Dabei zu beachten:
Der Parameter KonsultationsId ist im Objekt datanblattKoloskopie ein Muss-Feld und somit auch im Falle einer QZK zu versorgen. Da die QZK keine Konsultationsbindung besitzt, wird dieser Wert bei der weiteren Verarbeitung ignoriert. Es wird empfohlen in diesem Fall die KonsultationsId mit dem Wert "0" zu übermitteln.
Der Parameter Patientenzustimmung ist bei Erfassung einer VU-Koloskopie mittels createDatenblattKoloskopie() ein Muss-Feld, darf jedoch bei Erfassung einer QZ-Koloskopie mittels creatDatenblattQZKoloskopie() nicht angegeben werden. Wird der Parameter trotzdem angegeben, wird die Fehlermeldung DbasInvalidParameterException.KOL_PATIENTENZUSTIMMUNG_FORBIDDEN (CL-1205515 - "Der Wert in Patientenzustimmung ist ungültig. (Bei Erfassung einer Qualitätszertifikatskoloskopie ist die Angabe nicht erlaubt.)") retourniert.
Aufgetretene fachliche Fehler der QZ-Koloskopie sind aufgrund der identen Prüfungen der fachlichen Parameter vom Typ "KOL", z.B.: DbasInvalidParameterException.KOL_SEDIERUNG_ANALGESIE_REQUIRED.

##### Szenario 5 - Übermittlung eines Datenblattes mit bedingter KSE-Abhängigkeit:

#### Datenblatt mit DMP-Abhängigkeit übermitteln:

Um ein Datenblatt für eine DMP-Untersuchung zu übermitteln, muss der Patient beim Vertragspartner für das entsprechende DMP eingeschrieben sein (bzw. gewesen sein) und diese Einschreibung auch im e-card-System bekannt sein.
Mittels der Funktion searchDmpData() sind die möglichen Betreuungen für das Datenblatt abzufragen.
Das Untersuchungsdatum im Datenblatt muss zwischen den Datumswerten "Antragsdatum" und "Ausschreibedatum" eines der zurückgelieferten Betreuungen, sowie maximal drei Jahre in der Vergangenheit liegen. Die BvId (eindeutige ID der Betreuung) bei der das Untersuchungsdatum innerhalb des Betreuungszeitraumes liegt, ist im Datenblatt anzugeben.
Es muss nicht zwingend zum Tag der Übermittlung eine aufrechte Einschreibung bestehen.
Wichtig:
Siehe Wichtiger Hinweis bzgl. der unterstützten Datenblattversionen für die unterstützten Datenblattversionen bei dieser SS12-Version des DBAS.
Alte Datenblattversionen können unter Umständen nur mit der vorherigen SS12-Version übertragen werden.
Siehe Wichtiger Hinweis zur Angabe des manuellen Geburtsdatums in den Datenblättern für die Vorgehensweise, wenn für den Patienten kein Geburtsdatum retourniert wird.

##### Szenario 5 - Übermittlung des DM2 Datenblattes (mit DMP-Abhängigkeit und mit Druckaufbereitung):

Optional für den Vertragspartnersoftware-Hersteller:
Zusätzlich zu bereits bestehenden Abhängigkeiten der Attribute in den Datenblatt-Objekten (Muss-Felder und bedingte Muss-Felder) sind einige Attribute an die Parameter der Patientendaten gekoppelt.
Es gelten folgende Abhängigkeiten

- Geschlecht des Patienten

- Geschlechtscode aus Objekt PatientInfo

Diese Faktoren können bewirken, dass ein Eingabefeld:

- befüllt werden muss (Muss-Feld),
- nicht befüllt werden darf.

Die besonderen Bedingungen sind in den jeweiligen Objekt-Definitionen in der Javadoc zu finden.
Mit Hilfe dieser Bedingungen kann die Vertragspartnersoftware die benötigten Eingabeparameter für die Eingabe durch den Vertragspartner aufbereiten.

### Empfangsbestätigungen abfragen

Mit der Funktion searchQuittungen() hat der Vertragspartner die Möglichkeit, seine erhaltenen Empfangsbestätigungen mit Hilfe von Selektionskriterien für den Zeitraum der letzten sechs Monate abzufragen.