Technische Anlage eRezept

Gemäß § 355 SGB V wird SNOMED CT zur Darstellung klinischer Inhalte als Basisterminologie für die elektronische Patientenakte bereitgestellt. Dies wird im ePA Medikationsplan/-liste umgesetzt und jeweils alternativ / zusätzlich eine Kodierung mit SNOMED CT ermöglicht. Im Sinne der Harmonisierung und der Unterstützung des Datenflusses in die ePA sollte dies ebenfalls auch schon im eRezept ermöglicht werden.

Für den Aufbau des NCPeH-Fachdienst – Übermittlung von ePrescription/eDispensation Country A – ist es erforderlich, dass Inhalte, die ein Arzneimittel beschreiben, strukturiert und kodiert übermittelt werden. Dies betrifft insbesondere Wirkstoff, Wirkstärke und Einheit und Darreichungsform, da nicht davon auszugehen ist, dass ein auf dem deutschen Markt verfügbares Arzneimittel auch im Ausland verfügbar ist. Durch diese sprachunabhängigen Strukturen wird die abgebende Apotheke im Ausland in die Lage versetzt, ein adäquates Arzneimittel zu substituieren.

In Bezug auf die Harmonisierung mit europäischen Vorgaben möchten wir die folgenden Anpassungen vorschlagen:

Wirkstoff-Verordnung - Profil <span class="nobr"><a href="https://simplifier.net/erezept/kbv_pr_erp_medication_ingredient" class="external-link" rel="nofollow">https://simplifier.net/erezept/kbv_pr_erp_medication_ingredient^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> :

Wirkstoffkodierung und Displayname -
Medication.ingredient.item<span class="error">[x]</span>:itemCodeableConcept.coding:ask :
Eine Wirkstoffverordnung kann derzeit aufgrund fehlender kodierter Daten ins europäische Ausland nicht übermittelt werden. Um dies zu unterstützen, muss die Darstellung des Wirkstoffs in kodierter Form erfolgen. Die Erfassung von Wirkstoffen mit ASK-Nummer muss daher verbindlich vorgegeben werden (Kardinalität 1:1). Zusätzlich zum Code sollte die Übermittlung des code display (Medication.ingredient.item<span class="error">[x]</span>:itemCodeableConcept.coding:ask.display ermöglicht werden.
Ggf. könnte eine Vereinbarung getroffen werden, dass diese strukturierte Information zwar technisch elektronisch mitgeführt wird, jedoch im Rezeptausdruck nicht dargestellt wird.

Wirkstoffmengen Einheit -
Medication.ingredient.strength.numerator.unit :
Um europäische Kompatibilität zu unterstützen., sollte die Notation der Wirkstoffmengen-Einheit strukturiert in UCUM erfolgen und nicht als Freitext-Information. Dies kann bei nicht-standardisierter Schreibweise zu Übermittlungs-Problemen ins EU-Ausland führen. Um die Erfassung über Displaynamen zu unterstützen, könnte auf die auf dem Terminologieserver bereitgestellte Werteliste <span class="nobr"><a href="https://terminologien.bfarm.de/CodeSystem-ucum-common-units-translation-de-de-1-5-0.download.html" class="external-link" rel="nofollow">https://terminologien.bfarm.de/CodeSystem-ucum-common-units-translation-de-de-1-5-0.download.html^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> verwiesen werden (in Q1 2025 werden dort jedoch noch Anpassungen erfolgen).

Darreichungsform -
Medication.form:
Eine Wirkstoffverordnung kann derzeit aufgrund fehlender kodierter Daten ins europäische Ausland nicht übermittelt werden. Um dies zu unterstützen, muss die Darreichungsform erfasst werden. Auch im Sinne der Arzneimitteltherapiesicherheit muss die Erfassung der Darreichungsform verpflichtend erfolgen (Kardinalität 1:1).
Um die europäische Übermittlung zu unterstützen muss die Übermittlung der Darreichungsform kodiert erfolgen. Die in Europa konsentierte Werteliste für Darreichungsformen sind die EDQM Standard Terms Pharmaceutical form. Dies ist auch für die Datenmodellierung zum elektronischen Medikationsplan/-liste berücksichtigt (s. Medication.form.coding:edqm).

Amount - Medication.amount.numerator.extension:Packungsgroesse :
Eine Wirkstoffverordnung kann derzeit aufgrund fehlender kodierter Daten ins europäische Ausland nicht übermittelt werden. Für die Datenübermittlung ins europäische Ausland ist verpflichtend eine Angabe zur Packungsgröße erforderlich. Die Kardinalität der Packungsgrößen-Menge müsste daher als 1:1 gesetzt werden.

Unit -
Medication.amount.numerator.unit:
Eine Wirkstoffverordnung kann derzeit aufgrund fehlender kodierter Daten ins europäische Ausland nicht übermittelt werden. Für die Datenübermittlung ins europäische Ausland ist verpflichtend eine Angabe zur Packungsgröße erforderlich. Die Kardinalität der Packungsgrößen-Unit müsste daher als 1:1 gesetzt werden.
Für die Übermittlung ins europäische Ausland ist eine Kodierung mit dem System „EDQM Standard Terms Container bzw. unit of presentation“ (EHDSMedication.item.packageType) erforderlich.

P36-38 => Aufnahme der DGUV-Kostenträgerdatei für Angabe einer alternativen Kostrenträger IK die aus diesem Verzeichnis stammen muss.
(<span class="nobr"><a href="https://www.dguv.de/dale-uv/weitere_datenaustauschverfahren/informationen-_zu_300ama/index.jsp" class="external-link" rel="nofollow">https://www.dguv.de/dale-uv/weitere_datenaustauschverfahren/informationen-_zu_300ama/index.jsp^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>)

Auf Seite 71 des Technischen Handbuches DiMus sind Beispiele für BG-Fälle, die nicht passen. Das Kostenträger-IK ist in den Beispielen 2 b) und 2 c) leer, was nach der Definition im ERP-Dokument nicht sein dürfte. Dort wird eine Referenz auf die Liste der gültigen DGUV-Kassen angegeben. Diese sollte im ERP-Dokument referenziert werden, so dass das Kostenträger-IK in der „Liste Stammdaten Unfallversicherungsträger (UVT)“ auf der Seite gelistet sein muss. Leider funktioniert der Link nicht und müsste angepasst werden.
Generell wurde das eVerordnungs-Profil für alle sonstigen Kostenträger geöffnet, wenn diese eine eGK herausgegeben haben. In diesem Fall muss auch ein IK existieren, das sonst keine Abrechnung erfolgen kann. Das sollte auch über die Constraints sichergestellt werden.

In den technischen Anlagen ist das Feld KVK-Versichertennummer gestrichen aber in dem Profil nach wie vor ein eigenes Feld.
Wie wird mit dem Feld KVK-Versichertennummer im E-Rezept-Kontext umgegangen?

Die am FRT (20231011) erörterte
Schärfung der Profile wurde nicht umgesetzt.

Angabe einer verantwortl. Person (attester) mit LANR, wenn der Arzt in Weiterbildung als Ausstellender (author) keine LANR enthält.

Die Angabe von Dosierungen sind entweder als Freitext oder strukturiert vorzunehmen,
Warum wird die Ausgabe von strukturierten Dosierungen auf dem Ausdruck des Patienten nicht abgebildet?
Wie wird die Ausgabe von strukturierten Dosierungen in der Darstellung (Stylesheet) für den Arzt abgebildet? Wird ein Sylesheet zur Verfügung gestellt?

DIe unterschiedlichen Angabearten sind nicht eindeutig definiert.
So ist z.B. die Angabe des Dosierungskennzeichen nicht zwingend vorgeschrieben.
Auch die Unterscheidung der Medication und notwendigen Angabe als freitxt oder patientinstruction (Rezeptur) wird nicht kontrolliert.

Die übergreifende Nutzung solcher Strukturen sollte Kernprofilen folgen.

(siehe Arbeitskreis IOP "Governace für Kernprofile")

Die Extention ist ohne Angabe eines system des Identifier auf ihre Ausprägung begrenzt.

Hier könnte man Konzeptionell eine zukünftige Erweiterbarkeit (slicing) betrachten. Auch die technische Umsetzung ist mit Angabe eines Systems generischer und nicht strikt auf diesen Fall begrenzt.

KP36-04
Bitte um Aufnahme eines Hinweises, dass mit den alten Profilen (1.1.0) Sonstige Kostenträger (insb. BPOL) nicht funktionieren.

Die Verwendung einer SNOMED-Codierung für Medication.ingredient.item<span class="error">[x]</span>:itemCodeableConcept.coding:snomed ist nicht vorgesehen und explizit untersagt. Gleichzeitig ist im eMP-Profil für dasselbe Element must support festgelegt. Dadurch können Wirkstoffe in einer eMP-Verordnung mit anschließender Ausstellung eines E-Rezepts nicht einheitlich kodiert werden. Dies führt im Primärsystem zu einem generell unabhängigen bzw. isolierten Verordnungsprozess, der dem digital-gestützten Medikationsprozess widersagt.

Die textuelle Angabe einer Dosierung sollte zunächst der Standard bleiben. Erst wenn feste Belegungsvorgaben im FHIR-Profil für bekannte Dosierungen erarbeitet wurden, sollte die strukturelle Angabe einer Dosierinformation erfolgen. Daher sollte .text ein MS erhalten und die weiteren Elemente nicht mit MS belegt, aber auch nicht verboten werden, um sie zukünftig verwenden zu können.

Der Constraint -erp-geburtsdatumPatient enthält die Verwendung der FHIR-Path Funktion lowBoundary. Hierzu haben wir folgende Kommentare
Diese Funktion findet sich nicht in der Spezifikation für R4: <span class="nobr"><a href="https://hl7.org/fhir/R4/fhirpath.html" class="external-link" rel="nofollow">https://hl7.org/fhir/R4/fhirpath.html^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> und daher gilt ggf. die Annahme, dass Validierungstolls diese Funktion nicht entsprechend umgesetzt haben
Die Funktion mit der Funktionssignatur lowBoundary(Integer) ist nicht in R5 enthalten. Gleiche Annahmen wie in Punkt 1.
Die Funktion mit Funktionssignatur lowBoundary(Integer) ist in einem Vorab-Preview ersichtlich <span class="nobr"><a href="https://build.fhir.org/ig/HL7/FHIRPath/#lowboundaryprecision-integer-decimal--date--datetime--time" class="external-link" rel="nofollow">https://build.fhir.org/ig/HL7/FHIRPath/#lowboundaryprecision-integer-decimal--date--datetime--time^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>
In dem CI-Build von FHIR ist die Funktion außerdem als STU (Standard for Trial Use) gekennzeichnet.
Daher die Empfehlung diese Funktion in R4 nicht einzusetzen.

Beispielsweise KBV_PR_ERP_Medication_PZN. Vergleiche EPAMedication Profile:

Für folgende Felder wurde die Angabe einer strukturierten Einheit gestrichen (0..0):

Medication.ingredient.strength.numerator
Medication.ingredient.strength.denominator
Medication.amount.numerator
Medication.amount.denominator
Im Rahmen des integrierten Verordnungsprozesses der Erstellung einer Verordnung und der Eintragung in die eML, ist die Angabe der strukturierten Einheit verpflichtend.

Daher sollten die Verordnungsprofile nicht die Angabe der entsprechenden Felder verbieten, da dadurch die Daten weder in der ePA gespeichert noch in der eML dargestellt werden können.

Wie auch schon am FHIR-Runden Tisch besprochen ergeben sich jetzt in der Implementierung Probleme bei Verwendung von zweistelligen Versionsnummern in Referenzen (meta.profile) und der Angabe von dreistelligen Versionen in den StructureDefinitions.

Die Gefahr besteht, dass Tooling, wie z.B. Validatoren oder Libraries mit der Auflösung der Version nicht umgehen können.

StructureDefinition.version ist in R4 nur ein String, der unserer Auffassung eindeutig matchen muss, da insbesondere folgender Satz in der Spezifikation zu dem Feld zu finden ist:

There is also no expectation that versions can be placed in a lexicographical sequence.

Daher sollte auf meta.profile Versionen keine Logik implementiert werden.

R5 und R6 ermöglichen die Angabe von StructureDefinition.versionAlgorithm und damit auch die Möglichkeit Versionen algorithmisch aufzulösen.

ref:

<span class="nobr"><a href="https://hl7.org/fhir/r4/structuredefinition-definitions.html#StructureDefinition.version" class="external-link" rel="nofollow">https://hl7.org/fhir/r4/structuredefinition-definitions.html#StructureDefinition.version^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> <span class="nobr"><a href="https://build.fhir.org/structuredefinition-definitions.html#StructureDefinition.version" class="external-link" rel="nofollow">https://build.fhir.org/structuredefinition-definitions.html#StructureDefinition.version^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>
Daher sollte aus unserer Sicht die Angabe von StructureDefinition.version zweistellig erfolgen und der Vergleich von verschiedenen Versionen von verschienen Patch-Releases über StructureDefinition.date erfolgen.

Um eine internationale Übersetzung der Darreichungsform zu ermöglichen, müssen folgende Angaben zusätzlich zur KBV-Darreichungsform angegeben werden können:

Die Erfassung von EQDM sollte optional sein.
Die Erfassung von SNOMED sollte optional sein.
Die ausschließliche Angabe der KBV-Darreichungsform ist aus unserer Sicht nicht ausreichend.

Betrifft: KBV_PR_ERP_Medication_PZN

Die strukturierte Angabe von Stückzahl und Einheit muss zusätzlich zur Freitextangabe der Packungsgröße erfolgen, da sonst außerhalb Deutschlands nicht eindeutig ist, welche Packungsgröße gemeint ist.

Eine Übersetzung der Bezeichnungen N1/2/3 durch das BfArM ist im europäischen Kontext nicht eindeutig möglich. Daher sollte die strukturierte Angabe der Einheit mittels .system und .code nicht untersagt werden.

Zukünftig muss die Möglichkeit bestehen, .value anzugeben, um gegebenenfalls Reichweitenberechnungen durchführen zu können.

Vielen Dank für die Ermöglichung, am Kommentierungsverfahren teilnehmen zu können.

Betrifft: KBV_PR_ERP_Medication_PZN

Zukünftig sollte die Angabe des ASK Code verpflichtend gemacht werden, um strukturierte Wirkstoffe für dgMP und europäischen Kontext übermitteln zu können.

Die Daten hierzu könnten aus der BfArM Referenzdatenbank kommen.

Dieser Kommentar ist als Hinweis für die zukünftige Entwicklung zu sehen.

Grundsätzlich begrüßen wir die Möglichkeit, die Dosierung im E-Rezept strukturiert angeben zu können. Allerdings ist der Start mit einer komplexen FHIR-Struktur nicht sinnvoll, wenn klar definierte Regeln für die Anwendung und die Überführung der strukturierten Angabe in einen menschenverständlichen Text fehlen. Wir schlagen die Definition und Abstimmung eines Algorithmus vor, der eine einheitliche Umwandlung der strukturierten Daten in menschenverständliche Angaben durch alle betreffenden Systeme (Primärsysteme, E-Rezept- und EPA-App, EPA-Aktensystem (eML-Erzeugung)) ermöglicht. Nur dann kann die Dosierung sowohl beim Arzt als auch in der Apotheke und insbesondere vom Patienten gleich verstanden werden. Dies ist auch für den Ausdruck eines BMP relevant. Wird dies nicht berücksichtigt, sind Interpretationsprobleme und Übersetzungsfehler zu erwarten, die zu einem erhöhten Aufwand in der Apotheke und vermehrten Rückfragen beim Verordner führen werden. Für den Patienten ergibt sich ein AMTS-Risiko, wenn er ein Arzneimittel aufgrund einer nicht korrekt angezeigten Dosierung in der E-Rezept- oder ePA-App falsch einnimmt. Ohne ein entsprechendes Regelwerk zur Nutzung der strukturierten Dosierungsangabe kann der neuen Funktion nicht zugestimmt werden.

Der Streichung des Felds Gebrauchsanweisung bzw. der Umwandlung in das Feld Anwendungshinweis, in dem beliebige Anwendungshinweise enthalten sein können, kann nicht zugestimmt werden. Die AMVV fordert explizit die Angabe einer Gebrauchsanweisung bei der Verordnung einer Rezeptur. Daher ist auch ein dediziertes Feld für die Angabe der Gebrauchsanweisung erforderlich. Anderenfalls können sich Schwierigkeiten bei der Interpretation des Felds ergeben, die ggf. zu Rückfragen der Apotheke beim Arzt führen.

Für dieses Feld gibt es keine Vorgabe in der AMVV. Sofern die Aufnahme in die elektronische Verordnung erfolgt, muss sichergestellt werden, dass die Information ausschließlich aus den Preis- und Produktangaben nach § 131 SGB V entnommen wird und manuell nicht verändert werden kann. Die Beschreibung ist entsprechend zu formulieren.
Vorschlag: "Dieses Feld enthält die Wirkstärkeneinheit gemäß der Preis- und Produktangaben nach § 131 Abs. 4 SGB V."

Für dieses Feld gibt es keine Vorgabe in der AMVV. Sofern die Aufnahme in die elektronische Verordnung erfolgt, muss sichergestellt werden, dass die Information ausschließlich aus den Preis- und Produktangaben nach § 131 SGB V entnommen wird und manuell nicht verändert werden kann. Die Beschreibung ist entsprechend zu formulieren.
Vorschlag: "Dieses Feld enthält die Wirkstärke des Wirkstoffs gemäß der Preis- und Produktangaben nach § 131 Abs. 4 SGB V. Die Angabe erfolgt als Wirkstoffmenge /Bezugsgrößenmenge. Die zugehörige Einheit ist im Feld "Wirkstärkeneinheit" anzugeben."

Für dieses Feld gibt es keine Vorgabe in der AMVV. Sofern die Aufnahme in die elektronische Verordnung erfolgt, muss sichergestellt werden, dass die Information ausschließlich aus den Preis- und Produktangaben nach § 131 SGB V entnommen wird und manuell nicht verändert werden kann. Die Beschreibung ist entsprechend zu formulieren.
Vorschlag: "Dieses Feld enthält den Wirkstoffnamen gemäß der Preis- und Produktangaben nach § 131 Abs. 4 SGB V."

Für dieses Feld gibt es keine Vorgabe in der AMVV. Sofern die Aufnahme in die elektronische Verordnung erfolgt, muss sichergestellt werden, dass die Information ausschließlich aus den Preis- und Produktangaben nach § 131 SGB V entnommen wird und manuell nicht verändert werden kann. Die Beschreibung ist entsprechend zu formulieren. Vorschlag:
"Dieses Feld enthält die ASK-Nummer (Arzneistoffkatalog-Nummer) des Wirkstoffs gemäß der Preis- und Produktangaben nach § 131 Abs. 4 SGB V."

Mit der Aufnahme von Wirstoff und Wirkstärke im Verordnungsdatensatz sind diese Felder auch in der Beschreibung des Elements "ID des Produkts" zu ergänzen. Vorschlag:
"… Angaben Handelsname, Wirkstoff, Wirkstärke, Darreichungsform, Packungsgröße usw. entstammen den Preis- und Produktangaben nach § 131 Abs. 4 SGB V."

Die Bedingung für die Angabe einer Dosierung ist widersprüchlich.

Alle Arzneimittel, bei deren Verordnung das Feld Verschreiber-ID verwendet werden darf, sind explizit zu nennen, um einer falschen Verwendung des Felds möglichst vorzubeugen.

Die formulierte Bedingung passt nicht für PKV-Versicherte, da diese keine eGK erhalten.

Sehr geehrte Damen und Herren,

wenn ich es richtig verstehe, ist im Bereich dosageInstruction.timing ein typischer Anwendungsfall komplizierterer Anwendungsschemata nicht abgebildet.

So gibt es gerade in der Cortisontherapie oftmals Dosierungen die mit einer Verordnunung / Packung abgebildet werden können, aber je nach Therapie-Tag eine unterschiedliche Anzahl von Tabletten(-teilen) bzw. eine anders nur durch mehrere Packungen abbildbare Stufentherapie vorschreiben.

z.B.
1.-3. Tag 2 Tabletten
4.-6. Tag 1 Tablette
7.-9. Tag 0,5 Tabletten
...
Abbildbar mit genau einer Packung (die ist nach einem Durchlauf leer).

Diese zugegebenermaßen komplexe Dosierungsanweisung ist (soweit ich die Spezifikation richtig verstehe) im vorliegenden Profil nicht strukturiert darstellbar.
Gerade bei solchen komplexen Anweisungen ist eine Unterstützung für den Patienten jedoch essentiell.

Ich bin mir nicht sicher, in wie weit man das hier am Besten modellieren kann - eventuell ist eine Änderung der timing Kardinalität von 0..1 zu 0..* verbunden mit einer Reihenfolge der timing-Angaben und Mengenangabe in dieser Zeit eine Möglichkeit?

Vielen Dank und mit freundlichen Grüßen

Tobias Kast

Sehr geehrte Damen und Herren,

die Rezeptierdaten PZN-Verordnung werden ergänzt um die verpflichtende Angaben von mindestens einem Inhaltsstoff (1..n), die nicht verpflichtend codiert angegeben werden müssen, sondern auch als Freitext angegeben werden können.

Wenn ein im Freitext angegebener Wirkstoff/Inhaltsstoff nun nicht der PZN entspricht;

• Liegt eine Unklare Verordnung vor, der Apotheker muss Rücksprache mit den Arzt halten, welches von beiden nun der Therapie entspricht. Sie ist also bei einer Abweichung nicht belieferbar.
• Muss der Apotheker verpflichtend entweder eine korrigierte Verordnung vom Arzt anfordern, oder eine Rücksprache mit dem Arzt abrechnungssicher Codieren und Dokumentieren um gegenüber den Kostenträgern belegen zu können "in dem Freitextfeld Inhaltsstoff steht zwar etwas, das nicht zur Abgabe passt, aber ich habe Rücksprache mit dem Arzt (! explizit der Arzt ist der Ansprechpartner !) gehalten, es soll wirklich die PZN abgegeben werden / ich soll etwas passendes abgeben zum Freitext-Wirkstoff".

Zumindest wäre eine verpflichtende Befüllung dieser Freitextfelder aus einer Datenbank ohne händische Eingabemöglichkeit in die Anforderungen aufzunehmen.

Vielen Dank für die Erwägung einer Änderung und mit freundlichen Grüßen

Tobias Kast

Die ID19c wurde im Dokument KBV_ITA_VGEX_Technische_Anlage_ERP.pdf gestrichen, ist aber im KBV_ITA_VGEX_Technisches_Handbuch_DiMus.pdf weiterhin aktiv. Ist dies so korrekt und gewollt, und soll damit nur eine Verwendung beim e-Rezept unterbunden werden?

In der Technischen Anlage ERP sowie im Technischen Handbuch DiMus wird für die ab 01.10.2025 neu anzuwendenden FHIR-Profil-Versionen die "1.2.0" angegeben. In den Beispielen ist diese zweistellig mit "1.2" angegeben. Wir gehen aktuell davon aus, dass die zweistellige Versionsangabe stimmig ist. Falls dem so ist, sollte dies auch in den Dokumenten angepasst (vereinheitlicht) werden.