Technische Anlage eRezept

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.

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.

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.

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“