Kommentierungsüberblick

Die papiergebundenen Muster sind je nach Arzneimittelkategorie farblich kodiert (Grün - OTC; Rosa - Muster 16; Blau - PKV; Gelb - BtM). Die farbliche Einteilung der Rezepte und den damit verbundenen Arzneimittel ist bei allen Beteiligten des Arzneimittelverordnungsprozesses verinnerlicht. Sie bietet Patienten darüber hinaus eine Orientierung iS "Was erwarte ich für ein Arzneimittel?".

Der BAH weißt darauf hin, dass die Erfassung, Verarbeitung und Darstellung von OTC-Arzneimitteln noch nicht im vollen Umfang bei der MIO berücksichtigt wurde. Die Bedeutung von OTC-Arzneimittel im Rahmen des Medikationsplans/ AMTS wurde jedoch gesetzlich mit dem DigiG untermauert. Über das Grüne Rezept werden jährlich rund 41 Mio. ärztliche Empfehlungen Patienten ausgestellt. OTC Arzneimittel sind für Patienten eng verbunden mit der Farbe des Grünen Rezeptes. Aus Sicht des BAH gilt es, diesen Wiedererkennungswert Patienten und Leistungserbringern weiterhin zu ermöglichen. Dies gilt auch für die Darstellung anderer Arzneimittelkategorien.

Farbliche Kodierungen helfen, die Relevanz von Arzneimitteln im Rahmen der AMTS schnell einzuordnen. Die aktuelle Darstellung macht es den Patienten schwer einfach Arzneimittel/ Rezepte in Ihrer Relevanz/ Wirkung zuzuordnen. Dies kann zu AMTS Problemen führen.

Daneben bietet das Grüne Rezept bzw. in Zukunft das elektronische Grüne Rezept mehrere niederschwellige Vorteile:

• Adhärenz-Förderung und zusätzliche Therapieoption für die Ärzte
• Orientierung, Information und Sicherheit für Patienten
• Aktive Beratungsangebote in Apotheken
• Entlastung der GKV

Die komplexen Abhängigkeiten zwischen eML und eMP lassen sich für den Benutzer leichter berücksichtigen, wenn in der eML das Datum es letztgültigen eMP mit angezeigt wird und dies auch visuell in der eML berücksichtigt wird.

UMSETZUNG:
Hinweis: „Letzter eMP vom 26.4.204“ im Kopfbereich der eML
+
Darstellung der alten (schon im eMP berücksichtigen) Teile der eML abgedunkelt in grau,
während die aktuellen Bestandteile der eML (Datum nach Erstellung eMP) deutlich mit vollem Kontrast in Schwarz dargestellt werden.
ggf. noch zusätzlich durch eine horizontale Linie getrennt

NUTZEN:
Der Benutzer sieht zum einen dass es ggf. schon einen eMP gibt und zu welchem Datum dieser erstellt worden ist.
Zusätzlich wird er visuell geführt, welche Teile der eML noch nicht im eMP berücksichtigt worden sind. Dafür treten die schon im eMP berücksichtigten Teile der eML in den Hintergrund

Die ambulante und stationäre Langzeitpflege benötigt zeitnah zuverlässige Informationen über Änderungen bzw. Dosierungsänderungen von Medikamenten, damit Medikamente zuverlässig und korrekt durch Pflegepersonal gestellt bzw. gegeben werden können.
Bisher erfolgt dieser Prozess in vielen Fällen telefonisch oder persönlich durch den Arzt gegenüber dem Pflegepersonal und wird nicht im eML und eMP dokumentiert.

Das Ausstellen eines neuen Rezepts mit der gewünschten neuen Dosierung und die automatische Übernahme dessen in die eML genügt nicht, da hiermit bei Medikamentenänderungen unklar ist ob ein bestehendes Medikament abgesetzt werden soll
bzw bei Dosierungsänderungen unklar ist ob das Bestandsmedikament in der neuen Dosierung zusätzlich oder ersetzend zum alten Rezept genommen werden soll.

Vorschlag zur digitalen Prozessumsetzung:

• Absetzen der alten Dosierung/Einnnahmezeitpunkt oder ggf. alten Medikaments
  gemäß Kommentierungsvorschlag EMP1X0X0-305 incl. Eintrag in eML und eMP UND
• Erstellen eines neuen e-Rezepts für Folgedosierung/Folgemedikament

Um nur eine Dosierungsänderung bzw. Einnnahmezeitpunktänderung bei vorhandenen Medikamenten umzusetzen könnte ein Kennzeichen "Nicht neu liefern" dies ermöglichen um eine Doppellieferung auszuschließen.

Damit diese Änderungen durch den Arzt sicher und schnell erfolgen können benötigt es einen leichtgewichtigen und schnellen (computergestützten) Prozess um ein Medikament zu einem bestimmten Termin in eML und eMP ersetzen zu können.
Bisher wäre dies durch den Arzt nur durch einen neuen eMP zu erreichen.
Der dafür benötigte personelle und zeitliche Aufwand des Arztes wird die Nutzung diesen Prozess in der Realität sehr unwahrscheinlich machen.
==> Es muss eine expliziten Prozess für die Änderung von Medikamenten bzw. Dosierungen geben der die Medikationsliste (und ggf. auch den eMP -falls sachlich möglich) automatisch aktualisiert ohne dass der Arzt manuell einen neuen eMP erstellen muss.

Die ambulante und stationäre Langzeitpflege benötigt zeitnah zuverlässige Informationen über Absetzungen und Dosierungsänderungen von Medikamenten, damit Medikamente zuverlässig und korrekt durch Pflegepersonal gestellt bzw. gegeben werden können.
Bisher erfolgt dieser Prozess in vielen Fällen telefonisch oder persönlich durch den Arzt gegenüber dem Pflegepersonal und wid nicht im eMP dokumentiert.
(Hinweis zur bisherigen Vorgehensweisen:

• Handzeichen des Arztes auf dem Mediplan der Einrichtung vor Ort oder - Dokumentation mittels "Vorgelesen und Genehmigt" per Telefon durch den Arzt.
  Damit Absetzungen durch den Arzt sicher und schnell erfolgen können benötigt es einen leichtgewichtigen und schnellen (computergestützten) Prozess um ein Medikament zu einem bestimmten Termin in eML und eMP absetzen zu können.
  Bisher wäre dies durch den Arzt nur durch einen neuen eMP zu erreichen. Der dafür benötigte personelle und zeitliche Aufwand des Arztes wird diesen Prozess in der Relaität sehr unwahrscheinlich machen.
  ==> Es muss eine expliziten Prozess für das Absetzen von Medikamenten geben der die Medikationsliste (und ggf. auch den eMP -falls sachlich möglich) automatisch akutalisiert ohne dass der Arzt manuell einen neuen eMP erstellen muss.

Damit wird die eML automaitsch auch eine zuverlässigere Quelle für die aktuelle Medikation wenn neben den hinzugefügten auch die herausgenommenen Dokumente in der Liste mitgeführt werden.

In vielen Pflegesettings werden im Bereich Medikation und Selbstmedikation weitgehende Unterstützungen für Versicherte geleistet. Dabei müssen für schwer pflegebedürftige oder stark kognitiv eingeschränkte Personen Tätigkeiten vollständig übernommen werden.

In diesem Zusammenhang sieht der FINSOZ e. V. den dringenden Bedarf, in der Systematik vorzusehen, dass die Pflege (stationär und ambulant) die Möglichkeit erhält, Präparate der Selbstmedikation – also Medikamente, die abseits von Rezept und Apothekenpflicht verabreicht werden – in die Medikamentenliste von Versicherten einzutragen. Pflegekräfte sollten dafür Schreibrechte erhalten.

In der stationären und ambulanten Langzeitpflege erfahren die Pflegekräfte regelmäßig relevante Information zur Compliance der Medikamenteneinnahme (wie. Z.B. Patient nimmt Tabletten aus Grund xy nicht ein, eigenmächtige Dosierungsänderung durch den Patienten oder abweichende Einnahmezeitpunkte).
Von daher wäre es sinnvoll für Pflegekräfte eine Möglichkeit vorzusehen, Informationen zur tatsächlich erfolgten Medikation ergänzend eintragen zu können.
Nur über die Rückmeldung dieser Abweichungen erfährt der Arzt von ungeplanten Änderungen in der tatsächlichen Medikation und kann ggf. bei der nächsten Verordnung darauf reagieren.
ZUSATZ:
Diese Kommentierungsmöglichkeit sollte auch für den Patienten selbst möglich sein.
Das wird im Gegensatz zur professionellen Rückmeldung durch Pflegepersonal aber eine eher selten durch den Patienten genutzte Funktion in der ePA-APP sein.

Zusätzlich zur reinen Einsicht wie im Szenario "Lesen eines Medikationsplans durch eine/n berechtigte/n Anwender:in" beschrieben fehlt das Beispiel der Übernahme von Daten in ein Primärsystem (Pflegedokumentation), das (bisher und leider) nicht über schreibenden Zugriff auf die ePA verfügt.
Insbesondere bei stationärer Unterbringung in einer Pflegeeinrichtung, aber auch im genannten Beispiel eines ambulanten Pflegedienstes ist eine direkte Versorgung der Klienten anhand des eMP illusorisch –
Es muss auch zukünftig immer eine vollständige Hinterlegung des Medikationsplans im eigenen Primärsystem (Pflegedokumentation) erfolgen. In diesen Systemen wird die vollständige Medikation der Klienten strukturiert hinterlegt und u.a. zum Stellen der Medikamente und der Dokumentation der einzelnen Gaben aufbereitet. Dies umfasst auch die im eMP nicht berücksichtigten Fälle der BTMs und Selbstmedikation, sowie diejenigen Klienten, die nicht über einen Anspruch auf einen eMP verfügen.
Auch wenn die hierfür benötigten Datenstrukturen technisch mit denen zur Anzeige des eMP übereinstimmen, sollte ein entsprechendes fachliches Szenario explizit aufgenommen und in den Weiterentwicklungen berücksichtigt werden.

ASK identifiziert den Wirkstoff und ist daher als Code-Kodierung einer Medikation ungeignet.

Als Vergleich: Die ISIK-Spezifikation sieht im Medikationsmodul 4 eine Kodierung von ASK unter ingredient.itemCodeableConcept vor, nicht jedoch unter Code.

<span class="nobr"><a href="https://simplifier.net/guide/isik-medikation-v4/ImplementationGuide-markdown-Datenobjekte-Profile_Medikament?version=current" class="external-link" rel="nofollow">https://simplifier.net/guide/isik-medikation-v4/ImplementationGuide-markdown-Datenobjekte-Profile_Medikament?version=current^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Hier bitte mit ISIK harmonisieren.

Die ATC-WiDO-Versionen unterscheiden sich von der amtlichen ATC-DE-Version
Daher die Bitte um eine Bereitstellung des ATC-WiDO-Codes samt Jahresversionierung,
wie vom Wissenschaftlichen Institut der AOK bereitgestellt (siehe Link). <span class="nobr"><a href="https://www.wido.de/publikationen-produkte/analytik/arzneimittel-klassifikation/?L=0" class="external-link" rel="nofollow">https://www.wido.de/publikationen-produkte/analytik/arzneimittel-klassifikation/?L=0^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Die Angaben im KBV-Valeset TimingEvent sind ebenfalls kleinteilig aber zum Teil unpräzise. Im Kontext des Einnahmezeitpunkt ergeben sich immer wieder die selben Timing-Konstellationen. --> ValueSet entsprechend kürzen auf Vor/Mit/Nach der Mahlzeit, wobei zu "Vor" und "Nach" konkrete Zeitangaben wie 30 min/1 h etc. hinterlegbar sein sollten.

Das Hinterlegen von Dosierungsangaben erscheint sehr kleinteilig spezifiziert und dadurch u.U. je nach Umsetzung im Primärsystem aufwändig für die Eingabe der entsprechenden Angaben in den Medikationsplanen, z.B. 2.21.7.3.5.1 TAGESZEIT (KBV-Valuset Event Timing). Zeitangabe wir "am späten Vormittag" sind für Patienten nicht eindeutig bzw. sollten, sofern sie über das etablierte Viererschema (morgens-mittags-abends-zur Nacht) hinausgehen eher durch eine konkrete Uhrzeit definiert werden --> ValueSet entsprechend kürzen.

Das Valueset Statusgrund ist unvollständig und sollte um folgende Werte ergänzt werden. Statt "eingenommen" wäre "angewendet" die passendere Bezeichnung, da so auch nicht peroral angewendete Arzneimittel eingeschlossen würden:

• Abgesetzt wegen fehlender Sondengängigkeit
• Abgesetzt wegen Therapieumstellung
• Abgesetzt/Nicht angewendet wegen Allergie/Unverträglichkeit
• Abgesetzt/Nicht angewendet da Anwendungsgrund nicht mehr besteht
• Abgesetzt/Nicht angewendet wegen Problemen bei der Handhabung

Für Medikationen, die komplexe Dosierungsschemata aufweisen, sollte zusätzlich oder alternativ zu den strukturierten Informationen im Attribut .dosage, weitere Begleitinformation mittels Anhang zur Verfügung gestellt werden können (z.B: .dosageAttachment). Als mögliche Dateiformate bieten sich ggf. PDF/A oder ein einfaches standardisiertes Textformat wie z.B. MarkDown an.

Die Informationen im dgMP sind insbesondere beim Übergang von medizinischer zu pflegender Unterstützung von Menschen relevant und damit auch für die ambulant oder stationär Pflegenden.

Zur Medikation sollten die Pflegenden direkt an sie gerichtete Informationen erhalten.

Dies könnte beispielsweise mittels der zusätzlichen Attribute .nursingInstruction (das Medikament betreffend) und .additionalInstruction (den Kontext der Medikamentengabe betreffend) erfolgen. (Beide analog zu .note).

Der letzte Task "Prüfung kenntlich machen" ist für Apotheken zum aktuellen Stand nicht akzeptabel. Dass Änderungen am Medikation im Kontext einer AMTS-Püfung durch die Apotheke dokumentiert werden und damit für andere LE nachvollziehbar werden, ist zu unterstützen. Dass eine "Prüfung" kenntlich gemacht wird, wäre nur dann für die Apotheke akzeptabel, wenn Inhalt und Umfang, insb. auf welche ABP welche Medikationsdaten verpflichtend zu prüfen sind, einer solchen Prüfung definiert sind.

1. Der Titel des hier beschriebenen Szenarios sollte für ein besseres Verständnis im Versorgungskontext (siehe auch übergeordneter Kommentar) umbenannt werden in "Prüfen der Gesamtmedikation durch eine/n Ärztin oder eine/n Apotheker:in mit Erstellung bzw. Aktualisierung eines Medikationsplans", da sich die Prüfung nicht auf den Medikationsplan als solchen sondern auf die Medikation bezieht. Der Medikationsplan bzw. dessen Aktualisierung ist wiederum das Ergebnis dieser Prüfung
2. Weiterhin sollten die ersten beiden Absätze wie folgt ersetzt werden: In besonderen Betreuungsmodellen, z.B. im Medikationsmanagement werden umfassende AMTS-Prüfungen der Gesamtmedikation durchgeführt und sollten sowohl ärztlich als auch pharmazeutisch mit dem jeweiligen Schwerpunkt durchgeführt werden. Dies umfasst sowohl die medikationsbezogene Anamnese als auch die AMTS-Prüfung. Letztere kann unterschiedliche Ergebnisse zur Folge haben:
3. Die pharmazeutischen bzw. medizinischen Anteile bzw. Zuständigkeiten in einer AMTS-Prüfung über die Gesamtmedikation müssen zunächst noch definiert werden. Hierzu sollten die Arbeiten des im Positionspapier "Digital gestützter Medikationsprozess" geforderten Folgearbeitskreises "AMTS-Prüfung" abgewartet werden, zumal sich hiernach auch die Verantwortlichkeiten richten werden.

Im Kontext einer Rezeptbelieferung oder der Abgabe eines OTC-Arzneimittels in Apotheken erfolgt eine AMTS-Prüfung des abzugebenden Arzneimittels gegen die übrige, bekannte Medikation und in Abhängigkeit von den situativ verfügbaren Daten. Dies bilden hier das 2. sowie 3. Szenario sowie die darin wiederum eingebetteten Grundprozesse zur Dispensierung entsprechend ab. Eine AMTS-Prüfung über die Gesamtmedikation, wie im 4. Szenario beschrieben, erfolgt hingegen ausschließlich im Rahmen von Medikationsanalysen bzw. in einem Medikationsmanagement und ist damit also nicht Teil der Routineversorgung.

Der Bedarf zur Kommentierung eines Medikationsplans kann sich wiederum aus unterschiedlichen Situtationen heraus ergeben, z.B. im Kontext der Einsicht bzw. der Prüfung eines Medikationsplans. Entsprechend sollten hier noch Verlinkungen kenntlich gemacht zum Szenario "Prüfen eines Medikationsplans durch eine/n Ärztin oder eine/n Apotheker:in" bzw. dem Grundprozess "Aktualisierung medikationsrelevanter Daten". Der Startpunkt des BPMN sollte zudem kenntlich machen, dass Bedarf zur Kommentierung festgestellt wurde.

In Analogie zum PVS = Praxisverwaltungsystem wäre die Ergänzung AVS = Apothekenverwaltungssystem hilfreich, insb. für die Prozesse, hinsichtlich derer eine Differenzierung dieser beiden PS erforderlich ist, zum Beispiel zur Erläuterung der apothekenspezifischen "Stammkundenkartei" im Glossar.

Vielen Dank für die Übernahme der Definition des Begriffs AMTS aus dem Positionspapier "Digital gestützter Medikationsprozess". Die Definition des Begriffs "AMTS-Prüfung" wird hier jedoch hier um die Definition einer sog. "gesamthaften AMTS-Prüfung" ergänzt, die so bisher nirgends definiert wurde. Ebendies soll ja durch einen im Positionspapier ebenfalls geforderten Folgearbeitskreis "AMTS-Prüfung" passieren, dessen Einberufung Stand April 2024 jedoch noch aussteht. Im Kontext der Defintition fehlt hier zudem eine präzise inhaltliche Auflistung, auf welche Arzneimittelbezogenen Probleme in einer solchen AMTS-Prüfung bzw. im jeweiligen Setting verpflichtend geprüft werden muss, denn eine AMTS-Prüfung versteht sich für uns als eine Prüfung der Medikation auf Risiken, an die sich bei Bedarf eine Lösungsfindung anschließt und beschränkt sich somit nicht auf die Übernahme von Verantwortlichkeit für korrekte Angaben in einem Medikationsplan. Dementsprechend bitten wir um Streichung des Begriffs "gesamthafte AMTS-Prüfung" im Prozessleitfaden und Glossar und Verwendung des generischen Begriffs "AMTS-Prüfung" stattdessen.

Die Stammkundenkartei wird i.d.R im Moment der schriftlichen Einwilligung mit Basisdaten des Versicherten befüllt, weitere pharmazeutisch relevante Informationen können ergänzt werden. Sofern diese bei jedem Apothekenbesuch aufgerufen wird, befüllt sich diese dann kontinuerlich mit allen Abverkäufen (nicht auf Arzneimittel beschränkt) in dieser Apotheke. Insofern könnte der Zusatz "oder fertig angelegt" ggf. mißverstanden werden bzw. sollte entfallen.

Ein ePA-Zugriff ist derzeit technisch durch Einlesen der eGK möglich (Herstellung des Behandlungskontext). Wieso wird in diesem Prozess zusätzlich der Task "Zugriff via App berechtigen" abgebildet?

Der hier beschriebene Prozess vermittelt den Eindruck, dass ABP, die im Kontext der Auswahl eines OTC-Arzneimittels durch die Apotheke erkannt bzw. als relevant eingestuft werden, ausschließlich durch einen Präparatewechsel behoben werden können. Das ist jedoch so nicht richtig, bevor ein Präparatewechsel in Erwägung gezogen werden muss, gibt es eine Vielzahl von ABP, die sich u.U. durch Aufklärung und Beratung der Patient*innen beheben lassen. Dies könnte behoben werden, indem das Gateway umbenannt wird in "Behebung durch Apotheke möglich (z.B. Präparatewechsel oder Patientenberatung)". Entsprechend sollte der Text angepasst bzw. ergänzt werden.

Bitte analog der bereits geänderten Anmerkung Satz "Sofern kein Widerspruch vorliegt, erfolgt die Speicherung der OTC-Dispensierdaten in der ePA." dahingehend umformulieren, dass OTC-Dispensierdaten nur denn in den Medikationsplan in der ePA aufgenommen werden, sofern diese relevant sind. Die Dispensierdaten zu auf E-Rezept verordneten OTC-Arzneimitteln (derzeit Selbstzahler-E-Rezept) wiederum werden ja durch den eRx-FD automatisch in die eML in der ePA geschrieben.

Der hier beschriebene Prozess vermittelt den Eindruck, dass ABP, die im Kontext der Arzneimittelabgabe in der Apotheke erkannt bzw. als relevant eingestuft, ausschließlich durch einen Präparatewechsel behoben werden können. Das ist jedoch so nicht richtig abgebildet, insb. Interaktionen können u.U. ebenfalls eigenständig durch die Apotheke durch Aufklärung und Beratung der Patient*innen behoben werden, z.B. durch Zeitabstände zwischen Einnahmezeitpunkten. Dies könnte behoben werden, indem das Gateway umbenannt wird in "Behebung durch Apotheke möglich (z.B. Präparatewechsel oder Patientenberatung)".

Bisher sind AMTS-Prüfungen inhaltlich nicht definiert worden, vielmehr ist die "AMTS-Prüfung" als Sammelbegriff zu verstehen, wie auch im Glossar entsprechend beschrieben. Ebenso sind softwaregestützte AMTS-Prüfungen in unterschiedlichen Settings und mit unterschiedlichem inhaltlichem Fokus und Umfang möglich. Dies sollte hier ebenfalls deutlich werden, indem im Plural von "z.B. softwaregestützten AMTS-Prüfungen" gesprochen wird.

Das Feld "Identifier.value" soll laut Definition mit einer UUID befüllt werden und der Inhalt mit "urn:uuid:" beginnen. Dies könnte über ein Constraint mittels RegEx sichergestellt werden.

Realistische Beispiele für einen gesamten Medikationsplan wären zum Verständnis sehr hilfreich und bereits für die Kommentierung nötig gewesen.
Falls noch Beispiele ergänzt werden, sollte neben der FHIR-Struktur auch eine ohne FHIR-Kenntnisse "lesbare" Darstellung zur Verfügung gestellt werden.

Elemente mit dem Datentyp Codable Concept können profiliert werden, so dass entweder nur ein einziger Code angegeben werden kann oder nur Freitext. Es gibt daher keinen technischen Grund, mehr Freiheitsgrade vorzusehen.
Je komplexer die Angabemöglichkeiten sind, desto größer ist das Fehlerrisiko. Es muss daher eine restriktive Angabemöglichkeit definiert werden oder technisch sichergestellt werden, dass widersprüchliche Angaben nicht möglich sind. Andernfalls ist das Konzept nicht praxistauglich, da eine intellektuelle Überprüfung im Routinebetrieb nicht leistbar ist.

Der Nutzen, mehrere verschiedene Codierungen mit identischem Wertebereich für einen Eintrag zwingend vorzuschreiben, ist nicht erkennbar. Es ist zwingend erforderlich, widersprüchliche Angaben beim Eintragen durch ein Mapping technisch auszuschließen. Anderenfalls ist das Konzept nicht praxistauglich, da eine Überprüfung und ggf. Klärung von Abweichungen im Routinebetrieb nicht geleistet werden kann.

Zumindest bei den Aktivitäten Erstellen und Aktualisieren sollte das Datum der Durchführung verpflichtend sein.

Die verpflichtende Angabe des Behandlungsgrunds als Freitext passt nicht zur Darstellung in Kap. 2.21.8 ("Hier wird der Grund angegeben, aus dem das Arzneimittel eingesetzt anhand eines entsprechenden Codes oder alternativ mit einem Freitext angegeben. ").
Ist eine verpflichtenden Freitext-Angabe für den Patienten erforderlich, wird für die parallele Angabe eines Codes eine Referenzdatenbank und ein Mapping zu den zugelassenen Code-Systemen benötigt.

ALPHA-ID, SNOMED CT und ORPHANET Codes können in den Apothekensystemen nicht verarbeitet werden und damit auch nicht in die elektronisch unterstützte AMTS-Prüfung einbezogen werden. Eine manuelle Überprüfung ist im Routinebetrieb nicht möglich.
Die Eignung von SNOMED CT für den Anwendungszweck ist nachvollziehbar darzulegen. Dabei sind die Auswirkungen für die Primärsysteme und deren Anwender sowie für die Patienten in Deutschland zu beleuchten.
Die Menge von aktuell ca. 130.000 Diagnosen von SNOMED CT ist viel zu umfassend, um im dgMP sinnvoll genutzt werden zu können. Falls SNOMED CT hier vorgesehen wird, ist eine Limitierung der zulässigen SNOMED CT Codes erforderlich. Für die drei genannten Codes wird ein Mapping zum ICD-10 benötigt.

Mehrere verschiedene Codierungen für einen Eintrag parallel zu ermöglichen, kann zu widersprüchlichen Angaben führen. Daher ist ein Constraint erforderlich, dass immer nur ein Codesystem verwendet werden kann oder Widersprüche müssen durch ein Mapping technisch ausgeschlossen werden. Anderenfalls ist das Konzept nicht praxistauglich, da eine intellektuelle Überprüfung im Routinebetrieb nicht geleistet werden kann.

Die vorgesehene alternative Angabe eines Codes oder eines Freitexts muss durch einen Constraint im FHIR-Profil technisch vorgegeben werden, um ggf. widersprüchliche Angaben zu vermeiden. Im Routinebetrieb ist weder eine Überprüfung noch eine Auflösung möglicher Widersprüche aufgrund der parallelen Angabe von Code und Freitext leistbar.
Falls zusätzlich zum Code eine Freitextbezeichnung für den Patienten erforderlich ist, wird eine Referenzdatenbank inklusive Mapping zu den zugelassenen Code-Systemen benötigt.

Es muss ein eng begrenztes und verbindlich vorgegebenes ValueSet für SNOMED CT Codes definiert und abgestimmt werden. Anderenfalls ist die mit SNOMED CT codierte ergänzende Anweisung in den Apotheken nicht nutzbar.

Der Nutzen einer codierten Angabe für dieses Element erschließt sich nicht.
Wenn sowohl Code als auch Freitext-Bezeichnung angegeben werden, 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 eine ggf. aufwendige Klärung und Bereinigung des Fehlers erforderlich. Beides kann im Routinebetrieb nicht geleistet werden. Der Ansatz ist daher nicht praxistauglich.
Falls zusätzlich zum Code eine Freitextbezeichnung für den Patienten erforderlich ist, wird eine Referenzdatenbank inklusive Mapping zu den zugelassenen Code-Systemen benötigt.

Ein verbindliches ValueSet für die Dosiereinheit ist erforderlich. Andernfalls ist eine strukturierte Angabe nicht besser als ein Freitextfeld.

Wenn sowohl Code als auch Freitext-Bezeichnung angegeben werden, 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 eine ggf. aufwendige Klärung und Bereinigung des Fehlers erforderlich. Beides kann im Routinebetrieb nicht geleistet werden. Der Ansatz ist daher nicht praxistauglich.
Falls zusätzlich zum Code eine Freitextbezeichnung für den Patienten erforderlich ist, wird eine Referenzdatenbank inklusive Mapping zu den zugelassenen Code-Systemen benötigt.

SNOMED CT Codes können in den Apothekensystemen nicht verarbeitet werden und damit auch nicht in die elektronisch unterstützte AMTS-Prüfung einbezogen werden. Eine manuelle Überprüfung ist im Routinebetrieb nicht möglich.
Die Eignung von SNOMED CT für den Anwendungszweck ist nachvollziehbar darzulegen. Dabei sind die Auswirkungen für die Primärsysteme und deren Anwender sowie für die Patienten in Deutschland zu beleuchten.
Die Menge von aktuell ca. 130.000 Diagnosen von SNOMED CT ist viel zu umfassend, um im dgMP sinnvoll genutzt werden zu können. Falls SNOMED CT hier vorgesehen wird, ist eine Limitierung der zulässigen SNOMED CT Codes erforderlich. Ggf. wird ein Mapping zum ICD-10 benötigt.

Es muss ein eng begrenztes und verbindlich vorgegebenes ValueSet für SNOMED CT Codes definiert und abgestimmt werden. Anderenfalls ist die mit SNOMED CT codierte Angabe der Körperstelle in den Apotheken nicht nutzbar.

Wenn sowohl Code als auch Freitext-Bezeichnung angegeben werden, 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 eine ggf. aufwendige Klärung und Bereinigung des Fehlers erforderlich. Beides kann im Routinebetrieb nicht geleistet werden. Der Ansatz ist daher nicht praxistauglich.
Falls zusätzlich zum Code eine Freitextbezeichnung für den Patienten erforderlich ist, wird eine Referenzdatenbank inklusive Mapping zu den zugelassenen Code-Systemen benötigt.

Es muss ein eng begrenztes und verbindlich vorgegebenes ValueSet für SNOMED CT Codes definiert und abgestimmt werden. Anderenfalls ist die mit SNOMED CT codierte Angabe des Verabreichungswegs in den Apotheken nicht nutzbar.

Mehrere verschiedene Codierungen für einen Eintrag parallel zu ermöglichen, kann zu widersprüchlichen Angaben führen. Daher ist ein Constraint erforderlich, dass immer nur ein Codesystem verwendet werden kann oder Widersprüche müssen durch ein Mapping technisch ausgeschlossen werden. Anderenfalls ist das Konzept nicht praxistauglich, da eine intellektuelle Überprüfung im Routinebetrieb nicht geleistet werden kann.

Wenn sowohl Code als auch Freitext-Bezeichnung angegeben werden, 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 eine ggf. aufwendige Klärung und Bereinigung des Fehlers erforderlich. Beides kann im Routinebetrieb nicht geleistet werden. Der Ansatz ist daher nicht praxistauglich.
Falls zusätzlich zum Code eine Freitextbezeichnung für den Patienten erforderlich ist, wird eine Referenzdatenbank und ein Mapping zu den zugelassenen Code-Systemen benötigt.

Ein verbindliches ValueSet für die Dosiereinheit ist erforderlich. Andernfalls ist eine strukturierte Angabe nicht besser als ein Freitextfeld.

Für kombinierte Einheiten wird ein definiertes ValueSet benötigt.

Die Vorgabe, dass sich eine strukturierte Dosierungsanweisung und eine Freitext-Dosierungsanweisung gegenseitig ausschließen, muss in den FHIR-Profilen durch einen Constraint ungesetzt werden.

Die strukturierte Angabe einer Dosierung wirkt extrem kompliziert und ist aufgrund fehlender Beispiele nur sehr schwer nachzuvollziehen. Wir empfehlen dringend, eine umfassende, schrittweise Erprobung.

Das Datum der Erfassung bzw. Änderung einer Medikationsinformation sollte verpflichtend sein.

Die vorgesehene alternative Angabe eines Codes oder eines Freitexts muss durch einen Constraint im FHIR-Profil technisch vorgegeben werden, um ggf. widersprüchliche Angaben zu vermeiden.

Wie wird sichergestellt, dass alle Systeme aus dem MIO einen BMP generieren, bei dem die einzunehmenden Arzeimittel in der gleichen Reihenfolge aufgelistet sind?

Für UCUM muss ein eng begrenztes ValueSet definiert werden, damit eine Verarbeitung des Codes durch die Primärsysteme praktikabel ist.

SNOMED CT Codes können in den Apothekensystemen nicht verarbeitet werden und damit auch nicht in die elektronisch unterstützte AMTS-Prüfung einbezogen werden. Eine manuelle Überprüfung ist im Routinebetrieb nicht möglich.
Die Eignung von SNOMED CT für den Anwendungszweck ist nachvollziehbar darzulegen. Dabei sind die Auswirkungen für die Primärsysteme und deren Anwender sowie für die Patienten in Deutschland zu beleuchten. Ggf. wird ein Mapping zu ASK und ATC benötigt.

Mehrere verschiedene Codierungen für einen Eintrag parallel zu ermöglichen, kann zu widersprüchlichen Angaben führen. Daher ist ein Constraint erforderlich, dass immer nur ein Codesystem verwendet werden kann oder Widersprüche müssen durch ein Mapping technisch ausgeschlossen werden. Anderenfalls ist das Konzept nicht praxistauglich, da eine intellektuelle Überprüfung im Routinebetrieb nicht geleistet werden kann.

Wenn ein Code zum Arzneimittel (Kap. 2.20.1) angegeben ist, muss durch das Primärsystem sichergestellt werden, dass in diesem Fall die Bestandteile nur aus der verwendeten Arzneimitteldatenbank oder über ein Mapping aus zulässigen Datenbanken zu übernehmen sind und eine manuelle Eingabe durch den Anwender nicht erlaubt ist, um widersprüchliche Angaben zu vermeiden. Ein entsprechender Operationalisierungshinweis ist erforderlich.

Wenn sowohl Code als auch Freitext-Bezeichnung angegeben werden, 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 eine ggf. aufwendige Klärung und Bereinigung des Fehlers erforderlich. Beides kann im Routinebetrieb nicht geleistet werden. Der Ansatz ist daher nicht praxistauglich.
Wenn zusätzlich zum Code eine Freitextbezeichnung für den Patienten erforderlich ist, muss die Angabe aus der Referenzdatenbank des BfArM nach § 31b verwendet werden. Ein Mapping zu allen zugelassenen Code-Systemen wird benötigt.

Für UCUM muss ein eng begrenztes ValueSet definiert werden, damit eine Verarbeitung des Codes durch die Primärsysteme praktikabel ist.

Für UCUM muss ein eng begrenztes ValueSet definiert werden, damit eine Verarbeitung des Codes durch die Primärsysteme praktikabel ist.

Da Medication.amount.numerator.value den Datentyp decimal hat: Wie wird die Packungsgröße bei einer Bündelpackung angegeben (z.B. LEVOCOMP 200 mg/50 mg Tabletten 2x100 St)?

Wenn das Arzneimittel durch eine PZN codiert ist, sollte ein Operationalisierungshinweis aufgenommen werden, dass in diesem Fall die Packungsgröße aus der Arzneimitteldatenbank zu übernehmen ist und eine Eingabe durch den Anwender nicht zulässig ist, um widersprüchliche Angaben zu vermeiden.

SNOMED CT Codes können in den Apothekensystemen nicht verarbeitet werden und damit auch nicht in die elektronisch unterstützte AMTS-Prüfung einbezogen werden. Eine manuelle Überprüfung ist im Routinebetrieb nicht möglich.
Die Eignung von SNOMED CT für den Anwendungszweck ist nachvollziehbar darzulegen.

Mehrere verschiedene Codierungen für einen Eintrag parallel zu ermöglichen, kann zu widersprüchlichen Angaben führen. Daher ist ein Constraint erforderlich, dass immer nur ein Codesystem verwendet werden kann oder Widersprüche müssen durch ein Mapping technisch ausgeschlossen werden. Anderenfalls ist das Konzept nicht praxistauglich, da eine intellektuelle Überprüfung im Routinebetrieb nicht geleistet werden kann.

Wenn das Arzneimittel durch eine PZN codiert ist, muss den Vorgaben zum E-Rezept entsprechend die Darreichungsform mit der KBV Darreichungsform codiert verpflichtend angegeben werden. Ein entsprechender Constraint ist erforderlich.
Um widersprüchliche Angaben zu vermeiden, sollte ein Operationalisierungshinweis aufgenommen werden, dass in diesem Fall die Darreichungsform aus der Arzneimitteldatenbank zu übernehmen ist und eine manuelle Auswahl durch den Anwender nicht zulässig ist.

Generell ist eine codierte Angabe im Hinblick auf eine elektronisch unterstützte AMTS-Prüfung zu bevorzugen, die Priorisierung sollte entsprechend dargestellt werden (z.B. durch einen Operationalisierungshinweis).
Wenn sowohl Code als auch Freitext-Bezeichnung angegeben werden, 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 eine ggf. aufwendige Klärung und Bereinigung des Fehlers erforderlich. Beides kann im Routinebetrieb nicht geleistet werden. Der Ansatz ist daher nicht praxistauglich.
Falls zusätzlich zum Code eine Freitextbezeichnung für den Patienten erforderlich ist, muss die Angabe aus der Referenzdatenbank des BfArM nach § 31b SGB V verwendet werden. Ein Mapping zu allen zugelassenen Code-Systemen wird benötigt.

Sollen aus den vorgegebenen "Medikationsarten" Bedarfs- und Dauermedikation die entsprechenden Zwischenüberschriften für den Ausdruck als BMP abgeleitet werden? Wie werden wiederum die weiteren Zwischenüberschriften, die der BMP zulässt, im MIO abgebildet? Vergl. dazu Tabelle 6 in Anlage 3 der BMP Spezifikation 2.7 vom 15.07.2022 <span class="nobr"><a href="https://www.kbv.de/media/sp/Medikationsplan_Anlage3_ab_01.04.2023.pdf" class="external-link" rel="nofollow">https://www.kbv.de/media/sp/Medikationsplan_Anlage3_ab_01.04.2023.pdf^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Falls keine PZN angegeben ist, muss die Angabe der Darreichungsform verpflichtend sein. Im FHIR-Profil ist ein entsprechender Constraint erforderlich.

Generell ist die Verwendung der PZN im Hinblick auf eine elektronisch unterstützte AMTS-Prüfung zu bevorzugen, die Priorisierung sollte entsprechend dargestellt werden (z.B. durch einen Operationalisierungshinweis).
SNOMED CT Codes können in den Apothekensystemen nicht verarbeitet werden und damit auch nicht in die elektronisch unterstützte AMTS-Prüfung einbezogen werden. Eine manuelle Überprüfung ist im Routinebetrieb nicht möglich.
Die Eignung von SNOMED CT für den Anwendungszweck ist nachvollziehbar darzulegen. Dabei sind die Auswirkungen für die Primärsysteme und deren Anwender sowie für die Patienten in Deutschland zu beleuchten. Es ist zu begründen, warum die aktuell verwendeten Codesysteme nicht ausreichend sind. Das Merkmal "Internationaler Standard" reicht als Begründung keinesfalls aus.

Dispensierdaten zu OTC-Arzneimitteln stehen über eRx-FD nur zur Verfügung bzw. können automatisch in die eML geschrieben werden, wenn ein eRezept vorliegt (akutell als Selbstzahler-eRezpt). Entsprechend sollte der erste Satz der Anmerkung lauten: "Sofern ein eRezept vorlag, werden die Dispensierdaten in der eML in der ePA gespeichert." In Hinblick auf den eMP sollten OTC-Arzneimittel unabhängig ob auf Arztempfehlung oder nach Beratung durch die Apotheke angewendet, nur dann in den eMP aufgenommen werden, wenn sie AMTS-relevant sind, um den Medikationsplan für Patient*innen nicht zu überfrachten bzw. um zu vermeiden, dass wichtige Informationen bei der Arzneimittelanwendung übersehen werden.

Mehrere verschiedene Codierungen für einen Eintrag parallel zu ermöglichen, kann zu widersprüchlichen Angaben führen. Daher ist ein Constraint erforderlich, dass immer nur ein Codesystem verwendet werden kann oder Widersprüche müssen durch ein Mapping technisch ausgeschlossen werden. Anderenfalls ist das Konzept nicht praxistauglich, da eine intellektuelle Überprüfung im Routinebetrieb nicht geleistet werden kann.

Die letzten beiden Sätze der Anmerkung sollte darum ergänzt werden, dass der Dispensierdatensatz nach Abgabe der Medikation automatisiert in die eML in der ePA des jeweiligen Patienten gespeichert wird.

Generell ist eine codierte Angabe im Hinblick auf eine elektronisch unterstützte AMTS-Prüfung zu bevorzugen, die Priorisierung sollte entsprechend dargestellt werden (z.B. durch einen Operationalisierungshinweis).
Wenn sowohl Code als auch Freitext-Bezeichnung angegeben werden, 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 eine ggf. aufwendige Klärung und Bereinigung des Fehlers erforderlich. Beides kann im Routinebetrieb nicht geleistet werden. Der Ansatz ist daher nicht praxistauglich.
Falls zusätzlich zum Code eine Freitextbezeichnung für den Patienten erforderlich ist, wird eine Referenzdatenbank inklusive Mapping zu den zugelassenen Code-Systemen benötigt.

Das Zusammentragen von Medikationsdaten kann im Kontext von Gesprächen mit Patient*innen in Arztpraxis oder Apotheke erforderlich werden. Apotheken verfügen über eingeschränktere Zugriffsmöglichkeiten innerhalb der ePA als Ärzte. Apotheken haben keinen Zugriff auf Laborbefunde und Arztbriefe, die hier in der Beschreibung genannt werden. Die gelisteten Beispiele sollte daher insb. um Dokumente erweitert werden, auf die Apotheken zugreifen könnten, z.B. NFDM. Im BMPN könnte der Task "Vorbefunde und/oder Klinische Daten erheben" beide Professionen abbilden, indem dieser z.B. "Weitere relevante Daten erheben" lautet.

Bei einem solch umfassenden Codesystem wie SNOMED CT ist ein abgeschlossenes ValueSet zu definieren, das verbindlich zu nutzen ist, wenn der Code verwendet wird. Die beipielhafte Angabe möglicher Werte ist nicht ausreichend, da auch andere Werte angegeben werden können und eine technische Verarbeitung dann nicht mehr möglich ist.

Bei einem solch umfassenden Codesystem wie SNOMED CT ist ein abgeschlossenes ValueSet zu definieren, das verbindlich zu nutzen ist, wenn der Code verwendet wird. Die beipielhafte Angabe möglicher Werte ist nicht ausreichend, da auch andere Werte angegeben werden können und eine technische Verarbeitung dann nicht mehr möglich ist.

Im Kontext der E-Rezeptbelieferung durch die Apotheke kommt es insb. dadurch zu Abweichungen zwischen Verordnungs- und Dispensierdatensatz, dass sich Arzneimittelnamen auf Grund der jeweiligen Belieferungsverträge der Krankenkassen unterscheiden. Eine passende Bezeichnung für den Text in der Klammer wäre z.B. "bei Substitution gemäß Belieferungsverträgen der Krankenkassen".

Welchen Zweck hat die redundante Angabemöglichkeit der allergieauslösenden Substanz? Grundsätzlich darf die Angabe nur einmal erfolgen, um Widersprüche zu vermeiden.
Wir verweisen zudem auf unsere Kommentare zu Infomodell, Kap. 2.10.2.1 Substanz - Code-Auswahl.

Die Spezifizierung eines Ausdrucks des eMP als BMP befindet sich noch in Entwicklung (vergl. auch Grundprozess "Aktualisierung medikationsrelevanter Daten"). Welche Informationen darin enthalten sein werden kann zum aktuellen Zeitpunkt noch nicht abschließend beschrieben werden. Der letzte Satz in diesem Absatz sollte daher lauten "Ein Medikationsplan kann als BMP ausgedruckt werden"

In der Beschreibung der Arzneimittelabgabe auf E-Rezept sollte noch deutlicher herauskommen, dass der eRezept-Fachdienst automatisch die Dispensierinformationen in der ePA in der eML speichert. Ist die Aktualisierung eines eMP erforderlich, muss diese separat erfolgen, d.h. händisch bzw. mit Unterstützung des AVS.

SNOMED CT Codes können in den Apothekensystemen nicht verarbeitet werden und damit auch nicht in die elektronisch unterstützte AMTS-Prüfung einbezogen werden. Eine manuelle Überprüfung ist im Routinebetrieb nicht möglich.
Die Eignung von SNOMED CT für den Anwendungszweck ist nachvollziehbar darzulegen. Dabei sind die Auswirkungen für die Primärsysteme und deren Anwender sowie für die Patienten in Deutschland zu beleuchten. Ggf. wird ein Mapping zu ASK und ATC benötigt.

Mehrere verschiedene Codierungen für einen Eintrag parallel zu ermöglichen, kann zu widersprüchlichen Angaben führen. Daher ist ein Constraint erforderlich, dass immer nur ein Codesystem verwendet werden kann oder Widersprüche müssen durch ein Mapping technisch ausgeschlossen werden. Anderenfalls ist das Konzept nicht praxistauglich, da eine intellektuelle Überprüfung im Routinebetrieb nicht geleistet werden kann.

Wenn sowohl Code als auch Freitext-Bezeichnung angegeben werden, 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 eine ggf. aufwendige Klärung und Bereinigung des Fehlers erforderlich. Beides kann im Routinebetrieb nicht geleistet werden. Der Ansatz ist daher nicht praxistauglich.
Falls zusätzlich zum Code eine Freitextbezeichnung für den Patienten erforderlich ist, wird eine Referenzdatenbank und ein Mapping zu den zugelassenen Code-Systemen benötigt.

Wozu wird das administrative Geschlecht der behandelnden Person benötigt?

Die generelle, undifferenzierte Bevorzugung von SNOMED CT ist nicht ausreichend begründet. Die Eignung für den jeweiligen Anwendungsbereich ist detailliert und nachvollziehbar darzulegen. Dabei müssen die Aspekte Praxistauglichkeit und aktuelle Nutzung in den jeweiligen Sektoren betrachtet werden und es muss auf dieser Basis begründet werden, warum SNOMED CT jeweils am besten geeignet sein soll.

Das in FHIR R4 spezifizierte Element "category" ist derzeit nicht Teil der MIO-Spezifikation enthalten. Es enthält ein preferred Binding auf die "Medication usage category codes" von HL7, im folgenden: "inpatient", "outpatient", "community" (für Pflegeeinrichtungen und Hospize) und "patientspecified" für z.B. OTC.

<span class="nobr"><a href="https://simplifier.net/packages/hl7.fhir.r4.core/4.0.1/files/79011" class="external-link" rel="nofollow">https://simplifier.net/packages/hl7.fhir.r4.core/4.0.1/files/79011^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Eine korrekte Annotation, welches Medikament aus welchem Setting heraus genommen wurde, ist in der Spezifikation sonst nicht möglich. Die derzeitigen Entwicklungen wie Ambulantisierung etc. müssen bereits zeitnah in sektorübergreifenden Forschungsfragen untersucht werden, daher ist eine explizite Kodierung des Settings von Nutzen.

Eine Aktualisierung der ePA-Daten muss auch ohne gesteckte eGK möglich sein.
So kann es sein, dass sich erst im Zuge der Bestellung der Fertig-AM ergibt, welche Artikel tatsächlich lieferbar sind.
Auch eRp-Änderungen finden nicht immer in Gegenwart des Patienten statt, sondern häufig im Lauf des Tages.
Außerdem zieht sich der Abverkaufsvorgang sonst noch weiter in die Länge (Abruf, Bearbeitung, Rabattvertragsprüfung, Verfügbarkeitsprüfung, Dispens, Prüfung Abrechenbarkeit per FiveRX, Technische Sicherungseinrichtung der KassensicherungsVO, evtl Kartenzahlung, Aktualisierung ePA).

Da die elektronische Medikationsliste (eML) nur durch den eRezept-Fachdienst befüllt wird, finden sich Arzneimittel, die im Krankenhaus verabreicht werden, nicht auf der eML.
Beispielsweise würde ein Depot-Neuroleptikum, welches stationär verabreicht wurde aber nach der Entlassung noch für einige Wochen wirksam ist, nicht auf der eML erscheinen. Im Arztbrief würde es nur in nicht strukturierter Form erscheinen und da es keine Entlass-Medikation ist, würde es auch nicht im eMP erscheinen.
ggf. wäre es hilfreich, diese Problematik in das Fallbeispiel aufzunehmen, da sich meiner Ansicht nach hier eine mögliche Fehlerquelle verbirgt.

"Wer ist für die erfolgreiche Übermittlung verantwortlich?
Wie wird der Nachweis erbracht?"

"Störungen in der TI-Struktur: Müssen Prozesse neu angestoßen werden oder werden sie automatisch abgearbeitet, wenn die Konnektivität wieder vorliegt?
Wie ist es grundsätzlich mit der Störanfälligkeit?"

Wird damit die Freitext-VO nicht mehr zum WF gehören, sondern ausschließlich Rezeptierung über PZN?

"Sektions-/ LEI-übergreifende Pflege bedingt einheitliche Termini und Berabeitungskriterien
Welche Daten dürfen kollaborativ gepflegt werden?
Gibt es Ausschlusskriterien?
Wird es eine Historie der Daten geben?"

Wie ist es mit Stornierungen?

"Anlage verschiedener Medikationslisten kann zu Redundanzen führen
Wer darf eine Medikationsliste anlegen?
Ist die Anzahl der Medikationslisten begrenzt?
"

In den Fallbeispiel zum dgMP wird davon ausgegangen, dass bei Aufnahme oder Verlegung eine Medikationsanamnese bzw. Umstellung gemeinsam mit der Krankenhausapotheke erfolgt. Das wäre wünschenswert, aber aktuell stehen sicher nicht genügend Krankenhausapotheker zur Verfügung, um diese Aufgabe zu leisten.

In der Regel werden diese Prozesse ärztlich durchgeführt, sodass die Anwendung des dgMP auch hier auf speziell auf das ärztliche Personal zugeschnitten sein sollte z.B. Aktualisierung des MIO Medikationsplans (im Beispiel durch die Stationsapotheker:in durchgeführt) bei Entlassung der Patientin.

Die UX-Visualisierungen sind sehr hilfreich, sollten jedoch um folgende Aspekte ergänzt werden:

• Verordnungsart: Hier sollte zwischen PZN-, Wirkstoff- und Freitext-VO unterschieden werden. Alle drei haben unterschiedliche Input- und Output-Größen (unstrukturierte Rezeptur als Freitext hat in der Abgabe keine Daten außer "Rezeptur").
• Rahmenvertrag zur AM-Abgabe: Es ist nicht dargestellt, dass die Auswahl des Fertig-AM nicht nach Lagerbestand o.ä. ausgewählt wird, sondern nach klaren Regeln des entsprechenden Rabattvertrages. Hierfür ist z.B. bei Lieferengpässen eine Abweichung von der Verordnung möglich. Diese Änderungen sollten enthalten / gekennzeichnet sein.
• Chargennummern: OTC-Artikel benötigen in der Abgabe keine Chargennummern / Scan.
  Insgesamt ist der Kassenprozess viel komplexer und kann sicher nicht Teil dieser Visualisierungen sein.

Bei der Durchsicht der einzelnen FHIR-Objekte fällt auf, dass je nach FHIR-Spezifikation (eRezept. Medizininformatik-Initiative, ISIK-Schnittstelle, KBV-MIO) unterschiedliche Lösungen für den gleichen Aspekt gewählt wurden.
Während es beispielsweise in der ISIK-FHIR-Spezifikation für die Art der Medikation (im BMP noch unstrukturiert als Zeilenüberschrift angegeben) eigene Objekte gibt, braucht in der KBV-MIO-Variante für eine "Dauermedikation" nur ein Startzeitpunkt angegeben werden, das Element für den Endzeitpunkt bleibt einfach leer (siehe auch 2.21 Medikations-Information, Phase I).
Die zeitlichen Ressourcen alle Objekte zu vergleichen, stehen mir/uns nicht zur Verfügung, daher nur dieses Beispiel.
Es wäre aber wahrscheinlich besser, wenn die einzelnen FHIR-Spezifikationen zum gleichen Thema nicht zu stark von einander abweichen würden. Abweichungen einer deutschen Spezifikation von der Internationalen sind nachvollziehbar.

In vielen FHIR-Profilierungen des MIOs Medikationsplan besteht die Möglichkeit für die Coding-Elemente Kodes aus unterschiedlichen Kodiersystemen zu hinterlegen. Aus der Profilierung und den vorliegenden Beschreibungen geht jedoch nicht hervor für welche Gesundheits- bzw. Medikationsinformation sich welches Kodiersystem am besten eignet. Damit eine eindeutige Kodierung der Informationen gewährleistet werden kann, empfehlen wir das Hinzufügen von Kurzbeschreibungen zu den jeweiligen Kodiersystemen. Beispielsweise könnten Informationen, wie die Kurzbeschreibung und Definition direkt im Profil auf Simplifier hinterlegt werden.

Gemäß §355 Abs. 3 SGB V „Bei der Fortschreibung der Vorgaben zum elektronischen Medikationsplan hat die Kassenärztliche Bundesvereinigung die Festlegungen nach § 31a Absatz 4 und § 31b Absatz 2 zu berücksichtigen und sicherzustellen, dass Daten nach § 31a Absatz 2 Satz 1 sowie Daten des elektronischen Medikationsplans nach § 334 Absatz 1 Satz 2 Nummer 4 in den von den Vertragsärzten und den Ärzten in zugelassenen Krankenhäusern zur Verordnung genutzten elektronischen Programmen und in den Programmen der Apotheken einheitlich abgebildet und zur Prüfung der Arzneimitteltherapiesicherheit genutzt werden können.“
Die Referenzierung auf die Referenzdatenbank ist sicherzustellen. Dies dient auch einer einheitlichen Darstellung von Daten zu Fertigarzneimitteln und dem Austausch in Europa gemäß § 219d SGB V.

In Bezug auf Arzneimitteldaten muss auch das europäische Datenmodell (SPOR) als Standard zu verwenden sein, welches in DE über die AmAnDa-Datenbank umgesetzt ist. Die Referenzdatenbank nach §31b SGB V wird seit dem 01.04. Vom BfArM, aus der AmAnDa-DB zur Verfügung gestellt. Diese Arbeiten werden auch in Arbeiten zum Terminologieserver einfließen. Insb. vor dem Hintergrund des europäischen Datenaustausches sollten rein nationale Lösungen vermieden werden.

Das FHIR ValueSet "KBV_VS_MIO_EMP_Dose_Form_SNOMED_CT" beinhaltet lediglich eine Expansion, es existiert jedoch keine Valueset-Definition (ValueSet.compose). Alternative Expansions lassen sich somit nicht mehr automatisiert generieren. Wir empfehlen für sämtliche ValueSets, die Bestandteil einer Spezifikation sind auch die Definition mit anzugeben.

Diese ConceptMap enthält unter anderem Verknüpfungen zu deutschen Repräsentationen einiger LOINC-Kodes, dessen Übersetzungen bereits über die LOINC Linguistic Variants vorhanden sind. Zudem fällt auf, dass nicht alle LOINC-Kodes, die im MIO Medikationsplan angewendet werden, über ein KBV-spezifisches CodeSystem eine deutsche Übersetzung erhalten, beispielsweise für die Kodierung von Körpergröße (<span class="nobr"><a href="https://simplifier.net/packages/kbv.mio.emp/1.0.0-kommentierung.1/files/2383008" class="external-link" rel="nofollow">https://simplifier.net/packages/kbv.mio.emp/1.0.0-kommentierung.1/files/2383008^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>) und Körpergewicht (<span class="nobr"><a href="https://simplifier.net/packages/kbv.mio.emp/1.0.0-kommentierung.1/files/2383009" class="external-link" rel="nofollow">https://simplifier.net/packages/kbv.mio.emp/1.0.0-kommentierung.1/files/2383009^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>) existiert kein KBV-spezifisches CodeSystem im MIO Medikationsplan.

Mittels der ConceptMap ist auch in uneinheitlicher Umgang mit SNOMED CT Übersetzungen erkennbar. Auch in Anbetracht einer regelmäßigen Aktualisierung der German National Edition und damit der Bereitstellung deutscher Übersetzungen ist die Herangehensweise eigene Übersetzungen über separate CodeSysteme und anschließend über eine ConceptMap komplex und unter Umständen aufwändig für die zukünftige Implementierung.

Das BfArM plant im Zuge der Bereitstellung eines nationalen Terminologieservers zukünftig Übersetzungen von LOINC und SNOMED CT in Form von „CodeSystem-Supplements“ herauszugeben, welches ermöglicht Übersetzungen als „designations“ zu verwenden.

Auf der Seite <span class="nobr"><a href="https://mio.kbv.de/pages/viewpage.action?pageId=251297970" class="external-link" rel="nofollow">https://mio.kbv.de/pages/viewpage.action?pageId=251297970^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> ist eine Liste vorhanden, die alle Kodiersysteme bzw. Terminologien, welche im MIO Medikationsplan verwendet werden, aufführt.

Im Zuge der Implementierung eines nationalen Terminologieservers nach § 355 Absatz 12 und Absatz 13 SGB V haben die gematik und das BfArM die vom BfArM verantwortenden Kodiersysteme in ein FHIR-Format konvertiert. Hierfür wurde ebenfalls die Canonical URL für das folgende Kodiersystem angepasst, die aktuell im MIO Medikationsplan verwendet werden:
ICD-10-GM <span class="nobr"><a href="https://terminologieserver.bfarm.de/fhir/CodeSystem/icd10gm" class="external-link" rel="nofollow">https://terminologieserver.bfarm.de/fhir/CodeSystem/icd10gm^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>
Darüber hinaus ist ebenfalls eine Anpassung der Canonical URL für die Alpha-ID-SE und für den ATC-GM in Planung.
Wir schlagen vor, die neue Canonical URL bereits im MIO Medikationsplan zu berücksichtigen.

Auf der Seite <span class="nobr"><a href="https://mio.kbv.de/pages/viewpage.action?pageId=251297970" class="external-link" rel="nofollow">https://mio.kbv.de/pages/viewpage.action?pageId=251297970^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> ist eine Liste vorhanden, die alle Kodiersysteme bzw. Terminologien, welche im MIO Medikationsplan verwendet werden, aufführt. Bei einigen Kodiersystemen ist eine spezifische Version angegeben. Diese Versionen sind nicht immer in den FHIR-Spezifikationen referenziert. Es könnte passieren, dass von umsetzenden Akteuren diese Versionsangabe als empfohlene Version suggeriert wird. Dies könnte dazu führen, dass beispielsweise veraltete Darreichungsformen, oder veraltete ICD-10-GM Kodes im MIO Medikationsplan umgesetzt werden.

Wir schlagen deshalb vor, die Versionsangaben für Kodiersysteme, die regelmäßig aktualisiert werden, zu entfernen und einen Hinweis hinzuzufügen, dass stets die aktuelle Version zu verwenden ist.

Softwaresysteme für das nationale Gesundheitswesen sollten vorzugsweise mit der German National Edition umgehen und strukturierte Daten anhand dieser verarbeiten können.
Wir schlagen deshalb vor, anstelle von zwei unterschiedlichen Versionen der internationalen SNOMED CT Edition, bevorzugt versionsübergreifend die German National Edition in den Profilen des MIOs Medikationsplan zu integrieren: <span class="nobr"><a href="http://snomed.info/sct/11000274103" class="external-link" rel="nofollow">http://snomed.info/sct/11000274103^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>, siehe <span class="nobr"><a href="https://www.hl7.org/fhir/R4/snomedct.html" class="external-link" rel="nofollow">https://www.hl7.org/fhir/R4/snomedct.html^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> Abschnitt 4.3.1.0.3

Auch im Hinblick auf die Bereitstellung der Übersetzung von Display-Werten in deutscher Sprache ist eine bevorzugte Verwendung der nationalen Edition von Vorteil. Durch die aktuelle Implementierung von SNOMED CT Codesystem/Valueset mittels eines „required-Bindings“ bei einigen Coding-Elementen (beispielsweise: <span class="nobr"><a href="https://simplifier.net/packages/kbv.mio.emp/1.0.0-kommentierung.1/files/2383000" class="external-link" rel="nofollow">https://simplifier.net/packages/kbv.mio.emp/1.0.0-kommentierung.1/files/2383000^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>) führt dazu, dass nicht ohne Probleme die internationale Version durch die National Edition ersetzt werden kann.

Ist es möglich, aus der ePA/ dem eMP heraus ein Rezept auszustellen, das initial von einer anderen Person ausgestellt wurde?

Die Darreichungsform (=Dosiereinheit) "Zäpfchen" (Suppositorien) fehlt, die explizit bei Kindern eine sehr häufige Applikationsart darstellt.

Es wäre für uns von großem Vorteil, eine Abstimmung mit den ISiK-Profilen der Stufe 4 zu erwägen, da andernfalls der Implementierungsaufwand erheblich steigt. Wir haben festgestellt, dass es an einigen Stellen Unterschiede gibt, zum Beispiel in der Namensgebung (Medikament, MedikationsListe, MedikationsInformation) sowie in den verwendeten Code-Systemen. Daher wäre eine Abstimmung zwischen MIO42 und gematik äußerst hilfreich.

Zur Einteilung der Reaktion in die Schweregrad: Werden diese Codes in SNOMED CT abgebildet?

Value Set Route of Administration: Im Rahmen der Medikationsanweisung kann die Verabreichung über SNOMED CT oder EDQM kodiert werden. Dies ist jedoch nicht in den ValuSets wiederzufinden

Eine Erweiterung um die EDQM Codes aus ISiK ist wünschenswert. Zudem ist aus unserer Sicht ein offizielles Mapping zwischen SNOMED CT, EDQM und den KBV Formularen aus dem BMP sinnvoll
(KBV_VS_MIO_EMP_DOSE_FORM_SNOMED_CT)

• Wie kommt diese Auswahl an AMTS-relevanten Beobachtungen / Messungen zustande? Kann oder soll diese Liste noch ergänzt werden?

Weitere relevante Messungen könnten exemplarisch auch sein:

• TSH (Schilddrüsenhormon):
wichtig z.B. vor der Gabe von Jod-haltigen Kontrastmitteln im Rahmen von speziellen Röntgenuntersuchungen (CT, Szinti etc.)

• GOT / GPT / gamma-GT / CHE (Leberwerte):
Indikationseinschränkung bei allen Medikamenten, die über die Leber verstoffwechselt werden (z.B. Antidepressiva, etc.)

Da es sich um eine stationäre Aufnahme der Patientin in einem Krankenhaus handelt, sollte es statt "in der Praxis" besser "in der stationären Einrichtung" heißen.

– Wenn das Fallbeispiel konsequent durchdacht wird, hat die Patientin im Ergebnis zwei E-Rezepte. Welches davon soll der Apotheker jetzt dispensieren? Dies führt ggf. zu Verwirrungen und Mehraufwänden.

– Was passiert, wenn tatsächlich zwei Rezepte vorhanden sind und "konkurrierende" Medikamente verschrieben wurden (z.B. Akutklinik verschreibt MonoEmbolex Spritzen, Rehklinik verschreibt Xarelto)?

Bezug: "<span class="error">[…]</span> zeitnah in eine Fachklinik für Geriatrie zur geriatriatrische Komplexbehandlung (GKB) verlegt…<span class="error">[...]</span> auch werden nötige Entlass-Rezepte erstellt."

– Grundsätzlich soll hier der Prozess der Ausstellung eines Rezeptes bei Entlassung der Patientin (aus der stationären Behandlung) dargestellt werden. Dies ist in den Rahmenverträgen der KBV zum Entlassmanagement sowohl für Akutkrankenhäuser als auch für Rehakliniken eindeutig definiert.

Prinzipiell gibt es 3 Möglichkeiten der Entlassung:

I. Entlassung in die ambulante Weiterversorgung
II. Entlassung in die kurzfristige ambulante Weiterversorgung mit geplanter stationärer Aufnahme in einer Rehaklinik (innerhalb weniger Tage)
III. Direktverlegung in die Rehaklinik / anderes Krankenhaus

Bei einer Direktverlegung aus dem Akutkrankenhaus in die Reha - so wie im Fallbeispiel dargestellt - wird aber normalerweise kein Rezept ausgestellt, da die Rehaklinik den Medikamentenbedarf aus ihrer Apotheke für die Zeit der stationären Rehabilitationsmaßnahme vorhält.

Die Formulierung im Fallbeispiel sollte ggf. angepasst werden: Bei Entlassung in die ambulante Weiterbehandlung -> eRezept
bei Direktverlegung -> eMP

Ist ggf. die Anpassung der Prozessdarstellung in BPMN zur Vermeidung von Irritationen sinnvoll?

Bezug: "....Tetanus-Auffrischungsimpfung, da die letzte Tetanusimpfung schon zu lange her ist. Diese wird in das MIO Impfpass eingetragen."

– Aus unserer Sicht stellt sich die Realität anders dar:
Da die Patientin mit der administrativen Aufnahme im KIS des Krankenhauses einen Datensatz bekommt, wird die Dokumentation sicherlich nur im KIS erfolgen. Eine aktive Befüllung der ePA, einen Eintrag im MIO Impfpass (oder die Neu-Anlage) durch die Mitarbeiter:innen der Notaufnahme halten wir für unwahrscheinlich. Zu welchem Zeitpunkt ein Eintrag im Impfpass oder z.B. auch im Allergiepass erfolgen kann, müsste mit den KIS-Anbietern abgestimmt werden.

Daraus ergeben sich die folgenden Fragen:

• Zu welchem MIO Impfpass wird hier ein Bezug hergestellt?
• Gilt dies für das bereits freigegebene und seit 2022 gültige MIO Impfpass oder ist Erstellung eines neuen MIOs geplant?

Bezug: "Die Anamnese erfolgt sowohl ärztlich (…) sowie durch eine/n Apotheker:in für die Medikationsanamnese und die Umstellung der Medikation auf die Hausliste des Krankenhauses"

– Die Verfügbarkeit von Apotheker:innen in Notaufnahmen ist nach unserer Einschätzung eher die Ausnahme, sicherlich aber kein gängiger Standard. Teilweise werden Medikamente in Kliniken aber auch über Klinikverbünde bestellt und vertrieben, sodass unter Umständen auch überhaupt kein/e Apotheker:in im Haus ist. Daher sollte die explizite Nennung im Fallbeispiel zur Vermeidung von Konflikten verändert werden. Die Medikationsanamnese und die Umstellung auf die Hausliste erfolgt durch die behandelnden Ärzt:innen.

Bezug: ".."Dies erfolgt gemeinschaftlich durch den/die Stationsapotheker:in sowie den/die Stationsärzt:in."

– Gleiches gilt auch für die Station. I.d.R gibt es zumindest bei den größeren Häusern eine Hausapotheke mit Apotheker:innen und PTA's, die bei Bedarf jederzeit gefragt werden können. Auch hier schlagen wir vor, die Formulierung entsprechend zu ändern.

Bezug: "Die Notärztin liest den Notfalldatensatz (Patientenkurzakte) aus, sowie den elektronischen Medikationsplan und die elektronische Medikationsliste"

• In den Fahrzeugen des Rettungsdienstes gibt es aktuell zumindest für die Notfallsanitäter Tablets (mit Kartenlesefunktion) zur digitalen Dokumentation. Für das Notarztwesen ist dies zumindest in Bayern noch nicht flächendeckend vorhanden (Status quo in anderen Bundesländern ist nicht bekannt).
Es kann aktuell aber nur mit der eGK gearbeitet und so zumindest der Stammdatensatz abgerufen werden.

• Konnektoren, die Voraussetzung für die Anbindung an die TI darstellen, sind bisher in keinem Fahrzeug des Rettungsdienstes verbaut und wahrscheinlich auch nicht in Planung. Solange der eMP, eML und anderes auf der eGK gespeichert wird, ist ein Zugriff auf relevante Daten möglich.

• Querverweis "Abbildung gesetzliche Rahmenbedingungen" (<span class="nobr"><a href="https://mio.kbv.de/display/EMP1X0X0/Gesetzliche+Rahmenbedingungen+des+dgMP):" class="external-link" rel="nofollow">https://mio.kbv.de/display/EMP1X0X0/Gesetzliche+Rahmenbedingungen+des+dgMP):^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> Ab Bereitstellung der "ePA für alle" und des elektronischen Medikationsplans als MIO (gemäß § 355 SGB V) darf der elektronische Medikationsplan nur noch in der ePA gespeichert werden. War auf der elektronischen Gesundheitskarte ein elektronischer Medikationsplan vorhanden, so muss dieser gelöscht werden (§ 358 Ab. 8 SGB V).

Daraus ergeben sich die Fragen:
• Ist für die vorhandenen eMPs auf der eGK ein Migrationsprozess / Migrationsplan vorgesehen?
• Gilt dies an dem Zeitpunkt, ab dem die ePA 3.1 für den konkreten Versicherten/Patienten erstmalig aktiv ist? (Also bei Einhaltung des Zeitplans, 15.07.2025 für alle Versicherten, die nicht zuvor schon widersprochen haben (Opt-out-Regelung gem. §342(1) Satz 2).)

• Damit sind Notfalldatensatz, Medikationsliste und Plan, etc für die Mitarbeiter im Rettungsdienst nicht mehr verfügbar. Und hier wäre es besonders wichtig, da verletzte oder schwer erkrankte Menschen meistens nicht mehr in der Lage sind, ihre Medikamente sinnvoll aufzuzählen. Häufig liegen vor Ort auch keine aktuellen Medikationspläne vor.

• Ca 60% aller Einsätze im Rettungsdienst werden ohne Notarzt durchgeführt. Dafür alternativ sehr gut ausgebildet sind sogenannte Notfallsanitäter (NFS) - künftig möglicherweise mit Unterstützung durch Telelnotarzt-Systeme. Auch bei Einsätzen ohne Notarzt müssen patientenrelevante Daten (wie Medikationsplan oder Vorerkrankungen) eruiert werden, um eine adäquate Therapie und später gute Übergabe in der Zielklinik zu ermöglichen. Konsequenterweise brauchen auch die medizinischen Angestellten im Rettungsdienst die Berechtigung diese Daten von der eGK abrufen zu können. Hieraus ergibt sich ebenfalls ein Datendefizit, sobald die Daten nicht mehr auf eGK gespeichert werden und ein Zugang zur ePA aus dem RTW heraus nicht möglich ist.

• Gleiches gilt analog auch für die ärztlichen Kollegen im KV-ärztlichen Notfalldienst, die im Fahrdienst (Hausbesuche) unterwegs sind.
--> Haben Ärzte bei Hausbesuche/Notarzt Zugriff auf die ePA?

Wie werden folgende Fälle in der ePA + eMP geregelt?

a) Ein Patient wird aus dem Krankenhaus entlassen und erhält ein Medikament. Damit hat er Anspruch auf einen eMP in der ePA 3.0 (Rahmenvertrag Entlassmanagement, §7 Abs. 3, Satz 3). Nun geht der Patient zu seinem Hausarzt. Dieser verschreibt ihm evtl. noch ein weiteres Medikament. Da es sich dann um eine ambulante Versorgung handelt, hat der Patient keinen Anspruch mehr auf einen eMP in der ePA. Muss der vorhandene eMP mit einem Medikament gelöscht oder muss der eMP durch den Arzt weitergepflegt werden, auch wenn ein Patient nur 2 dauerhaft einzunehmende Medikament hat?

b) Ein Patient nimmt aktuell drei, durch den Hausarzt verordnete Medikamente dauerhaft ein. Durch eine Medikamentenanpassung entfällt ein Medikament. Da der Patient nun nur noch zwei Medikamente einnimmt, hat er keinen Anspruch mehr auf einen eMP in der ePA 3.0. Muss hier der eMP aus der ePA gelöscht werden?

Die Struktur der Spezifikation stellt eine Reihe von Herausforderungen dar, die es schwierig machen, sich darin zurechtzufinden. Zum Beispiel variieren die Strukturen und Bezeichnungen zwischen dem Informationsmodell und den FHIR-Ressourcen. Darüber hinaus funktionieren einige Verlinkungen nicht ordnungsgemäß oder führen zu falschen Inhalten. Das Gesamtkonzept der dgMP ist uns noch nicht vollständig klar. Dadurch entstehen Unsicherheiten darüber, welche Teile zu welchem Zeitpunkt umgesetzt werden müssen und welche Teile spezifisch für eMP, eML und AMTS-relevante Zusatzinformationen sind, sowie wie das Gesamtbild letztendlich aussehen soll. Eine erleichterte Bedienung und eine umfassende Übersicht über das Gesamtsystem würden wir begrüßen.

Es gibt eine uneinheitliche Verwendung von gendergerechter Sprache. Wir sind der Meinung, dass gendergerechte Sprache an dieser Stelle nicht erforderlich ist, jedoch sollte sie einheitlich angewendet werden. Darüber hinaus empfehlen wir, die Mappings von Conceptcodes in Deutschland einheitlich festzulegen und zu verwenden.

Dieses Profil wird auf den Profilen, die im Simplifier veröffentlicht sind, nicht referenziert.

1. Hier wird in der Beschreibung von "einer Liste" geschrieben. Die Kardinalität von entry ist jedoch 0..*. Soll es hier nur eine Liste geben, oder ist geplant, dass in späteren Phase womöglich weitere Listen mit angebunden werden? Aktuell wird hier nur ein Typ an Liste referenziert. Daher die Annahme, dass womöglich eine 1..0 Kardinalität ausreicht.

2. Der entry selber ist vom Typ auch eine Liste. Ist angedacht, dass hier potenziell mehrere Listen vom gleichen Typ hinterlegt werden oder soll immer nur genau eine Liste an KBV_PR_MIO_EMP_List_AllergyIntolerance hinterlegt werden?

Können Elemente ignoriert werden, die nicht als MUST-Support gekennzeichnet sind? Es geht hier insbesondere um Elemente, die laut Profilbeschreibung eine 1..1, 1..* Kardinalität haben (also "mindestens einmal vorhanden"). Beispielhaft ist der "title" im Profil KBV_PR_MIO_EMP_Composition.

Beim Format der FHIR-Ressourcen wurde als Format JSON angegeben. Bisher wurde für alle FHIR Formate (eRP, B1/B2, ...) das XML-Format gewählt.

1. Hat Kardinalität von 1..*, ist aber nicht als must-support gekennzeichnet.
2. Verweist auf die Basisprofile für Practitioner und PractitionerRole - sollten hier besser die MIO-Varianten dieser Profile verwendet werden?

Handelt es sich bei "Patient (ePA)" um ein FHIR-Profil, dass im Rahmen der ePA vorgegeben wird? Hierzu konnten auf Simplifier kein passendes Profil gefunden werden. In den FHIR-Profilen auf Simplifier zum MIO-MP wird nur auf das Basisprofil des Patienten von HL7 verwiesen.

Wenn z.B. eine Allergie in einem eMP durch SNOMED CT codiert erfasst wird und ein anderes PVS-System hat keine SNOMED CT-Anbindung, wie wird garantiert, dass die erfassten Informationen korrekt angezeigt werden können?

Durch die bessere und ausführlichere Erfassung von Dosierungen eines Medikaments muss es möglich sein, diese Informationen auf einem BMP auch drucken zu können. Wird es eine Neufassung des aktuellen BMP geben oder werden die im eMP strukturiert erfassten Dosierungen bei einem gedruckten BMP „nur“ als Freitext aufgedruckt und im QR-Code erfasst?

Derzeit gibt es noch keine genauen Feldbeschreibungen bzgl. der Länge von String-Elementen. Für den BMP sind die Feldbeschreibungen genau definiert. Gibt es hier noch Nachbesserungen?

1. Wo werden gebundene Zusatzzeilen aus einem BMP im MIO eMP abgespeichert?
2. Was passiert mit Überschriften bzw. Zwischenüberschriften aus einem BMP?
3. Kann das Druck-Kennzeichen, ob z.B. das Geschlecht gedruckt wird, erst beim erstellen eines BMPs erfolgen?
4. Die Patient:innen werden nur über die KVNR identifiziert, wie ist die Regelung zum Druck eines BMPs? Die Daten zu den Patient:innen müssen dann aus dem Stammdaten eines PVS ausgelesen werden. Ist diese Annahme richtig?

Das Prozessdiagramm ist auf den niedergelassenen Bereich zugeschnitten.

Im Krankenhaus werden Patienten häufig auch behandelt, z.B. im Rahmen operativer Eingriffe. Insofern wird im Krankenhaus, wie tw. auch im niedergelassenen Bereich, nicht nur „Diagnostik“ durchgeführt, sondern Medikamentenbedarfe ergeben sich auch aus der durchgeführten Behandlung. Bitte das Diagramm als nur für den niedergelassenen Bereich geltend kennzeichnen oder entsprechend erweitern.

Für eine vollständige und sicher Darstellung einer Verordnung ist neben dem Name des Arzneimittels/Wirkstoff, der Formulierung, der Stärke des Formulierten Arzneimittels, auch der Applikationsweg notwendig.
Im aktuellen Medikationsplan und vielen Resourcen wird nur auf Formulierung des Arzneimittels hingewiesen und der Applikationsweg extrapoliert.
Bestimmte Formulierungen könne über verschieden Applikationswege geben werden z.B. oral, buccal oder Magensonde, oral oder IV und SC

Hallo liebes dgMP-Team,
in der Übergangsphase werden ggf. nicht alle Primärsysteme direkt das dgMP anbieten, bzw. die Verbreitung zunächst noch gering sein.
Für diese Fälle wäre es wichtig, dass ein Ausdruck des eMPs (zB für die Patient:innen, die keine ePA-App nutzen) für eine Übergangszeit den bereits etablierten QR-Code enthält.

Hallo liebes dgMP-Team,
in ambulanten Praxen kommen Patienten mit einem BMP an, zu dem es im PVS der Praxis keine Informationen gibt. Diese BMPs müssen perspektivisch alle in einen eMP umgewandelt werden. Eine technische Unterstützung ist in der Spezifikation des MIOs nirgends beschrieben.
Wir bitten daher darum, auch hier einen Migrationsweg zu beschreiben, an den sich die Primärsystemanbieter halten müssen und der sicherstellt, dass die Migration weitestgehend automatisiert erfolgt.

Hallo liebes dgMP-Team,
Zum Start des MIOs werden auf der eGK gespeicherte eMPs in das dgMP überführt werden müssen. Dies geschieht in der Leistungserbringerumgebung und darf dort keinen Zusatzaufwand auslösen.
Wir bitten daher darum, einen Migrationsweg zu beschreiben, an den sich die Primärsystemanbieter halten müssen und der sicherstellt, dass die Migration weitestgehend automatisiert erfolgt.

Hallo liebes dgMP-Team,
zum 15.0.7.25 werden ja die nach §31a SGB V Anspruchsberechtigten neben der eML einen eMP entsprechend der vorliegenden Spezifikation haben.
In den Fällen, in denen beides vorliegt, sollte die Nutzerführung bei der Bearbeitung so sein, dass Änderungen im eMP vorgenommen werden und sich auf die eML auswirken.
Bsp. Anpassung Dossierschema: Dies wird in der Praxis sicher im eMP vorgenommen werden, muss aber in die eML übernommen werden. Änderungen in der Liste sollten aber dennoch in den Plan übernommen werden.
Der eMP sollte also die Datensicht sein, die, wenn vorhanden, die führende Information ist.

Die Möglichkeit entsprechend relevante Zustände abzubilden sollte um die Möglichkeit snomed CT zu codieren erweitert werden, z.B: Mit Hilfe eines zweiten Slice.
Als relevant sehen für z.B. folgenden sct-Code: 1260078007

Die Gabe von Medikamenten „bei Bedarf und auch „vor und nach den Mahlzeiten““ ist geregelt – aktuell werden jedoch Insulin-Anordnungen mit sogenannten „Korrektur-Schemata“ verordnet.
Getrennt für die Früh- Mittags- und Spät-Gabe des Insulins soll der Patient je nach Abweichung des gemessenen Blutzuckers noch eine Menge Insulin mehr oder weniger als das Standard-Schema verordnet. Dabei ist der BZ dann z.B. 0-50 mg/dl, 51-100, 101-150 etc. – d.h. in Stufen (je nach Bundesland SI-Einheiten) – erhöht – und der Arzt ordnet dann +3 IE bzw. +5IE etc. an. Das ist nicht linear, sodaß man auch nicht schreiben kann „je xxx mmol Abweichung Korrektur um xxx IE Insulin.
Hier wären für Spezial-Anwendungen (z.B. Insulin-Korrektur-Schema, wöchentliche Gabe, monatliche Gabe) noch Informationen vorzusehen.

Der Bundesmedikationsplan muß in einer längeren Übergangsphase für den Patienten weiterhin mit Barcode bedruckt werden, denn es wird diverse Einrichtungen (KH/Vertragsarzt/Apotheke) geben, die noch nicht die MIO eMP und eML lesen oder schreiben können.

Die Einheit des Medikaments muß interoperabel mit ausgetauscht werden. Aktuell sind aus Praxis-Software gelieferte Papier Bundesmedikationspläne oft leer in der Spalte Einheit – dies ist jedoch wichtig für die Eindeutigkeit. Das Feld "Einheit" muß also Mandantory sein und für AMTS-Systeme im Krankenhaus lesbar/nutzbar. Aktuell stürzen Importe eines BMP aus der Praxissoftware ohne "Einheit" in die Klinik-AMTS-Software AiD von Dosing (r) regelmäßig ab.

Bei jedem Medikament (z.B. wo es AutIdem und AutSimile preiswertere alternativen gibt, die aber nicht gewählt wurden), welches spezifischen Bedarfen gehorcht, muß dieser Bedarf (Grund) mitgegeben werden – auch zur (halb)automatisierten Umstellung auf (Kranken-)Haus-Medikation oder AutIdemAutSimile:

• Magensondengängigkeit
• Mörserbarkeit
• Galenik - Bio-Verfügbarkeit etc.
• Retard-Präparat etc.
• Teilbarkeit
• Löslichkeit
• Farbe notwendig bei Selbst-Medikation und psych. Alterierter Person?
• Magenschutz?
• Allergie/Empfindlichkeit gegen einen der sonst verwendeten Wirkstoffe oder Hilfsstoffe
• Wirksamkeit des Aut Simile geringer als erwartet
• Paradoxe Wirkung eines aut Simile
• Konkrete Herstellerauswahl beim selben Wirkstoff (Gerinnungspräparate (Immunologische Probleme mit einem Hersteller), Immunglobuline mit anderer Valenz, Zulassung einzelner Produkte oder Wirkstoffe für die konkrete Erkrankung unterschiedlich (=Gefahr von OffLabelUse) etc.)
  Sollte hier keine Angabe gemacht werden über die Besonderheiten, die zu beachten sind bei der Aut-Idem/Aut-Simile-Umsetzung (d.h.: „Was hat sich der Verordner bei der der konkreten Auswahl des Produkts gedacht?“), dann wird der Nach-Verordner (KH-Arzt) nicht auf diese Besonderheiten (Bedarfe) achten (können).

Jeder Eintrag muß versioniert sein – alte Stände und Gründe zur Umsetzung/Ansetzung/Absetzung müssen immer erkennbar sein
Die Information der Absetzung eines Medikaments durch einen anderen Arzt – mit der Begründung warum – sollte im MIO gespeichert bleiben, denn dann bekommt ein nachfolgender Arzt die Botschaft, daß ein gewisses Medikament (und warum) bei dem Patienten abgesetzt wurde (sodaß er das nicht wieder ansetzt – unwissend den Grund des vorherigen Absetzens).

Das Produkt muß auch nach Jahren noch lesbar sein. (Aktuell liefert „Dosing GmbH“ nur die Medikamente/PZN-Listen aus der Medikamente, die aktuell auf dem Markt sind – bei alten Medikamenten/Plänen schreibt das Programm dann „unbekannte PZN“) – Herr Fritzlar schreibt im Kommentar EMP1X0X0-102, daß durch PZN-Angabe Eindeutigkeit bei Fertigarzneimitteln besteht – das aber nur, wenn das Verzeichnis aller FAM auch immer verfügbar ist. Dosing liefert nicht alle PZN in ihrer Datenbank aus.

Hier wäre eine Beschreibung hilfreich, was man unter "leicht", "schwer" und "mittel" versteht.

Die AWMF sieht für die Einteilung des Schweregrades von Allergien vier Stufen vor:

<span class="nobr"><a href="https://register.awmf.org/assets/guidelines/061-025l_S2k_Akuttherapie-Management-Anaphylaxie_2021-10.pdf" class="external-link" rel="nofollow">https://register.awmf.org/assets/guidelines/061-025l_S2k_Akuttherapie-Management-Anaphylaxie_2021-10.pdf^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Diese sind mild (Grad I), mäßig (Grad II), schwer (Grad III) und Anaphylaxie (Grad IV).

Da die für das vorliegende MIO vorgeschlagene Einteilung von HL7 abgeleitet ist, ist natürlich eine international abgestimmte Einteilung sinnvoll. Gleichwohl wäre in diesem Fall eine Beschreibung der Schweregrade zielführend, um einheitliche Informationen zu erhalten.

(Anmerkung: Offenbar gibt es mehrere Einträge zu Allergie/Intoleranz, daher doppelt sich mein Kommentar gegebenenfalls)

Die Art und Weise, wie die Spezifikation mit Übersetzungen von englischsprachigen Konzepten/Konzeptbeschreibungen umgeht, ist aus unserer Sicht problematisch und kann deutlich eleganter über die Verwendung von CodeSystem-Supplements gelöst werden. Der aktuelle Ansatz, über die Definition eigener Konzepte in separaten CodeSystemen und einem anschließenden Mapping über eine ConceptMap, ist aus unserer Sicht komplex, fehleranfällig und aufwändig in der Umsetzung. CodeSystem-Supplements bieten die Möglichkeit zusätzliche "designations" für Konzepte aus bestehenden CodeSystemen zu definieren. Diese designations können dann entsprechend auch mit einem passenden language-Code (z.B. de-DE) versehen und somit als Übersetzung verwendet werden.

Das ValueSet "KBV_VS_MIO_EMP_Dose_Form_SNOMED_CT" beinhaltet lediglich die Expansion, die Definition des VS (ValueSet.compose) ist jedoch nicht zu finden. Alternative Expansions lassen sich somit nicht mehr automatisiert bauen. Wir empfehlen daher für sämtliche ValueSets, die Bestandteil einer Spezifikation sind, auch die Definition mit anzugeben.

Es wäre hilfreich, wenn es zu jedem selbst erstellten CodeSystem auch ein passendes ValueSet gäbe, das sämtliche Konzepte des jeweiligen CS inkludiert und auf welches über das Element CodeSystem.valueSet verwiesen wird.

Es wäre hilfreich, wenn in den verschiedenen Ressourcen (StructureDefinitions, CodeSystems, ValueSet) das date-Element ergänzt werden könnte. Dies ermöglicht eine zeitliche Einordnung der jeweiligen Versionen und wird insbesondere dann hilfreich, wenn perspektivisch mehrere Versionen verfügbar sind.

Guten Tag, der Prozessdarstellung in BPMN entnehme ich, dass ABP auf Relevanz geprüft werden sollen. Soll dies automatisiert oder durch den Anwender erfolgen?Insgesamt scheint es, als habe die Berücksichtigung von Allergien/ Unverträglichkeiten im Rahmen des AMTS-Prozesses keine hohe Priorität. Komplex wird es sicherlich im Zusammenspiel mit dem PVS der Arztpraxis, den exklusiven Rabattverträgen der Krankenkassen, den Verordnungsrichtlinien von KBV Und KV sowie dem Rahmenvertrag nach §129 Abs. 2 SGB V. Da hier im generischen Bereich auf der Basis von Wirkstoffen in der Apotheke substituiert werden soll, würde ein automatisiertes aut idem-Kreuz bei Hilfsstoffallergien Sinn machen. Und die Arzneimittelvorschlagsliste sollte nur Produkte ohne den allergieauslösenden Stoff zeigen oder diese zumindest hervorheben.

Guten Tag, die Berücksichtigung von Allergien/Unverträglichkeiten im Rahmen des AMTS-Prozesses erscheint unklar bzw. noch nicht ausreichend definiert, auch im Hinblick auf das PVS der Arztpraxis. Beispiel: der Patient hat eine Unverträglichkeit bzgl. des in Augentropfen häufig aber nicht immer enthaltenen Konservierungs-mittels/Hilfsstoffes Benzalkoniumchlorid (BAC). Der Arzt könnte dann mit einem cave-Button mit aktiver Bestätigung auf den Konflikt hingewiesen werden. Oder es werden "direkt" nur Präparate ohne den kritischen Hilfsstoff angezeigt. Idealerweise mit automatischem aut idem, da ansonsten gem. Rahmenvertrag nach §129 Abs. 2 SGB V in der Apotheke wirkstoffbezogen auf ein Rabattvertragsmedikament substituiert wird.

Guten Tag, Ihre Isolde Meinhardt hat keine Allergien/Unverträglichkeiten. Bei vorhandenen Allergien sollte eine automatische Prüfung unter AMTS-Gesichts-punkten erfolgen. Beispiel: Patientin mit Glaukom und neu eingetragener Konservierungsmittelunverträglichkeit (Benzalkoniumchlorid, BAC), Therapie mit Antiglaukomatosa (Dorzolamid + Timolol), Darreichungsform ATR. Es gibt Medikamente mit/ohne BAC. Es müsste zumindest ein cave kommen und den Verschreiber um Bestätigung der Rezeptierung mit einem BAC-haltigen Präparat bitten. Bei einem NEIN zeigt die Medikationsliste idealerweise dann nur die vier Präparate (von x Anbietern) ohne Konservierungsmittel und sollte ein aut idem-Kreuz setzen, um den Austausch in der Apotheke zu verhindern, sofern das ausgewählte Präparat kein Rabattvertragsprodukt ist.

Hier wäre eine Beschreibung hilfreich, was man unter "leicht", "schwer" und "mittel" versteht. Die AWMF sieht für die Einteilung des Schweregrades von Allergien vier Stufen vor (<span class="nobr"><a href="https://register.awmf.org/assets/guidelines/061-025l_S2k_Akuttherapie-Management-Anaphylaxie_2021-10.pdf" class="external-link" rel="nofollow">https://register.awmf.org/assets/guidelines/061-025l_S2k_Akuttherapie-Management-Anaphylaxie_2021-10.pdf^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>). Diese sind Mild (Grad I), Mäßig (Grad II), Schwer (Grad III) und Anaphylaxie (Grad IV).

Da die für das vorliegende MIO vorgeschlagene Einteilung von HL7 abgeleitet ist, ist natürlich eine international abgestimmte Einteilung sinnvoll. Gleichwohl wäre in diesem Fall eine Beschreibung der Schweregrade zielführend, um einheitliche Informationen zu erhalten.

Die Beschreibung des Ablaufes am Unfallort ist leider etwas ungünstig geraten.
Im Beispiel wirkt es so, als ob die Notärztin sich nach einer kurzen Einschätzung der Patienten direkt mit den digitalen Medien zur weiteren Anamnese-Erhebung beschäftigt.
Eine „stark blutende Rissquetschwunde am Kopf“, mit der Verdachtsdiagnose „Schädelhirntrauma“, ein „eindeutiger Oberschenkelhalsbruch“ sowie „tiefere Abschürfungen an den Extremitäten“ sind eigentlich Befunde, die ein Notarzt erhebt, bevor er die Anamnese auf externe Medien ausweitet.

Der zweite Bullet-Point (Lesen den Notfalldatensatzes, ePA, eMP oder eML sollte daher erst nach der „ersten Notfallbehandlung zur Blutstillung und Frakturstabilisierung“ stattfinden.

Die Möglichkeit entsprechend relevante LOINC-Codes abzubilden sollte erweitert werden, um mit der IPS kompatibel zu sein.

Wir sehen dort die folgenden Codes: 11779-6, 11780-4

Die Möglichkeit entsprechend relevante Zustände abzubilden sollte um die Möglichkeit snomed CT zu codieren erweitert werden, z.B: Mit Hilfe eines zweiten Slice.
Als relevant sehen für z.B. folgenden sct-Code: 1260078007

Die Möglichkeit entsprechend relevante LOINC-Codes abzubilden sollte (im ValueSet) überarbeitet werden.

Wir sehen dort ergänzend die folgenden Codes:
39802-4, 70266-2, 70264-7, 2160-0, 14682-9, 40248-7, 40264-4, 44784-7, 11042-9, 51619-5, 40112-5, 11041-1, 72271-0, 40116-6, 2164-2, 40250-3, 40254-5, 40252-9, 26752-6, 40267-7

Die UX-Darstellung im AVS umfasst hinsichtlich der Tätigkeiten eines Apothekers leider ausschließlich die heutigen Aktivitäten im Rahmen der eRX-Einlösung. Die hier eigentlich relevanten Aspekte der Aktualisierung des Medikationsplans (aus einer eRX-Dispensierung oder einer OTC-Abgabe heraus) werden nicht thematisiert. Damit ist die Visualisierung zwar interessant aber leider weitgehend ohne Mehrwert für die Apotheken-Aspekte im Rahmen des dgMP.

Hier wäre es wünschenswert, wenn (gemeinsam) Vorschläge erarbeitet werden könnten, wie eine Pflege / Aktualisierung des eMP direkt aus dem Auswahl und Verkaufsvorgang heraus stattfinden sollten, damit der eMP tatsächlich immer aktuell vorliegt. Eine nachgelagerte Pflege der Einträge nach dem Verkaufsvorgang, erhöht den Aufwand für den Apotheker und trägt die Gefahr, dass die Aktualisierung unterbleibt.

Die verschiedenen Observations (Creatinine, Pragnancy_Status, Body_Weight, Body_Height etc.) besitzen mal nur einen loinc-Code und mal sowohl einen loinc-Code als auch einen snomed-Code.

Es ist nicht erkennbar, warum nicht durchgängig beide Codesysteme verwendet werden oder nicht durchgängig nur loinc verwendet wird. Eine Einheitlichkeit wäre wünschenswert.

Die Kontaktpersonen eines Patienten im Rahmen des dgMP erfassen zu können, ist überaus sinnvoll.
Eine solche Liste an Kontaktpersonen sowie die dafür notwendigen FHIR-Operationen hat die gematik aber bislang nicht beschrieben.
Entsprechend sollte das Grobkonzept der gematik diesbezüglich erweitert werden - oder Kontaktperson (und entsprechend KBV_PR_MIO_EMP_RelatedPerson) müsste aus diesem Scope entfernt werden.

Um die Umsetzungskomplexität für die erste Ausbaustufe bis 15.07.25 zu begrenzen (und damit den Terminplan erreichbar zu halten), sollten die Elemente des Knotens
.relationship.coding
nicht auf "must support" gesetzt werden.
Stattdessen sollte lediglich das Textfeld
.relationship.text
weiterhin mit "must support" versehen bleiben.

Die Umsetzung der Auscodierung erfordert sehr viel Aufwand für die Oberflächensteuerung im PVS und der ePA-App, sowie in der "Umrechung" für die Anzeige der kodierten Werte.
Dies sollte erst für eine zweite Umsetzungsstufe vorgesehen werden.

In der Profilierung der Bezugsperson wird unter Definition ausgeführt:
"Wenn ausgedrückt werden soll, dass sie an der Versorgung beteiligt ist, kann sie im Versorgungsteam aufgeführt werden. Ein Beispiel für Letzteres ist ein/e pflegender An- oder Zugehörige/r."

Im eMP und dem dgMP der gematik existiert keine pflegbare Liste für ein Versorgungsteam. Daher ist der Verweis (und die Abgrenzung) nicht korrekt.

Laut Grobkonzept der gematik sollen Provenance-Ressourcen nicht auf die Practitioner-Ressource verweisen, sondern stattdessen auf die PractitionerRole-Ressource (die ihrerseits auf den Practitioner verweist).

Die Ausgestaltung von Provenance.agent.who erlaubt jedoch auch die Verlinkung direkt auf eine Practitioner-Ressource.
Steht dies dann nicht im Widerspruch zum dgMP-Grobkonzept der gematik?

Dies gilt für ebenso für alle anderen Ressourcen, die auf die Practitioner(Role)-Ressource verweisen müssen: MedicationStatement, ePAObservation etc.

Insgesamt bin ich noch nicht überzeugt, dass PractitionerRole innerhalb des dgMP korrekt abgebildet werden kann, da es bislang keine Prozessbeschreibung gibt, wie dort eine korrekte PractitionerRole angelegt und dann auch korrekt referenziert werden soll. Von daher wäre es gut die Verwendung dieser Ressource zu überdenken. Schlussendlich müssen aber natürlich die Konzepte / Spezifikationen der gematik mit den Spezifikationen der MIO42 zusammen passen...

Neben der Liste der Allergien und Unverträglichkeiten, die sich primär auf Wirkstoffe bezieht, sollte eine weitere "Blacklist" geführt werden, in der konkrete Fertigarzneimittel geführt werden, die der Patient nicht vertragen hat / nicht verträgt.

Ursachen für solche Unverträglichkeiten auf Ebene der Fertigarzneimittel können z.B. Tablettenformen sein, die zu Schluckproblemen führen. Solche Unverträglichkeiten lassen sich über die aktuellen Listeneinträge nicht abbilden, sind aber ausgesprochen versorgungsrelevant. Auch führt die Information über bestimmte Präparate, die nicht vertragen werden, bei späteren Verordnungen anderer Ärzte nicht zu widerholten Problemen (und unnötigen Arzneimittelausgaben, weil das Med - erneut - weggeworfen werden muss).

Daher sollte eine solche Liste an Medication-Ressourcen, die der Patienten nicht verträgt, verbunden mit einer Information über die damit verbundenen Probleme, zusätzlich in dgMP aufgenommen werden.
Da die Umsetzung einer solchen Funktion wenig Aufwand bedeutet (da gut auf vorhandene Ressourcen-Profile aufgesetzt werden kann und die Businisslogik sehr einfach ist), sollte diese Liste direkt ab ePA 3.1 aufgenommen werden.

Sowohl auf der Ebene des eML als auch des eMP, müssen für eine vollständige fachliche Nutzbarkeit der Medikationsliste, alle Medikamente - soweit möglich - mit dem korrekten ATC-Code versehen werden.
Diese Klassifikation ist unerlässlich, wenn im Rahmen der Anamnese medikationsbezogene Fragen geklärt werden müssen, wie z.B.
"Wann haben Sie das letzte Mal Antibiotika genommen?"

Eine solche Frage lässt sich nicht auf Ebene der konkreten Präparate beantworten (sonst müsste man im eML / eMP nach allen bekannten Antibiotika suchen), sondern ausschließlich über den ATC-Code, hier beispielsweise über ATC-Code = "J01*"

Es muss daher, in Zusammenarbeit mit der gematik, sichergestellt werden, dass
1. alle vom eRX-Server übertragenen Medikamente automatisch mit einem ATC-Code versehen werden (durch den eRX-Server)
2. alle manuell hochgeladenen oder angepassten Medication-Ressourcen mit einem ATC-Code versehen werden sollen.

Es wird nicht ersichtlich, ob sich .note an andere Heilberufler oder an den Patienten richten soll.
Für eine zielgruppenkonforme Kommunikation erscheint es notwendig, dass zwei getrennte Informationen für getrennte Zielgruppen hinterlegt werden können:
1. An den Patienten (siehe EMP1X0X0-124)
2. An die mitbehandelnden Ärzte, Apotheker, Pfleger

#2 ist relevant, um Informationen wie "Bewusste Gabe trotz Wechselwirkungswarnung, wegen ..." hinterlegen zu können, damit andere Ärzte z.B. wissen, dass eine Medikation trotz eines AMTS-Hinweises bewusst erfolgte - und entsprechend NICHT korrigiert werden soll. Auch weitere Hinweise zu für diesen Patienten schlechteren Alternativen (Einschränkung bei Schluckleistung, daher Warnung vor Substitution z.B. durch Rabattverträgen oder Klinikmedikation) sollten hier aufgenommen werden können. Im Sinne der asynchronen, gemeinschaftlichen Behandlung eines Patienten.

All dies lässt sich über .note abbilden. Es sollte nur deutlicher herausgestellt werden, dass .note genau dafür gedacht ist. Diese deutlichen Festlegungen sind wichtig, damit das Feld in seiner Semantik für die Versorgung verstanden und in Folge von allen Herstellern (PVS, AVS, KIS, ePA-App) gleich verwendet wird.

Die Informationen im dgMP sind über die ePA-App auch für den Patienten bzw. für den ihn familiär Betreuenden relevant.
Zur Medikation dieses Medikaments, ist es daher sinnvoll, dem Patienten direkt an ihn gerichtete Informationen mit zu geben.

A)
Aktuell ist vorgesehen, dass zu jeder der n möglichen Dosierungsangaben innerhalb eines Medikationsstatements sowohl eine .dosage.patientInstruction (Einnahme, Lagerung, Anwendung) als auch eine .dosage.additionalInstruction (z.B. "mit den Mahlzeiten") gespeichert werden kann.
Es erscheint unwahrscheinlich, dass sich diese Informationen an den Patienten in den unterschiedlichen Dosierangaben unterscheiden werden.
Daher wäre es sowohl für die Umsetzung als auch für die Verständlichkeit zielführender, wenn .patientInstruction und .additionalInstruction nicht als Unterelemten unter .dosage, sondern als Elemente direkt unter MedicationStatement. verortet werden sollten.

B)
Die an den Patienten (oder seinen Betreuer) zu gebenden Begleitinformationen sind gelegentlich umfangreicher als nur eine Textzeile. Daher wäre es hilfreich, wenn
1. neben der Option auf reinen Text auch Markdown zulässig wäre
2. neben der Option auf Text auch ein Attachment mitgegeben werden könnte (PDF/A)

Insbesondere die Möglichkeit für ein Attachment wäre ausgesprochen hilfreich (und notwendig), um zielgerichtet, niederschwellig und einfach in der technischen Umsetzung, dem Patienten (seinem Begleiter) aufbereitete begleitende Informationen zukommen lassen zu können. Heute werden dem Patienten, z.B. in der Rheumatologie, Begleit-A4 mitgegeben, worauf er bei der Einnahmetherapie des Medikaments zu achten hat. Dies muss strukturiert erfolgen, in Tabellenform, teilweise mit Grafiken oder Illustrationen. Solche Informationen werden arztseitig bislang maximal als PDF erzeugt und bereitgestellt. Diese Informationen sollten im dgMP im Interesse der Patienten mit hinterlegt werden können.

Die aktuellen Festlegungen zu .dosage.maxDosePerPeriod sind für interoperable Implementierungen (von >200 Herstellern) noch nicht ausreichend detailliert.
Auch deshalb sollte für die erste Ausbaustufe daher auf eine textuelle Beschreibung zurückgegriffen werden.

Im Detail:
.dosage.maxDosePerPeriod.numerator
Definiert nicht, welches Codesystem verwendet werden soll. Dies ist zwingend festzulegen. Unter .code wird KBV_VS_SFHIR_BMP_DOSIEREINHEIT lediglich empfohlen. Aus dieser Empfehlung sollte eine Festlegung mit fixen Werte für .system und als zwingendes Valueset für .code werden.

.dosage.maxDosePerPeriod.denominator
Besitzt weder normative Festlegung noch eine Empfehlung, wie die Zeiteinheit codiert werden soll. Hier muss .system und das Valueset für .code festgelegt werden.

Wie an anderer Stelle auch: Abgesehen von den fehlenden Festlegungen für eine interoperable Umsetzung bei allen Herstellern, reicht die Zeit bis zum 15.07.25 nicht für komplexe Geschäftslogiken und Benutzeroberflächen aus.
Daher sollte unter .dosage.maxDosePerPeriod ein zusätzliches Element .text 0..1 string aufgenommen werden, in dem - wie bei .asNeeded - die maximale Dosis per Zeitraum als Fließtext eingetragen werden kann, wie als Beispiel ausgeführt:
"2 Tabletten alle 4 Stunden bis zu einem Maximum von 8/Tag".

Um die Umsetzungskomplexität für die erste Ausbaustufe bis 15.07.25 zu begrenzen (und damit den Terminplan erreichbar zu halten), sollten die Elemente des Knotens
.dosage.asNeeded<span class="error">[x]</span>:asNeededCodeableConcept.coding
nicht auf "must support" gesetzt werden. Insbesondere, da die dort für .code zu verwendenden Werte noch kein ValueSet besitzen und diese für dort sinnvolle Werte von allen Herstellern erst einmal ermittelt werden müssten - was aus Gründen der Interoperabilität bei ziemlich sicher unterschiedlichen Wertemengen wenig hilfreich wäre.
Stattdessen sollte lediglich das Textfeld
.dosage.asNeeded<span class="error">[x]</span>:asNeededCodeableConcept.text
weiterhin mit "must support" versehen bleiben.

Die Umsetzung der Auscodierung erfordert sehr viel Aufwand für die Oberflächensteuerung im PVS und der ePA-App, sowie in der "Umrechung" für die Anzeige der kodierten Werte.
Dies sollte erst für eine zweite Umsetzungsstufe vorgesehen werden.

Bei einer Profilierung einer Observation speziell für Glomerulären Filtrationsrate, sollten die erlaubten Loinc-Codes unter
.code.coding:loinc.code
auf ein ValueSet mit entsprechend zulässigen Loinc-Codes für Glomerulären Filtrationsrate eingegrenzt werden.
Dies verhindert Fehlebelegungen.

Bei einer Profilierung einer Observation speziell für Serumkreatinin, sollten die erlaubten Loinc-Codes unter
.code.coding:loinc.code
auf ein ValueSet mit entsprechend zulässigen Loinc-Codes für Serumkreatinin eingegrenzt werden.
Dies verhindert Fehlebelegungen.

Um die Umsetzungskomplexität für die erste Ausbaustufe bis 15.07.25 zu begrenzen (und damit den Terminplan erreichbar zu halten), sollten die Elemente des Knotens
.dosage.timing
nicht auf "must support" gesetzt werden. Stattdessen sollte ein zusätzliches Textfeld aufgenommen werden, welche "must support" ist (vergleiche .additionalInstruction)

Die Umsetzung der Auscodierung erfordert sehr viel Aufwand für die Oberflächensteuerung im PVS und der ePA-App, sowie in der "Umrechung" für die Anzeige der kodierten Werte.
Dies sollte erst für eine zweite Umsetzungsstufe vorgesehen werden.

Um die Umsetzungskomplexität für die erste Ausbaustufe bis 15.07.25 zu begrenzen (und damit den Terminplan erreichbar zu halten), sollten die Elemente des Knotens
.dosage.additionalInstruction.coding
nicht auf "must support" gesetzt werden. Lediglich
.dosage.additionalInstruction.text
sollte "must support" bleiben.

Die Umsetzung der Auscodierung erfordert sehr viel Aufwand für die Oberflächensteuerung im PVS und der ePA-App, sowie in der "Umrechung" für die Anzeige der kodierten Werte.
Dies sollte erst für eine zweite Umsetzungsstufe vorgesehen werden.

MedicationStatement sieht mit .identifier:zeilenId die Referenz auf eine Ressource dar, die (sehr aufwändig) lediglich die Zeilennummer festlegen soll, mit der das MedikationsStatement innerhalb des eMP dargestellt werden soll - wobei dort eine UUID statt einer Zeilennummer definiert wird und nicht klar wird, wie eine solche UUID als Zeilennummer interpretiert werden soll.

Das Konzept der Zeilennummern ist im Grobkonzept der gematik zum dgMP nicht abgebildet.

Das Konzept der Zeilennummern sollte grundsätzlich überdacht werden. Grundsätzlich wäre es deutlich sinnvoller, wenn keinerlei Semantik in der Anordnung der Medikationen innerhalb einer Visualisierung eines Plans enthalten wäre. Vielmehr muss jede Zeile informationstechnisch in sich geschlossen sein, bzw. auf gegebenenfalls relevante Informationen per Referenz verweisen.
So können Pläne in ihrer Darstellungsreihenfolge je nach Bedarf erzeugt werden (Einnahmezeitpunkte, Wirkgruppen, etc.)
Eine semantische Aussage durch eine ZeilenID sollte daher strickt unterlassen werden.

Unter
MedicationStatement.extension:behandlungsziel
soll eingetragen werden:
"Die Referenz soll eine Instanz der Ressource KBV_Base_Treatment_Goal sein."

Eine solche Profildefinition KBV_Base_Treatment_Goal ist jedoch (noch) nicht zu finden.
Ferner muss sichergestellt werden, dass die seitens gematik definierten Operationen für dgMP die Übertragung dieses Ressourcentyps zulassen.

Das Element wird beschrieben als
"Hier kann ein Dokument als Informationsquelle für die Information angegeben werden, die als Ziel der Herkunfts-Information referenziert ist."

.entity.what soll dabei auf ein Quelle verweisen, wobei unklar ist, welche Art von Quelle dies im dgMP der ePA sein soll, die keine beliebigen Dokumente oder andere Ressourcen aufnimmt, als die, die für die Definition des dgMP vorgesehen sind.

Es scheint, als könnte der gesamte Knoten im Rahmen des dgMP der ePA technisch überhaupt nicht genutzt werden. Um so mehr überrascht dann das "must support" flag für diesen Knoten.
Mindestens für die erste Umsetzung des dgMP sollte auf diesen Knoten verzichtet werden.

Hier bei Medication.text sowie bei allen anderen eMP-Profilen sollte auf das Hinzufügen von .text-Elementen (oder ähnlichen Felder) verzichtet werden, die die inhaltliche Aussage der Felder einer FHIR-Ressource noch einmal menschenlesbar zusammenfassen.
Die FHIR-Ressourcen werden IMMER durch Apps interpretiert und zur Anzeige gebracht. Keine FHIR-Ressource wird in Rohformat heruntergeladen und von Endnutzern betrachtet werden.
Daher sind inhaltliche Redundanzen (text-Zusammenfassungen zu Summe aller Codierungen in einer Ressource) nur Aufwandstreiber für eine Umsetzung sowie Fehlerquelle für auseinanderlaufende Informationen.
Daher sollte auf solch zusammenfassende, ergänzende Felder grundsätzlich verzichtet werden (Redundanzfreiheit ist ein Grundprinzip in der Datenbanktechnik).

Das Grobkonzept der gematik zu dgMP (auf das hier auch verwiesen wird), verwendet ausschließlich die gematik-seitig definierten eMP-Profile. Die hier zu kommentierenden MIO42-Profilierungen setzen oft (aber nicht immer!) auf den gematik-Profilen auf und verändern diese zusätzlich. Auch das Wording der Ressourcennamen weicht ab.
Dies macht es "schwer", die Profilfestlegungen der MIO42 inhaltlich - sowohl fachlich wie technisch - auf Passung zum Grobkonzept der gematik zu prüfen. Dies um so mehr, als dass sich das Grobkonzept selbst ja auch noch in der Kommentierung befindet.

MIO42 und gematik sollten hier bitte auch im Rahmen der Dokumentation so zusammenarbeiten, dass das Grobkonzept die Profile der MIO42 vewendet und innerhalb der inhaltlichen Beschreibung der MIO42 (Struktur, UX) auf die Festlegungen im Grobkonzept referenziert wird.

Schlussendlich müssen Krankenkassen und Industrie beide Vorgaben in ein funktionierendes Produkt umsetzen. Dazu muss eine Durchgängigkeit in den Festlegung und Beschreibungen gegeben sein.

Die Kommentierung gestaltet sich schwierig, da nicht beschrieben ist, wie ein FHIR-DB-basierter eMP in der ePA fachlich organisiert werden soll.
Die UX-Visualisierungen geben eine Idee, bilden aber nicht ein vollständiges Konzept ab. Auch eine Beschreibung der fachlich zu erreichenden Ziele wäre hilfreich, um prüfen zu können, ob die Zielvorstellungen vollständig sind und ob die Strukturfestlegungen diese erreichen. So ist z.B. unklar, ob der eMP auch den Patienten sowie den Betreuenden dienen soll (vermutlich ja, wird aber nicht beschrieben und auch die UX-Visualisierungen gehen nicht darauf ein).

In den UX-Visualisierungen sind keine Zeilenüberschriften mehr vorhanden, lediglich die Gruppierung in Dauer- sowie Bedarfsmedikation.
Sofern Zeilenüberschrift fachlich noch gewünscht werden, braucht es auch ein Konzept die Reihenfolge der Medikationen innerhalb des Plans abzubilden.
Insgesamt sollte aber bei einer FHIR-DB-Umsetzung des eMP auf zeilenbasierte Semantik verzichtet werden!

Vermutlich ist das eine Anfängerfrage, aber ist das Profil zur Erfassung der Körpergröße nicht "etwas" überkomplex?
Ich betrachte das aus der Sicht eines System-Entwicklers sowie eines Designers für die Benutzeroberflächen (Ärzte, Apotheker, Patienten).

Was fachlich im Kontext des eMP benötigt wird, sind lediglich folgende Informationen:
0. Patientenzuordnung
1. Körpergröße (interoperabel codiert)
2. Datum der Messung
3. Information zur Qualität der Messung (ärztlich erhoben oder mündlicher Bericht des Patienten)

Was nun aber nach diesen Vorgaben umgesetzt werden muss, ist die zwingende Verarbeitung zum Umgang mit folgenden Informationen (vom Systemkern bis hoch zur Benutzerführung):
4. Status der Messung (final, vorläufig, abgebrochen, unbekannt, Fehleingabe,...)
5. Referenz auf eine Ressource, die die Messung durchgeführt hat (7 Ressourcenprofiltypen zulässig)
6. Wert darf leer sein!
7. zusätzliche Hinweistexte, mit Angaben zum Autor des Textes (Referenz auf komplette Ressource), Datum der Erfassung des Textes und den Text als Markdown

Dazu kommen Felder, die vorhanden sind aber nicht zwingend von Zielsystemen umgesetzt werden müssen (wozu dann vorhanden?), deren Sinnhaftigkeit sich für die Angabe der Körpergröße für eine AMTS-Prüfung nicht erschließen:
8. Körperseite (bei der Körperlänge?)
9. Messmethode
10. Referenz auf das Gerät, mit dem gemessen wurde
11. Referenzwerte (low, high, ...)
12. Zuordnung zu anderen Beobachtungen oder Fragebögen
13. Angabe zur Quelle, von der die Messung abgeleitet wurde
14. Referenz zum Behandlungstermin als Ressource
15. Codes für übergeordnete Beobachtungskategorien
16. Referenz zur Ressource eines Behandlungsplans (oder ähnliches)
17. Referenz zu Ressourcen der Art Medikation, Impfung etc.

Dazu kommt, dass das Profil ein neues Profil für die Speicherung / Übermittlung der Körpergröße eines Patienten darstellt - im Kontext des eMP!
Das Profil ist eine Ableitung des KBV-Basisprofils zur Körpergröße, welches eine Ableitung von Deutschen Basisprofil für Körpergröße ist.
Dies alles für den Messewert der Körpergröße, der sicherlich "selten" in unterschiedlichen Kontexten unterschiedliche Annotationen und Begleitinformationen braucht, sodass drei Profilableitungen dafür notwendig sind (die im Zweifel im Rahmen der Produktpflege alle nachgehalten werden müssen).

Vermutlich ist dieser Kommentar, wie eingangs ausgeführt, eine echte FHIR-Anfängerfrage. Aber die (Entwicklungs- und Pflege-)Aufwände für EINEN Messwert, der "meist" über die Zeit bei erwachsenen Menschen doch recht konstant bleibt, erscheint maßlos übertrieben. Denn dieser Aufwand muss für alle anderen Messwerte und damit für deren Darstellungen auch betrieben werden.
Dies müsste doch effizienter umsetzbar sein.

"resource": {
"id": "029585b678cd11eeaefc0242ac140004",
"bodySite": {
"coding": [
{
"code": "18944008 |Right eye structure (body structure)|",
"system": "http://snomed.info/sct"
}
]
},
"code": {
"coding": [
{
"code": "81016008 |Optic disc structure (body structure)| + 230504002 |Tilted optic disc (disorder)|",
"system": "http://snomed.info/sct"
}
],
"text": "verkippt"
},
"status": "registered",
"resourceType": "Observation"

Wir würden es begrüßen, wenn neben den hier aufgeführten Observations weitere AMTS-relevante Laborwerte hinzugenommen würden. Diese sind nach Erarbeitung der AG-Medikation des ISiK Standards für eine AMTS Bewertung von grundlegendem Charakter.

Und zwar:

C-reactive protein (CRP) 
Hämoglobin (Hb)
Procalcitonin (PCT)
Thrombozyten
Troponin
Thyreoidea-stimulierendes Hormon (TSH)

Für diese aus unserer Sicht obligatorischen Information würden wir uns über eine Anlehnung an das ISiK Support Modul Labor Stufe 4 freuen.

Wir würden es begrüßen, wenn neben der Schwangerschaft weitere AMTS relevante Lebenszustände in Form einer Observation aufgenommen würden, z.B. AkoholAbusus, RaucherStatus oder Gendefekte im weiteren Sinne (z.B. Gerinnungsstörung, Diabetes Typ I, usw. ). Diese lassen sich nicht unbedingt gut über eine Diagnose abbilden.

Für die aus unserer Sicht obligatorischen Information zu AkoholAbusus und RaucherStatus würden wir uns über eine Anlehnung an das ISiK Basismodul Stufe 4 freuen.

Hallo liebes dgMP-Team,

die Klickdummys sind unglaublich hilfreich!
Als konstruktive Kritik:
Für die Erstellung eines (e)Rezepts gelten die Vorgaben der KBV hinsichtlich der Verordnungssoftware. Dies inkludiert Anzeige-, Filter- und Auswahlvorgaben bei der Auswahl des (konkreten) Medikaments.
Entsprechend muss der Workflow die Vorgaben der KBV an ein solches VOS beinhalten. Dies ist mit dem Auslösen der Verordnung auf dem eMP heraus (nach aktuellen Vorgaben!) vermutlich nicht umsetzbar.

Hinzu kommt, dass das Verordnungsmodul ein vom PVS unabhängiges Modul sein kann. Entsprechen sind der Ort der ePA-eMP-Datendarstellung und -Fortschreibung sowie der Ort zur Erstellung eines (e)Rezepts unterschiedlich.

Es ist daher dringend angezeigt, dass
a) der Prozess unter Berücksichtigung der KBV-Vorgaben zum VOS erfolgen
b) die VOS-Vorgaben der KBV auf die sinnvollen Prozesse unter Nutzung des dgMP angepasst werden!

Hallo liebes dgMP-Team,

die Klickdummys sind unglaublich hilfreich!
Als konstruktive Kritik:
Wie an anderer Stelle kommentiert, ist die ePA und damit der dortige eMP für die ärztliche Arbeit nur additiv zu sehen - und selbst für den einzelnen Patienten teilweise nicht erreichbar, selbst wenn der Patient eine ePA hat (z.B. weil eine Befugnis abgelaufen ist und der Patient bzw. seine eGK nicht vor Ort ist).

Das bedeutet, dass die führende Arbeit des Arztes nicht in den Daten der ePA (dem dortigen eMP) erfolgen kann, sondern in den lokal im PVS gehaltenen Daten - die um die Daten der ePA angereichert werden, SOFERN die ePA und ein dortigen eMP in dieser Situation erreichbar ist.
Dabei wird der Arzt immer im angezeigten eMP sehen wollen, welche Einträge des eMP aus seiner Praxis kommen und welche Einträge aus seiner Sicht Fremdeinträge sind.
Dies inkludiert, dass das PVS im Behandlungsfall darstellen muss, welchen Stand der lokale eMP hat und welche Informationen des ePA-eMP sich seit dem letzten Mal geändert haben - und damit für den Arzt prüfrelevant sind.

Dieses Zusammenspiel zwischen lokalen Daten im PVS (Verordnungsliste, MP) und den Daten in der ePA (eMP, eML) ist anspruchsvoll und muss prozessseitig durch entsprechend Datenfelder unterstützt werden, die eine Synchronisation erlauben.

Es wäre wünschenswert, wenn die UX-Simulation dieses Zusammenspiel abbilden würde, um mögliche "Knackpunkte" in den Festlegung finden zu können. Die "letzten eigenen Rezepte" neben dem Medikationsplan darzustellen, wird vermutlich den Ärzten nicht ausreichen.

Hallo liebes dgMP-Team,

in den Beschreibungen wird widerholt betont, dass eine Verordnung nicht zwingend ein Rezept auslösen muss. Es wird jedoch (soweit ich sehen konnte) weder in den beschreibenden Texten noch in den Diagrammen dargelegt, in welchen Fällen eine Verordnung nicht zu einem Rezept führt (vermutlich innerhalb der Klinik?) und wie in diesen Fällen die Verordnungsdaten fließen bzw. wo und wie die Verordnungsdaten (ohne Rezept) erfasst und gespeichert werden.

Hallo liebes dgMP-Team,

die Arbeiten eines Arztes, finden natürlich in seinem PVS statt. Die ePA und dort die eML sowie eMP sind systemisch betrachtet zwingend als zusätzliche Informationsquellen und -senken zu sehen.
D.h. wenn ein Prozess für Ärzte modelliert wird, findet die Dokumentation zuerst im PVS statt und zusätzlich in der ePA (sofern vorhanden UND aktuell erreichbar, ansonsten muss nachgetragen und möglicherweise nachgelagert interveniert werden!).
Dazu gehört auch, dass eine Verordnungsanfrage durch den Arzt auch mit den lokalen Medikationsinformationen im PVS verglichen wird ("Was habe ICH bislang verordnet?").

Dies Komplexitätssteigerung ist für die Ausgestaltung der Prozesse und auch der Daten in so weit relevant, weil "Kopplungsinformationen" benötigt werden und Prozessabfolgen (Zusammenspiel zwischen PVS und ePA, auch zeitlich verzögert!) berücksichtigt werden müssen.
All diese Punkte müssen auf PVS/KIS-Seite am Ende berücksichtigt und umgesetzt werden. Daher sollten sie bei der fachlichen und systemischen Konzeption berücksichtigt werden, damit eine für den Arzt taugliche Umsetzbarkeit gewährleistet werden kann.

Diese Beschreibung gilt für die Apotheke und ihr AVS entsprechend, da dort lokale Daten zu Stammkunden vorgehalten & berücksichtigt werden, sowie Zugänge zur ePA nicht, nicht immer oder temporär nicht möglich sind und entsprechend auch dort gegebenfalls nachgelagert gearbeitet und interveniert werden muss.

Grundsätzlich empfehlen wir, die Daten hinsichtlich der Kategorie Fertigarzneimittel und Rezepturen zu trennen. Denn damit, könnten einheitliche Regelung deutlicher dargestellt werden.

Zu Datenelement 2.20.1.1.1 PZN:
Änderung: Konformität von O auf R
Begründung: Fertigarzneimittel sollten zwingend mit ihrer PZN codiert werden, um eine Zuordnung zu gewährleisten.

Zu Datenelement 2.20.1.2 Bezeichnung:
Änderung: Kardinalität von 0…1 auf 1…1 und Konformität von O auf M
Begründung: nach § 31a Abs. 3a S. 1 SGB V „sind <span class="error">[bei der Angabe von Fertigarzneimitteln]</span> im Medikationsplan neben der Arzneimittelbezeichnung insbesondere auch die Wirkstoffbezeichnung, die Darreichungsform und die Wirkstärke des Arzneimittels anzugeben.“

Zu Datenelement 2.20.4 Darreichungsform - Code/Bezeichnung:
Änderung: Kardinalität von 0…1 auf 1…1 und Konformität von O auf M
Begründung: nach § 31a Abs. 3a S. 1 SGB V „sind <span class="error">[bei der Angabe von Fertigarzneimitteln]</span> im Medikationsplan neben der Arzneimittelbezeichnung insbesondere auch die Wirkstoffbezeichnung, die Darreichungsform und die Wirkstärke des Arzneimittels anzugeben.“

Zu Datenelement 2.20.4.1 Code-Auswahl:
Änderung: Kardinalität von 0…* auf 2…* und Konformität von O auf M
Begründung: nach § 31a Abs. 3a SGB V „sind <span class="error">[bei der Angabe von Fertigarzneimitteln]</span> im Medikationsplan neben der Arzneimittelbezeichnung insbesondere auch die Wirkstoffbezeichnung, die Darreichungsform und die Wirkstärke des Arzneimittels anzugeben. Hierfür sind einheitliche Bezeichnungen zu verwenden, die in der Referenzdatenbank nach § 31b zur Verfügung gestellt werden.“

Da „2.20.4.1.2 EDQM“ und „2.20.4.1.4 Bezeichnung nach Referenzdatenbank § 31b“ zwingend anzugeben sind, kann die Kardinalität nur 2…* sein. (siehe Begründung zu 2.20.4.1.2 EDQM)

Zu Datenelement 2.20.4.1.2 EDQM:
Änderung: Kardinalität von 0…1 auf 1…1 und Konformität von O auf M
Begründung: EDQM ist das europäische einheitliche System zu Qualifizierung von Darreichungsformen und ist für die europäische elektronische Patientenakte vorgesehen. Daher halten wir es für zwingend erforderlich, auch im deutschen Medikationsplan EDQM zu verwenden.

Auch hier wäre es wünschenswert, sofern die Übernahme in die Primärsysteme der Pflege vorgesehen, diese mit entsprechenden Visualisierungen zu hinterlegen.

Auch hier vermisse ich die Möglichkeit für die Pflege, die Daten in ihre Systeme zu übernehmen.

Warum wird in das Szenario die Pflege, wie in der Pflege Journey <span class="nobr"><a href="https://www.ina.gematik.de/mitwirken/arbeitskreise/pflege-journey" class="external-link" rel="nofollow">https://www.ina.gematik.de/mitwirken/arbeitskreise/pflege-journey^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> skizziert, einbezogen?

alle überschriebenen Felder (must support, fixed values, etc) sollten auch eine Description/short description enthalten

• meta
• meta.versionId
• meta.lastUpdated
• meta.profile
• meta.profile.mioProfile
• text.status
• Hinweis.value
• patient

alle überschriebenen Felder (must support, fixed values, etc) sollten auch eine Description/short description enthalten

• meta
• meta.versionId
• meta.lastUpdated
• meta.profile
• meta.profile.mioProfile
• text.status
• target.reference
• target.identifier
• target.display
• recorded
• agent.who.reference
• agent.who.identifier

alle überschriebenen Felder (must support, fixed values, etc) sollten auch eine Description/short description enthalten

• meta
• meta.versionId
• meta.lastUpdated
• meta.profile
• meta.profile.mioProfile
• text.status

alle überschriebenen Felder (must support, fixed values, etc) sollten auch eine Description/short description enthalten

• meta
• meta.versionId
• meta.lastUpdated
• meta.profile
• meta.profile.mioProfile
• text.status
• identifier.ANR.type
• identifier.ANR.system
• identifier.ANR.value
• idenifier.EFN.*
• identifier.ZANR.*
• identifier.Telematik-ID.*
• telecom.system
• telecom.value
• gender
• gender.other-amtlich
• birthDate
• qualification.*

Karidnalität 1 auf code/coding bei

• identifier.Institutskennzeichen.type
• identifier.betriebsstaettennummer.type
• identifier.VKNR.type
• identifier.KZV-Abrechnungsnummer.type
• identifier.Telematik-ID.type

Was ist der Grund für die Beschränkung der Kardinalität und Fixierung des CodeSystems? Sollte es nicht offen gelassen werden, falls andere CodeSysteme die Codierung ablösen, ergänzen oder detaillieren sollten?

alle überschriebenen Felder (must support, fixed values, etc) sollten auch eine Description/short description enthalten

• meta
• meta.versionId
• meta.lastUpdated
• meta.profile
• meta.profile.mioProfile
• text.status
• ergaenzende_Angaben.value
• ergaenzende_Angaben.valueString
• identifier.Institutskennzeichen
• partOf.reference
• partOf.identifier

alle überschriebenen Felder (must support, fixed values, etc) sollten auch eine Description/short description enthalten

• meta
• meta.versionId
• meta.lastUpdated
• meta.profile
• meta.profile.mioProfile
• text.status
• subject
• subject.identifier
• performer.reference
• performer.identifier
• hasMember.reference

alle überschriebenen Felder (must support, fixed values, etc) sollten auch eine Description/short description enthalten

• meta
• meta.versionId
• meta.lastUpdated
• meta.profile
• meta.profile.mioProfile
• text.status
• subject
• subject.identifier
• performer.reference
• performer.identifier

alle überschriebenen Felder (must support, fixed values, etc) sollten auch eine Description/short description enthalten

• meta
• meta.versionId
• meta.lastUpdated
• meta.profile
• meta.profile.mioProfile
• text.status
• subject
• subject.identifier
• effective
• performer.reference
• performer.identifier
• value

alle überschriebenen Felder (must support, fixed values, etc) sollten auch eine Description/short description enthalten

• meta
• meta.versionId
• meta.lastUpdated
• meta.profile
• meta.profile.mioProfile
• text.status
• subject
• subject.identifier

alle überschriebenen Felder (must support, fixed values, etc) sollten auch eine Description/short description enthalten

• meta
• meta.versionId
• meta.lastUpdated
• meta.profile
• meta.profile.mioProfile
• text.status
• subject
• subject.identifier
• value

alle überschriebenen Felder (must support, fixed values, etc) sollten auch eine Description/short description enthalten

• meta
• meta.versionId
• meta.lastUpdated
• meta.profile
• meta.profile.mioProfile
• text.status
• subject
• subject.identifier
• value

code.coding mit 2 Einträgen? Reicht dort nicht 1..*? Müssen LOINC und SNOMED angegeben werden?

alle überschriebenen Felder (must support, fixed values, etc) sollten auch eine Description/short description enthalten

• meta
• meta.versionId
• meta.lastUpdated
• meta.profile
• meta.profile.mioProfile
• text.status
• subject
• subject.identifier
• effective
• performer.reference
• performer.identifier
• value