Elektronische Gesundheitskarte und Telematikinfrastruktur

Feature:

E-Rezept: Mehrfachverordnung

    

     

      
Version
      
1.0.1
     
     

      
Revision
      
947494
     
     

      
Stand
      
09.08.2022
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemF_eRp_MVO
     
    

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 ärztlichen und zahnärztlichen Verordnungen für apothekenpflichtige Arzneimittel als Mehrfachverordnung. 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 Leistungserbringer 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. Die Ausführung dieses Dokumentes ergänzen die bisherigen Festlegungen.

1.4 Methodik

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.

Anforderungen

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

Da in dem Beispielsatz „Eine leere Liste DARF NICHT ein Element besitzen.“ die Phrase „DARF NICHT“ semantisch irreführend wäre (wenn nicht ein, dann vielleicht zwei?), wird in diesem Dokument stattdessen „Eine leere Liste DARF KEIN Element besitzen.“ verwendet. Die Schlüsselworte werden außerdem um Pronomen in Großbuchstaben ergänzt, wenn dies den Sprachfluss verbessert oder die Semantik verdeutlicht.

Anforderungen werden im Dokument wie folgt dargestellt:
<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche zwischen Afo-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

In diesem Abschnitt wird das Feature fachlich motiviert und der Mehrwert für Nutzer vorgestellt. Aus diesen Epics und User Stories wird anschließend ein technisches Konzept abgeleitet.

2.1 Mehrfachverordnung

Mehrfachverordnungen sollen die Versorgung mit Arzneimittel für chronisch Kranke erleichtern. Hierfür wurde in § 31 Absatz 1b SGB V die Grundlage geschaffen: „Für Versicherte, die eine kontinuierliche Versorgung mit einem bestimmten Arzneimittel benötigen, können Vertragsärzte Verordnungen ausstellen, nach denen eine nach der Erstabgabe bis zu dreimal sich wiederholende Abgabe erlaubt ist. Die Verordnungen sind besonders zu kennzeichnen. Sie dürfen bis zu einem Jahr nach Ausstellungsdatum zu Lasten der gesetzlichen Krankenkasse durch Apotheken beliefert werden.“

Neben § 31 Absatz 1b SGB V regelt § 4 Abs. 3 AMVV i.V.m. § 2 Abs. 1 Nr. 6a AMVV die gesetzliche Grundlage der Mehrfachverordnungen.

Aus der Mehrfachverordnung ergeben sich Vorteile für Patienten und die Abläufe in Arztpraxen, da die Rezepte für Dauermedikationen im Voraus ausgestellt werden können und somit Wege zur Arztpraxis zum Rezepte abholen entfallen.

2.2 User Stories

Die User Stories beschreiben die Erwartungen der Nutzer für die neuen digitalen Prozesse mit Bezug zur Mehrfachverordnung.

2.2.1 Versicherte

Als Versicherter möchte ich:

• für jedes einzelne E-Rezept aus meiner Mehrfachverordnung eine Apotheke frei auswählen können, damit ich wählen kann, ob ich die einzelnen Rezepte in der gleichen oder in unterschiedlichen Apotheken einlöse.
• erkennen können, dass ein Rezept Bestandteil einer Mehrfachverordnung ist, um meine Abläufe (d.h. Gänge zum Arzt für Abholung Rezepte und Gänge zur Apotheke für Einlösung Rezepte) besser organisieren zu können.
• erkennen können, um das wievielte Rezept einer Mehrfachverordnung es sich handelt, damit ich meine Medikamenteneinnahme sowie die Termine beim Arzt und Apotheker einplanen kann.
• sehen können, wie viele E-Rezepte aus meiner Mehrfachverordnung ich bereits eingelöst habe.
• sehen können, wann ich mein einzelnes E-Rezept aus der Mehrfachverordnung einlösen kann, das heißt den Beginn der Einlösefrist.
• genau sehen können, wie lange jede einzelne Verordnung gültig ist, das heißt das Ende der Einlösefrist. 
• dass ich meine E-Rezepte darüber hinaus wie alle meine anderen Rezepte in meiner E-Rezept-App verwalten kann, um mich nicht mit neuen Abläufen in meiner E-Rezept App oder mit dem Arzt und Apotheker herumschlagen zu müssen.
• dass meine E-Rezept-App mich dabei unterstützt, dass ich das richtige E-Rezept in der Apotheke einlöse, damit ich in der Apotheke keine Zeit damit verschwende, einen ungültigen Token vorzuzeigen z.B. wenn ein E-Rezept erst in der Zukunft eingelöst werden kann.
• dass meine E-Rezept-App mich dabei unterstützt, dass ich auf den ersten Blick erkenne, dass der Beginn der Einlösefrist eines E-Rezeptes erst in der Zukunft liegt. 
• erinnert werden, dass eine Teilverordnung gültig geworden ist, damit ich nicht vergesse, das Rezept einzulösen.
• jedes einzelne E-Rezept einer Mehrfachverordnung löschen können.

2.2.2 Verordnende

Als Verordnender möchte ich:

• dass mein Primärsystem mich dabei unterstützt, eine Mehrfachverordnung auszustellen, so dass ich identische Felder nur einmal ausfülle und mich auf das Ausfüllen der Unterschiede (z.B. Anzahl der einzelnen Rezepte) konzentrieren kann.
• dass mein Primärsystem mich dabei unterstützt, die Einlösefristen für die einzelnen E-Rezepte automatisch zu berechnen und auszufüllen, so dass ich nicht mühsam Termine berechnen muss.
• alle einzelnen E-Rezepte einer Mehrfachverordnung in einem Schritt löschen können, damit ich eventuell auftretende Fehler schnell und unkompliziert korrigieren kann.
• dass mein Primärsystem mich dabei unterstützt, die einzelnen Teilverordnungen einfach und unkompliziert in einem Arbeitsschritt zu signieren.

2.2.3 Apotheker

Als Apotheker möchte ich:

• erkennen können, dass ein Rezept Bestandteil einer Mehrfachverordnung ist.
• sehen können, um das wievielte Rezept einer Mehrfachverordnung es sich handelt.
• jedes E-Rezept einer Mehrfachverordnung einzeln abrufen, beliefern und abrechnen können.
• ein E-Rezept einer Mehrfachverordnung, das mir zugewiesen worden ist, löschen können.
• erkennen können, wenn der Beginn des Einlösezeitraumes einer Verordnung noch nicht erreicht wurde, sodass ich keine unnötige Arbeit mit noch nicht gültigen Rezepten habe.
• wenn mein Patient es sich wünscht, die Zugangsinformationen und den Gültigkeitszeitraum zum Rezept speichern und später (wenn sie gültig werden) abrufen können.

3 Einordnung in die Telematikinfrastruktur

Das Feature der Mehrfachverordnung führt keine neuen Produkttypen oder Komponenten ein. Das Primärsystem der verordnenden und abgebenden Leistungserbringer sowie das E-Rezept-FdV benutzen die Schnittstellen des E-Rezept-Fachdienstes gemäß den Festlegungen für die E-Rezept-Workflow-Typen "160" und "200".

Abbildung 1: Übersicht E-Rezept-Komponenten 

Der Unterschied gegenüber den in der bisherigen Prozessdefinition für den Workflowtype 160 bzw. 200 ausgestellten Verordnungsdaten besteht in der Verschreibung mehrerer Einzelrezepte auf einmal.

4 Fachliches Konzept

Eine Mehrfachverordnung besteht aus mindestens 2 bis maximal 4 Teilverordnungen. Jede Teilverordnung einer Mehrfachverordnung ist ein vollständiges E-Rezept mit QES-signierten Verordnungsdatensatz und E-Rezept-Token. Das bedeutet, dass jede der Teilverordnungen durch den eigenen E-Rezept-Token auch einzeln durch den Versicherten, ggf. in verschiedenen Apotheken, eingelöst werden kann. 

Das Statusmodell für E-Rezepte wird für die Teilverordnungen nicht geändert. Der Versicherte erhält nach der Abgabe für jede Teilverordnung eine eigene Information zur Abgabe (MedicationDispense). Auch die Abrechnung der Apotheke bzw. der Versicherten gegenüber dem Kostenträger erfolgt auf Basis der Teilverordnungen.

Es gibt kein Ersatzverfahren (Muster 16), da Mehrfachverordnungen nur in elektronischer Form vorhanden sind. 

Für Mehrfachverordnungen gibt es keine Ersatzverordnungen. Bei Verlust muss ein Einzelrezept für die verlorene Teilverordnung ausgestellt werden.

Die Mehrfachverordnung ist unabhängig vom Versichertenverhältnis, d.h. anwendbar für GKV- und PKV-Versicherte. 

Gültigkeit der Teilverordnungen einer Mehrfachverordnung

Der Verordnende legt den Beginn des Gültigkeitszeitraumes für jede Teilverordnung im Verordnungsdatensatz fest.

Der Verordnende kann das Ende der Gültigkeitszeitraumes einer Teilverordnung festlegen. Falls das Ende nicht durch den Verordnenden festgelegt wird, dann gilt die Teilverordnung bis 365 Tage nach dem Ausstellungsdatum der Mehrfachverordnung.

Die Abrechnungsmöglichkeit gegenüber den Kostenträgern ist bestimmt durch die Arzneimittel-Richtlinie des G-BA und die Regelungen der ergänzenden Verträge nach § 129 Absatz 5 SGB V in denen der Zeitraum, in dem eine Abrechnung zu Lasten der Krankenkassen möglich ist, festgelegt ist. Bei den Teilverordnungen ist eine Abrechnung gegenüber dem Kostenträger möglich, wenn das E-Rezept innerhalb des Gültigkeitszeitraum beliefert und quittiert wird.

Bis zum Erreichen des Gültigkeitszeitraums ist keine Einsicht für die Apotheke in das E-Rezept möglich. Der Versicherte kann mittels E-Rezept-FdV oder E-Rezept-AdV die E-Rezepte einsehen.

Kürzere Belieferungsfristen nach § 12 Absatz 1 Nummer 1 Buchstabe c BtMVV und den §§ 3a Absatz 4 und 3b Absatz 2 AMVV bleiben unberührt. Das bedeutet, es gibt keine Mehrfachverordnung für Entlassrezepte, BTM-Rezepte und T-Rezepte.

Abbildung 2:  Übersicht Gültigkeit von Teilverordnungen

Löschen und Löschfristen für Teilverordnungen einer Mehrfachverordnung

Es besteht beim Löschen kein Unterschied zu Einzelrezepten. Wenn eine Teilverordnung noch nicht eingelöst wurde, dann kann sie von Arzt, Patient oder Apotheker gelöscht werden.

Für die Teilverordnungen gelten die gleichen Löschfristen wie für Einzelrezepte. D.h. Teilverordnungen werden automatisch 10 Tage nach Ablauf der Gültigkeit oder 100 Tage nach Dispensierung gelöscht.

Ausdruck für den Versicherten

Der Versicherte kann einen Ausdruck für die Teilverordnungen durch den Verordnenden erhalten.

Regelungen für das Erstellen des Ausdrucks für die Teilverordnungen einer Mehrfachverordnung sind in der „Technischen Anlage zur elektronischen Arzneimittelverordnung (E16A)“ [KBV_ITA_VGEX_TECHNISCHE_ANLAGE_ERP] getroffen.

Wenn ein Ausdruck die Daten zu mehrere Teilverordnungen einer Mehrfachverordnung beinhaltet und diese eingescannt werden, dann dürfen die E-Rezept-Token der Teilverordnungen, welche noch nicht ihren Gültigkeitszeitraum erreicht haben, nicht automatisch im AVS gespeichert werden, da der Versicherte das Recht hat, für diese ggf. eine andere Apotheke für das Einlösen auszuwählen. Das Speichern kann auf Wunsch des Versicherten erfolgen.

5 Technisches Konzept

Für jede Teilverordnung einer Mehrfachverordnung wird ein einzelnes E-Rezept erstellt. Im Verordnungsdatensatz wird das E-Rezept als Teil einer Mehrfachverordnung gekennzeichnet (MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen).

Zusätzlich werden u.a. die Informationen

• Nummer des Rezepts der Mehrfachverordnung
  (MedicationRequest.extension:Mehrfachverordnung.extension:Nummerierung.
  value[x]:valueRatio.numerator)
  

• Gesamtzahl der Teilverordnungen in der Mehrfachverordnung
  (MedicationRequest.extension:Mehrfachverordnung.extension:Nummerierung.
  value[x]:valueRatio.denominator)
  

• Start der Gültigkeit
  (MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.
  value[x]:valuePeriod.start)
  

• Ende der Gültigkeit
  (MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.
  value[x]:valuePeriod.end)

angegeben.

Jede Teilverordnung einer Mehrfachverordnung wird im E-Rezept-Fachdienst mit einem eigenen Workflow (Task) verwaltet. Dies ermöglicht den Versicherten und den Apotheken eine separate Verarbeitung jedes E-Rezepts einer Mehrfachverordnung.

6 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 des E-Rezepts, die bestehende Anforderungslage für bereits eingeführte Workflow-Typen, wie bspw. den Prozess der apothekenpflichtigen Arzneimittel (Flowtype=160) bleibt hiervon unberührt.

6.1 Anforderungen an den E-Rezept-Fachdienst

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

6.1.1 POST /Task/<id>/$activate

Die Anforderung "A_22068 - E-Rezept-Fachdienst - Task aktivieren - Ausschluss Mehrfachverordnung" wird storniert.

Hinweis: Ist das Gültigkeitsende-Datum  (MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end) nicht angegeben, kann die Teilverordnung bis zum Tag [Ausstellungsdatum + 365] eingelöst und für E-Rezepte des Workflow-Typen 160 zu Lasten der GKV abgerechnet werden.

6.1.2 POST /Task/<id>/$accept

6.2 Anforderungen an das E-Rezept-FdV

Für das E-Rezept-FdV ergeben sich keine Änderungen für die Nutzung der Operationen des E-Rezept-Fachdienstes.

Durch eine geeignete Gestaltung der Benutzerführung im E-Rezept-FdV werden die User Stories des Versicherten (siehe 2.2.1 Versicherte ) erfüllt.

6.3 Anforderungen an das Primärsystem der verordnenden LEI

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

Die Mehrfachverordnungen sind im Rahmen des Dokuments „Technische Anlage zur elektronischen Arzneimittelverordnung (E16A)“ [KBV_ITA_VGEX_TECHNISCHE_ANLAGE_ERP] als Anforderungen an Softwarehersteller definiert. Die Umsetzung ist als Bestandteil des Zertifizierungsverfahrens „Verordnung von Arzneimitteln“ der KBV nachzuweisen.

Die Angabe des Endes der Einlösefrist der Teilverordnung ist optional.

6.4 Anforderungen an das Primärsystem der abgebenden LEI

Wenn ein AVS eine Teilverordnung abruft, deren Einlösezeitraum noch nicht erreicht ist, dann liefert der E-Rezept-Fachdienst einen Fehler 403. Im OperationOutcome der Fehlermeldung liefert der E-Rezept-Fachdienst das Datum des Beginns der Einlösefrist.

Wenn Datamatrix-Codes einer Mehrfachverordnung von einem Ausdruck eingescannt werden, dann dürfen die E-Rezept-Token der Teilverordnungen, welche noch nicht ihren Gültigkeitszeitraum erreicht haben, nicht automatisch im AVS gespeichert werden, da der Versicherte das Recht hat, für diese ggf. eine andere Apotheke für das Einlösen auszuwählen.

Ein Speichern des E-Rezept-Token kann auf Wunsch des Versicherten erfolgen.

6.5 Daten- und Informationsmodell

6.5.1 Fast Healthcare Interoperability Resources

Es ergeben sich keine Änderungen am bestehenden FHIR-Datenmodell https://simplifier.net/erezept/kbvprerpprescription .

6.5.2 Erweiterung der Prozessparameter

Die nachfolgenden Änderungen werden in das Dokument [gemSpec_DM_eRp] übernommen.

6.6 Datenschutz und Sicherheit

Es werden im Zuge der Mehrfachverordnung nur bereits existierende Operationen nachgenutzt. Die Einführung von Mehrfachverordnungen erfordert keine zusätzlichen – über das Maß der bereits spezifizierten Datenschutz- und Sicherheitsanforderungen hinausgehende – Anforderungen an die Produkttypen des E-Rezepts.

Der Fachdienst prüft – soweit möglich – die fachlichen Vorgaben an Mehrfachverordnungen aus [EXT_ITA_VGEX_Anforderungskatalog_AVWG].

Die Primärsysteme der verordnenden LEI müssen die fachlichen Anforderungen zu Mehrfachverordnungen aus [EXT_ITA_VGEX_Anforderungskatalog_AVWG] erfüllen.

6.7 Betrieb

Es werden im Zuge der Mehrfachverordnung nur bereits existierende Operationen nachgenutzt. Daraus resultieren keine zusätzlichen betrieblichen Anforderungen im Rahmen der Mehrfachverordnung.

7 Dokumentenhaushalt

7.1 Übersicht betroffener Dokumente

Dieses Dokument beschreibt das Feature als geschlossene funktionale Einheit. Mit der Freigabe zur Umsetzung werden die hier getroffenen Festlegungen in einem nachgelagerten Wartungsrelease in die jeweiligen Produkt- und Anbietertypspezifikationen überführt.

7.2 Übersicht Produkt- und Anbietertypen

Die hier aufgelisteten Anforderungen richten sich an die Produkt- und Anbietertypen

• E-Rezept-Fachdienst
• Primärsystem der verordnenden LEI
• Primärsystem der abgebenden LEI

8 Anhang A – Verzeichnisse

8.1 Abkürzungen

8.2 Referenzierte Dokumente

8.2.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert; Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument jeweils gültige Versionsnummern sind in der aktuellen, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

8.2.2 Weitere Dokumente