Technische Anlage eRezept in der Version 1.20

In der Beschreibung fehlt die Gebrauchsanweisung bei Rezepturen.
Es sollte eine Bedingung aufgenommen werden, dass bei der Verordnung einer Rezeptur das Kennzeichen Dosierung nicht "false" sein darf, da die AMVV für die Gebrauchsanweisung bei Rezepturen nicht vorsieht, statt deren Angabe in der Verordnung auf die Mitgabe einer schriftlichen Gebrauchsanweisung oder eines Medikationsplans zu verweisen.

Da ID 128 gestrichen wurde, passen die Bedingungen nicht mehr für Rezepturen. In der Technischen Anlage sollte mindestens an einer Stelle eindeutig dargestellt werden, wie die Gebrauchsanweisung bei der Verordnung einer Rezeptur anzugeben ist.

Die erste Bedingung sollte um "Kategorie" gleich "02" ergänzt werden, da es sich bei E-T-Rezepten ausschließlich um Arzneimittel handeln kann und somit die AMVV hinsichtlich der Dosierungsangabe einzuhalten ist.

Kann dieses Feld auch für die Aufnahme eines Hinweises auf schriftliche Vorgaben für den Fall verwendet werden, dass dem Patienten schriftliche
Vorgaben zur Abgabe oder zum Überlassen zum unmittelbaren Verbrauch des Substitutionsmittels übergeben wurden (siehe § 9 Abs. 1 Nr. 5 BtMVV)?

Muss die Regel, dass bei E-T-Rezepten der Typ der ausstellenden Person nicht Kategorie 02 = Hebamme sein darf, nicht auch für E-BtM-Rezepte gelten?

Wir sehen von einer Kommentierung der Einführung strukturierter Dosierungsanweisungen ab und verweisen auf das laufende Abstimmungsverfahren von HL7 Deutschland in diesem Kontext.

Im Kontext des sozialen Entschädigungsrechtes (SER) sollte eine Prüfung auf den erforderlichen Zuzahlungsstatus (1) und der Personengruppe (06) erfolgen.

Warum ist die Bedingung der Feld-ID 41 ist nicht als Prüfung umgesetzt?
Sollte nicht auch die Arzneimittelkategorie 01 (BtM) ausgeschlossen werden?

Neben der Angabe einer eventuell erforderlichen Verschreiber-ID (Feld-ID 155) existiert auch die eventuelle Notwendigkeit einer Patienten-ID.
Sollte hier nicht auch ein extra Feld aufgenommen werden? Wird der Arzt, durch die Erfordernis der Patienten-ID, das Vorhandensein bei Ausstellung prüfen?

Changelog: KBV_PR_ERP_PracticeSupply

Betaeubungsmittel.extension:ErgaenzendeAngabenSubstitutionsmittel is set to 0..0,
since substitute medication may not be prescribed as an outpatient requirement.

Why is this substitution remark under practice supply? Does it apply to all BTM prescriptions created or only for practice supply?

File: Beispiel_66_Rezeptur_BtM

<extension url="ErgaenzendeAngabenSubstitutionsmittel">
<valueString value="Einnahme ab dem 23.05.2025" />
</extension>

What means here substitution? Replacing one medication with another? Or is just additional information that the practitioner can add.

Der elektronische Medikationsplan (eMP) in der elektronischen Patientenakte (ePA) soll sich gemeinsam mit dem E-Rezept effizient in einen Versorgungsprozess - den digital gestützten Medikationsprozess (dgMP) - integrieren.

1. Zum Hintergrund (Auszug aus dem Fachkonzept dgMP gemäß Vorveröffentlichung am 15.07.2025):

Zum Verständnis des Konzepts <span class="error">[des eMP in der ePA 3.1.2]</span> sind folgende Leitgedanken zu verstehen:
Das Ergebnis der Medikationsplanung ist eine therapeutische Entscheidung. Zu solchen Entscheidungen gehört die Aufnahme einer Therapie, die Entscheidung für ihre Fortführung, jegliche Änderungen an sowie die Beendigung von einer bestehenden Therapie. Ein konsequent geführter Medikationsplan bildet all diese Entscheidungen ab und verschafft so dem Anwender einen klaren Blick auf die aktuelle Arzneimitteltherapie.
In der Medikationsplanung werden Entscheidungen getroffen, die über das einzelne Präparat hinaus gehen. Daher ist der Medikationsplan dem Verordnungs- und Abgabegeschehen und entsprechend der eML übergeordnet. Jede Entscheidung, die im eMP erfasst wird, muss sich jedoch notwendigerweise auf ein konkretes Präparat beziehen, um umgesetzt werden zu können. Daraus ergibt sich ein direkter inhaltlicher Bezug zwischen eMP, E-Rezept und eML: Formal ist die Verschreibung und Abgabe, die über das E-Rezept in der eML erfasst wird, das Ergebnis der Medikationsplanung und damit des eMP. Diese Beziehung muss im digital gestützten Medikationsprozess abgebildet werden.

2. Mehrwert eines eMP-Identifiers:
Die Einführung eines eMP-Identifiers erlaubt es, therapeutische Entscheidungen, die ein Arzt oder Apotheker trifft, konsequenter im eMP mit abzubilden, da der eMP besser in die bestehenden Prozesse integriert werden kann. Beispielsweise:

Wird ein E-Rezept ausgestellt, das einen eMP-Identifier trägt, kann die abgebende Apotheke nachvollziehen, wie sich das rezeptierte Arzneimittel in den Medikationsplan integriert. Wird hingegen ein E-Rezept ohne eMP-Identifier ausgestellt, kann die abgebende Apotheke prüfen, ob und wie der Medikationsplan durch sie aktualisiert werden sollte. Auch AMTS-Prüfungen werden zuverlässiger, da eine die therapeutische Intention beteiligter Ärzte und Apotheker transparenter wird.

Wird aus einem lokalen Verordnungsmodul oder Medikationsplan im Primärsystem eine Folgeverordnung ausgestellt, deren eMP-Identifier lokal persistiert wurde, kann durch diese Referenzierung die Aktualisierung des Medikationsplans durch den Leistungserbringer ausgelöst werden. Andersrum kann einem Leistungserbringer bei Verordnungen/Abgaben ohne eMP-Identifier angeboten werden, einen eMP-Eintrag für dieses Arzneimittel zu erstellen.

3. Vorgeschlagene Umsetzung des eMP-Identifiers: Legt ein Leistungserbringer einen eMP-Eintrag an, um ein Medikament auf den Medikationsplan aufzunehmen, wird der eMP-Identifier durch den ePA Medication Service erzeugt. Dieser FHIR-basierte eMP-Identifier referenziert den eMP-Eintrag eindeutig. Die Verknüpfung eines eMP-Eintrags mit einer Verschreibung erfolgt durch die primärsystemseitige, optionale Übergabe des eMP-Identifiers an das E-Rezept. Der E-Rezept-Fachdienst gibt bei der nachfolgenden Übergabe der Verschreibung an den ePA Medication Service diese optional vorhandene Referenz ebenso mit. Intern erzeugt der ePA Medication Service bei Erhalt der Verschreibung eine Medikationsinformation für den entstehenden eML-Eintrag und verknüpft diesen mit dem assoziierten eMP-Eintrag.

4. Beispielhaftes FHIR Objekt:

{
"resourceType": "MedicationRequest",
// ...
"basedOn": [
{
"identifier": {
"system": "https://gematik.de/fhir/sid/emp-identifier",
"value": "8cc8e04b-6df7-43b5-b847-508268e95ba7"
}
}
],
// ...
}

Sollte das FHIR-Objekt durch die Formatierung nicht richtig dargestellt werden, kann dieses gerne auf anderem Wege bereitgestellt werden.

Herzlichen Dank!

Neben dem eigentlich Verordnungs- und Abgabeprozess, landen die eRezepte des Arztes auch in der eML der ePA und dienen dort der aktuellen und langfristigen Einsicht auch durch den Patienten, welche Medikamente er von wem verordnet bekommen hat.
Damit bildet die eML (auch) eine Grundlage für die regelmäßige Einnahme von Patienten, insbesondere für solche ohne Medikationsplan. Somit sollte das eRezept auch mit seinem Folgenutzen im Kontext der eML betrachtet werden.

Auch wenn sich aus den gesetzlichen Vorgaben sowie den Rahmenverträgen keine Verpflichtung zum Eintragen der Verordnungsindikation in das eRezept ergibt, gibt es auch kein Verbot den Verordnungsgrund als optionales Feld in das eRezept aufzunehmen.

Da Studienlagen zeigen, dass das mangelnde Wissen über den Einnahmegrund die Adhärenz der Patienten negativ beeinflussen <span class="error">[beispielsweise in 1]</span>, sollte der Einnahmegrund als optionales Feld aufgenommen werden. Der reason sollte daher in KBV_PR_ERP_Prescription aufgenommen werden.
Um das System für den Start einfach zu halten, wäre es ausreichend den Einnahmegrund als reinen (optionalen) Freitext aufzunehmen. Da er vorrangig für den Patienten intendiert ist, wären ohnehin patientenverständliche Formulierungen förderlich.

<span class="error">[1]</span> Bülow et al. (2024) – Scoping Review:
„Previous studies have shown that poor knowledge about the indications for their medications are associated with patients having reduced adherence to therapy.“ <span class="nobr"><a href="https://bmchealthservres.biomedcentral.com/articles/10.1186/s12913-024-11685-7" class="external-link" rel="nofollow">https://bmchealthservres.biomedcentral.com/articles/10.1186/s12913-024-11685-7^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Die Herleitungen für Designentscheidungen werden (leider) nicht veröffentlicht, daher die Frage:
Wieso wird die Profilierung für die Dosierung im niedergelassenen Bereich (hier beginnend mit dem eRezept) in fünf nahezu identischen Profilen abgebildet?

FREE_TEXT, DAILY_FOUR_SCHEME, DAILY_TIME, INTERVAL, WEEKDAY

Alle Profile unterscheiden sich nur marginal, sofern die Kommentare EREZEPT-107 bis 110 umgesetzt würden, wären die Differenzen noch geringer. Ferner werden, wie kommentiert, Kombinationen dieser Dosierungskategorien benötigt - was mit 5 unterschiedlichen Profilen nicht möglich ist, daher würden für die verschiedenen Kombinationen zusätzliche Profile nötig.

Von daher erscheint es eigentlich sinnvoll, statt der 5 (und später mehr) kategoriebezogenen Dosierungsprofile lediglich EIN Dosierungsprofil anzulegen, welches die Kombination aus allen 5 bisherigen darstellt.
Die gewünschten Constraints können auch mit lediglich einem Profil gleichwertig definiert und umgesetzt werden.

Ein Dosierungsprofil gegenüber 5+X Spezialprofilen hätte folgende Vorteile:

1. Geringere Umsetzungsaufwände zur Pflege unterschiedlicher Profile

2. Direkte Umsetzungsmöglichkeit fachlich benötigter Kombinationen (sofern Gründe für eine Einschränkung der Kombinationen in der ersten Ausbaustufe sprechen, könnten die Beschränkungen auch über Constraints oder AKs aufgenommen und durchgesetzt werden)

3. Leichtere Versionierung im Zuge weitere Ausbaustufen

Nachteile für ein spezialisiertes Dosierungsprofil sehe ich (bislang keine).
Vorteile für differenzierte Dosierungsprofile sehe ich - auch auf der Implementierungsseite - keine.

Ich möchte daher vorschlagen, auf ein einzieges Dosierungsprofil für eRezepte (und eMP) umzustellen.

KBV_PR_ERP_Dosage_DailyFourScheme ist durch Fixed Values auf eine Frequenz von "täglich" festgeschrieben.
Wie in EREZEPT-109 bereits beschrieben, besteht der Bedarf für Dosierschemata mit Frequenzangabe. Dies gilt auch für Dosierungen, bei denen das 4er-Schema die beste Form der Darstellung ist, z.B. für "1-0-1-0 alle 2 Tage".

Daher sollte bei KBV_PR_ERP_Dosage_DailyFourScheme die Festschreibung auf frequency=1 und period=Day gestrichen werden und freie Frequenzfestlegungen erlaubt werden. Diese können im Rahmen der Anzeige/Ausdrucks auch gut in automatisch generierte Texte überführt werden, die das 4er-Schema verbal ergänzen (ohne dazu tatsächlich auf Freitext-Ergänzungen gehen zu müssen und die Information weiterhin maschinell auswertbar zu halten).

Der Umsetzungsaufwand erscheint gering, wenn in allen drei Dosierprofilierungen jeweils die selben (offenen) Vorgaben für eine optionale Frequenzangabe festgelegt wird - der Nutzen ist jedoch sehr hoch und sollte für den Feldstart direkt angeboten werden.

KBV_PR_ERP_Dosage_Weekday und KBV_PR_ERP_Dosage_DailyTime besitzen keine .frequency, period und periodUnit-Element.

Dies ist aus fachlicher Sicht problematisch, weil dadurch Standarddosiermuster der Art "alle 2 Wochen Montags" (und vergleichbar) nicht abgebildet werden können. Die alternative Verwendung von KBV_PR_ERP_Dosage_Interval ist oftmals wenig hilfreich, wenn multiple Medikationen vorhanden sind, bei denen für den zeitlichen Abstand Medikamente Montags, Mittwoch und/oder Freitags (im Abstand von 2 Wochen) genommen werden sollen.

Da das Frequenzmuster ohnehin umgesetzt werden muss, sollte es wenig problematisch in der Umsetzung und Anzeige/Ausdruck sein, bei den eingangs genannten Profilierungen ein Frequenzmuster optional zu erlauben.
Anderenfalls muss auch hier wieder auf Freitextdosierung für multiple Medikations-kombinationen ausgewichen werden.

Die geringfügige Erhöhung der Komplexität durch Aufnahme der Frequenzmuster sollte den Nutzengewinn dadurch nicht auf Textdosierungen wechseln zu MÜSSEN deutlich aufheben.

Ein Stufenweises Vorgehen für die Profilierung komplexer Dosierschemata ist sicher sinnvoll. Die erste Fassung (die dann auch in der eML und eMP Verwendung finden wird!) sollte jedoch die Kern-Use Cases abbilden können.
Hierzu gehört die Definition, ob eine Dosierungsangabe ein Bedarfsmedikation ist oder nicht.

Diese Information ist auch relevant für ein gruppiertes bzw. strukturiertes Ausspielen der Summe der Medikations- und Dosierangaben im Kontext eML und eMP, in denen diese Profile auch zur Nutzung kommen werden.
Hier ist es aus Gründen der Patientensicherheit notwendig, Dauereinnahmen von Bedarfseinnahmen für den Patienten (und die Pfelge) deutlich und unmittelbar sichtbar abgrenzen zu können. Dies verlangt aber die kodierte Information, ob eine Dosierung eine Dauer- oder Bedarfsdosierung ist.

Daher sollte in allen Dosierprofilierungen das Element .asNeeded unbedingt wieder erlaubt werden. Ohne die Möglichkeit zur kodierten Angabe von Bedarfsmedikationen sollte das System nicht starten.

Auch die Kombination multipler Dosierungen zu einer Verordnung (eMP-Zeile), bei denen Dauer- und Bedarfsmedikationen gemischt werden, ist aus fachlicher Sicht erforderlich (Ergänzungs- bzw. Reservedosierung zu Dauerdosierungen) und kann sowohl im Ausdruck als auch in Benutzeroberflächen gut abgebildet werden.

Für den Start sollte ein sehr einfaches Konzept für asNeededCodeableConcept verwendet werden (für den Anfang zur Not auch nur ein Freitextfeld).

Bezugnehmend auf EREZEPT-100

Ich habe jetzt gesehen, dass die Mischung verschiedener Dosierungsprofile in einer Verordnung gemäß P36-32#2a verboten ist.

Auch wenn der neue Profilierungsansatz eine stufenweise Erweiterung vorsieht, scheint diese Einschränkung vor dem Hintergrund der Sicherheit nachvollziehbar. Jedoch ist die fehlende Möglichkeit Konkretisierungen oder situationsabhängige Anpassungen am einer Dosierung angeben zu können (Freitext) problematisch und wird dazu führen, dass im Zweifelsfall direkt nur die Freitextdosierung verwendet wird (bzw. nur diese in diesen Fällen verwendet werden kann).

So kann beispielsweise:
„1-0-0-0; bei BZ > 180 mg/dl zusätzlich 1-0-0-1“
mit den aktuellen Vorgaben nur als Freitext umgesetzt werden, wobei eine Kombination aus 4er-Schema plus Ergänzung durchaus hilfreicher für die Anzeigen in interaktiven Anwendungen wäre.

Ich möchte daher anregen, in jeder Dosierungsprofilierung das .text-Element wieder zuzulassen (0..1) und im Rahmenwerk zu definierten, dass das .text-Element ausschließlich additiv <img class="emoticon" src="/images/icons/emoticons/warning.png" height="16" width="16" align="absmiddle" alt="" border="0"/> zur stukturierten Dosierung anzugeben ist.

Im Unterschied zu den anderen Dosieungsprofilierungen, ist bei
KBV_PR_ERP_Dosage_DailyFourScheme
das Element
.doseAndRate.dose<span class="error">[x]</span>:doseQuantity.unit
fix mit "Stück" zu belegen.
Dies ist problematisch, da Dosierungen der Art
"10 - 0 - 0 - 0 Tropfen"
oder
"50 - 0 - 50 - 0 ml"
durchaus üblich sind und daher für das 4er-Schema auch nutzbar sein müssen.
Die Fixierung auf "Stück" sollte entsprechend gestrichen werden.

Gemäß P36-26, AK#1 MUSS
MedicationRequest.dispenseRe
quest.expectedSupplyDuration.v
alue
befüllt werden, wenn es eine Substitutionsverordnung ist. Ansonsten KANN es befüllt werden.
Wenn es befüllt wird, DARF es NICHT größer als 30 (Tage) sein.

Die Öffnung des Felder auf Nicht-Substitionsverordnung ist für Benutzeroberflächen und Prozesse schwierig, insbesondere mit der Begrenzung auf 30 Tage, da normale Packungsgröße auch über 30 Tage hinaus reichen können. Was den Einsatz in solchen Fällen verhindert.
Da das Feld bei normalen Vorordnungen nicht befüllt sein muss, können sich Folgeprozesse (insbesondere bei Patienten-Apps) nicht auf das Vorhandensein verlassen.
Beides zusammen genommen:
Auf die Öffnung für Nicht-Substitutionsmedikamente sollte verzichtet werden ODER die Dauerbegrenzung müsste für Nicht-Substitutionsmedikamente aufgehoben werden.

Da die strukturierten Dosierungen (sinnvollerweise!) erst einmal einfach starten, sind komplexere Dosierungen darüber nicht abbildbar.
Dennoch ist es überaus sinnvoll, dass auch komplexere Dosierangaben nicht ausschließlich auf alternativem Wege (A4-Ausdruck) dem Patienten mitgegeben werden und in der Verordnung (und damit später im eML) als Dosierung nur steht "siehe ausgedruckter Dosieranweisung".

Da wir über den eRezept-Server sowie in der ePA nicht mehr über Platzmangel klagen, dann - und sollte - die Freitextdosierung daher im Stande sein, auch komplexere Dosierschemata aufnehmen zu können.
Daher bietet es sich an, dass man
1. Dosage.text von String auf Markdown ändert, wodurch z.B. Aufzählungen und die Übersicht fördernde Zeilenumbrüche möglich werden (sowie Fettsetzungen)

2. Die Größenbegrenzung von 500 Byte auf 1MB erhöht wird, um auch umfangreichender Aufbau und Ausschleichschemata aufnehmen zu können.

3. Ein optionales .attachment Element aufgenommen wird, in welche PDF-Anhänge gespeichert werden dürfen.

Nummer 3 erscheint zuerst widersinnig ("Wir wollen strukturieren, dann bitte kein PDF!"), ist aber für einen unterbrechungsfreien Informationsfluss unerlässlich, solang nicht ALLE Komplexdosierschemata für ALLE Verordnungen in FHIR abgebildet werden (können). Ein Verweis auf ein externes, nicht verfügbares Dokument erschwert die Arbeit sowohl für den Patienten, als auch die mitbetreuenden Pflegekräft (professionell wie familiär), sowie die Unterstützung durch Ärzte und Apotheken (z.B: im Rahmen der Dienstleistung der pharmakologischen Beratung). Denn die Verordnungen gelangen zur Nach- und Langzeitnutzung in der eML der ePA. Dort sollte jederzeit jegliche ärzliche Dosiervorgabe einsehbar sein und bleiben. PDF-Attachments als base64-Einträge wäre hier die Lösung.

Dosierungen der Art

"Wöchentlich
Mo, Di, Do, Fr: 1-0-0-0
Mi: 1-0-0-1"

also mit einer regelhafte zusätzlichen Abend- oder Nachdosis an einzelnen Tagen sind nicht unüblich.
Sofern ich die Vorgaben richtig verstehe, wäre ein solches Schema mit den aktuellen Vorgaben nicht strukturiert speicherbar.

Wenn dies so ist, wäre der Vorschlag, dass in einer 4er-Schema-Dosierung auch zusätzlich Wochentage codiert angegeben werden dürfen, also Aufnahme .timing.repeat.dayOfWeek mit 0..7 für KBV_PR_ERP_Dosage_DailyFourScheme.
Damit wären auch diese Schema codierbar - und die Art der Kodierung entspräche noch dem grundsätzlichen Vorgehen für einfache strukturierte Kodierungen.

Dosage.timing.repeat.bounds<span class="error">[x]</span>:boundsDuration.unit
erlaubt gemäß Valueset derzeit ausschließlich
Tag, Woche, Monat, Jahr

Da nur eine maximal Wertangabe für boundsDuration zulässig, können "gebrochene" wie "10 Tage" entweder über "10 Tage" oder über "1.5 Wochen" codiert werden - wobei bei "1.5 Wochen" (zulässig, da boundsDuration.value ein decimal ist) unklar ist, ob damit 10 oder 11 Tage gemeint sind.

Die Codierung wäre immer eindeutig, wenn ausschließlich "Tag" zugelassen würde. Bei langen Dauern ergeben sich entsprechend hohe Werte, die aber in der Anzeige entsprechend in lesbare Werte (unter Verwendung von "Woche", "Monat", "Jahr") heruntergebrochen werden können.
Dies erleichtert die Interpretation einrichtungsübergreifende Dosierungen (in eML und eMP) deutlich, da die Systeme und Anzeigen dann nicht mit unterschiedlichen "Kodierungsvorlieben" der verschiedenen Arztpraxen klarkommen müssen. (auch die ePA-Apps hätten es dann leichter)

Unter
Dosage.timing.repeat.bounds<span class="error">[x]</span>:boundsDuration.unit
dürfen bislang nur Tag, Woche, Monat oder Jahr eingegeben werden. Dies ergibt ausschließlich die Möglichkeit für eine zeitliche Dauer.

Gerade im Bereich der Antibiothika ist die Dosierungsangabe "Einzunehmen bis die Packung aufgebraucht ist" durchaus üblich.

Entsprechend sollte eine Möglichkeit aufgenommen werden, dass "bis Packungsende" über .duration codiert werden kann.

In P36-32, AK 3 werden die Kardinalitäten für die 5 Dosierschematypen definiert. In der Festlegungen sind alle mit mindestens (oder genau) 1 angegeben.

Es liest sich, als müsste entsprechend den Vorgaben in jeder Verordnung JEDE dieser Dosieranweisungstypen verwendet werden. Dies ist vermutlich nicht intendiert.

Vorgaben ob und wenn ja in welcher Form innerhalb einem Request multipe Dosieranweisungstypen erlaubt sind (oder verpflichtend sind), habe ich bislang nicht gefunden. Hier wäre eine Klarstellung hilfreich (so sie denn tatsächlich nicht enthalten ist).

Multiple Dosieranweisungstypen sind grundsätzlich sinnvoll.
Dazu wäre erforderlich, ein Regelwerk zu defieren, wie die Typen kombiniert werden dürfen und wie die Gesamtheit in einem solchen Fall zu interpretieren ist.

Vorschlag:
Multiple Dosierungsangaben (egal welchen Typs) gelten immer additiv. Bei der Befüllung ist entsprechend auf Widerspruchsfreiheit zu achten.
Somit könnten z.B. 4er-Dosierungen mit zusätzlicher Freitextangabe ermöglicht werden, wie beispielsweise "1-0-0-0 Tabl. täglich; Morgens 30 Min. vor dem Frühstück")

Praktisch alle verwendeten PZN-Arzneimittel verfügen auch über einen ATC-Code (Mapping BfArM).

Wird einer PZN-Verordnung ihr zugehörigen ATC-Code generell mitgegeben, kann die Verordnung im Rahmen des dgMP leichter eingebunden werden (automatische "lockere" Bindung zwischen eML und eMP; Meldehinweis Doppelmedikation <span class="error">[unterschiedliche PZN mit identischer Indikation]</span>, etc.)

Der jeweilige ATC-Code sollte daher verpflichtend unter Medication.code.coding als weiterer Slice aufgenommen werden.

P36-44 verlangt Ausgaben gemäß Pseudocode. Dies führt laut Vorgabe zu:
„1 Stück – 0 – 1 Stück – 0“
„20 ml – 0 – 20 ml – 0; für 7 Tage“
„3 Tropfen – 0 – 4 Tropfen – 0; für 7 Tage“

Dies erschwert die Lesbarkeit.
Da bereits Gleicheit in den Einheiten aller Einträge verlangt ist, kann der String "optimiert" werden zu:
„1 – 0 – 1 – 0 Stück “
„20 – 0 – 20 – 0 ml; für 7 Tage“
„3 – 0 – 4 – 0 Tropfen; für 7 Tage“

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.

Aufgrund der hohen Komplexität von dosageInstruction und der Möglichkeit, die gleiche Dosierung auf verschiedene Arten strukturiert angeben zu können, ist ein umfassender Implementierungsleitfaden und eine hohe Zahl realistischer Beispiele mit entsprechender Dokumentation erforderlich. Die Primärsystemhersteller benötigen bereits zum Start der Implementierung Arzneimitteldatenbanken, die alle vorgesehenen Codierungen unterstützen. Der dadurch zusätzlich benötigte zeitliche Vorlauf sollte mit den Datenbankherstellern abgestimmt werden.
Aufgrund des hohen Aufwands für die Primärsystemhersteller schlagen wir vor zu prüfen, ob die Komplexität der strukturierten Dosierungsangabe in einer ersten Ausbaustufe verringert werden kann, auch wenn dann ggf. z.B. nur 90 % der möglichen Dosierschemata strukturiert angegeben werden können. Sollte eine Verringerung der Komplexität nicht möglich sein, ist den Arzneimitteldatenbank- und Primärsystemherstellern ausreichend Zeit für die Umsetzung einzuräumen. Es ist davon auszugehen, dass die üblichen 9 Monate Vorlauf nicht ausreichen werden.
Wir verweisen auf unsere Anforderung für die Definition eines Algorithmus zur Umwandlung strukturierter Dsierungsangaben in menschenverständlichen Text (siehe unser Kommentar zur Technischen Anlage ERP).

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.

Für alle Elemente, bei denen mehrere verschiedene Codesysteme vorgesehen sind, ist zwingend ein Constraint erforderlich, dass bei Angabe einer Codierung nur ein Codesystem verwendet werden darf und keine Mischung verschiedener Codesysteme zulässig ist. Begründung: Wenn mehrere Codierungen aus verschiedenen Codesystemen für einen Eintrag ermöglicht werden, kann dies zu widersprüchlichen Angaben führen und ein intellektueller Abgleich wäre immer erforderlich. Wenn festgestellt wird, dass die verschiedenen Codes nicht zusammenpassen, ist ggf. eine aufwendige Klärung und Rücksprache beim Arzt erforderlich.

Für alle Elemente mit dem Datentyp CodeableConcept ist ein Constraint erforderlich, dass entweder nur die codierte Angabe oder nur eine Angabe im Freitext möglich ist. Begründung: Wird sowohl Freitext als auch Code angegeben, besteht ein relevantes Risiko für widersprüchliche Angaben und ein intellektueller Abgleich wäre immer erforderlich. Wenn festgestellt wird, dass Code und Freitext nicht zusammenpassen, ist ggf. eine aufwendige Klärung und Rücksprache beim Arzt erforderlich.

Für alle Werte der zugelassenen ValueSets muss zwingend eine deutsche Übersetzung bereit gestellt werden.