Elektronische Gesundheitskarte und Telematikinfrastruktur

Feature:

Verordnung von Digitalen Gesundheitsanwendungen

    

     

      
Version
      
1.0.0_CC
     
     

      
Revision
      
932627
     
     

      
Stand
      
17.06.2024
     
     

      
Status
      
zur Abstimmung freigegeben
     
     

      
Klassifizierung
      
öffentlich_Entwurf
     
     

      
Referenzierung
      
gemF_eRp_DiGA
     
    

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

Dieses Dokument beschreibt das Feature zur Übermittlung von Verordnungen für Digitale Gesundheitsanwendungen (DiGA). Das Feature umfasst die Definition der Prozessparameter und Ergänzungen der workflowspezifischen Anforderungen an die Schnittstellen des E-Rezept-Fachdienstes sowie die Darstellung der Use Cases für verordnende Leistungserbringer, Kostenträger und Versicherte.

1.1 Zielsetzung

Die Beschreibung des Funktionsumfangs als Feature erleichtert das Verständnis und die Nachvollziehbarkeit der Lösung, ausgehend von der Darstellung der Nutzersicht auf Epic-Ebene, über das technische Konzept bis zur Spezifikation der technischen Details. Mit den hier aufgestellten Anforderungen sollen Hersteller in der Lage sein, den zusätzlichen Funktionsumfang ihrer verantworteten Komponente bzw. Produkttyp bewerten und umsetzen zu können. 

1.2 Zielgruppe

Das Dokument richtet sich an den Hersteller und Anbieter des Produkttyps E-Rezept-Fachdienst sowie Hersteller von Clientsystemen für den Zugriff auf den E-Rezept-Fachdienst.

1.3 Abgrenzungen

Die Festlegungen zum E-Rezept der bisher spezifizierten Workflows für apothekenpflichtige Arzneimittel sind nicht Gegenstand dieses Dokuments. Auch sollen die Ausführungen dieses Dokuments nicht im Widerspruch zu den bisherigen Festlegungen verstanden werden.

Folgende Aspekte sind nicht Gegenstand dieses Featuredokumentes:

• Die Option der Beantragung einer DiGA durch gesetzlich Versicherte direkt bei einer Krankenkasse ohne vorliegende ärztliche oder psychotherapeutische Verordnung.
• Privatversicherte und Versicherte sonstiger Kostenträger werden nicht betrachtet.
• Bestehende Schnittstellen zwischen DiGA Herstellern und Krankenkassen zwecks Abrechnung von Freischaltcodes werden nachgenutzt und sind daher unabhängig dieses Dokumentes.

1.4 Methodik

E-Rezept (E-Verordnung)

Das Dokument beschreibt das Feature zur Übermittlung von Verordnungen für DiGAs. Hierbei werden viele technische Konzepte der Übermittlung von ärztlichen und zahnärztlichen Verordnungen für apothekenpflichtige Arzneimittel wiederverwendet. Um eine doppelte Spezifikation zu vermeiden, wird im Zusammenhang von Verordnungen von DiGAs für eine Verordnung mit QES der Begriff E-Rezept verwendet.

Rolle Verordnender (Arzt/Zahnarzt/Psychotherapeut)

Wenn im Dokument der Arzt in der Rolle Verordnender benannt wird, dann umfasst diese sowohl die Ärzte, Zahnärzte als auch Psychotherapeuten, sofern Zahnärzte  und Psychotherapeuten nicht explizit ausgeschlossen werden.

Wenn im Dokument Psychotherapeuten benannt werden, dann umfasst diese Bezeichnung Psychotherapeuten, psychologische Psychotherapeuten sowie Kinder- und Jugendpsychotherapeuten.

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. [Wikepedia: 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.

Anforderungen / Anwendungsfälle

Anforderungen und Anwendungsfälle als Ausdruck normativer Festlegungen werden durch eine eindeutige ID sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Anforderungen und Anwendungsfälle werden im Dokument wie folgt dargestellt:
<ID> - <Titel der Anforderung / Titel des Anwendungsfalles>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung/der Anwendungsfall sämtliche zwischen ID und Textmarke [<=] angeführten Inhalte.

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 Epic und User Story

Durch das Digitale Versorgungsgesetz wurde ermöglicht, "digitale Gesundheitsanwendungen" (DiGAs) ärztlich zu verordnen.

Beschreibung DiGA: (Quelle: https://www.bundesgesundheitsministerium.de/themen/krankenversicherung/online-ratgeber-krankenversicherung/arznei-heil-und-hilfsmittel/digitale-gesundheitsanwendungen):

DiGA – auch Apps auf Rezept genannt - sind digitale CE-gekennzeichnete Medizinprodukte niedriger Risikoklassen, die die Versicherten etwa bei der Behandlung von Erkrankungen oder dem Ausgleich von Beeinträchtigungen unterstützen können. Anwendungsfelder wie Diabetologie, Kardiologie, Logopädie, Psychotherapie oder Physiotherapie vermitteln nur einen kleinen Überblick über die Vielzahl der Einsatzgebiete. Eine häufige Form sind Gesundheits-Apps für das Smartphone, aber es gibt auch browserbasierte Webanwendungen oder Software zur Verwendung auf klassischen Desktop-Rechnern. [...] Voraussetzung ist, dass die Anwendungen zuvor eine Prüfung auf Anforderungen wie Sicherheit, Funktionstauglichkeit, Datenschutz und Daten­sicherheit beim BfArM durchlaufen haben. [...] Um Leistungserbringende und Versicherte über gute und sichere digitale Gesundheitsinformationen informieren zu können, wurde beim BfArM ein Verzeichnis für DiGA eingerichtet (https://diga.bfarm.de/de). Es enthält neben der Aufzählung erstattungsfähiger DiGA eine Vielzahl weitergehender Informationen für die Versicherten und Leistungserbringenden.

Beschreibung des Verordnungsvorgangs: (Quelle: https://www.kbv.de/html/diga.php)

Ärzte und Psychotherapeuten können bislang ein Rezept auf Muster 16 für eine DiGA ausstellen. Zu jeder gelisteten DiGA stellt das BfArM im Verzeichnis Informationen bereit, die verordnungsrelevant sind. Diese Informationen stehen den Praxisverwaltungssystemen (PVS) bereit: 

• Im DiGA-Verzeichnis steht zu jeder DiGA unter „Informationen für Fachkreise“ eine eindeutige PZN.
• Kann eine DiGA für unterschiedliche Indikationen mit jeweils unterschiedlichen Inhalten angewendet werden, ist jeder Indikation eine eigene PZN zugeordnet.
• Sofern für eine DiGA unterschiedliche Anwendungsdauern hinterlegt sein sollten, würden ebenfalls eigene PZN zugeordnet sein.
• Die PZN ist auf dem Rezept anzugeben.

Verordnungsdauer und Menge:

• Für jede DiGA ist eine bestimmte, vom Hersteller bereits vorgegebene Anwendungsdauer festgelegt; diese Informationen können im DiGA-Verzeichnis ebenfalls unter „Informationen für Fachkreise“ eingesehen werden. Eine Angabe auf der Verordnung ist nicht erforderlich.
• Eine Folgeverordnung für die gleiche DiGA kann ausgestellt werden, wenn sie aus medizinischer Sicht indiziert ist und das angestrebte Therapieziel damit voraussichtlich erreicht werden kann.
• Derzeit sind keine DiGA-Höchstverordnungsmengen pro Versicherten festgelegt; das heißt, dass gegebenenfalls mehrere unterschiedliche DiGA für unterschiedliche Indikationen gleichzeitig verordnet werden können.
• Pro Rezeptblatt darf nur eine DiGA verordnet werden.

Einlösen des Rezeptes:

• Mit dem Rezept wenden sich Versicherte an ihre Krankenkasse.
• Diese prüft unter anderem den Versichertenstatus und generiert einen Freischaltcode.
• Danach laden sich Versicherte die DiGA im jeweiligen App-Store herunter und geben den Freischaltcode ein.
• Die Kosten für die DiGA werden dann von der Kasse direkt mit dem Hersteller abgerechnet.
• Eine Zuzahlungspflicht für Versicherte besteht nicht. Nur wenn der DiGA-Preis über dem Höchstbetrag liegt, müssen Versicherte die Mehrkosten tragen.
  

Verweise:

• Anforderungen an Primärsysteme zur Auswahl einer DiGA aus dem Verzeichnis des BfArM ergeben sich aus den Zertifizierungsanforderungen der KBV (siehe https://update.kbv.de/ita-update/Verordnungen/VDGA/)
• Die FHIR Profile der KBV zur elektronischen Verordnung der DiGA werden hier definiert:
  https://simplifier.net/evdga
• Die technische Anlage zur elektronischen Verordnung Digitaler Gesundheitsanwendungen (Muster E16D):  https://update.kbv.de/ita-update/DigitaleMuster/eVDGA/KBV_ITA_VGEX_Technische_Anlage_EVDGA.pdf
• Vereinbarungen zur Abrechnung werden hier definiert:
  https://www.gkv-spitzenverband.de/krankenversicherung/digitalisierung/kv_diga/diga.jsp 

2.1 E-Rezept für DiGA

Es besteht der gesetzliche Auftrag, die ärztlichen und psychotherapeutischen Verordnungen von DiGA zukünftig in elektronischer Form zu übermitteln (siehe SGB V §360 Abs. 4).

Vorteile der elektronischen Verordnung:

1. Durch die Umstellung und den Verzicht auf die Nutzung von Muster 16 wird entfallen Wege zur Krankenkasse zwecks Übermittlung von Antrag und bisherigem Mustervordruck. Dies verringert den Zeitauf- und Wegeaufwand für Versicherte und lässt sie potentiell früher in die DiGA-Nutzung einsteigen.
2. Ärzte verordnen bereits verschreibungspflichtige Arzneimittel standardmäßig per E-Rezept und erzeugen nur auf Wunsch von Patienten noch einen Ausdruck. Mit dem E-Rezept für DiGA wird ein weiterer Grund zur Verwendung von Muster 16 eliminiert.
3. Krankenkassen werden Anfragen nach Freischaltcodes häufiger auf digitalem Weg erhalten. Es entfällt daher die Handhabung des Muster 16.

Involvierte Akteure:

• Ärzte, Zahnärzte und Psychotherapeuten können DiGA verordnen. Auf Wunsch der Patienten ist ein Ausdruck bereitzustellen (SGB V §360 Abs. 9).
• Patienten können mit Hilfe von Apps mit E-Rezept-Funktionalität nach SGB V §360 Abs. 10 auf ihre Verordnungen zugreifen und durch aktive Anfrage zu einem einzelnen E-Rezept für DiGA den Freischaltcode erlangen. Nach Eingabe oder Übertragung des Freischaltcodes kann die verordnete DiGA verwendet werden.
• gesetzliche Krankenkassen nehmen Zugriffsinformationen einer elektronischen Verordnung von Versicherten aus einer App nach SGB V §360 Abs. 10 oder als Ausdruck nach SGB V §360 Abs. 9 entgegen, laden das E-Rezept vom Fachdienst herunter und stellen nach Prüfung einen Freischaltcode bereit.
• DiGA Hersteller stellen nach Erhalt eines Freischaltcodes den Versicherten die DiGA zur Nutzung bereit und rechnen gegenüber der gesetzlichen Krankenkasse den erhaltenen Freischaltcode ab.

Wesentliche Rahmenbedingungen:

• Das Ersatzverfahren für die elektronische Verordnung von DiGA wird im Bundesmantelvertrag vereinbart. Als Ersatzverfahren wird das bisherige Muster 16 genutzt.
• Krankenkassen greifen nach erfolgter Anfrage eines Versicherten gemäß SGB V §361b auf den Fachdienst zu, um das E-Rezept herunterzuladen. Der Zugriff auf den Fachdienst sowie die Bereitstellung des Freischaltcodes wird vom Fachdienst als Statusänderung erfasst. Der bereitgestellte Freischaltcode wird als Abgabeinformation im Fachdienst gespeichert.
• DiGA Hersteller erhalten keinen Zugriff auf den E-Rezept-Fachdienst und somit auch nicht das E-Rezept.

Prämissen und Anforderungen:

• Die bestehende Schnittstelle zur Auswahl der DiGA im Verzeichnis des BfArM wird von den verordnenden Primärsystemen zur Ermittlung der Stammdaten der DiGA nachgenutzt.
• Etwaige in der TI detektierte Ausfälle werden im Primärsystem der verordnenden Person erkannt und leiten den Nutzer zur Verwendung des Ersatzverfahrens.
• Anforderungen und Empfehlungen für eine gute UX werden im Implementierungsleitfaden beschrieben bzw. finden auch für die elektronische Verordnung von DiGA Anwendung.
• Die Anforderung des Freischaltcodes in der App gemäß SGB V §360 Abs. 10 ist eine bewusste vom Versicherten gesteuerte Aktion (Klick in einer App mit E-Rezept Funktionalität) oder wird durch Bereitstellung des Papierausdrucks (SGB V §360 Abs. 9) gesteuert.
• Die Speicherung des Freischaltcodes erfolgt als Abgabeinformation im E-Rezept-Fachdienst. Die digitale Bereitstellung und Anzeige des Freischaltcodes in der App nach SGB V §360 Abs. 10 ebenso wie die Anzeige eines Deep-Links, so dass ein einfacher Aufruf der DiGA inkl. Übertragung des Freischaltcodes erfolgen kann.
• Sollte eine Bereitstellung eines Freischaltcodes nach Herunterladen des E-Rezeptes und Prüfung durch die Krankenkasse nicht erfolgen können, so ist eine Rückmeldung in den Abgabeinformationen anzugeben, damit Versicherte ein Ergebnis des Prozessschrittes nachvollziehen können.

Wesentliche funktionale Erweiterungen:

• Es wird ein neuer Rezepttyp (Workflow) definiert.
• Neben approbierten Ärzten, Zahnärzten dürfen DiGA auch von Psychotherapeuten verschrieben werden.
• Die Krankenkasse terminiert den Workflow durch Bereitstellung eines Freischaltcodes oder einer Rückmeldung; weshalb dies nicht erfolgen kann. Der Freischaltcode oder die Rückmeldung ist im E-Rezept-Fachdienst von der Krankenkasse zu hinterlegen, damit, gemäß SGB V §312 Abs. 1 Satz 1 Nr. 3 "Abgabeinformationen zu elektronischen Verordnungen nach den Nummern 7 [...] den Versicherten elektronisch verfügbar gemacht werden können". Dies ermöglicht die in SGB V §360 Abs. 14 vorgesehenen automatisierte Bereitstellung der Verordnungsdaten und Dispensierinformationen auch zur elektronischen Verordnung von DiGA in der elektronischen Patientenakte.

2.2 User Stories

2.2.1 Versicherte

Als Patient möchte ich ...

• ... DiGA-Verordnungen unmittelbar/sofort elektronisch empfangen können, so dass ich die DiGA, die mir verschrieben wurde, auch medienbruchfrei beziehen kann.
• ... auch ohne Einsatz einer App mit E-Rezept-Funktionalität (beispielsweise durch Papierausdruck und/oder Einsatz Krankenkassen-App) mit DiGA-Verordnungen umgehen können, so dass ich nicht darauf angewiesen bin, eine NFC-fähige eGK, eine dazu passende PIN, ein NFC-fähiges Gerät haben zu müssen, um DiGAs verwenden zu können.
• ..., dass sich der Prozess des Empfangs der DiGA-Verordnungen möglichst wenig von dem Prozess für Arzneimittelverordnungen unterscheidet, so dass ich mich nicht umgewöhnen muss.
• ..., dass ich über den Erhalt einer DiGA-Verordnung in meiner App mit E-Rezpt-Funktionalität benachrichtigt werde, so dass ich reagieren kann und den Erhalt nicht selbst prüfen muss.
• ..., dass meine sensiblen medizinischen Daten nur den Personen oder Institutionen offenbart werden, die sie wirklich brauchen, so dass ich mich sicher fühle.
• ..., dass eine mir verordnete DiGA ganz leicht freigeschaltet werden kann, so dass ich möglichst ohne Hürden in die Nutzung der DiGA einsteigen und damit meine Therapie unterstützen kann.
• ..., dass ich beim Freischaltprozess, so weit es geht, von der Technik unterstützt werde, so dass dieser Vorgang leicht ist und sich für mich „automatisch“ anfühlt.
• ..., dass ich die Freischaltcode-Anforderung bei meiner Krankenkasse einfach starten und den Status verfolgen kann. Der Start kann über eine App mit E-Rezept-Funktionalität, die Krankenkassen-App (mindestens per Scan des Tokens), per Post oder im Servicecenter der Krankenkasse erfolgen.
• ..., dass ich den Freischaltcode der DiGA sowohl als Information meiner Krankenkasse (via App/Brief) oder direkt in der App mit E-Rezept-Funktionalität erhalten kann.
• ..., dass der Abrechnungsprozess ohne mein Mitwirken abläuft, so dass ich wie gewohnt Leistungen meiner Krankenkasse einfach beziehen kann und keinen administrativen Aufwand habe.
• ... installierbare DiGA-Apps direkt aus der Ansicht der Verordnungen in der App mit E-Rezept-Funktionalität (alternativ Krankenkassen-App) heraus installieren können, so dass ich nicht manuell im App/Play-Store suchen muss und der Prozess für mich einfach ist.
• ... auf DiGAs, die nicht installiert werden können (Bsp. Web-Apps) direkt aus der Ansicht der Verordnung in der App mit E-Rezept-Funktionalität (alternativ Krankenkassen-App) heraus aufrufen können, so dass ich nicht auf Bookmarks oder andere Quellen angewiesen bin.
• ..., dass ich einfach auf die beim BfArM hinterlegte Informationsseite der DiGA sowie die Gebrauchsanweisung per Link aus der E-Rezept–App zugreifen kann, so dass ich mich schnell informieren kann.
• ..., dass ich einfach die Mindestanforderungen der DiGA aus dem Verzeichnis des BfArM per App finden kann, so dass ich in der Lage bin die Mindestanforderungen an mein Endgerät zu prüfen. Bei App-Nutzung wird ein Hinweis ausgespielt (z.B.: „Auf diesem Gerät werden die DiGA ggf. nicht verwendet werden“).

2.2.2 Verordnende

Als verordnender Arzt möchte ich, ...

• ... dass der DiGA-Verordnungsprozess nahtlos in meine Prozesse integriert ist, so dass die Prozesskosten/Aufwand beim Verordnen niedrig ist/bleibt.
• ... dass durch den DiGA-Verordnungsprozess keine zusätzlichen Aufwände in der täglichen Arbeit entstehen, so dass ich nicht noch mehr Zeit für Bürokratie aufbringen muss. Es sollen möglichst wenig Papierausdrucke erstellen.
• ... dass durch den DiGA-Verordnungsprozess möglichst gleiche Abläufe wie für sonstige Medikamente nachgenutzt werden, so dass ich dem Patienten nicht viel erklären muss. Über den Freischaltcodeabruf (Anfragen des Freischaltcodes beim Kostenträger) muss aufgeklärt werden.
• ... dass meine Patienten gut informiert über die DiGA sind. Als Arzt möchte ich möglichst wenig Aufklärung über nicht-medizinische Aspekte (administrative Prozesse) nicht übernehmen.
• ... dass vom Patienten die DiGA diskriminierungsfrei genutzt werden kann, so dass das Verordnen unabhängig einer Regulierung erfolgt/ohne Eingriff in das Verordnungsverhalten des Arztes.
• ... dass ein Ersatzverfahren existiert (vergleichbar heutiger Prozess Muster 16), so dass ich auch bei Internetausfall (de/zentrale Verbindungsprobleme mit/ohne TI) eine DiGA verordnen kann.

2.2.3 Kostenträger

Als Kostenträger möchte ich ...

• ..., dass der Abrechnungsprozess einfach ist, so dass die Prozesskosten niedrig sind.
• ..., dass nur die versicherte Person die verordnete Leistung in Anspruch nehmen kann, so dass missbräuchliche Nutzung bestmöglich vermieden wird.
• ..., dass ich alle Informationen erhalte, die ich für den Abrechnungsprozess benötige, so dass ich nicht Rückfragen stellen muss, um die Abrechnung durchzuführen.
• ..., dass alle Prozesse und auch die Prüfbarkeit so gestaltet sind, dass eine einfache maschinelle Verarbeitung möglich ist, so dass ich automatisieren und damit die Prozesskosten niedrig halten kann.
• ..., dass Versicherte einfach per Krankenkassen-App den E-Rezept Code vom Ausdruck scannen, durch Einsenden per Post, Abgabe im Servicecenter oder aus einer App mit E-Rezept-Funktionalität heraus die Freischaltcode-Anforderung starten können.
• ... nach Übergabe des E-Rezept-Tokens des Versicherten die Verordnungsdaten direkt über den Fachdienst abholen.
• ... Verordnungsservices (Empfangen und Weiterleiten von E-Rezept-Token) über die Krankenkassen-Apps bereitstellen.
• ..., dass Verordnungs- und Abrechnungsprozess prüfbar sind, so dass ich jederzeit nachprüfen kann, ob eine Verordnung und die anschließende Nutzung korrekt sind.

• ..., dass der Abrechnungsprozess einfach ist, so dass die Prozesskosten niedrig sind.
• ..., dass der Verordnungs- und Abrechnungsprozess so gestaltet ist, dass Betrug ausgeschlossen oder mindestens erschwert wird, so dass die Versichertengelder für den richtigen Zweck eingesetzt werden. Eine revisionssichere Dokumentation muss möglich sein.
• ..., dass nur die versicherte Person die verordnete Leistung in Anspruch nehmen kann, so dass missbräuchliche Nutzung bestmöglich vermieden wird.
• ..., dass ich alle Informationen erhalte, die ich für den Abrechnungsprozess benötige, so dass ich nicht Rückfragen stellen muss, um die Abrechnung durchzuführen.
• ..., dass alle Prozesse und auch die Prüfbarkeit so gestaltet sind, dass eine einfache maschinelle Verarbeitung möglich ist, so dass ich automatisieren und damit die Prozesskosten niedrig halten kann.
• ..., dass Versicherte einfach per Krankenkassen-App den E-Rezept Code vom Ausdruck scannen, durch Einsenden per Post, Abgabe im Servicecenter oder aus einer App mit E-Rezept-Funktionalität heraus die Freischaltcode-Anforderung starten können.
• ... nach Übergabe des E-Rezept-Tokens des Versicherten die elektronischen Verordnungsdaten direkt vom Fachdienst abholen
• ..., dass Verordnungs- und Abrechnungsprozess prüfbar sind, so dass ich jederzeit nachprüfen kann, ob eine Verordnung und die anschließende Nutzung korrekt sind

2.2.4 DiGA Hersteller

DiGA Hersteller sind zunächst nicht in den Verordnungsvorgang und nicht bei Übergabe der elektronischen Verordnung vom Versicherten an die Krankenkasse involviert. Die User Stories aus Sicht der DiGA Hersteller, sollen dennoch als Perspektive zum Verständnis der Rolle der Hersteller und derer Anforderungen hier genannt werden.

Als DiGA Hersteller möchte ich ...

• …, dass Patienten auch die DiGA erhalten, die sie verordnet bekommen haben.
• … meinen Patienten einen einfachen Einstieg in meine DiGA bieten.
• …, dass Nutzer im Standardprozess nicht mit dem Freischaltcode in Berührung kommen oder diesen gar manuell übertragen müssen.
• …, dass die Einlösung des E-Rezeptes bei der Krankenkasse die Dispensierung darstellt.
• …, dass mit Einlösung des E-Rezeptes bei der Krankenkasse der Patient über den Freischaltcode informiert wird.
• ..., dass mit Einlösung des E-Rezeptes der Freischaltcode sofort bereitgestellt wird, damit ich direkt nach Erstellung (Dispensierung) abrechnen kann.
• ..., dass im Verordnungsprozess wie auch bei Bereitstellung der Freischaltcodes hochverfügbare Dienste angeboten werden.
• …, dass Patienten eine einheitliche Rückmeldung erhalten, warum kein Freischaltcode ausgestellt werden kann.

3 Einordnung in die Telematikinfrastruktur

Die Einführung der Verordnung von DiGAs setzt auf die bestehende Infrastruktur der Anwendung E-Rezept auf.

Die Psychotherapeuten sind eine neue Benutzergruppe. Das Primärsystem nutzt die bestehende Anbindung an die TI, um Verordnungen einzustellen.

Die gesetzlichen Krankenkassen sind eine neue Benutzergruppe. Das Clientsystem eines Kostenträgers verbindet sich über einen Basis-Consumer mit dem zentralen Netz der TI. Der Basis-Consumer dient der netztechnische Anbindung für den Zugriff auf den IDP-Dienst und den E-Rezept-Fachdienst für das Einlösen der Verordnungen von DiGAs. Für die Authentisierung am IDP-Dienst wird die ExternalAuthenticate Funktion der SM-B KTR über den Basis-Consumer genutzt.

Abbildung 1: Übersicht E-Rezept Komponenten

4 Fachliches Konzept

4.1 Verschreiben

Der technische Ablauf zum Verschreiben einer Verordnung für eine DiGA erfolgt analog zu einer Verordnung für apothekenpflichtige Arzneimittel.

Verordnungen von DiGAs können Ärzten, Zahnärzten und Psychotherapeuten vornehmen.

Der Arzt oder medizinischer Fachangestellter (MFA) erstellt eine elektronische Verordnung für eine DiGA. Über das Primärsystem der LEI wird vom E-Rezept-Fachdienst eine Rezept-ID angefragt und in der Verordnung ergänzt. Der Arzt prüft die Verordnung und führt eine qualifizierte elektronische Signatur (QES) der Verordnung durch.

Anschließend wird die signierte Verordnung (E-Rezept) an den E-Rezept-Fachdienst übermittelt, wo die formale Korrektheit der Verordnung gemäß dem Datenmodell und die QES validiert werden.

Das E-Rezept liegt auf dem E-Rezept-Fachdienst zum Abruf durch den Versicherten bereit.

4.2 Zuweisen durch den Versicherten

Der Versicherte sieht in seinem E-Rezept-FdV, dass ein E-Rezept für eine DiGA erstellt wurde. Diese kann er einsehen und seinem Kostenträger zuweisen, damit er einen Freischaltcode zur Nutzung der DiGA erhält.

Das E-Rezept-FdV bietet dem Versicherten dazu die Möglichkeit den E-Rezept-Token der Verordnung an den Kostenträger zu übertragen. Das Ermitteln des Kostenträgers erfolgt möglichst automatisch, kann aber auch manuell erfolgen.

4.3 Einlösen

Der Kostenträger kann mit den Informationen aus dem E-Rezept-Token die Verordnung vom E-Rezept-Fachdienst herunterladen und den Vorgang prüfen. Sobald ein Freischaltcode generiert wurde, wird dem Versicherten dieser über Abgabeinformationen der Verordnung bereitgestellt. Dadurch wird der Vorgang der Verordnung abgeschlossen und der Versicherte hat den Freischaltcode für die DiGA in seinem E-Rezept-FdV vorliegen.

Sollte die fachliche Prüfung des Kostenträgers ergeben, dass kein Leistungsanspruch besteht, kann der E-Rezept-Workflow auch ohne die Übermittlung eines Freischaltcodes abgeschlossen werden.

Über entsprechende Protokolleinträge ist der Versicherte darüber informiert, dass der Kostenträger den Vorgang bearbeitet.

Der Kostenträger erhält analog zum Abschluss von Arzneimittelverordnungen eine Quittung des Fachdienstes, was dem Kostenträger quittiert, dass der Vorgang erfolgreich abgeschlossen wurde. Die Quittung wird nicht für Abrechnungszwecke benötigt, da die Abwicklung des Vorgangs direkt mit dem Kostenträger erfolgt.

5 Technisches Konzept

Folgendes Sequenzdiagramm bildet den Gesamtprozess einer DiGA Verordnung ab:

Abbildung 2: SD Übermittlung von Verordnungen für DiGAS 

5.1 Verordnen von DiGAs durch Psychotherapeuten

Für die Verordnung von DiGAs durch Psychotherapeuten gelten die gleichen technischen Voraussetzungen wie für Ärzte und Zahnärzte. Der Psychotherapeut muss die Verordnung mit seinem Heilberufsausweis (HBA) qualifiziert elektronisch signieren. Es muss ein HBA verwendet werden, welcher einer der folgenden Berufsgruppe zugeordnet ist:

• Psychotherapeut/-in (oid_psychotherapeut)
• Psychologische/-r Psychotherapeut/-in (oid_ps_psychotherapeut)
• Kinder- und Jugendlichenpsychotherapeut/-in (oid_kuj_psychotherapeut)

Das Primärsystem der Psychotherapeuten Praxis ist über einen Konnektor an das zentrale Netz der TI angebunden und greift über das zentrale Netz der TI auf den zentralen IdP-Dienst und den E-Rezept-Fachdienst zu.

Die Authentisierung des Primärsystem eines Psychotherapeuten am E-Rezept-Fachdienst erfolgt mittels eines ACCESS_TOKEN. Diese werden durch den zentralen IDP-Dienst ausgestellt, welche die Identität des Nutzers attestieren. Eine Nutzung sektoraler IdP-Dienste ist nicht vorgesehen.

Für die Authentisierung nutzt die Psychotherapeuten Praxis ihre SMC-B mit der Rolle oid_praxis_psychotherapeut, bzw. in einer Gemeinschaftspraxis mit Ärzten die Rolle oid_praxis_arzt.

5.2 Authentisierung Kostenträger

Das Primärsystem des Kostenträgers ist über den Basis-Consumer des Kostenträger an das zentrale Netz der TI angebunden und greift über das zentrale Netz der TI auf den zentralen IdP-Dienst und den E-Rezept-Fachdienst zu.

Die Authentisierung des Clientsystem eines Kostenträgers am E-Rezept-Fachdienst erfolgt mittels eines ACCESS_TOKEN. Diese werden durch den zentralen IDP-Dienst ausgestellt, welche die Identität des Nutzers attestieren. Eine Nutzung sektoraler IdP-Dienste ist nicht vorgesehen.

Für die Authentisierung nutzt der Kostenträger seine SM-B KTR mit der Rolle oid_kostentraeger.

5.3 Workflow 162

Für die Übermittlung von E-Rezepten für Digitale Gesundheitsanwendungen wird der Flowtype 162 eingeführt.

Der Flowtype 162 verwendet dasselbe Statusmodell mit denselben möglichen Statusübergängen, wie der Flowtype 160. Siehe [gemSysL_eRp#2.4.6 Konzept Status E-Rezept]. Der Statusübergang eines Task von "in Abgabe gesperrt" zu "gelöscht" durch "UC 4.3 E-Rezept durch Abgebenden löschen" ist nicht vorgesehen.

5.4 Löschfristen

Die Löschfristen für E-Rezepte des Flowtype 162 entsprechen denen der E-Rezept des Flowtyps 160.

5.5 Use Cases im Rahmen der Verordnung

Die Prozesse des verordnenden Leistungserbringers, welche für die Übermittlung von ärztlichen und zahnärztlichen Verordnungen für apothekenpflichtige Arzneimittel konzipiert wurden, werden ebenso für die Verordnung von DiGA genutzt.

Folgende Anwendungsfälle werden genutzt:

• UC 2.1 - E-Rezepte erzeugen
• UC 2.3 - E-Rezept einstellen
• UC 2.5 - E-Rezept durch Verordnenden löschen

Für Details zu den Anwendungsfällen siehe [gemSysL_eRp].

5.5.1 eVDGA FHIR Profile

Zur Verordnung von DiGAs werden die FHIR-Profile der KBV genutzt: https://simplifier.net/evdga.
Die Workflowprofile https://simplifier.net/erezept-workflow werden dahingehend erweitert, dass diese Profile ebenfalls unterstützt werden.

Der E-Rezept-Fachdienst prüft, ob Verordnungen, die mittels Workflowtyp 162 verordnet werden, mit den DiGA-Profilen erstellt wurden.

5.6 Use Cases im Rahmen der Verwaltung durch den Versicherten

Die Prozesse des Versicherten für die Einsichtnahme in die Verordnungen, das Übermitteln der Verordnung an den Kostenträger und die Kommunikation mit dem Kostenträger, entsprechen denen welche für die Übermittlung von ärztlichen und zahnärztlichen Verordnungen für apothekenpflichtige Arzneimittel konzipiert wurden.

Folgende Anwendungsfälle werden genutzt:

• UC 3.1 - E-Rezepte durch Versicherten abrufen
• UC 3.2 - E-Rezept durch Versicherten löschen 
• UC 3.3 - Nachricht durch Versicherten übermitteln
• UC 3.4 - Nachrichten durch Versicherten empfangen
• UC 3.8 - Nachricht durch Versicherten löschen
• UC 3.5 - Protokolldaten abrufen

Für Details zu den Anwendungsfällen siehe [gemSysL_eRp].

Für das Übermitteln der Verordnung wird als Adressat der Kostenträger ausgewählt. Bei der Umsetzung im E-Rezept-FdV kann die Auswahl automatisiert erfolgen.

5.6.1 Ermitteln der Telematik-ID des Kostenträgers

Damit das E-Rezept-FdV der gematik "UC 3.3 - Nachricht durch Versicherten übermitteln" ausführen kann, muss es zunächst die Telematik-ID des Kostenträgers als Empfängeradresse der Nachricht ermitteln.

Das E-Rezept-FdV benötigt das Haupt-Institutionskennzeichen (IK) des Kostenträgers. Dieses IK wird über die Authentifizierungsmethoden des E-Rezept-FdV bereitgestellt. Das E-Rezept-FdV erhält sowohl bei der Authentifizierung mittels eGK, wie auch mittels sektoralem IDP (GesundheitsID) einen ACCESS_TOKEN vom E-Rezept Authorization Server (Teil des IDP-Dienstes) ausgestellt. Dieser ACCESS_TOKEN wird erweitert, sodass das IK des Kostenträgers dort enthalten ist.

Sobald dem E-Rezept-FdV das IK vorliegt, sucht es im FHIR-VZD nach der Telematik-ID des Kostenträgers mithilfe des IK.

Dieser Fall ist für die E-Rezept-FdVs der Krankenkassen nicht relevant, da diese die korrekte Telematik-ID in ihren Apps vorab festlegen können. Sollte jedoch eine Vertreterfunktion implementiert werden, wird dieser Fall auch für sie relevant.

5.6.1.1 Fallback bei Fehlern und fehlenden Informationen

Falls es dem E-Rezept-FdV nicht möglich ist, das IK oder die Telematik-ID des Kostenträgers zu bestimmen, soll der Versicherte dennoch die Möglichkeit haben, seine DiGA Verordnung zuzuweisen.

Hierzu zeigt das E-Rezept-FdV dem Versicherten alle Kostenträgereinträge des FHIR-VZD mit oid_kostentraeger, die eine IKNR und Telematik-ID haben. Der Versicherte wählt die Krankenkasse aus, bei der er versichert ist und kann so die Einlösung vornehmen.

5.6.2 Zuweisen der Verordnung durch den Versicherten

Sobald die Telematik-ID im E-Rezept-FdV vorliegt, kann der Versicherte das E-Rezept seinem Kostenträger zuweisen. Hierzu wird eine Communication (GEM_ERP_PR_Communication_DispReq) erstellt und der E-Rezept-Token eingebettet. Das FHIR-Profil wird dahingehend angepasst, dass Communication.payload eine Kardinalität von 0..1 hat, da beim Zuweisen im Rahmen einer DiGA-Verordnung kein Payload mit Zusatzinformationen wie bspw. Kontaktdaten und Belieferungsoptionen übertragen werden muss.

5.7 Use Cases im Rahmen des Einlösens durch Kostenträger

Die Prozesse der Krankenkasse für das Einlösen der Verordnung orientieren sich an den Prozessen der abgebenden Leistungserbringerinstitutionen bei Verordnungen für apothekenpflichtige Arzneimitteln.

Die folgenden Anwendungsfälle werden adaptiert und angepasst.

5.7.1 UC 4.6 - Nachrichten durch Abgebenden empfangen

A_18617-01 - Anwendungsfall "Nachrichten durch Abgebenden empfangen"

Alle am Anwendungsfall "Nachrichten durch Abgebenden empfangen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 1: TAB_SYSLERP_036 Anwendungsfall Nachrichten durch Abgebenden empfangen

Name	UC 4.6 - Nachrichten durch Abgebenden empfangen
Vorbedingung	Ein Versicherter oder Vertreter hat den Anwendungsfall "UC 3.3 - Nachricht durch Versicherten übermitteln" ausgeführt
Kurzbeschreibung (Außenansicht)	Das Primärsystem der abgebenden Institution kann automatisch oder manuell ausgelöst Nachrichten, die an die Telematik-ID der Institution gesendet wurden vom E-Rezept-Fachdienst abrufen. Es gibt verschiedene Nachrichtentypen: Zuweisen Verfügbarkeitsanfrage In einer Nachricht zum Zuweisen wird die Information übermittelt, welches zum Abruf einer Verordnung vom E-Rezept-Fachdienst legitimiert (E-Rezept-Token). Das Empfangen von Nachrichten über die TI erfolgt mithilfe des E-Rezept-Fachdienstes. Das PS fragt beim E-Rezept-Fachdienstes an, ob für die Telematik-ID der Institution neue Nachrichten vorliegen und lädt diese herunter.
Nachbedingung	Der E-Rezept-Token liegt im PS der abgebenden Institution vor.

Abbildung 3 : SD UC 4.6  - Nachrichten durch Abgebenden empfangen

[<=]

Für die Verordnung von DiGAs ist ausschließlich die Nutzung der Nachrichten zum Zuweisen vorgesehen.

5.7.2 UC 4.7 Nachricht durch Abgebenden übermitteln

A_19013-01 - Anwendungsfall "Nachricht durch Abgebenden übermitteln"

Alle am Anwendungsfall "Nachricht durch Abgebenden übermitteln" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 2: TAB_SYSLERP_055 Anwendungsfall Nachricht durch Abgebenden übermitteln

Name	UC 4.7 - Nachricht durch Abgebenden übermitteln
Vorbedingung	Ein Versicherter oder Vertreter hat den Anwendungsfall "UC 3.3 - Nachricht durch Versicherten übermitteln" ausgeführt. Die abgebende Institution hat den Anwendungsfall "UC 4.6 - Nachrichten durch Abgebenden empfangen" durchgeführt.
Kurzbeschreibung (Außenansicht)	Das PS der abgebenden Institution erzeugt eine Antwort auf eine Nachricht durch den Versicherten. Der sichere Versand über die TI erfolgt mithilfe des E-Rezept-Fachdienstes. Als Empfänger wird der Absender der ursprünglichen Nachricht gesetzt. Das PS stellt die Nachricht in den E-Rezept-Fachdienst ein.
Nachbedingung	Die Nachricht liegt im E-Rezept-Fachdienst und kann vom Versicherten bzw. Vertreter asynchron empfangen werden.

Abbildung 4 : SD UC 4.7 Nachricht durch Abgebenden übermitteln

[<=]

5.7.3 UC 4.1 - E-Rezept durch Abgebenden abrufen

A_18511-01 - Anwendungsfall "E-Rezept durch Abgebenden abrufen"

Alle am Anwendungsfall "E-Rezept durch Abgebenden abrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 3: TAB_SYSLERP_014 Anwendungsfall E-Rezept durch Abgebenden abrufen

Name	UC 4.1 - E-Rezept durch Abgebenden abrufen
Vorbedingung	Ein E-Rezept-Token liegt im Primärsystem vor. Das E-Rezept im E-Rezept-Fachdienst hat den Status "offen"
Kurzbeschreibung (Außenansicht)	Im PS wird ein E-Rezept-Token zum Abruf ausgewählt. Das PS ermittelt die Rezept-ID und den AccessCode aus dem E-Rezept-Token. Das PS ruft mit der Rezept-ID und dem AccessCode das E-Rezept vom E-Rezept-Fachdienst ab. Der E-Rezept-Fachdienst prüft die Autorisierung des Clientsystems. Der Status der Verordnung im E-Rezept-Fachdienst wird auf "in Abgabe (gesperrt)" geändert. Der E-Rezept-Fachdienst erzeugt ein Geheimnis zur Statusänderung "in Abgabe (gesperrt)", welches im E-Rezept-Fachdienst gespeichert und dem PS zusammen mit dem E-Rezept übermittelt wird. Das PS prüft optional die Gültigkeit der QES der Verordnung.
Nachbedingung	Das E-Rezept hat im E-Rezept-Fachdienst den Status "in Abgabe (gesperrt)". Der Statuswechsel ist im E-Rezept-Fachdienst für den Versicherten protokolliert. Das E-Rezept steht zur Verarbeitung im PS bereit. Das Geheimnis zur Statusänderung "in Abgabe (gesperrt)" ist im PS gespeichert.

Abbildung 5 : SD UC 4.1 - E-Rezept durch Abgebenden abrufen

[<=]

5.7.4 UC 4.2 - E-Rezept durch Abgebenden zurückgeben

Der Kostenträger muss für den Fall einer fehlerhaften Zuweisung, bspw. wenn der Versicherte manuell seinen Kostenträger aussucht und dabei eine falsche Auswahl vornimmt, den Anwendungsfall "UC 4.2 - E-Rezept durch abgebenden zurückgeben" ausführen, um das E-Rezept wieder an den Nutzer zurückzugeben. Weiterhin ist der Anwendungsfall "UC 4.7 - Nachricht durch Abgebenden übermitteln" auszuführen und darin eine verständliche Nachricht an den Nutzer zu übertragen, warum die Zuweisung nicht bearbeitet werden konnte.

A_18512-01 - Anwendungsfall "E-Rezept durch Abgebenden zurückgeben"

Alle am Anwendungsfall "E-Rezept durch Abgebenden zurückgeben" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 4: TAB_SYSLERP_015 Anwendungsfall E-Rezept durch Abgebenden zurückgeben

Name	UC 4.2 - E-Rezept durch Abgebenden zurückgeben
Vorbedingung	Der Anwendungsfall "UC 4.1 - E-Rezept durch Abgebenden abrufen" wurde durchgeführt. Die Rezept-ID und das Geheimnis zur Statusänderung "in Abgabe (gesperrt)" sind im PS bekannt. Das E-Rezept im E-Rezept-Fachdienst hat den Status "in Abgabe (gesperrt)".
Kurzbeschreibung (Außenansicht)	Im PS der abgebenden Institution wird ein E-Rezept zum Zurückgeben ausgewählt. Das PS übermittelt beim Aufruf des E-Rezept-Fachdienstes die Rezept-ID und das Geheimnis zur Statusänderung "in Abgabe (gesperrt)". Der Status des E-Rezepts im E-Rezept-Fachdienst wird geändert.
Nachbedingung	Das E-Rezept im E-Rezept-Fachdienst hat den Status "offen". Der Statuswechsel ist im E-Rezept-Fachdienst für den Versicherten protokolliert. Das E-Rezept, der E-Rezept-Token und das Geheimnis zur Statusänderung "in Abgabe (gesperrt)" sind im PS gelöscht.

Abbildung 6 : SD UC 4.2 - E-Rezept durch Abgebenden zurückgeben

[<=]

5.7.5 UC 4.4 - Quittung abrufen

Nachdem der Kostenträger die Zuweisung des Versicherten bearbeitet und einen Freischaltcode generiert hat, wird dieser in "UC 4.4 - Quittung abrufen" in den Abgabeinformationen an den E-Rezept-Fachdienst übertragen, damit der Versicherte den Freischaltcode im E-Rezept-FdV einsehen kann.

Der Freischaltcode und der Name der verordneten DiGA werden, wenn der Vorgang ordnungsgemäß abgeschlossen werden kann, im FHIR-Profil der MedicationDispense angegeben. Stellt die fachliche Prüfung fest, dass kein Leistungsanspruch besteht, wird kein Freischaltcode übertragen und der Workflow wird dennoch ordnungsgemäß abgeschlossen.

neu:

A_18514-01 - Anwendungsfall "Quittung abrufen"

Alle am Anwendungsfall "Quittung abrufen" beteiligten Produkttypen und Komponenten MÜSSEN die nachfolgenden Festlegungen umsetzen.

Tabelle 5: TAB_SYSLERP_017 Anwendungsfall Quittung abrufen

Name	UC 4.4 - Quittung abrufen
Vorbedingung	Der Anwendungsfall "UC 4.1 - E-Rezept durch Abgebenden abrufen" wurde durchgeführt. Die Rezept-ID, der AccessCode und das Geheimnis zur Statusänderung "in Abgabe (gesperrt)" des E-Rezepts sind im PS bekannt. Das E-Rezept im E-Rezept-Fachdienst hat den Status "in Abgabe (gesperrt)".
Kurzbeschreibung (Außenansicht)	Der Inhalt der Verordnung wurde dispensiert. Das E-Rezept wird über über das PS als abgegeben markiert und zum Abschluss freigegeben. Das PS übermittelt beim Aufruf des E-Rezept-Fachdienstes die Rezept-ID, den AccessCode und das Geheimnis zur Statusänderung "in Abgabe (gesperrt)" und die Informationen zur Abgabe. Der Status des E-Rezepts im E-Rezept-Fachdienst wird geändert. Der E-Rezept-Fachdienst erstellt eine Quittung und übermittelt diese an das PS.
Nachbedingung	Das E-Rezept im E-Rezept-Fachdienst hat den Status "quittiert". Die Information zur Abgabe liegen im E-Rezept-Fachdienst. Der Statuswechsel des E-Rezept zum Status "quittiert" ist im E-Rezept-Fachdienst für den Versicherten protokolliert. Im PS liegt eine Quittung vor, welche bspw. für die Abrechnung des E-Rezepts genutzt werden kann.

Abbildung 7 : SD UC4.4 - Quittung abrufen

[<=]

6 Datenschutz und Informationssicherheit

Das Feature Verordnung von Digitalen Gesundheitsanwendungen bewirkt, dass zwei neue Akteure Zugriff auf den E-Rezept-Fachdienst erhalten: Krankenkassen in der Rolle Kostenträger und Psychotherapeuten, die an der vertragsärztlichen Versorgung teilnehmen in der Rolle verordnende Leistungserbringer – ausschließlich für den neuen Workflow für die Verordnung von Digitalen Gesundheitsanwendungen.

Während die Psychotherapeuten über ihre bestehende Anbindung an die TI mit dem E-Rezept-Fachdienst kommunizieren (sobald ihre Primärsysteme die benötigte Funktionalität zur Verfügung stellen), erfolgt der Zugang zum E-Rezept-Fachdienst für die Krankenkassen über das zentrale Netz der TI.

Die Kostenträger authentifizieren sich dabei beim IDP-Dienst mit ihrer KTR-Identität und am E-Rezept-Fachdienst mittels des vom IDP ausgestellten Access-Token. Ob ein Leistungserbringer berechtigt ist, ein E-Rezept für eine DiGA einzustellen, wird anhand seiner Rolle in der QES festgestellt. Die netztechnische Verbindung zwischen Clientsystem der Kostenträger und dem E-Rezept-Fachdienst erfolgt über TLS und VAU-Protokoll.

Die wesentlichen neuen Informationsobjekte sind einerseits ein E-Rezept mit einer Verordnung für DiGAs, das den gleichen Schutzbedarf hat, wie ein E-Rezept mit einer Verordnung für apothekenpflichtige Arzneimittel und andererseits der Freischaltcode, mit dem ein Versicherter eine DiGA für sich freischalten kann. Der Freischaltcode kommt in der TI nur als Teil der Abgabeinformationen vor. Der Schutzbedarf der Abgabeinformationen ändert sich dadurch nicht.

Im Rahmen des neuen Workflows (162) werden neue Anwendungsfälle (Use Cases) für die Verarbeitung von E-Rezepten für DiGAs vorgesehen und bereits für E-Rezepte mit einer Verordnung für apothekenpflichtigen Arzneimitteln existierende Anwendungsfälle nachgenutzt. Der Schutzbedarf für Verfügbarkeit dieser Anwendungsfälle wird mit „mittel“ bewertet, da bei einer Nichtverfügbarkeit keine kritische Auswirkung auf den Nutzer der DiGA gesehen wird. Die Rechtmäßigkeit der Anwendungsfälle für E-Verordnungen ergibt sich aus § 360 Abs. 4 SGB V.

Bei der Ausführung eines Anwendungsfalls durch einen Akteur wird ein dementsprechender Eintrag in das Protokoll für den Versicherten geschrieben.

Die Einlösung eines E-Rezepts mit einer Verordnung für DiGAs durch einen Versicherten erfolgt vorzugsweise über eine App mit E-Rezept-Funktionalität (E-Rezept-FdV der gematik oder E-Rezept-FdV eines Kostenträgers). Dadurch ist es möglich, dass der Versicherte das E-Rezepts mit einer Verordnung für eine DiGA dem Kostenträger über die App zuweist und den Freischaltcode in die App laden kann. Alternativ können Versicherte über das Versenden eines Ausdrucks der Verordnung an ihren Kostenträger von diesem einen Freischaltcode per Post erhalten.

Die Sicherheit und Datenschutzkonformität der DiGAs selbst wird in der Verordnung über das Verfahren und die Anforderungen zur Prüfung der Erstattungsfähigkeit digitaler Gesundheitsanwendungen in der gesetzlichen Krankenversicherung (DiGAV) geregelt.

7 Spezifikation

Dieses Kapitel beschreibt die technische Umsetzung der beschriebenen Konzepte an die verschiedenen Produkt- und Anbietertypen. In den jeweiligen Produkt- und Anbietertypsteckbriefen sind zu den Anforderungen ("Blattanforderungen") die jeweiligen Prüfverfahren angegeben.

Dargestellt sind die zusätzlichen Anforderungen an die Produkttypen der Anwendung E-Rezept, die bestehende Anforderungslage für bereits eingeführte Flowtypes, wie bspw. den Prozess der apothekenpflichtigen Arzneimittel (Flowtype=160) bleibt hiervon unberührt.

7.1 Anforderungen an gemSpec_IDP_Dienst (zentralen IDP-Dienst)

Im Rahmen der Verordnung von DiGA benötigt das E-Rezept-FdV das IK des Kostenträgers bei dem der Empfänger der Verordnung versichert ist, um eine DiGA Verordnung an diesen Kostenträger zuweisen zu können. Das IK soll dem E-Rezept-FdV über den ACCESS_TOKEN des IDP-Dienstes  im Claim "organizationIK" bereitgestellt werden.

Dieser Claim soll in allen Authentisierungsverfahren, d.h. aktuell via GesundheitsID und via eGK enthalten sein.

eGK:

Das C.CH.AUT Zertifikat eGK enthält immer in OU=KVNR und OU=IK-Nummer. Der IDP-Dienst extrahiert aktuell aus dem Zertifikat OU=KVNR und setzt den Wert im ID-Token. OU=IK-Nummer wird derzeit ignoriert

Notwendige Änderungen im zentralen IDP-Dienst (Kapitel 5.3.2 Token-Endpunkt Ausgangsdaten)

• Erweiterung der Spezifikation Anforderungen A_20524-04 um Identifier organizationIK= Institutionskennzeichen (Zertifikatsfeld organizationalUnitName)

GesundheitsID:

• sektoraler IDP
• keine Anpassung notwendig, gemäß _A_22989-01 - "scopes" und "claims" des sektoralen IDP für Versicherte_ wird die IK-Nummer im claim urn:telematik:claims:organization unter dem scope urn:telematik:versicherter im ID-Token mitgeliefert.
• IDP-Dienst (eRP-AuthZ)
• Anpassung der Spezifikationen (Anforderungen), damit das FdV für alle Auth-Verfahren mit eGK die IK-Nummer im Access-Token kommt (A_22271-01)

7.1.1 Änderungen in 5.3.2 Token-Endpunkt Ausgangsdaten

alt:

neu:

Hinweis: Zertifikatsbelegung - siehe gemSpec_PKI Kapitel 10

alt:

neu:

7.2 Anforderungen an gemSpec_IDP_FD

7.2.1 Änderungen in 5.1.1 Inhalte des Claims

alt:

neu:

7.3 Anforderungen an den E-Rezept-Fachdienst

Die nachfolgenden Anforderungen werden in das Dokument [gemSpec_FD_eRp] übernommen.

7.3.1 Änderung in 5.2.1 Registrierung beim Identity Provider

Um die Suche der für das Zuweisen zu nutzenden Telematik-ID des KTR im im E-Rezept-FdV zu unterstützen, wenn diese nicht statisch festgelegt ist, wird im ACCESS_TOKEN und ID_TOKEN ein weiteres Feld mit der IK ergänzt. Somit kann das E-Rezept-FdV bei der Authentifizierung über den IDP-Dienst das IK des Kostenträgers des Versicherten im Token auslesen.

alt:

neu:

alt:

neu:

7.3.2 Änderung in 5.5 Protokollierung

Protokolleinträge werden für die Operationen abstrahiert, auf denen auch die Kostenträger operieren.

alt:

neu:

7.3.3 Autorisierung der Kostenträger am E-Rezept-Fachdienst

Kostenträger müssen autorisiert werden, das Abrufen und die Belieferung von E-Rezepten über den E-Rezept-Fachdienst auszuführen. Daher muss die oid_kostentraeger als Kriterium im ACCESS_TOKEN Zugriffe auf den E-Rezept-Fachdienst erlauben.

7.3.3.1 Änderung in 5.7 Berechtigungen und Prozessparameter

Hinzufügen der oid_kostentraeger zu den Operationen $accept, $close und $reject, sowie GET und POST /Communication

alt:

neu:

7.3.4 Anpassen der Anforderungen von Workflow Operationen

7.3.4.1 Änderung in 6.1.2.2 POST /Task/<id>/$activate

Hinzufügen des Packages kbv.itv.evdga als gültiges Schema

alt: 

neu:

Aufteilen der Anforderungen zur Aktivierung, sodass Ärzte Arzneimittel und DiGAs und Psychotherapeuten nur DiGAs verordnen dürfen.

alt:

neu:

neue Anforderung die Ärzten, Zahnärzten und Psychotherapeuten erlaubt DiGAs zu Verordnen

Neue AFO, die für Flowtype 162 nur Verordnungen mit KBV Profilen kbv.itv.evdga zulässt

Erweiterung einer Anforderung zur Steuerung von Zulässigen Coverage Typen

alt:

neu:

Anpassung einer Anforderung zum Umschreiben von DiGA Verordnungen für das FdV

alt:

neu:

Neue Anforderung zur PZN Prüfung für DiGAs

Anpassungen von Anforderungen zur Steuerung des Zugriffs durch Kostenträger

7.3.4.2 Änderung in 6.1.2.3 POST /Task/<id>/$accept

7.3.4.2.1 POST /Task/<id>/$accept - Arzneimittelverordnungen

Änderung einer bestehenden und Hinzufügen einer neuen AFO, damit Apotheken Arzneimittel und Kostenträger Digitale Anwendungen abrufen können

alt:

neu: 

7.3.4.2.2 POST /Task/<id>/$accept - Verordnungen Digitaler Gesundheitsanwendungen

7.3.4.3 Änderung in 6.1.2.4 POST /Task/<id>/$reject

Kostenträger können eine Verordnung zurückweisen, eine Unterscheidung nach Flowtype ist nicht nötig, da beim $accept schon danach unterschieden wird

alt:

neu:

7.3.4.4 Änderung in 6.1.2.5 POST /Task/<id>/$close

alt:

neu: 

Einführen WF spezifischer AFOs, die die Angabe von MedicationDispense Profilen validiert

7.3.5 Anpassen der Anforderungen von Communication-Ressourcen

7.3.5.1 Änderung in 6.5 Ressource Communication

Kostenträger können Communications senden und empfangen

alt:

neu: 

7.3.6 Anpassen der Anforderungen der Subscription Ressource

7.3.6.1 Änderung in 6.8.1 HTTP-Operation POST

alt:

neu:

7.4 Anforderungen an das E-Rezept-FdV

Die nachfolgenden Anforderungen werden in das Dokument [gemSpec_eRp_FdV] übernommen.

7.4.1 Änderung in 5.2.1 Übersicht der Anwendungsfälle

Ergänzung der Übersicht der Anwendungsfälle um die Information, für welche Workflows sie umgesetzt werden.

Tabelle 18 : TAB_FdVERP_003 – Übersicht Anwendungsfälle E-Rezept-FdV

7.4.2 Änderung in 5.2.3.9 Anfrage zur Belieferung von E-Rezepten bei einer Apotheke

Erweiterung einer AFO, dass für DiGAs keine Belieferungsanfrage gestellt werden darf

alt:

neu:

Zur Unterscheidung von Apotheke und Kostenträger ist im FHIR-VZD das Feld Organization.type vorgesehen.

7.4.3 Änderung in 5.2.3.10 E-Rezept einer Apotheke über die TI zuweisen

Neue Anforderung, dass für die Zuweisung eine Apotheke oder Kostenträger ausgewählt werden kann.

aktuell vorhanden:

neue Anforderung:

Fortschreiben Anwendungsfall "Verordnung einer abgebenden Institution zuweisen" 

alt:

neu:

7.4.4 Neues Kapitel 5.2.3.x Kostenträger suchen

Einzufügen nach Kapitel "5.2.3.13 Apotheke suchen"

User Stories:

Als Patient möchte ich, ...

• ... dass ich meine mir ausgestellte DiGA Verordnung meinem Kostenträger/ meiner Krankenkasse zugewiesen werden kann, damit ich einen Freischaltcode erhalte.
• ... dass die richtige Zieladresse der Zuweisung automatisch erfolgt.
• ... dass wenn die Zieladresse nicht automatisch ermittelt werden kann, ich meine Krankenkasse manuell auswählen kann.

Mit diesem Anwendungsfall soll ermöglicht werden, dass ein Nutzer eines E-Rezept-FdV möglich ist, eine DiGA Verordnung an den korrekten Kostenträger zuzuweisen. Soweit möglich, kann die Telematik-ID des Kostenträgers für den Versicherten im E-Rezept-FdV fest vorgegeben werden. In diesem Fall müssen die Anforderungen zu diesem Anwendungsfall nicht umgesetzt werden.

Wenn die Telematik-ID des KTR des Versicherten nicht im Programmcode hinterlegt wird, muss diese zur Laufzeit bestimmt werden. Hierfür nutzt das E-Rezept-FdV das IKNR des KTR, wodurch es dann in der Lage ist nach der Telematik-ID im FHIRVZD zu suchen.

Als Antwort erhält das E-Rezept-FdV ein Suchset mit mindestens 2 Ressourcen: eine oder mehrere HealthcareServices und genau eine Organization Ressource. Die Organization Ressource enthält dann einen identifier mit identifier.type == "PRN". Dieser identifier enthält die Telematik-ID unter identifier.value.

Falls das E-Rezept-FdV nicht in der Lage ist die IKNR oder die Telematik-ID des Kostenträgers des Nutzers zu ermitteln, soll der Nutzer die Möglichkeit haben den Kostenträger manuell zu bestimmen.

Der Nutzer soll eine Liste aller Kostenträger, denen eine DiGA zugewiesen werden kann, zur Auswahl angezeigt bekommen.

Als Antwort erhält das E-Rezept-FdV ein Suchset mit mehreren HealthcareServices und mehreren Organizations. Dem Nutzer ist dann eine Liste der Organizations anzuzeigen und zu verarbeiten:

• Organization.name enthält den Namen der Krankenkasse
• Organzation.identifier:Telematik-ID enthält die Telematik-ID an die die Communication gesendet werden muss

7.4.5 Änderung in 5.2.3.16 Abgabeinformationen anzeigen

Neue Anforderung unter "A_20036-01 E-Rezept FdV: Abgabeinfomationen abfragen - Anzeige der Abgabeinformationen"

7.5 Anforderungen an das Clientsystem der Kostenträger

Für das Primärsystem der Kostenträger im E-Rezept-Kontext wird ein neuer Produkttyp "CS_E-Rezept_KTR" definiert. Die nachfolgenden Anforderungen für diesen Produkttyp werden in [gemILF_PS_eRp] aufgenommen.

7.5.1 Änderung in 5.1.1 Kommunikation zu den Diensten der TI

alt:

neu:

7.5.2 Änderung in 5.3.5 Quittung abrufen

bestehende Anforderungen für Apotheken

neue Anforderung für Workflow 162

7.5.3 Neue Anforderungen für Clientsystem Kostenträger

Folgende Kapitel werden in gemILF_PS_eRp hinzugefügt. 

7.5.3.1 Änderung in 5.3.7 E-Rezept zurückgeben

Folgendes wird als Einleitungstext für das Kapitel "E-Rezept zurückgeben" gesetzt:

Mit diesem Anwendungsfall kann die abgebende LEI ein E-Rezept, welches vom E-Rezept-Fachdienst abgerufen wurde, wieder zurückgeben, z.B. weil das E-Rezept nicht beliefert werden kann oder weil der Versicherte darum gebeten hat. Nachfolgend kann es durch den Versicherten einer anderen abgebenden LEI zugewiesen werden.

Dieser Anwendungsfall ist auch von Kostenträgern auszuführen, wenn die Verarbeitung der Zuweisung einer digitalen Gesundheitsanwendung nicht möglich ist.

7.5.3.2 Neues Kapitel 9 Best practice UX Clientsysteme Kostenträger

7.5.3.2.1 Zusatzinformationen

Nach Abschluss der Workflows eines E-Rezeptes hat der Kostenträger die Möglichkeit dem Versicherten eine Antwort zur Zuweisung zu übermitteln. Hierfür erstellt der Kostenträger eine Communication vom Profil  GEM_ERP_PR_Communication_Reply und ergänzt unter Communication.payload.contentString den Antworttext, der dem Nutzer im E-Rezept-FdV dargestellt werden soll.

Hierfür gelten die Vorgaben aus gemSpec_DM_eRp#A_23877.

7.5.3.2.2 Fehlermanagement

Falls es bei der Verarbeitung einer Zuweisung einer digitalen Gesundheitsanwendung zu einem Fehler kommt, bspw. wenn der Nutzer nicht beim Kostenträger versichert ist, muss das Clientsystem den Nutzer informieren und das E-Rezept zur weiteren Nutzung zurückgeben.

Hierzu führt der Kostenträger die E-Rezept-Fachdienst Operation "$reject" aus und übermittelt dem Nutzer eine GEM_ERP_PR_Communication_Reply in der der Kostenträger angeben kann, warum die Verordnung nicht bearbeitet werden kann.

7.5.4 Umzusetzende Anforderungen

Die durch das Clientsystem umzusetzenden Anforderungen sind im Steckbrief "Clientsystem-Schnittstelle für E-Rezept: Kostenträger" [gemSST_CS_eRp_KTR_V] gelistet.

7.6 Daten- und Informationsmodell

7.6.1 Fast Healthcare Interoperability Resources

7.6.1.1 Datenmodell Verordnung der KBV für DiGA

Das Datenmodell für die Verordnung von DiGAs wird von der KBV definiert und unter https://simplifier.net/eVDGA veröffentlicht.

7.6.1.2 Datenmodell Workflow Profile der gematik für DiGA

Das Datenmodell der Workflow Profile die für die Verordnung von digitalen Gesundheitsanwendungen genutzt werden sind von der gematik unter https://simplifier.net/erezept-workflow bereitgestellt.

7.6.1.2.1 MedicationDispense

Für die Umsetzung der Verordenbarkeit von DiGAs am E-Rezept-Fachdienst wird eine neue MedicationDispense profiliert. Ein weiteres Profil begründet sich darin, dass der Implementiererkreis und der Anwendungsfall ein anderer ist. E-Rezepte von DiGAs werden von den Kassen abgeschlossen und E-Rezepte von Arzneimitteln von Apotheken.

Die neue MedicationDispense weist folgende Besonderheiten auf:

• MedicationDispense.extension:redeemCode: Der Freischaltcode für eine DiGA wird nicht als eigene Ressource sondern innerhalb der MedicationDispense Ressource als Extension angegeben (0..1).
• MedicationDispense.extension:deepLink: Angabe eines DeepLinks für eine DiGA. Diese werden nicht als eigene Ressourcen sondern innerhalb der MedicationDispense Ressource als Extension angegeben (0..1).
• MedicationDispense.substitution: Dieses Feld enthält die Kardinalität, darf also nicht gesetzt werden, da Kostenträger nach aktueller Gesetzeslage eine DiGA-Verordnung nicht substituieren dürfen.
• MedicationDispense.medicationReference: Wenn eine Abgabe erfolgt, dann müssen laut FHIR-Spezifikation Angaben zur abgegebenen Medikation gemacht werden. Hierfür ist vorgesehen, dass folgendes angegeben wird:
• .display: Angabe des Namens der DiGA
• .identifier.value: Die DiGA-VE-ID des BfArM (mit .system = https://fhir.bfarm.de/Identifier/DigaVeId)
• Im Falle, dass keine Bereitstellung des Freischaltcodes erfolgt und der Vorgang des E-Rezeptes abgeschlossen wird, wird unter medicationReference.extension ein DataAbsentReason = #asked-declined angegeben

Es gelten folgende Constraints für die MedicationDispense:

• Wenn ein Freischaltcode existiert muss der Name der Diga und die DiGA ID angegeben werden
• Wenn kein Freischaltcode bereitgestellt wird, dann muss das Feld .note befüllt werden, um dem Nutzer eine Rückmeldung zu geben
• Wenn kein Freischaltcode bereitgestellt wird, muss ein DataAbsentReason angegeben werden

7.6.1.2.2 CodeSystem Flowtype

Das CodeSystem GEM_ERP_CS_FlowType wird erweitert, um den neuen Flowtype "162" zu unterstützen.

7.6.1.2.3 CodeSystem Organisations-Typ

Das CodeSystem GEM_ERP_CS_OrganizationType wird erweitert, um den neuen Performer-Organisations-Typ "Kostenträger" mit oid 1.2.276.0.76.4.59 zu unterstützen.

7.6.1.2.4 Communication

Für die Zuweisung einer DiGA wird kein Payload unter Communication.payload benötigt. Daher wird im Profil die Kardinalität für Communication.payload im Profil GEM_ERP_PR_Communication_DispReq auf 0..1 gesetzt.

Um sicherzugehen, dass bei Zuweisungen von Arzneimittelverordnungen ein Payload vorhanden ist, wird die Extension "GEM_ERP_EX_PrescriptionType" verpflichtend in die Communication eingefügt. Weiterhin wird ein Constraint eingeführt: Wenn der Flowtype der Communication "162" entspricht, darf keine payload angegeben werden, andernfalls muss sie vorhanden sein:

extension.where(url = 'https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_EX_PrescriptionType').valueCoding.code = '162' implies payload.empty() or payload.exists()

7.6.1.2.5 Erweiterung der OperationDefinition $close

Die OperationDefinition von $close wird dahingehend erweitert, dass das neue Profil GEM_ERP_PR_MedicationDispense_DiGA als Eingangsparameter akzeptiert wird.

7.6.2 Erweiterungen der Prozessparameter

Das Kapitel 2.1 aus [gemSpec_DM_eRp] wird erweitert.

Das Kapitel 2.4 aus [gemSpec_DM_eRp] wird erweitert.

Erweiterung A_23384-* Prüfung Gültigkeit FHIR Ressourcen

alt:

neu:

Nach der Anforderung wird noch folgende Zeile hinzugefügt:

Die zeitliche Gültigkeit der Versionen des Packages "kbv.itv.evdga" ist in [KBV_ITA_VGEX_TECHNISCHE_ANLAGE_EVDGA] beschrieben.

7.6.3 Gültigkeitszeiträume von DiGA Verordnungen

Erweiterung A_19445-* - FHIR FLOWTYPE für Prozessparameter um die Parameter für Workflow 162

Einfügen des Dokumentes [KBV_ITA_VGEX_TECHNISCHE_ANLAGE_EVDGA] am Ende von gemSpec_DM_eRp unter "3.5.2 Weitere Dokumente"

7.7 Betrieb

7.7.1 Änderungen in der gemKPT_Betr

7.7.1.1 Änderung in 5.3.2.9 Anwendung E-Rezept (PDT50, PDT59)

Hinzufügen des neuen UseCases zur Tabelle Tab_gemKPT_Betr_eRP_S::O/A

7.7.2 Änderungen in der gemSpec_Perf

7.7.2.1 Änderung in 3.2.2.2 Format

Erweiterung der Tabelle 16: Tab_gemSpec_Perf_Berichtsformat_E-Rezept-Fachdienst um den neuen UseCase

7.7.2.2 Änderung in 3.2.3 Bestandsdaten E-Rezept Fachdienst

Erweiterung der Bestandsdatenlieferung mit dem neuen FlowType 162 

8 Dokumentenhaushalt

8.1 Neue Dokumente

Die sind mit den Feature ergebenden Änderungen fließen in die bestehenden Dokumente der Anwendung E-Rezept ein.

Für den neuen Produkttypen CS_E-Rezept_KTR wird ein neuer Steckbrief "Clientsystem-Schnittstelle für E-Rezept: Kostenträger" [gemSST_CS_eRp_KTR_V] eingeführt.

8.2 Übersicht betroffener Dokumente

Für folgende Spezifikationsdokumente ergeben sich Änderungen durch dieses Feature:

• [gemSpec_FD_eRp]
• [gemSpec_DM_eRp]
• [gemSpec_eRp_FdV]
• [gemILF_PS_eRp]
• [gemSpec_IDP_Dienst]
• [gemSpec_IDP_FD]

8.3 Übersicht Produkt- und Anbietertypen

Für folgende Steckbriefe ergeben sich Änderungen durch dieses Feature:

• [gemProdT_eRp_FD_PTV]
• [gemProdT_eRp_FdV_PTV]
• [gemProdT_IDP_Dienst]
• [gemProdT_eRp_AdV]
• [gemAnbT_eRp_FD]
• [gemSST_PS_eRp_verordnend]
• [gemSST_PS_eRp_abgebend]
• neuer Steckbrief: [gemSST_CS_eRp_KTR_V]

9 Anhang A – Verzeichnisse

9.1 Abkürzungen

9.2 Referenzierte Dokumente

9.2.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur.

9.2.2 Weitere Dokumente