# Package at.chipkarte.client.dmp.soap

Interface und Klassen des Disease Management Programm (DMP).

See: Description

- Interface Summary
  Interface | Description
  --- | ---
  IDmpService | Dieses Service stellt die Funktionalitäten des Disease Management Programm (DMP) zur Verfügung.

- Class Summary
  Class | Description
  --- | ---
  Anfrage | Enthält die Daten zur Anfrage sowie den Status der Anfrage.
  AusschreibeErgebnis | Enthält die Daten zu einer erfolgreich durchgeführten DMP Ausschreibeanfrage.
  AusschreibeParameter | Enthält die Parameter zu einer DMP Ausschreibeanfrage.
  BetreuterPatient | Enthält die Daten zu einem betreuten Patienten.
  Betreuungsverhaeltnis | Enthält die Beziehung zwischen Vertragspartner und DMP Patient sowie den Status dieser Beziehung.
  EingabeErgebnis | Enthält die Daten zu einer erfolgreich durchgeführten DMP-Eingabe.
  EingabeParameter | Enthält die Parameter zu einer DMP-Eingabe.
  PatientenInformation | Enthält administrative oder medizinische Patienteninformationen zu einem Patienten.
  SvPerson | Enthält die Daten zu einer SV-Person.
  Textmeldung | Enthält Meldungen zu einem Patienten.
  Zustelladresse | Enthält die Daten der Zustelladresse eines DMP-Patienten.

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

Interface und Klassen des Disease Management Programm (DMP). Enthält den SOAP-Endpoint `IDmpService` sowie die dazu notwendigen Klassen.
Inhalt der DMP package-Beschreibung:

- Allgemein

- Rechte
- Dynamische Ermittlung von Parameterwerten des e-card-Regelwerks
- Online-/Offline-Status
- SV-Nummer vs. e-card CardToken
- Abläufe des DMP-Service
- Informationen zur Abrechnung von DMP-Diensten

- Funktionalität des DMP-Service

- DMP-Anfrage - Patient einschreiben
- DMP-Anfrage - Patient ausschreiben
- DMP-Anfragen nachverfolgen
- Patienteninformation abfragen
- DMP-Patient abfragen
- DMP betreute Patienten abfragen
- DMP-Betreuungsverhältnisse eines Patienten abfragen

# Allgemein

Patienten mit speziellen Krankheitsbildern können von Vertragspartnern (VP) in sogenannte Disease Management Programme (DMP) eingeschrieben werden.

## Rechte

Für die Funktionen des DMP-Service benötigt der Vertragspartner für die Durchführung das Recht DMP.CORE (Ausnahme: Vertragspartnerunabhängige Funktionen zur Parameterwertermittlung).
Wird eine Funktion, welche dieses Recht benötigt, ohne das entsprechende Recht aufgerufen, erhält man die Exception AccessException.MISSING_DMP_CORE.
Mittels der Funktion getBerechtigungen() aus dem BASE-Service ist es möglich, die Rechte des Vertragspartners abzufragen.

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

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

Krankenversicherungsträger ermitteln | - | FDAS-Methode: getSVTs()
Fachgebiete ermitteln | - | FDAS-Methode: getFachgebiete()
DM-Programme ermitteln | - | DMP-Methode: getDMPs()

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

Bei den DMP Funktionen mit Kartenunterstützung 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) 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 DMP 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 DMP Funktionen:

- doEingabe()
- doAusschreibung()
- searchBetreuungsverhaeltnisseForPatient()

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.

## Abläufe des DMP-Service

Die folgenden Abläufe sollen vereinfacht darstellen wie, das DMP-Service verwendet werden kann und bieten einen Anhaltspunkt für die mögliche Implementierung in die Vertragspartnersoftware.
Legende für die Abläufe:

### Ablauf 1 - Patient ist aktuell nicht bei dem VP für ein DMP eingeschrieben

Dieser Ablauf befasst sich mit der Aufnahme eines Patienten in ein DM-Programm.

### Ablauf 2 - Patient ist aktuell bei dem VP für ein DMP eingeschrieben

Dieser Ablauf befasst sich mit einem Patient, der bereits vom Vertragspartner in einem DM-Programm betreut wird / wurde.

### Ablauf 3 - Verarbeitung einer gestellten Anfrage

Dieser Ablauf befasst sich mit der Verarbeitung einer Anfrage durch die DMP-Administration. Es wird jeweils auf dem Schritt "Daten werden an die DMP-Administration geschickt" der Abläufe 1 und 2 aufgesetzt.

## Informationen zur Abrechnung von DMP-Diensten

Die Abrechnung erfolgt viermal jährlich mit der „normalen“ Quartalsabrechnung des Arztes. Pro Patient und DM-Programm kann österreichweit trägerübergreifend nur einmal pro Quartal die Position DMP abgerechnet werden.
Die Positionsnummern für die DMP-Betreuung sind in jedem Bundesland unterschiedlich definiert und werden gegebenenfalls per Newsletter bekannt gegeben bzw. sind diese bei den jeweiligen Trägern zu erfragen.
Ein vollständig ausgefüllter und eingesendeter Dokumentationsbogen ist Voraussetzung für die Honorierung der vier Quartale.

# Funktionalität des DMP-Service

Die Funktionen des Disease Management Programm Service sind nur im Onlinefall verfügbar. Voraussetzung für die Verwendung dieser Funktionen ist ein aktiver Onlinedialog.
Die Integration von DMP in die Vertragspartnersoftware ist optional. Wird DMP integriert, müssen alle DMP-Funktionalitäten implementiert werden:

- DMP-Anfrage - Patient einschreiben
- DMP-Anfrage - Patient ausschreiben
- DMP-Anfragen nachverfolgen
- Patienteninformation abfragen
- DMP-Patient abfragen
- DMP betreute Patienten abfragen
- DMP-Betreuungsverhältnisse eines Patienten abfragen

Hinweis Betreuungsstatus:
Das DMP-Service stellt verschiedene Funktionen zur Kommunikation mit der DMP-Administration zur Verfügung, dies ist allerdings nicht der einzige Kommunikationsweg. Patienten haben z.B. die Möglichkeit, sich über eine direkte Kontaktaufnahme aus dem DM-Programm ausschreiben zu lassen. Des Weiteren hat die DMP-Administration die Möglichkeit Betreuungsverhältnisse zu beenden, wenn fehlende Daten durch den Vertragspartner nicht rechtzeitig eingeschickt werden. Wird ein Arztwechsel mit Zustimmung des Patienten erfolgreich durchgeführt, wird zwischen Patient und neuem Arzt durch die DMP-Administration ein Betreuungsverhältnis eingerichtet. Das Betreuungsverhältnis zum vorhergehenden Arzt wird beendet, wobei dieser Arzt von der DMP-Administration keine Benachrichtigung darüber erhält.
Aus diesen Gründen ist es wichtig, bei einer Speicherung von Informationen über Betreuungsverhältnisse in der Vertragspartnersoftware auf eine regelmäßige Aktualisierung der Daten zu achten, um nicht mit einem veralteten Datenbestand zu arbeiten. Bei Änderungen des Status des Betreuungsverhältnisses muss der Vertragspartner von der Vertragspartnersoftware eine Information über die Statusänderung erhalten.

## DMP-Anfrage - Patient einschreiben

Mit der Funktion doEingabe() hat der VP die Möglichkeit einen Patienten für das DMP einzuschreiben. Dazu müssen sowohl die Patientendaten (DMP-Anspruchsdaten sowie, falls notwendig eine Zustelladresse - notwendig wenn die Zustelladresse von der Meldeadresse abweichen sollte) als auch die DMP-Daten (DMPCode, Eingabeart) angegeben werden.
Der VP hat weiters die Möglichkeit den Leistungserbringer für das DMP-Backend genauer zu spezifizieren (vor allem relevant wenn mehrere Ärzte unter einer Vertragspartnernummer Patienten betreuen, da die Einschreibung selbst auf die Vertragspartnernummer des Vertagspartners gebunden wird).
Hinweis: Der angegebene Leistungserbringer wird mit einer Anfrage an das DMP-Backend übermittelt, nicht jedoch im e-card-System als Teil für Beauskunftungen gespeichert! D.h. diese Information steht wie z.B. auch die Zustelladresse oder die Telefonnummer nach Übermittlung der Anfrage nicht mehr zur Abfragen zur Verfügung.
Mittels Eingabeart wird angegeben, um welche Art der Einschreibung es sich handelt. Es sind aktuell folgende Eingabearten möglich:

- Ersteinschreibung (E)
  Bedingung: Der Patient ist aktuell nicht eingeschrieben und war auch noch nie in dem angegebenen DM-Programm eingeschrieben.
- Arztwechsel (A)
  Bedingung: Der Patient ist aktuell bei einem anderen Vertragspartner für das DM-Programm eingeschrieben.
- Wiedereinschreibung (W)
  Bedingung: Der Patient ist aktuell nicht eingeschrieben, war aber bereits mindestens einmal im angegebenen DM-Programm eingeschrieben.

Pro DM-Programm kann ein Patient nur einen aktuell zuständigen DMP-Arzt haben.
Bei erfolgreichem Einschreibeantrag wird dieser als Anfrage an die DMP-Administration weitergeleitet, welche über die endgültige Einschreibung des Patienten entscheidet.
Hinweise:
Die Auswahlmöglichkeiten für Fachgebiet und KVT, sowie DMPCode müssen mit den jeweiligen Funktionen ermittelt werden (siehe Dynamische Ermittlung von Parameterwerten des e-card-Regelwerks).
Wird die Fehlermeldung DmpException.NO_SVT_PROVIDED_EXCEPTION zurückgeliefert, muss dieselbe Funktion mit einem KVT, der in der Fehlermeldung mitgeliefert wird, nochmals aufgerufen werden.

##### Szenario 5 - DMP-Anfrage - Patient einschreiben:

## DMP-Anfrage - Patient ausschreiben

Mit der Funktion doAusschreibung() hat der VP die Möglichkeit einen Patienten aus einem DMP auszuschreiben. Dazu muss ein bestehendes Betreuungsverhältnis zwischen dem Vertragspartner und dem Patienten (angegeben mittels SV-Nummer und/oder e-card Cardtoken) in dem angegebenen Programm bestehen.
Bei erfolgreichem Ausschreibeantrag wird dieser als Anfrage an die DMP-Administration weitergeleitet, welche über die endgültige Ausschreibung des Patienten entscheidet.
Hinweis:
Die Auswahlmöglichkeit für den DMPCode muss mit der Abfragefunktion der DMP-Codes ermittelt werden (siehe Dynamische Ermittlung von Parameterwerten des e-card-Regelwerks).

##### Szenario 5 - DMP-Anfrage - Patient ausschreiben:

## DMP-Anfragen nachverfolgen
Der Vertragspartner kann mit der Funktion searchAnfragen() den Status der von ihm ausgestellten DMP-Anfragen (Ein- und Ausschreibungen) kontrollieren.
Mittels der Selektionskriterien der Funktion kann unter anderem angegeben werden ob alle Anfrage oder nur Ein- bzw. Ausschreibeanfragen gesucht werden sollen.
Wurde die Anfrage weder positiv abgeschlossen noch abgelehnt, verbleibt die Anfrage im Status "in Bearbeitung".
Hinweis zur Zeitdauer einer Bearbeitung:
Die Entscheidung der DMP-Administration über Annahme oder Ablehnung einer Einschreibung kann längere Zeit in Anspruch nehmen, da vor der endgültigen Aufnahme des Patienten in das DM-Programm ein Briefwechsel zwischen dem Patient und der 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 (eCS) über die Aufnahme.

## Patienteninformation abfragen

Der Vertragspartner kann gespeicherte Informationen über einen DMP-Patienten abfragen.
Man unterscheidet dabei zwischen:

- administrative Patientendaten - Funktion getAdminPatientenInformationen()
- medizinische Patientendaten - Funktion getMedPatientenInformationen()

## DMP-Patient abfragen

Mit der Funktion isDMPPatient() kann ermittelt werden, ob aktuell eine bestehende Einschreibung zwischen dem Vertragspartner und dem Patient vorliegt. Als Ergebnis wird ein Boolean-Wert retourniert. Bei "true" besteht mindestens eine aktuell gültige Einschreibung zu einem DM-Programm zwischen dem Vertragspartner und dem Patient. Bei "false" existiert aktuell keine Einschreibung zwischen Vertragspartner und Patient. Die Abfrage ist unabhängig vom DM-Programm. D.h. bei Returnwert "true" können unter Umständen mehrere Einschreibungen zu unterschiedlichen Programmen vorliegen.
Es wird empfohlen diese Funktion bei jedem Patientenkontakt durchzuführen (z.B. bei der Durchführung einer Konsultation) um festzustellen, ob prinzipiell eine Einschreibung vorliegt.
Retourniert die Funktion "true" wird empfohlen, zur Ermittlung in welchem Programm bzw. in welchen Programmen eine Einschreibung besteht im Anschluss die Funktion "DMP-Betreuungsverhältnisse eines Patienten abfragen" aufzurufen.

## DMP betreute Patienten abfragen

Die Funktion getBetreutePatienten() ermöglicht die Abfrage aller durch den Vertragspartner betreuten Patienten. Je nach Selektionskriterien werden nur die aktuell betreuten oder die nicht mehr betreuten Patienten rückgeliefert (oder beide).
Anhand der gesetzten Datumswerte in EinschreibungSeit und AusschreibungSeit kann zwischen einer aktuell bestehenden Ein- und Ausschreibung unterschieden werden.
Wurde zu dem Betreuungsverhältnis des Patienten ein Dokumentationsbogen mittels des DBAS (Dokumentationsblattannahme-Service) übermittelt, wird zusätzlich das Untersuchungsdatum dieses Dokumentationsbogens retourniert.

## DMP-Betreuungsverhältnisse eines Patienten abfragen

Die Funktion searchBetreuungsverhaeltnisseForPatient() dient der Ermittlung der Daten zu den Betreuungen die zwischen dem Vertragspartner und dem Patient bestehen bzw. bestanden haben. In Abhängigkeit des Eingangsparameters DmpCode wird entweder nur das Betreuungsverhältnis des angegebenen Programmes oder alle vorhandenen Betreuungsverhältnisse (bei DmpCode = leer) ermittelt.
Hinweise:

- Es werden immer nur die Betreuungsverhältnisse des Patienten angezeigt, die zwischen dem Patient und dem abfragenden Vertragspartner bestehen.
- Es wird immer der aktuelle Status der Betreuung zurückgeliefert. D.h. es wird auch dann ein Betreuungsverhältnis retourniert, wenn aktuell keine gültige Einschreibung mehr vorliegt.
- Wurde zu dem Betreuungsverhältnis des Patienten ein Dokumentationsbogen mittels des DBAS übermittelt, wird zusätzlich das Untersuchungsdatum dieses Dokumentationsbogens retourniert.

Es wird empfohlen diese Funktion dann aufzurufen, wenn ein Aufruf der Funktion "DMP-Patient abfragen" ergeben hat, dass der Patient ein DMP-Patient des Vertragspartners ist und weitere Informationen notwendig sind.
Zur Feststellung der aktuell gültigen Betreuungen ist nach BetreuungsStatus gleich "Ein" (Eingeschrieben) innerhalb der retournierten Betreuungsverhältnisse zu selektieren.

##### Szenario 5 - DMP-Betreuungsverhältnisse eines Patienten abfragen: