Technische Anlage zur elektronischen Verordnung digitaler Gesundheitsanwendungen (e16D) in der Version 0.90

Durch das Wesen der DiGAs müssen die eVerodnungen durch den Patient (§ 361 SGB V folgend) beim jeweiligen DiGA-Hersteller (als sonstigen Leistungserbringer) eingelöst werden.

Dazu muss der Versicherte die entsprechende Webanwendung der DiGA aufrufen oder die entsprechende App der DiGA installieren.

Daher sollte der Versicherte zielgerichtet zur verordneten DiGA geleitet werden, um so den Aufruf bzw. den Download der falschen DiGA zu vermeiden und den der korrekten zu ermöglichen.

Quelle dieser Informationen ist für die Patienten und für alle DiGAs die entsprechende Website des BfArMs (diga.bfarm.de/de/verzeichnis) und dort die jeweilige Detailseite zur verordneten DiGA (für „Selfapy“ als ein beliebiges Beispiel die Seite diga.bfarm.de/de/verzeichnis/01830).

Auf dieser Seite erhält der Patient alle von ihm benötigten Informationen und Verlinkungen:

• Informationen zur DiGA an sich
• Zugang zu den Apple- und Google-Stores bzw. zur Webanwendung der DiGA
• Zugang zu den Informationsseiten der DiGA durch den Hersteller (Hilfe und Support,
  Gebrauchsanweisung, Informationswebsite)

Der Link zur verordneten DiGA sollte daher dem Patienten im Rahmen der Verordnung bereitgestellt werden:

1. über das eRezept (der FHIR-Ressource)
2. über den Ausdruck

Entsprechend sollte:

1. in KBV_PR_EVDGA_HealthAppRequest
   1. neben der PZN der DiGA (in code<span class="error">[x]</span>:codeCodeableConcept.coding.code) sowie
   2. dem Namen des DiGA (in code<span class="error">[x]</span>:codeCodeableConcept.text)
   3. auch der Link zur BfArM-Seite der verordneten DiGA im BfArM-Verzeichnis
   verpflichtend aufgenommen werden, z.B. über „code<span class="error">[x]</span>:codeCodeableConcept.url“
   (oder über einen anderen Knoten)
2. die URL der BfArM-Seite als QR-Code (nicht 2D-Code) auf den Ausdruck mit angedruckt werden.

Der Patient kann dann im Anschluss

1. aus der eRX-App heraus, sowie
2. über das Scannen des QR-Codes

die entsprechende BfArM-Seite der DiGA aufrufen.

Die PVS sollten diese URL entweder aus der DIGA-API ermitteln (sofern diese direkt bereitgestellt wird) oder errechnen (aus dem Basis-Pfad + DiGA-ID). Ebenfalls findet sich diese Information in der DiGA-API des BfArMs.

Die Technische Anlage greift der noch ausstehenden Festlegung des Einlöseprozesses einer digitalen DiGA-Verordnung durch die gematik vor, in dem sie den Weg der Verordnung über die Krankenassen beschreibt:

• „Start des Genehmigungsprozesses bei den Krankenkassen“ (P62-01)
• "Übermittlung der Verordnung „an die Krankenkassen“ (P62-09)
• „um die Verordnung bei den Krankenkassen einzulösen“ (P62-10)
• „Einlösung bei den Krankenkassen“ (P62-11)

Ein Einlöseweg über die Krankenkasse entspricht offensichtlich nicht der gesetzlichen Intension, auf die u.a. das BAS in seinem Rundschreiben vom 21.11.2023 noch einmal explizit hinweist:

www.bundesamtsozialesicherung.de/de/service/rundschreiben/detail/pruefung-der-notwendigkeit-von-verordneten-digitalen-gesundheitsanwendungen-diga-nach-33a-sgb-v/

Es ist daher davon auszugehen, dass die kommende Prozessfestlegung der gematik diesen
Vorgaben folgen wird. Da die finale Prozessdefinition jedoch noch nicht bekannt ist, sollte auf jegliche Prozessdetails in diesem Dokument verzichtet werden.

Die konkreten Vorschläge zur Umformulierung lauten daher:

P62-01

„Auf Wunsch des Versicherten muss die Einlösung einer elektronischen Gesundheitsanwendungen-Verordnung auch ohne Nutzung von digitalen Anwendungen und zusätzlicher Hardware möglich sein.“

„Der Ausdruck stellt keine allein gültige Verordnung dar. Er dient alleinig der alternativen Einlösung einer elektronischen Gesundheitsanwendungen-Verordnung durch den Versicherten.“

P62-09

„Der Ausdruck dient der alternativen Übermittlung der elektronischen Verordnung digitalerGesundheitsanwendungen durch den Versicherten.“

P62-10

„Der aufzudruckende 2D-Code der elektronischen Gesundheitsanwendungen-Verordnung enthält die technischen Informationen (Zugangs-Code), um die elektronischen Gesundheitsanwendungen-Verordnung einzulösen.“

P62-11

„Der Sammeltoken ermöglicht die Einlösung der elektronischen Verordnungen digitaler Gesundheitsanwendungen.“

Die manuelle Angabe einer PZN und des DiGA-Namens als Freitext trägt das Potential von Störungen in der Versorgung durch Fehleingaben. Die DiGA-Daten des BfArM stehen tagesaktuell über die DiGA-API zur Verfügung. Statt dieser Freitexteingabe erscheint es daher sinnvoller auf die Freitexteingabe vollständig zu verzichten und stattdessen P2-010 hinsichtlich der Akzeptanzkriterien folgendermaßen zu überarbeiten:

P2-010 Vollständigkeit und Aktualität der Daten des Produktverzeichnisses

Akzeptanzkriterien:

4. Die Verordnungssoftware muss den nutzenden Ärzt:innen und Psychotherapeut:innen die Möglichkeit bieten, manuell die Aktualisierung der Daten des Produktverzeichnisses auslösen zu können, sodass anschließend auf dem aktuellen Stand gemäß der DIGA-API gearbeitet werden kann.

Die Anforderung verlangt, dass auf Basis der PZN einer früheren DiGA-Verordnung eine erneute Verordnung angelegt werden kann. Eine solche Anforderung macht bei Arzneimitteln Sinn, da sich die PZN bei Folgeverordnungen nicht ändert. Bei DiGA-Verordnungen kann für eine Folgeverordnung jedoch eine andere PZN als bei der Erstverordnung vonnöten sein. Daher sollte P4-320 folgendermaßen überarbeitet werden:

P4-320 Zugriff auf zurückliegende Verordnungen

Den nutzenden Ärzten und Psychotherapeuten muss die Möglichkeit gegeben werden, eine Verordnung auf Basis von zurückliegenden Verordnungen auszustellen.

Begründung:

Zur Vereinfachung des Verordnungsvorgangs muss es möglich sein, auf zurückliegende Verordnungen zugreifen zu können. Dabei muss wahlweise die PZN oder einer der PZNs der DiGA-ID der zurückliegenden Verordnungen in die neue Verordnung übernommen werden können.

Akzeptanzkriterien:

1a. Die Verordnungssoftware muss den nutzenden Ärzten und Psychotherapeuten die Möglichkeit bieten, die PZN aus einer zurückliegenden Verordnung des jeweiligen Patienten in die aktuelle Verordnung zu übernehmen.(sinnvoll, sofern die zurückliegende Verordnung bereits eine Folgeverordnung war)

1b. Die Verordnungssoftware muss den nutzenden Ärzten und Psychotherapeuten die Möglichkeit bieten, alle PZNs inkl. DiGA-Name aus der DiGA-ID einer zurückliegenden Verordnung des jeweiligen Patienten anzuzeigen, und dem Nutzer die Möglichkeit zur Auswahl und Übernahme einer dieser Zeilen in die aktuelle Verordnung zu ermöglichen.

Beispiele:
a.) Verantwortlicher Arzt vs. Ausstellender Arzt: eRP P36-34 vs. EVDGA P35-31
b.) IK-Kostenträger bei BG: eRP P36-38 vs. EVDGA P35-33
c.) Ausstellungsdatum: eRP O36-39 vs. EVDGA O35-34
d.) Alle Anforderungen zum Patientenausdruck (Kapitel 6.2). Die "Sortenreinheit" (DiGA nicht mit anderen Verordnungen gemischt) könnte mit einem Satz im techn. Handbuch eRP erreicht werden.
e.) Betrifft auch Basics wie Schriftart (P62-13)

Die Feldliste sollte nicht doppelt gepflegt werden. Es würde reichen, die DiGA-Spezifika (Felder 81 ff.) zu listen und ansonsten auf das techn. Handbuch eRP zu verweisen.
In der Feldliste gibt es inhaltlich nicht nötige Abweichungen zu den eRP-Vorgaben, z.B. bei Feld 36 "Postleitzahl der Versicherten-Postfachanschrift".

Die Nutzung des entsprechenden Merkmals in P62-12 sollte aus den Arzneimittelstammdaten und
nicht <span class="nobr"><a href="https://www.xxx.xx" class="external-link" rel="nofollow">https://www.xxx.xx^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> erfolgen.

Es ist unklar, welcher Validator bei P35-13 verwendet werden muss.

Es sollte klargestellt werden, warum
„KBV_PR_EVDGA_HealthAppRequest.extension:Unfallinformationen.extension:Unfalltag.value<span class="error">[x]</span>:valueDate“ ein String und kein Datum ist.

Das Constraint „-evdga-angabeUnfalltag“ des Profils „KBV_PR_EVDGA_HealthAppRequest“ sollte
auch in Tabelle 6 abgebildet werden.

Die Bedingung unter P35-25 im Element „Kennzeichen Rechtsgrundlage“ im Profil
„KBV_PR_EVDGA_Composition“ ist nicht identisch mit dem tatsächlich definierten Constraint im
„Profil KBV_PR_EVDGA_Bundle“. Das Constraint „-evdga-angabePatientPLZ“ ist ggf. nicht korrekt.
Der Patient könnte nur eine Postfachadresse haben. Dies sollte auch im Constraint berücksichtigt
werden.