Elektronische Gesundheitskarte und Telematikinfrastruktur
Feature:
Elektronische Verordnung
Häuslicher Krankenpflege (HKP)
| Version | 2.0.0_CC |
| Revision | 1689535 |
| Stand | 10.08.2026 |
| Status | zur Abstimmung freigegeben |
| Klassifizierung | öffentlich_Entwurf |
| Referenzierung | gemF_VO_HKP |
Änderungen zur Vorversion
Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.
Dokumentenhistorie
| Version
|
Stand
|
Kap./ Seite
|
Grund der Änderung, besondere Hinweise
|
Bearbeitung
|
|---|---|---|---|---|
| 1.0.0 | 20.11.2025 | Beschreibung der fachlichen Abläufe und Anforderungen sowie weitere Anwendungsfälle. | gematik | |
| 2.0.0_CC | 19.05.2026 | Erarbeitung des technischen Konzeptes | gematik |
Das vorliegende Fachkonzept beschreibt die Fachanwendung zur elektronischen Verordnung von häuslicher Krankenpflege (HKP). Im Jahr 2024 machten Leistungen der HKP 3,39% der GKV-Ausgaben aus, insgesamt 9,48 Mrd. Euro ([GKV_SV-Kennzahlen] ). Die Ausgaben sind insbesondere aufgrund demografischer Faktoren in den letzten Jahren stark gestiegen. Die effiziente Unterstützung von Versicherten in der Häuslichkeit gewinnt daher nicht zuletzt angesichts der limitierten Personalsituation in der Pflege zunehmend an Bedeutung. Beschäftigte ambulanter Pflegedienste (PD) nehmen im Kontext der HKP eine zentrale Rolle zwischen Ärzten, Kostenträgern und Versicherten ein. Für die Pflegedienste sind daher effiziente Abläufe und Kommunikationsmöglichkeiten von besonderer Bedeutung. Insbesondere im Hinblick auf die administrativen Aufwände und Abstimmungswege rund um die Verordnungen von HKP-Leistungen kann die Digitalisierung einen wesentlichen Beitrag zur Steigerung der Effizienz leisten. Anknüpfungspunkte zur elektronischen Patientenakte, zu den Anwendungen KIM und TI-Messenger ergänzen die Transformationsprozesse in der Pflege, unterstützen den intersektoralen Austausch und können für Pflegefachpersonen nützliche Werkzeuge darstellen.
Folgende Verbesserungen werden mit Einführung der elektronischen Verordnung häuslicher Krankenpflege beabsichtigt:
Vor dem Lesen des vorliegenden Fachkonzeptes empfiehlt es sich entlang des Versorgungsprozesses vom Verordnen bis zur Leistungsentscheidung durch den Demonstrator zu klicken: [Darstellung eines Happy Cases im TI-Demonstrator].
Das deutsche Gesundheitswesen hat mit der Einführung des E-Rezepts für Arzneimittel einen wichtigen Baustein erhalten, der nun die Grundlage für die Digitalisierung weiterer Verordnungen darstellt. Der Gesetzgeber hat die gematik in [§ 312 Abs. 1 Nr. 12 SGB V] damit beauftragt, die zur Übermittlung der Verordnung von häuslicher Krankenpflege erforderlichen Maßnahmen durchzuführen und dabei auch die Verfahren festzulegen, mit denen Versicherte diese Verordnungen, vor einer Inanspruchnahme der Leistungen, elektronisch ihrem Kostenträger (Krankenkasse) zur Bewilligung übermitteln können (vgl. [§ 312 Abs. 7 SGB V]).
In Deutschland gibt es über 5 Millionen Pflegebedürftige, von denen im Jahr 2023 [nach Angaben des statistischen Bundesamts] rund 19% durch ambulante Pflegedienste versorgt wurden. Die Pflege wird von über 17.500 ambulanten Pflegediensten geleistet. Die Zahl der Pflegebedürftigen und damit verbunden auch die Kosten für deren Versorgung werden aufgrund des demographischen Wandels in den nächsten Jahren deutlich ansteigen.
Der derzeitige Prozess der Verordnung von häuslicher Krankenpflege basiert auf dem Muster 12, ist somit papiergebunden und geprägt von Medienbrüchen. Dies führt nicht nur zu administrativem Mehraufwand für alle Beteiligten – Ärzte, Pflegedienste, Kostenträger und Versicherte – sondern auch zu Verzögerungen in der Kommunikation und Belastung von begrenzt verfügbaren Fachkräften.
Durch die Digitalisierung dieses Prozesses soll die Effizienz gesteigert, Transparenz erhöht, Fehlerquellen minimiert und die zeitnahe Versorgung der Versicherten sichergestellt werden. Eine elektronische Verordnung ermöglicht eine direkte und schnelle Kommunikation zwischen den Beteiligten sowie eine effiziente und medienbruchsfreie Leistungsentscheidung durch die Kostenträger.
Der Gesetzgeber hat die gematik (in [§ 312 Abs. 1 Nr. 12 SGB V]) damit beauftragt die Maßnahmen durchzuführen, die erforderlich sind, damit vertragsärztliche elektronische Verordnungen von häuslicher Krankenpflege nach [§ 37 SGB V] elektronisch nach [§ 360 Abs. 1 SGB V] übermittelt werden können. Die gematik hat zudem die Verfahren festzulegen, mit denen Versicherte diese Verordnungen vor einer Inanspruchnahme der Leistungen, elektronisch ihrer Krankenkasse zur Bewilligung übermitteln können, soweit erforderlich (vgl. [§ 312 Abs. 7 SGB V]). Dieses Dokument beschreibt die fachlichen Grundlagen für die zukünftige Erstellung der elektronischen Verordnung für häusliche Krankenpflege, die Auswahl und Zuweisung an einen Pflegedienst sowie die Übermittlung an einen Kostenträger zwecks Antragstellung.
Weitere wesentliche Rechtsgrundlagen in diesem Zusammenhang zu denen die Festlegungen NICHT in diesem Dokument oder von der gematik definiert werden, sind u. a.:
Ergänzung: Die Partner des Bundesmantelvertrag-Ärzte (BMV-Ä) beauftragen die gematik für die Beratung durch die Krankenkasse einen datenschutzrechtlich konformen Zugriff zu entwickeln, z. B. über einen Zugangscode. Das Bundesministerium für Gesundheit prüft zudem die Möglichkeit einer Regelung ohne Verwendung eines zusätzlichen Codes.
Dieses Dokument beschreibt, wie die Verordnung von häuslicher Krankenpflege in Zukunft digital erfolgen soll und betrachtet hierbei den Verordnungs-, den Einlöse- und den Beantragungsprozess. Das Erkennen des Versorgungsbedarfs sowie das Abrechnen der Leistungen der HKP werden als Start und Abschluss des Prozesses teilweise mit in den Blick genommen, jedoch ohne in der technischen Spezifikation normative Vorgaben zu definieren. Sonderfälle, die vom Gesamtprozess abweichen, werden ebenfalls beschrieben.
Abbildung 1: Gesamtprozess der elektronischen Verordnung häuslicher Krankenpflege (ohne Sonderfälle) und Abgrenzung der Inhalte des Fachkonzepts
Das Dokument richtet sich an die interessierte Fachöffentlichkeit, z. B. Verbände im Gesundheitswesen und an die Industrie. Das vorliegende Dokument soll ein Verständnis für die fachlichen Abläufe und Zusammenhänge schaffen und durch beispielhaft bereitgestellte Demonstratoren das spätere Nutzererlebnis vermitteln.
Dieses Dokument beschreibt nicht die fachliche Konzeption für eine elektronische Verordnung außerklinischer Intensivpflege (AKI) gem. [§ 37c SGB V]. Der Auftrag der gematik gemäß [§ 312 Abs. 1 Nr. 12 SGB V] wird auf der [Roadmap der gematik] zu einem späteren Zeitpunkt eingeplant (voraussichtlich nicht vor 2028/2029).
Das Dokument basiert auf einer fachlichen Konzeption, welche in Zusammenarbeit mit Pflegeverbänden und den Gesellschaftern der gematik erarbeitet wurde.
Das vorliegende Dokument beschreibt zunächst den Problemraum sowie die Anforderungen an eine digitale Lösung aus Sicht der verschiedenen Akteure. Im Anschluss wird der Soll-Prozess beschrieben, Sonderfälle werden betrachtet und daraufhin werden Anwendungsfälle und funktionale Eigenschaften herausgearbeitet. Während der Konzeption erstellte Demonstratoren werden zudem bereitgestellt, um einzelne Aspekte aus dem Soll-Prozess aus der Nutzerperspektive grafisch darzustellen.
Es ist nicht Ziel des vorliegenden Fachkonzeptes die technische Architektur oder die Spezifikationen der elektronischen Verordnung häuslicher Krankenpflege zu erläutern, gleichwohl werden Annahmen an die technische Umsetzung getroffen. Sobald Konsens über die fachlichen Abläufe besteht, folgt die technische Konzeption und Spezifikation. Die Umsetzung durch die Industrie erfolgt nach Freigabe der Spezifikation. Sobald der Ende-zu-Ende-Prozess (Verordnung bis Leistungsentscheidung) digital in der Produktion genutzt werden kann, ist geplant, die elektronische Verordnung der häuslichen Krankenpflege in den Modellregionen der TI zu verproben. Der Abrechnungsprozess ist nicht Bestandteil dieses Konzepts.
User Stories
Eine User Story ist eine in Alltagssprache formulierte Software-Anforderung. Sie ist bewusst kurz gehalten und umfasst in der Regel nicht mehr als zwei Sätze. User Stories werden im Rahmen der agilen Softwareentwicklung zusammen mit Akzeptanztests zur Spezifikation von Anforderungen eingesetzt. [Wikipedia: User Story]
Aus diesem Grund kann in den User Stories eine abweichende Terminologie genutzt werden, welche für den Leser nachvollziehbar (bspw. Patient = Versicherter) ist.
Hinweise auf offene Punkte
Themen, die noch intern geklärt werden müssen oder eine Entscheidung seitens der Gesellschafter erfordern, sind wie folgt im Dokument gekennzeichnet:
Beispiel für einen offenen Punkt.
Der E-Rezept-Fachdienst verarbeitet aktuell E-Rezepte für Arzneimittel und elektronische Verordnungen digitaler Gesundheitsanwendungen. Der E-Rezept-Fachdienst soll für die Verordnung von häuslicher Krankenpflege weiterentwickelt werden, d. h., es werden neue unabhängige Workflows erstellt.
Im Zuge einer Verordnung häuslicher Krankenpflege werden bislang auch weitere fakultative Unterlagen an den Pflegedienst übermittelt. Die Übermittlung der fakultativen Begleitunterlagen (z. B. Insulinplan) soll volldigital erfolgen. Es wird geprüft, ob die Übermittlung über die ePA erfolgen kann.
Grundlage bildet das [Glossar der Telematikinfrastruktur]. Im vorliegenden Fachkonzept werden vorwiegend folgende Begriffe verwendet:
Tabelle 1: Übersicht über vorwiegend verwendete Begriffe im Fachkonzept
| Begriff | Abkürzung | Beschreibung |
|---|---|---|
| Ambulanter Pflegedienst | PD | Der ambulante Pflegedienst ist die Leistungserbringerinstitution für die Pflege. |
| Arztpraxis | - | Die Arztpraxis ist die Leistungserbringerinstitution für den Verordnenden. Die Arztpraxis wird synonym für die Arztpraxis und das Krankenhaus verwendet, sofern dies nicht ausdrücklich abgegrenzt und hervorgehoben wird. |
| Basistarif | - | Der Basistarif in der privaten Krankenversicherung (PKV) ist ein gesetzlich vorgeschriebener Tarif, der eine Grundversorgung im Krankheitsfall sicherstellt und sich am Leistungsumfang der gesetzlichen Krankenversicherung (GKV) orientiert.
|
| Entlassmanagement | - | Krankenhausprozess zur Sicherstellung der Weiterversorgung inkl. HKP-Verordnung. |
| Fachdienst | FD | Der zentrale Dienst in der TI für die Speicherung der Datensätze eines Vorgangs wird Fachdienst genannt. |
| Fortgeschrittene Signatur | FES | Der Begriff wird in diesem Dokument verwendet für die nicht-qualifizierte, d.h. nicht-personenbezogene Signatur einer Organisation bzw. Leistungserbringerinstitution. |
| Frontend des Versicherten | FdV | Das Frontend des Versicherten ist eine Anwendung für den Versicherten, welche die für die Nutzung von Fachanwendungen notwendigen Funktionalitäten bündelt und dezentrale Fachlogik der Fachanwendung ausführt. Das FdV wird von der gematik und den in §360 Abs. 10 SGB V genannten Kostenträgern angeboten. |
| Gebührenpositionsnummer | GPOS | Gebührenpositionsnummer entsprechend dem Bundeseinheitlichen Positionsnummernverzeichnis für Leistungen der häuslichen Krankenpflege und Haushaltshilfe |
| Happy Case | Bezeichnung für idealen Beispielablauf im TI-Demonstrator. | |
| Heilberufsausweis | HBA | Ausweis des (Zahn-)Arztes/Heilberufsangehörigen; erforderlich u. a. für QES. |
| Kostenerstattungsanfrage-Bundle (Kostenerstattungsprinzip) | - | Eine Vorabgenehmigung/Genehmigung an einen Kostenträger (Kostenerstattungsprinzip) erfolgt durch den Versicherten und dieser übergibt:
1. Verordnungsdatensatz 2. Blankoverordnungsdatensatz (optional) 3. Angaben des Pflegedienstes (Name, Adresse, IK und sofern vorhanden KIM-Adresse) - kein allgemein definierter Datensatz, sondern vom Kostenträger festzulegende Angaben über den Pflegedienst, z. B. aus dem Verzeichnisdienst übernommen |
| Kostenträger | KTR | Kostenträger sind im Kontext der TI die gesetzlichen und privaten Krankenversicherungen, gesetzliche Unfallversicherungen sowie die sonstigen Kostenträger nach [§ 362 SGB V]. Unterscheidungen erfolgen hinsichtlich des Sachleistungs- und Kostenerstattungsprinzips siehe entsprechendes Kapitel.
|
| Krankenversichertennummer | Eindeutige Identifikationsnummer eines Versicherten (gemäß 290 SGB V); erforderlich zur Zuordnung beim Kostenträger. | |
| Leistungserbringer | LE | Ein Leistungserbringer gehört zu einem zugriffsberechtigten Personenkreis und erbringt Leistungen des Gesundheitswesens für Versicherte. Nach [§ 339 SGB V] darf er auf Versichertendaten in Anwendungen der Telematikinfrastruktur zugreifen. Im Hinblick auf elektronische Verordnungen sind Zugriffsrechte nach [§ 339 Abs. 2 SGB V] in Verbindung mit [§ 361 SGB V] zu beachten.
|
| Leistungserbringer-institution | LEI | Die in organisatorischen Einheiten oder juristischen Personen zusammengefassten Leistungserbringer (z. B. Arztpraxen, Krankenhäuser). |
| Mitarbeiter medizinischer Institution / Medizinischer Fachangestellter | MFA | Ein „Mitarbeiter medizinische Institution“ arbeitet in einer Institution zur medizinischen Versorgung (z. B. Arztpraxis, Krankenhaus) auf Weisung des verantwortlichen Vorgesetzten als berufsmäßiger Gehilfe des Leistungserbringers oder zur Vorbereitung auf den Beruf. Er kann auf die Daten zugreifen, soweit dies im Rahmen der von ihm zulässigerweise zu erledigenden Tätigkeiten erforderlich ist. Dazu muss er von einer Person autorisiert sein, die über einen HBA oder entsprechenden BA verfügt. Die Autorisierung und der Zugriff müssen nachprüfbar elektronisch protokolliert werden [§ 339 Abs. 5 Satz 1 SGB V]. Im Kontext der Verordnung häuslicher Krankenpflege werden insbesondere auch die Mitarbeiter des Sozialdienstes eines Krankenhauses (Patientenbetreuer) mit der Bezeichnung MFA (Medizinischer Fachangestellter) eingeschlossen.
|
| Pflegedienstleitung / Pflegefachperson | PDL / PFP | Die Pflegedienstleitung (PDL) ist die fachliche Leitung des Pflegedienstes, übernimmt eine koordinierende Rolle und ist verantwortlich für die Überprüfung der Vollständigkeit und Korrektheit der pflegerischen Angaben auf den Verordnungen, die Kommunikation mit Ärzten und Kostenträgern sowie die Sicherstellung, dass alle gesetzlichen und vertraglichen Vorgaben im Verantwortungsbereich der Pflege eingehalten werden.
Pflegefachperson ist ein Mitarbeiter, der die Versorgung der Versicherten meist in der Häuslichkeit übernimmt. Beide werden in diesem Konzept unter dem Begriff Pflegefachperson zusammengefasst. |
| Primärsystem | PS | Ein IT-System, das bei einem Leistungserbringer eingesetzt wird – z. B.
|
| Proof of Patient Presence | PoPP | Ein Nachweis über einen Versorgungskontext, der ein Zusammentreffen von Leistungserbringer und Versichertem bestätigt. Weitere Informationen dazu finden sich im [Technischen Konzept PoPP].
|
| Qualifizierte elektronische Signatur | QES | Signatur für vertragsärztliche Verordnungen am PVS in der TI. |
| Sachbearbeiter bei Kostenträger |
|
Ein Sachbearbeiter beim Kostenträger prüft die Angaben eines Vorgangs (Sachleistungsprinzip) bzw. das Kostenerstattungsanfrage-Bundle (Kostenerstattungsprinzip) und entscheidet über (Teil-)Genehmigung/Ablehnung.
|
| Verordnender / (Zahn-) Arzt |
|
Zugelassener Leistungserbringer, der berechtigt ist, Verordnungen (und Überweisungen) auszustellen (z. B. Arzt oder Zahnarzt). Er ist approbierter Heilberufler und aufgrund seiner Mitgliedschaft in einer (Zahn-)Ärztekammer im Besitz eines HBA. Er ist befugt, vertragsärztliche Verordnungen am PVS zu erzeugen, mit einer QES zu versehen und diese in der TI bereitzustellen. Die hier zu berücksichtigenden (Zahn-)Ärzte sind immer einer LEI zuzuordnen (z. B. eigene Praxis, med. Berufsausübungsgemeinschaft, MVZ, Krankenhaus).
|
| Verordnung | VO | Signierter elektronischer Verordnungsdatensatz für die Verordnung von Leistungen der häuslichen Krankenpflege.
Es wird nicht die für elektronische Verschreibungen von Arzneimitteln gebräuchliche Bezeichnung E-Rezept genutzt. |
| Verordnung - Korrekturvorschlag | VO-k | Datensatz mit einem Vorschlag zur Anpassung des Inhalts einer ausgestellten Verordnung, der von einem Pflegedienst bzw. einem Kostenträger an eine Arztpraxis bzw. einen Pflegedienst übermittelt werden kann.
|
| Verordnung - neue Version | VO-nV | Signierter elektronischer Verordnungsdatensatz in einer neuen Version, nachdem eine Korrektur durch den Arzt oder den PD vorgenommen wurde. |
| Versicherter |
|
Ein Versicherter ist eine natürliche Person, die in einem Versicherungsverhältnis mit einem Kostenträger steht und eine KVNR besitzt. An einzelnen Stellen im Fachkonzept wird synonym der Begriff Patient verwendet (z. B. Patientenausdruck, Patientenakte), wenn dieser bereits etabliert ist. |
| Vertreter |
|
Ein Vertreter ist die Person, die für den Versicherten bestimmte Anwendungsfälle in Bezug auf die Verordnung von HKP durchführen kann. Voraussetzung hierfür ist der Besitz der Gesundheitskarte, eines FdVs bzw. des Ausdrucks zu einer HKP-Verordnung.
Der Vertreter muss nicht in einem Versicherungsverhältnis mit dem gleichen Kostenträger stehen. Vom Vertreter im Sinne dieser Definition ist der gesetzliche Vertreter zu unterscheiden. Nur ein gesetzlicher Vertreter (z. B. Betreuer oder Sorgeberechtigter) kann die Vertretung im Verwaltungsverfahren mit dem Kostenträger übernehmen. |
| Verzeichnisdienst | VZD | Der Verzeichnisdienst ist ein zentraler Dienst der TI-Plattform. Er beinhaltet die Speicherung aller Einträge von Leistungserbringern und Institutionen mit allen definierten Attributen, die in das Verzeichnis aufgenommen werden sollen und die Fachdaten durch fachanwendungsspezifische Dienste. Anhand einer Suchanfrage können Clients und fachanwendungsspezifische Dienste Basis- und Fachdaten abfragen (z. B. X.509 Zertifikate). Ferner können Einträge des Verzeichnisses durch berechtigte fachanwendungsspezifische Dienste geändert, hinzugefügt und gelöscht werden. Der Verzeichnisdienst ist ein Produkttyp. |
| Vorgang | - | Ein Vorgang ist eine zeitlich abgegrenzte, zusammenhängende Folge von Handlungen und Anwendungsfällen rund um eine Verordnung der häuslichen Krankenpflege inkl. derer einzelnen Datensätze, Korrekturvorschläge und neuer Versionen. Die Verwendung des Begriffes 'Vorgang' ist erforderlich, um Ablauf, Prozessschritt und Status in Zusammenhang zu setzen. Der technische Begriff in der Spezifikation wird "Task am Fachdienst" sein. |
Hinweis: Für alle Rollenbezeichnungen bzw. Akteure wird die männliche Bezeichnung verwendet. Diese umfasst gleichermaßen auch die weibliche sowie diverse Bezeichnung.
Folgende Tabelle listet unterschiedliche Kostenträger auf und nennt die gesetzliche oder vertragliche Grundlage für die Beziehung zu Pflegeeinrichtungen sofern vorhanden. Zudem wird auf gesetzlich oder vertraglich definierte Ausnahmefälle kurz hingewiesen im Hinblick auf die Verordnungen häuslicher Krankenpflege, deren genauere Betrachtung im SOLL-Prozess sowie den Anwendungsfällen erfolgt. Die Zuordnung des Leistungsgewährungsprinzips (Sachleistungsprinzip vs. Kostenerstattungsprinzip) ermöglicht für die Prozessbetrachtung im vorliegenden Dokument eine schematische Unterteilung in die beiden Prinzipien anstelle einer erneuten Betrachtung für jeden einzelnen Kostenträger.
Tabelle 2: Übersicht Leistungsgewährungsprinzipien
| Kostenträger | Leistungsgewährungsprinzip | Vertragssituation mit Pflegeeinrichtung |
|---|---|---|
| Gesetzliche Krankenversicherung | Sachleistungsprinzip ist der Normalfall. Abweichend vom Sachleistungsprinzip gibt es folgende Ausnahmen (siehe Kapitel 6.4 Sonderfälle der Kostenerstattung):
|
|
| Gesetzliche Unfallversicherung | Sachleistungsprinzip ist der Normalfall, Kostenerstattung im Ausnahmefall siehe:
|
|
| Private Krankenversicherung | Kostenerstattungsprinzip |
|
| Beihilfe | Kostenerstattungsprinzip |
|
| Sonstige Kostenträger: Bundespolizei | Sachleistungsprinzip | Verwaltungsvorschrift zur Bundespolizei Heilfürsorgeverordnung[]:
|
| Ausblick Sonstige Kostenträger | Die Festlegung erfolgt im Einzelfall mit dem jeweiligen Kostenträger, sobald ein weiterer Sonstiger Kostenträger sich der Telematikinfrastruktur bzw. insbesondere der Anwendung E-Rezept/Verordnung häusliche Krankenpflege anschließt.
Es ist davon auszugehen, dass das Leistungsprinzip dem Sachleistungsprinzip oder Kostenerstattungsprinzip zuzuordnen sein wird. |
|
Das Kapitel befasst sich aus Sicht der einzelnen Rollen bzw. Akteure im analogen heutigen IST-Versorgungsprozess mit den empfundenen Hemmnissen in Hinblick auf die HKP-Verordnung sowie den gelebten Versorgungsprozess und formuliert Anforderungen an den digitalen Prozess. Die Beschreibung der Rollen, der Hemmnisse und der Anforderungen wurde in Workshops während der Discovery- und Konzeptionsphase mit Ärzten, Sozialdienstmitarbeitern in Krankenhäusern, Pflegefachpersonen und Pflegedienstleitungen sowie Sachbearbeitern von Kostenträgern erarbeitet oder in Interviews formuliert. Es werden in den Unterkapiteln die folgenden Perspektiven beschrieben:
Gesetzlich Versicherte (einschließlich gesetzlich Unfallversicherte)
Der Versicherte erhält zunächst eine Verordnung und wählt dann einen ambulanten Pflegedienst, welcher die verordneten Leistungen erbringen soll. Dabei kann er von unterschiedlichen Stellen Hilfe erhalten (z. B. Arztpraxis, Kostenträger, Beratungsstellen, etc.), um einen Pflegedienst zu finden, der die benötigten Qualifikationen erfüllt. Bevor der Antrag beim Kostenträger (Sachleistungsprinzip) zur Leistungsentscheidung eingereicht wird, unterschreibt der Versicherte den Antrag. Nach der Leistungsentscheidung wird der Versicherte über die Entscheidung vom Kostenträger informiert und leistet (sofern nicht befreit) nach erbrachter Leistung eine Zuzahlung und eine Verordnungsblattgebühr. Zur Abrechnung der erbrachten Leistungen durch den Pflegedienst muss der Versicherte einen Leistungsnachweis meist einmal im Monat unterschreiben.
Privatversicherte
Der Versicherte erhält zunächst eine Verordnung und wählt dann einen ambulanten Pflegedienst, der die verordneten Leistungen erbringen soll. Dabei kann er von unterschiedlichen Stellen Hilfe erhalten (z. B. Arztpraxis, Krankenversicherung, Beratungsstellen, etc.). Der Privatversicherte erhält meist das Muster 12, auch wenn dies nicht zwingend von den Versicherungen verlangt wird. Der Versicherte kann oder muss die Verordnung bzw. den Antrag zur Verordnung unterschreiben (je nach Tarif kann/muss) und bei der Versicherung für eine Vorabprüfung einreichen. Falls der Versicherte bereits einen Pflegedienst ausgewählt hat und von diesem einen Kostenvoranschlag erhält, so kann (oder je nach Tarif, muss) dieser ebenfalls zur Prüfung eingereicht werden. Falls Rückfragen bestehen oder Korrekturbedarfe seitens der Versicherung festgestellt werden, muss der Versicherte diese mit dem Arzt oder dem Pflegedienst klären. Nachdem die Leistung erbracht wurde, unterschreibt der Versicherte einen Leistungsnachweis und erhält eine Rechnung. Diese Rechnung, eine Kopie des Leistungsnachweises und die Verordnung reicht der Versicherte bei seiner Krankenversicherung ein. Nach der Prüfung erhält der Versicherte eine Kostenerstattung. Ebenso wird die Rechnung vom Pflegedienst durch den Versicherten beglichen.
Vertreter
Da der Versicherte häufig aufgrund seiner Erkrankungen nicht in der Lage ist die Aufgaben zu übernehmen, kann jede der oben beschriebenen Aktionen der Versicherten auch durch einen gesetzlichen Vertreter übernommen werden. Im Krankenhaus kommt es regelmäßig vor, dass Ehepartner im Rahmen der Ehegatten-Notvertretung als Vertreter des Patienten handeln.
Unklarheit über Bearbeitungsstand: Versicherte haben keinen klaren Einblick in den Status ihrer Verordnung, was zu Verunsicherungen und zusätzlichen Rückfragen führt.
Unterschrift des Versicherten oder Vertreters: Der Antrag muss vom Versicherten oder einem Vertreter unterschrieben werden. Wenn der Vertreter nicht im gleichen Haushalt wohnt, müssen die Verordnungen per Post zwischen Vertreter und Pflegedienst ausgetauscht werden oder der Vertreter muss zur Unterschrift in die Häuslichkeit des Versicherten fahren.
Die Postlaufzeiten von Verordnung und Entscheidungsschreiben erzeugen Zeitverzögerungen, was zu Wartezeiten bei und Rückfragen von den Versicherten führt.
Versicherte möchten auch bei einer digitalen Verordnung die freie Wahl des ambulanten Pflegedienstes haben. Gleichzeitig möchten Versicherte bei der Einlösung und Leistungsentscheidung möglichst wenig manuelle Schritte durchführen müssen. Da die betroffenen Versicherten häufig weniger digital affin sind, müssen der Einlöseprozess und der Prozess zur Leistungsentscheidung vollständig ohne digitale Anwendungen für den Versicherten möglich sein. Für Vertreter könnten digitale Tools eine Erleichterung darstellen, sofern diese niederschwellig und einfach zu benutzen sind. Wichtig ist den Versicherten, dass der Schutz ihrer persönlichen Daten gewährleistet sein muss, während gleichzeitig alle relevanten Informationen für die Beteiligten zugänglich sein sollen. Privatversicherte möchten darüber hinaus alle erstattungsrelevanten Dokumente gebündelt digital abrufen und einreichen können. Manuelle Schritte wie das Abfotografieren oder Scannen sollen dabei entfallen.
Ärzte übernehmen eine zentrale Rolle bei der Verordnung von häuslicher Krankenpflege, indem sie auf Basis der Diagnosen des Versicherten und Einschränkungen, die HKP erforderlich machen, die medizinische Notwendigkeit für Leistungen der HKP feststellen. Hierzu müssen sie sich persönlich vom Zustand des Versicherten überzeugen oder diesen aus der laufenden Behandlung kennen. Die Verordnung wird von ihnen erstellt und unterschrieben, wobei sie die erforderlichen Maßnahmen der HKP und deren Dauer gemäß den Richtlinien selbst festlegen oder, im Falle einer Blankoverordnung, die Festlegung von Dauer und Häufigkeit einer Maßnahme an eine dementsprechend qualifizierte Pflegefachperson eines Pflegedienstes übergeben. Zudem koordinieren Ärzte Abstimmungen mit dementsprechend qualifizierten Pflegefachpersonen eines Pflegedienstes, um die Umsetzung der Verordnung sicherzustellen. Sie stehen für Rückfragen zur Verfügung und nehmen bei Bedarf Anpassungen vor, sofern medizinisch erforderlich. Darüber hinaus betrachten sie den Gesundheitszustand im Verlauf der Versorgung und passen die Verordnung an, wenn sich die Bedürfnisse des Versicherten ändern.
Mitarbeiter in der Arztpraxis (z. B. MFAs) unterstützen bei der Vorbereitung von Erst- und Folgeverordnungen. Sie organisieren die administrativen Abläufe in der Praxis und koordinieren die Kommunikation zwischen der Arztpraxis, den Pflegediensten und etwaige medizinische Rückfragen der Kostenträger, um sicherzustellen, dass alle Beteiligten die notwendigen Informationen erhalten. Zudem sind Mitarbeiter in der Arztpraxis oft erste Ansprechpartner für Versicherte und deren Angehörige und klären Fragen zur Verordnung.
Hoher Administrativer Aufwand: Für Ärzte und MFAs ist der administrative Aufwand erheblich. Das aktuelle Verordnungsformular (Muster 12) bietet oft nicht genügend Platz für detaillierte Informationen, zum Beispiel für Wundbeschreibungen, Informationen zur Medikamentengabe und Diagnosen. Weiterhin ist der manuelle Aufwand zur Übertragung von Informationen aus der Patientendokumentation im Praxisverwaltungssystem in die Verordnung hoch. Die Kommunikation mit Pflegediensten und Kostenträger erfolgt häufig über Telefon oder Fax, was zeitaufwendig ist und zu Verzögerungen führen kann. Die Nutzung eines papierbasierten Formulars verlangsamt die Kommunikation zudem erheblich.
Unterscheidung Erst- und Folgeverordnung: Die Unterscheidung zwischen Erst- und Folgeverordnungen ist oft schwierig, insbesondere wenn Informationen aus dem Krankenhaus zur HKP-Verordnung nicht rechtzeitig übermittelt werden.
Unterstützung bei der Pflegedienstsuche: MFAs sind bei Erstverordnungen oft damit beschäftigt, Versicherten und Vertreter bei der Suche nach einem geeigneten Pflegedienst zu unterstützen, was viel Zeit in Anspruch nimmt.
Ärzte wünschen sich einen benutzerfreundlichen und effizienten Prozess zur elektronischen Verordnung von häuslicher Krankenpflege, der den administrativen Aufwand sowie Korrekturfälle reduziert. Eine intuitive Benutzeroberfläche und eine gute Integration in das Praxisverwaltungssystem sollten das Ausfüllen der Verordnung erleichtern und manuelle Überträge von bereits erfassten Informationen (z. B. Patientenstammdaten, Diagnosen oder Leistungen aus vorherigen Verordnungen) unnötig machen. Automatische Überprüfungen auf Vollständigkeit und Plausibilität sollen Rückfragen reduzieren. Zudem ist eine digitale und direkte Kommunikation mit Pflegediensten und Kostenträgern wichtig, um Rückfragen schnell klären und Anpassungen effizient vornehmen zu können.
Da unterschiedliche Mitarbeiter der Arztpraxis administrative Prozesse vorbereiten und Anfragen für neue Verordnungen über diverse Kanäle aufnehmen, sollten elektronische Verordnungen von diesen Mitarbeitern vorbereitet werden können. Auch automatisierte Erinnerungen für Folgeverordnungen sowie strukturierte Anfragen zur Notwendigkeit für Folgeverordnungen durch den Pflegedienst würden den Arbeitsablauf erheblich verbessern.
In einem Krankenhaus spielt die Verordnung von häuslicher Krankenpflege im Rahmen des Entlassmanagements eine entscheidende Rolle. Häufig müssen Versicherte nach ihrer Entlassung aus dem Krankenhaus weiterhin medizinisch pflegerisch versorgt werden, was die Ausstellung von HKP-Verordnungen erforderlich macht. Mitarbeitende (z. B. Sozialpädagogen) in Sozialdiensten der Krankenhäuser unterstützen die Krankenhausärzte bei der Vorbereitung von Verordnungen. Sie wählen in Absprache mit dem Versicherten einen Pflegedienst aus, der die Versorgung übernehmen kann und koordinieren die Kommunikation mit den Pflegediensten und den Kostenträgern. Zudem sind Sozialdienste oft der erste Ansprechpartner für Versicherte und deren Angehörige und klären Fragen zur Verordnung. Der Prozess umfasst die Abstimmung mit Pflegediensten und die Sicherstellung, dass alle notwendigen Informationen, wie ICD-Codes und Medikationspläne, korrekt erfasst und bei Entlassung zur Verfügung gestellt werden. Nach der Vorbereitung der Verordnung durch den Sozialdienst, wird die Verordnung durch den Krankenhausarzt geprüft und freigegeben. Häufig werden die Inhalte der Verordnung bereits vor der Entlassung dem Pflegedienst (z. B. telefonisch mitgeteilt oder Entlassmanagement-Plattform) zur Verfügung gestellt. Die Originalverordnung erhält der Versicherte bei Entlassung.
Begrenzter Platz auf Papierformular: Der Platz auf dem Formular ist begrenzt und reicht häufig bei längeren Begründungen oder einer Vielzahl an benötigten Leistungen nicht aus. Aus diesem Grund müssen häufig mehrere Verordnungsformulare für einen Versicherten verwendet werden oder Texte händisch auf dem Formular in kleiner Schrift ergänzt werden.
Hoher Zeitaufwand für Korrekturen: Ein wesentliches Hemmnis ist der erhebliche Zeitaufwand, der durch notwendige Korrekturen von HKP-Verordnungen entsteht. Wenn Fehler in den Verordnungen entdeckt werden, müssen diese oft storniert und neu angelegt werden, was den Prozess verlangsamt und zusätzliche Arbeit verursacht.
Arbeitsabläufe im Krankenhaus: Die Verordnungen werden häufig durch den Sozialdienst inhaltlich vorbereitet und im Anschluss durch den Facharzt der Station unterschrieben. In der Papierwelt ist diese Arbeitsteilung sehr aufwendig; Papier muss zwischen Krankenhausstandorten hin und her gefahren werden, wenn es z. B. kurzfristige Änderungen z. B. beim Entlassdatum gibt. Insbesondere steht der Prozess im Entlassmanagement unter einem hohen Zeitdruck, da, anders als im niedergelassenen Bereich, die Entlassung oft eine sehr schnelle Lösung verlangt und andernfalls leistungsrechtliche Komplikationen drohen.
Medienbrüche verursachen in der externen Kommunikation einen hohen Aufwand. Oft müssen telefonische Absprachen und schriftliche Genehmigungen parallel erfolgen. Unter anderem muss der Hausarzt im Nachgang auf dem Schriftwege informiert werden.
Krankenhausärzte und Mitarbeiter in Sozialdiensten von Krankenhäusern wünschen sich einen benutzerfreundlichen und effizienten Prozess zur elektronischen Verordnung von häuslicher Krankenpflege, der den administrativen Aufwand sowie Korrekturfälle reduziert. Eine intuitive Benutzeroberfläche und eine gute Integration in das Krankenhausinformationssystem bzw. Entlassmanagement-Software sollten das Ausfüllen der Verordnung erleichtern und manuelle Überträge von bereits erfassten Informationen (z. B. Patientenstammdaten, Diagnosen oder Leistungen aus vorherigen Verordnungen) verhindern. Automatische Überprüfungen auf Vollständigkeit und Plausibilität sollen Rückfragen reduzieren. Mitarbeiter in Sozialdiensten sollten die Inhalte der Verordnungen im Krankenhausinformationssystem bzw. in der Entlassmanagement-Software vorbereiten können und den Krankenhausärzten zur Signatur vorlegen können. Zudem ist eine digitale und direkte Kommunikation mit Pflegediensten und Kostenträgern wichtig, um Rückfragen schnell klären und Anpassungen effizient vornehmen zu können.
Pflegefachperson
Pflegefachpersonen sind verantwortlich für die Durchführung der verordneten Maßnahmen und können, im Rahmen der erweiterten Versorgungsverantwortung, selbstständig über die Häufigkeit und Dauer bestimmter Maßnahmen entscheiden, sofern dies nicht schon explizit auf der ärztlichen Verordnung festgelegt ist. Diese Verantwortung erfordert eine enge Abstimmung mit den verordnenden Ärzten.
Pflegedienstleitung
Die Pflegedienstleitung (PDL) übernimmt eine koordinierende Rolle. Dazu gehört die Überprüfung der Vollständigkeit und Korrektheit der pflegerischen Angaben auf den Verordnungen, die Kommunikation mit Ärzten und Kostenträgern sowie die Sicherstellung, dass alle gesetzlichen und vertraglichen Vorgaben im Verantwortungsbereich der Pflege eingehalten werden.
Fehlerhafte und unvollständige Verordnungen: Pflegedienste sehen häufig Anpassungsbedarf bei Verordnungen aus Krankenhäusern oder Arztpraxen. Korrekturschleifen führen zu Verzögerungen und zusätzlichem administrativen Aufwand.
Unklarheit über Bearbeitungsstand im Prozess zur Leistungsentscheidung: Es fehlt an Transparenz beim Status der Entscheidungsprozess und ggf. zu den Ablehnungsgründen. Dies führt zu Unsicherheiten und erhöhtem Kommunikationsaufwand.
Kurze Verordnungszeiträume: Aus Sicht der Pflege werden die maximal möglichen Verordnungszeiträume nicht genutzt. Die Erinnerung an Folgeverordnungen erhöht den administrativen Aufwand.
Die Pflege erhofft sich durch die elektronische Verordnung, dass administrative Aufwände reduziert werden, indem Korrekturschleifen und manuelle Eingaben minimiert werden. Hierfür ist die Prüfung der Verordnung bereits in der Arztpraxis auf Vollständigkeit und Plausibilität (gemäß der HKP-RL) notwendig. Weiterhin ist es der Pflege wichtig, dass der gesamte Verordnungs- und Einlöseprozess ohne Medienbruch (z. B. beim Einholen der Unterschrift des Versicherten) stattfinden kann, sodass weder Gesundheitskarten noch Papiere zwischen den Akteuren hin und her transportiert werden müssen. Auch eine nahtlose und benutzerfreundliche Integration in bestehende Pflegeprimärsysteme ist notwendig, um den Arbeitsablauf zu optimieren und die Effizienz zu steigern. Damit die Versorgung der Versicherten durchgehend sichergestellt wird, sollten Folgeverordnungen immer rechtzeitig durch den Arzt ausgestellt werden (was z. B. durch eine Erinnerungsfunktion in der Arztpraxis erreicht werden könnte). Weiterhin wünscht sich die Pflege Transparenz im Entscheidungsprozess, damit der Status der Entscheidung bzw. die Ablehnungsgründe jederzeit einsehbar sind und Unsicherheiten vermieden werden. Hinweis: Mit Verweis auf datenschutzrechtliche Gründe können die Krankenkassen den Pflegediensten nicht alle Ablehnungsgründe mitteilen.
Bevor eine Verordnung in der Krankenkasse oder Unfallversicherung geprüft wird, wird sie eingescannt und digitalisiert. Einige Krankenkassen und Unfallversicherungen nutzen bereits (teil-)automatische Prozesse zur Dunkelverarbeitung. Dennoch übernehmen Sachbearbeiter oft die Leistungsentscheidung für häusliche Krankenpflege. Ihre Aufgabe ist es, die Verordnungen und Antragsdaten auf Vollständigkeit und Korrektheit zu überprüfen und sicherzustellen, dass sie den Richtlinien und Verträgen entsprechen. Bei Bedarf klären sie Rückfragen mit Ärzten, Pflegediensten, Versicherten, deren Angehörigen oder dem Medizinischen Dienst. Nach der Prüfung informieren sie alle Beteiligten über die Entscheidung, ob die Verordnung genehmigt, abgelehnt oder teilweise genehmigt wird. Die Mitarbeiter der Krankenkasse unterstützen ihre Versicherten auch bei der Suche nach einem geeigneten Pflegedienst.
Fehlerhafte und unvollständige Verordnungen: Häufig sind Verordnungen nicht korrekt ausgefüllt oder es fehlen wichtige Angaben wie Stempel, Unterschriften oder das Ausstellungsdatum.
Hoher administrativer Aufwand: Der manuelle Aufwand zur Korrektur und Nachbearbeitung von Verordnungen ist erheblich. Dies wird durch die Notwendigkeit, nachträglicher händischer Unterschriften des Arztes verstärkt. Die Bearbeitung kann sich abhängig von Kommunikationswegen und Versandzeiten verzögern.
Intransparente Bearbeitungsprozesse: Versicherte und Leistungserbringer haben oft keinen Einblick in den Bearbeitungsstatus der Verordnungen, was zu Unsicherheiten und zusätzlichen Rückfragen führt.
Krankenkassen und Unfallversicherungen wünschen sich einen vollelektronischen Prozess, bei dem die Digitalisierung durch Scannen der papierbasierten Verordnung entfällt. Um die Prüfung effizient zu gestalten, sollte der Abruf der Verordnung durch die Krankenkasse oder Unfallversicherung oder von ihnen beauftragte Partner erfolgen und in die Systeme integriert werden. Eine standardisierte Prüfung der Verordnung auf Basis der HKP-Richtlinie beim Verordnenden und der Verträge beim Pflegedienst würde unvollständige oder fehlerhafte Verordnungen und somit aufwendige Korrekturschleifen reduzieren. Sollten dennoch Rückfragen notwendig sein, sollte ein einheitlicher digitaler Kommunikationsweg mit Ärzten und Pflegediensten genutzt werden. Eine transparente Statusanzeige für alle Beteiligten wäre hilfreich, um unnötige Rückfragen zu minimieren.
Die gesetzliche Unfallversicherung legt Wert auf die Angabe des Unfalltages in der Verordnung. Bei Angabe von Arbeitsunfall oder Berufskrankheit in der Verordnung sind die Limitationen der G-BA-Richtlinie nicht zu berücksichtigen, da diese nicht für die gesetzliche Unfallversicherung gelten.
Versicherte haben die Möglichkeit, die Verordnung vorab bei ihrer Versicherung einzureichen, um zu klären, ob und welche Kosten übernommen werden. Die Versicherungen bieten Unterstützung bei der Erstattung und der Beschaffung der Leistungen. Die Versicherungen archivieren die geprüfte Verordnung in der entsprechenden Versichertenakte und informieren den Versicherungsnehmer über das Ergebnis der Prüfung per Post/Versicherten-App. Der Prozess ist jedoch nicht standardisiert und kann je nach Vertrag variieren.
Entfällt die Vorabprüfung, prüfen die Krankenversicherungen die Verordnung auf Notwendigkeit und Umfang der verordneten Leistung auf Basis des Vertrages mit dem Versicherungsnehmer, wenn dieser die Verordnung zusammen mit einer Rechnung, Leistungsnachweisen und ggf. weiterführenden Unterlagen einreicht. Hierfür digitalisieren die Versicherungen bereits die eingereichten Unterlagen (Scan) und prüfen die Verordnung manuell. Nach abgeschlossener Prüfung erhält der Versicherungsnehmer die Information, ob die Kosten (teilweise) erstattet werden (per Post/Versicherten-App). Werden bei der Prüfung Fehler auf den eingereichten Unterlagen bemerkt, wird der Versicherungsnehmer informiert und um Korrektur gebeten.
Fehlerhafte und unvollständige Verordnungen: Oft sind die Verordnungen, insbesondere Erstverordnungen aus Krankenhäusern, fehlerhaft oder unvollständig. Dies führt zu einem hohen Korrekturaufwand und Verzögerungen, denn es darf nur mit bzw. über den Versicherungsnehmer kommuniziert werden.
Intransparente Preisgestaltung: Aktuell basieren die vom Pflegedienst angesetzten Preise der Leistungen auf dem Basistarif, individuell festgelegten Preisen des Pflegedienstes oder auf den GKV-Vergütungsvereinbarungen. Auf den Rechnungen selbst ist meist nicht erkennbar, welche Preisbasis zu Grunde liegt. Ist eine Abweichung zu durchschnittlichen Preisen erkennbar, wird der Versicherte aufgefordert die Vergütungsvereinbarung/Preisliste bei seinem Pflegedienst anzufragen. Das Versicherungsunternehmen selbst erhält auf Anfrage beim Pflegedienst meist keine Information, da ein Vertragsverhältnis ausschließlich zwischen Pflegedienst und Versichertem besteht.
Komplexe Prüfprozesse durch unterschiedliche Formate und Anforderungen an eingereichte Dokumente: Die unterschiedlichen eingereichten Dokumente wie Verordnung, Rechnung und Leistungsnachweise müssen in Abhängigkeit zueinander auf Richtigkeit und Plausibilität geprüft werden. Wird bspw. eine Leistungsgruppe abgerechnet, kann nur mithilfe des Leistungsnachweises geprüft werden, welche Einzelleistung tatsächlich erbracht wurde und ob diese auch verordnet wurde. Aufgrund dieser komplexen Abhängigkeit, fehlender standardisierter sowie strukturierter Daten, ist eine automatisierte Bearbeitung derzeit nicht möglich.
Private Versicherungsunternehmen streben eine Vereinheitlichung der Prozesse und Dunkelverarbeitung der Verordnungen, zugehöriger Rechnungen und Leistungsnachweise an, um die Bearbeitung effizienter zu gestalten. Eine zentrale Anforderung ist die Möglichkeit, dass Verordnungen und Abrechnungen strukturiert und digital erfasst werden können, um den administrativen Aufwand zu reduzieren. Um diesen Prozess zu vereinfachen und zu beschleunigen, wäre es vorteilhaft, die Vergütungsvereinbarungen strukturiert und zentral abzulegen. Zudem wäre es wünschenswert, wenn Rechnungen und zugehörige Leistungsnachweise zusammengeführt und standardisiert werden, sodass der Prüfungsprozess vereinfacht wird. Eine alternative Möglichkeit wäre, dass der passende Datensatz automatisch mit der Abrechnung übermittelt wird.
Auf Wunsch der PKV soll die Harmonisierung von elektronischer Verordnung und digitaler Patientenrechnung als ganzheitliches Konzept betrachtet werden und erfordert daher ein übergreifendes Fachkonzept. Für alle Verordnungstypen, einschließlich Arzneimittel, ist eine nahtlose Verbindung zwischen Verordnung und anschließender Abrechnung anzustreben, um eine optimale Nutzererfahrung zu gewährleisten.
Im Rahmen der gemeinsamen Ausarbeitung dieses Fachkonzeptes mit Vertretern der gesetzlichen Kranken- und Unfallversicherung, der privaten Krankenversicherung, sonstigen Kostenträgern, der Kassenärztlichen Bundesvereinigung und Verbänden der Pflege wurden Prämissen diskutiert, welche grundsätzlichen Charakter für die Ausgestaltung der Anwendung haben sollen. Diese Prämissen werden im Folgenden genannt.
P1.1 Eindeutige ID: Die elektronische Verordnung, die zu übermittelnden Daten der Pflege und die Entscheidung der Kostenträger lassen sich jeweils einer eindeutigen ID zuordnen. Die Statusinformationen zu dieser ID sind für alle Akteure (Arzt, ausgewählter Pflegedienst, Kostenträger im Sachleistungsprinzip, Versicherter) transparent. Diese ID wird
Hinweise:
P1.2 Eindeutige Kennung je Leistung. Jede Leistungsposition wird einzeln verordnet und genehmigt:
P1.3 Parallel zur Verordnung stehen begleitende Unterlagen elektronisch zur Verfügung (z. B. für Leistungsentscheidung):
P1.4 Für die Pflege von Vertragsdaten (GPOS) in das Pflegeprimärsystem sind weiterhin die Pflegedienste oder deren IT-Dienstleister selbst verantwortlich. Es erfolgt keine elektronische Bereitstellung der Vertragsdaten durch die Kostenträger. Bestehende Lösungen von einzelnen Kostenträgern können weiter genutzt werden.
P1.5 Es sind im Prozess keine Unterschriften des Versicherten auf Papier erforderlich (Details regeln die Rahmenempfehlungen nach § 132a Abs. 1 SGB V)
P2.1 Das Primärsystem der Ärzte unterstützt durch Hilfestellungen beim Verordnen. Die Unterstützung kann erfolgt durch:
P2.2 Das Primärsystem der Pflege unterstützt die Pflegefachperson dabei
P3.1 Datenerfassung
P3.2 Datenintegrität:
P3.3 Versionierung: Anpassungen und Änderungen an Verordnungen oder Anträgen werden jeweils als neue Version erstellt. Alte Versionen bleiben erhalten, die Referenzierung ist über die gemeinsame Verordnungs-ID gegeben. Disclaimer: Details werden in der technischen Spezifikation festgelegt.
P3.4 Abrechnung: Die sich aus Verordnung, Antrag und Entscheidung ergebenden Informationen dienen als Grundlage der Abrechnung.
P3.5 Dokumentationspflichten: Dokumentationspflichten liegen bei den Akteuren, der zentrale Fachdienst als Transaktionsmedium (Workflow-Engine) dient nicht als Lösung für die Dokumentationspflichten der handelnden Akteure. Eine automatische Übernahme in die Dokumentation der Primärsoftware muss möglich sein.
P3.6 Einfachheit: Da nicht alle betroffenen Versicherten als digital affin eingeschätzt werden können, muss die Einlösung (und der Prozess zur Leistungsentscheidung) ohne eigenes Smartphone ablaufen können. Die Nutzung des FdVs ist für die Versicherten optional. Eine umfassende Berücksichtigung einer Vertreterlösung ist dabei ggf. nicht Teil des MVP - Minimum Viable Product (= Version 1.0).
Folgenden Vorgänge werden vom Soll-Prozess erfasst:
Tabelle 3: Anwendungsfälle des fachlichen Soll-Prozesses
| Akteur | Vorgang | Anwendungsfall |
|---|---|---|
| Verordnender | - Erstellung und Signatur der Verordnung
- Bereitstellung der Zugriffsinformationen als Papierausdruck - Löschen der Verordnung - Anpassung der Verordnung aufgrund Korrekturbedarfs oder verändertem Leistungsumfang |
6.1 Verordnungsprozess
6.8 Korrekturprozesse 6.3 Verordnungen löschen 6.2 Veränderter Leistungsumfang innerhalb des Verordnungszeitraums |
| Kostenträger | - Beratung des Versicherten aus verschiedenen Gründen vor der Einlösung | 6.4 Sonderfälle der Kostenerstattung
|
| Versicherter | - Einlösen der Verordnung
- Verfügbarkeitsanfrage eines Versicherten bei einem Pflegedienst per FdV - Zuweisung an Pflegedienst- Falls ein Versicherter nicht einlösen möchte, kann er sie löschen |
6.5 Anwendungsfälle im Einlöseprozess
6.5.3 Beratung durch die Kostenträger 6.3 Verordnungen löschen |
| Pflegedienst | - Übernahme der Verordnung ins Pflegeprimärsystem (Bestätigung der Zuweisung)
- Korrekturanfrage der Verordnung beim Verordnenden - Ergänzen der Blankoverordnung - Ergänzen der Angaben des Pflegedienstes und Übergabe zur Leistungsentscheidung an Kostenträger (nicht PKV) - Anpassung der Angaben aufgrund Korrekturbedarfs - Erstellung der Leistungsnachweise - Anpassung des Leistungsumfangs bei Bedarf |
6.6 Angaben des Pflegedienstes erfassen
6.8 Korrekturprozesse 6.10 Leistungsnachweise 6.12 Abrechnungsverfahren |
| Kostenträger | Prozess zur Leistungsentscheidung im Sachleistungsprinzip:
- Einsicht in den Vorgang - ggf. Weiterleitung des Vorgangs bei Unzuständigkeit - ggf. Korrekturanfrage Verordnenden oder Pflegedienst - Information für Versicherten, Arzt und Pflegedienst über Ergebnis der Leistungsentscheidung |
6.7 Prozess zur Leistungsentscheidung / Kostenerstattungsanfrage
6.9 Unzuständigkeit der Krankenkasse (nur GKV und DGUV) 6.8 Korrekturprozesse 6.12 Abrechnungsverfahren |
Hinweis: zu den Themen Leistungsnachweise und Abrechnungsverfahren erfolgen keine Festlegungen in diesem Fachkonzept.
Die detaillierte grafische Soll-Prozessdarstellung findet sich im Kapitel [14.1 Fachlicher Soll-Prozess].
Die Verordnungsdaten werden von dem verordnenden Arzt oder einer MFA im PVS erfasst. Bereitet die MFA die Verordnung vor, kann diese dem Arzt auf einer Signaturliste zur Prüfung und Signatur bereitgestellt werden. Eine VO HKP hat eine eindeutige ID und kann beliebig viele Leistungen beinhalten. Bei Folgeverordnungen können Daten aus vorherigen Verordnungen übernommen werden. Benötigte weiterführende Unterlagen können innerhalb des Verordnungsvorgangs der Verordnung beigefügt werden oder werden automatisch durch das PVS hinterlegt (z. B. Behandlungsplan für pHKP). Bereits während der Eingabe der Verordnung werden Hinweise (z. B. Angaben zur Verordnungsdauer) auf Basis der HKP-RL angezeigt, sodass diese bei der Befüllung der Verordnung beachtet werden können. Beim Speichern der Verordnung wird eine Prüfung der Verordnung auf formale Korrektheit und Plausibilität auf Basis des Informationsmodells (welches durch GKV und KBV definiert werden) durchgeführt. Sollte ein Fehler auftreten, werden verständliche und handlungsweisende Fehlermeldungen angezeigt (z. B. Pflichtfelder markiert, etc.). Der Verordnungsdatensatz wird grundsätzlich mit dem Heilberufsausweis oder, in im BMV-Ä definierten Ausnahmefällen der Vertragspartner, mit der SMC-B der Arztpraxis oder des Krankenhauses signiert. Näheres dazu regeln die Vertragspartner in Verträgen. Die Vertragspartner Kassenärztliche Bundesvereinigung, GKV-Spitzenverband und Deutsche Krankenhausgesellschaft e.V. prüfen Regelungen auch für den Rahmenvertrag Entlassmanagement.
Es besteht keine Unterscheidung je Leistungsprinzip beim Verordnen der Leistung in der Arztpraxis. Unabhängig vom Verordnen und der Fachanwendung zur elektronischen Verordnung häuslicher Krankenpflege ist der Nachweis eines Versicherungsverhältnisses oder die sichere Übermittlung der Krankenversichertennummer (KVNR) - unterstützt durch eGK, GesundheitsID oder elektronische Ersatzbescheinigung (eEB) oder Online-Checkin (OCI) - eine notwendige Voraussetzung.
In folgenden Links werden die Anwendungsfälle im TI-Demonstrator dargestellt:
Zur Umsetzung des Verordnungsprozesses werden im technischen Konzept Best Practice UX Vorgaben mitgeben, die aber keine normativen Vorgaben darstellen. Die normativen Vorgaben zu dem Prozess finden sich in der technischen Anlage der KBV.
Abbildung 2: Übersicht über den Verordnungsprozess
Für folgende Fälle werden neben der Verordnung für somatische HKP-Leistungen immer separate Verordnungen erstellt, die in unterschiedlichen Pflegediensten eingelöst werden können:
Die Erfassung dieser Leistungen in separaten Verordnungen soll durch das PVS erfolgen, sodass der verordnende Arzt keinen Mehraufwand hat. Obwohl technisch damit separat einlösbare Verordnungen entstehen, werden diese als Gesamtverordnung betrachtet, sodass entsprechend der gesetzlichen Regelungen zur Zuzahlungspflicht von den gesetzlichen Krankenkassen nur einmal 10€ Zuzahlungen (Verordnungsgebühr) für diese Gesamtverordnung erhoben wird. Die separate Aufteilung der Verordnungen gilt auch für alle anderen Kostenträger, nicht nur gesetzliche Krankenversicherungen.
Verordnungen über häusliche Krankenpflege können für einen Zeitraum von bis zu sieben Kalendertagen nach der Entlassung auch im Rahmen des Entlassmanagements erstellt werden. Die Anforderung an das Krankenhaus, dass der Hausarzt gemäß Entlassmanagement Rahmenvertrag und gemäß der GBA-Richtlinie in geeigneter Form informiert werden muss, bleibt bei der elektronischen Verordnung weiterhin bestehen und muss über geeignete Kommunikationskanäle erfolgen (hierzu macht das Fachkonzept keine Vorgaben).
Damit Hausärzte (und auch weitere behandelnde Ärzte) einen guten Überblick über die verordneten Leistungen der Versicherten erlangen können, sollen automatisiert durch die Fachanwendung elektronische Verordnung HKP alle verordneten HKP-Leistungen in der ePA des Versicherten in Form einer Verordnungsübersicht gespeichert werden (analog zur Arzneimittelliste). Dies ist insbesondere im Entlassmanagement eine Hilfestellung, wenn Folgeverordnungen auf Basis von Verordnungen aus dem Krankenhaus durch Hausärzte ausgestellt werden sollen. Auf Basis dieser Übersicht können Folgeverordnungen leicht erstellt werden, indem Inhalte aus alten Verordnungen in eine neue Verordnung übernommen werden können. Details zu diesem Anwendungsfall werden in diesem Dokument nicht beschrieben.
Abbildung 3: Beispielhafte Darstellung der verordneten Leistungen in dem TI-Demonstrator
Als Arzt möchte ich ...
Als MA einer Pflegeeinrichtung möchte ich ...
Als MA eines Kostenträgers möchte ich ...
Die benötigte Versorgung des Versicherten kann sich innerhalb des genehmigten Verordnungszeitraums durch verschiedene Umstände ändern (z. B. Änderung des Gesundheitszustands, der Therapie oder durch Krankenhausaufenthalte).
Fall 1: Es werden mehr/geänderte Leistungen als ursprünglich verordnet benötigt (z. B. 2x statt 1x tägliche Medikamentengabe). In diesem Fall muss eine neue Verordnung ausgestellt werden. Der Verordnungszeitraum der alten Verordnung wird nicht angepasst.
Fall 2: Es werden weniger Leistungen als ursprünglich verordnet benötigt (z. B. 1x statt 2x tägliche Medikamentengabe). In diesem Fall wird keine neue Verordnung ausgestellt und die bestehende Verordnung wird nicht angepasst. Die Krankenkasse und der Pflegedienst werden vom Verordnenden informiert. Der Pflegedienst leistet weniger und rechnet entsprechend auch weniger ab als ursprünglich verordnet.
Fall 3: Die Versorgung wird für einen bestimmten Zeitraum pausiert (z. B. Krankenhausaufenthalt). In diesem Fall wird keine neue Verordnung ausgestellt und die bestehende Verordnung wird nicht angepasst. Die Krankenkasse und der Pflegedienst werden vom Verordnenden informiert. Der Pflegedienst leistet in diesem Zeitraum nicht und nimmt die Versorgung dann erst nach der Entlassung aus dem Krankenhaus wieder auf (sofern keine Anpassung am Leistungsumfang durch die Krankenhausentlassung benötigt wird, ansonsten siehe Fall 1).
Aus diesem Anwendungsfall ergeben sich keine neuen oder zusätzlichen Anforderungen an den Verordnungsprozess. Es wird parallel zur Spezifikation der Anwendung HKP die Frage zu klären sein, wie die Information des Pflegedienstes durch den Verordnenden im Falle von Änderungen in den Fällen 2 und 3 erfolgen soll.
Die Löschrechte werden auch in Kapitel [8 Datensätze] in tabellarischer Form zusammengefasst.
In folgenden Fällen ist das Löschen einer Verordnung vorgesehen:
Der Pflegedienst und der Kostenträger dürfen die Verordnung hingegen nicht löschen.
In folgenden Fällen ist das Löschen eines Blankoverordnungsdatensatzes vorgesehen:
Der Arzt, der Kostenträger und auch der Pflegedienst dürfen den Blankoverordnungsdatensatz hingegen nicht vom Fachdienst löschen.
In folgenden Fällen ist das Löschen eines Datensatzes "Angaben zur Leistungserbringung des PD" vorgesehen:
Der Arzt, der Kostenträger und auch der Pflegedienst dürfen die Angaben zur Leistungserbringung hingegen nicht vom Fachdienst löschen.
Das Löschen von Korrekturanfragen wird in der Spezifikation ausgearbeitet und daher an dieser Stelle nicht weiter beschrieben.
Als Versicherter möchte ich ...
Als Arzt möchte ich ...
In bestimmten Fällen kann bei Versicherten der gesetzlichen Krankenkasse von dem üblichen Sachleistungsprinzip abgewichen werden. Folgende drei Sonderfälle sollen mit der Verordnung ebenfalls ermöglicht werden:
Bei allen drei Fällen werden die weiteren Prozesse zur Leistungsentscheidung und Erstattung außerhalb des Fachdienstes abgebildet und sind nicht Teil des Fachkonzepts (z. B. Einreichen der Rechnung). Auch bei Kostenträgern der gesetzlichen Unfallversicherung kann gemäß der [gemeinsamen Richtlinie] der Verbände der Unfallversicherungsträger über häusliche Krankenpflege vom üblichen Sachleistungsprinzip abgewichen werden. Die Prozesse verlaufen analog zu den oben beschriebenen Fällen Kostenerstattung nach § 37 Abs. 4 SGB V und persönliches Budget.
In folgendem Link werden die Anwendungsfälle im TI-Demonstrator dargestellt:
Versicherte sollen ab dem Ausstellungsdatum bis zum Ende des Verordnungszeitraums den Zugriff auf die Inhalte einer Verordnung auf folgenden Wegen an einen Leistungserbringer übergeben können:
Vor einer Zuweisung und Übernahme der Versorgungsleistung kann ein Pflegedienst zunächst prüfen, ob die Leistung erbracht werden kann. Nur wenn die Übernahme der Leistung möglich ist, akzeptiert der Leistungserbringer die Zuweisung.
Abbildung 4: Übersicht über den Einlöseprozess
Der Versicherte kann einen Pflegedienst berechtigen alle einlösbaren Verordnungen für HKP abzurufen. Hierfür muss ein PoPP-Token erzeugt werden. Wie dieser Token erzeugt werden kann, wird nicht in diesem Featuredokument beschrieben, sondern in der Spezifikation [PoPP-Service]. Grundsätzlich werden alle PoPP-Token vom Fachdienst akzeptiert, unabhängig davon wie dieser erzeugt wird (siehe PoPP-Use Cases aus Kapitel 2.2 des Dokuments [PoPP-Service]).
Insbesondere relevant in der Versorgung sind diese beiden Anwendungsfälle:
In folgendem Link wird der Anwendungsfall im TI-Demonstrator dargestellt:
Für diesen Einlöseweg benötigt der Versicherte zur Anmeldung eine eGK mit PIN oder eine G-ID sowie ein Frontend des Versicherten auf seinem Smartphone. Ein "Frontend der Versicherten" (kurz FdV) darf gemäß [§ 360 Abs. 10 SGB V] von der gematik oder den im Gesetz benannten Kostenträgern angeboten werden. In dem FdV werden nach Anmeldung des Nutzers alle Verordnungen angezeigt. Um die Verordnung bei einem Pflegedienst einzulösen, werden die Einträge der Pflegedienste aus dem Verzeichnisdienst der Telematikinfrastruktur in einer Suche wettbewerbsneutral angezeigt. Hierbei werden alle verfügbaren und relevanten Informationen der Pflegedienste angezeigt und der Versicherte hat die Möglichkeit nach bestimmten Kriterien zu filtern und die Einträge z. B. nach Entfernung zu sortieren. Um einen geeigneten Pflegedienst auszuwählen, sollen die Angaben der Zusatzqualifikation und der Zulassung dargestellt werden. Über weitere Informationen je Pflegedienst können die Einträge im VZD um sogenannte Mehrwertdaten erweitert werden. Hierfür sind verschiedene Optionen denkbar, die unabhängig von der Verordnung bewertet und umgesetzt werden. Beispiele hierfür wären die Nutzung des Self-Service-Portal des VZD über das Pflegeprimärsystem oder die automatische Anreicherung durch die Vertragsdatenbank des vdek. Auch eine geeignete Umsetzung und Pflege von Organisationsstrukturen von Pflegediensten innerhalb des VZDs ist für die Suche wichtig, wird jedoch nicht im Fachkonzept beschrieben.
Versicherte, die das FdV verwenden, können die Komfortfunktion "Stammpflegedienst" nutzen. Hierbei kann ein ambulanter Pflegedienst festgelegt werden, welcher Folgeverordnungen für Leistungen der häuslichen Krankenpflege automatisch zugewiesen bekommt. Die Wahl eines Stammpflegedienstes kann durch den Versicherten jederzeit beendet oder verändert werden. Der Versicherte muss durch diese Funktion nicht mehr aktiv werden und der Pflegedienst erhält sofort nach dem Ausstellen der Verordnung Zugriff darauf. Für Einzelfälle, bei denen ein Versicherter mehrere Verordnungen gleichzeitig ausgestellt bekommt, diese aber bei unterschiedlichen Pflegediensten einlösen möchte, ist diese Funktion nicht geeignet und eine manuelle Einlösung wird empfohlen.
In folgendem Link wird der Anwendungsfall im TI-Demonstrator dargestellt:
Die Versicherten haben gemäß [§ 360 Abs. 9 SGB V] einen gesetzlichen Anspruch auf einen Patientenausdruck zur Verordnung. Insbesondere bei Erstverordnungen und nicht-digital-affinen Versicherten stellt der Patientenausdruck sicher, dass die Verordnungsinhalte durch den Versicherten z. B. bei der Suche nach einem Pflegedienst abgelesen werden können. Das Layout der Verordnung wird in der technischen Anlage durch die KBV und den GKV-SV definiert. Er umfasst mindestens einen Datamatrix-Code, der die Zugangsinformationen zur Verordnung beinhaltet und eine Pflegeeinrichtung oder Kostenträger berechtigt die Verordnung einzusehen. Weiterhin sind die verordneten Leistungen darauf lesbar.
Es besteht der Wunsch, die Festlegung eines Stammpflegedienstes auch ohne FdV (siehe Einlöseweg 2) zu ermöglichen. Bei der Umsetzung dieses Einlösewegs sollen keine Aufwände für die Ärzte in der ambulanten Versorgung und die Ärzte in Krankenhäusern entstehen. Das Bundesministerium für Gesundheit prüft die Möglichkeiten zur Schaffung der notwendigen Rahmenbedingungen und wird gegebenenfalls in einem zukünftigen Gesetzgebungsverfahren dieses Thema einbringen. Im Kapitel 10 "Handlungsbedarf für den Gesetzgeber" wird das Thema daher aufgenommen.
Für angemeldete Nutzer des FdV gibt es die Möglichkeit bei bis zu drei Pflegediensten unverbindlich anzufragen, ob die Leistungen erbracht werden können. Das FdV soll verhindern, dass der gleiche Pflegedienst mehrfach angefragt werden kann. Der Versicherte erhält die Rückmeldung zur möglichen Übernahme der Leistung je angefragtem Pflegedienst in dem FdV und kann jederzeit entscheiden, die Verordnung einem Pflegedienst verbindlich zuzuweisen (unabhängig davon, ob alle Pflegedienste zuvor auf die Anfrage geantwortet haben). Die Antwort des Pflegedienstes ist eine Momentaufnahme und der Pflegedienst ist nicht an diese Antwort gebunden (wenn sich die Kapazität z. B. aufgrund anderer Anfragen geändert hat). Der Pflegedienst ist nicht verpflichtet auf die Anfrage zu antworten. Zur Bewertung der Anfrage erhält der Pflegedienst in dem Pflegeprimärsystem. Einsicht in alle Informationen der Verordnung (auch in beigefügte/angehängte Dokumente). Das Pflegeprimärsystem soll die Pflegefachpersonen dabei unterstützen die Anfragen mit wenigen Klicks zeitnah und ggf. auch automatisiert zu beantworten (z. B. "Alle Anfragen ablehnen"). Der Pflegedienst möchte in dem Pflegeprimärsystem sehen, ob sich der Versicherte zwischenzeitlich bereits für einen anderen Pflegedienst entschieden hat.
In folgenden Links werden die Anwendungsfälle im TI-Demonstrator dargestellt:
Um einen geeigneten Pflegedienst zu finden, kann sich der Versicherte an seinen Kostenträger wenden. Hierzu kann der Versicherte seinem Kostenträger (Sachleistungsprinzip) auf den vereinbarten Kommunikationskanäle die notwendigen Daten übermitteln. Indem er zum Beispiel ...
sodass der Kostenträger (Sachleistungsprinzip) die Verordnung vom Fachdienst herunterladen, einsehen und den Versicherten beraten kann bei der Suche nach einem Pflegedienst.
Folgende weitere Zwecke können neben der Beratung verfolgt werden:
Das aktive Ermöglichen eines Zugriffs auf die Verordnung in diesem Prozessschritt ändert den Status der Verordnung bzw. des Vorgangs nicht. Es wird durch den Fachdienst auch kein Ergebnis erfasst, sondern individuell entweder im Frontend des Versicherten (FdV) oder durch persönliches Beratungsgespräch mit dem Kostenträger agiert. Bei Verwendung des FdVs kann auch der TI-Messenger genutzt werden.
Bei Kostenträgern nach Kostenerstattungsprinzip (z. B. Private Krankenversicherung) kann durch den Versicherten eine Kostenzusage angefragt werden vor Erbringen der Leistung zu klären, ob die Kostenerstattung nach Einreichen der Belege erfolgen wird. Dazu wird die Möglichkeit geschaffen, die Verordnung als PDF/A3 im FdV des Versicherten bereitzustellen, sodass eine Weiterleitung des Dokuments an Kostenträger im Kostenerstattungsprinzip über etablierte digitale Serviceangebote ermöglicht wird. Der Versicherte hat hierbei immer die Möglichkeit einen Pflegedienst auszuwählen und die Stammdaten des Pflegedienstes an den Kostenträger zu übermitteln (egal ob die Verordnung dort bereits eingelöst wurde oder nicht). Sofern bei einer Blankoverordnung die Angaben durch den Pflegedienst bereitgestellt wurden, werden diese ebenfalls über diesen Weg dem Kostenträger zur Prüfung bereitgestellt.
In folgenden Links werden die Anwendungsfälle im TI-Demonstrator dargestellt:
Häufig übernehmen pflegende Angehörige oder gesetzliche Vertreter die Aufgaben des Versicherten, wenn dieser nicht selbst dazu in der Lage ist. In dem Konzept wird die Rolle des Vertreters vorgesehen, jedoch nicht definiert, wie das Vertretungsverhältnis eingerichtet werden kann. Dies wird in einer anwendungsübergreifenden Vertreterregelung für alle Anwendungen der Telematikinfrastruktur definiert. Sofern nicht anders ausgeführt, hat der Vertreter die gleichen Rechte wie der Versicherte selbst.
Als Versicherter möchte ich ...
Als MA in einem Pflegedienst möchte ich ...
Als verordnender Arzt möchte ich ...
Als MA eines Kostenträgers möchte ich ...
Bevor die Verordnung zur Leistungsentscheidung beim Kostenträger eingereicht werden kann, muss der vom Versicherten gewählte Pflegedienst eigene Angaben zur Leistungserbringung sowie zur Einrichtung in dem Datensatz "Angaben zur Leistungserbringung des Pflegedienstes" erfassen und mit der fortgeschrittenen Signatur der SMC-B signieren. Hierbei können GPOS-Daten optional ergänzt werden. Das Pflegeprimärsystem (PPS) unterstützt die Pflegefachpersonen bei der Befüllung des Datensatzes und kann etwa Übertragungen aus dem Verordnungsdatensatz anbieten sowie gleichbleibende Stammdaten zum Pflegedienst automatisch ergänzen. Sobald dieser Datensatz durch die Pflegeeinrichtung signiert und gespeichert worden ist, erhält der Kostenträger Zugriff auf den Vorgang und kann mit der Prüfung starten. Sofern im Verordnungsdatensatz mindestens eine Leistung vom Arzt als Blanko-Leistung markiert worden ist, muss zuvor ein Blankoverordnungsdatensatz durch die Pflegeeinrichtung auf den Fachdienst abgelegt worden sein.
Für Kostenträger mit dem Sachleistungsprinzip ist dieser Schritt verpflichtend. Bei Kostenträgern mit dem Kostenerstattungsprinzip ist er hingegen optional.
In folgendem Link wird der Anwendungsfall im TI-Demonstrator dargestellt:
Gemäß [§ 37 Abs. 8 SGB V] können Pflegefachpersonen, die die in den [Rahmenempfehlungen nach § 132a Abs. 1 SGB V] genannten Anforderungen erfüllen, innerhalb des vertragsärztlich festgestellten Verordnungsrahmens, für die im Leistungsverzeichnis des GB-A gekennzeichneten Leistungen selbst über die erforderliche Häufigkeit und Dauer bestimmen. Hierfür muss die Angabe "Dauer und Häufigkeit wird durch Pflegefachperson festgelegt" vom Verordnenden in der Verordnung ausgewählt worden sein.
Die qualifizierte Pflegefachperson dokumentiert für diese Leistungen die Dauer und Häufigkeit in einem separaten Datensatz und signiert diesen mit der fortgeschrittenen Signatur der SMC-B. Die Pflegefachperson muss im Datensatz über die Beschäftigtennummer erkennbar sein. Das Pflegeprimärsystem soll sicherstellen, dass nur Pflegefachpersonen mit der entsprechenden Kompetenz/Qualifikation die Daten zur Verordnung freigeben können.
Nachdem die Dauer und Häufigkeit durch die Pflegefachperson erfasst worden sind, stehen diese Informationen dem verordnenden Arzt in seinem PVS zur Verfügung. Die Pflicht sich regelmäßig mit dem Verordnenden abzustimmen (gemäß § 7 Absatz 4a der HKP-RL) ist hiervon unberührt. Auch der Versicherte kann über das FdV die Informationen über das FdV einsehen. Dem Kostenträger (Sachleistungsprinzip) stehen die Informationen im Rahmen der Leistungsentscheidung ebenfalls zur Verfügung. Der Kostenträger (Sachleistungsprinzip) erhält Zugriff auf diesen Datensatz, um ihn im Rahmen der Leistungsentscheidung einzusehen, sobald der Pflegedienst den Datensatz "Angaben zur Leistungserbringung des PD" an den Fachdienst übertragen hat. Dem Kostenträger (Kostenerstattungsprinzip) können die Angaben als PDF/A3 durch den Versicherten bereitgestellt werden.
In folgendem Link wird der Anwendungsfall im TI-Demonstrator dargestellt:
Als Arzt möchte ich ...
Als MA einer Pflegeeinrichtung möchte ich ...
Als Mitarbeiter eines Kostenträgers im Sachleistungsprinzip und auch als Mitarbeiter eines Kostenträgers im Kostenerstattungsprinzip möchte ich ...
Als Versicherter möchte ich ...
Für gesetzlich Versicherte muss ein Prozess zur Leistungsentscheidung zwingend durchlaufen werden. Der Prozess zur Leistungsentscheidung wird vom Pflegedienst über sein Pflegeprimärsystem gestartet. Voraussetzung hierfür ist, dass die Verordnung dem Pflegedienst zugewiesen und alle Angaben des Pflegedienstes erfasst und mit der SMC-B signiert worden ist. Die Regelungen zur vorläufigen Kostenübernahme entsprechend § 6 Abs. 5 HKP-RL sind zu beachten.
Der Kostenträger, der im Verordnungsdatensatz durch den Arzt erfasst wurde, erhält somit über das Kostenträgerverwaltungssystem (KTRVS) Zugriff auf den Vorgang, bzw. genauer auf den Verordnungsdatensatz, die Angaben zur Leistungserbringung des PD, den Blankoverordnungsdatensatz und begleitende Unterlagen, die vom Arzt oder von der Pflegefachperson zu dieser Verordnung erfasst worden sind. Sollte der Kostenträger feststellen, dass er unzuständig ist, ist das Vorgehen wie in Kapitel [6.9 Unzuständigkeit der Krankenkasse (nur GKV und DGUV)] zu beachten. Sobald die Leistungsentscheidung gestartet worden ist, sind die Angaben des Pflegedienstes nicht mehr veränderbar. Der Kostenträger kann zu jeder beantragten Leistungsposition im KTRVS erfassen, ob diese genehmigt, teilgenehmigt (also in geringerem Umfang genehmigt) oder abgelehnt wird. Bei Fehlern in der Verordnung, die durch den Verordnenden zu prüfen/korrigieren sind, wird ein Korrekturprozess angestoßen. Ebenso kann eine Korrektur des Blankoverordnungsdatensatzes bei dem Pflegedienst angefragt werden (siehe Kapitel [6.8 Korrekturprozesse]. Sollten für die Prüfung Inhalte der bereitgestellten Datensätze oder Unterlagen an Dritte weitergegeben werden müssen (z. B. Medizinischer Dienst) erfolgt dies außerhalb der TI und wird durch das vorliegende Konzept nicht definiert. Hat der Kostenträger den Vorgang vollständig geprüft, wird die Entscheidung zur Genehmigung, Ablehnung, Teilgenehmigung für jede einzelne Leistung über das KTRVS im Fachdienst als Entscheidungsdatensatz erfasst und mit der SMC-B signiert. Das Ergebnis des Antragsprozesses kann durch den Kostenträger solange verändert werden (z. B. im Rahmen eines Widerspruchsverfahrens), bis die Verordnung aus dem Fachdienst gelöscht wurde. Der Kostenträger kann für den Arzt, den Versicherten und den Pflegedienst individuelle Begründungen zu der Entscheidung eintragen. Der Versicherte wird über das FdV über den Abschluss der Prüfung informiert und kann die Entscheidung einsehen. Dies ersetzt nicht die Bekanntgabe des Verwaltungsaktes nach § 35 SGB X. Die Arztpraxis und der ambulante Pflegedienst können die Entscheidung über die eigenen Primärsysteme ebenfalls einsehen und werden über das Update informiert. Ergänzende Kommunikationswege zum Versicherten (Kostenträger-Service-App, TI-Messenger), Arzt oder Pflegedienst können unabhängig davon zusätzlich von den Kostenträgern genutzt werden, ebenso ergeht wie bislang eine schriftliche oder ggf. elektronische Information an die Versicherten.
In folgenden Links werden die Anwendungsfälle im TI-Demonstrator dargestellt:
Neu bei Privatversicherten und Beihilfeberechtigten, deren Kostenträger grundsätzlich dem Kostenerstattungsprinzip zuzuordnen sind (siehe Kapitel Leistungsgewährungsprinzipien), kann ein Genehmigungsverfahren je nach Tarif optional oder verpflichtend erfolgen. Der Versicherte kann ein PDF-Dokument mit den verfügbaren Datensätzen (Verordnungsdatensatz, ggf. Blankoverordnungsdatensatz und mindestens im Basistarif mit einem Eintrag des gewählten Pflegedienstes aus dem Verzeichnisdienst) aus dem FdV heraus exportieren (Kostenerstattungsanfrage-Bundle) und bei seinen Kostenträgern über die jeweilige App vorlegen. Das Genehmigungsverfahren des Kostenträgers hat keine Schnittstelle zum Fachdienst in der TI. Die Information an den Versicherten zum Ergebnis des Leistungsentscheidung erfolgt daher auch nicht über den Fachdienst, sondern über andere Kommunikationswege zwischen dem Versicherten und dem Kostenträger. Sofern eine Ablehnung erfolgt, obliegt es dem Versicherten als Vertragspartner des Pflegedienstes, den Pflegedienst selbst zu informieren.
Sofern der Verordnungsdatensatz keine Option zur Ergänzung durch den Pflegedienst vorsieht (Angaben in einer Blankoverordnung also ausgeschlossen sind), kann direkt nach dem Verordnen durch die Arztpraxis die Bereitstellung des exportierten PDFs zur Genehmigungsprüfung erfolgen. Ist hingegen die Möglichkeit der Angabe von Dauer und Häufigkeit durch die Pflegefachperson in der ärztlichen Verordnung vorgesehen, so ist die Blankoverordnung inkl. Verordnungsdatensatz nach Zuweisung an den Pflegedienst zunächst zu erstellen und kann danach vom Privatversicherten als Kostenerstattungsanfrage-Bundle dem eigenen Kostenträger bereitgestellt werden.
Das Kostenerstattungsanfrage-Bundle, der im PDF bereitgestellten Inhalte, lässt sich wie folgt zusammenfassen:
Das PDF enthält eine menschenlesbare Darstellung, welche von dem PKV-Verband festzulegen ist sowie maschinenlesbare strukturierte Daten.
In folgenden Links werden die Anwendungsfälle im TI-Demonstrator dargestellt:
Als Arzt möchte ich ...
Als Mitarbeiter einer Pflegeeinrichtung möchte ich ...
Als Versicherter möchte ich ...
Als Mitarbeiter eines Kostenträgers im Sachleistungsprinzip möchte ich ...
Als Mitarbeiter eines Kostenträgers im Kostenerstattungsprinzip möchte ich ...
Disclaimer: Die Partner des BMV-Ä vereinbaren ein Korrekturverfahren. Die Details werden im Rahmen der Spezifikation erarbeitet.
Im Rahmen der Verordnung häuslicher Krankenpflege kann es nach der Ausstellung einer Verordnung erforderlich werden, inhaltliche Korrekturen oder Ergänzungen vorzunehmen. Der Korrekturprozess stellt sicher, dass alle beteiligten Akteure – insbesondere Ärzte, Pflegedienste und Kostenträger, aber auch der Versicherte selbst – stets Zugriff auf die aktuellste und gültige Version der Verordnung haben. Zudem wird gewährleistet, dass die Historie der Änderungen transparent und nachvollziehbar bleibt und die Korrekturen in einem strukturierten und einheitlichen Vorgehen erfolgen.
Klarheit zu (Un-)Gültigkeit der (Blanko-)Verordnung bzw. Korrekturanfrage
Schnelle und enge Zusammenarbeit der Akteure wird ermöglicht
Transparenz für alle Akteure, sobald diese erstmalig in den Vorgang involviert werden
Inhaltliche Klarheit
Prozessuale Klarheit / Verantwortungsklarheit
Flexibilität für Leistungserbringer und Kostenträger
Einheitliche Behandlung der Datensätze und Versionen eines Vorgangs am Fachdienst
Es gibt folgende Unterschiede im Falle der Kostenträger nach dem Kostenerstattungsprinzip (z. B. für Privatversicherte und Beihilfeberechtigte): Bei Korrekturanfragen durch den Kostenträger organisiert der Versicherte selbst die notwendigen Anpassungen der Verordnung beim Arzt. Dies erfolgt nicht über den zuvor genannten Prozess, da weder diese Kostenträger Zugriff auf den Fachdienst haben noch der Versicherte einen konkreten Korrekturvorschlag erstellen kann. Der Versicherte wendet sich daher auf direktem Weg an den Verordnenden (außerhalb dieser TI-Anwendung) und dieser löscht die Verordnung bei Bedarf und stellt eine neue Verordnung aus. Hier muss berücksichtigt werden, dass dies nur möglich ist, solange die Verordnung nicht von einem Pflegedienst abgerufen und die Zuweisung bestätigt wurde. Hat ein Pflegedienst die Zuweisung bereits angenommen, kann der Pflegedienst auch in diesen Fällen die Korrekturanfrage an den verordnenden Arzt übermitteln.
Nur der Akteur, der als nächstes im Korrekturprozess handeln muss, sollte auch aktiv benachrichtigt werden. Alle am Prozess beteiligten können den Status des Korrekturverfahren einsehen. Sofern Art und/oder Umfang der verordneten Leistungen angepasst wurden, soll die Pflegesoftware einen Hinweis ausgeben.
Als Arzt möchte ich
Als Mitarbeiter einer Pflegeeinrichtung möchte ich ...
Als MA eines Kostenträgers möchte ich ...
Als Versicherter möchte ich ...
In seltenen Fällen kann es dazu kommen, dass bei der Verordnung ein Kostenträger vom verordnenden Arzt erfasst wird, der nicht für den Versicherten zuständig ist (z. B. bei einem Kassenwechsel). In diesen Fällen kann entweder eine neue Verordnung mit dem korrekten Kostenträger ausgestellt werden (insbesondere bei Wechsel von PKV zu GKV oder GKV zu DGUV), oder die Verordnung an den zuständigen Kostenträger (innerhalb der GKV oder innerhalb der DGUV) weitergeleitet werden. Es wird in zwei Fälle unterschieden:
Fall 1: Die Zuständigkeit der Krankenkasse endet vor dem Verordnungszeitraum oder hat nie vorgelegen.
Ergebnis: Die abgebende Krankenkasse lehnt den Vorgang im Status Antragsprüfung ab und markiert den Vorgang als "Unzuständigkeit". Der Versicherte und der Pflegedienst werden über die Ablehnung informiert und darüber, dass die Zugriffsinformationen auf den Vorgang der neuen Krankenkasse zur Verfügung gestellt wurden. Eine abgebende Krankenkasse muss die Zugriffsinformationen auf die Verordnungsdaten mehrfach an eine aufnehmende Krankenkasse übermitteln können. Die aufnehmende Krankenkasse führt ein eigenes Verwaltungsverfahren durch. Die Vorgangsdaten können von der neuen Krankenkasse eingesehen werden, ohne dass die alte IK im Verordnungsdatensatz geändert wird.
Empfehlung: Für den Fall 1 empfiehlt die gematik den gesetzlichen Krankenkassen, dass die abgebende Krankenkasse die Zugriffsinformationen inkl. AccessCode des Vorgangs der neuen Krankenkasse zur Verfügung stellt. Diese Regelung stellt jedoch kein Präjudiz für weitere Verordnungstypen (z. B. Hilfsmittel etc.) dar. In einer weiteren Ausbaustufe der elektronischen Verordnung wird eine Weiterleitungsmöglichkeit innerhalb des Fachdienstes geprüft.
Fall 2: Die Mitgliedschaft endet im Laufe des Verordnungszeitraums.
Ergebnis: Die abgebende Krankenkasse erlässt eine Änderung zum vorherigen Verwaltungsakt und kürzt den Zeitraum im Entscheidungsdatensatz entsprechend auf das Ende der Mitgliedschaft. Für den Zeitraum bei der neuen Krankenkasse muss eine neue Verordnung erstellt werden.
Als MA eines Kostenträgers möchte ich ...
Als Versicherter möchte ich ...
Es ist vertraglich geregelt, dass Pflegedienste regelmäßig Leistungsnachweise über die erbrachten Leistungen in der Abrechnung an die Kasse übermittelt werden. Die Regelung dessen obliegt dem GKV-SV, weshalb im vorliegenden Fachkonzept keine Vorgaben zu diesem Verfahren gemacht werden.
Besonderheiten für das Kostenerstattungsprinzip: Für Privatversicherte sind Leistungsnachweise des Pflegedienstes eine Anlage der Rechnung, die beim Einreichen zur Kostenerstattung vom Versicherten bestätigt werden können oder gemäß AGB nur korrekt eingereicht werden dürfen. Sobald über die Anwendung "Digitale Patientenrechnung" auch verordnete Leistungen der Pflege abgerechnet werden können, ist eine Bereitstellung der elektronischen Verordnung, des elektronischen Leistungsnachweises (bestehend aus dem Datensatz der Leistungsdokumentation) und der elektronischen Rechnung als Teil der Anwendung "Digitale Patientenrechnung" zu betrachten. Bis dahin soll ausschließlich die (Blanko-)Verordnung als exportierbares PDF/A3 bereitgestellt werden, denn eine Bereitstellung des E-Leistungsnachweises unabhängig von der Digitalen Patientenrechnung erfolgt nicht. Leistungsnachweis und Rechnungen werden daher in Stufe 1 wie bislang genutzt (Papierrechnung mit Leistungsnachweis auf Papier als Anhang) und können in der App der PKV gescannt und dem PDF/A3 der (Blanko-)Verordnung zugeordnet werden.
Grundsätzlich ist es denkbar in weiteren Ausbaustufen der elektronischen Verordnung häuslicher Krankenpflege die Leistungsnachweise durch Mittel der Telematikinfrastruktur vom Versicherten bestätigen zu lassen (z. B. über das FdV oder das Erzeugen eines PoPP-Token auf dem Smartphone der Pflegefachperson). Eine hierfür notwendige Anpassung des PoPP-Token zur Sicherstellung der Fälschungssicherheit der Nachweise, wird im Rahmen der Weiterentwicklung des PoPP-Dienstes bewertet.
Bei verordneter chronischer Wundversorgung kann der Fall eintreten, dass ein nicht-spezialisierter Pflegedienst die Verordnung vom Versicherten erhält, mit der Leistungserbringung beginnt und die Verordnung zur Leistungsentscheidung einreicht. Auch wenn bereits eine Genehmigung ausgesprochen wurde, kann der Kostenträger innerhalb des laufenden Genehmigungszeitraums mit einem Vorlauf von mindestens einer Woche dem Versicherten einen spezialisierten Leistungserbringer benennen, der die Versorgung übernehmen soll. (siehe § 6 Abs. 17 der Rahmenempfehlung zur häuslichen Krankenpflege)
Dieser Sonderfall wird in der ersten Ausbaustufe der elektronischen Verordnung häuslicher Krankenpflege aufgrund der geringen Fallzahlen nicht gesondert abgebildet. Kostenträger, Pflegedienste und Versicherter müssen sich im Einzelfall einigen und eine Lösung finden.
Besonderheiten für das Kostenerstattungsprinzip: Wenn der z. B. Privatversicherte den Pflegedienst innerhalb des Verordnungszeitraums wechseln möchte, muss die Verordnung vom Pflegedienst an den Versicherten zurückgegeben werden. Danach kann die Verordnung vom Versicherten bei einem anderen Pflegedienst eingelöst werden. Alternativ kann eine neue Verordnung vom Arzt ausgestellt werden.
Die Abrechnung erfolgt außerhalb der Fachanwendung. Die Abrechnung erfolgt zwischen Pflegedienst und Kostenträger, ggf. unter Einbindung eines Abrechnungsdienstleisters. Durch das Ergebnis der Antragsprüfung hat der Pflegedienst bereits eine Rückmeldung über den Umfang der erstattbaren Leistung und ggf. Genehmigungskennziffern, die zu nutzen sind, enthalten. Verordnung, Blankoverordnung, Leistungsnachweise und notwendige Rechnungsdaten nach Vorgabe der Richtlinien gemäß § 302 SGB V liegen somit vor.
Die Abrechnung erfolgt für Privatversicherte und Beihilfeberechtigte außerhalb der Fachanwendung.
Der Pflegedienst stellt in einer ersten Stufe eine Rechnung inkl. Anlage zum Leistungsnachweis an den Versicherten und dieser verauslagt die Kosten. Zwecks Kostenerstattung stellt der Versicherte die Rechnung samt Anlage (beides in Papierform) zusammen mit den Zugriffsinformationen zum Vorgang oder einem exportierten PDF/A3 dem oder den eigenen Kostenträger(n) bereit, sofern nicht im Rahmen der Vorabgenehmigung der Zugriff auf den Vorgang oder das PDF/A3 bereits gewährt wurde. Da Papierform und elektronische Zugriffsinformation/PDF/A3 einen Medienbruch bedeuten und eine Zuordnung durch den Versicherten erfordern, ist dies eine temporäre Lösung.
Sobald die Fachanwendung "Digitale Patientenrechnung" in einer zukünftigen Ausbaustufe der Spezifikation die Möglichkeit geschaffen haben wird elektronische Rechnungen der Pflegedienste entgegenzunehmen, soll auch die Bereitstellung der Daten der Verordnung, der Blankoverordnung sowie der Leistungsnachweise ermöglicht werden und Teil ebendieser Digitalen Patientenrechnung sein. Dies erfordert Zugriffe der Fachanwendung Digitale Patientenrechnung auf den Fachdienst E-Rezept sowie entsprechende Vorgaben an die Anbieter von Pflegeprimärsystemen.
Für die Abbildung der Anwendungsfälle wird das folgende fachliche Statusmodell verwendet. Die Bezeichnungen der Status finden sich auch in der Darstellung des SOLL-Prozesses im Kapitel [14.1 Fachlicher Soll-Prozess] wieder.
Abbildung 5: Fachliches Statusmodell
Die Verordnung wird von der Arztpraxis erstellt (siehe Kapitel [6.1 Verordnungsprozess]).
Tabelle 4 : Erläuterungen zum fachlichen Statusmodell - Status 'initialisiert'
| Status | initialisiert |
|---|---|
| Definition | Zum Anlegen einer Verordnung wird initial eine Verordnungs-ID vom Fachdienst abgerufen, sodass diese im Datensatz der Verordnung mit signiert werden kann.
Die verordnende Arztpraxis ergänzt nun im nächsten Schritt im PVS die Inhalte der Verordnung, prüft diese und muss die Verordnung signieren, bevor der Datensatz inkl. Signatur an den Fachdienst übertragen wird, woraus der Übergang zum Status "offen" resultiert. Das Einstellen der signierten Verordnung auf dem Fachdienst muss innerhalb von 10 Tagen nach dem initialen Erstellen im Fachdienst erfolgen. Anderenfalls wird die Verordnung (Status "initialisiert") auf dem Fachdienst automatisch gelöscht. Nach dem Löschen kann keine Verordnung mit der Verordnungs-ID mehr eingestellt werden. Das Initialisieren müsste erneut erfolgen. Anwendungsbeispiel 1: Im Behandlungsgespräch erstellt der Arzt eine Verordnung, prüft und signiert diese, sodass eine Übertragung an den Fachdienst erfolgen kann. Anwendungsbeispiel 2: Bereitet (initialisiert) ein Mitarbeiter in der Arztpraxis eine Verordnung am Freitagnachmittag vor, hat die Arztpraxis 10 Tage Zeit diese zu prüfen und zu signieren. Die Arbeitsteilung soll wie beim E-Rezept für Arzneimittel möglich sein. |
| Vorbedingung | Die Arztpraxis ist mit der Telematikinfrastruktur verbunden.
Die Berechtigung der Praxis zum Zugriff wurde anhand einer der folgenden Object Identifier (OID) geprüft: - oid_praxis_arzt - oid_krankenhaus - oid_psychotherapeut - oid_ps_psychotherapeut - oid_kuj_psychotherapeut Übersicht OIDs für Institutionstypen siehe Festlegung von OIDs [gemSpec_OID]. |
| Nachfolge | AL1 Wird eine initialisierte Verordnung nicht innerhalb von 10 Tagen befüllt, signiert und erfolgreich an den Fachdienst übertragen, so wird die Verordnung gelöscht → Status "gelöscht".
ML1 Aktiv LÖSCHEN: Wird eine initialisierte Verordnung von Mitarbeitenden der Praxis gelöscht, so ändert sich am Fachdienst der Status in "gelöscht". 1 Verordnung erstellen, signieren, übertragen: Wird die initialisierte Verordnung im PVS befüllt, signiert und erfolgreich an den Fachdienst übertragen, so erfolgt eine Aktivierung der Verordnung im Fachdienst und der Status des Vorgangs wechselt zu "offen". |
| Zugriffs-berechtigung | Nur Mitarbeiter der Arztpraxis haben Zugriff auf die Verordnung am Fachdienst. |
Die Verordnung kann für die Anfrage der Verfügbarkeit bei einem Pflegedienst und die Beratung durch den Kostenträger genutzt werden, u.a. für Hilfe bei der Suche nach einem Pflegedienst, Vereinbarungen zu persönlichem Budget oder Wahl der Kostenerstattung (Anwendungsfälle der GKV).
Privatversicherte können eine Kostenübernahme beim Kostenträger anfragen.
Tabelle 5 : Erläuterungen zum fachlichen Statusmodell - Status 'offen'
| Status | offen |
|---|---|
| Definition | Die Verordnung kann vom Versicherten per FdV abgerufen werden.
Die Zugriffsinformationen auf die Verordnung können vom Versicherten an einen oder mehrere Pflegedienste zum Zweck "Lese Verordnung" gegeben werden. Der lesende Zugriff eines Pflegedienstes mit Hilfe der übergebenen Zugriffsinformationen ändert den Status nicht. Die Zugriffsinformationen der Verordnung können vom Versicherten an einen Pflegedienst zum Zweck "Zuweisung der Verordnung" gegeben werden. Nach Zugriff des Pflegedienstes mit Hilfe der übergebenen Zugriffsinformationen kann der Pflegedienst den Status in "zugewiesen" ändern (Auftrag annehmen/bestätigen). Die Zugriffsinformationen der Verordnung können vom Versicherten dem Kostenträger zur Verfügung gestellt werden und den Zugriff ermöglichen zwecks Beratung zur Verordnung und der Leistungserbringerauswahl. Der lesende Zugriff eines Kostenträgers mit Hilfe der übergebenen Zugriffsinformationen ändert den Status nicht. [6.4 Sonderfälle der Kostenerstattung]: Bei Wahl der Kostenerstattung nach §13 SGB V werden die Zugriffsinformationen der Verordnung direkt und automatisch der Krankenkasse bereitgestellt nach erfolgreicher Bereitstellung der Verordnung am Fachdienst. In Fällen der Kostenerstattung nach §37 Abs. 4 SGB V oder persönlichem Budget (beides Ausnahmen vom Sachleistungsprinzip) kann der Vorgang im Zuge der Beratung in den Status Antragsprüfung überführt werden. Besonderheit PKV: Die Verordnungsinformationen (ohne Signatur) KÖNNEN vom Versicherten an die Kostenträger (Kostenerstattungsprinzip), z. B. eine private Krankenversicherung zwecks Anfrage der Kostenübernahme als PDF/A3 über die FdV bereitgestellt werden da kein Fachdienstzugriff der privaten Krankenversicherung oder Beihilfe besteht. Die Verordnung kann von Mitarbeitern der verordnenden Arztpraxis oder dem Versicherten per FdV als gelöscht markiert werden. Die Verordnung wechselt dann in den Status "gelöscht". Die Verordnung kann von Mitarbeitern der verordnenden Arztpraxis korrigiert werden. Dabei wird eine neue Version erzeugt. Die Verordnung verbleibt im Status "offen". |
| Vorbedingung | 1 Nach Befüllen, Signieren und erfolgreichem Hochladen der Verordnung auf den Fachdienst wird die Verordnung am Fachdienst aktiviert und erhält den Status "offen".
3 Weil die Verordnung zurück in den Status offen gestellt wird vom Pflegedienst, wird der Status auf "offen" geändert. Beispiel: Wenn eine Versorgung doch nicht übernommen werden kann, so wird der Status von "zugewiesen" zurück auf "offen" geändert und die Zuordnung des Pflegedienstes erlischt. |
| Nachfolge | AP1 Stellt ein Versicherter einen Antrag auf Kostenerstattung nach § 37 Abs. 4 SGB V oder persönliches Budget wird der Vorgang dem Kostenträger zur Leistungsentscheidung übergeben → Status "Antragsprüfung".
ML2 LÖSCHEN durch die verordnende Arztpraxis z. B. aufgrund Irrtum und in Rücksprache mit dem Versicherten → Status "gelöscht". ML2 LÖSCHEN durch den Versicherten → Status "gelöscht". Die Bereitstellung der Zugriffsinformationen auf den Vorgang am Fachdienst an Pflegedienste zum Zweck des LESENs der Inhalte der Verordnung führen nicht zur Änderung des Status (Claim wie bei Apotheken). 2 Die Bereitstellung der Zugriffsinformationen auf die Verordnung an Pflegedienste zum Zweck des ZUWEISENs der Verordnung kann vom Pflegedienst zur aktiven Änderung des Status (Claim wie bei Apotheken) in einem bewussten weiteren Schritt erfolgen → Status "zugewiesen". AA1 Findet keine Zuweisung bzw. kein Wechsel des Status in "zugewiesen" statt, wird der Vorgang nach Ablauf des Verordnungszeitraums automatisch vom Fachdienst in den Status "abgeschlossen" versetzt. 4 Im Zuge der Bearbeitung der [6.4 Sonderfälle der Kostenerstattung] durch Mitarbeiter des Kostenträgers kann der Vorgang auf "abgeschlossen" gesetzt werden. |
| Zugriffs-berechtigung | Versicherte haben Zugriff auf die Verordnung am Fachdienst.
Nach Bereitstellung der Zugriffsinforma-tionen auf die Verordnung kann auch der Kostenträger die Inhalte des Vorgangs einsehen → Beratung, persönliches Budget, Wahl der Kostenerstattung. Nach Bereitstellung der Zugriffsinformationen auf die Verordnung können Pflegedienste die Inhalte der Verordnung einsehen. Verordnende können den Status einsehen. |
Der Versicherte hat sich für einen Pflegedienst entschieden und der Pflegedienst hat die Zuweisung akzeptiert.
Pflegedienste erfassen ggf. die Blankoverordnungsangaben und die Daten des Pflegedienstes bevor die Antragstellung ggb. dem Kostenträger erfolgen kann.
Tabelle 6 : Erläuterungen zum fachlichen Statusmodell - Status 'zugewiesen'
| Status | zugewiesen |
|---|---|
| Definition | Die Verordnung ist einem Pflegedienst zugeordnet, d.h. ein eindeutiges Merkmal (Telematik-ID) des Pflegedienstes ist der Verordnung am Fachdienst zugeordnet. Die Verordnung kann nicht mehr von einem weiteren Pflegedienst abgerufen werden.
Im Status „zugewiesen“ kann durch den Versicherten mit Bereitstellung der Zugriffsinformationen dem Kostenträger ein Zugriff ermöglicht werden zwecks Beratung zur Verordnung / Leistungserbringerauswahl / []. Dies ändert den Status nicht. Die Verordnung kann vom Pflegedienst zurück in den Status "offen" gestellt werden, sofern die Versorgung des Versicherten nicht übernommen wird. Die Besonderheit für Privatversicherte zur Bereitstellung der Verordnungsinformationen ohne Signatur zwecks Anfrage der Kostenübernahme als PDF/A3 besteht ebenso wie im Status "offen". Die Leistungserbringerdaten (Telematik-ID) müssen dem Vorgang zugeordnet sein und lassen sich mit dem Verzeichnisdienst auflösen. Die Verordnung kann vom Pflegedienst zwecks Korrektur an die verordnende Arztpraxis übergeben werden, dabei bleibt der Pflegedienst selbst aber zugeordnet. Der Vorgang kann vom Pflegedienst nach Erfassung der Angaben zur Leistungserbringung des PD und ggf. Erfassung der Blankoverordnungsinformationen dem Kostenträger (Sachleistungsprinzip) zur Leistungsentscheidung übergeben werden. |
| Vorbedingung | 2 Die Zugriffsinformationen der Verordnung wurden vom Versicherten an einen Pflegedienst zum Zweck des Zuweisens bereitgestellt. Nach Zugriff des Pflegedienstes mit Hilfe der übergebenen Zugriffsinformationen (siehe Kapitel [6.5 Anwendungsfälle im Einlöseprozess]) hat dieser den Auftrag für die Verordnung angenommen und selbst aktiv den Status in "zugewiesen" geändert.
K2 Nach einer Korrekturanfrage an den Verordnenden wurde die Anfrage beantwortet und der Status in "zugewiesen" geändert. K3 Der anfragende Pflegedienst kann die Korrekturanfrage zurückziehen. |
| Nachfolge | AP3 Nach Erfassung der Angaben zur Leistungserbringung des PD und ggf. Erfassung der Blankoverordnungsinformationen wird der Vorgang dem Kostenträger (im Sachleistungsprinzip) zur Leistungsentscheidung übergeben → Status "Antragsprüfung".
Besonderheit PKV-Basistarif: Nach Erfassung der Daten zum Leistungserbringer und ggf. Erfassung der Blankoverordnungsinformationen überträgt der Versicherte mittels FdV die Angaben als PDF/A3 an den privaten Kostenträger. Es erfolgt kein Statuswechsel. 3 Die Verordnung kann vom Pflegedienst zurück in den Status "offen" gestellt werden. K1 Die Verordnung kann vom Pflegedienst zwecks Korrekturanfrage mit einem Korrekturvorschlag an die verordnende Praxis übergeben werden → "Korrekturanfrage". AA2 Findet keine weitere Verarbeitung nach der Zuweisung statt, wird nach Ende des Verordnungszeitraums der Vorgang automatisch in den Status "abgeschlossen" versetzt. |
| Zugriffs-berechtigung | Versicherte haben Zugriff auf die Verordnung am Fachdienst und können den Status einsehen, jedoch selbst keine Änderung der Zuweisung vornehmen.
Der zugewiesene Pflegedienst kann die Inhalte der Verordnung einsehen. Der Kostenträger (Sachleistungsprinzip und auch Kostenerstattungsprinzip) hat keinen Zugriff. |
Der Kostenträger prüft die bereitgestellten Informationen und wendet sich mit Nachfragen oder Korrekturbedarf an die verordnende Praxis oder den Pflegedienst.
Tabelle 7 : Erläuterungen zum fachlichen Statusmodell - Status 'Antragsprüfung'
| Status | Antragsprüfung |
|---|---|
| Definition | Die Zugriffsinformationen auf die Datensätze mit den Verordnungsdaten, den Angaben des Pflegedienstes sowie ggf. die Daten der Blankoverordnung liegen dem Kostenträger vor.
Der Status der Verordnung bzw. der Leistungsentscheidung kann von dem Pflegedienst, dem Verordnenden und Versicherten abgerufen werden. Die Verordnung kann vom Kostenträger nicht gelöscht werden. Das Ergebnis der Antragsprüfung wird vom Kostenträger als Datensatz im Fachdienst hinterlegt und enthält mind. die Angabe „nicht genehmigt mit vorläufiger Kostenzusage“, „nicht genehmigt ohne vorläufige Kostenzusage“, „Teilweise genehmigt“, „Genehmigt“ oder „Unzuständig“. nicht relevant für PKV bzw. Kostenträger im Kostenerstattungsprinzip. |
| Vorbedingung | AP1 Stellt ein Versicherter einen Antrag auf Kostenerstattung nach § 37 Abs. 4 SGB V oder persönliches Budget (beides Ausnahmen vom Sachleistungsprinzip) wird der Vorgang dem Kostenträger zur Leistungsentscheidung übergeben → Statusübergang "offen" zu "Antragsprüfung"
AP3 Nach Erfassung der Angaben zur Leistungserbringung des PD und ggf. Erfassung der Blankoverordnungsinformationen wurde der Vorgang vom Pflegedienst dem Kostenträger zur Leistungsentscheidung übergeben. Ein Behandlungsplan pHKP kann für den Prozess der Leistungsentscheidung als begleitendes Dokument ebenso bereitgestellt werden. → Statusübergang "zugewiesen" zu "Antragsprüfung". K5 Nach einer Korrekturanfrage an den Verordnenden oder den Pflegedienst wurde eine neue Version der Verordnung oder Blankoverordnung erstellt und der Status in "Antragsprüfung" geändert. K6 Der Anfragende (Kostenträger im Sachleistungsprinzip) kann die Korrekturanfrage zurückziehen. |
| Nachfolge | K4 Der Kostenträger kann den Vorgang in den Status „Korrekturanfrage“ ändern und einen Korrekturvorschlag bereitstellen zwecks:
Anpassung der Verordnung durch den Verordnenden oder Anpassung der ergänzenden Angaben der Blankoverordnung des Pflegedienstes. AP2 Nach Dokumentation der Entscheidung der Antragsprüfung eines Antrags auf Kostenerstattung nach § 37 Abs. 4 SGB V oder persönlichem Budget wird der Status auf "abgeschlossen" geändert AP4 Nach Übertragung des Ergebnisses der Antragsprüfung wird der Status auf "zugewiesen" (beschieden)" geändert. AP4 Der Vorgang der Prüfung kann vom Kostenträger abgebrochen werden aufgrund von "Unzuständigkeit" → Fortführung zu Status "zugewiesen (beschieden)". AL3 Wird der Vorgang der Prüfung vom Kostenträger nicht weiterbearbeitet (z. B. Versicherter wechselt Kostenträger oder verstirbt) erfolgt, wie in Kapitel [9 Gültigkeiten und Löschregeln] beschrieben, ein automatischer Übergang 100 Tage nach dem Verordnungszeitraum zu Status "gelöscht". |
| Zugriffs-berechtigung | Der Status der Verordnung (des Vorgangs) kann vom zugewiesenen Pflegedienst, dem Verordnenden und dem Versicherten abgerufen werden. Es wird Ihnen der Status "Antragsprüfung" angezeigt.
Der Kostenträger (Kostenerstattungsprinzip) hat keinen Zugriff. Der Kostenträger (Sachleistungsprinzip) kann die Verordnung und die Angaben des Pflegedienstes sowie ggf. die Blankoverordnung einsehen. |
Tabelle 8 : Erläuterungen zum fachlichen Statusmodell - Status 'Korrekturanfrage'
| Status | Korrekturanfrage |
|---|---|
| Definition | Im Status Korrekturanfrage liegt entweder der verordnenden Arztpraxis eine Anfrage inkl. konkretem Vorschlag zur Anpassung der ursprünglichen Verordnung vor oder dem Pflegedienst liegt eine Anfrage inkl. konkretem Vorschlag zur Anpassung der Blankoverordnung vor.
Der Arzt oder der Pflegedienst sind aufgefordert die Verordnung bzw. Blankoverordnung anzupassen. Während der Status gesetzt ist, sind Arzt, Pflegedienst und Kostenträger (sofern schon über Prozess der Leistungsentscheidung oder Beratung eingebunden) über den Status informiert. Nach erfolgter Korrektur wird der zuvor geltende Status wieder übernommen ("zugewiesen“ und „Antragsprüfung“). Wurde bereits ein Pflegedienst zugewiesen zuvor, ist dieser weiterhin als zuständiger Pflegedienst mit dem Vorgang verknüpft, sodass kein anderer Pflegedienst auf den Vorgang zugreifen kann. Fallunterscheidung: Fall 1: Pflegedienst stellt Anpassungsbedarf in der Verordnung fest und übergibt an die verordnende Praxis Fall 2 : Kostenträger im Sachleistungsprinzip stellt Anpassungsbedarf in der Verordnung fest und übergibt an die verordnende Praxis Fall 3 : Kostenträger im Sachleistungsprinzip stellt Anpassungsbedarf am Blankoverordnungsdatensatz fest und übergibt an den Pflegedienst Hinweis : Die Korrekturanfrage eines Versicherten an den Arzt ist nicht möglich. Sollte dieser Bedarf bestehen, wendet sich der Versicherte an die Arztpraxis auf anderem Weg. |
| Vorbedingung | K1 Im Status „zugewiesen“ hat der Pflegedienst nach Sichtung der Verordnung den Status in „Korrekturanfrage“ geändert und der verordnenden Praxis einen Korrekturvorschlag der Verordnung zum Zwecke der Korrektur bereitgestellt.
K4 Im Status „Antragsprüfung“ hat der Kostenträger im Rahmen des Prozesses der Leistungsentscheidung den Status in „Korrekturanfrage“ geändert und entweder der verordnenden Praxis einen Korrekturvorschlag der Verordnung zum Zwecke der Korrektur bereitgestellt, oder dem Pflegedienst einen Korrekturvorschlag der Blankoverordnung zum Zwecke der Korrektur bereitgestellt. |
| Nachfolge | Nach erfolgter Korrektur wird der zuvor geltende Status wieder übernommen:
K2 "zugewiesen“ K5 „Antragsprüfung“ Wurde zu einer Korrekturanfrage noch keine neue Version erstellt (mit Anpassung oder Ablehnung), kann der Anfragende die Korrekturanfrage zurückziehen, um ohne erfolgte Korrektur dennoch weiter agieren zu können. K3 "zugewiesen“ K6 „Antragsprüfung“ Eine zuvor erfolgte Zuordnung des Pflegedienstes vor der Korrektur besteht auch während und nach Abschluss der Korrektur. |
| Zugriffs-berechtigung | Der Status ist einsehbar durch den Versicherten, die verordnende Praxis sowie den Kostenträger (Sachleistungsprinzip) und/oder Pflege-dienst.
Versicherte haben Zugriff auf die Verordnung am Fachdienst und können den Status einsehen, jedoch selbst keine Änderung der Zuweisung vornehmen. Der zugewiesene Pflegedienst kann die Inhalte der Verordnung einsehen. |
Tabelle 9 : Erläuterungen zum fachlichen Statusmodell - Status 'zugewiesen (beschieden)'
| Status | zugewiesen (beschieden) |
|---|---|
| Definition | Die Entscheidung zur Antragsprüfung ist im Entscheidungsdatensatz dokumentiert und in dem Fachdienst gespeichert.
Es gelten die gleichen Regelungen wie für "zugewiesen":
|
| Vorbedingung | AP4 Bei Übertragung des Ergebnisses der Antragsprüfung wird der Status auf "zugewiesen (beschieden)" gesetzt.
AP4 Der Vorgang der Antragsprüfung wurde vom Kostenträger abgebrochen aufgrund "Unzuständigkeit" → Fortführung zu Status "zugewiesen (beschieden)". Der Inhalt der Entscheidung des Antragsverfahrens ist als Entscheidungsdatensatz (siehe Kapitel [8 Datensätze]) im Fachdienst gespeichert. |
| Nachfolge | Die Verordnung kann vom Pflegedienst nach Abschluss des Leistungsentscheidungs-prozesses (vorliegender Entscheidungsdatensatz) nicht zurück in den Status "offen" gestellt werden.
AA2 Nach Ende des Leistungszeitraums wird der Vorgang automatisch in den Status "abgeschlossen" versetzt. |
| Zugriffs-berechtigung | Der Status des Vorgangs kann von dem Pflegedienst, dem Verordnenden und dem Versicherten abgerufen werden.
Ebenso können die Angaben des Pflegedienstes, ggf. die Daten der Blankoverordnung und die Angaben des Entscheidungsdatensatzes vom Pflegedienst, dem Verordnenden und dem Versicherten eingesehen werden. |
Die Leistung wurde erbracht und dokumentiert oder der Verordnungszeitraum wurde überschritten, während sich die Verordnung im Status "offen" befand.
Tabelle 10 : Erläuterungen zum fachlichen Statusmodell - Status 'abgeschlossen'
| Status | abgeschlossen |
|---|---|
| Definition | Nach Ende des Verordnungszeitraums wird die Verordnung automatisch in den Status abgeschlossen überführt, sofern sie zuvor den Status "offen" oder "zugewiesen" oder "zugewiesen (beschieden)" hatte.
Sofern die Verordnung nicht innerhalb des Verordnungszeitraums einem Pflegedienst zugewiesen und von diesem akzeptiert wurde, erhält diese den Status abgeschlossen. Es ist davon auszugehen, dass entweder die Leistung nicht in Anspruch genommen wurde oder diese über das persönliche Budget bzw. bei Privatversicherten nach dem Kostenerstattungsprinzip bilateral zwischen Privatversichertem und dessen Kostenträger(n) betrachtet wurden. |
| Vorbedingung | AA1 Findet keine Zuweisung statt und verbleibt die Verordnung im Status "offen", wird die Verordnung nach Ablauf des Verordnungszeitraums automatisch vom Fachdienst in den Status "abgeschlossen" versetzt .
AA2 Aus dem Status "zugewiesen" oder "zugewiesen (beschieden)" wird der Vorgang nach Ablauf des Verordnungszeitraums automatisch vom Fachdienst in den Status "abgeschlossen" versetzt. 4 Im Zuge der Bearbeitung der [] durch Mitarbeiter des Kostenträgers (Sachleistungsprinzip) kann die Verordnung aktiv auf "abgeschlossen" gesetzt werden. Die Verordnungsinhalte sind so zunächst noch einsehbar für den Versicherten. AP2 Nach Dokumentation der Entscheidung der Antragsprüfung eines Antrags auf Kostenerstattung nach §37 Abs. 4 SGB V oder persönlichem Budget (beides Ausnahmen vom Sachleistungsprinzip) wird der Status von "Antragsstellung" auf "abgeschlossen" geändert |
| Nachfolge | ML3 Löschen durch den Versicherten ermöglicht diesem Daten die nicht mehr für die Versorgung durch die Pflege benötigt werden selbst zu löschen.
AL2 Die Verordnung wird wie in Kapitel [9 Gültigkeiten und Löschregeln] beschrieben, automatisch gelöscht. Der Vorgang soll, wie in Kapitel [9 Gültigkeiten und Löschregeln] beschrieben, wie beim Arzneimittelkosten-beleg nach 10 Jahren vom Fachdienst automatisch gelöscht werden. Bis dahin ist es möglich Rechnungen und rechnungsbegründende Unterlagen (in diesem Fall die Verordnungsinformationen via PDF/A3) zwecks Kostenerstattung einzureichen beim Kostenträger (PKV-Mitgliedsunternehmen oder/und Beihilfe). Eine Abbildung eines Status am Fachdienst erfolgt nicht. |
| Zugriffs-berechtigung | Der Status des Vorgangs kann von dem Pflegedienst, dem Verordnenden und dem Versicherten abgerufen
werden. |
finaler Status. Die Inhalte der Verordnung sind nicht mehr abrufbar. Es stehen die Protokolldaten des Vorgangs am Fachdienst aber noch bis zu 3 Jahre zum Abruf durch den Versicherten zur Verfügung.
Tabelle 11 : Erläuterungen zum fachlichen Statusmodell - Status 'gelöscht'
| Status | gelöscht |
|---|---|
| Definition | Versicherte haben die Möglichkeit Verordnungen im Status "offen" zu löschen, was zu diesem Status führt.
Sofern eine Verordnung fehlerhaft ausgestellt wurde, besteht auch die Möglichkeit für den Verordnenden, die Verordnung in Rücksprache mit dem Versicherten zu löschen. Abgeschlossene Verordnungen werden nach einem festgelegten Zeitraum gelöscht. |
| Vorbedingung | ML1 Eine zunächst "initialisierte" Verordnung wird von Mitarbeitern der Arztpraxis gelöscht.
AL1 Eine zunächst "initialisierte" Verordnung wird von Mitarbeitern der Arztpraxis nicht befüllt und dann automatisch gelöscht. ML2 Versicherter haben die Verordnung im Status "offen" gelöscht bzw. die verordnende Arztpraxis hat in Rücksprache mit dem Versicherten die Verordnung im Status "offen" gelöscht. ML3 Löschen durch den Versicherten ermöglicht diesem, alle Daten des Vorgangs am Fachdienst die in diesem Status nicht mehr für die Versorgung durch die Pflege benötigt werden, selbst zu löschen. AL2 Die Verordnung wurde, wie in Kapitel [9 Gültigkeiten und Löschregeln] definiert, vom Status "abgeschlossen" automatisch 100 Tage nach dem Verordnungszeitraum gelöscht. AL3 Die Verordnung wurde, wie in Kapitel [9 Gültigkeiten und Löschregeln] definiert, vom Status "Antragsprüfung" automatisch 100 Tage nach dem Verordnungszeitraum gelöscht. |
| Nachfolge | |
| Zugriffs-berechtigung | Der Status des Vorgangs kann von dem Pflegedienst, dem Verordnenden und dem Versicherten abgerufen werden.
Die Protokolldaten des Vorgangs können vom Versicherten eingesehen werden. Die Vorgangsdaten am Fachdienst sind nicht mehr abrufbar (Verordnung, Blankoverordnung, Angaben zur Leistungserbringung des Pflegedienstes, Entscheidungsdatensatz, Korrekturen). |
Die fachlichen Informationsmodelle und FHIR-Profile der Datensätze werden durch die Partner des BMV-Ä festgelegt. Die nachfolgende Übersicht nennt die Inhalte der unterschiedlichen Datensätze exemplarisch ergänzt um die Angabe der erforderlichen Signatur, des Speicherortes außerhalb der beteiligten Primärsysteme sowie der Zugriffsrechte der beteiligten Akteure.
Tabelle 12: Übersicht über die Datensätze, deren Inhalte, Signaturen, Speicherorte und Rechte der einzelnen Akteure
| Bezeichnung | Inhalte (Beispielhaft) | Signatur | Speicherort | Rechte Arzt | Rechte Versicher-ter | Rechte Pflege-dienst | Rechte Kosten-träger |
|---|---|---|---|---|---|---|---|
| Verordnungsdatensatz
(initial oder neue Verordnung nach Korrektur) VO und VO-nV (wird festgelegt durch BMV-Ä Partner) |
- Angaben zum Versicherten;
- Verordnungsdatum, - Verordnungszeitraum, in dem die Leistungen erbracht werden sollen - Angaben zur verordnenden Person und deren Institution, - Diagnosen im Zusammenhang mit der zu verordnenden Maßnahmen (Begründung), - Angabe der Maßnahmen der häuslichen Krankenpflege; Die Bezugnahme auf die erste Version des Verordnungsdatensatz ist über gemeinsame Verordnungs-ID möglich. |
Qualifizierte Signatur
und fortgeschrittene Signatur (siehe Regelungen im BMV-Ä) |
Fachdienst | schreibend und danach lesend (Status)
löschen im Status "offen" und "initialisiert" |
lesend
löschen im Status "offen" und "abge-schlossen" |
lesend
(nach Berech-tigung) Kein Löschrecht |
lesend
(nach Berech-tigung) Kein Löschrecht |
| Verordnungsdatensatz
(Korrekturvorschlag) VO-k (wird festgelegt durch BMV-Ä Partner bzw. ist eine inhaltliche Ergänzung zum Verordnungs-datensatz (initial)) |
Auf Basis des Verordnungsdatensatzes (initial) erstellt entweder eine Pflegefachperson einen Korrekturvorschlag zwecks Anfrage beim Verordnenden oder der Kostenträger (Sachleistungsprinzip) erstellt den Korrekturvorschlag zwecks Anfrage beim Verordnenden.
Die Absenderorganisation (Telematik-ID) ist erkennbar. Die Bezugnahme auf den zugrundeliegenden Verordnungsdatensatz ist über die gemeinsame Verordnungs-ID möglich. |
keine Signatur | Fachdienst | lesend
Kein Löschrecht |
lesend
löschen im Status "abgeschlossen" |
schreibend
löschen für eigene VO-k |
schreibend
löschen für eigene VO-k |
| Blankoverordnungs-datensatz
(initial oder neue Blankoverordnung nach Korrektur) (wird festgelegt durch GKV mit Pflegeverbänden — voraussichtlich auf Basis der Rahmenempfehlung nach § 132 a Abs. 1 SGB V zur Versorgung mit häuslicher Krankenpflege) |
Konkretisierungen zur Verordnung im Rahmen der Kompetenzerweiterung.
Lebenslange Beschäftigtennummer der ausstellenden Pflegefachperson. Im Falle einer neuen Blankoverordnung nach Korrekturanfrage kann ein Bezug auf die initiale Version des Blankoverordnungsdatensatzes über die gemeinsame Verordnung-ID ermöglicht werden. |
Fortgeschrittene Signatur | Fachdienst | lesend
Kein Löschrecht |
lesend
löschen im Status "abge-schlossen" |
schreibend
Kein Löschrecht |
lesend (nach erst-maliger Einreich-ung)
Kein Löschrecht |
| Blankoverordnungs-datensatz
(Korrekturvorschlag) (wird festgelegt durch GKV mit Pflegeverbänden — voraussichtlich auf Basis der Rahmenempfehlung bzw. ist Ergänzung zum Blanko-verordnungsdatensatz (initial) |
Auf Basis des Blanko-verordnungsdatensatzes (initial oder neue Blankoverordnung nach Korrektur) erstellt der Kostenträger (Sachleistungsprinzip) einen Korrekturvorschlag zwecks Anfrage beim Verordnenden und legt diesen Korrekturvorschlag an.
Die Absenderorganisation (Telematik-ID) ist erkennbar. Es ist ein Bezug auf den zugrunde liegenden Datensatz über die gemeinsame Verordnungs-ID möglich. |
keine Signatur | Fachdienst | Kein Leserecht
Kein Löschrecht |
lesend
löschen im Status "abge-schlossen" |
lesend
Kein Löschrecht |
schreibend
Kein Löschrecht |
| Angaben zur Leistungserbringung des PD
(wird festgelegt durch GKV mit Pflegeverbänden — voraussichtlich auf Basis der Rahmenempfehlung) |
Angaben zu LEI: ergänzende Angaben zum LE (IK, Adresse, Ansprechpartner, Angaben zum Leistungsort, ...)
Die Absenderorganisation (Telematik-ID) ist erkennbar. optional AC/TK Kennzeichen und GPOS-Nummern Hinweis: Zu diesem Datensatz gibt es keinen Korrekturdatensatz. Bei Bedarf wird ein neuer Datensatz von der Pflege ausgestellt. |
Fortgeschrittene Signatur
|
Fachdienst | lesend
Kein Löschrecht |
lesend
löschen im Status "abge-schlossen" |
schreibend
Kein Löschrecht |
lesend
Kein Löschrecht |
| Entscheidungsdatensatz
(wird festgelegt durch GKV) |
Entscheidung zum Vorgang: Angaben je Maßnahme ob genehmigt, teilgenehmigt oder abgelehnt
Zeitraum für den die Zusage gilt Datum der Entscheidung optional AC/TK, Auflistung der GPOS-Nummern der Kostenübernahme (ganz / teilweise / Frequenz / Anzahl) Eine übergeordnete Begründung der Entscheidung jeweils für Arzt, für PD, für Versicherten. Hinweis: Der Fachdienst bietet die Möglichkeit aktualisierte Versionen des Entscheidungsdatensatzes einzustellen. Es wird ersichtlich, welcher der Datensätze aktuell gilt. |
keine Signatur | Fachdienst | lesend (siehe Begründung der Entscheidung für Arzt)
Kein Löschrecht |
lesend (siehe Begründung der Entscheidung für Versicherten)
löschen im Status "abge-schlossen" |
lesend (siehe Begründung der Entscheidung für Pflegedienst)
Kein Löschrecht |
schreibend
löschen im Status "abge-schlossen" |
| Leistungsnachweis-datensatz
(wird festgelegt durch GKV nach §302 SGB V) |
Die Festlegung erfolgt zwischen den Vertragspartnern nach §302 SGB V. Es folgen keine Regelungen im Fachkonzept. Keine Speicherung im Fachdienst. | ||||||
| Abrechnungsdatensatz
(wird festgelegt durch GKV nach §302 SGB V) |
Die Festlegung erfolgt zwischen den Vertragspartnern nach §302 SGB V. Es folgen keine Regelungen im Fachkonzept. Keine Speicherung im Fachdienst.
|
||||||
Die Häusliche Krankenpflege-Richtlinie enthält keine Angabe zur Gültigkeit der HKP-Verordnung. Somit kann die Verordnung innerhalb des Gesamtverordnungszeitraums eingelöst bzw. in Anspruch genommen werden. Starre Fristen, wie im Bereich Arznei- und Heilmittel, gibt es nicht. Die Angabe „Verordnungszeitraum bis“ ist zwingend durch den Verordnenden zu füllen. Eine Speicherung und eine Zugriffsmöglichkeit auf den Vorgang für die Kostenträger (Sachleistungsprinzip) besteht über „Verordnungszeitraum bis“ hinaus, sofern die Verordnung vom Versicherten nach „Verordnungszeitraum bis“ nicht gelöscht wurde.
Tabelle 13: Übersicht über Gültigkeiten und Löschregeln
| Beschreibung | Zeitdauer / Frist zu Lasten eines Kostenträgers mit Sachleistungsprinzip | Zeitdauer / Frist zu Lasten eines Kostenträgers mit Kostenerstattungsprinzip |
|---|---|---|
| Zuweisen bei PD | Ab Zuweisung bis Ende des Verordnungszeitraums | Ab Einstellung bis Ende des Verordnungszeitraums |
| Freigabe an Kasse zur Beratung oder Inanspruchnahme von Persönlichem Budget, Kostenerstattung | Ab Einstellung bis Ende des Verordnungszeitraums + 100 Tage | Ab Einstellung bis 10 Jahre nach Verordnungsdatum (entsprechend Kostenerstattungsprinzip in §360 Abs. 12 SGB V) |
| Anfrage Leistungsentscheidung | Ab Einstellung bis Ende des Verordnungszeitraums | (optional) Ab Einstellung bis innerhalb des Verordnungszeitraums |
| Abrechnung Leistung | Vertragliche Regelung (keine Frist für den Fachdienst) | 10 Jahre nach Verordnungsdatum (entsprechend Kostenerstattungsprinzip in §360 Abs. 12 SGB V) |
| Löschen der Verordnung am Fachdienst | nach Ende des Verordnungszeitraums + 100 Tage | nach 10 Jahre nach Verordnungsdatum (entsprechend Kostenerstattungsprinzip in §360 Abs. 12 SGB V) |
Da das Verfahren zum Widerspruch außerhalb des Fachdienstes erfolgt, ist für diesen Fall keine längere Vorhaltung der Datensätze auf dem Fachdienst erforderlich, als unter" Löschen der Verordnungen am Fachdienst" vorgesehen ist.
Um das vorliegende Fachkonzept umzusetzen, müssen aus Sicht der gematik folgende Anpassungen der gesetzlichen Rahmenbedingungen getroffen werden. Diese sind als Vorschläge für ein kommendes Gesetzgebungsverfahren anzusehen und richten sich an das Bundesministerium für Gesundheit.
Tabelle 14: Übersicht über die Anpassungsbedarfe der gesetzlichen Rahmenbedingungen
| Bisherige Regelung | Motivation | Regelungsvorschlag |
|---|---|---|
| keine | Legitimieren der Zugriffe auf die elektronische Verordnung häuslicher Krankenpflege, außerklinischer Intensivpflege und Soziotherapie zum Zweck der Leistungsentscheidung und/oder Abrechnung der entsprechend verordneten Leistung für jeder Art von Kostenträger:
|
Neu § 361c SGB V: Zugriff auf ärztliche Verordnungen häuslicher Krankenpflege, außerklinischer Intensivpflege und Soziotherapie in der Telematikinfrastruktur
(1) Krankenkassen, gesetzliche Unfallversicherung, Beihilfe sowie Kostenträger der Versicherten gemäß §362 Abs. 1 SGB V dürfen zum Zwecke der Beratung, Leistungsentscheidung sowie Kostenerstattung elektronischer Verordnungen von häuslicher Krankenpflege, außerklinischer Intensivpflege nach § 360 Absatz 5 und Verordnungen von Soziotherapie nach § 360 Absatz 6, auf Daten der Versicherten in elektronischen Verordnungen zugreifen. (2) Im Rahmen des Zugriffs nach Absatz 1 darf nicht in die ärztliche Therapiefreiheit eingegriffen oder die Wahlfreiheit der Versicherten beschränkt werden. |
| [§ 27a SGB VII - Nutzung der Telematikinfrastruktur]
§ 360 des Fünften Buches gilt entsprechend für die Leistungserbringer nach § 27 Absatz 1 sowie die Unfallversicherungsträger, sobald die Verordnung von Leistungen nach § 27 Absatz 1 Nummer 4 elektronisch erfolgt und der Leistungserbringer an die Telematikinfrastruktur angebunden ist. |
Redaktioneller Anpassungsbedarf für die DGUV:
Da [§ 27 Abs. 1 Nr. 4 SGB VII] nur auf die "Versorgung mit Arznei-, Verband-, Heil- und Hilfsmitteln" abzielt, sind die Verordnungen von:
|
Unter § 27 Absatz 1 Nummer 5 SGB VII ist häusliche Krankenpflege bereits genannt, es fehlt jedoch in [§ 27 Abs. 2 SGB VII] der Verweis darauf. Die zukünftig ebenfalls zu digitalisierenden Verordnungen der außerklinischen Intensivpflege und Soziotherapie sollte zudem gleich ergänzt werden.
Vorschlag: [§ 27a SGB VII]: Abs. (2) wird wie folgt ergänzt: Abs. (2): "§ 360 des Fünften Buches gilt entsprechend für die Leistungserbringer nach § 27 Absatz 1 sowie die Unfallversicherungsträger, sobald die Verordnung von Leistungen nach § 27 Absatz 1 Nummer 4 und 5 elektronisch erfolgt und der Leistungserbringer an die Telematikinfrastruktur angebunden ist." [§ 27 Abs. 1 Nr. 5 SGB VII] wird wie folgt ergänzt: "häusliche Krankenpflege, außerklinische Intensivpflege und Soziotherapie," |
| Anbieter einer Komponente der TI zum Zugriff auf Verordnungen (FdV) nach §360 Abs. 10 Satz 1 und Satz 8 SGB V | Neben der gematik sowie den gesetzlichen Krankenkassen und Unternehmen der privaten Krankenversicherung darf die Komponente der TI (FdV), die den Zugriff der Versicherten auf die elektronische ärztliche Verordnung nach § 334 Absatz 1 Satz 2 Nummer 6 SGB V ermöglicht, auch zur Verfügung gestellt werden von:
Ausgeschlossen sind, weil keine eigene App zum Einlösen von E-Rezepten/Verordnungen vorhanden ist:
|
[§ 360 Abs. 10 Satz 8 SGB V] könnte wie folgt gefasst werden:
"Komponenten nach diesem Absatz, für die ein externes Sicherheitsgutachten vorliegt, das gemäß Satz 6 durch das Bundesamt für Sicherheit in der Informationstechnik bestätigt wurde, dürfen den Versicherten abweichend von Satz 7 auch durch die Krankenkassen und durch die Unternehmen der privaten Krankenversicherung sowie Kostenträger der Versicherten gemäß §362 Abs. 1 SGB V über die Benutzeroberfläche gemäß § 342 zur Verfügung gestellt werden." |
| keine | Entsprechend Kapitel 6.5.1.4 besteht der Wunsch, die Festlegung eines Stammpflegedienstes auch ohne FdV zu ermöglichen. | Das Bundesministerium für Gesundheit prüft die Möglichkeiten zur Schaffung der notwendigen Rahmenbedingungen bereits und wird gegebenenfalls in einem zukünftigen Gesetzgebungsverfahren dieses Thema einbringen. |
| §360 Abs. 11 SGB V regelt bislang: "Verordnungsdaten und Dispensierinformationen sind mit Ablauf von 100 Tagen nach Dispensierung der Verordnung zu löschen." | Während Verordnungsdatensatz, Blankoverordnungsdatensatz und dazugehörige Korrekturvorschläge unter dieser Regelung Berücksichtigung finden, sind die in Kapitel 8 neu eingeführten Datensätze bislang noch nicht in dieser Norm enthalten, konkret fehlen:
|
SGB V §360 Abs. 11 könnte wie folgt gefasst werden:
"Mit Ablauf von 100 Tagen sind:
|
Dieses Kapitel beschreibt das technische Konzept für Umsetzung der Funktionalität für die Ausbaustufe Minimal Viable Product (Version 1).
Die Einführung der elektronischen Verordnung für HKP setzt auf die bestehende Infrastruktur der Anwendung E-Rezept auf.
Abbildung 6 : Systemüberblick HKP
Prozessbeteiligte für die elektronische Verordnung HKP sind Verordnende, Versicherte, Pflegedienste und Kostenträger.
Verordnende nutzen ein PVS/KIS, welches sich über das zentrale Netz der TI mit dem E-Rezept-Fachdienst verbindet. Das Primärsystem nutzt eine SM(C)-B, um sich gegenüber dem E-Rezept-Fachdienst zu authentifizieren. SM(C)-Bs mit folgenden ProfessionOIDs für Institutionen sind zulässig:
Für die Signatur eines Verordnungsdatensatzes verwendet der Verordnende einen HBA mit der ProfessionOID oid_arzt oder oid_ps_psychotherapeut. In Ausnahmefällen ist eine nonQES Signatur des Verordnungsdatensatzes mit einer SM(C)-B mit folgenden ProfessionOIDs für Institutionen zulässig:
Versicherte nutzen ein Frontend des Versicherten, welches durch die gematik und die Kostenträger bereitgestellt wird. Das FdV verbindet sich über das Internet mit dem E-Rezept-Fachdienst. Versicherte authentifizieren sich mittels eGK oder Gesundheits-ID gegenüber dem E-Rezept-Fachdienst.
Pflegedienste nutzen ein PPS, welches sich über das zentrale Netz der TI mit dem E-Rezept-Fachdienst verbindet. Es sind keine mobilen Szenarien vorgesehen, bei dem sich das PPS über das Internet mit dem E-Rezept-Fachdienst verbindet. Das PPS nutzt eine SM(C)-B mit ProfessionOID oid_institution-pflege, um sich gegenüber dem E-Rezept-Fachdienst zu authentifizieren.
Für die Signatur eines Datensatzes verwendet der Pflegedienst eine SM(C)-B mit ProfessionOID oid_institution-pflege.
Kostenträger nutzen ein Clientsystem des Kostenträgers, welches sich über das zentrale Netz der TI mit dem E-Rezept-Fachdienst verbindet. Das Primärsystem nutzt eine SM(C)-B mit ProfessionOID oid_kostentraeger, um sich gegenüber dem E-Rezept-Fachdienst zu authentifizieren.
Der Workflow einer Verordnung wird durch ein zweistufiges Statusmodell beschrieben, das aus einem technischen Statusmodell und einem fachlichen Business-Statusmodell besteht. Das Statusmodell basiert auf den in der FHIR Task-Ressource vorgesehenen Elementen Task.status und Task.businessStatus.
Der technische Status (Task.status) dient der Steuerung des Workflow-Lebenszyklus und beschreibt den technischen Bearbeitungszustand einer Verordnung. Das fachliche Business-Statusmodell (Task.businessStatus) beschreibt dagegen die jeweiligen fachlichen Prozessschritte innerhalb des HKP-Verfahrens.
Im Rahmen des Verordnungs-Workflows können eigenständige Teilprozesse als Anfrage-Workflows ausgeführt werden. Ein Anfrage-Workflow stellt einen fachlich abgegrenzten Bearbeitungsschritt dar, der durch eine eigene Task-Instanz repräsentiert wird und unabhängig vom übergeordneten Verordnungs-Workflow bearbeitet werden kann. Für den HKP-Workflow werden insbesondere die Anfrage-Workflows Antragsprüfung und Korrektur-/Anfrage verwendet.
Während ein Anfrage-Workflow bearbeitet wird, wird der übergeordnete Verordnungs-Workflow technisch pausiert. Nach Abschluss des Anfrage-Workflows wird die Bearbeitung des Verordnungs-Workflows fortgesetzt. Hierdurch können fachliche Teilprozesse unabhängig voneinander ausgeführt werden, ohne den Kontext des übergeordneten Workflows zu verlieren.
Durch die Trennung von technischem Status und Business-Status kann der fachliche Bearbeitungsstand unabhängig von der technischen Workflow-Steuerung abgebildet werden. Dies ist insbesondere für die Ausführung von Anfrage-Workflows relevant. Während ein Anfrage-Workflow bearbeitet wird, kann der übergeordnete Workflow technisch pausiert werden, ohne dass Informationen über den fachlichen Prozessschritt verloren gehen. Der Business-Status beschreibt hierbei den fachlichen Kontext des Vorgangs, während der technische Status die Ausführung und den Lebenszyklus des Workflows steuert.
Die technischen Zustände des Verordnungs-Workflows sind in der folgenden Tabelle beschrieben:
Tabelle 15 : Technisches Statusmodell - Status
| Technischer Status | Beschreibung |
|---|---|
| draft | Der Vorgang wurde angelegt, ist jedoch noch nicht zur Bearbeitung freigegeben. |
| ready | Der Vorgang kann bearbeitet werden. |
| in-progress | Der Vorgang befindet sich in Bearbeitung. |
| on-hold | Die Bearbeitung des Vorgangs ist vorübergehend pausiert, beispielsweise während ein Anfrage-Workflow ausgeführt wird. |
| completed | Der Vorgang wurde abgeschlossen. |
| cancelled | Der Vorgang wurde zur Löschung markiert und wird gemäß den definierten Löschregeln entfernt. |
Die möglichen technischen Zustandsübergänge sind in der folgenden Abbildung dargestellt.
Abbildung 7 : Technisches Statusmodell des Verordnungs-Workflows
Die technischen Zustände ready und in-progress können zur Ausführung eines Anfrage-Workflows in den Zustand on-hold überführt werden. Währenddessen wird die Bearbeitung des Verordnungs-Workflows pausiert. Nach Abschluss des Anfrage-Workflows wird die Bearbeitung des Verordnungs-Workflows fortgesetzt.
Zusätzlich können Vorgänge zum Löschen markiert werden. Hierzu wird analog zu den Workflows für Arzneimittel der technische Status cancelled verwendet. Die zulässigen Übergänge in den Zustand cancelled sind in der folgenden Abbildung dargestellt.
Abbildung 8 : Zulässige Übergänge in den technischen Status cancelled
Ein Übergang in den Zustand cancelled ist aus den technischen Zuständen draft, ready, on-hold und completed zulässig.
Der fachliche Bearbeitungsstand wird über den Business-Status (Task.businessStatus) abgebildet. Hierdurch bleibt erkennbar, aus welchem fachlichen Prozessschritt heraus ein Anfrage-Workflow gestartet wurde. Nach Abschluss eines Anfrage-Workflows kann anhand des vorherigen Business-Status ein gezielter fachlicher Zustandsübergang ausgelöst werden.
Die fachlichen Zustände des Verordnungs-Workflows werden durch die folgenden Business-Statuswerte beschrieben:
Tabelle 16 : Business Statusmodell
| Business-Status | Technischer Status | Beschreibung |
|---|---|---|
| initialized | draft | Der Vorgang wurde initial angelegt und befindet sich noch vor der eigentlichen fachlichen Bearbeitung. |
| open | ready | Die Verordnung liegt vor und ist bereit für die Zuweisung eines Pflegedienstes. |
| open | on-hold | Die Verordnung ist bereit für die Zuweisung eines Pflegedienstes. Die Bearbeitung ist jedoch pausiert, da ein Anfrage-Workflow ausgeführt wird. |
| open-reviewed | ready | Die Antragsprüfung wurde abgeschlossen. Die Verordnung befindet sich weiterhin im offenen Bearbeitungszustand. |
| assigned | in-progress | Der Verordnung wurde einem Pflegedienst zugewiesen. |
| assigned | on-hold | Der Verordnung wurde ein Pflegedienst zugewiesen. Die Bearbeitung ist jedoch pausiert, da ein Anfrage-Workflow ausgeführt wird. |
| assigned-reviewed | in-progress | Der Verordnung wurde ein Pflegedienst zugewiesen und die Antragsprüfung wurde abgeschlossen. |
| completed | completed | Der fachliche Prozess wurde erfolgreich abgeschlossen. |
| deleted | cancelled | Der Löschprozess wurde abgeschlossen. Der Vorgang gilt fachlich als gelöscht und steht nicht mehr zur Bearbeitung zur Verfügung. |
Die Zustände open-reviewed und assigned-reviewed kennzeichnen Vorgänge, bei denen eine Antragsprüfung bereits abgeschlossen wurde. Dadurch bleibt das Ergebnis der Antragsprüfung auch nach der Rückkehr in den regulären Verordnungs-Workflow erhalten und kann bei nachfolgenden Prozessschritten berücksichtigt werden.
Eine Antragsprüfung kann ausschließlich aus den fachlichen Zuständen open und assigned initiiert werden. Die Zustände open-reviewed und assigned-reviewed dokumentieren den Abschluss der Antragsprüfung und verhindern, dass der Anfrage-Workflow erneut gestartet wird. Hierdurch wird sichergestellt, dass eine bereits abgeschlossene Antragsprüfung innerhalb derselben Bearbeitungsphase nicht erneut durchgeführt werden kann.
Der Business-Status dient darüber hinaus dazu, den fachlichen Kontext eines pausierten Verordnungs-Workflows zu erhalten. Wird ein Anfrage-Workflow gestartet, verbleibt der Verordnungs-Workflow technisch im Zustand on-hold. Der zugehörige Business-Status ermöglicht es dabei, nach Abschluss des Anfrage-Workflows den fachlich korrekten Zustandsübergang auszulösen.
Die Statussübergänge des Verordnungs-Workflows werden durch die Kombination aus technischem Status und fachlichem Business-Status beschrieben. Die nachfolgende Abbildung zeigt die technische Abbildung des Verordnungs-Workflows einschließlich der Interaktion mit den Anfrage-Workflows zur Antragsprüfung und zur Korrektur-/Anfrage.
Die Antragsprüfung und die Korrektur/Anfrage werden dabei nicht als eigene Zustände der Verordnungs-Task modelliert, sondern als eigenständige Anfrage-Workflows mit eigenen Task-Instanzen. Während ein Anfrage-Workflow ausgeführt wird, wird die Verordnungs-Task technisch in den Zustand on-hold überführt. Der fachliche Kontext bleibt über den Business-Status erhalten und ermöglicht nach Abschluss des Anfrage-Workflows die Rückkehr in den fachlich korrekten Zustand.
Abbildung 9 : Statusübergänge des Verordnungs-Workflows
Die fachliche Bedeutung, die Voraussetzungen sowie die auslösenden Ereignisse der einzelnen Übergänge werden in Kapitel 7 des Fachkonzepts beschrieben. Die Tabelle dient der technischen Abbildung dieser Übergänge auf die FHIR Task-Ressource.
Tabelle 17 : Statusübergänge
| Übergang | Auslösender Akteur | Beschreibung | Von
businessStatus (status) |
Nach
businessStatus (status) |
|---|---|---|---|---|
| Verordnender | Erzeugen des Tasks | initialized (draft) | ||
| 1 | Verordnender | Bereitstellung der Verordnung am Fachdienst | initialized (draft) | open (ready) |
| Pflegedienst
Kostenträger |
Lesender Zugriff | open (ready) | open (ready) | |
| 2 | Pflegedienst | Übernahme der Verordnung durch einen Pflegedienst. | open (ready) | assigned (in-progress) |
| 3 | Pflegedienst | Rückgabe der Verordnung, z. B. wenn die Versorgung nicht übernommen werden kann. | assigned (in-progress) | open (ready) |
| AP1 | Versicherter (FdV)
Kostenträger (stellvertretend) |
Start einer Antragsprüfung für einen offenen Vorgang | open (ready) | open (on-hold) |
| Kostenträger | Ablehnen einer Antragsprüfung | open (on-hold) | open (ready) | |
| AP2 | Kostenträger | Abschluss der Antragsprüfung eines offenen Vorgangs | open (on-hold) | open-reviewed (ready) |
| AP3 | Pflegedienst | Start einer Antragsprüfung für einen bereits zugewiesenen Vorgang | assigned (in-progress) | assigned (on-hold) |
| AP4 | Kostenträger | Abschluss der Antragsprüfung eines zugewiesenen Vorgangs | assigned (on-hold) | assigned-reviewed (in-progress) |
| K1 | Pflegedienst
|
Start einer Korrekturanfrage an den Verordnenden | assigned (in-progress) | assigned (on-hold) |
| K2 | Verordnender | Beantwortung einer Korrekturanfrage | assigned (on-hold) | assigned (in-progress) |
| K3 | Pflegedienst | Rücknahme einer Korrekturanfrage | assigned (on-hold) | assigned (in-progress) |
| K3 | Verordnender | Ablehnung einer Korrekturanfrage | assigned (on-hold) | assigned (in-progress) |
| K4 | Kostenträger | Start einer Korrekturanfrage während einer laufenden Antragsprüfung | assigned (on-hold)
oder open (on-hold) |
assigned (on-hold)
oder open (on-hold) |
| K5 | Verordnender / Pflegedienst | Beantwortung einer Korrekturanfrage und Rückkehr zur Antragsprüfung | assigned (on-hold)
oder open (on-hold) |
assigned (on-hold)
oder open (on-hold) |
| K6 | Kostenträger | Rücknahme einer Korrekturanfrage und Rückkehr zur Antragsprüfung | assigned (on-hold)
oder open (on-hold) |
assigned (on-hold)
oder open (on-hold) |
| K6 | Verordnender / Pflegedienst | Ablehnung einer Korrekturanfrage und Rückkehr zur Antragsprüfung | assigned (on-hold)
oder open (on-hold) |
assigned (on-hold)
oder open (on-hold) |
| AA1 | Fachdienst | Automatischer Abschluss nach Ablauf des Verordnungszeitraums ohne Zuweisung | open (ready)
oder open-reviewed (ready) |
completed (completed) |
| AA2 | Fachdienst | Automatischer Abschluss eines zugewiesenen Vorgangs gemäß den definierten Fachregeln | assigned (in-progress)
oder assigned-reviewed (in-progress) |
completed (completed) |
| AL1 | Fachdienst | Automatische Löschung eines initial angelegten Vorgangs gemäß Löschregeln | initialized (draft) | deleted (cancelled) |
| AL2 | Fachdienst | Automatische Löschung eines abgeschlossenen Vorgangs gemäß Löschregeln | completed (completed) | deleted (cancelled) |
| AL3 | Fachdienst | Automatische Löschung während einer laufenden Antragsprüfung gemäß Löschregeln | assigned (on-hold)
oder open (on-hold) |
deleted (cancelled) |
| ML1 | Verordnender | Manuelle Löschung eines noch nicht bereitgestellten Vorgangs | initialized (draft) | deleted (cancelled) |
| ML2 | Verordnender oder Versicherter | Manuelle Löschung eines offenen Vorgangs | open (ready)
oder open-reviewed (ready) |
deleted (cancelled) |
| ML3 | Versicherter | Manuelle Löschung eines abgeschlossenen Vorgangs | completed (completed) | deleted (cancelled) |
Die Übergänge AP1 bis AP4 beschreiben die Interaktion mit dem Anfrage-Workflow zur Antragsprüfung. Während der Ausführung des Anfrage-Workflows verbleibt die Verordnungs-Task technisch im Zustand on-hold. Der fachliche Kontext bleibt über den Business-Status erhalten.
Die Übergänge K1 bis K6 beschreiben die Interaktion mit dem Anfrage-Workflow für Korrekturen und Anfragen. Da diese Vorgänge innerhalb eines eigenständigen Anfrage-Workflows bearbeitet werden, bleibt die Verordnungs-Task auch hierbei technisch im Zustand on-hold.
Die Übergänge AA1 und AA2 beschreiben automatische Abschlussvorgänge. Die Übergänge AL1 bis AL3 sowie ML1 bis ML3 beschreiben automatische beziehungsweise manuelle Löschvorgänge. Die fachliche Löschung eines Vorgangs wird durch den Business-Status deleted dargestellt, während die technische Markierung zur Löschung über den technischen Status cancelled erfolgt.
In diesem Kapitel wird ein allgemeines Konzept zu einem Anfrage-Workflow beschrieben. Der Anfrage-Workflow wird für HKP-Verordnungen für Korrekturanfragen und Antragsprüfungen verwendet.
Folgende Rollen sind am Anfrage-Workflow beteiligt.
Tabelle 18 : Anfrage-Workflow Rollen
| Rolle | Beschreibung |
|---|---|
| Anfragender | Die Organisation oder Person, die eine Anfrage initiiert – z.B. zur Korrektur eines bestehenden Fachdokumentes. |
| Bearbeitender | Die Organisation oder Person, die eine eingehende Anfrage prüft und darauf reagiert – z.B. durch Annahme, Ablehnung oder Rückmeldung. Der Bearbeitende ist für die fachliche Bewertung und mögliche Umsetzung der vorgeschlagenen Änderungen zuständig. |
| Vorgangsbeteiligte | Die Organisation oder Person, die eine eingehende Anfrage prüft und darauf reagiert – z.B. durch Annahme, Ablehnung oder Rückmeldung. Der Bearbeitende ist für die fachliche Bewertung und mögliche Umsetzung der vorgeschlagenen Änderungen zuständig. |
Ein Anfrage-Workflow bezieht sich auf einen Dokumenten-Workflow. Im Rahmen der Konzeption des Dokumenten-Workflow wird festgelegt, in welchem Status des Dokumenten-Workflows welcher Typ eines Anfrage-Workflows gestartet werden kann.
Es ist sicherzustellen, dass es für einen Dokumenten-Workflow nur einen aktiven Anfrage-Workflow gibt. Dies wird sichergestellt, indem der zugrunde liegende Workflow in den Status on-hold wechselt.
Die technischen Zustände des Anfrage-Workflows sind in der folgenden Tabelle beschrieben:
Tabelle 19 : Anfrage-Workflow - Statusmodell
| Technischer Status | Business Status | Beschreibung |
|---|---|---|
| requested | review-requested | Die Anfrage kann bearbeitet werden. |
| in-progress | review-in-progress | Die Anfrage befindet sich in Bearbeitung. |
| on-hold | review-in-progress | Die Anfrage ist aufgrund einer Anfrage pausiert. |
| completed | review-completed | Die Anfrage wurde abgeschlossen. |
| rejected | review-rejected | Die Anfrage wurde abgelehnt. |
| cancelled | review-cancelled | Die Anfrage wurde abgebrochen. |
Folgende Statusübergänge sind möglich:
Abbildung 10 : Anfrage-Workflow Statusübergänge
Tabelle 20 : Anfrage-Workflow - Statusübergänge
| Übergang von | Übergang nach | auslösender Akteur | Beschreibung | Prozessschritt |
|---|---|---|---|---|
| requested | Anfragender | Ein Anfragender erstellt in seinem PS eine Anfrage mit Bezug auf einen Dokumenten-Workflow und stellt diese in den Fachdienst ein. | Anfrage starten | |
| requested | in-progress | Bearbeitender | Das PS des Bearbeitenden lädt den Anfrage-Workflow vom Fachdienst. Das kann automatisch oder auf Interaktion des Mitarbeiters der Institution erfolgen. Das PS stellt die Information bereit.
Hinweis: Wenn der Mitarbeiter mit der Bearbeitung der Anfrage beginnt, prüft das PS den Status des Anfrage-Workflows. Wenn der Status "requested" ist, dann meldet das PS den Start der Bearbeitung an den Fachdienst (erneute Änderung des Status von requested zu in-progress). Wenn der Status "cancelled" ist, dann informiert das PS den Mitarbeiter, dass die Anfrage durch den Anfragenden storniert wurde. |
Anfrage zur Bearbeitung abrufen |
| in-progress | requested | Fachdienst | Wenn am Ende des Tages der Anfrage-Workflow den Status in-progress hat, d.h. die Bearbeitung der Anfrage nicht abgeschlossen wurde, dann wird der Status des Anfrage-Workflows auf requested geändert. | Anfrage freigeben |
| in-progress | on-hold | Bearbeitender | Der Bearbeitende initialisiert einen separaten Anfrage-Workflow mit Bezug auf diesen Anfrage-Workflow. | |
| on-hold | in-progress | Fachdienst | Der separate Anfrage-Workflow wurde beendet. | |
| in-progress | completed | Bearbeitender | Der Bearbeitende bearbeitet die Anfrage und stellt das Ergebnis, bspw. eine neue Version des Fachdokumentes, im Fachdienst bereit. | Anfrage abschließen |
| in-progress | rejected | Bearbeitender | Der Bearbeitende prüft die Anfrage und entscheidet, die Anfrage abzulehnen. Das PS des Bearbeitenden übermittelt die Entscheidung an den Fachdienst. | Anfrage ablehnen |
| requested | cancelled | Anfragender | Der Anfragende entscheidet die Anfrage zu stornieren. Das PS des Anfragenden übermittelt die Information an den Fachdienst. | Anfrage abbrechen |
Zusätzlich zum technischen Statusmodell kann ein Business Statusmodell spezifiziert werden.
Für jede Anfrage werden folgende Informationen im Anfrage-Workflow verwaltet:
Tabelle 21 : Anfrage-Workflow - Fachliches Datenmodell
| Fachliche Informationseinheit | Beschreibung | Quelle | Kardinalität |
|---|---|---|---|
| ID Anfrage-Workflow | Identifier der Anfrage | generiert vom Fachdienst | 1 |
| ID Fach-Workflow | Referenz zum Dokumenten-Workflow | übernommen aus .partOf oder
aus Operationsaufruf |
1 |
| ID zugrundeliegender Workflow | Referenz zum Workflow von dem die Anfrage gestartet wurde. | Übernommen aus Operationsaufruf | 1 |
| Anfragender | Initiator der Anfrage | Access_Token der Anfrage | 1 |
| Bearbeitender | Adressat der Anfrage. Muss berechtigt sein, auf den zugrundeliegenden Task zu bearbeiten, um die Anfrage zu lösen. | Wert im Body der Anfrage | 1 |
| Vorgangsbeteiligte | Institutionen, welche über die Anfrage informiert werden | Versicherter aus Task.for des zugrundeliegenden Tasks | 0 ... n |
| Typ der Anfrage | Welche Art von Anfrage gestellt wird | Wert im Body der Anfrage | 1 |
| Status | Technischer Status der Anfrage | gesetzt durch Fachdienst | 1 |
| Business Status | Business Status der Anfrage | gesetzt durch Fachdienst | 0 ... 1* |
| Anfragedokument | Dokument mit den Änderungsvorschlägen zum Fachdokument
(bspw. Fachdokument im Entwurfsstatus) |
generiert durch Fachdienst | 0 ... 1* |
| Ablehnungsgrund | Grund für eine Ablehnung der Anfrage | Wert im Body der Anfrage | 0 ... 1 |
* Die Kardinalität ist im Rahmen der Spezifikation des Types der Anfrage festzulegen.
Beim Erstellen einer Anfrage wird hinterlegt, welche Institutionen Anfragende, Bearbeitende und Vorgangsbeteiligte sind.
Die anfragende Institution erstellt den Anfrage-Workflow und kann den Status entsprechend dem Statusmodell des Anfrage-Workflows ändern.
Die bearbeitende Institution kann lesend auf die Anfrage zugreifen, den Status entsprechend dem Statusmodell ändern und ggf. Grund für die Ablehnung der Anfrage hinzufügen.
Vorgangsbeteiligte können lesend Anfrage-Workflows zugreifen.
Anfragende, Bearbeitende und Vorgangsbeteiligte können zu jeder Zeit den Status des Anfrage-Workflows am Fachdienst abfragen.
Ein Anfrage-Workflow hat immer einen Bezug zu einem Dokumenten-Workflow. Er wird mit Referenz zu dem Dokumenten-Workflow im Fachdienst gespeichert.
Nach Beendigung eines Anfrage-Workflows werden die Daten des Anfrage-Workflows zu folgenden Zwecken vorgehalten:
Die Daten des Anfrage-Workflows werden zusammen mit dem Dokumenten-Workflow gelöscht.
Der Anfrage-Workflow ist in der ersten Ausbaustufe ein einfacher Statusautomat, der keine Schleifen zulässt, sondern linear durch einen Automaten führt. Damit ergeben sich aus Sicht der Clients die folgenden Prozessschritte:
Tabelle 22 : Anfrage-Workflow - Rolle mit Statusübergang
| Rolle | Aktion | Statuswechsel |
|---|---|---|
| Anfragender | Verfügbare Anfragebögen abrufen | nein |
| Anfragender | Anfrage starten | ja |
| Anfragender | Anfrage abbrechen | ja |
| Anfragender, Bearbeitender, Vorgangsbeteiligte | Anfrageinformationen | nein |
| Bearbeitender | Anfrage zur Bearbeitung abrufen | ja |
| Bearbeitender | Anfrage abschließen | ja |
| Bearbeitender | Anfrage ablehnen | ja |
| Fachdienst | Anfrage freigeben | ja |
Um einen Anfrage-Workflow zu starten muss der Anfragende den für die Anfrage gültigen Anfragebogen kennen. Dadurch ist sichergestellt, dass für den jeweiligen Task das korrekte Formular verwendet wird. Der Anfragende muss wissen,
Daher wird für jeden Endpunkt eine optionale Operation bereitgestellt, die für den jeweiligen Task die verfügbaren Questionnaires abrufbar macht. Ein Primärsystem, was eine generische Formular-Render-UI verwendet, kann hiervon profitieren und automatisch die aktuell gültigen Formulare runterladen. Einem Primärsystem steht es aber auch frei die Questionnaireresponse im Code zu programmieren und damit auf diesen Aufruf zu verzichten.
Ist die Antwort des E-Rezept-Fachdienst eine leere Liste, impliziert das, dass für die Kombination aus technischem und fachlichem Status kein Anfrage-Workflow erlaubt ist.
Tabelle 23 : Anfrage-Workflow - Operation "$get-request-forms"
| API | GET /hkp/Task/<task-id>/$get-request-forms |
|---|---|
| Header | Authorization: Bearer <access_token> |
| Body | - |
| Response | Parameters( [ (anfragetyp, Questionnaire) ] ) |
Um den Anfrage-Task zur Bearbeitung zu starten müssen die fachlichen Parameter der Anfrage bereitgestellt werden. Dies können zum Beispiel Inhalte zu einer Korrektur eines Anfragenden sein.
Diese werden in Form von QuestionnaireResponses bereitgestellt, die inhaltlich zu dem Questionnaire passen müssen, das bei der Initialisierung der Anfrage bereitgestellt wurde.
Wenn die Anfrage erfolgreich erstellt wurde, wird der Anfrage-Task erstellt und in den entsprechenden Status gestellt. Der Bearbeitende der Anfrage wird informiert, dass der Task vorliegt.
Die Anfrage wird dann auf dem Subtask mit dem QuestionnaireResponse aktiviert.
Tabelle 24 : Anfrage-Workflow - Operation "$request-subworkflow"
| API | POST /hkp/Task/<basedOn-task-id>/$request-subworkflow |
|---|---|
| Header | Authorization: Bearer <access_token> |
| Body | Parameters( (anfragetyp, angefragte-telematik-id, QuestionnaireResponse) ) |
| Response | Anfrage-Task
|
Der E-Rezept-Fachdienst stellt sicher, dass das QuestionnaireResponse mit Anfragetyp zum aktuellen Task passt und dass für eine Korrektur eine QuestionnaireResponse vorhanden ist.
Aus verschiedenen Gründen kann der Anfragende sich entscheiden, eine Anfrage im Status requested abzubrechen.
Der Anfrage-Task wird abgebrochen und kann nicht weiter bearbeitet werden. Der Task, der dem Anfrage-Task zugrunde liegt wird in den vorherigen fachlichen und technischen Status gesetzt.
Tabelle 25 : Anfrage-Workflow - Operation "$cancel-subworkflow"
| API | POST /hkp/Task/<anfrage-task-id>/$cancel-subworkflow |
|---|---|
| Header | Authorization: Bearer <access_token> |
| Body | - |
| Response | Anfrage-Task |
Teilnehmende des Prozesses können jederzeit Informationen zu einem Anfrage Task abrufen, ohne dabei den Status des Workflows zu beeinflussen. Insbesondere können sie so den Status des Anfrage Task ermitteln.
Die Abfrage erfolgt nach Standard-FHIR Mechanismen.
Tabelle 26 : Anfrage-Workflow - Suche Anfrage-Task
| API | GET /hkp/Task/<anfrage-task-id>
?owner=<telematik-id-bearbeitender> &requester=<telematik-id-anfragender> &patient=<kvnr-versicherter> |
|---|---|
| Header | Authorization: Bearer <access_token> |
| Body | - |
| Response | Anfrage-Task |
Es ist ebenfalls möglich, eine Liste an Tasks zu bekommen, in denen man Teilnehmer, Bearbeitender oder Anfragender ist. Der Aufruf kann mit entsprechenden Queryparametern gesteuert werden.
Tabelle 27 : Anfrage-Workflow - Suche Bundle Anfrage-Tasks
| API | GET /hkp/Task
?owner=<telematik-id-bearbeitender> &requester=<telematik-id-anfragender> &patient=<kvnr-versicherter> |
|---|---|
| Header | Authorization: Bearer <access_token> |
| Body | - |
| Response | Bundle(Anfrage-Task) |
offener Punkt: Abfrage des Anfragedokuments und QuestionnaireResponse kann über den DocumentStore erfolgen. Konzept s. "Workflowbegleitende Dokumente"
Das Ausführen dieser Query Funktionen verändert nicht den Status einer Anfrage, sondern dient der Darstellung von Listen und Detailansichten zu laufenden Anfragen.
Der Bearbeitende ruft mit der Operation die fachlichen Informationen der Anfrage ab. Der Fachdienst setzt damit die Status am Anfrage-Task in der Art, dass ausschließlich der Bearbeitende den Status ändern kann.
Da die QuestionnaireResponse eine einfache Datenstruktur ist, wird beim Aufruf zum Akzeptieren einer Anfrage diese Struktur übermittelt. Sie enthält in kondensierter Form, was der Anfragende möchte.
Der Bearbeitende, bzw. das Clientsystem hat die Möglichkeit auch eine gerenderte Version der Anfrage zu erhalten. Der Fachdienst ist in der Lage je nach Anfrage-Workflow ein Anfragedokument zu erzeugen, was dem Clientsystem ermöglicht strukturiert die Informationen bereitzustellen, wie sich der Anfragende das finale Dokument vorstellt.
Die Anfrage wird vom Bearbeitenden abgerufen. Das PS erhält den Anfrage-Task mit administrativen Informationen, sowie dem QuestionnaireResponse, welches die angefragten Änderungen enthält.
Tabelle 28 : Anfrage-Workflow - Operation "$accept-subworkflow"
| API | POST /hkp/Task/<anfrage-task-id>/$accept-subworkflow |
|---|---|
| Header | Authorization: Bearer <access_token> |
| Body | - |
| Response | Bundle(Anfrage-Task, KorrekturvorschlagFHIR-Doc)
|
offener Punkt: Abfrage des Anfragedokuments und QuestionnaireResponse kann über den DocumentStore erfolgen. Konzept s. "Dokumenten Store"
Das Clientsystem hat außerdem die Möglichkeit, die vom FD zentral implementierte Anpassungslogik zu nutzen, um ein Anfragedokument zu erhalten:
Tabelle 29 : Anfrage-Workflow - Operation "$get-proposal"
| API | POST /hkp/Task/<anfrage-task-id>/$get-proposal |
|---|---|
| Header | Authorization: Bearer <access_token> |
| Body | - |
| Response | Document-Bundle |
Das Clientsystem hat nach Abschluss dieses Schrittes alle Informationen vorhanden, um die Anfrage zu bearbeiten.
Wenn der Status eines Anfrage-Tasks sich im Status in-progress befindet, hat der Bearbeitender bis zum Ende des laufenden Tages Zeit, einen weiteren Statuswechsel zu triggern. Wenn das nicht geschieht, setzt der Fachdienst den Anfrage-Task zurück auf den Status requested.
Die Ausführung erfolgt nach definiertem Zeitpunkt im Fachdienst.
Der Bearbeitende der Anfrage evaluiert den vom Clientsystem präsentierten Inhalt. Der Bearbeitende kann die Anfrage im nächsten Schritt annehmen. In diesem Fall wird die Anfrage abgeschlossen und der Fach-Task in seinen ursprünglichen technischen Status versetzt. Der fachliche Status kann sich je nach Anfrageart in einen anderen Status übergehen. Die Logik dazu wird Anfragetyp-spezifisch im Fachdienst definiert.
Diese Funktion wird genutzt unabhängig davon, ob inhaltlich die Anfrage gänzlich, zum Teil oder gar nicht umgesetzt wurde. Der Abschluss einer Anfrage bedeutet, dass die Anfrage bearbeitet wurde und der Anfragende zu einem Entscheid gekommen ist.
Wurde die Anfrage bearbeitet, kann in einem Aufruf das Ergebnis der Bearbeitung bereitgestellt werden, um den Vorgang zu schließen.
Je nach Anwendungsfall wird der DocumentStore aktualisiert. Übermittelte Daten werden im Anfrage-Task.output hinterlegt und stehen damit den Prozessbeteiligten zur Verfügung.
Tabelle 30 : Anfrage-Workflow - Operation "$close-subworkflow"
| API | POST /hkp/Task/<anfrage-task-id>/$close-subworkflow |
|---|---|
| Header | Authorization: Bearer <access_token> |
| Body | CompleteSubworkflowParameters
|
| Response | Anfrage-Task
|
offener Punkt: wie kann der Bearbeiter dem Anfragenden zusätzliche Informationen bereitstellen? Freitext, kodiert?
Der Bearbeitende der Anfrage evaluiert den vom Clientsystem präsentierten Inhalt. Der Bearbeitende kann die Anfrage im nächsten Schritt ablehnen. In diesem Fall wird die Anfrage beendet und der Fach-Task in seinen ursprünglichen technischen und fachlichen Status versetzt.
Dieser Aufruf ist nicht dafür gedacht eine Anfrage inhaltlich abzulehnen, sondern diese nicht zu bearbeiten (bspw. bei Unzuständigkeit).
Wird die Anfrage abgelehnt, muss ein Grund angegeben werden.
Tabelle 31 : Anfrage-Workflow - Operation "$reject-subworkflow"
| API | POST /hkp/Task/<id>/$reject-subworkflow |
|---|---|
| Header | Authorization: Bearer <access_token> |
| Body | Parameters(reject-reason) |
| Response | Anfrage-Task |
Für den Anfrage-Workflow wird angestrebt ein Pattern zu etablieren, welches in zukünftigen Anfragearten wiederverwendet werden kann. Erreicht werden soll, dass Datenstrukturen definiert werden, die konzeptuell generisch sind und für einen spezifischen Use-Case angepasst werden können.
Dabei sollen Funktionen im E-Rezept-Fachdienst ermöglichen, Operationen auf Dokumenten auszuführen, oder neue FHIR-Ressourcen zu erzeugen. Hierzu existiert der [Implementation Guide SDC], der für dieses Ziel Anweisungen gibt und dessen Funktionalitäten genutzt werden.
Im Anfrage-Workflow (bspw. "HKP Korrektur-Anfrage eines Pflegedienstes an den Verordnenden") muss ein Anfragender strukturiert mitteilen können, was an einem Fachdokument geändert werden soll. Anstatt für jede Anfrageart ein eigenes, proprietäres Datenformat zu definieren, wird ein generisches Pattern auf Basis von FHIR Questionnaire / QuestionnaireResponse und dem internationalen Standard SDC (Structured Data Capture) etabliert.
Der fachlich Verantwortliche für ein FHIR-Dokument beschreibt deklarativ in einem Questionnaire, was an diesem Dokument korrigierbar ist – der E-Rezept-Fachdienst führt die Anfrage anschließend generisch aus.
FHIR stellt mit Questionnaire und QuestionnaireResponse ein flexibles Pattern für Fragebögen und deren Beantwortung bereit. Jede Frage im Fragebogen ist über eine eindeutige linkId sowie den zulässigen Datentyp der Antwort beschrieben:
Tabelle 32 : Struktur eines Questionnaire (schematisch)
| Element | Kardinalität | Beschreibung |
|---|---|---|
| Questionnaire.url, .name | 1..1 | Identifizierende Metadaten des Fragebogens |
| Questionnaire.item | 0..* | Eine Frage bzw. eine Gruppe von Fragen |
| - item.linkId | 1..1 | Eindeutige ID der Frage; wird von der zugehörigen Antwort referenziert |
| - item.type | Zulässiger Datentyp der Antwort (group, boolean, decimal, choice, ,...) |
Eine QuestionnaireResponse referenziert das zugehörige Questionnaire und enthält eine Liste von Antworten. Jede Antwort trägt dieselbe linkId wie die zugehörige Frage im Questionnaire:
Tabelle 33 : Struktur einer QuestionnaireResponse (schematisch)
| Element | Kardinalität | Beschreibung |
|---|---|---|
| QuestionnaireResponse.questionnaire | 1..1 | Referenz auf das beantwortete Questionnaire |
| QuestionnaireResponse.item | 0..* | Eine Antwort bzw. eine Gruppe von Antworten |
| - item.linkId | 1..1 | ID der beantworteten Frage; muss mit dem Questionnaire übereinstimmen |
| - item.answer.value[x] | 1..1 | Der konkrete Antwortwert |
| - item.item | 0..* | Weitere, verschachtelte Antworten |
Über ein answerValueSet kann eingeschränkt werden, welche Antworten fachlich zulässig sind. Der E-Rezept-Fachdienst stellt eine generische Implementierung bereit, die beim Einstellen einer QuestionnaireResponse strukturell prüft, ob die Antworten zum referenzierten Questionnaire passen (u. a. Vorhandensein korrekter linkIds und Übereinstimmung der Datentypen).
Abbildung 11: Validierung von QuestionnaireResponse zu Questionnaire
Der reine Frage-Antwort-Mechanismus reicht allein nicht aus, um daraus automatisiert Änderungen an einem FHIR-Dokument abzuleiten. Der [Implementation Guide SDC] zeigt hierfür Erweiterungsmechanismen, mit denen ein Questionnaire nicht nur Antworten einsammelt, sondern auch beschreibt, wie aus diesen Antworten FHIR-Daten extrahiert, in neue FHIR-Ressourcen transformiert oder bestehende FHIR-Ressourcen manipuliert werden.
Der Ablauf ist dabei immer gleich:
Damit ergibt sich eine klare Trennung von Verantwortlichkeiten auf drei FHIR-Artefakte:
Tabelle 34: Questionnaire FHIR-Artefakte
| FHIR-Artefakt | Rolle | Verantwortung |
|---|---|---|
| Questionnaire-Profil | Verantwortlicher für den E-Rezept-Fachdienst (gematik) | Definiert die technischen Möglichkeiten am Fachdienst: welche Operationstypen und Erweiterungen es gibt. Jede Funktionalität ist dort mit Geschäftslogik im Fachdienst hinterlegt. |
| Questionnaire-Instanz | Fachlich Verantwortlicher für das FHIR-Dokument (z. B. KBV) | Definiert fachlich, was an einer konkreten Dokumentversion korrigiert werden darf – und wohin die Werte geschrieben werden (bspw. per FHIR-Path). |
| QuestionnaireResponse | Anfragender (z. B. Pflegeprimärsystem des Pflegedienstes) | Enthält die konkrete Korrektur-Anfrage: die ausgefüllten Antworten. |
Diese Trennung hält den Aufwand für alle Beteiligten klein: Der fachlich Verantwortliche erstellt genau eine Questionnaire-Instanz je Dokumentversion.
Validierung, Ausführung und Speicherung übernimmt der Fachdienst generisch – für alle heutigen und künftigen Anfragearten gleichermaßen.
Der Mechanismus wird im Folgenden am Beispiel der Korrektur eines HKP-Verordnungsdatensatzes (FHIR-Document) beschrieben.
Hierzu müssen die folgenden Artefakte beschrieben sein:
Tabelle 35: Questionnaire FHIR-Artefakte Korrektur
| Artefakt | Autor | Beschreibung |
|---|---|---|
| Questionnaire-Profil | gematik | Das QuestionnaireProfil ist eine Profilierung der FHIR-Ressource "Questionnaire".
Es definiert konkrete items, die jeweils Funktionalitäten am E-Rezept-Fachdienst auslösen können. |
| Questionnaire-Instanz | KBV | Der fachliche Verantwortliche eines FHIR-Documents erstellt ein Questionnaire, was vom Questionnaire Profil ableitet.
Dieses Questionnaire definiert konkrete Fragen (items), die fachlich zulässige angaben enthalten können. Im Questionnaire angegeben sind hierzu auch die entsprechenden Datentypen, die für die Antwort zulässig ist. |
Das Questionnaire-Profil erlaubt in einem Korrektur-Questionnaire genau drei Arten von Top-Level-Items, die beliebig kombiniert und wiederholt werden können:
Alle drei Operationstypen sind wiederholbar – eine einzige Anfrage kann somit mehrere Korrekturen gleichzeitig transportieren, etwa das Hinzufügen einer neuen Maßnahme und gleichzeitig das Entfernen einer anderen.
Der E-Rezept-Fachdienst führt zwei getrennte Schritte aus:
Der Bearbeitende erhält auf diesem Weg den Korrekturvorschlag als vollständiges, lesbares Dokument und muss die einzelnen Änderungsoperationen nicht selbst nachvollziehen.
Das folgende Beispiel zeigt den einfachsten der drei Operationstypen: Ein Pflegedienst bittet den Verordnenden, den Startzeitpunkt der Verordnung zu verschieben.
Technisch werden die drei Operationstypen über ein Questionnaire-Profil festgelegt. Das Profil schreibt dabei nur den generischen Mechanismus fest – nicht die konkreten fachlichen Datenfelder einer einzelnen Anfrageart. Die folgende Tabelle zeigt, welche Elemente und Erweiterungen das Profil je Operationstyp vorschreibt:
Tabelle 36 : Struktur der drei Operationstypen im Questionnaire-Profil
| Operationstyp | Element | Kardinalität | Bedeutung |
|---|---|---|---|
| ressourceHinzufuegen | item (Gruppe, wiederholbar) | 0..* | Kennzeichnet, dass eine neue Ressource erzeugt werden soll
(gekürzt) |
| ressourceAendern | item (Gruppe, wiederholbar) | 0..* | Kennzeichnet, dass ein bestehender Wert geändert werden soll |
| Unterfrage „neuer Wert" | 1..1 | Trägt den zu setzenden Wert | |
| Erweiterung erpTargetPath (an der Wert-Unterfrage) | 1..1 | FHIRPath auf das Zielfeld im Dokument | |
| Unterfrage „ID der Ressource" | 0..1 | Optional: identifiziert die konkrete Ressource, falls das Zielfeld nicht eindeutig ist | |
| ressourceLoeschen | item (Referenz, wiederholbar) | 0..* | Kennzeichnet, dass eine Ressource entfernt werden soll
(gekürzt) |
Im Questionnaire ist dazu eine Gruppe ressourceAendern.startdatum hinterlegt, die genau eine Unterfrage für den neuen Wert enthält. Diese Unterfrage trägt die Erweiterung erp-target-path, die per FHIRPath angibt, wohin der Wert im Dokument geschrieben wird::
| {
"linkId": "ressourceAendern.startdatum", "text": "Anpassung des Startzeitpunktes der Verordnung", "type": "group", "repeats": true, "item": [ { "linkId": "ressourceAendern.startdatum.value", "type": "date", "extension": [ { "url": "https://gematik.de/fhir/erp/hkp/StructureDefinition/erp-target-path", "valueString": "Bundle.entry.ofType('CarePlan').first().period.start" } ] } ] } |
Das Pflegeprimärsystem füllt hierzu die QuestionnaireResponse aus – sie bildet ausschließlich das Delta zum Original ab, nicht das gesamte Dokument:
| {
"resourceType": "QuestionnaireResponse", "status": "completed", "questionnaire": "https://gematik.de/fhir/tiflow/hkp/Questionnaire/KBVHKPKorrekturVerordnung", "item": [{ "linkId": "ressourceAendern.startdatum", "item": [{ "linkId": "ressourceAendern.startdatum.value", "answer": [{ "valueDate": "2026-08-15" }] }] }] } |
Ruft der Verordnende anschließend das Anfragedokument ab, schreibt der Fachdienst den neuen Wert `2026-08-15` an die im FHIRPath referenzierte Stelle – `CarePlan.period.start` – in der Kopie des Verordnungsdatensatzes. Alle übrigen Felder des Dokuments bleiben unverändert. Der Verordnende sieht das vollständige Dokument mit dem neuen Startdatum und entscheidet, ob er die Änderung durch eine neue, signierte Verordnung übernimmt.
Der Questionnaire-Ansatz drückt eine Korrekturanfrage als kompaktes, validierbares Delta aus, statt den Verordnungsdatensatz selbst zu verändern. Die Verantwortlichkeiten sind dabei klar getrennt: Der Verantwortliche für den E-Rezept-Fachdienst definiert im Questionnaire-Profil einmalig, welche Operationen technisch möglich sind. Der fachlich Verantwortliche für das FHIR-Dokument legt je Dokumentversion fest, was fachlich korrigiert werden darf und wohin die Werte geschrieben werden. Der Anfragende füllt lediglich den Fragebogen aus.
Der Fachdienst validiert jede Antwort automatisch gegen das Questionnaire und erzeugt bei Bedarf das Anfragedokument als Kopie des Fachdokuments mit angewendeten Korrekturen, während das Original unverändert bleibt. Für die fachlich Verantwortlichen bedeutet das: Der Einstieg in eine neue Korrekturart erfordert kein Fachdienst-Release, sondern lediglich ein weiteres Questionnaire nach dem etablierten Profil.
Dieser Ansatz lässt sich nicht nur für die Korrekturanfrage, sondern jede beliebige Anfrageart für Anfrage-Workflows nachnutzen.
offener Punkt: zu klären ist, ob für den MVP von HKP zunächst nur Freitextinformationen und kodierte Werte im QuestionnaireResponse übertragen werden sollen und der Bearbeiter der Anfrage dann selbst aktiv wird und die gewünschten Änderungen umsetzt. Das ermöglicht, dass zunächst nur das Konzept von Anfrageworkflows mit Statusmodell umgesetzt wird und die komplexe und automatisierte Anpassung von FHIR-Documents dann in einer weiteren Ausbaustufe umgesetzt wird. Das minimiert Aufwände in der Erstellung der Spezifikation, Testen der Spezifikation und Implementierung im E-Rezept-Fachdienst sowie den PS.
In diesem Abschnitt werden die für HKP-Verordnung genutzten Ausprägungen des Anfrage-Workflows beschrieben.
Die Anfrage-Workflows für Korrekturen beziehen sich auf die im Fachkonzept dargestellten Korrekturen zum Verrodnungsdatensatz bzw. Blankoverordnungsdatensatz. Es besteht die Möglichkeit das Konzept um Anfrage-Workflows für fehlende Dokumente, zu erweitern.
Tabelle 37: Anfrage-Workflow - HKP Antragsprüfung durch Versicherten
| HKP Antragsprüfung durch Versicherten | |
|---|---|
| Dokumenten-Workflow | HKP-Verordnungs-Workflow |
| Typ des Anfrage-Workflow | Antragsprüfung bei Kostenträger durch Versicherten |
| Zulässiger Initiator (Anfragender) | Versicherter, welchem die Verordnung zugewiesen ist * |
| Bearbeitender | Kostenträger |
| Vorgangsbeteiligte | Verordnender |
| Status des Verordnungs-Workflows
vor Start des Anfrage-Workflows: während des Anfrage-Workflows: nach Beendigung des Anfrage-Workflows: mit $close-subworkflow: nach Beendigung des Anfrage-Workflows mit $cancel-subworkflow oder $reject-subworkflow: |
open (ready)
open (on-hold) open-reviewed (ready) open (ready) |
| Trigger aus Dokumenten-Workflow für Status completed | |
| Statuswechsel zu on-hold möglich | ja |
| zulässige Anfrage-Workflows in Status in-progress | HKP Korrektur-Anfrage eines Kostenträgers an den Verordnender |
* Für den Fall, dass der Versicherte kein Frontend des Versicherten nutzt, um diesen Anfrage-Workflow zu starten und bspw. sich telefonisch bei seinem Kostenträger meldet, dann kann zur Umsetzung des Statusmodells, der Kostenträger den Anfrage-Workflow in Vertretung für den Versicherten starten.
Tabelle 38: Anfrage-Workflow - HKP Antragsprüfung durch Pflegedienst
| HKP Antragsprüfung durch Pflegedienst | |
|---|---|
| Dokumenten-Workflow | HKP-Verordnungs-Workflow |
| Typ des Anfrage-Workflow | Antragsprüfung bei Kostenträger durch Pflegedienst |
| Zulässiger Initiator (Anfragender) | Pflegedienst, welcher die Verordnung zugewiesen ist |
| Bearbeitender | Kostenträger |
| Vorgangsbeteiligte | Versicherter
Verordnender |
| Status des Verordnungs-Workflows
vor Initialisierung des Anfrage-Workflows: während des Anfrage-Workflows: nach Beendigung des Anfrage-Workflows mit $close-subworkflow: nach Beendigung des Anfrage-Workflows mit $cancel-subworkflow oder $reject-subworkflow: |
assigned (in-progress) assigned (on-hold) assigned-reviewed (in-progress) assigned (in-progress) |
| Trigger aus Dokumenten-Workflow für Status completed | Einstellen einer Leistungsentscheidung zur Verordnung |
| Statuswechsel zu on-hold möglich | ja |
| zulässige Anfrage-Workflows in Status in-progress | HKP Korrektur-Anfrage eines Kostenträgers an den Verordnenden
HKP Korrektur-Anfrage eines Kostenträgers an den Pflegedienst |
Eine Pflegedienst hat die Möglichkeit eine Korrekturanfrage an den Verordnenden zu stellen.
Tabelle 39: Anfrage-Workflow - HKP Korrektur-Anfrage Pflegedienst Verordnender
| HKP Korrektur-Anfrage Pflegedienst Verordnender | |
|---|---|
| Dokumenten-Workflow | HKP-Verordnungs-Workflow |
| Typ des Anfrage-Workflow | Korrekturworkflow Pflegedienst Verordnender |
| Zulässiger Initiator (Anfragender) | Pflegedienst, welcher die Verordnung zugewiesen ist |
| Bearbeitender | verordnende LEI |
| Vorgangsbeteiligte | Versicherter
Kostenträger, falls in Kenntnis der Verordnung |
| Status des Verordnungs-Workflows
vor Start des Korrektur-Workflows: während des Korrektur-Workflows: nach Beendigung des Korrektur-Workflows: |
assigned (in-progress) assigned (on-hold) assigned (in-progress) |
| Trigger aus Dokumenten-Workflow für Status completed | Einstellen einer neuen Version der Verordnung |
| Statuswechsel zu on-hold möglich | nein |
Tabelle 40: Anfrage-Workflow - HKP Korrektur-Anfrage Kostenträger Verordnender
| HKP Korrektur-Anfrage Kostenträger Verordnender | |
|---|---|
| Dokumenten-Workflow | HKP-Verordnungs-Workflow |
| Typ des Anfrage-Workflow | Korrekturworkflow Kostenträger Verordnender |
| Zulässiger Initiator (Anfragender) | Kostenträger, welcher in der Verordnung angegeben ist |
| Bearbeitender | verordnende LEI |
| Vorgangsbeteiligte | Versicherter
Pflegedienst, falls Verordnung bereits zugewiesen ist |
| Status des Verordnungs-Workflows
Variante 1: vor Start des Korrektur-Workflows: während des Korrektur-Workflows: nach Beendigung des Korrektur-Workflows: Variante 2: vor Start des Korrektur-Workflows: während des Korrektur-Workflows: nach Beendigung des Korrektur-Workflows: |
open (on-hold) open (on-hold) open (on-hold) assigned (on-hold) assigned (on-hold) assigned (on-hold) |
| Status des aktiven Antragsprüfungsworkflows
vor Start des Korrektur-Workflows: während des Korrektur-Workflows: nach Beendigung des Korrektur-Workflows: |
in-progress on-hold in-progress |
| Trigger aus Dokumenten-Workflow für Status completed | Einstellen einer neuen Version der Verordnung |
| Statuswechsel zu on-hold möglich | nein |
Tabelle 41: Anfrage-Workflow - HKP Korrektur-Anfrage Kostenträger Pflegedienst
| HKP Korrektur-Anfrage Kostenträger Pflegedienst | |
|---|---|
| Dokumenten-Workflow | HKP-Verordnungs-Workflow |
| Typ des Anfrage-Workflow | Korrekturworkflow Kostenträger Pflegedienst |
| Zulässiger Initiator (Anfragender) | Kostenträger, welcher in der Verordnung angegeben ist |
| Bearbeitender | Pflegedienst, welcher die Verordnung zugewiesen ist |
| Vorgangsbeteiligte | Versicherter
Verordnender |
| Status des Verordnungs-Workflows
vor Start des Korrektur-Workflows: während des Korrektur-Workflows: nach Beendigung des Korrektur-Workflows: |
assigned (on-hold) assigned (on-hold) assigned (on-hold) |
| Status des aktiven Antragsprüfungsworkflows
vor Start des Korrektur-Workflows: während des Korrektur-Workflows: nach Beendigung des Korrektur-Workflows: |
in-progress on-hold in-progress |
| Trigger aus Dokumenten-Workflow für Status completed | Einstellen einer neuen Version der Blankoverordnung |
| Statuswechsel zu on-hold möglich | nein |
Im Rahmen der HKP-Verordnung werden folgende Datensätze durch den Fachdienst verwaltet:
Tabelle 42: HKP Datenmodelle
| Datensatz | Format | Verantwortlich | Referenz
(Kap.) |
|---|---|---|---|
| Verordnungsdatensatz | FHIR-Document | KBV, GKV-SV | 8 |
| Blankoverordnungsdatensatz | FHIR-Document | GKV-SV mit Pflegeverbänden | 8 |
| Angaben zur Leistungserbingung des PD | FHIR-Document | GKV-SV mit Pflegeverbänden | 8 |
| Verordnungsdatensatz - Korrekturvorschlag | FHIR-Questionnaire | KBV, GKV-SV | 8 |
| Blankoverordnungsdatensatz - Korrekturvorschlag | FHIR-Questionnaire | GKV-SV mit Pflegeverbänden | 8 |
| Kostenerstattungsanfrage-Bundle (Kostenerstattungsprinzip)
(Verordnungsdatensatz, ggf. Blankoverordnungsdatensatz und Eintrag des gewählten Pflegedienstes aus dem Verzeichnisdienst) |
GKV: Abruf aus Task
PKV: Export als PDF/A3 |
Stylesheets durch Verantwortliche der FHIR-Documents | 6.7.2 |
| Entscheidungsdatensatz | FHIR-Document | GKV-SV | 8 |
| Rechnungsbegründende Unterlage
(Verordnungsdatensatz, ggf. Blankoverordnungsdatensatz) |
PKV: Export als PDF/A3 | Stylesheets durch Verantwortliche der FHIR-Documents | 7.1.7 |
| Verordnungsworkflow | FHIR-Task | gematik | |
| Anfrage-Workflow | FHIR-Task | gematik | 11.3.3 |
In diesem Abschnitt wird ein workflow-typ übergreifendes Konzept für workflow-begleitende Dokumente beschrieben.
Zur Unterstützung dokumentenbasierter Fachworkflows wird für jeden Workflow eine Dokumentenhaltung bereitgestellt. Die Dokumentenhaltung dient der Ablage, Verwaltung und Referenzierung von Dokumenten, die während der Bearbeitung eines Workflows entstehen oder verarbeitet werden. Hierzu zählen beispielsweise Verordnungen, qualifizierte elektronische Signaturen (QES), Korrekturdokumente, Prüfentscheidungen sowie weitere workflowbegleitende Dokumente in Form von PDF/A-Dokumenten oder FHIR-Dokumenten.
Die Architektur orientiert sich am IHE-Profil Mobile Access to Health Documents (MHD). MHD ist ein international etablierter Standard zur Verwaltung und zum Austausch medizinischer Dokumente auf Basis von HL7 FHIR. Das Profil definiert hierfür FHIR-Ressourcen und Profile, insbesondere DocumentReference zur Beschreibung von Dokumentmetadaten, sowie standardisierte Interaktionen zur Veröffentlichung, Suche und zum Abruf von Dokumenten.
Die in MHD definierten Interaktionen zur Veröffentlichung, Suche und zum Abruf von Dokumenten dienen als konzeptionelle Vorlage für die Dokumentenhaltung, werden jedoch nicht vollständig oder unverändert übernommen. Stattdessen werden die für die Fachworkflows erforderlichen Mechanismen in workflowbezogenen Operationen umgesetzt. Dabei werden die etablierten FHIR-Ressourcen und Profile des MHD-Dokumentenmodells verwendet. Dadurch müssen Primärsysteme Dokumente und Dokumentmetadaten nicht nach einem neuen, workflowspezifischen Datenmodell interpretieren, sondern können auf bereits bekannten FHIR-Strukturen aufbauen.
Die Orientierung an IHE MHD erfolgt bewusst, da MHD-basierte Konzepte bereits in zentralen Komponenten der Telematikinfrastruktur eingesetzt werden. So nutzt die ePA MHD-basierte FHIR-Ressourcen und Profile für die Dokumentenverwaltung. Auch das ISiK-Programm verwendet IHE MHD für die standardisierte Bereitstellung und den Austausch von Dokumenten. Durch die Wiederverwendung dieser etablierten Strukturen können bestehende Implementierungserfahrungen genutzt und die Interoperabilität mit anderen TI- und FHIR-basierten Systemen erleichtert werden.
Weitere Informationen zu IHE MHD sind unter folgenden Quellen verfügbar:
Jeder Fachworkflow verwaltet seine Dokumente innerhalb seines eigenen Kontextes. Dadurch bleiben die fachlichen Zuständigkeiten, Sicherheitsanforderungen und Lebenszyklen der Dokumente voneinander getrennt, während gleichzeitig ein gemeinsames Dokumentenmodell verwendet wird. Beispielsweise können unterschiedliche Fachworkflows eigene Endpunkte bereitstellen:
| [base]/hkp/fhir/Task
[base]/hkp/fhir/DocumentReference [base]/hkp/fhir/Binary [base]/referral/fhir/Task [base]/referral/fhir/DocumentReference [base]/referral/fhir/Binary |
Der Zugriff auf Dokumente erfolgt grundsätzlich über den jeweiligen Workflow. Die führende fachliche Referenz eines Workflows wird durch die FHIR-Ressource Task beschrieben. Das primäre Dokument eines Workflows wird über Task.focus oder Task.input referenziert. Begleitende Dokumente können über Task.input eingebunden werden, beispielsweise Verordnungen, qualifizierte elektronische Signaturen (QES), Anlagen oder Korrekturvorschläge. Ergebnisdokumente eines Workflows können über Task.output bereitgestellt werden, beispielsweise Prüfentscheidungen, Bescheide oder Korrekturergebnisse.
Zusätzlich können Dokumente über Dokumentbeziehungen (DocumentReference.relatesTo) miteinander verknüpft werden. Beispielsweise kann eine qualifizierte elektronische Signatur über eine signierende Beziehung mit der zugehörigen Verordnung verbunden werden. Nachweise zu Workflow-Schritten können über Task.relevantHistory und referenzierte Provenance-Ressourcen dokumentiert werden.
Die Dokumente werden als DocumentReference mit einem referenzierten Dokumentinhalt gespeichert. Der eigentliche Dokumentinhalt wird getrennt von den Dokumentmetadaten verwaltet und kann beispielsweise als Binary-Ressource abgelegt werden. Die Dokumentmetadaten umfassen unter anderem den Dokumenttyp, den Patientenbezug, Autor und Erstellungszeitpunkt, das Dokumentformat, Zugriffsberechtigungen sowie Beziehungen zu anderen Dokumenten. Durch die Trennung von Dokumentmetadaten und Dokumentinhalt können Dokumente effizient gesucht, referenziert und später in andere Systeme übertragen werden.
Für die Einstellung strukturierter Dokumente unterstützt die Dokumentenhaltung ein an IHE MHD angelehntes Vorgehen. Hierfür können unterschiedliche Operationen das Prinzip der serverseitigen Metadatengenerierung nach Generate Metadata [ITI-106] nutzen. Die konkrete Verwendung richtet sich nach dem jeweiligen Fachworkflow und dem Anwendungsfall. Die serverseitige Erzeugung der Dokumentmetadaten wird im folgenden Abschnitt beschrieben.
Die IHE MHD-Transaktion Generate Metadata [ITI-106] dient der serverseitigen Erzeugung von Dokumentmetadaten und kann für unterschiedliche fachliche Operationen genutzt werden, bei denen Dokumentmetadaten aus einem strukturierten Dokument serverseitig abgeleitet werden. Im Gegensatz zu einer klassischen Dokumentenpublikation übermittelt das Primärsystem ausschließlich das eigentliche Dokument. Die für die Dokumentenverwaltung erforderlichen Metadaten werden serverseitig aus dem Dokumentinhalt abgeleitet und als DocumentReference erzeugt. Dadurch muss das Primärsystem keine vollständige DocumentReference erzeugen und der Server kann sicherstellen, dass Dokumente innerhalb des jeweiligen Fachworkflows konsistent und nach einheitlichen Regeln gespeichert werden.
Die $activate-Operation ist ein Beispiel für die Anwendung dieses Prinzips. Das Primärsystem übermittelt den signierten Verordnungsdatensatz als CAdES-Envelope mit einem eingebetteten FHIR-Dokument. Anschließend validiert der Server die Signatur und das enthaltene Dokument, erzeugt die erforderlichen Dokumentmetadaten und legt die resultierenden Dokumente im Document Store ab. Hierbei entstehen abhängig vom Dokumenttyp eine oder mehrere DocumentReference-Ressourcen. Beispielsweise kann neben der Verordnung auch der signierte CAdES-Envelope als separates Nachweisdokument gespeichert und über standardisierte Dokumentbeziehungen mit der Verordnung verknüpft werden.
Die Operation orientiert sich damit an dem Grundgedanken von Generate Metadata [ITI-106], ohne die MHD-Transaktion selbst abzubilden. Das Primärsystem stellt ausschließlich das fachliche Dokument bereit, während die vollständige Dokumentenverwaltung einschließlich der Erzeugung der Dokumentmetadaten serverseitig erfolgt.
Für die Einstellung workflowbegleitender Dokumente wird die Operation $publish-document bereitgestellt. Die Operation orientiert sich konzeptionell an der IHE MHD-Transaktion Simplified Publish [ITI-105] und dient dazu, Dokumente einem bestehenden Workflow zuzuordnen. Die Operation übernimmt dabei ausgewählte Prinzipien von Simplified Publish [ITI-105], bildet die MHD-Transaktion jedoch nicht vollständig ab.
Im Gegensatz zur serverseitigen Metadatengenerierung nach dem Prinzip von Generate Metadata [ITI-106] erfolgt bei $publish-document keine fachliche Interpretation oder inhaltliche Auswertung des Dokuments. Das Primärsystem stellt sowohl den Dokumentinhalt als auch die zugehörigen Dokumentmetadaten bereit. Der Server validiert die übermittelten Ressourcen, prüft deren Zuordnung zum Workflow sowie die zulässigen Dokumenttypen und übernimmt anschließend die Speicherung.
Die Operation eignet sich sowohl für strukturierte als auch für nicht strukturierte Dokumente. Hierzu zählen beispielsweise Anlagen, Korrekturvorschläge, Prüfentscheidungen, Nachweise sowie Dokumente in Form von PDF/A-Dokumenten oder FHIR-Dokumenten. Da der Dokumentinhalt ausschließlich formal validiert und nicht fachlich verarbeitet wird, können beliebige Dokumenttypen nach einem einheitlichen Verfahren veröffentlicht werden.
Von Simplified Publish [ITI-105] wird insbesondere das Prinzip übernommen, Dokumentmetadaten und Dokumentinhalt gemeinsam zu übertragen. Hierzu übermittelt das Primärsystem eine DocumentReference, in der der Dokumentinhalt entsprechend der ITI-105 Message Semantics im Element DocumentReference.content.attachment.data Base64-kodiert eingebettet ist. Die übermittelte DocumentReference kann einschließlich des eingebetteten Dokumentinhalts gespeichert werden.
Weitere Verarbeitungsregeln von Simplified Publish [ITI-105] werden nicht übernommen, sofern sie für den Fachworkflow nicht benötigt werden. Insbesondere wird kein SubmissionSet erzeugt. Auch der Operationsaufruf weicht bewusst von der MHD-Transaktion ab: Während Simplified Publish [ITI-105] eine FHIR-create Interaktion mittels HTTP POST auf den DocumentReference-Endpunkt vorsieht, erfolgt die Dokumentenpublikation hier über die workflowbezogene Operation.
Die Zuordnung zum Workflow erfolgt über die adressierte Task-Instanz. Das veröffentlichte Dokument kann anschließend beispielsweise über Task.input als Begleitdokument oder über Task.output als Ergebnisdokument referenziert werden. Die konkrete Verwendung richtet sich nach dem fachlichen Kontext des jeweiligen Workflows.
Beispielhafte Operation:
| POST [base]/hkp/fhir/Task/{id}/$publish-document |
Die Dokumentenpublikation kann sowohl Dokumente aufnehmen, die innerhalb des Fachworkflows gespeichert werden, als auch Dokumente referenzieren, die bereits in der ePA des Versicherten abgelegt wurden. Hierzu kann die Operation $publish-document eine bestehende DocumentReference übernehmen, die zuvor aus der ePA abgerufen wurde.
In diesem Fall wird der Dokumentinhalt nicht erneut im Workflow gespeichert. Stattdessen wird die bestehende DocumentReference zur Referenzierung des Dokuments innerhalb des Workflows verwendet. Die bereits aus der ePA stammende DocumentReference enthält die erforderlichen Metadaten sowie die Referenz auf den Dokumentinhalt in der ePA.
Der bevorzugte Weg besteht darin, Dokumente, die bereits in der ePA des Versicherten vorhanden sind, ausschließlich über ihre DocumentReference zu referenzieren. Dadurch wird eine redundante Speicherung von Dokumenten vermieden und sichergestellt, dass sowohl der Workflow als auch die ePA auf dieselbe fachliche Dokumentreferenz zugreifen. Eine Speicherung des Dokumentinhalts im workfloweigenen Document Store erfolgt nur in Ausnahmefällen, beispielsweise wenn der Versicherte der Nutzung der ePA widersprochen hat oder die verordnende Leistungserbringerinstitution keinen Zugriff auf die ePA besitzt. In diesen Fällen werden Dokument und Dokumentmetadaten vollständig innerhalb des Fachworkflows verwaltet.
Die Verfügbarkeit eines ausschließlich referenzierten Dokuments hängt von dessen weiterer Verfügbarkeit in der ePA und den Zugriffsberechtigungen des jeweiligen Workflowbeteiligten ab. Wird das Dokument während eines laufenden Workflows aus der ePA gelöscht oder besitzt ein Beteiligter keinen Zugriff auf das Dokument, kann der Dokumentinhalt nicht bereitgestellt werden. Diese eingeschränkte Verfügbarkeit ist eine Folge der reinen Referenzierung und wird akzeptiert. Die im Workflow verwendete DocumentReference kann weiterhin als Nachweis dafür erhalten bleiben, welches Dokument in den Workflow eingebunden wurde.
Folgende Dokumente werden im workfloweigenen Document Store bereitgestellt:
Workflowbegleitende Dokumente, auf die obige Kriterien nicht zutreffen, werden bei Verfügbarkeit der ePA und Zugriffsberechtigung für den Bereitstellenden über eine bestehende DocumentReference aus der ePA referenziert.
Die innerhalb eines Workflows gespeicherten Dokumente müssen den für die ePA vorgesehenen Formatvorgaben entsprechen. Unterstützt werden Dokumente in den Formaten FHIR-Dokument und PDF/A. FHIR-Dokumente werden als FHIR-Bundle vom Typ document bereitgestellt und müssen die FHIR-Vorgaben für den Aufbau eines Dokuments und die enthaltenen Ressourcen erfüllen.
Für Dokumente innerhalb eines Workflows gilt eine maximale Dokumentgröße von 25 MByte. Bei jeder Schreiboperation, über die ein oder mehrere Dokumente in den Workflow eingebracht werden, ermittelt der Server die tatsächliche Größe jedes einzelnen Dokuments. Überschreitet mindestens ein Dokument die zulässige Größe von 25 MByte, wird die gesamte Schreiboperation abgelehnt. Die Prüfung erfolgt unabhängig vom Dokumentformat und gilt damit gleichermaßen für strukturierte Dokumente, PDF/A-Dokumente sowie weitere unterstützte Dokumentformate.
Die Größenbeschränkung gilt für alle Mechanismen, über die Dokumentinhalte im workfloweigenen Document Store gespeichert werden, beispielsweise bei der serverseitigen Metadatengenerierung oder der Dokumentenpublikation. Dokumente, die lediglich über eine bestehende DocumentReference aus der ePA referenziert und nicht erneut im Workflow gespeichert werden, sind von dieser Prüfung ausgenommen.
Die Begrenzung orientiert sich an den Anforderungen der ePA-Dokumentenverwaltung und schafft damit ein einheitliches Größenlimit für Dokumente, die innerhalb der Fachworkflows verarbeitet und gespeichert werden.
Dokumente werden unveränderlich gespeichert. Änderungen an einem Dokument führen daher nicht zur Aktualisierung einer bestehenden DocumentReference, sondern zur Erstellung einer neuen Dokumentversion. Die Beziehung zwischen den Versionen wird über DocumentReference.relatesTo mit dem Beziehungstyp replaces modelliert. Dieses Vorgehen orientiert sich an dem aus IHE MHD/XDS bekannten Prinzip der Dokumentersetzung, das auch in der ePA verwendet wird. Ein Dokument mit DocumentReference.relatesTo.code = replaces ersetzt das referenzierte Vorgängerdokument fachlich vollständig. Frühere Dokumentversionen bleiben erhalten und können weiterhin für Nachweis- und Revisionszwecke herangezogen werden, während ausschließlich die aktuelle Dokumentversion als fachlich gültig betrachtet wird.
Die Abbildung zeigt beispielhaft die Ersetzung eines Dokuments durch eine neue Version. Der Task referenziert ausschließlich die aktuelle DocumentReference (Version 2), die über relatesTo.code = replaces auf die vorherige Version verweist. Beide Dokumentversionen und ihre jeweiligen Dokumentinhalte bleiben weiterhin erhalten.
Die Operation $documents dient dem workflowbezogenen Abruf der einem Task zugeordneten Dokumente. Sie ermittelt die relevanten DocumentReference-Ressourcen unabhängig davon, ob diese über Task.focus, Task.input, Task.output oder weitere Dokumentbeziehungen mit dem Workflow verbunden sind.
Die Rückgabe orientiert sich dabei stark an der IHE MHD-Transaktion Find Document References [ITI-67]. Wie bei ITI-67 werden die ermittelten Dokumente als DocumentReference-Ressourcen in einem FHIR-Bundle bereitgestellt. Die Operation bildet Find Document References [ITI-67] jedoch nicht vollständig ab, sondern überträgt das MHD-Prinzip auf den Kontext eines konkreten Fachworkflows. Anstelle einer freien Suche nach Dokumentmetadaten wird die Dokumentmenge ausgehend von der adressierten Task-Instanz ermittelt.
Vor der Rückgabe werden die für den aufrufenden Akteur geltenden Zugriffsberechtigungen geprüft. Darüber hinaus berücksichtigt die Operation die Dokumentversionierung. Dokumente, die durch eine Nachfolgeversion mittels DocumentReference.relatesTo.code = replaces ersetzt wurden, werden standardmäßig nicht zurückgegeben. Dadurch liefert $documents ausschließlich die aktuell fachlich gültigen und für den aufrufenden Akteur zugänglichen Dokumente des Workflows.
Beispielsweise:
| GET [base]/hkp/fhir/Task/{id}/$documents |
Über den optionalen Parameter include-history können zusätzlich Dokumentversionen zurückgegeben werden, die durch eine Nachfolgeversion mittels DocumentReference.relatesTo.code = replaces ersetzt wurden.
| GET [base]/hkp/fhir/Task/{id}/$documents?include-history=true |
Bei Verwendung von include-history=true enthält die Ergebnismenge sowohl die aktuellen als auch die ersetzten DocumentReference-Ressourcen. Die Beziehungen zwischen den Dokumentversionen bleiben über DocumentReference.relatesTo nachvollziehbar. Die Prüfung der Zugriffsberechtigungen erfolgt unabhängig vom Parameter weiterhin für jede zurückgegebene Dokumentversion.
Neben dem workflowbezogenen Abruf über $documents können einzelne Ressourcen auch über die regulären FHIR-Read Interaktionen abgerufen werden. Eine DocumentReference kann direkt über ihre Ressourcen-ID abgerufen werden:
| GET [base]/hkp/fhir/DocumentReference/{id} |
Der Dokumentinhalt wird getrennt von den Dokumentmetadaten in einer Binary-Ressource gespeichert und kann ebenfalls direkt abgerufen werden:
| GET [base]/hkp/fhir/Binary/{id} |
Ergänzend kann die Komfortoperation $with-content verwendet werden, um eine DocumentReference gemeinsam mit dem referenzierten Dokumentinhalt (Binary-Ressource) abzurufen.
| GET [base]/hkp/fhir/DocumentReference/{id}/$with-content |
Die Operation liefert die angeforderte DocumentReference gemeinsam mit dem referenzierten Dokumentinhalt, einer Binary-Ressource, in einem gemeinsamen FHIR-Bundle zurück. Die Operation vereinfacht den Abruf von Dokumenten, ohne die Trennung zwischen Dokumentmetadaten und Dokumentinhalt aufzugeben.
Der Dokumentenspeicher (Document Store) dient ausschließlich der Unterstützung eines laufenden Fachworkflows und stellt keinen permanenten Dokumentenspeicher dar. Er ist insbesondere keine Alternative zur ePA für die dauerhafte Ablage medizinischer Dokumente. Mit der Löschung einer Task-Instanz werden auch die zugehörigen DocumentReference- und Binary-Ressourcen aus dem Document Store entfernt. Werden Dokumente aus der ePA referenziert, wird ausschließlich die im Workflow gespeicherte DocumentReference gelöscht. Das referenzierte Dokument sowie dessen DocumentReference in der ePA bleiben unverändert erhalten.
Dokumente, die dauerhaft verfügbar sein sollen, sind daher spätestens vor Abschluss des Workflows in der ePA abzulegen oder bereits aus der ePA zu referenzieren. Dadurch bleibt der Document Store auf die Dauer des Fachworkflows beschränkt und übernimmt ausschließlich die für dessen Durchführung erforderliche Dokumentenverwaltung.
Der HKP-Workflow verwendet das zuvor beschriebene Dokumentenkonzept zur Verwaltung aller fachlichen Datensätze. Die im HKP-Fachkonzept definierten Datensätze werden dabei als eigenständige Dokumente behandelt und über DocumentReference mit einem referenzierten Dokumentinhalt verwaltet.
Der HKP-Workflow unterscheidet zwischen Dokumenten, die den fachlichen Ablauf steuern und workflowbegleitenden Dokumenten. Führende Dokumente, wie der Verordnungsdatensatz (VO), der Entscheidungsdatensatz als Ergebnis einer Antragsprüfung oder korrigierte Versionen einer Verordnung, werden über fachliche Workflowoperationen bereitgestellt. Workflowbegleitende Dokumente, beispielsweise Blankoverordnungsdatensatz, Angaben zur Leistungserbringung oder weitere Anlagen, werden dagegen über die Operation $publish-document in den Workflow eingebracht.
Der HKP-Workflow beginnt mit dem Verordnungsdatensatz (VO), der über die Operation $activate in den Workflow eingebracht wird und den fachlichen Kontext der Verordnung bildet. Im weiteren Verlauf entstehen fachliche Ergebnisdokumente innerhalb von Anfrage-Workflows. Hierzu zählen insbesondere korrigierte Versionen einer Verordnung oder Blankoverordnung sowie das Entscheidungsdatensatz der Antragsprüfung. Diese Dokumente werden jeweils über die Operation $close-Anfrage-Workflow an den übergeordneten HKP-Workflow übergeben.
Die Operationen $activate und $close-Anfrage-Workflow orientieren sich konzeptionell an den Prinzipien der IHE MHD-Transaktion Generate Metadata [ITI-106]. Das Primärsystem übermittelt dabei das jeweilige fachliche Dokument, während der Server den Dokumentinhalt validiert, die erforderlichen Dokumentmetadaten erzeugt und das Dokument dem Workflow zuordnet.
Handelt es sich bei einem Korrektur-Anfrage-Workflow um die Erstellung einer neuen Version eines bestehenden Dokuments, wird die Beziehung zwischen den Dokumentversionen über DocumentReference.relatesTo.code = replaces hergestellt. Dadurch bleibt die Dokumenthistorie erhalten, während die neue Dokumentversion fachlich das bisherige Dokument ersetzt.
Workflowbegleitende Dokumente werden unabhängig vom fachlichen Ablauf eines Workflows über die Operation $publish-document bereitgestellt. Diese orientiert sich konzeptionell an der IHE MHD-Transaktion Simplified Publish [ITI-105]. Das Primärsystem übermittelt hierbei sowohl den Dokumentinhalt als auch die zugehörigen Dokumentmetadaten. Der Server validiert die übermittelten Ressourcen, prüft deren Zuordnung zum Workflow und speichert sie, ohne den Dokumentinhalt fachlich auszuwerten. Workflowbegleitende Dokumente werden über Task.input mit dem Fachworkflow verknüpft. Die Operation $publish-document dient der Einstellung workflowbegleitender Dokumente. Abhängig vom Dokumenttyp kann der Server neben der formalen Validierung auch dokumenttypspezifische fachliche Validierungen durchführen. Dies gilt insbesondere für workflowinhaltlich bekannte Dokumente, wie beispielsweise den Blankoverordnungsdatensatz. Dokumente, deren Inhalt vom Workflow nicht fachlich interpretiert wird, werden dagegen ausschließlich formal validiert und gespeichert.
Die Operation $publish-document kann ausschließlich auf die Task-Instanz eines Fachworkflows angewendet werden. Eine Anwendung auf Task-Instanzen von Anfrage-Workflows ist derzeit nicht vorgesehen. Dokumente, die innerhalb eines Anfrage-Workflows entstehen oder fachlich verändert werden, werden ausschließlich über die jeweilige $close-Anfrage-Workflow Operation an den übergeordneten Fachworkflow übergeben.
Für jeden Dokumenttyp ist im HKP-Workflow festgelegt, ob eine elektronische Signatur erforderlich ist, welcher Signaturtyp verwendet werden muss und welche Rolle im Signaturzertifikat für die Signatur zulässig ist. Die Signaturanforderung ist Bestandteil der Definition des jeweiligen Dokumenttyps und wird unabhängig von der verwendeten Workflowoperation geprüft. Die Operation validiert bei der Einstellung eines Dokuments, ob die für den jeweiligen Dokumenttyp erforderliche Signatur vorhanden ist. Hierbei kann zwischen fortgeschrittenen elektronischen Signaturen (nonQES) und qualifizierten elektronischen Signaturen (QES) unterschieden werden. Die konkrete Signaturanforderung richtet sich nach dem jeweiligen Dokumenttyp.
Die eigentliche Signaturprüfung erfolgt im Rahmen der jeweiligen Workflowoperation, beispielsweise bei $activate, $close-Anfrage-Workflow oder $publish-document, sofern für den betreffenden Dokumenttyp eine Signatur vorgesehen ist.
Tabelle 43: Dokumente im HKP-Workflow
| Dokument | Rolle | Bereitstellung | Signatur | Zugriffsberechtigung | Besonderheiten |
|---|---|---|---|---|---|
| Verordnungsdatensatz (VO) | Führendes Dokument | $activate | QES | alle Prozessbeteiligten | Bildet den fachlichen Kontext des HKP-Workflows. |
| Korrgierte Version eines Verordnungsdatensatzes (VO-nV) | Führendes Dokument | $close-Anfrage-Workflow | QES | alle Prozessbeteiligten | Ersetzt die vorherige Version über DocumentReference.relatesTo.code = replaces. |
| Blankoverordnungsdatensatz | Workflowbegleitendes Dokument, das fachlich verarbeitet und versioniert werden kann | $publish-document | nonQES | alle Prozessbeteiligten | Dem Workflow fachlich bekannt und kann korrigiert werden. |
| Korrigierte Version eines Blankoverordnungsdatensatzes | Workflowbegleitendes Dokument, das fachlich verarbeitet und versioniert werden kann | $close-Anfrage-Workflow | nonQES | alle Prozessbeteiligten | Ersetzt die vorherige Version über DocumentReference.relatesTo.code = replaces. |
| Angaben zur Leistungserbringung des PD | Workflowbegleitendes Dokument | $publish-document | nonQES | alle Prozessbeteiligten | Fachlich relevantes Begleitdokument des Workflows |
| Entscheidungsdatensatz | Workflowbegleitendes Dokument, das fachlich verarbeitet und versioniert werden kann | $close-Anfrage-Workflow | keine | alle Prozessbeteiligten | Ergebnis der Antragsprüfung. |
| sonstige workflowbegleitende Dokumente
(z. B. Anlagen, Nachweise, PDF/A-Dokumente, weitere FHIR-Dokumente oder aus der ePA referenzierte Dokumente) |
Workflowbegleitendes Dokument | $publish-document | konfigurierbar | alle Prozessbeteiligten, ausser Kostenträger | Werden nicht fachlich ausgewertet und können nicht Gegenstand eines Korrektur-Anfrage-Workflows sein. |
Nicht jedes über $publish-document eingestellte Dokument kann fachlich verarbeitet oder korrigiert werden. Voraussetzung für eine fachliche Korrektur ist, dass der Workflow den Inhalt des Dokuments fachlich kennt und verarbeitet. Nur solche workflowinhaltlich bekannten Dokumente können Gegenstand eines Korrektur-Anfrage-Workflows sein. Reine workflowbegleitende Dokumente, die ausschließlich zur Dokumentation oder als Anlage dienen und vom Workflow nicht fachlich interpretiert werden, können dagegen nicht inhaltlich korrigiert werden.
Dokumente, die den fachlichen Ablauf des HKP-Workflows steuern oder von Workflowbeteiligten fachlich verarbeitet werden, müssen im workfloweigenen Document Store gespeichert werden. Eine ausschließliche Referenzierung dieser Dokumente aus der ePA ist hierfür nicht ausreichend. Dies gilt insbesondere für Dokumente, die Grundlage von Workflowübergängen, Korrekturprozessen oder der Antragsprüfung sind.
Hierzu zählen insbesondere:
Sonstige workflowbegleitende Dokumente, die nicht für die Steuerung oder fachliche Verarbeitung des Workflows erforderlich sind, können dagegen auch ausschließlich über eine bestehende DocumentReference aus der ePA referenziert werden.
Die Gültigkeit einer Verordnung ergibt sich aus der Angabe "Verordnungszeitraum bis" im Verordnungsdatensatz. Für das Entlassmanagement prüft der E-Rezept-Fachdienst, dass der Verordnungszeitraum die 7-Tage Frist nicht überschreitet.
Der E-Rezept-Fachdienst soll eine Datensparsamkeit realisieren. Dafür werden nicht mehr benötigte Ressourcen automatisch durch den E-Rezept-Fachdienst nach einer festen Frist gelöscht.
Tabelle 44: Löschfristen
| Szenario | Löschfrist |
|---|---|
| Die Verordnung wurde durch den Verordnenden, den Versicherten oder durch eine automatischen Statuswechsel (AL1, AL2, AL3) in den cancelled gesetzt. | 10 Tage nach dem Statuswechsel Task.status = cancelled |
Hinweis: Die im Fachkonzept beschriebenen Anwendungsfälle zum Löschen überführen den Workflow in den Status "cancelled". Hierbei werden die Daten personenbezogenen und medizinischen Daten (ausser KVNR) sowie zugehörige Informationen (bspw. Communications und Dokumente) gelöscht.
Der Workflow im Status "cancelled" bleibt bis zum erreichen der Löschfrist im Fachdienst gespeichert, um das Löschen der Verordnung für Clients nachvollziehbar zu machen.
Im Rahmen des Workflowmodells für HKP besteht die Notwendigkeit für die Kommunikation zwischen den Prozessbeteiligten:
Für diese Nachrichten wird analog zum Zuweisungsprozess im Workflow für verschreibungspflichtige Arzneimittel Communications im Fachdienst verwendet. Es besteht die Möglichkeit anwendungsfall-spezifische Nachrichteninhalte (payload) zu definieren. Der Sender der Nachricht stellt eine Communication im Fachdienst ein. Der Empfänger kann die Communication asynchron vom Fachdienst abrufen.
Mit der Verfügbarkeit und flächendeckenden Nutzung einer Kommunikationsanwendung der TI durch alle Prozessbeteiligten ist geplant, diese Kommunikation auf diese Plattform zu migrieren.
Alternativen:
Für die Übermittlung der Zugriffsinformation für eine Verordnung durch den Versicherten steht dem Versicherten ein vom Verordnenden ausgestellten Patientenausdruck zur Verfügung. Der Patientenausdruck beinhaltet einen Datamatrixcode mit der Information zu Verordnungs-ID und Accesscode_state. Zusätzlich ist ein Telefon-Code aufgedruckt.
Die Informationen aus dem Datamatrixcode berechtigen Kostenträger und Pflegedienst für den Zugriff auf den Workflow.
Der Telefon-Code (zusammen mit der Verordnungs-ID) berechtigt den Kostenträger für den Zugriff auf den Workflow.
Der E-Rezept-Fachdienst unterstützt Push Notification für die Frontend der Versicherten. Es werden Notification für Statusänderungen des Workflows zur Verordnung und für Communications versendet.
Kostenträger und Pflegedienste können sich für einen Notificationdienst registrieren, welcher im Fachdienst eingehende Communication für die Institution signalisiert.
Die Übermittlung von HKP Verordnungsdaten ist nicht im Scope des MVP. Es kann Teil einer Ausbaustufe sein.
Die Übermittlung von workflow-begleitenden Dokumenten in die ePA ist nicht vorgesehen.
Siehe Kapitel 6.5.1
eGK/Gesundheits-ID via Pflegeprimärsystem & PoPP
Es wird das PoPP-Feature im PPS genutzt. Der Pflegedienst erhält im Response vom Fachdienst die Liste der einlösbaren HKP Verordnungen inklusive AccessCode_state, um sich eine Verordnung zuweisen zu können.
Frontend des Versicherten
Der Versicherte kann eine Verordnung im FdV einem Pflegedienst zuweisen. Das FdV stellt im Fachdienst eine Communication mit dem Zugriffsinformationen (inklusive AccessCode_state) ein. Der Pflegedienst erhält eine Notification für die eingestellte Communication, kann diese abrufen und sich die Verordnung zuweisen.
Patientenausdruck
Der vom Verordnenden bereitgestellten Patientenausdruck umfasst mindestens einen Datamatrix-Code mit den Zugangsinformationen (inklusive AccessCode_state). Der Versicherte kann den Patientenausdruck den Pflegedienst übergeben. Der Pflegedienst kann damit die Verordnung abrufen und sich zuweisen.
Siehe Kapitel 6.5.2
Der Versicherte kann im FdV das Einlösen einer Verordnung bei bis zu 3 Pflegediensten anfragen. Das FdV stellt im Fachdienst eine Communication mit dem Zugriffsinformationen (inklusive AccessCode_read) ein. Der Pflegedienst erhält eine Notification für die eingestellte Communication, kann diese abrufen. Mit den Zugriffsinformationen kann das PPS die Verordnung vom Fachdienst abrufen, ohne dass der Status des Workflows sich ändert, d.h. es erfolgt kein Zuweisen.
Beratung durch die Krankenkasse (siehe Kapitel 6.5.3)
Standardmäßig hat der Kostenträger nach dem Einstellen einer Verordnung in den Fachdienst keine Kenntnis von der Verordnung.
Wenn der Versicherte sich zu der Verordnung von seinem Kostenträger beraten lassen möchte, kann der Versicherte dem Kostenträger die Zugriffsinformation übermitteln. Damit erhält der Kostenträger einen Zugriff auf die Verordnung. Diese Berechtigung bleibt für den gesamten Lifecycle der Verordnung bestehen.
Wahl der Kostenerstattung [§13 Abs. 2 SGB V] (siehe Kapitel 6.4)
Beim Einstellen der Verordnung durch den Verordnenden prüft der Fachdienst, ob eine Wahl der Kostenerstattung dokumentiert wurde. In dem Fall erstellt der Fachdienst eine Communication Ressource und adressiert sie an den im Verordnungsdatensatz dokumentierten Kostenträger. Die Communication enthält die Information zur Kostenerstattung und die Zugriffsinformation für die Verordnung.
Abweichend zum Standardablauf ist der Start des Anfrageworkflows "Antragsprüfung durch Pflegedienst" nicht zulässig.
Kostenerstattung nach [§ 37 Abs. 4 SGB V], nach [§ 32 Abs. 3 SGB VII] sowie persönliches Budget (siehe Kapitel 6.4)
Für die Abstimmung mit dem Kostenträger übermittelt der Versicherte die Zugriffsinformation an den Kostenträger (Communication in FdV, Patientenausdruck, telefonsiche Übermittlung des Geheimnis auf Patientenausdruck).
Nach der erfolgten Abstimmung zwischen Versicherten und Kostenträger stellt der Kostenträger einen Entscheidungsdatensatz mit der Kennzeichnung "Kostenerstattung / Persönliches Budget" in den Workflow ein.
Der Fachdienst ändert den Workflowstatus für die Verordnung von offen/zugewiesen auf completed. Alle Vorgangsbeteiligten können nachfolgend nur noch lesend auf die Verordnung und die zugehörigen Dokumente zugreifen.
Offener Punkt: Abweichend vom fachlichen Konzept, wäre es möglich analog zum Szenario Wahl der Kostenerstattung [§13 Abs. 2 SGB V] den weiteren Durchlauf des Workflows zu erlauben, um bspw. Korrekturanfragen der Pflegeeinrichtung an den verordnenden zuzulassen.
Unzuständigkeit der Krankenkasse (siehe Kapitel 6.9)
Der Versicherte startet den Anfrageworkflow "Antragsprüfung durch Versicherten" oder der Pflegedienst startet des Anfrageworkflow "Antragsprüfung durch Pflegedienst". Die im Anfrageworkflow adressierte Krankenkasse stellt fest, dass sie nicht zuständig ist. Die Krankenkasse lehnt die Anfrage ab und stellt ein Dokument mit dieser Begründung ein. Der Anfrageworkflow wird beendet.
optionales Clearing: Die Krankenkasse kann die Zugriffsinformation für den Verordnungsworkflow (Task-ID und AccessCode_state) an andere Krankenkassen weiterleiten. Mit den Zugriffsinformationen können andere Krankenkassen prüfen, ob sie zuständig sind und dies der ursprünglich angefragten Krankenkasse mitteilen. In diesem Fall kann die ursprünglich angefragte Krankenkasse in der Begründung zusätzlich zu ihrer eigenen Unzuständigkeit die tatsächlich zuständige Krankenkasse angeben.
Der Versicherte oder Pflegedienst kann, wenn die Information zur tatsächlich zuständigen Krankenkasse vorliegt, einen neuen Anfrageworkflow zur Antragsprüfung starten. Das PPS kann die Telematik-ID der Krankenkasse , falls notwendig, über eine Abfrage am FHIR-VZD bestimmen.
Wenn eine neue Verordnung zu Lasten des tatsächlichen Kostenträgers ausgestellt werden soll und keine Leistung auf die ursprüngliche Verordnung erbracht wurde, kann der Pflegedienst die Verordnung an den Versicherten zurückgeben und der Verordnende löscht die ursprüngliche Verordnung.
Siehe Kapitel 6.5.3
Für eine Verordnung zu Lasten einer privaten Krankenversicherung ist abweichend zum Standardablauf der Start des Anfrageworkflows "Antragsprüfung durch Versicherten" und "Antragsprüfung durch Pflegedienst" nicht zulässig.
Für eine Verordnung zu Lasten einer privaten Krankenversicherung kann der Versicherte mittels FdV die Daten zur Verordnung als PDF mit eingebetteten FHIR-Datensätzen (ohne QES) herunterzuladen, um sich mit dem Kostenträger bezüglich der Kostenerstattung abzustimmen.
Die Unfallversicherungsträger sind an die TI angebunden und unterstützen KIM. Für HKP Verordnungen haben die Unfallversicherungsträger derzeit nicht vorgesehen, sich an den E-Rezept-Fachdienst anzubinden.
Der Durchlauf des Workflows erfolgt ohne Beteiligung des Unfallversicherungsträgers. Wenn der zugewiesene Pflegedienst die Antragsprüfung zur Kostenerstattung (AP3) startet, erzeugt der Fachdienst eine KIM Message mit Daten zur Verordnung als PDF mit eingebetteten FHIR-Datensätzen (mit QES) und sendet diese an den Unfallversicherungsträger. Die KIM-Adresse wird auf Basis der IK des in der Verordnung hinterlegten Kostenträger vom Fachdienst auf Basis der Daten im FHIR-VZD ermittelt. Die KIM-Nachricht erhält eine eigene KIM-Dienstkennung, um eine Zuordnung der Nachricht beim Unfallversicherungsträger zu ermöglichen. Der Versand der KIM-Nachricht wird für den Versicherten im Fachdienst protokolliert.
Abweichend zum Standardablauf ist der Start des Anfrageworkflows "Antragsprüfung durch Versicherten" nicht zulässig.
Es besteht keine Möglichkeit, mögliche Korrekturanfragen des Unfallversicherungsträgers an den Verordnenden oder den Pflegedienst über einen Anfrage-Workflow des Fachdienstes zu stellen und somit auch keine Möglichkeit, dass der Verordnende aufgrund der Korrekturanfrage eine neue Version der Verordnung auf dem Fachdienst einstellt. Die Kommunikation zu Korrekturanfragen kann über KIM durchgeführt werden.
Für eine Verordnung zu Lasten eines Unfallversicherungsträger kann der Versicherte mittels FdV die Daten zur Verordnung als PDF mit eingebetteten FHIR-Datensätzen (ohne QES) herunterzuladen, um mit diesen Informationen eine Beratung mit dem Unfallversicherungsträger zu initiieren.
offener Punkt: Es ist zu klären, wie mit einer Verordnung umzugehen ist, wenn zur IK der UV keine KIM-Adresse im FHIR-VZD gefunden werden kann.
Lösungsidee: Die DGUV pflegt auf dem Terminologieserver eine Mappingtabelle (zulässige IKs / KIM-Adressen). Der Fachdienst prüft beim Einstellen der Verordnung, falls es sich um eine Verordnung zu Lasten einer UV handelt, ob eine aus der Mappingtabelle bekannte IK im Verordnungsdatensatz verwendet wurde und weisst den Verordnungsdatensatz im Fehlerfall ab.
In diesem Kapitel werden die technischen Anwendungsfälle der Nutzergruppen beschrieben.
Mit diesem Anwendungsfall erstellt ein Verordnender einen neuen Workflow für eine HKP Verordnung.
AF_10442 - Anwendungsfall HKP "Verordnung erzeugen"
Alle am Anwendungsfall "Verordnung erzeugen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC 2.1 - Verordnung erzeugen |
|---|---|
| Vorbedingungen |
|
| Kurzbeschreibung
(Außenansicht) |
Der Arzt wählt im PS einen Verordnungsdatensatz aus.
Das PS ruft für die Verordnung vom E-Rezept-Fachdienst eine Verordnungs-ID ab und ergänzt diese im Verordnungsdatensatz. Der Arzt wählt das Signaturverfahren aus. Das PS signiert die Verordnung mittels Konnektor mit einer QES (in Ausnahmefällen ist eine non-QES ausreichend). Es kann für die QES die Einzel-, Stapel- oder Komfortsignatur genutzt werden. |
| Nachbedingungen |
|
Mit diesem Anwendungsfall stellt eine verordnende LEI einen Verordnungsdatensatz in den Fachdienst ein.
AF_10443 - Anwendungsfall HKP "Verordnung einstellen"
Alle am Anwendungsfall "Verordnung einstellen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC 2.3 - Verordnung einstellen |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Der Arzt oder ein Mitarbeiter der medizinischen Institution wählt im Primärsystem eine Verordnung zum Einstellen aus.
Das Primärsystem stellt die Verordnung in den E-Rezept-Fachdienst ein. Der E-Rezept-Fachdienst prüft die Gültigkeit der Signatur und die Validität des Verordnungsdatensatzes. Der E-Rezept-Fachdienst extrahiert das Dokument (Verordnungsdatensatz) und erstellt dafür eine DocumentReference. Das Primärsystem erstellt einen Verordnungstoken und speichert diesen. |
| Nachbedingung |
|
Mit diesem Anwendungsfall kann eine verordnende LEI Informationen zu einem durch sie erstellten Workflow abrufen.
AF_10444 - Anwendungsfall HKP "Verordnung durch Verordnenden abrufen"
Alle am Anwendungsfall "Verordnung durch Verordnenden abrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC 2.6 - Verordnung durch Verordnenden abrufen |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Das Primärsystem ermittelt die Verordnungs-ID und den AccessCode_state.
Das Primärsystem ruft mit der Verordnungs-ID und dem AccessCode_state die Verordnung vom E-Rezept-Fachdienst ab. |
| Nachbedingung |
|
Mit diesem Anwendungsfall kann eine verordnende LEI einen durch sie erstellten Workflow löschen.
AF_10445 - Anwendungsfall HKP "Verordnung durch Verordnenden löschen"
Alle am Anwendungsfall "Verordnung durch Verordnenden löschen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC 2.5 - Verordnung durch Verordnenden löschen |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Ein Mitarbeiter der medizinischen Institution markiert über das Primärsystem eine durch die LEI verordnete Verordnung zum Löschen und bestätigt den Vorgang.
Der E-Rezept-Fachdienst ändert den Status der Verordnung zu "cancelled". Der E-Rezept-Fachdienst löscht die personenbezogenen und medizinischen Daten zum Workflow. Das Primärsystem löscht den AccessCode_state. |
| Nachbedingung |
|
Mit diesem Anwendungsfall kann der Versicherte seine im Fachdienst verwalteten HKP Verordnungen abrufen.
AF_10446 - Anwendungsfall HKP "Verordnungen durch Versicherten abrufen"
Alle am Anwendungsfall "Verordnungen durch Versicherten abrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC 3.1 - Verordnungen durch Versicherten abrufen |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Ein Versicherter ruft über ein FdV alle seine im E-Rezept-Fachdienst verfügbaren Verordnungen ab.
Der E-Rezept-Fachdienst identifiziert die Verordnungen auf Basis der Versicherten-ID des Versicherten und liefert die Verordnungen, Status und die Zeitpunkte, an denen die Status gesetzt wurden. |
| Nachbedingung |
|
Mit diesem Anwendungsfall kann der Versicherte eine seiner im Fachdienst verwalteten HKP Verordnungen löschen.
AF_10447 - Anwendungsfall HKP "Verordnung durch Versicherten löschen"
Alle am Anwendungsfall "Verordnung durch Versicherten löschen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC 3.2 - Verordnung durch Versicherten löschen |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Ein Versicherter wählt am FdV ein für ihn ausgestellte Verordnung aus, die gelöscht werden soll. Der Versicherte bestätigt das Löschen.
Das FdV überträgt die Anforderung an den E-Rezept-Fachdienst. Der E-Rezept-Fachdienst ändert den Status der Verordnung und löscht die personenbezogenen und medizinischen Daten in der Verordnung. Das FdV löscht abschließend den Verordnungstoken. |
| Nachbedingung |
|
AF_10448 - Anwendungsfall HKP "Nachrichten durch Versicherten empfangen"
Alle am Anwendungsfall "Nachrichten durch Versicherten empfangen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC 3.4 - Nachrichten durch Versicherten empfangen |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Das FdV fragt beim E-Rezept-Fachdienst an, ob neue Nachrichten für den Nutzer des FdV vorliegen und lädt diese herunter.
Der E-Rezept-Fachdienst ermittelt die Nachrichten in denen die anfragende Versicherten-ID als Empfänger eingetragen ist. |
| Nachbedingung |
|
Mit diesem Anwendungsfall kann der Versicherte
AF_10449 - Anwendungsfall "Nachricht durch Versicherten übermitteln"
Alle am Anwendungsfall "Nachricht durch Versicherten übermitteln" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC 3.3 - Nachricht durch Versicherten übermitteln |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Ein Versicherter wählt im FdV einen Verordnungstoken aus und trifft dann die Entscheidung, ob der Versand über die TI oder alternativ optisch per 2D-Code stattfinden soll. Der sichere Versand über die TI erfolgt mithilfe des E-Rezept-Fachdienstes.
Der Versicherte wählt im Verzeichnisdienst den Pflegedienst oder den Kostenträger aus, an den die Nachricht übermittelt werden soll. Das FdV stellt anschließend die Nachricht für den Empfänger im E‑Rezept-Fachdienst ein. Die Nachricht enthält einen Verordnungstoken und/oder eine Textnachricht. Im Falle der Alternative wird der Verordnungstoken in einen 2D-Code umgewandelt und dem Abgebenden oder Vertreter entweder zum Scannen an einem Bildschirm gezeigt oder als Ausdruck übergeben. |
| Nachbedingung |
|
AF_10450 - Anwendungsfall "Nachricht durch Versicherten löschen"
Alle am Anwendungsfall "Nachricht durch Versicherten löschen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC 3.8 - Nachricht durch Versicherten löschen |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Der Versicherte wählt eine ihm übermittelte Nachrichten zum Löschen aus und bestätigt das Löschen.
Das FdV überträgt die Löschanforderung an den E-Rezept-Fachdienst. Die zu löschenden Nachrichten werden im E-Rezept-Fachdienst gelöscht. Der E-Rezept-Fachdienst übermittelt dem FdV eine Warning, wenn die Nachricht bereits durch den Empfänger abgerufen wurde. Abschließend wird die zu löschenden Nachricht im FdV gelöscht. |
| Nachbedingung |
|
AF_10451 - Anwendungsfall "HKP Verordnungen durch Pflegedienst abrufen (PoPP)"
Alle am Anwendungsfall "HKP Verordnungen durch Pflegedienst abrufen (PoPP)" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC 6.15 - HKP Verordnungen durch Pflegedienst abrufen (PoPP) |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Das Primärsystem liest unter Nutzung eines im Rahmen von PoPP zulässigen Kartenlesegerät die eGK ein.
Das Primärsystem ruft für diese eGK den Anwendungsfall zum Erstellen eines PoPP-Token auf. Im Ergebnis erhält das Primärsystem, sofern die eGK nicht gesperrt und das Authentifizierungszertifikat gültig ist, einen PoPP-Token. Das Primärsystem übermittelt dem PoPP-Token, um die einlösbaren Verordnungen des Versicherten vom E-Rezept-Fachdienst abzurufen. Der E-Rezept-Fachdienst prüft die Gültigkeit des PoPP-Tokens. Der E-Rezept-Fachdienst übermittelt die Informationen zu jeder einlösbaren Verordnung. |
| Nachbedingung |
|
Mit diesem Anwendungsfall kann ein Pflegedienst, nachdem ein Versicherter die Zugriffsinformation zur Verordnung übermittelt hat, die Verordnung zur unverbindlichen Einsicht abrufen.
AF_10452 - Anwendungsfall "HKP Verordnung durch Pflegedienst unverbindlich einsehen"
Alle am Anwendungsfall "HKP Verordnung durch Pflegedienst unverbindlich einsehen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC 6.23 - HKP Verordnung durch Pflegedienst unverbindlich einsehen |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Ein Mitarbeiter des Pflegedienstes wählt einen Verordnungstoken zum Abruf im Primärsystem aus.
Das Primärsystem ermittelt die Zugriffsinformationen (Task-ID, AccessCode_read oder AccessCode_state) zur Verordnung. Das Primärsystem ruft die Verordnung vom E-Rezept-Fachdienst ab. |
| Nachbedingung |
|
Mit diesem Anwendungsfall kann ein Pflegedienst, nachdem ein Versicherter die Zugriffsinformation zur Verordnung übermittelt hat (Zuweisen der Verordnung durch den Versicherten), die Verordnung abrufen.
AF_10453 - Anwendungsfall "HKP Verordnung durch Pflegedienst verbindlich abrufen"
Alle am Anwendungsfall "HKP Verordnung durch Pflegedienst verbindlich abrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC 6.1 - HKP Verordnung durch Pflegedienst verbindlich abrufen |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Ein Mitarbeiter des Pflegedienstes wählt einen Verordnungstoken zum Abruf im Primärsystem aus.
Das Primärsystem ermittelt die Verordnungs-ID und den AccessCode_state aus dem Verordnungstoken. Das Primärsystem ruft mit der Verordnungs-ID und dem AccessCode_state die Verordnung vom E-Rezept-Fachdienst ab. Der E-Rezept-Fachdienst ändert den Status der Verordnung auf "in-progress" und den Business-Status der Verordnung auf "assigned". Der E-Rezept-Fachdienst erzeugt ein Geheimnis zur Statusänderung "in-progress", welches im E-Rezept-Fachdienst gespeichert und dem Primärsystem zusammen mit der Verordnung übermittelt wird. |
| Nachbedingung |
|
Mit diesem Anwendungsfall kann ein Pflegedienst eine zuvor verbindlich abgerufene Verordnung an den Versicherten zurückgeben.
AF_10454 - Anwendungsfall HKP "Verordnung durch Pflegedienst zurückgeben"
Alle am Anwendungsfall "Verordnung durch Pflegedienst zurückgeben" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC 6.2 - Verordnung durch Pflegedienst zurückgeben |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Ein Mitarbeiter des Pflegedienstes markiert über das Primärsystem eine Verordnung zum Zurückgeben und bestätigt es.
Das Primärsystem übermittelt beim Aufruf des E-Rezept-Fachdienstes die Verordnungs-ID, den AccessCode_state und das Geheimnis zur Statusänderung "in-progress". Der E-Rezept-Fachdienst ändert den Status der Verordnung. |
| Nachbedingung |
|
Mit diesem Anwendungsfall kann eine Pflegeeinrichtung die im Fachdienst für die Pflegeeinrichtung hinterlegten Nachrichten abrufen.
AF_10455 - Anwendungsfall "Nachrichten durch Pflegedienst empfangen"
Alle am Anwendungsfall "Nachrichten durch Pflegedienst empfangen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC 6.6 - Nachrichten durch Pflegedienst empfangen |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Der Mitarbeiter des Pflegedienstes wählt im Primärsystem aus, ob er einen Verordnungstoken über die TI empfangen möchte oder der Verordnungstoken als 2D-Code vorliegt.
Das Empfangen über die TI erfolgt mithilfe des E-Rezept-Fachdienstes. Das Primärsystem fragt beim E-Rezept-Fachdienstes an, ob für die Telematik-ID des Pflegedienstes neue Nachrichten vorliegen und lädt diese herunter. Im Falle der Alternative über den 2D-Code wandelt das Primärsystem die optische Repräsentation in die Textform um. |
| Nachbedingung |
|
Mit diesem Anwendungsfall kann ein Pflegedienst auf die Nachricht eines Versicherten (Übermittlung der Zugriffsinformation zum unverbindlichen Einsehen) reagieren.
AF_10456 - Anwendungsfall "Nachricht durch Pflegedienst versenden"
Alle am Anwendungsfall "Nachricht durch Pflegedienst versenden" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC 6.7 - Nachricht durch Pflegedienst versenden |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Der Mitarbeiter des Pflegedienstes wählt im Primärsystem die Nachricht eines Versicherten zu einer Verordnung aus und erstellt eine Antwortnachricht. Der sichere Versand über die TI erfolgt mithilfe des E-Rezept-Fachdienstes.
Das Primärsystem stellt die Nachricht in den E-Rezept-Fachdienst ein. |
| Nachbedingung |
|
Mit diesem Anwendungsfall kann eine Pflegeeinrichtung eine durch ihn eingestellte Nachricht im Fachdienst löschen.
AF_10457 - Anwendungsfall "Nachricht durch Pflegedienst löschen"
Alle am Anwendungsfall "Nachricht durch Pflegedienst löschen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC 6.9 - Nachricht durch Pflegedienst löschen |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Der Mitarbeiter des Pflegedienstes wählt eine von ihm übermittelte Nachricht zum Löschen aus und bestätigt das Löschen.
Das Primärsystem überträgt die Löschanforderung an den E-Rezept-Fachdienst. Der E-Rezept-Fachdienst löscht die zu löschenden Nachrichten. Der E-Rezept-Fachdienst übermittelt dem Primärsystem eine Warnung, wenn die Nachricht bereits durch den Empfänger abgerufen wurde. Das Primärsystem löscht abschließend die zu löschenden Nachrichten. |
| Nachbedingung |
|
AF_10458 - Anwendungsfall HKP "Verordnung durch Kostenträger abrufen"
oAlle am Anwendungsfall "Verordnung durch Kostenträger abrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC 7.12 - Verordnung durch Kostenträger abrufen |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Das Kostenträgerverwaltungssystem ermittelt die Verordnungs-ID und den AccessCode_state aus dem Verordnungstoken.
Das Kostenträgerverwaltungssystem ruft mit der Verordnungs-ID und dem AccessCode_state die Verordnung vom E-Rezept-Fachdienst ab. |
| Nachbedingung |
|
AF_10459 - Anwendungsfall "Nachrichten durch Kostenträger empfangen"
Alle am Anwendungsfall "Nachrichten durch Kostenträger empfangen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC 7.6 - Nachrichten durch Kostenträger empfangen |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Der E-Rezept-Fachdienst sendet über die Subscription eine Information an das Kostenträgerverwaltungssystem, dass eine neue Nachricht für den Kostenträger vorliegt.
Das Kostenträgerverwaltungssystem fragt beim E-Rezept-Fachdienstes an, ob für die Telematik-ID des Kostenträgers neue Nachrichten vorliegen, und lädt diese herunter. Im Falle der Alternative über den 2D-Code wandelt das Kostenträgerverwaltungssystem die optische Repräsentation in die Textform um. |
| Nachbedingung |
|
Mit diesem Anwendungsfall kann ein Anfrage-Workflow gestartet werden. Der Anwendungsfall kann durch den Versicherten, einen Pflegedienst oder einen Kostenträger ausgeführt werden.
AF_10460 - Anwendungsfall "Anfrage-Workflow starten"
Alle am Anwendungsfall "Anfrage-Workflow starten" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC x.30 - Anfrage-Workflow starten |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Der Prozessbeteiligte füllt die QuestionnaireResponse aus.
Das Clientsystem übermittelt beim Aufruf des E-Rezept-Fachdienstes die Art der zu erstellenden Anfrage, die Telematik-ID des Bearbeiters, den AccessCode_state sowie die QuestionnaireResponse. Der E-Rezept-Fachdienst setzt den Status der Verordnung auf "on-hold" und erstellt eine Anfragetask des gewünschten Typs mit dem Status "requested". Der E-Rezept-Fachdienst übermittelt den neu erstellten Anfragetask an das Clientsystem. |
| Nachbedingung |
|
Im Anwendungsfall für den Versicherten wird "UC 5.1 - AuthN-Token durch Versicherten anfordern" ausgeführt, sofern kein gültiger AuthN-Token vorhanden ist. Das FdV übermittelt beim Aufruf der Operation $request-subworkflow keinen AccessCode_state an den E-Rezept-Fachdienst.
Mit diesem Anwendungsfall kann ein Anfrage-Workflow zurückgezogen werden. Der Anwendungsfall kann durch den Anfragenden (Versicherter, Pflegedienst oder Kostenträger) ausgeführt werden.
AF_10461 - Anwendungsfall "Anfrage-Workflow abbrechen"
Alle am Anwendungsfall "Anfrage-Workflow abbrechen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC x.31 - Anfrage-Workflow abbrechen |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Der Prozessbeteiligte markiert im Clientsystem die Anfrage, die abgebrochen werden soll, und bestätigt dies.
Das Clientsystem übermittelt beim Aufruf des E-Rezept-Fachdienstes die Anfragetask-ID. Der E-Rezept-Fachdienst prüft, ob der Status des Anfragetask "requested" ist. Der E-Rezept-Fachdienst setzt den Status des Anfragetasks auf "cancelled" und setzt den fachlichen sowie den technischen Status des Workflows, der dem Anfragetask zugrunde liegt, auf den vorherigen Status zurück. Der E-Rezept-Fachdienst übermittelt den aktualisierten Anfragetask an das Clientsystem. |
| Nachbedingung |
|
Der Versicherte führt "UC 5.1 - AuthN-Token durch Versicherten anfordern" aus, sofern kein gültiger AuthN-Token vorhanden ist.
Mit diesem Anwendungsfall können alle Anfrage-Workflows abgerufen werden. Der Anwendungsfall kann durch den Anfragenden, den Bearbeiter, dem Versicherten und weiteren Prozessbeteiligten ausgeführt werden.
AF_10462 - Anwendungsfall "Alle Anfrage-Workflows abrufen"
Alle am Anwendungsfall "Alle Anfrage-Workflows abrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC x.32 - Alle Anfrage-Workflows abrufen |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Das Clientsystem fragt beim E-Rezept-Fachdienst alle Anfrage-Workflows an, optional gefiltert nach einem bestimmten Status.
Der E-Rezept-Fachdienst übermittelt eine Liste der Anfrage-Workflows an das Clientsystem. |
| Nachbedingung |
|
Im Anwendungsfall für den Versicherten wird "UC 5.1 - AuthN-Token durch Versicherten anfordern" ausgeführt, sofern kein gültiger AuthN-Token vorhanden ist.
Mit diesem Anwendungsfall kann ein Anfrage-Workflow abgerufen werden. Der Anwendungsfall kann durch den Anfragenden, den Bearbeiter, dem Versicherten und weiteren Prozessbeteiligten ausgeführt werden.
AF_10463 - Anwendungsfall "Anfrageinformationen abrufen"
Alle am Anwendungsfall "Anfrageinformationen abrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC x.33 - Anfrageinformationen abrufen |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Der Prozessbeteiligte markiert im Clientsystem eine Anfrage, die aktualisiert werden soll, und bestätigt dies.
Das Clientsystem übermittelt beim Aufruf des E-Rezept-Fachdienstes die Anfragetask-ID. Der E-Rezept-Fachdienst übermittelt die Anfrageinformationen an das Clientsystem. |
| Nachbedingung |
|
Im Anwendungsfall für den Versicherten wird "UC 5.1 - AuthN-Token durch Versicherten anfordern" ausgeführt, sofern kein gültiger AuthN-Token vorhanden ist.
Mit diesem Anwendungsfall kann ein Anfrage-Workflow zum Bearbeiten abgerufen werden. Der Anwendungsfall kann durch den Bearbeiter (Verordnender, Pflegedienst oder Kostenträger) ausgeführt werden.
AF_10464 - Anwendungsfall "Anfrage-Workflow zur Bearbeitung abrufen"
Alle am Anwendungsfall "Anfrage-Workflow zur Bearbeitung abrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC x.34 - Anfrage-Workflow zur Bearbeitung abrufen |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Der Prozessbeteiligte wählt einen zugewiesenen Anfragetask aus.
Das Clientsystem ruft anhand der Anfragetask-ID den Anfragetask sowie die QuestionnaireResponse beim E-Rezept-Fachdienst ab. Der E-Rezept-Fachdienst prüft den Status des Anfragetasks. Der E-Rezept-Fachdienst setzt den Status des Anfragetasks auf "in-progress". |
| Nachbedingung |
|
Mit diesem Anwendungsfall kann ein Anfrage-Workflow abgeschlossen werden. Der Anwendungsfall kann durch den Bearbeiter (Verordnender, Pflegedienst oder Kostenträger) ausgeführt werden.
AF_10465 - Anwendungsfall "Anfrage-Workflow abschließen"
Alle am Anwendungsfall "Anfrage-Workflow abschließen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC x.35 - Anfrage-Workflow abschließen |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Ein Prozessbeteiligter markiert im Clientsystem eine Anfrage, die abgeschlossen werden soll, und bestätigt dies.
Das Clientsystem übermittelt beim Aufruf des E-Rezept-Fachdienstes die Anfragetask-ID sowie den benötigen Datensatz, der das Dokument beinhaltet. Der E-Rezept-Fachdienst extrahiert das Dokument und erstellt dafür eine DocumentReference mit Metadaten. Der E-Rezept-Fachdienst fügt diese DocumentReference dem Output des Anfragetask sowie dem Input des Verordnungs-Tasks hinzu. Der E-Rezept-Fachdienst setzt den Status des Anfragetasks auf "completed", setzt den fachlichen Status des Workflows, der dem Anfragetask zugrunde liegt, auf den nächsten Status und den technischen Status der Verordnung wieder auf den vorherigen Status zurück. Der E-Rezept-Fachdienst übermittelt den aktualisierten Anfragetask an das Clientsystem. |
| Nachbedingung |
|
Mit diesem Anwendungsfall kann ein Anfrage-Workflow abgelehnt werden. Der Anwendungsfall kann durch den Bearbeiter (Verordnender, Pflegedienst oder Kostenträger) ausgeführt werden.
AF_10466 - Anwendungsfall "Anfrage-Workflow ablehnen"
Alle am Anwendungsfall "Anfrage-Workflow ablehnen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC x.36 - Anfrage-Workflow ablehnen |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Ein Prozessbeteiligter markiert im Clientsystem eine Anfrage, die abgelehnt werden soll, und bestätigt dies.
Das Clientsystem übermittelt beim Aufruf des E-Rezept-Fachdienstes die Anfragetask-ID sowie den Ablehnungsgrund. Der E-Rezept-Fachdienst setzt den Status des Anfragetasks auf "rejected" und setzt den fachlichen sowie den technischen Status der Verordnung, die dem Anfragetask zugrunde liegt, auf den vorherigen Status zurück. Der E-Rezept-Fachdienst übermittelt den aktualisierten Anfragetask an das Clientsystem. |
| Nachbedingung |
|
Mit diesem Anwendungsfall kann ein Workflow-begleitendes Dokument eingestellt werden. Der Anwendungsfall kann durch den Verordnender, einen Pflegedienst oder den Kostenträger ausgeführt werden.
AF_10467 - Anwendungsfall "Workflow-begleitendes Dokument einstellen"
Alle am Anwendungsfall "Workflow-begleitendes Dokument einstellen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC x.50 - Workflow-begleitendes Dokument einstellen |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Ein Prozessbeteiligte markiert im Clientsystem eine Verordnung, für die ein Dokument hochgeladen werden soll, und bestätigt dies.
Das Clientsystem erstellt eine DocumentReference mit dem Dokument als Blob sowie den zugehörigen Metadaten. Das Clientsystem übermittelt beim Aufruf des E-Rezept-Fachdienstes die Verordnungs-ID, den AccessCode_state sowie die DocumentReference. Der E‑Rezept-Fachdienst extrahiert das Dokument and speichert es. Der E-Rezept-Fachdienst fügt die DocumentReference dem Input des Workflows zur Verordnung hinzu. Der E-Rezept-Fachdienst übermittelt die aktualisierte Verordnung an das Clientsystem. |
| Nachbedingung |
|
Mit diesem Anwendungsfall können alle Dokumente zu einem Task abgerufen werden. Der Anwendungsfall kann durch den Versicherten, den Verordnender, einen Pflegedienst oder einen Kostenträger ausgeführt werden.
AF_10468 - Anwendungsfall "Alle Dokumente zu einem Task abrufen"
Alle am Anwendungsfall "Alle Dokumente zu einem Task abrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC x.51 - Alle Dokumente zu einem Task abrufen |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Ein Prozessbeteiligte markiert im Clientsystem eine Verordnung, für die die Dokumente abgerufen werden sollen, und bestätigt dies.
Das Clientsystem übermittelt beim Aufruf des E-Rezept-Fachdienstes die Verordnungs-ID sowie entweder den AccessCode_read oder AccessCode_state. Der E-Rezept-Fachdienst übermittelt die aktuellen gültigen Dokumente der Verordnung als Bundle mit DocumentReferences an das Clientsystem. |
| Nachbedingung |
|
Im Anwendungsfall für den Versicherten wird "UC 5.1 - AuthN-Token durch Versicherten anfordern" ausgeführt, sofern kein gültiger AuthN-Token vorhanden ist.
Mit diesem Anwendungsfall kann ein Dokument abgerufen werden. Der Anwendungsfall kann durch den Versicherten, den Verordnenden, einen Pflegedienst oder den Kostenträger ausgeführt werden.
AF_10469 - Anwendungsfall "Ein Dokument abrufen"
Alle am Anwendungsfall "Ein Dokument abrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.
| Name | UC x.52 - Ein Dokument abrufen |
|---|---|
| Vorbedingung |
|
| Kurzbeschreibung (Außenansicht) | Ein Prozessbeteiligte markiert im Clientsystem ein Dokument, das abgerufen werden sollen, und bestätigt dies.
Das Clientsystem übermittelt beim Aufruf des E-Rezept-Fachdienstes die Document-ID sowie entweder den AccessCode_read oder den AccessCode_state. Der E-Rezept-Fachdienst übermittelt die Metadaten des Dokuments und/oder das Dokument an das Clientsystem. |
| Nachbedingung |
|
Im Anwendungsfall für den Versicherten wird "UC 5.1 - AuthN-Token durch Versicherten anfordern" ausgeführt, sofern kein gültiger AuthN-Token vorhanden ist. Das FdV übermittelt beim Aufruf der Operation $request-subworkflow keinen AccessCode_state an den E-Rezept-Fachdienst.
Da das Feature zur elektronischen Verordnung von häuslicher Krankenpflege in den bestehenden E-Rezept-Fachdienst integriert wird, gilt grundsätzlich das Datenschutz- und Sicherheitskonzept des E-Rezept-Fachdienstes, insbesondere das Bedrohungsmodell und die Maßnahmen, die zum Schutz der dort verarbeiteten Daten getroffen wurden.
Ergänzend gelten folgende Punkte:
Die gesetzliche Grundlage für das Feature zur elektronischen Verordnung von häuslicher Krankenpflege ist durch § 312 Abs. 1 Nr. 12 SGB V gegeben.
Das Feature erweitert den Nutzerkreis des E-Rezept-Fachdienstes um die Leistungserbringerinstitutionsrolle „ambulanter Pflegedienst“, die auch als technische Rolle (oid_institution-pflege) abgebildet wird. Die fachlich relevante Leistungserbringerrolle „Pflegefachperson“ wird hingegen nicht in einer technischen Rolle abgebildet, da der Zugriff auf den Fachdienst durch Leistungserbringer und Kostenträger weiterhin rollenbasiert funktioniert. Der Zugriff von Kostenträgern beruht auf § 312 Abs. 7 SGB V sowie dem zukünftigen § 361c des Gesetzes für Daten und digitale Innovation im Gesundheitswesen (GDIG, Stand: Kabinettsentwurf).
Seitens der Client-Systeme, die auf den Fachdienst zugreifen, kommt das Kostenträgerverwaltungssystem (KTRVS) und das Pflegeprimärsystem (PPS) hinzu.
Maßgebliche neue Informationsobjekte des Features sind:
Die Autorisierung für den Zugriff auf die Daten einer Verordnung ist wie folgt geregelt:
Versicherte greifen mittels FdV mit E-Rezept-Funktionalität auf die Verordnungen im E-Rezept-Fachdienst zu. Nach einer erfolgreichen Authentisierung ist der Versicherte zum Zugriff auf seine Daten im E-Rezept-Fachdienst autorisiert. Der Versicherte erhält beim Abruf seiner Verordnungen die Daten für das Erstellen eines Verordnungstokens, den er entweder mittels einer Nachricht an einen Pflegedienst bzw. seinem Kostenträger senden kann oder bei einem Pflegedienst vor Ort als 2D-Code anzeigen und scannen lassen kann.
Leistungserbringer in der Rolle „verordnender Leistungserbringer“ erhalten beim Erzeugen einer Verordnung den AccessCode_state, mit dem sie anschließend auf die Verordnung zugreifen können.
Leistungserbringer in der Rolle „ambulanter Pflegedienst“ werden vom Versicherten
autorisiert.
Kostenträger werden vom Versicherten mittels FdV oder dem Patientenausdruck für einen Zugriff berechtigt (AccessCode_state).
Nach § 361c Abs. 3 GDIG (Stand: Kabinettsentwurf) können Versicherte einen Zugriff durch die Kostenträger auch ohne Zurverfügungstellung eines Verordnungstoken autorisieren. Dies wird durch einen Telefon-Code ermöglicht, den Versicherte dem Kostenträger telefonisch übermitteln können und der auf dem Patientenausdruck steht. Dieser Code wird durch den Fachdienst generiert und beim Erzeugen einer Verordnung durch ein PS eines verordnenden Leistungserbringers vom Fachdienst an das PVS übertragen. Die Eigenschaften des Telefon-Codes werden in der Spezifikation festgelegt und folgend ggf. auftretende Implikationen (z.B. Restrisiken) daraus betrachtet. Durch einen Zugriff des Kostenträgers mittels Telefon-Codes erhält dieser für weitere Zugriffe einen Verordnungstoken. Um den Anwendungsfall des Clearings zwischen Kostenträgern bei Unzuständigkeit eines Kostenträgers zu unterstützen, ist es erforderlich, dass der Kostenträger, der vom Versicherten den Telefon-Code erhalten hat, den Verordnungstoken an einen anderen Kostenträger weitergeben kann, damit dieser auf die Verordnungsdaten zugreifen kann. Der Versicherte kann den Zugriff des anderen Kostenträgers in seinem Zugriffsprotokoll nachvollziehen.
Der Zugriff auf die Protokolle der Versicherten ist zunächst – wie bisher – nur durch den Versicherten selbst mittels FdV möglich. Zusätzlich sieht das GDIG in § 307 Abs. 5 vor, dass die koordinierende Stelle in der gematik zukünftig Betroffenen auf Anforderung Auskunft über die Protokolldaten der Zugriffe erteilt. Diese Zugriffe durch die gematik sind in diesem Konzept noch nicht berücksichtigt.
Neben Verordnungsdaten werden begleitende Dokumente dazu im Fachdienst verarbeitet. Die zugelassenen Dokumententypen entsprechen denen, die für die ePA zugelassen sind. Damit wird die Schad-Code-Problematik gleichartig zur ePA behandelt.
Grenzen der Sicherheitsleistung:
Die Abrechnung von Verordnungen für Versicherte mit einem Kostenträger erfolgt außerhalb der Fachanwendung.
Versicherte sind – wie bisher auch - für einen sorgfältigen Umgang mit dem Patientenausdruck verantwortlich und müssen diesen vor Beschädigung, Zerstörung sowie Verlust schützen.
Die Weitergabe von Verordnungstoken zwischen Beteiligten ist anwendungsfallabhängig eine Notwendigkeit und erfolgt nicht mittels des E-Rezept-Fachdienstes. Dass die am Austausch beteiligten Akteure sichere Übermittlungsverfahren (z.B. KIM, TI-M) dafür auswählen, liegt in ihrer Verantwortung.
| Kürzel | Erläuterung |
|---|---|
| AC | 2-stelliger Abrechnungscode |
| AC/TK | Vergütungsvereinbarungen (Abrechnungscode/Tarifkennzeichen) |
| BPolHfV | Bundespolizei-Heilfürsorgeverordnung |
| CAN | Card Access Number |
| eEB | Ersatzbescheinigung |
| eGK | Elektronische Gesundheitskarte |
| FD | Fachdienst |
| FdV | Frontend des Versicherten |
| FHIR | HL7 Fast Healthcare Interoperability Resources |
| G-BA | Gemeinsamer Bundesausschuss |
| G-ID | Gesundheits-ID |
| GKV | Gesetzliche Krankenversicherung |
| GPOS | Gebührenpositionsnummer |
| HBA | Heilberufsausweis |
| HKP | Häusliche Krankenpflege |
| HKP-RL | HKP-Richtlinie (Häusliche Krankenpflege-Richtlinie) |
| ICD | Internationale statistische Klassifikation der Krankheiten |
| ID | Kennung / Identifier |
| IK | Institutskennzeichen |
| KIS | Krankenhausinformationssystem |
| KTR | Kostenträger |
| KTRVS | Kostenträgerverwaltungssystem |
| KVNR | Krankenversichertennummer |
| LE | Leistungserbringer |
| LEI | Leistungserbringer Institution |
| MD | Medizinischer Dienst |
| MFA | Medizinische(r) Fachangestellte(r) / Mitarbeiter medizinischer Institution |
| MVP | Minimal Viable Produkt |
| MVZ | Medizinisches Versorgungszentrum |
| OCI | Online-Checkin |
| PD | (ambulanter) Pflegedienst |
| PDL | Pflegedienstleitung |
| PFP | Pflegefachperson |
| pHKP | Psychiatrische häusliche Krankenpflege |
| PKV | Private Krankenversicherung |
| PoPP | Proof of Patient Presence |
| PPS | Pflegeprimärsystem |
| PS | Primärsystem |
| PVS | Praxisverwaltungssoftware |
| QES | Qualifizierte elektronische Signatur |
| RL | Richtlinie |
| SEG | Soldatenentschädigungsgesetz |
| SGB V | Sozialgesetzbuch Fünftes Buch |
| SGB VII | Sozialgesetzbuch Siebtes Buch |
| SGB IX | Sozialgesetzbuch Neuntes Buch |
| SGB XIV | Sozialgesetzbuch Vierzehntes Buch |
| TI | Telematik Infrastruktur |
| TID | Telematik-ID |
| TK | 5-stelliges Tarifkennzeichen |
| vdek | Verband der Ersatzkassen |
| VO | Verordnung |
| VO-k | Verordnung - Korrekturvorschlag |
| VO-nV | Verordnung - neue Version |
| VZD | Verzeichnisdienst |
Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur.
| [Quelle]
|
Herausgeber: Titel
|
|---|---|
| [gemGlossar]
|
gematik: Glossar der Telematikinfrastruktur,
URL: https://fachportal.gematik.de/fileadmin/Fachportal/Glossar/gemGlossar_V5.2.0.pdf , abgerufen am 30.07.2025 |
| [gemKPT_PoPP] | Technisches Konzept PoPP URL: https://gemspec.gematik.de/docs/gemKPT/gemKPT_PoPP/gemKPT_PoPP_V1.0.0/ , abgerufen am 30.07.2025
|
| [gemSpec_OID] | Spezifikation Festlegung von OIDs,
URL: https://gemspec.gematik.de/docs/gemSpec/gemSpec_OID/gemSpec_OID_V3.20.0/ , abgerufen am 30.07.2025 |
| [gemSpec_PoPP_Service] | Spezifikation Proof of Patient Presence (PoPP)-Service,
URL: https://gemspec.gematik.de/prereleases/Draft_PoPP_25_1/gemSpec_PoPP_Service_V1.0.0_CC2/ , abgerufen am 05.09.2025 |
| [Quelle]
|
Herausgeber (Erscheinungsdatum): Titel
|
|---|---|
| [DemoVO_HKP] | TI-Simulator @Figma: Darstellung eines Happy Cases im TI-Demonstrator (Ende-zu-Ende Prozess ohne Korrekturschleifen)
URL: https://www.figma.com/proto/1ertibUle84XTSWzXAUWuW/Showcase-%7C-eVerordnung-HKP?node-id=52-54090&p=f&t=urAHNTeve6iPXURP-0&scaling=scale-down&content-scaling=fixed&page-id=1%3A441&starting-point-node-id=52%3A54090&show-proto-sidebar=1 , abgerufen am 29.07.2025 |
| [DGUV_RL_HKP] | Deutsche Gesetzliche Unfallversicherung, Gemeinsamen Richtlinie der Verbände der Unfallversicherungsträger über häusliche Krankenpflege,
URL: https://www.dguv.de/medien/inhalt/reha_leistung/richtlinien_uvt/pflege.pdf |
| [GBA_HKP_RL] | Gemeinsamer Bundesausschuss, Häusliche Krankenpflege-Richtlinie - Richtlinie über die Verordnung von häuslicher Krankenpflege, 31.10.2023
URL: https://www.g-ba.de/richtlinien/11/ , abgerufen am 30.07.2025 |
| [GKV_SV-EmpfehlungHKP] | GKV-Spitzenverband, Rahmenempfehlungen nach § 132a Abs. 1 SGB V zur Versorgung mit häuslicher Krankenpflege, Berlin, 18.12.2023
URL: https://www.gkv-spitzenverband.de/media/dokumente/krankenversicherung_1/ambulante_leistungen/haeusliche_krankenpflege/20231218_Rahmenempfehlungen_132a_Abs.1_SGB_V_zur_Versorgung_mit_Haeuslicher_Krankenpflege.pdf , abgerufen am 30.07.2025 |
| [GKV_SV-Kennzahlen] | GKV-SV: Pressemitteilung, GKV-Kennzahlen
URL: https://www.gkv-spitzenverband.de/gkv_spitzenverband/presse/zahlen_und_grafiken/gkv_kennzahlen/gkv_kennzahlen.jsp , abgerufen am 29.07.2025 |
| [SGB_V] | Bundesministerium für Justiz und für Verbraucherschutz - Bundesamt für Justiz, Sozialgesetzbuch (SGB) Fünftes Buch (V) - Gesetzliche Krankenversicherung,
URL: https://www.gesetze-im-internet.de/sgb_5/ , abgerufen am 30.07.2025 |
| [StatBA_Pflege] | Statistisches Bundesamt, Pflege - Pflegeheime und ambulante Pflegedienste, Stand 18. Dezember 2024
URL: https://www.destatis.de/DE/Themen/Gesellschaft-Umwelt/Gesundheit/Pflege/Tabellen/pflegeeinrichtungen-deutschland.html , abgerufen am 30.07.2025 |
| [StatBA_VersorgArt] | Statistisches Bundesamt, Pflegebedürftige nach Versorgungsart, 2025
URL: https://www.destatis.de/DE/Themen/Gesellschaft-Umwelt/Gesundheit/_Grafik/_Interaktiv/pflege-versorgungsart.html , abgerufen am 30.07.2025 |
| [Implementation Guide SDC] | HL7 International, Structured Data Capture 4.0.0 - STU 4, 2026
URL: https://hl7.org/fhir/uv/sdc/en/ |
Abbildung 12: Fachlicher Soll-Prozess der elektronischen Verordnung von häuslicher Krankenpflege
Hier finden Sie die Links zu allen Demonstratoren, welche die unterschiedlichen Anwendungsfälle zeigen.
Disclaimer: Die Demonstratoren verbildlichen einen Zwischenstand der Datensätze. Diese sind zum Zeitpunkt der Veröffentlichung des Fachkonzepts noch nicht final, weshalb es noch zu Änderungen kommen kann. Die Demonstratoren sollen die Prozessschritte aus Sicht der unterschiedlichen Akteure in fiktiven Primärsystemen und Apps darstellen. Der Fokus liegt daher mehr auf dem Prozess als auf den dargestellten Datensätzen. Die Demonstratoren dienen der Veranschaulichung und haben keinen normativen Charakter.
Tabelle 45: Übersicht über die im Dokument verlinkten Demonstratoren
| Prozessschritt | Anwendungsfallbeschreibung | Link |
|---|---|---|
| Ende zu Ende "Happy Case" |
|
Link zum Demonstrator |
| Verordnungs-prozess | Der Arzt konfiguriert sein Profil "HKP Standard" mit den Leistungen Medikamentengabe, Kompressionsbehandlung und Positionswechsel zur Dekubitusbehandlung. | Link zum Demonstrator |
| Verordnungs-prozess | Der Arzt erstellt eine Verordnung mit Leistungen der HKP für Renate mit dem Standard-Profil, ergänzt die Leistung Blutzuckermessung und wählt die Leistung "Positionswechsel zur Dekubitusbehandlung" als Blanko-Leistung aus. Es wird dargestellt, wie im PVS auf Fehler in der Verordnung hingewiesen wird und wie Hinweise aus der HKP-RL angezeigt werden können. | Link zum Demonstrator |
| Verordnungs-prozess | Der Arzt erstellt für Aurelia eine Verordnung mit dem Profil pHKP, welches die beiden Leistungen pHKP und Medikamentengabe beinhaltet. Dies führt im Hintergrund zu zwei Verordnungen, was Aurelia auch anschließend in dem FdV sieht (als separate Einträge). Aurelia löst nur die Verordnung für pHKP beim Pflegedienst Hand & Herz ein. | Link zum Demonstrator |
| Verordnungs-prozess | Ein Jahr später erstellt der Arzt eine Folgeverordnung auf Basis der Verordnungsübersicht für Renate, jedoch ohne die Leistung "Wundversorgung", die nach einem Krankenhausaufenthalt nur für kurze Zeit benötigt wurde. | Link zum Demonstrator |
| Einlöseprozess | Renate sieht die HKP-Verordnung in dem FdV ein und weist sie dem Pflegedienst Hand & Herz zu. Die Verordnung wird im PPS vom Pflegedienst Hand & Herz angezeigt. Elena nimmt die Verordnung an. | Link zum Demonstrator |
| Einlöseprozess | Pflegefachperson Daniel ruft die Verordnung mit der eGK von Renate in der App seines Pflegeprimärsystems ab. Die Verordnung wird im PPS angezeigt. Dabei wird auch gleich die Berechtigung auf die ePA von Renate eingerichtet. | Link zum Demonstrator |
| Einlöseprozess | Renate braucht Unterstützung bei der Suche nach einem Pflegedienst von ihrer Krankenkasse. Sie sieht die Verordnung in der App und berechtigt die Kasse darauf. Die Kasse sieht die Verordnung in ihrem System. Darauf basierend kann ein Beratungsgespräch stattfinden. | Link zum Demonstrator |
| Unverbindliche Anfrage | Pflegedienst Hand & Herz konfiguriert automatische Antworten auf Verfügbarkeitsanfragen. Dabei wird eine automatische Ablehnung aller Anfragen zunächst deaktiviert und dann werden zwei neue Regeln auf Basis der Qualifikation und des Einzugsgebietes eingestellt. | Link zum Demonstrator |
| Unverbindliche Anfrage | Renate sieht die Verordnung in dem FdV ein und fragt bei verschiedenen Pflegediensten (Hand & Herz, Integral) die Verfügbarkeit an. Hand & Herz sieht die Anfrage und antwortet mit Verfügbarkeit. Renate sieht die Rückmeldung und weist die Verordnung verbindlich dem Pflegedienst Hand & Herz zu. | Link zum Demonstrator |
| Korrektur-prozesse | Pflegedienst Hand & Herz sieht die Verordnung von Renate und bemerkt drei Fehler (eine Einschränkung fehlt, es wurde "Medibox stellen" anstatt "Medigabe" verordnet, die Leistung Dekubitusbehandlung fehlt). Der Arzt sieht die Anfrage und bestätigt die fehlende Einschränkung, die Änderung der Medigabe anstelle von Medibox stellen und lehnt Dekubitusbehandlung ab. Pflegedienst sieht die Rückmeldung in dem PPS. | Link zum Demonstrator |
| Korrektur-prozesse | Die gematiker Kasse sieht die Verordnung von Karl-Heinz ein und bemerkt einen Fehler. Die verordnete und beantragte Häufigkeit ist nicht valide, und sie bittet den Arzt daher um Prüfung. Der Arzt bestätigt und korrigiert die Häufigkeit. Die Kasse sieht die neue Version der Verordnung und genehmigt diese. | Link zum Demonstrator |
| Angaben des Pflegedienstes erfassen | Die Verordnung von Renate wird im PPS angezeigt und die Angaben zur Leistungserbringung ergänzt. | Link zum Demonstrator |
| Leistungs-entscheidung | Die Kasse sieht den Vorgang von Renate Berger und genehmigt alle Leistungen. Die Entscheidung wird in dem PPS, dem PVS und dem FdV angezeigt. | Link zum Demonstrator |
| Leistungs-entscheidung | Die Kasse sieht den Vorgang von Karl-Heinz und genehmigt einen kürzeren Leistungszeitraum. Die Entscheidung wird in dem PPS, dem PVS und dem FdV angezeigt. | Link zum Demonstrator |
| Leistungs-entscheidung | Die Kasse sieht den Vorgang von Karl-Heinz und lehnt die Verordnung ab. Die Entscheidung wird in dem PPS, dem PVS und dem FdV angezeigt. | Link zum Demonstrator |
| Kosten-erstattung | Rolf hat eine Blankoverordnung und reicht diese NACH der Einlösung mit seinem FdV seiner privaten Versicherung ein. | Link zum Demonstrator |
| Kosten-erstattung | Rolf hat eine Verordnung und reicht diese VOR der Einlösung mit seinem FdV bei seiner privaten Versicherung ein. | Link zum Demonstrator |
| Kosten-erstattung | Rolf hat eine Verordnung und reicht diese NACH der Einlösung mit seinem FdV bei seiner privaten Versicherung ein. | Link zum Demonstrator |
Zum GoLive der elektronischen Verordnung der häuslichen Krankenpflege bzw. zum Start der Pilotierung werden nicht alle denkbaren beteiligten Akteure und nicht alle Anwendungsfälle und Funktionen realisiert sein. Daher wird in diesem Kapitel eine Unterscheidung bzw. ein Ausblick auf Ausbaustufen vorgenommen. Die Übersichten sind im Rahmen der technischen Konzeption und Spezifikation erneut zu prüfen bzw. zu bestätigen.
Die nachfolgende Tabelle listet die potenziell beteiligten Akteure an der Umsetzung des vorliegenden Fachkonzeptes auf und ordnet sie einem Release oder einer Ausbaustufe zu:
Tabelle 46: Überblick über die beteiligten Akteure - im MVP und Ausbaustufen
| Akteure | Minimal Viable Product
(Version 1) |
Ausbaustufe |
|---|---|---|
| Verordnende Ärzte | ||
| niedergelassene Vertragsärzte und ärztliche Psychotherapeuten (oid_arzt) | x | |
| Psychologische Psychotherapeuten (oid_ps_psychotherapeut) | x | |
| Entlassmanagement Krankenhaus | x | |
| Privatärzte (oid_arzt) | x | |
| Arbeitsmediziner | x | |
| Rehabilitationseinrichtungen | x | |
| Sanitätsdienst der Bundeswehr | x | |
| Öffentlicher Gesundheitsdienst (ÖGD) | x | |
| Kostenträger | ||
| Gesetzliche Krankenversicherung | x | |
| Gesetzliche Unfallversicherung | x | |
| Private Krankenversicherung | x | |
| Beihilfe | x | |
| sonstige Kostenträger Bundespolizei | x | |
| Postbeamtenkrankenkasse | x | |
| Krankenversorgung der Bundesbahnbeamten | x | |
| Krankenversorgung für Polizeivollzugsbeamte | x | |
| Krankenversorgung für sonstige heilfürsorgeberechtigte Beamte | x | |
| Krankenversorgung für Soldaten der Bundeswehr | x | |
Tabelle 47: Überblick über die Anwendungsfälle - im MVP und Ausbaustufen
| Thema | Nr. in Prozessbild | Minimal Viable Product
(Version 1) |
Ausbaustufe |
|---|---|---|---|
| Anwendungsfälle der Ärzte | |||
| Mitarbeiter in der Arztpraxis bereitet Verordnung inhaltlich vor (und legt sie auf Signaturliste) | 1.1 | x | |
| Verordnung gemäß Infomodell ausstellen und signieren (inkl. Option zur Blankoverordnung) | 1.2 | x | |
| Anzeigen von Vorgaben der HKP-RL im Verordnungsprozess (z. B. max. Verordnungsdauer) | 1.1 / 1.2 | in Klärung | |
| Verordnung wird fachlich validiert vor Einstellen auf den Fachdienst | 1.2 | in Klärung | |
| Bereitstellen von begleitenden Unterlagen auf digitalem Weg | 1.2 | x | |
| Automatisches Erstellen von separaten Verordnungen bei bestimmten Leistungen | 1.2 | x | |
| Mitarbeiter in der Arztpraxis löscht Verordnung | 1.3 | x | |
| Einsicht in den Verordnungsübersicht in der ePA (und die automatische Übermittlung der Verordnungsdaten in die ePA) | / | x | |
| Anwendungsfälle des Versicherten | |||
| Verbindliche Einlösung via eGK/G-ID & PoPP in App von PPS, via FdV, via eGK-Stecken, via Patientenausdruck | 2.4 | x | |
| Automatische Einlösung in Stamm-Pflegedienst via FdV | / | x | |
| Unverbindliche Anfrage bei Pflegediensten via FdV | 2.5 | x | |
| Bereitstellen der Verordnung für Kostenträger bei Sachleistungsprinzip (z. B. für Beratung oder alternative Wege der Kostenerstattung) | 2.2 / 2.3 | x | |
| Bereitstellen der Verordnung für Kostenträger bei Kostenerstattungsprinzip | 2.5 | x | |
| Darstellen von Basis-VZD-Daten in FdV für Auswahl des Leistungserbringers | 2.4 / 2.5 | x | |
| Darstellen von um Mehrwertdaten angereicherte Angaben des Pflegedienstes in FdV für Auswahl des Leistungserbringers (z. B. durch VZD oder andere Dienste) | 2.4 / 2.5 | x | |
| Leistungserbringer im Verordnungszeitraum wechseln ohne neue Verordnung auszustellen | / | x | |
| Versicherter bestätigt Leistungsnachweise im FdV | / | x | |
| Versicherter löscht Verordnung | 2.1 | x | |
| Anwendungsfälle der Pflegedienste | |||
| Verordnung verbindlich abrufen durch Pflegedienst in PPS | 3.3 | x | |
| Verordnung unverbindlich einsehen durch Pflegedienst in PPS | 3.1 / 3.2 | x | |
| Automatisierte Antworten auf Verfügbarkeitsanfrage in PPS konfigurieren | / | x | |
| Verordnung durch Pflegedienst an Versicherten zurückgeben | 3.4 | x | |
| Korrekturverfahren Pflegedienst → Arzt | 1.4 / 3.5 | x | |
| Pflegedienste ergänzen Angaben zur Leistungserbringung gemäß Datensatz | 3.7 | x | |
| Pflegedienste ergänzen Dauer & Häufigkeit bei Blanko-Leistungen gemäß Datensatz | 1.5 / 3.6 | x | |
| Pflegedienst reicht Vorgang zur Leistungsentscheidung bei Kostenträger (Sachleistungsprinzip) ein | 3.8 | x | |
| Pflegedienste holen sich Bestätigung der Leistungsnachweise per PoPP ein | / | x | |
| Pflegedienste prüfen Korrekturanfrage und korrigieren eigene Angaben | 3.9 | x | |
| Pflege eigener Standort-VZD-Daten (SelfServicePortal) | / | x | |
| Pflege eigener Mehrwert-VZD-Daten (SelfServicePortal)
In Abhängigkeit einer Lösung durch das VZD-Team oder indem andere Dienste eingebunden werden |
/ | x
|
|
| Anwendungsfälle der Kostenträger (Sachleistungsprinzip) | |||
| Kostenträger haben Zugriff auf Vorgang (für Leistungsentscheidung) | 4.2 | x | |
| Kostenträger haben Zugriff auf Vorgang (für Beratungszwecke oder alternative Wege der Kostenerstattung) | 4.1 | x | |
| Korrekturverfahren Kostenträger → Arzt | 1.6 / 1.7 / 4.8 | x | |
| Korrekturverfahren Kostenträger → Pflegedienst | 3.9 / 4.7 | x | |
| Kostenträger dokumentieren Entscheidung der Prüfung im Fachdienst (Genehmigung, Teilgenehmigung, Ablehnung) | 4.4 / 4.5 / 4.6 | x | |
| Kostenträgerwechsel bei Unzuständigkeit durch Übergabe des Vorgangs an andere gesetzliche Krankenkasse oder gesetzliche Unfallversicherung statt neuer Verordnung
Hinweis für MVP: der Workaround über KIM-Nachrichten zwischen den Kostenträger kann genutzt werden |
4.3 |
x | |
| Kostenträgerwechsel bei Unzuständigkeit durch Ändern auf IK des neuen Kostenträgers / Zuordnung an neuen Kostenträger | / | x | |
| Leistungserbringerwechsel | / | x | |