Elektronische Gesundheitskarte und Telematikinfrastruktur





Feature:

Elektronische Verordnung
Häuslicher Krankenpflege (HKP)




Version2.0.0_CC
Revision1689535
Stand10.08.2026
Statuszur Abstimmung freigegeben
Klassifizierungöffentlich_Entwurf
ReferenzierunggemF_VO_HKP


Dokumentinformationen

Ä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

Inhaltsverzeichnis

1 Vorwort

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

2 Einordnung des Dokuments

2.1 Motivation

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. 

2.2 Rechtsgrundlagen

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.

2.3 Zielgruppe und Zielsetzung des Dokuments

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

2.4 Vorgehensweise

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.

2.4.1 User Story und Anforderungen

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.

2.5 Abgrenzung und Einordnung bzgl. E-Rezept für Arzneimittel

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.

2.6 Bezeichnungen

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.
  • eine Praxisverwaltungssoftware (PVS)
  • ein Krankenhausinformationssystem (KIS) 
  • NEU: Kostenträgerverwaltungssystem (KTRVS)
  • NEU: Pflegeprimärsystem (PPS)
Das PVS wird in diesem Dokument synonym für das KIS verwendet, sofern dies nicht explizit abgegrenzt und hervorgehoben wird. 
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.

2.7 Leistungsgewährungsprinzipien

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):
  • [§ 132a Abs. 1 SGB V] "Der Spitzenverband Bund der Krankenkassen und die für die Wahrnehmung der Interessen von Pflegediensten maßgeblichen Spitzenorganisationen auf Bundesebene haben unter Berücksichtigung der Richtlinien nach § 92 Abs. 1 Satz 2 Nr. 6 gemeinsam Rahmenempfehlungen über die einheitliche und flächendeckende Versorgung mit häuslicher Krankenpflege abzugeben[...]"
  • In den Rahmenempfehlungen sind nach [§ 132a Abs. 1 Satz 4 Nummer 6 SGB V] Verfahren der Prüfung der Leistungspflicht der Krankenkassen zu erfassen. Die [Rahmenempfehlungen nach § 132a Abs. 1 SGB V zur Versorgung mit häuslicher Krankenpflege] enthalten diese Empfehlungen in §2 "Empfehlungen zu Verordnungs- und Genehmigungsverfahren".
  • Es schließen nach [§ 132a Abs. 4 Satz 1 SGB V] "[...] die Landesverbände der Krankenkassen und die Ersatzkassen gemeinsam und einheitlich Verträge mit den Leistungserbringern."
Gesetzliche Unfallversicherung Sachleistungsprinzip ist der Normalfall, Kostenerstattung im Ausnahmefall siehe:
  • Die häusliche Krankenpflege ist Teil der Heilbehandlung [§ 27 Abs. 1 Nr. 5 SGB VII] und wird grundsätzlich als Sachleistung erbracht.
  • Bei einer häuslichen Krankenpflege durch eine Pflegefachperson sind die Aufwendungen im Allgemeinen bis zur Höhe der vertraglichen Vereinbarungen nach [§ 132a Abs. 4 SGB V] der gesetzlichen Krankenkassen zu übernehmen.
  • Ausnahmefall für Kostenerstattung: Sofern eine Pflegefachperson nicht gestellt werden kann oder wenn ein Grund vorliegt, von der Bereitstellung abzusehen, hat der Unfallversicherungsträger die Kosten für eine selbst beschaffte geeignete Pflegefachperson in angemessener Höhe zu erstatten. (Siehe auch [Gemeinsame Rrichtlinien] der Verbände der Unfallversicherungsträger über häusliche Krankenpflege.)
  • Für Personen, die eine Wehrdienstbeschädigung erlitten haben oder deren Angehörige und Hinterbliebene ist 
    [§16 Satz 1 Nr. 7 Soldatenentschädigungsgesetz (SEG)] zu beachten.
Private Krankenversicherung Kostenerstattungsprinzip
  • Es besteht keine Vertragsbeziehung zwischen Privaten Krankenversicherungen und Leistungserbringern der ambulanten Pflege.
  • Vertragspartner der ambulanten Pflegedienste sind die Privatversicherten selbst, d.h. Privatversicherten beauftragen den Pflegedienst, erhalten Rechnungen für erbrachte Leistungen vom Pflegedienst und wenden sich zwecks Kostenerstattung an den eigenen Kostenträger. Maßgeblich für die Kostenerstattung ist der individuelle Vertrag des Versicherten mit dem Kostenträger.
Beihilfe Kostenerstattungsprinzip
  • Siehe Private Krankenversicherung. 
  • Maßgeblich für die Kostenerstattung ist der festgelegte Leistungsumfang für Gesundheitsleistungen des Beamten im Verhältnis zu dessen privater Krankenversicherung.
Sonstige Kostenträger: Bundespolizei Sachleistungsprinzip Verwaltungsvorschrift zur Bundespolizei Heilfürsorgeverordnung[]:
  • Kapitel 2: Das Sachleistungsprinzip ist festgeschrieben in Anlehnung an die Gesetzliche Krankenversicherung. Der Heilfürsorgeberechtigte wird medizinisch versorgt ohne dafür in Vorleistung gegenüber den Leistungserbringern zu treten. Eine Kostenerstattung ist nur im Rahmen der BPolHfV in Verbindung mit dieser Verwaltungsvorschrift möglich.
  • Kapital 4.2: Bei der Gewährung von häuslicher Krankenpflege ist zu beachten, dass durch die Heilfürsorge aufgrund fehlender Satzung analog zu § 37 Absatz 2 Satz 4 SGB V zusätzlich zur Behandlungspflege nach § 37 Absatz 1 Satz 1 SGB V als häusliche Krankenpflege auch Grundpflege und hauswirtschaftliche Versorgung gemäß den Vorgaben des Verbandes der Ersatzkassen (vdek) oder einer der Mitgliedskassen, erbracht werden können; Dauer und Umfang richten sich ebenfalls danach. Die kassenärztliche Verordnung ist zur Genehmigung [... vorab ...] einzureichen
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.
  • Die Festlegung wird im Einzelfall vom jeweiligen Kostenträger bestimmt
  • Weitere noch nicht in dieser Tabelle genannte Sonstige Kostenträger sind in [§362 SGB V] aufgeführt. 

3 Anforderungen aus Nutzersicht

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:

3.1 Anforderungen der Versicherten

3.1.1 Rollen im Versorgungsprozess

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.

3.1.2 Hemmnisse im heutigen Prozess

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.

3.1.3 Anforderungen an den digitalen Prozess

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. 

3.2 Anforderungen der Arztpraxen

3.2.1 Rollen im Versorgungsprozess

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

3.2.2 Hemmnisse im heutigen Prozess

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.

3.2.3 Anforderungen an den digitalen Prozess

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

3.3 Anforderungen der Krankenhäuser

3.3.1 Rollen im Versorgungsprozess

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. 

3.3.2 Hemmnisse im heutigen Prozess

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.

3.3.3 Anforderungen an den digitalen Prozess

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. 

3.4 Anforderungen der ambulanten Pflegedienste

3.4.1 Rollen im Versorgungsprozess

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.

3.4.2 Hemmnisse im heutigen Prozess

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.

3.4.3 Anforderungen an den digitalen Prozess

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.

3.5 Anforderungen der gesetzlichen Kranken- und Unfallversicherung

3.5.1 Rolle eines Sachbearbeiters in einer gesetzlichen Krankenkasse oder Unfallversicherung

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.

3.5.2 Hemmnisse im heutigen Prozess

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.

3.5.3 Anforderungen an den digitalen Prozess

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.

3.6 Anforderungen der privaten Versicherungsunternehmen und der Beihilfe

3.6.1 Rollen im Versorgungsprozess

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. 

3.6.2 Hemmnisse im heutigen Prozess

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.

3.6.3 Anforderungen an den digitalen Prozess

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.

4 Prämissen für die Ausgestaltung der elektronischen Verordnung HKP

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.

4.1 Übergreifende Prämissen

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 

  1. je Verordnung neu vergeben werden 
  2. als Referenz für Rückfragen und Anfragen in Bezug auf die Verordnung verwendet werden
  3. einen Rahmen um die verordneten Leistungen darstellen. Um folgende Leistungen wird (durch das PVS automatisiert) ein Rahmen gesetzt:

Hinweise:

P1.2 Eindeutige Kennung je Leistung. Jede Leistungsposition wird einzeln verordnet und genehmigt:

  1. Die Angaben des PD müssen nicht alle Leistungsdaten der ärztlichen Verordnung enthalten, d.h. es können auch nur Teile der Leistungspositionen vom Pflegedienst beantragt werden. Je Verordnung kann es nur einen Antrag geben. Bei einer Entscheidung kann auch weiterhin differenziert werden. Die ärztliche Verordnung wird immer vollständig inkl. aller Maßnahmen betrachtet.
  2. Der Kostenträger im Sachleistungsprinzip kann dennoch immer das Gesamtbild je Versicherten (KVNR) bei der Leistungsentscheidung bewerten.
  3. Die Leistungspositionen einer Verordnung können nur gesamtheitlich durch einen Leistungserbringer erbracht werden.
  4. Abgerechnet werden Leistungen dennoch entsprechend Rahmenempfehlungen nach § 132a Abs. 1 SGB V und den Verträgen nach § 132a Abs. 4 SGB V.

P1.3 Parallel zur Verordnung stehen begleitende Unterlagen elektronisch zur Verfügung (z. B. für Leistungsentscheidung):

  1.  Obligate, vom Arzt zu übermittelnde Begleitunterlagen, die einen Bezug zu den HKP-Verordnungen des Versicherten haben (z. B. Behandlungsplan für pHKP) können mit der Verordnung über die Fachanwendung HKP abgelegt und von der Pflege, dem Versicherten, der Arztpraxis und dem Kostenträger (Sachleistungsprinzip) abgerufen werden. Wird die Verordnung vom Fachdienst gelöscht, gilt dies auch für die dazugehörigen Unterlagen. Die Partner des BMV-Ä prüfen, inwieweit diese Unterlagen zukünftig in Form strukturierter Daten digital übermittelt werden können.

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)

  1. Die Angaben des Versicherten, die bisher auf der Rückseite des bisherigen Muster 12 erfasst wurden, sind nicht Bestandteil des ärztlichen HKP-Verordnungsdatensatzes. 
  2. Versicherte müssen keinen schriftlichen Antrag unterschreiben, um zu bestätigen, dass keine im Haushalt lebende Person die Leistung übernehmen kann.

4.2 Prämissen für Endnutzersysteme

P2.1 Das Primärsystem der Ärzte unterstützt durch Hilfestellungen beim Verordnen. Die Unterstützung kann erfolgt durch:

  1. Erinnerung an das rechtzeitige Ausstellen neuer Verordnungen, sollten Verordnungszeiträume in bisherigen Verordnungen demnächst ablaufen, sofern es sich nicht um einmaligen/temporären Bedarf handelte (dauerhafte Versorgungsnotwendigkeit) 
  2. Angaben zur verordnenden Person und Institution, sowie die Stammdaten der Versicherten werden automatisch vom PVS befüllt. 
  3. Übernahme von Daten aus bisherigen Verordnungen, falls vorhanden und für den aktuellen Bedarf zutreffend 
  4. Übernahme von Daten aus Anfragen nach Folgeverordnungen falls vorhanden und für aktuellen Bedarf zutreffend 
  5. Anzeige der laut HKP-RL empfohlenen Dauer und Häufigkeit der Maßnahme als Hinweistext
  6. Anzeige der laut HKP-RL bestehenden Regelung, ob die Festlegung von Häufigkeit und Dauer auch durch die Pflegefachperson möglich ist, sodass Ärzte bewusst entscheiden können, ob sie selbst die Festlegung treffen müssen oder es dem Pflegedienst überlassen, die Häufigkeit und Dauer einzuschätzen und festzulegen (Blankoverordnung)
  7. Kommunikationsmöglichkeiten, die die Kommunikation rund um die Verordnungen bündeln und einen Bezug auf die Verordnung herstellen.
  8. Kommunikationsmöglichkeiten, sodass Korrekturschleifen im Rahmen der Vorbereitung der Leistungsentscheidung mit Pflegedienst, Versicherten und Kostenträger (Sachleistungsprinzip) schnell und digital erfolgen können und einen Bezug auf die Verordnung besteht.
  9. Der Arzt wird bei gesetzlich Versicherten über die Entscheidung Genehmigung, Ablehnung, Teilgenehmigung informiert. 

P2.2 Das Primärsystem der Pflege unterstützt die Pflegefachperson dabei

  1. Verordnungsdaten in das PPS zu übernehmen, sodass diese nicht mehr abgetippt werden müssen. Pflegedienste kennzeichnen lediglich Leistungen, die nicht oder nur teilweise übernommen werden können (nur Erfassung von Abweichungen). 
  2. Angaben über die Leistungserbringerinstitution werden automatisch vom Pflegedokumentationssystem befüllt.
  3. Anzeige der laut HKP-RL empfohlenen Dauer und Häufigkeit der Maßnahme als Hinweistext für Blankoverordnungen.
  4. durch Kommunikationsmöglichkeiten, die zu einer Verordnungs-ID die Kommunikation rund um die Verordnungen bündeln und einen Bezug auf die Verordnung herstellen.
  5. dass Korrekturen zu Verordnungen und den Angaben der Leistungen des Pflegedienstes zusammen mit Ärzten bzw. Kostenträgern (Sachleistungsprinzip) schnell und digital erfolgen können und ein Bezug auf die Verordnung besteht.
  6. Auch bei Ablehnung der Kostenübernahme müssen die Inhalte aus der ärztlichen Verordnung im Pflegeprimärsystem erhalten bleiben, bspw. für MD-Prüfungen.
  7. Der Pflegedienst wird bei gesetzlich Versicherten über die Entscheidung (Genehmigung, Ablehnung, Teilgenehmigung) in seinem PPS informiert.

4.3 Weitere Prämissen

P3.1 Datenerfassung

  1. Die Inhalte der Verordnung werden im Rahmen des Informationsmodells (siehe auch Kapitel 8 Datensätze) definiert.
  2. Der Fachdienst akzeptiert nur valide Datensätze. Die genaue Betrachtung der technischen Möglichkeiten hierfür wird im Rahmen der technischen Konzeption durch gematik aufbereitet.
  3. In den Angaben des Pflegedienstes werden immer die Informationen zur Institution erfasst. Bei Erstverordnung und bei Folgeverordnung mit Abweichungen zur vorherigen Verordnung werden zudem vollständige Angaben zu den geplanten Leistungen erfasst. Diese können aus dem Verordnungsdatensatz übernommen und angepasst werden (z. B. Arzt verordnet 3x täglich, PD ändert auf 2x täglich). Es werden optional die Leistungen um die Gebührenpositionen (GPOS) aus den Vergütungsvereinbarungen (AC/TK) ergänzt. Bei Folgeverordnungen ohne Änderungen zur vorherigen Verordnung ist lediglich diese Angabe zu erfassen.
  4. Die Leistungsentscheidung erfolgt je Leistungsposition. Kostenträger im Sachleistungsprinzip betrachten dabei weiterhin den gesamten Kontext eines Versicherten. Je Leistungsposition wird der Status der Leistungsentscheidung im Fachdienst für alle ersichtlich hinterlegt. Dabei gilt:
    1. Alle an der Behandlung Beteiligten werden über die Entscheidung und über die Gründe (mit jeweils individuellen Texten) informiert, sodass Arzt- und Pflegeprimärsysteme den Statuswechsel erkennen und Arzt/PD informiert werden
    2. Versicherte können den Status jederzeit aktuell im FdV einsehen, werden aber auch auf den vereinbarten Kanälen durch die Krankenkassen informiert
    3. im Rahmen der Entscheidung werden optional die GPOS-Nummern je Leistungsposition ergänzt

P3.2 Datenintegrität:

  1. Die Integrität und Authentizität von Verordnung, Angaben des Pflegedienstes, Blankoverordnungsdatensatz und Entscheidung werden durch geeignete elektronische Signaturen garantiert. Details ergeben sich aus der Beschreibung der Datensätze.  
  2. Diese Signaturen lassen sich mehrere Jahre lang überprüfen
  3. Die Integrität wird erzielt, da die Datensätze als unveränderbar betrachtet werden

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

5 Darstellung des fachlichen Soll-Prozesses

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

6 Anwendungsfälle

6.1 Verordnungsprozess

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

6.1.1 Erstellen von separaten Verordnungen

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.

6.1.2 Verordnung im Entlassmanagement

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

6.1.3 Übersicht über alle verordneten Leistungen in der ePA

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

6.1.4 User Stories

Als Arzt möchte ich ...

  1. VO einfach erstellen und signieren können, um bei der Umstellung auf die elektronische Verordnung keine aufwendigen Schulungen für mich und mein Team zu benötigen.
  2. an das Auslaufen einer Verordnung in meinem PVS erinnert werden, damit ich rechtzeitig eine neue Verordnung ausstellen kann. 
  3. beim Ausfüllen des Formulars durch das PVS unterstützt werden, sodass die VO der HKP-RL entspricht und nur plausible Verordnungen erstellt werden. 
  4. beim Ausfüllen des Formulars Hinweise zur Verordnungsdauer und -häufigkeit angezeigt bekommen, sodass ich mir Folgeverordnungen durch längere Verordnungsdauern sparen kann. 
  5. innerhalb des Verordnungsprozesses benötigte Dokumente (z. B. Behandlungsplan für pHKP) der Verordnung beifügen können, sodass diese der Pflege und den Kostenträgern direkt zur Verfügung stehen. 
  6. in meinem PVS das Verordnungsformular konfigurieren können (und mir Profile mit definierten Leistungen definieren können), sodass ich häufig verordnete Leistungen direkt ausfüllen kann. 
  7. mehrere vorbereitete elektronische Verordnungen (auch mit unterschiedlichen Leistungen - Arzneimittel/HKP/etc.) mit einem Klick signieren können.
  8. dass mein PVS automatisch technisch getrennte Verordnungen für die Leistungen der somatischen HKP, der chronischen Wundversorgung oder pHKP erstellt, sodass ich daran nicht denken muss und mein Patient die Verordnungen auch bei unterschiedlichen Pflegediensten einlösen kann. 
  9. eine Übersicht über alle bisherigen elektronischen Verordnungen der HKP meines Patienten einsehen können, sodass ich passende Folgeverordnungen darauf basierend erstellen kann, auch wenn andere Ärzte HKP-Leistungen verordnet haben.
  10. handlungsleitende Fehlermeldungen angezeigt bekommen, wenn bei der Signatur (und dem Einstellen auf dem Fachdienst) etwas schiefläuft, damit ich weiß, was zu tun ist.
  11. bei Folgeverordnungen den Verordnungsinhalt der letzten Verordnung nach einer Überprüfung der Inhalte übernehmen können, um weniger Aufwand zu haben. 
  12. im Rahmen von Korrekturschleifen die Vorschläge des Pflegedienstes übernehmen und diese nach Prüfung und ggf. notwendiger Änderung als neue Version der Verordnung signieren können. 
  13. bei Korrekturschleifen, dass die neue Version der Verordnung direkt dem anfragenden Pflegedienst zur Verfügung gestellt wird, ohne dass ich den Empfänger manuell auswählen muss, sodass ich damit keine Mehraufwände habe.
  14. einsehen können, welche Angaben der Pflegedienst zur Leistungserbringung (insbesondere bei Blankoverordnungen) erfasst hat, damit ich weiß, wie der Versicherte versorgt wird. 
  15. in definierten Ausnahmefällen die Verordnung auch ohne Heilberufsausweis signieren können, sodass die Versorgung des Versicherten sichergestellt ist. 

Als MA einer Pflegeeinrichtung möchte ich ...

  1. mich darauf verlassen können, dass nur verordnungsfähige Leistungen verordnet werden können.

Als MA eines Kostenträgers möchte ich ...

  1. durch eine Plausibilitätsprüfung bei dem Ausstellen der Verordnung eine gesteigerte Ausfüllqualität erhalten, um eine effiziente Prüfung zu ermöglichen.
  2. dass Verordnende immer eine Verordnung mit dem gültigen Datensatz erstellen können, sodass die Übergangszeiten kurz sind und keine parallelen Prozesse oder Strukturen aufrechterhalten werden müssen.

6.2 Veränderter Leistungsumfang innerhalb des Verordnungszeitraums

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.

6.3 Verordnungen löschen

Die Löschrechte werden auch in Kapitel [8 Datensätze] in tabellarischer Form zusammengefasst.

6.3.1 Ärztliche Verordnung löschen

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.

6.3.2 Blankoverordnung 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.

6.3.3 Angaben zur Leistungserbringung des PD 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.

6.3.4 Datensätze zur Korrekturanfrage löschen

Das Löschen von Korrekturanfragen wird in der Spezifikation ausgearbeitet und daher an dieser Stelle nicht weiter beschrieben.

6.3.5 User Stories

Als Versicherter möchte ich ...

  1. , dass mein Arzt die Verordnung nur löschen kann, wenn ich sie noch nicht eingelöst oder zugewiesen habe oder sie vom Pflegedienst nach dem Zuweisen wieder zurückgegeben wurde.
  2. in meinem FdV nachvollziehen können, wenn ein Arzt eine Verordnung löscht.
  3. eine Verordnung vollständig löschen können, wenn ich sie nicht in Anspruch nehmen möchte oder die Leistung abschließend erbracht wurde und der Verordnungszeitraum in der Vergangenheit liegt, sodass keine überflüssigen Daten gespeichert sind.

Als Arzt möchte ich ...

  1. , dass das Löschen der Verordnung einfach und mit wenigen Klicks möglich ist.
  2. im Fehlerfall erkennen können, warum das Löschen nicht funktioniert hat, um ggf. mit einem Pflegedienst, dem Versicherten oder der Kasse oder meinem IT-Dienstleister in Kontakt treten zu können.

6.4 Sonderfälle der Kostenerstattung

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: 

6.5 Anwendungsfälle im Einlöseprozess

6.5.1 Verbindliche Einlösung bei einem Pflegedienst

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:

  1. Einlösen mit eGK / Gesundheits-ID via Pflegeprimärsystem und PoPP:
    1. im mobilen Szenario per eGK / Gesundheits-ID via PoPP
    2. eGK stecken in ein im Rahmen von PoPP zulässiges Kartenlesegerät beim Pflegedienst (ohne PIN zur eGK des Versicherten)
    3. Check-In in dem Pflegedienst mit der Gesundheits-ID (durch Scan eines QR-Codes des Pflegedienstes)
  2. angemeldete Nutzer (mit eGK & PIN oder Gesundheits-ID) in einem zugelassenen Frontend des Versicherten (FdV) weisen digital einem Pflegedienst zu oder zeigen Zugriffsinformationen als Datamatrix-Code im FdV an, der von Pflegefachperson abgescannt werden kann.
  3. Patientenausdruck, von dem der Datamatrix-Code von der Pflegefachperson abgescannt werden kann.

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

6.5.1.1 Einlöseweg 1 - eGK/Gesundheits-ID via Pflegeprimärsystem & PoPP

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: 

6.5.1.2 Einlöseweg 2 - Frontend des Versicherten

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: 

6.5.1.3 Einlöseweg 3 - Patientenausdruck

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.

6.5.1.4 Einlöseweg 4 - Stammpflegedienst auch ohne FdV einrichten

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.

6.5.2 Unverbindliche Anfrage bei Pflegediensten via FdV

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: 

6.5.3 Beratung durch die Kostenträger

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:

  1. Gesetzliche Krankenversicherung: im Rahmen der Wahl der Kostenerstattung nach § 13 Abs. 2 SGB V soll der Krankenkasse der Zugriff direkt nach Signatur der Arztpraxis bzw. des Arztes ermöglicht werden bzw. im Falle der Kostenerstattung nach § 37 Abs. 4 SGB V, können Versicherte dem Kostenträger Zugriff auf eine Verordnung ermöglichen. Der Zugriff ermöglicht in beiden [] die Bereitstellung der Verordnung für Dokumentationspflichten der Kostenträger.
  2. Gesetzliche Unfallversicherung: Sofern eine Pflegefachperson nicht gestellt werden kann oder wenn ein Grund vorliegt, von der Bereitstellung abzusehen, hat der Unfallversicherungsträger die Kosten für eine vom Versicherten selbst beauftragte geeignete Pflegefachperson in angemessener Höhe zu erstatten. Hierzu erfolgt eine Beratung, für die Versicherte dem Kostenträger Zugriff auf eine Verordnung ermöglichen können. Der Zugriff ermöglicht die Bereitstellung der Verordnung für Dokumentationspflichten der gesetzlichen Unfallversicherungsträger.

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: 

6.5.4 Einlösen als Vertreter

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.

6.5.5 User Stories

Als Versicherter möchte ich ...

  1. die Verordnung komfortabel und ohne Medienbruch bei dem Pflegedienst meiner Wahl einlösen können. Hierfür möchte ich die gleichen Einlösewege nutzen, wie für andere Verordnungen, damit ich nichts Neues lernen muss.
  2. die Möglichkeit haben, unverbindlich die Verfügbarkeit eines Pflegedienstes für die Leistungen meiner Verordnung anzufragen, um sicherzustellen, dass meine Versorgung zeitnah stattfinden kann.
  3. bei einer unverbindlichen Anfrage die Option haben, weitere Angaben (z. B. zu Wunschzeiträumen der Leistungserbringung oder Interesse an weiteren Leistungen oder Pflegesachleistungen) zu ergänzen, sodass ich einen geeigneten Pflegedienst finde.
  4. bei der Suche nach einem passenden Pflegedienst in dem FdV nur die Pflegedienste angezeigt bekommen, die für meine verordneten Leistungen qualifiziert sind.
  5. nach den Rückmeldungen der verschiedenen Pflegedienste entscheiden können, welcher der Pflegedienste die Verordnung final einlösen können soll.
  6. informiert werden, sobald Pflegedienste eine Rückmeldung auf eine unverbindliche Anfrage gegeben haben, ob sie die Leistungen übernehmen können oder nicht, damit ich mich selbst schnell verbindlich entscheiden kann.
  7. einzelne Verordnungen bei unterschiedlichen Pflegediensten einlösen können.
  8. in dem FdV nachvollziehen können, wenn ein Pflegedienst meine Zuweisung der Verordnung angenommen (oder abgelehnt) hat und in welchem Status sich die Verordnung danach befindet.
  9. in dem FdV einstellen können, dass mein Stammpflegedienst immer automatisch Folgeverordnungen erhalten soll, sodass ich nicht jedes Mal aktiv werden muss. 
  10. in dem FdV meine Favoriten-Pflegedienste markieren, damit ich diese bei der Einlösung einer neuen Verordnung schneller finde und nicht jedes Mal manuell suchen muss. 
  11. meinen Anspruch auf einen Ausdruck zur Verordnung in Anspruch nehmen können, insbesondere bei Erst-Verordnungen und wenn ich kein FdV nutze, damit ich bei der Suche nach einem Pflegedienst lesen kann, was mir verordnet wurde. 
  12. meinem Kostenträger die Verordnung vor der Einlösung bei einem Pflegedienst bereitstellen, um bspw. eine Beratung zu einem geeigneten Leistungserbringer zu erhalten oder einen vorläufige Kostenzusage zu erhalten.
  13. meinem Kostenträger die Verordnung als Beleg einreichen, um z. B. ein persönliches Budget, eine Kostenerstattung oder Vorabgenehmigung (PKV) zu beantragen.
  14. meine Kontaktdaten für den Pflegedienst hinterlegen können, wenn ich eine unverbindliche Anfrage oder eine Zuweisung durchführe.

Als MA in einem Pflegedienst möchte ich ...

  1. Verfügbarkeitsanfragen von Versicherten in meinem PPS übersichtlich angezeigt bekommen, um schnell zu prüfen, ob ich die angefragte Leistung erbringen kann, damit ich meine Kapazitäten besser planen kann.
  2. bei einer Verfügbarkeitsanfrage alle Informationen aus der Verordnung (z. B. Diagnosen, Leistungen, etc.) und der Anfrage (z. B. Wunschzeiträume oder weitere Angaben des Versicherten) einsehen, um prüfen können, ob unser Pflegedienst die notwendigen Kapazitäten hat, um die Leistung erbringen zu können.
  3. Kontaktdaten des Anfragenden sehen können, um ggf. Kontakt mit ihm über einem anderen Kanal aufnehmen zu können.
  4. zeitnah eine Rückmeldung geben können, ob die Leistungen zum aktuellen Zeitpunkt übernommen werden können, um den Versicherten eine schnelle Entscheidung zu ermöglichen.
  5. zur verbindlichen Einlösung alle verfügbaren Einlösewege unterstützen können, sodass ich keinen Versicherten abweisen muss (z. B. Scan des Patientenausdrucks, mobiler Abruf via PoPP und eGK, Empfang der Verordnung via FdV).
  6. vor der verbindlichen Einlösung alle Informationen aus der Verordnung (z. B. Diagnosen, Leistungen, etc.) einsehen, um zu prüfen und die Zusage geben zu können, dass unser Pflegedienst die notwendigen Kapazitäten hat, um die Leistung zu erbringen.
  7. nach der verbindlichen Einlösung und vor dem Start des Entscheidungsprozesses die Verordnung über mein Pflegeprimärsystem an den Versicherten zurückgeben können, falls ich die Verordnung nicht annehmen kann/darf/möchte und die Verordnung somit durch einen anderen Pflegedienst erbracht werden soll (soll auch geräteübergreifend funktionieren). 
  8. mein Pflegeprimärsystem die CAN der Versicherten dauerhaft speichert, sodass ich diese nicht jedes Mal eingeben muss, wenn eine Folgeverordnung auf meinem mobilen Gerät via eGK und PoPP bei mir eingelöst wird
  9. in der Lage sein, den Versicherten transparent über den Status der Anfrage zu informieren, insbesondere wenn die Leistungen nicht übernommen werden können, um Missverständnisse zu vermeiden und alternative Lösungen zu ermöglichen.
  10. konfigurieren können, ob und wie automatisch auf Anfragen durch meine PPS geantwortet wird, damit ich damit keinen manuellen Aufwand habe. (z. B. wenn ich aktuell keine Kapazitäten habe, sollen Anfragen automatisch abgelehnt werden).
  11. bei der Antwort auf die Verfügbarkeitsanfrage an den Versicherten auch zusätzliche Bemerkungen per Freitext hinzufügen können.

Als verordnender Arzt möchte ich ...

  1. , dass ich nach Einstellen der Verordnung keine weiteren Schritte unternehmen muss.

Als MA eines Kostenträgers möchte ich ...

  1. einen vollelektronischen Prozess, sodass ich keine papiergebundenen Unterlagen mehr aufbewahren muss. 
  2. (nach Einverständnis durch den Versicherten) auch schon vor der Einlösung bei einem Pflegedienst einen unkomplizierten Zugriff auf die Verordnungsdaten erhalten, um die Versicherten optimal zur Leistungsinanspruchnahme beraten und leistungsrechtlich beurteilen zu können.
  3. dass die Verordnung und z. B. ein Behandlungsplan für pHKP vollautomatisiert überspielt werden (an/in die Systeme der KTR) und nicht einzeln, versichertenbezogen und manuell von den Mitarbeitenden der Krankenkassen abgerufen werden müssen. 

6.6 Angaben des Pflegedienstes erfassen

6.6.1 Angaben zur Leistungserbringung des Pflegedienstes erfassen

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: 

6.6.2 Kompetenzerweiterung (Blankoverordnung)

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: 

6.6.3 User Stories

Als Arzt möchte ich ...

  1. , dass ich dem Pflegedienst die Entscheidung über Häufigkeit und Dauer überlassen kann, sofern dies gemäß der HKP-RL möglich ist.
  2. die gewählte Häufigkeit und Dauer von der Pflegefachperson in meinem PVS einsehen können.
  3. selbst keine Häufigkeit und Dauer bei Leistungen erfassen können, bei denen ich angegeben habe, dass die Pflegefachperson diese erfassen soll, sodass es zu keinen Unstimmigkeiten kommt. 
  4. in meinem PVS konfigurieren können, ob ich über neu eingestellte Blankoverordnungsdatensätze und Angaben zur Leistungserbringung des Pflegedienstes informiert werden möchte, oder ob ich diese nur bei Bedarf einsehen können möchte.

Als MA einer Pflegeeinrichtung möchte ich ...

  1. , dass mir ein aktuelles Verzeichnis der abrechenbaren Leistungen zur Verfügung steht (Die Vergütungsvereinbarung muss - wie jetzt - im Pflegeprimärsystem erhalten bleiben).
  2. , dass meine Stammdaten automatisch in die Blankoverordnung sowie den Angaben des Pflegedienstes für den Entscheidungsprozess übertragen werden, sodass ich keine manuellen Aufwände habe.
  3. Angaben zu verordneten Leistungen aus der Verordnung des Arztes (automatisch) in die Angaben des Pflegedienstes übernehmen können. Dabei soll sichergestellt werden, dass die Informationen zur Leistungserbringung auf Basis der verordneten Leistungen vollständig sind.
  4. , dass ich auf Unstimmigkeiten zwischen der Verordnung und den vertraglichen Vereinbarungen oder gar Unstimmigkeiten zur HKP-RL hingewiesen werde, um rechtzeitig Korrekturen vornehmen oder mit dem Arzt Rücksprache halten zu können.
  5. erfasste Angaben digital signieren können.
  6. die erfassten und signierten Angaben elektronisch übertragen können, sodass keine Papierausdrucke und kein Versand per Post erforderlich sind.
  7. beim Ergänzen der Dauer und Häufigkeit bei Blankoverordnungen nur gemäß der HKP-RL zulässige Werte eintragen können, sodass keine Korrekturschleifen benötigt werden.
  8. , dass der verordnende Arzt meine gewählte Dauer und Häufigkeit bei Blankoverordnungen in seinem PVS einsehen kann, sodass ich ihn nicht separat informieren muss. 

Als Mitarbeiter eines Kostenträgers im Sachleistungsprinzip und auch als Mitarbeiter eines Kostenträgers im Kostenerstattungsprinzip möchte ich ...

  1. , dass nur qualifizierte Pflegefachpersonen die Dauer und Häufigkeit einer Leistung erfassen können.
  2. durch eine Plausibilitätsprüfung beim Erfassen der Dauer und Häufigkeit eine gesteigerte Ausfüllqualität erhalten, um eine effiziente Prüfung zu ermöglichen.
  3. , dass Pflegedienste vorab prüfen können, ob die verordnete Leistung nach dem Vertrag mit dem Kostenträger des Versicherten und gemäß HKP-Richtlinie plausibel ist.

Als Versicherter möchte ich ...

  1. die gewählte Häufigkeit und Dauer von der Pflegefachperson in meinem FdV einsehen können.

6.7 Prozess zur Leistungsentscheidung / Kostenerstattungsanfrage

6.7.1 Für Versicherte mit einem Kostenträger nach dem Sachleistungsprinzip

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: 

6.7.2 Für Versicherte mit einem Kostenträger nach dem Kostenerstattungsprinzip

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:

  1. Verordnungsdatensatz inkl. technischer Signatur des Fachdienstes
  2. Blankoverordnungsdatensatz inkl. technischer Signatur des Fachdienstes sofern vorhanden
  3. Angaben des Pflegedienstes (Name, Adresse, IK und, sofern vorhanden, KIM-Adresse). Sofern die Auswahl und Zuweisung eines Pflegedienstes noch nicht erfolgt ist, kann der Versicherte das Kostenerstattungsanfrage-Bundle auch ohne entsprechende Angaben einreichen. Anbieter des FdV können jedoch optional – je nach Tarifart (z. B. Basistarif) – technisch vorsehen, dass eine Einreichung erst möglich ist, sobald Auswahl und Zuweisung eines Pflegedienstes abgeschlossen sind.

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: 

6.7.3 User Stories

Als Arzt möchte ich ...

  1. in meinem PVS konfigurieren können, ob ich über neu eingestellte Entscheidungsdatensätze informiert werden möchte, oder ob ich diese nur bei Bedarf einsehen können möchte. (nur gesetzliche Kranken- oder Unfallkasse sowie sonstige Kostenträger im Sachleistungsprinzip, nicht PKV und Beihilfe)

Als Mitarbeiter einer Pflegeeinrichtung möchte ich ...

  1. möglichst einfach die Angaben der Verordnung, der Blankoverordnung und der Angaben des Pflegedienstes dem Kosenträger (Sachleistungsprinzip) bereitstellen können.
  2. , dass die Verordnung zur Leistungsentscheidung automatisch dem richtigen Kostenträger übermittelt wird, sodass ich dabei keine Fehler machen kann.
  3. Einsicht in den Status der Bearbeitung eines Entscheidungsprozesses haben.
  4. eine Statusanzeige für jeden Entscheidungsprozesses sehen können.
  5. eine Information über Ablehnungsgründe zu den von mir erfassten Angaben (z. B. Dauer und Häufigkeit bei Blankoverordnung), die vom Kostenträger (Sachleistungsprinzip) für mich erfasst wurden, bzw. die (Teil-) Genehmigung einer Verordnung erhalten.
  6. die Gültigkeit der QES des Arztes prüfen können.

Als Versicherter möchte ich ...

  1. den Pflegedienst bitten können, die Verordnung zwecks Leistungsentscheidung an meinen Kostenträger weiterzuleiten (Sachleistungsprinzip).
  2. die (Blanko)Verordnung zwecks (Vorab-)Leistungsentscheidung an meinen Kostenträger eigenständig weiterleiten können (Kostenerstattungsprinzip).
  3. sehen können, dass die Verordnung zur Genehmigung beim Kostenträger vorliegt.
  4. über das Ergebnis der Leistungsentscheidung informiert werden.
  5. , dass auch mein Arzt sowie der Pflegedienst über den Status und das Ergebnis der Leistungsentscheidung automatisch und zeitnah informiert werden (Sachleistungsprinzip).

Als Mitarbeiter eines Kostenträgers im Sachleistungsprinzip möchte ich ...

  1. dass die Angaben des Pflegedienstes automatisch innerhalb des KTRS mit den vertraglichen Bedingungen abgeglichen werden, um sicherzustellen, dass alle Leistungen den aktuell vereinbarten Verträgen entsprechen.
  2. die Möglichkeit haben Verordnungen inkl. ggf. bereitgestelltem Behandlungsplan für pHKP digital zu empfangen, um sie entsprechend dem gesetzlichen Auftrag zu prüfen und dabei den Verwaltungsaufwand zu reduzieren und Prozesse effizient zu gestalten.
  3. , dass nur Verordnungen bei mir ankommen, für die ich zuständig bin (bspw. anhand der IK, TID), um unnötige Rücksprachen oder Zurückweisungen aufgrund von Unzuständigkeit zu vermeiden.
  4. nur einen Teil der verordneten Leistungen genehmigen können; möchte dem Versicherten aber ermöglichen die genehmigungsfähige Teilleistung zu erhalten.
  5. in der Lage sein, Verordnungen schnell und sicher zu überprüfen, ob die Verordnung den geltenden Richtlinien und Vorschriften entspricht bzw. bestenfalls eine Dunkelverarbeitung durchführen.
  6. , dass der Status des Entscheidungsprozesses allen Beteiligten jederzeit transparent ist und die Entscheidung automatisch mitgeteilt wird, damit unnötige Rückfragen entfallen. 
  7. über eine Schnittstelle die Daten aus den Verordnungen in andere Systeme übernehmen können (z. B. Genehmigungsschreiben auch in die ePA oder Kostenträger-Service-App stellen können).
  8. die Entscheidung über die Genehmigung/Ablehnung/Teilgenehmigung allen Beteiligten (Arzt, PD, gesetzl. Vertreter, Versicherter) medienbruchsfrei zur Verfügung stellen.
  9. die Gültigkeit der QES des Arztes prüfen können.

Als Mitarbeiter eines Kostenträgers im Kostenerstattungsprinzip möchte ich ...

  1. , dass Versicherte (Blanko)-Verordnungen optional zur Vorabgenehmigung vorlegen können.
  2. , dass Versicherte im Basistarif (Blanko)-Verordnungen inkl. Angaben zum Pflegedienst zwingend zur Genehmigung vorlegen müssen.
  3. von Versicherten die Informationen für die Genehmigung als PDF mit eingebetteten strukturierten Daten erhalten, sodass die Daten in meinem KTRVS automatisch verarbeitet werden können (Abgleich mit HKP-Richtlinie und Vertragsbedingungen in Dunkelverarbeitung).
  4. Versicherten auf elektronischem Weg (Service App des Kostenträgers) Rückmeldung zum Genehmigungsverfahren geben können.
  5. nur (Blanko)Verordnungen erhalten, für die ich zuständig bin.
  6. , dass die Gültigkeit der QES des Arztes durch die Signatur des Fachdienstes bestätigt, im generierten PDF eingebettet und anschließend beim Kostenträger überprüft werden kann.

6.8 Korrekturprozesse

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.

6.8.1 Grundsätzliche Anforderungen, die an die Korrekturprozesse gestellt werden

Klarheit zu (Un-)Gültigkeit der (Blanko-)Verordnung bzw. Korrekturanfrage

  1. eine neu signierte Version einer (Blanko-)Verordnung ist immer die aktuell gültige Version
  2. eine neu signierte Version macht vorhergehende Versionen einer (Blanko-)Verordnung ungültig
  3. Die Versionen einer Verordnung müssen nachvollziehbar sein, d.h. sie sind immer dem ursprünglichen Vorgang zuzuordnen
  4. Die Korrekturanfrage wird automatisch ungültig, sobald eine neue Version der Verordnung ausgestellt oder die Anfrage abgelehnt wurde. 

Schnelle und enge Zusammenarbeit der Akteure wird ermöglicht

  1. Es kann beliebig viele Versionen einer Verordnung geben, aber nur die neueste Version ist gültig. 
  2. Es kann daher bei Bedarf mehr als eine Korrekturschleife durchlaufen werden. Die einzelnen Korrekturanfragen müssen immer auf der zuletzt gültigen bzw. aktuellen Version (VO oder VO-nV) aufbauen.

Transparenz für alle Akteure, sobald diese erstmalig in den Vorgang involviert werden

  1. Alle Versionen einer (Blanko)Verordnung können von dem Pflegedienst und dem Kostenträger eingesehen werden (sobald sie Zugriff gemäß Prozessbild haben).
  2. Alle Versionen einer (Blanko)Verordnung können immer vom Arzt und vom Versicherten eingesehen werden.
  3. Die Korrekturanfrage, die von einem Pflegedienst bei einem Arzt gestellt wird, kann zunächst nur vom Pflegedienst selbst, dem Versicherten und dem Arzt eingesehen werden. Der Kostenträger sieht Korrekturanfragen eines Pflegedienstes erst, nach dem ersten Zugriff auf den Vorgang (z. B. im Zuge der Leistungsentscheidung).
  4. Ablehnungen von Korrekturanfragen können immer vom Arzt oder dem Pflegedienst begründet werden. 

Inhaltliche Klarheit

  1. Änderungen von Stammdaten des Versicherten, des Arztes, der Praxis, des Kostenträgers oder des Pflegedienstes in einer neuen Version der (Blanko)Verordnung kann es nicht geben. 
  2. Korrekturanfragen beziehen sich daher beispielsweise auf die verordneten Leistungen, Leistungszeitraum oder die Angaben zu den Einschränkungen, die häusliche Krankenpflege notwendig machen.

Prozessuale Klarheit / Verantwortungsklarheit

  1. Der Empfänger einer Korrekturanfrage muss erkennen können, wer die Anfrage gestellt hat. 
  2. Es darf für die einzelne Verordnung nur eine aktive Korrekturanfrage geben. Diese muss zunächst durch den Arzt bzw. den Pflegedienst beantwortet werden, bevor eine erneute Korrekturanfrage gestellt werden kann. 
  3. Korrekturanfragen zur Verordnung dürfen vom Pflegedienst nur im Status "zugewiesen" ausgelöst werden.
  4. Korrekturanfragen zur Verordnung oder Blankoverordnung dürfen vom Kostenträger nur im Status "offen" oder "Antragsprüfung" ausgelöst werden.

Flexibilität für Leistungserbringer und Kostenträger

  1. In Einzelfällen können neue Versionen einer Verordnung auch von anderen Ärzten signiert werden als vom ursprünglich verordnenden Arzt. (Vertretung).
  2. Signieren neuer Versionen der (Blanko-)Verordnung ist leistungserbringerinstitutions- bzw. kostenträgerinstitutionsabhängig aber innerhalb der jeweiligen Organisation personenunabhängig. Einschränkung: kollegiale Vertretung im niedergelassenen Bereich erfordert, dass eine neue Verordnung statt einer neuen Version erstellt wird.

Einheitliche Behandlung der Datensätze und Versionen eines Vorgangs am Fachdienst

  1. Versionen werden nicht gelöscht, sondern liegen im Fachdienst, bis der gesamte Vorgang gelöscht wird.
  2. Der Gesamtvorgang mit allen zugehörigen Versionen der (Blanko)Verordnungen und erstellten Korrekturanfragen hat einen Status.

6.8.2 Besonderheiten beim Kostenerstattungsprinzip

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.

6.8.3 Benachrichtigungen über Änderungen innerhalb des Korrekturprozesses an verschiedene Akteure

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.

6.8.4 User Stories

Als Arzt möchte ich 

  1. nach der Ausstellung einer Verordnung die Möglichkeit haben, Fehler oder unvollständige Angaben selbst zu korrigieren, damit die Verordnung den medizinischen Anforderungen entspricht und korrekt ist.
  2. nachvollziehen können, ob eine Korrekturanfrage von einem Pflegedienst oder einem Kostenträger gestellt wurde, damit ich die Anfrage gezielt bearbeiten kann. Ich möchte erkennen können, welcher Pflegedienst bzw. welcher Kostenträger die Anfrage gestellt hat, damit ich im Zweifel über andere Kanäle Rücksprache halten kann.
  3. Korrekturanfragen von Pflegediensten oder Kostenträgern meinem PVS angezeigt bekommen, damit ich die notwendigen Änderungen vornehmen kann.
  4. die Möglichkeit haben, eine Korrekturanfrage abzulehnen und eine Begründung dafür anzugeben, um die ursprüngliche Verordnung beizubehalten und Rückfragen zu vermeiden.
  5. eine neue Version der Verordnung erstellen können, die entweder den Korrekturvorschlägen entspricht oder von diesen abweicht, um medizinische Entscheidungen flexibel treffen zu können.
  6. dass die neue, korrigierte Verordnung bzw. die Ablehnung einer Anfrage automatisch an den Anfragenden übermittelt wird, damit ich hier keine manuellen Aufwände habe.
  7. dass eine MFA in meiner Praxis die Anfragen ebenfalls einsehen und vollständig bearbeiten kann. 
  8. immer über neu eingetroffene Anfragen vom Pflegedienst oder Kostenträger in meinem PVS informiert werden, damit ich eine schnelle Rückmeldung geben kann. 
  9. im Einzelfall auch korrigierte Verordnungen von Kollegen aus meiner Praxis mit der Institutionskarte signieren können, wenn diese die neue Verordnung nicht selbst unterschreiben können (z. B. Urlaub, Wochenende), damit die Versorgung der Versicherten sichergestellt ist. 
  10. gelöschte bzw. zurückgezogene Korrekturanfragen von Pflegediensten oder Kostenträgern nicht angezeigt bekommen, sodass ich mir damit keine Arbeit mache.
  11. immer die originale und neuste Version des Verordnungsdatensatzes einsehen können.

Als Mitarbeiter einer Pflegeeinrichtung möchte ich ...

  1. eine Korrekturanfrage an den Arzt stellen können, wenn ich der Ansicht bin, dass die Verordnung unklare oder unvollständige Angaben enthält, damit die Versorgung des Patienten korrekt durchgeführt werden kann.
  2. in der Korrekturanfrage konkrete Vorschläge für Änderungen machen können, um den Arzt bei der Bearbeitung zu unterstützen.
  3. in der Korrekturanfrage Begründungen für meine vorgeschlagenen Änderungen senden können, um Rückfragen zu vermeiden.
  4. dass mein PPS die Anfrage automatisch an den richtigen Arzt bzw. seine Praxis sendet, damit ich keine manuellen Aufwände in der Auswahl des Adressaten habe.
  5. über Korrekturanfragen des Kostenträgers informiert werden, wenn diese sich auf eine von mir erstellte Blankoverordnung beziehen, damit ich die notwendigen Änderungen vornehmen kann, oder die Möglichkeit haben, eine Korrekturanfrage abzulehnen und eine Begründung dafür anzugeben.
  6. eine neue Version der Blankoverordnung erstellen können, die entweder den Vorschlägen des Kostenträgers entspricht oder von diesen abweicht, um die Versorgung weiterhin sicherzustellen
  7. automatisch Zugriff auf die neueste Version der Verordnung erhalten, sobald der Arzt eine Korrektur vorgenommen hat, damit ich die Versorgung auf Basis der aktuellen Verordnung durchführen kann.
  8. einen Hinweis bei Änderungen im Datensatz durch Korrekturen erhalten, die vom Kostenträger beim Arzt angeregt wurden, mindestens dann, wenn sich Art und/oder Umfang verändert haben.
  9. gelöschte bzw. zurückgezogene Korrekturanfragen von Kostenträgern nicht angezeigt bekommen, sodass ich mir damit keine Arbeit mache.
  10. Korrekturanfragen bei Ärzten zurückziehen oder aktualisieren können, wenn sich der Bedarf geändert hat oder ich innerhalb der Frist den Vorgang zur Leistungsentscheidung einreichen möchte.
  11. immer die originale und neuste Version des Verordnungsdatensatzes einsehen können. 

Als MA eines Kostenträgers möchte ich ...

  1. eine Korrekturanfrage an den Arzt stellen können, wenn ich der Ansicht bin, dass die Verordnung fehlerhaft ist, um die Leistungsentscheidung korrekt prüfen zu können.
  2. eine Korrekturanfrage an den Pflegedienst stellen können, wenn ich der Ansicht bin, dass eine Blankoverordnung fehlerhaft ist, damit der Pflegedienst die notwendigen Änderungen vornehmen kann.
  3. Zugriff auf die neue Version der Blankoverordnung erhalten, sobald der Pflegedienst diese erstellt hat, um die Leistungsentscheidung erneut prüfen zu können.
  4. immer die originale und neuste Version des (Blanko-)Verordnungsdatensatzes einsehen können, um die Historie der Änderungen nachvollziehen zu können.
  5. Korrekturanfragen bei Ärzten oder Pflegediensten zurückziehen oder aktualisieren können, wenn sich der Bedarf geändert hat.  

Als Versicherter möchte ich ...

  1. über Änderungen an meiner Verordnung informiert werden, wenn diese durch den Arzt, den Pflegedienst oder den Kostenträger vorgenommen wurden, damit ich den aktuellen Stand nachvollziehen kann.
  2. nachvollziehen können, welche Version der Verordnung aktuell gültig ist, um sicherzustellen, dass meine Versorgung korrekt erfolgt.
  3. die Möglichkeit haben, den Arzt auf Anpassungsbedarf in der Verordnung hinzuweisen, solange diese noch nicht von einem Pflegedienst eingelöst worden ist, um sicherzustellen, dass die Verordnung meinen Bedürfnissen entspricht.
  4. erfahren, ob eine Korrekturanfrage vom Kostenträger oder dem Pflegedienst gestellt wurde, um den Grund für Änderungen zu verstehen.

6.9 Unzuständigkeit der Krankenkasse (nur GKV und DGUV)

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.

6.9.1 User Stories

Als MA eines Kostenträgers möchte ich ...

  1. , dass nur Verordnungen bei mir ankommen können, für die ich zuständig bin (bspw. anhand IK, TID), um unnötige Rücksprachen und Unzuständigkeit zu vermeiden. 
  2. den Vorgang elektronisch an den zuständigen Träger (andere Kostenträger, Sozialleistungsträger) weitergeben.

Als Versicherter möchte ich ...

  1. wissen, wie es weitergeht, wenn meine Verordnung aufgrund der Angabe eines falschen Kostenträgers nicht genehmigt oder beliefert werden kann.

6.10 Leistungsnachweise

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. 

6.11 Leistungserbringerwechsel

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

6.12 Abrechnungsverfahren

6.12.1 Abrechnung von Verordnungen für Versicherte mit einem Kostenträger nach dem Sachleistungsprinzip

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.

6.12.2 Abrechnung von Verordnungen für Versicherte mit einem Kostenträger nach dem Kostenerstattungsprinzip

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.

7 Fachliches Statusmodell

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

7.1 Erläuterungen zum Statusmodell

7.1.1 Status 'initialisiert'

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.

7.1.2 Status 'offen'

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 Statu"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.

7.1.3 Status 'zugewiesen'

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. 

7.1.4 Status 'Antragsprüfung'

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.

7.1.5 Status 'Korrekturanfrage'

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.

7.1.6 Status 'zugewiesen (beschieden)'

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":
  • Die Verordnung kann nicht mehr von einem weiteren Pflegedienst abgerufen werden. Die Verordnung ist einem Pflegedienst zugeordnet, d.h. ein eindeutiges Merkmal (Telematik-ID) des Pflegedienstes ist der Verordnung am Fachdienst zugeordnet.
  • vom Versicherten kann mit Bereitstellung der Zugriffsinformationen dem Kostenträger ein Zugriff ermöglicht werden zwecks Beratung zur Verordnung / Leistungserbringerauswahl / Leistungserbringerwechsel. Dies ändert den Status nicht.
  • Die Verordnung kann vom Pflegedienst nicht zurück in den Status "offen" gestellt werden, sofern die Versorgung des Versicherten nicht übernommen wird.
Nicht relevant für PKV. 
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.

7.1.7 Status 'abgeschlossen'

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.

7.1.8 Status 'gelöscht'

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

8 Datensätze

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.

9 Gültigkeiten und Löschregeln

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.

10 Handlungsbedarf für den Gesetzgeber

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:
  • gesetzliche Krankenkassen
  • gesetzliche Unfallversicherung
  • Beihilfe
  • Kostenträger der Versicherten gemäß §362 Abs. 1 SGB V
    • sonstige heilfürsorgeberechtigte Beamte (z. B. Bundespolizei)
    • Unternehmen der privaten Krankenversicherung 
    • Postbeamtenkrankenkasse (derzeit noch nicht mit gematik im Dialog)
    • Krankenversorgung der Bundesbahnbeamten (derzeit noch nicht mit gematik im Dialog)
    • Polizeivollzugsbeamte (derzeit noch nicht mit gematik im Dialog)
    • Soldaten der Bundeswehr (derzeit noch nicht mit gematik im Dialog)
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:
  • Häuslicher Krankenpflege
  • Außerklinischer Intensivpflege
  • Soziotherapie 
nicht berücksichtigt.
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:
  • Kostenträger für sonstige heilfürsorgeberechtigte Beamte (z. B. Bundespolizei)
  • Postbeamtenkrankenkasse
  • der Krankenversorgung der Bundesbahnbeamten 
  • Polizeivollzugsbeamte 
  • Soldaten der Bundeswehr 
Vereinfachend sollen die Kostenträger der Versicherten gemäß SGB V §362 Abs. 1 genannt werden, somit kann die explizite Nennung der "Unternehmen der privaten Krankenversicherung" entfallen.
Ausgeschlossen sind, weil keine eigene App zum Einlösen von E-Rezepten/Verordnungen vorhanden ist:
  • Gesetzliche Unfallversicherung (wird über das FdV der gesetzlichen Kasse dargestellt)
  • Beihilfe (wird über die App der privaten Krankenversicherung dargestellt)
[§ 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:
  • Angaben zur Leistungserbringung des PD
  • Entscheidungsdatensatz
SGB V §360 Abs. 11 könnte wie folgt gefasst werden:

"Mit Ablauf von 100 Tagen sind:
  1. nach Dispensierung Verordnungsdaten und Dispensierinformationen nach den Absätzen 2 bis 4 
  2. nach Ende des gewählten Verordnungszeitraums die Verordnungsdaten, Angaben zur Leistungserbringung des Pflegedienstes und Entscheidungsdaten der Krankenkassen für Verordnungen nach Abs. 5 Satz 1
zu löschen."

11 Technisches Konzept (MVP)

Dieses Kapitel beschreibt das technische Konzept für Umsetzung der Funktionalität für die Ausbaustufe Minimal Viable Product (Version 1).

11.1 Systemüberblick

Die Einführung der elektronischen Verordnung für HKP setzt auf die bestehende Infrastruktur der Anwendung E-Rezept auf. 

Abbildung 6 : Systemüberblick HKP

11.2 Nutzergruppen

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.

11.3 Workflow

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.

11.3.1 Workflow für die HKP Verordnung

11.3.1.1 Technisches Statusmodell

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.

11.3.1.2 Fachliches Business-Statusmodell

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.

11.3.1.3 Statusübergänge

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.

11.3.2 Anfrage-Workflow

11.3.2.1 Konzept Anfrage-Workflow

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.

11.3.2.1.1 Rollen

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.


11.3.2.1.2 Initialisierung eines Anfrage-Workflows

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.

11.3.2.1.3 Technisches Statusmodell

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.

11.3.2.1.4 Fachliches Datenmodell

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.

11.3.2.1.5 Zugriffsberechtigung Anfrage-Workflow

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.

11.3.2.1.6 Speicherdauer des Anfrage-Workflows

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.

11.3.2.1.7 Ablauf und Prozess

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

11.3.2.1.7.1 Verfügbare Anfragebögen abrufen

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) ] )
11.3.2.1.7.2 Anfrage starten

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.

11.3.2.1.7.3 Anfrage abbrechen

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
11.3.2.1.7.4 Anfrageinformationen abrufen

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.

11.3.2.1.7.5 Anfrage zur Bearbeitung abrufen

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.

11.3.2.1.7.6 Anfrage freigeben

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.

11.3.2.1.7.7 Anfrage abschließen

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
  • responseString 0..1
  • document: FHIR-Document 0..1
C: wenn kein Dokument vorliegt muss ein Grund angegeben werden
Response Anfrage-Task

offener Punkt: wie kann der Bearbeiter dem Anfragenden zusätzliche Informationen bereitstellen? Freitext, kodiert?

11.3.2.1.7.8 Anfrage ablehnen

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


11.3.2.2 Datenmodelle des Anfrage-Workflow

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.

11.3.2.2.1 FHIR-Questionnaire Ansastz

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

11.3.2.2.2 FHIR-Questionnaire Erweiterung

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:

  1. Im Questionnaire-Profil definiert der Verantwortliche des E-Rezept-Fachdienstes technische Erweiterungen, hinter denen konkrete Geschäftslogik im Fachdienst hinterlegt ist, bspw. die Manipulation eines FHIR-Documents.
  2. Das daraus abgeleitete konkrete Questionnaire legt fest, welche dieser Erweiterungen für ein bestimmtes Fachdokument genutzt werden und wohin die Werte geschrieben werden.
  3. Die QuestionnaireResponse liefert die konkreten Inhalte und löst beim Abruf des Anfragedokuments die Ausführung der hinterlegten Operation aus.

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.

11.3.2.2.3 Veranschaulichung am Beispiel "Korrektur eines FHIR-Documents"

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.

11.3.2.2.3.1 Die drei Operationstypen

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.

11.3.2.2.3.2 Ausführung durch den Fachdienst

Der E-Rezept-Fachdienst führt zwei getrennte Schritte aus:

  1. Beim Einstellen der Anfrage validiert der Fachdienst die eingehende QuestionnaireResponse strukturell gegen das zugehörige Questionnaire (korrekte linkIds, passende Datentypen) und speichert sie erst danach.
  2. Beim Abruf des Anfragedokuments durch den Bearbeitenden lädt der Fachdienst Questionnaire-Profil, Questionnaire und QuestionnaireResponse, erstellt eine Kopie des Fachdokuments (das Anfragedokument) und wendet für jede beantwortete linkId die im Profil hinterlegte Geschäftslogik auf dieser Kopie an. Ausgegeben wird ausschließlich das vollständige Anfragedokument – nicht die einzelnen Änderungsschritte.

Der Bearbeitende erhält auf diesem Weg den Korrekturvorschlag als vollständiges, lesbares Dokument und muss die einzelnen Änderungsoperationen nicht selbst nachvollziehen.

11.3.2.2.3.3 Beispiel: "Startdatum einer Verordnung anpassen"

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.

11.3.2.2.4 Zusammenfassung FHIR-Questionnaire für Anfrage-Workflows

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.

11.3.3 HKP-spezifische Anfrage-Workflows

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.

11.3.3.1 HKP Antragsprüfung durch Versicherten bei Kostenerstattung nach §37 Abs. 4 SGB V oder persönlichem Budget

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.

11.3.3.2 HKP Antragsprüfung durch Pflegedienst

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
11.3.3.3 HKP Korrektur-Anfrage einer Pflegedienst an den Verordnenden

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

11.3.3.4 HKP Korrektur-Anfrage eines Kostenträgers an den Verordnenden

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
11.3.3.5 HKP Korrektur-Anfrage eines Kostenträgers an den Pflegedienst

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

11.4 Datenmodelle

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

11.5 Verwendung von Dokumenten

11.5.1 Konzept zur Verwendung von Dokumenten

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.

11.5.1.1 Serverseitige Metadatengenerierung

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.

11.5.1.2 Dokumentenpublikation

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
11.5.1.3 Referenzierung von Dokumenten aus der ePA

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.

11.5.1.4 Ablage und Referenzierung von Dokumenten

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.

11.5.1.5 Anforderungen an die Dokumente
11.5.1.5.1 Unterstützte Dokumentenformate

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.

11.5.1.5.2 Begrenzung der Dokumentengröße

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.

11.5.1.6 Versionierung von Dokumenten

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.

11.5.1.7 Workflowbezogener Dokumentenabruf

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
11.5.1.7.1 Abruf historischer Dokumentversionen

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

11.5.1.7.2 Abruf einzelner Dokumente

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.

11.5.1.8 Lebenszyklus der Dokumente

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.

11.5.2 Verwendung von Dokumenten im HKP Workflow

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.

11.5.2.1 Führende Workflowdokumente

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.

11.5.2.2 Workflowbegleitende Dokumente

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.

11.5.2.3 Signaturanforderungen

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.

11.5.2.4 Dokumente im HKP-Workflow

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.

11.5.2.5 Speicherung workflowrelevanter Dokumente

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.

11.6 Prozessparameter

11.6.1 Gültigkeit einer HKP-Verordnung

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.

11.6.2 Löschfristen

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.

11.7 Kommunikation der Prozessbeteiligten

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.

11.8 Notifications

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.

11.9 Übermittlung von Daten in die ePA

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.

11.10 Umsetzung fachlicher Szenarien

11.10.1 Einlösewege

11.10.1.1 Verbindliches Einlösen bei einem Pflegedienst

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. 

11.10.1.2 Unverbindliche Anfrage bei Pflegediensten via FdV

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.

11.10.2 Verordnungen zu Lasten einer gesetzlichen Krankenkasse

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.

11.10.3 Verordnungen zu Lasten einer privaten Krankenversicherung

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.

11.10.4 Verordnungen zu Lasten eines Unfallversicherungsträgers

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.

11.11 Use Cases

11.11.1 Use Cases des Verordnenden

In diesem Kapitel werden die technischen Anwendungsfälle der Nutzergruppen beschrieben.

11.11.1.1 HKP Verordnung erstellen

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
  • Die Daten zum Versicherten sind im PS bekannt.
  • Ein Verordnungsdatensatz liegt im Primärsystem vor.
  • für QES: HBA ist gesteckt und freigeschaltet.
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
  • Der signierte Verordnungsdatensatz liegt im PS vor.
  • AccessCode_state des Workflows ist im PS gespeichert.
  • Workflow zur Verordnung ist im E-Rezept-Fachdienst im Business-Status "initialized" (technischer Status "draft") angelegt.

[<=]

11.11.1.2 HKP Verordnung durch Verordnenden einstellen

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
  • Der Anwendungsfall "UC 2.1 - Verordnung erzeugen" wurde ausgeführt.
  • Ein signierter Verordnungsdatensatz liegt im Primärsystem vor.
  • Die Verordnungs-ID und der AccessCode_state sind im Primärsystem bekannt.
  • Der Workflow zur Verordnung im E-Rezept-Fachdienst hat den Status "initialized" ("draft").
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
  • Die Verordnung ist im E-Rezept-Fachdienst gespeichert und hat den Status "open" ("ready").
  • Das Einstellen der Verordnung ist im E-Rezept-Fachdienst für den Versicherten protokolliert.

[<=]

11.11.1.3 HKP Verordnung durch Verordnenden abrufen

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
  • Der Verordnungstoken liegt im Primärsystem vor.
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
  • Das Lesen der Verordnung ist im E-Rezept-Fachdienst für den Versicherten protokolliert.
  • Die Informationen zur Verordnung stehen zur Weiterverarbeitung im Primärsystem bereit.

[<=]


11.11.1.4 HKP Verordnung durch Verordnenden löschen

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
  • Ein Mitarbeiter der medizinischen Institution hat den Anwendungsfall "UC 2.3 - Verordnung einstellen" ausgeführt.
  • Die Verordnungs-ID und der AccessCode_state sind im Primärsystem bekannt.
  • Der Workflow zur Verordnung im E-Rezept-Fachdienst hat den Status "initialized" ("draft") oder "open" ("ready").
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
  • Die Verordnung im E-Rezept-Fachdienst hat den Status "deleted" ("cancelled"). Sie beinhaltet keine personenbezogenen oder medizinischen Daten. 
  • Das Löschen der Verordnung ist im E-Rezept-Fachdienst für den Versicherten protokolliert.

[<=]

11.11.2 Use Cases des Versicherten

11.11.2.1 HKP Verordnungen durch Versicherten abrufen

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
  • keine
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
  • Im FdV stehen die Verordnungen zur Anzeige sowie die Daten für das Erstellen eines Verordnungstokens bereit.
  • Der Abruf ist im E-Rezept-Fachdienst für den Versicherten protokolliert.

[<=]

11.11.2.2 HKP Verordnung durch Versicherten löschen

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
  • Der Versicherte hat den Anwendungsfall "UC 3.1 - Verordnungen durch Versicherten abrufen" ausgeführt.
  • Der Workflow zur Verordnung hat den Status "ready" oder "completed"
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
  • Der Workflow zur Verordnung im E-Rezept-Fachdienst hat den Status "cancelled". Er beinhaltet keine personenbezogenen oder medizinischen Daten (ausser Versicherten-ID). 
  • Das Löschen der Verordnung ist im E-Rezept-Fachdienst für den Versicherten protokolliert. 

[<=]

11.11.2.3 Nachrichten durch Versicherten empfangen

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
  • Ein Mitarbeiter des Pflegedienstes hat den Anwendungsfall "UC 4.7 - Nachricht durch Abgebenden übermitteln" ausgeführt.
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
  • Die Nachrichten liegen im FdV zur Anzeige bereit.

[<=]

11.11.2.4 Nachricht durch Versicherten versenden

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
  • Der Versicherte hat den Anwendungsfall "UC 3.1 - Verordnungen durch Versicherten abrufen" ausgeführt. Das FdV hat einen Verordnungstoken erstellt.
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
  • Die Nachricht mit dem Verordnungstoken liegt im E-Rezept-Fachdienst und kann vom Empfänger asynchron empfangen werden. Im Falle der Alternative kann der Empfänger den 2D-Code abscannen.

[<=]

11.11.2.5 Nachricht durch Versicherten löschen

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
  • Ein Versicherter hat den Anwendungsfall "UC 3.3 - Nachricht durch Versicherten übermitteln" ausgeführt.
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
  • Die Nachricht ist auf dem E-Rezept-Fachdienst und im FdV gelöscht und kann vom Empfänger nicht mehr abgerufen werden.

[<=]

11.11.3 Use Cases des Pflegedienstes

11.11.3.1 HKP Verordnungen durch Pflegedienst abrufen (PoPP)

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
  • Der Versicherte oder ein Vertreter befindet sich vor Ort im Kontakt mit einem Mitarbeiter des Pflegedienstes.
  • Der Versicherte hat seine eGK bzw. der Vertreter die eGK des zu Vertretenden dabei
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
  • Im Primärsystem stehen die Informationen für alle einlösbaren Verordnungen zur Anzeige bereit.
  • Der Zugriff des Pflegedienstes auf die Verordnungen ist auf dem E-Rezept-Fachdienst für den Versicherten protokolliert.

[<=]

11.11.3.2 HKP Verordnung durch Pflegedienst unverbindlich einsehen

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
  • Ein Versicherter hat über das FdV eine Anfrage an den Pflegedienst gesendet
    alternativ: Ein Versicherter hat dem Pflegedienst einen Verordnungstoken übermittelt.
  • Die Zugriffsinformationen zur Verordnung liegen im Primärsystem vor.
  • Die Verordnung im E-Rezept-Fachdienst hat den Status "ready".
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
  • Das Lesen der Verordnung ist im E-Rezept-Fachdienst für den Versicherten protokolliert.
  • Die Verordnung steht zur Anzeige im Primärsystem bereit.

[<=]

11.11.3.3 HKP Verordnung durch Pflegedienst verbindlich abrufen

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
  • Ein Versicherter oder ein Vertreter hat dem Pflegedienst einen Verordnungstoken übermittelt.
  • Der Verordnungstoken liegt im Primärsystem vor.
  • Die Verordnung im E-Rezept-Fachdienst hat den Status "ready".
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
  • Die Verordnung hat im E-Rezept-Fachdienst den Status "in-progress" und den Business-Status "assigned".
  • Der verbindliche Abruf ist im E-Rezept-Fachdienst für den Versicherten protokolliert.
  • Die Verordnung steht zur Anzeige im Primärsystem bereit.
  • Das Geheimnis zur Statusänderung "in-progress" ist im Primärsystem gespeichert.

[<=]

11.11.3.4 HKP Verordnung durch Pflegedienst zurückgeben

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
  • Ein Mitarbeiter des Pflegedienstes hat den Anwendungsfall "UC 6.1 - Verordnung durch Pflegedienst zum Zuweisen abrufen" durchgeführt.
  • Die Verordnungs-ID, der AccessCode_state und das Geheimnis zur Statusänderung "in-progress" sind im Primärsystem bekannt.
  • Die Verordnung im E-Rezept-Fachdienst hat den Status "in-progress".
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
  • Die Verordnung im E-Rezept-Fachdienst hat den Status "ready".  
  • Der Statuswechsel der Verordnung zum Status "ready" ist im E-Rezept-Fachdienst für den Versicherten protokolliert. 
  • Die Verordnung, der Verordnungstoken und das Geheimnis zur Statusänderung "in-progress" sind im Primärsystem gelöscht.

[<=]

11.11.3.5 Nachrichten durch Pflegedienst empfangen

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
  • Ein Versicherter hat den Anwendungsfall "UC 3.3 - Nachricht durch Versicherten übermitteln" ausgeführt.
Alternativ kann ein Versicherter persönlich in dem Pflegedienst den 2D-Code des Verordnungstokens ausgedruckt oder als Anzeige in einem mobilen Gerät dem Abgebenden präsentieren.
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
  • Der Verordnungstoken liegt im Primärsystem des Pflegedienstes vor.

[<=]

11.11.3.6 Nachricht durch Pflegedienst versenden

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
  • Ein Versicherter hat den Anwendungsfall "UC 3.3 - Nachricht durch Versicherten übermitteln" ausgeführt.
  • Ein Mitarbeiter des Pflegedienstes hat den Anwendungsfall "UC 6.6 - Nachrichten durch Pflegedienst empfangen" durchgeführt.
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
  • Der Nachricht liegt im E-Rezept-Fachdienst und kann vom Versicherten asynchron empfangen werden.

[<=]

11.11.3.7 Nachricht durch Pflegedienst löschen

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
  • Ein Pflegedienst hat den Anwendungsfall "UC 6.7 - Nachricht durch Pflegedienst versenden" ausgeführt.
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
  • Die Nachrichten sind auf dem E-Rezept-Fachdienst und im FdV gelöscht.

[<=]

11.11.4 Use Cases des Kostenträgers

11.11.4.1 HKP Verordnung durch Kostenträger abrufen

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
  • Ein Versicherter, ein Pflegedienst oder der Fachdienst hat dem Kostenträger einen Verordnungstoken übermittelt.
  • Alternativ: Der Versicherte hat dem Kostenträger telefonisch die Verordnungs-ID und den Telefon-Code vem Patientenausdruck übermittelt.
  • Der Verordnungstoken oder der Telefon-Code aus dem Patientenausdruck liegt im Kostenträgerverwaltungssystem.
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
  • Das Lesen der Verordnung ist im E-Rezept-Fachdienst für den Versicherten protokolliert.
  • Die Verordnung steht zur Weiterverarbeitung im Kostenträgerverwaltungssystem bereit.

[<=]

11.11.4.2 Nachrichten durch Kostenträger empfangen

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
  • Ein Versicherter hat den Anwendungsfall "UC 3.3 - Nachricht durch Versicherten übermitteln" ausgeführt.
  • Das Kostenträgerverwaltungssystem hat sich am E-Rezept-Fachdienst für Subscription registiert.
Alternativ kann ein Versicherter persönlich beim Kostenträger:
  • den 2D-Code des Verordnungstokens ausgedruckt oder
  • den 2D-Code als Anzeige auf einem mobilen Gerät dem Mitarbeiter des Kostenträgers präsentieren oder 
  • das auf dangegebene Geheimnis telefonisch mitteilen.
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
  • Der Verordnungstoken liegt im Kostenträgerverwaltungssystem vor.

[<=]

11.11.5 Use Cases zum Anfrage-Workflow

11.11.5.1 HKP Anfrage-Workflow starten

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
  • Der Verordnungstoken liegt im Clientsystem vor.
  • Die Verordnung im E-Rezept-Fachdienst hat den Status "on-hold".
  • Die passende QuestionnaireResponse ist vorhanden.
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
  • Der Anfragetask im E-Rezept-Fachdienst hat den Status "requested".
  • Der der Anfrage zugrundeliegende Workflow hat den Status "on-hold".
  • Der Start der Anfrage ist im E-Rezept-Fachdienst für den Versicherten protokolliert.
  • Der erstellte Anfragetask ist im Clientsystem vorhanden.

[<=]

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.

11.11.5.2 HKP Anfrage-Workflow zurückziehen

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
  • Der Prozessbeteiligte hat den Anwendungsfall "UC x.30 - Anfrage-Workflow starten" ausgeführt.
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 Anfragetask im E-Rezept-Fachdienst hat den Status "cancelled".  
  • Der Abbruch der Anfrage ist im E-Rezept-Fachdienst für den Versicherten protokolliert..
  • Der dem Anfragetask zugrunde liegende Workflow im E-Rezept-Fachdienst hat wieder den vorherigen fachlichen und technischen Status.

[<=]

Der Versicherte führt "UC 5.1 - AuthN-Token durch Versicherten anfordern" aus, sofern kein gültiger AuthN-Token vorhanden ist.

11.11.5.3 Alle HKP Anfrage-Workflows abrufen

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
  • Keine
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
  • Der Abruf der Liste ist im E-Rezept-Fachdienst für den Versicherten protokolliert.
  • Das Clientsystem hat eine Liste der Anfrage-Workflows erhalten.

[<=]

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.

11.11.5.4 Ein HKP Anfrage-Workflows abrufen

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
  • Keine
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
  • Der Abruf der Anfrage ist im E-Rezept-Fachdienst für den Versicherten protokolliert.
  • Das Clientsystem hat die Anfrageinformationen erhalten.

[<=]

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.

11.11.5.5 HKP Anfrage-Workflow zum Bearbeiten abrufen

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
  • Der Prozessbeteiligte ist im Anfragetask als Bearbeiter zugewiesen.
  • Der Anfragetask hat den Status "requested".
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
  • Der Anfragetask im E-Rezept-Fachdienst hat den Status "in-progress".  
  • Der E-Rezept-Fachdienst protokolliert den Statuswechsel für den Versicherten.
  • Der Anfragetask steht im Clientsystem zur Anzeige bereit.

[<=]

11.11.5.6 HKP Anfrage-Workflow abschließen

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
  • Der Prozessbeteiligte ist im Anfragetask als Bearbeiter zugewiesen.
  • Der Prozessbeteiligte hat den Anwendungsfall "UC x.34 - Anfrage-Workflow zur Bearbeitung abrufen" durchgeführt.
  • Der Anfragetask hat den Status "in-progress".
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
  • Der Anfragetask im E-Rezept-Fachdienst hat den Status "completed".
  • Der Workflow, der dem Anfragetask zugrunde liegt, hat wieder den vorherigen technischen Status und den nächsten fachlichen Status. 
  • Der E-Rezept-Fachdienst protokolliert den Statuswechsel für den Versicherten.
  • Der aktualisierte Anfragetask steht im Clientsystem bereit.

[<=]

11.11.5.7 HKP Anfrage-Workflow ablehnen

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
  • Der Prozessbeteiligte ist im Anfragetask als Bearbeiter zugewiesen.
  • Der Prozessbeteiligte hat den Anwendungsfall "UC x.34 - Anfrage-Workflow zur Bearbeitung abrufen" durchgeführt.
  • Der Anfragetask hat den Status "in-progress".
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
  • Der Anfragetask im E-Rezept-Fachdienst hat den Status "rejected".
  • Die dem Anfragetask zugrunde liegende Verordnung im E-Rezept-Fachdienst hat wieder den vorherigen fachlichen und technischen Status.
  • Der E-Rezept-Fachdienst protokolliert den Statuswechsel für den Versicherten.
  • Der aktualisierte Anfragetask steht im Clientsystem bereit.

[<=]

11.11.6 Use Cases zum Dokumentenmanagement

11.11.6.1 Workflow-begleitendes Dokument einstellen

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
  • Der Verordnungstoken liegt im Clientsystem vor.
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
  • Der E-Rezept-Fachdienst protokolliert das Hinzufügen des Dokuments für den Versicherten.
  • Die aktualisierte Verordnung steht im Clientsystem bereit.

[<=]

11.11.6.2 Alle Dokumente zu einem Task abrufen

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
  • Der Verordnungstoken liegt im Clientsystem vor.
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
  • Der E-Rezept-Fachdienst protokolliert den Abruf der Dokumente für den Versicherten.
  • Die Bundle mit den DocumentReferences steht im Clientsystem bereit.

[<=]

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.

11.11.6.3 Ein Dokument abrufen

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
  • Der Verordnungstoken liegt im Clientsystem vor.
  • Die Dokument-ID des Dokuments liegt im Clientsystem vor.
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
  • Der E-Rezept-Fachdienst protokolliert den Abruf des Dokuments für den Versicherten.
  • Die Metadaten des Dokuments und/oder das Dokument stehen im Clientsystem bereit.

[<=]

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.

12 Datenschutz und Informationssicherheit

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.

13 Anhang A – Verzeichnisse

13.1 Abkürzungen

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

13.2 Abbildungsverzeichnis

13.3 Tabellenverzeichnis

13.4 Referenzierte Dokumente

13.4.1 Dokumente der gematik

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

13.4.2 Weitere Dokumente

[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/ 

14 Anhang

14.1 Fachlicher Soll-Prozess

Abbildung 12: Fachlicher Soll-Prozess der elektronischen Verordnung von häuslicher Krankenpflege

14.2 Demonstratoren

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"
  • Der Arzt stellt (Blanko-)Verordnung für Renate aus
  • Daniel vom PD Hand & Herz löst die Verordnung mit der eGK im PPV ein 
  • Elena vom PD Hand & Herz sieht die Verordnung in dem PPS ein, und ergänzt eigene Angaben und leitet die Verordnung weiter an Kasse
  • Die Kasse sieht die Verordnung und die Angaben des Pflegedienstes ein
  • Die Kasse genehmigt alle Leistungen
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 

14.3 MVP - Release 1.0

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.

14.3.1 Beteiligte Akteure

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

14.3.2 Funktionen / Anwendungsfälle

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