Stellungnahmen

Sehr geehrtes dgMP-Team,

der bvitg e. V. bedankt sich für die Möglichkeit zur Teilnahme an der Benehmensherstellung. Da die Einladung zur Benehmensherstellung für das MIO Medikationsplan und die AMTS-Relevante Zusatzinformationen am gleichen Tag der Veröffentlichung der ePA Spezifikation 3.1.0 der gematik einging, war es uns auch durch die Sommerpause und der kurzen Frist leider kaum möglich, den MIO Medikationsplan und die AMTS-Relevante Zusatzinformationen noch mal genauer zu prüfen. Dennoch sehen wir aufgrund des zu erwartenden mehrmonatigen Rollouts den Bedarf für ein Migrationskonzept, aus dem auch hervorgeht, wie damit umzugehen ist, wenn eine Gesundheitseinrichtung z.B. im dritten Quartal 2025 noch keine ePA-3.1-fähige Software einsetzt. Konkret: Zu einer Patientin / einem Patienten liegt bei Aufnahme der Medikationsplan nur als (durch diese Gesundheitseinrichtung noch nicht verarbeitbarer) MIO-eMP in der ePA vor. Bei Behandlungsabschluss soll der eMP aktualisiert werden, was zu diesem Zeitpunkt dieser Gesundheitseinrichtung nur im bisherigen eMP Format möglich ist.

Wir möchten uns auch im Rahmen der Benehmensherstellung für die stets konstruktive Zusammenarbeit bedanken.

Wir bedanken uns für die Möglichkeit zur Stellungnahme und begrüßen ausdrücklich die gründliche Visualisierung möglicher elektronischer Medikationspläne (eMPs) sowie die Bemühungen um eine benutzerfreundliche Darstellung (UX) und das Angebot eines Klick-Dummys.

Leider mussten wir feststellen, dass die Pflegebranche in der aktuellen Entwicklung des MIO Medikationsplans nicht berücksichtigt wurde. Diese wird auch durch die Darstellung im FAQ zur Frage „Wie arbeiten wir?“ sichtbar. Der Austausch findet hier ausschließlich mit Medizinern statt. Im Gegensatz zu den Darstellungen der Integration in Systeme der Apotheken, Ärzte, Rettungskräfte und Krankenhäuser, fehlt die Darstellung des eMPs in einem Primärsystem der Pflege gänzlich.

Es ist unabdingbar, dass auch Leistungserbringer der Pflege von Anfang an in den Entwicklungsprozess einbezogen werden, da sie maßgeblich mit den MIOs arbeiten werden.

Eine umfassende Stellungnahme wird dadurch erschwert, da wir in die Kommentierungsphase nicht einbezogen wurden und damit nur knapp 10 Tage Zeit hatten, uns mit dem eMP, den AMTS-rZI und dem wenig übersichtlichem Aufbau der Webseite und der dort enthaltenen Informationen auseinanderzusetzen. Darüber hinaus sind einige Unterseiten auf der Webseite noch in der Erstellung (FB 4- FHIR, Phase II), was eine vollständige Stellungnahme ebenso erschwert.

Besonders relevant für die Pflege sind zwei Punkte, die aus den bisherigen Kommentierungen hervorgehen:

1. Absetzen eines Medikaments: Es ist dringend erforderlich, einen klar definierten und standardisierten Prozess für das Absetzen von Medikamenten zu etablieren. Dies ist notwendig, um Medikationsfehler zu vermeiden, die Sicherheit der Patienten zu gewährleisten und den zusätzlichen Aufwand für Pflegekräfte durch wiederholtes Nachfragen bei den verordnenden Ärzten zu reduzieren

2. Dosisänderung eines Medikaments: Dasselbe gilt für die Darstellung und Kennzeichnung von Dosisänderungen. Diese müssen klar und verpflichtend dokumentiert werden und für die Pflegekräfte im eMP eindeutig erkennbar sein.

Für die Pflege ist es von zentraler Bedeutung, dass jederzeit erkennbar ist, ob der eMP aktuell ist und/oder Veränderungen vorgenommen wurden.

Um eine praxisgerechte Erstellung der MIOs zu gewährleisten und die Akzeptanz bei allen Beteiligten zu fördern, ist es essenziell, alle Leistungserbringer von Anfang an in den Entwicklungsprozess einzubeziehen und neue MIOs ausgiebig zu testen.

Nur so kann sichergestellt werden, dass der eMP auch in der Pflege optimal genutzt werden kann und die medikamentöse Versorgung der Patienten weiterhin sichergestellt und verbessert wird.

Wir bedanken uns für die Spezifikation der MIO Medikationsplan und der AMTSrZI, sowie für die Möglichkeit der Stellungnahme im Rahmen der Benehmensherstellung.

Wir haben GMDS-seits zusammen mit dem SITIG, die folgende Anmerkungen:
Verfügungstellung eines vollständigen Glossars verendeter Begriffe/Datenbezeichnungen zur Vermeidung von Fehlinterpretationen
Um ein einheitliches Verständnis der Begriffe/Datenbezeichnungen zur Medikation und zum Kontextes der Datengenerierung sicherzustellen und Fehlinterpretationen zu vermeiden.
Prüfung der Validierungsmöglichkeit von Verordnungsdaten oder automatischen Datenübertragungen im eMP/BMP (s.a.Einbindung der EPAPractitionerRole)
Wir bitten um die Einbindung der Rolle in der Weise, dass Validierungen möglich und sichtbar werden, insbes. wenn automatische und ungepürfte Datenübernahmen erwogen werden.
Ergänzung/Prüfung einer Dokumentationsmöglichkeit der Freisetzungsart (Retardierung Ja/Nein) (gem. <span class="nobr"><a href="https://www.aps-ev.de/hempfehlungen/verordnungspraxis/" class="external-link" rel="nofollow">https://www.aps-ev.de/hempfehlungen/verordnungspraxis/^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>)
Prüfung der verwendeten FHIR Ressource (Medication.form?) ob diese eine Differenzierung von retardiert und unretardierter Form zulässt.
Vermeidung zusätzlicher automatischer und insbes. manuellen Dokumentationsmöglichkeiten in der eML außer der Verordnungs- und Dispensierdaten
Spezifikation einer voreingestellten, fixen Ansicht des eMP/BMP für alle Nutzer auf der zentralen Ablage (TI bzw. in der ePA)
Die Ansicht des zentral abgelegten BMP/eMP sollte für alle Nutzer in allen Sektoren zur leichteren Orientierung einheitlich voreingestellt werden und unveränderlich sein. Das bedeutet, dass die Bedürfnisse insbes. der Kliniken dazu berücksichtig werden sollten. Eine lokal Anpassung durch den Nutzer sollte unabhängig davon möglich sein, aber die zental abgelegten BMP/eMP nicht verändern dürfen.
Verwendung internationaler Klassifikation-/Code-Systeme (z.B. für Darreichungsformen, Applikationsarten , etc) IDMP-konform
Sicherstellung der Aktualität der eingebundenen Klassifikationssysteme (z.B. ATC jährlich)
Ergänzung einer Dokumentationsmöglichkeit von Unerwünschten Arzneimittelwirkungen im Rahmen des Risikoassessments (vgl. FHIR)
zu AMTSrZI:
Prüfung auf vollständige Darstellung der Arzneimitteltypen in den AMTSrZI
(Dauer., Akut-, Bedarfs- und Selbstmedikation) (gem. <span class="nobr"><a href="https://www.aps-ev.de/hempfehlungen/verordnungspraxis/" class="external-link" rel="nofollow">https://www.aps-ev.de/hempfehlungen/verordnungspraxis/^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>). Möglicherweise sind dazu Ergänzungen der verfügbaren FHIR Ressourcen nötig.
Einbindung von Therapiegrund und Therapieziel in die AMTSrTI (gem. <span class="nobr"><a href="https://www.aps-ev.de/hempfehlungen/verordnungspraxis/" class="external-link" rel="nofollow">https://www.aps-ev.de/hempfehlungen/verordnungspraxis/^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>) Wenn AMTSrZI dynamische Ansichten von Daten/FHIR-Ressource werden sollen, dann sollten Therapieziel und Therapiegrund (Übergreifend oder je Arzneimittel) in die Ansicht der AMTSrZI eingebunden werden. Für Therapieziel/grund z.B. MedicationStatement.reasonCode oder MedicationRequest.extension:behandlungsziel (Freitext)

Bitte die Spec. auseinander halten. Liste, Plan, AMTS etc sind in sich geschlossene Specs, die mit anderen Specs (zB Labor) zusammengeführt werden sollen.

Der bestehende Medikationsplan (BMP) mit Barcode muss erhalten bleiben. Es muss eine Übergangslösung / Rückfalloption (z.B. bei Stromausfall) geben.

Alle FHIR Spezifikationen müssen über HL7 Germany abgestimmt werden.

AG AIS und AG SIE und SITIG Spitzenverband

Wir bedanken uns für die Gelegenheit zur Stellungnahme und möchten folgende Rückmeldungen zum MIO Medikationsplan Version 1.0.0 geben:

Genauere Beschreibung des Usecases „Verwaltung aller Medikationsdaten“:
Allgemein: Betrifft <span class="nobr"><a href="https://simplifier.net/guide/medication-service?version=current" class="external-link" rel="nofollow">https://simplifier.net/guide/medication-service?version=current^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Kommentar: Aus dem Scope „Verwaltung aller Medikationsdaten“ unter <span class="nobr"><a href="https://simplifier.net/guide/medication-service?version=current" class="external-link" rel="nofollow">https://simplifier.net/guide/medication-service?version=current^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> wird nicht klar, ob auch Rezepturarzneimittel oder patientenindividuell hergestellte Arzneimittel (Zytostatika) mit erfasst werden sollen und ob eine wirkstoffbasierte Dokumentation (Wirkstoffverordnung) möglich ist. Das Datenmodell und die Beschreibung der Constraints scheinen dies zu berücksichtigen. Das Informationsmodell sollte die Referenz auf das Pharmaceutical Product berücksichtigen.

Strukturierte Kennzeichnung von Kombinationspackungen
Betrifft: Valueset Medication Type <span class="nobr"><a href="https://simplifier.net/epa-medication/epa-medication-type-vs" class="external-link" rel="nofollow">https://simplifier.net/epa-medication/epa-medication-type-vs^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> bzw. <span class="nobr"><a href="https://simplifier.net/epa-medication/epa-medication-type-pharmaceutical-product-vs" class="external-link" rel="nofollow">https://simplifier.net/epa-medication/epa-medication-type-pharmaceutical-product-vs^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Kommentar: Das Valueset Medication Type <span class="nobr"><a href="https://simplifier.net/epa-medication/epa-medication-type-vs" class="external-link" rel="nofollow">https://simplifier.net/epa-medication/epa-medication-type-vs^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> bzw. <span class="nobr"><a href="https://simplifier.net/epa-medication/epa-medication-type-pharmaceutical-product-vs" class="external-link" rel="nofollow">https://simplifier.net/epa-medication/epa-medication-type-pharmaceutical-product-vs^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>
kennzeichnet Fertigarzneimittel und Rezepturarzneimittel und auch, ob es sich beim Fertigarzneimittel um eine Kombinationspackung aus mehreren Darreichungsformen handelt <span class="error">[781405001 Medicinal product package (product); 1208954007 Extemporaneous preparation (product); 373873005 Pharmaceutical / biologic product (product)]</span>
In SNOMED CT sind sowohl „extemporaneous preparation“ als auch „Medicinal product package“ Unterbegriffe des Oberbegriffs für pharmazeutische Produkte „Pharmaceutical / biologic product“ allgemein. Die Zuordnung „Inhalt einer Kombinationspackung“ sollte daher über einen anderen (neuen) Wert erfolgen, da eine diskriminierende Zuordnung im Sinne der SNOMED-CT-Logik nicht möglich ist. Bei der Modellierung sollte folgendes Dokument beachtet werden <span class="nobr"><a href="https://confluence.ihtsdotools.org/display/IAP/Reference+Documentation+-+Medicinal+Product+Model?preview=/31987859/115874595/SNOMED%20CT%20Medicinal%20Product%20Model%20Specification%20v3.pdf" class="external-link" rel="nofollow">https://confluence.ihtsdotools.org/display/IAP/Reference+Documentation+-+Medicinal+Product+Model?preview=/31987859/115874595/SNOMED%20CT%20Medicinal%20Product%20Model%20Specification%20v3.pdf^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>.

Anwendung der Referenzdaten gemäß § 31b SGB V nicht nur für Inhalte der Kombinationspackungen
Betrifft: Profil <span class="nobr"><a href="https://simplifier.net/epa-medication/epamedicationpharmaceuticalproduct" class="external-link" rel="nofollow">https://simplifier.net/epa-medication/epamedicationpharmaceuticalproduct^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Kommentar: Gemäß Constraint „epa-med-2“ sind Inhalte von Kombinationspackungen – und nur diese - durch das Profil <span class="nobr"><a href="https://simplifier.net/epa-medication/epamedicationpharmaceuticalproduct" class="external-link" rel="nofollow">https://simplifier.net/epa-medication/epamedicationpharmaceuticalproduct^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> zu beschreiben. Das bedeutet, dass die Referenzdaten gemäß § 31b SGB V nicht für alle anderen Fertigarzneimittel zu nutzen sind bzw. genutzt werden können. Das widerspricht dem Ziel von Referenzdaten.
Das Constraint „epa-med-2“ sollte so geändert werden, dass die Referenzdaten in Sinne der Interoperabilität auch für alle anderen Fertigarzneimittel genutzt werden können / sollen.

Anpassung des Modells für das Pharmazeutische Produkt (für Kombinationpackungen) an die aktuelle Ausbaustufe der Referenzdatenbank § 31b SGB V
Betrifft: Profil <span class="nobr"><a href="https://simplifier.net/epa-medication/epamedicationpharmaceuticalproduct" class="external-link" rel="nofollow">https://simplifier.net/epa-medication/epamedicationpharmaceuticalproduct^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Kommentar:

• Gemäß § 31a Abs. 3a SGB V sollen für den Medikationsplan einheitliche Bezeichnungen zur Beschreibung von Wirkstoff, Darreichungsform und Wirkstärke basierend auf der Referenzdatenbank § 31b SGB V verwendet werden. Die Modellierung muss also sicherstellen, dass die vom BfArM bereitgestellten Referenzdaten integriert werden können. Das Modell sollte daher entsprechend an die Gegebenheiten der Referenzdaten angepasst werden.
• Insbesondere betrifft das die Verweise auf die strukturierten Wirkstoffdaten (Referenzdaten = ASK-Nummer), Darreichungsform (Referenzdaten = erweiterte EDQM Standard Terms pharmaceutical form) sowie eine Darstellung von Wirkstärke und Einheit als gemeinsames Freitextfeld. Im Sinne der Interoperabilität sollten weitere Optionen zur Bereitstellung als strukturierte Informationen sehr restriktiv (KBV-Darreichungsformen, EDQM, SNOMED, UCUM, ATC als Zusatzinformationen) behandelt werden.
• Die Modellierung des Pharmazeutischen Produktes sollte nochmal überprüft werden, ob alle vererbten Datenelemente wirklich an dieser Stelle gebraucht werden oder sinnvoll sind. Eine Vererbung von EPAMedication sollte grundsätzlich nicht angestrebt werden, da die Unterschiede in der Form der Darstellung doch zu groß sind. Das Profil für das pharmazeutische Produkt sollte sich inhaltlich sehr eng an der Referenzdatenbank und ihren Besonderheiten orientieren. Entsprechend sollte sich das auch in den Elementen widerspiegeln. Die Extensions zur Produktklassifizierung, die alternativen Optionen zur Übermittlung von Stoffinformationen unter dem „Produkt-Code“ und unter „ingredient“, Hinweise zum Status, zu Amount, zum Hersteller oder zum Batch auf dieser Ebene.
• Der code und somit auch der "product-key" sollten hier verpflichtend anzugeben sein, da mit diesem Profil eigentlich die Referenzdatenbank adressiert werden soll. Die Slices für pzn, atc-de, ask, snomed könnten dann entsprechend entfernt werden.
• In der Referenzdatenbank wird auf strukturierte Daten zu Darreichungsformen verwiesen. Diese sollten explizit bereitgestellt und referenziert werden. Das preferred Binding an <span class="nobr"><a href="http://hl7.org/fhir/uv/ips/ValueSet/medicine-doseform" class="external-link" rel="nofollow">http://hl7.org/fhir/uv/ips/ValueSet/medicine-doseform^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> sollte durch dieses neue Valueset ausgetauscht werden.
• In der Referenzdatenbank wird auf strukturierte Daten zu Wirkstoffen (ASK) verwiesen. Diese sollten explizit bereitgestellt und referenziert werden. Eine Referenz auf ATC-DE und SNOMED CT entspricht nicht den aktuellen Gegebenheiten der Referenzdatenbank.
• Die Informationen zu „strength“ werden aktuell in der Referenzdatenbank als Stärke und Einheit in einem Stringfeld abgebildet.
• Die zur Referenzdatenbank bereitgestellten Examples stimmen nicht mit den Daten und dem Aufbau der Referenzdatenbank überein. Das sollte im Sinne einer Validierbarkeit angepasst werden.
• Der Display Namen sollte nicht die Darreichungsform des Teil-Arzneimittels sein, sondern die SubID der PZN mit „Produktname XY - Teil 1“ und „Produktname XY - Teil 2“ ausgelesen und interpretiert werden.
  Wir schlagen vor, das Profil für das pharmazeutische Produkt inhaltlich sehr eng an die aktuellen Gegebenheiten der Referenzdatenbank § 31b SGB V und deren zeitnahe Bereitstellung auf dem zentralen Terminologieserver zu orientieren.

Redundante Datenfelder für Stoffbezeichnungen
Betrifft: Profil <span class="nobr"><a href="https://simplifier.net/epa-medication/epamedication" class="external-link" rel="nofollow">https://simplifier.net/epa-medication/epamedication^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Kommentar: Sowohl auf Ebene „Medikation“ als auch auf Ebene „Ingredient“ werden redundant die Kodesysteme ASK, ATC-DE und SNOMED CT verwendet. Diese bezeichnen üblicherweise Stoffe. Möglicherweise ist das der Nutzung des Modells auch für Wirkstoffverordnungen geschuldet, die üblicherweise auf Stoffebene dokumentiert werden.
Wir bitten zu prüfen, ob diese Redundanz im Datenmodell notwendig und sinnvoll ist.

Versionierung von Kodiersystemen und Wertelisten
Betrifft: Alle verwendeten CodeSystems und ValueSets (s. <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>)

Kommentar:

• 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 auf der Kommentierungsseite vorgegebenen Versionen nicht verbindlich umgesetzt werden.
• Durch eine Referenz auf vorgegebene Versionen können aktuellere Versionen nicht genutzt werden und z.B. neue Wirkstoffe (ATC-GM) oder Darreichungsformen nicht übertragen werden. Die Referenzdatenbank § 31b SGB V wird 14-tägig aktualisiert.
• Die Notwendigkeit einer Vorgabe von 2 unterschiedlichen verbindlichen SNOMED CT-Versionen, Version <span class="nobr"><a href="http://snomed.info/sct/900000000000207008/version/20230731" class="external-link" rel="nofollow">http://snomed.info/sct/900000000000207008/version/20230731^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> und Version <span class="nobr"><a href="http://snomed.info/sct/900000000000207008/version/20200131" class="external-link" rel="nofollow">http://snomed.info/sct/900000000000207008/version/20200131^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>, sollte in diesem Zusammenhang nochmal geprüft werden.
  Wir schlagen vor, dass in allen Profilen sichergestellt wird, dass für sämtliche verwendete Codings verbindlich eine Version dokumentiert und übermittelt wird. Die Spezifikation soll sicherstellen, dass immer klar ist, welche Version konkret verwendet wurde. Dies ermöglicht, dass auch aktuellere bzw. jeweils die aktuellste Version genutzt werden kann, und unterstützt eine Weiternutzung und Erweiterung von Daten im Medikationsplan im Zeitverlauf (d.h. die Medikation muss mit neuen Releases nicht immer auf den neuen Release-Stand „nachgezogen“ werden).

Nutzung der im aufzubauenden zentralen Terminologieserver § 355 SGB V referenzierten Canonical URLs für die vom BfArM verantwortende Kodiersysteme
Betrifft: CodeSystems, die in der Ownership des BfArM liegen (s. <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>)

Kommentar: 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 verantworteten Kodiersysteme in ein FHIR-Format konvertiert. Dies betrifft insbesondere dies die Canonical URLs für die ICD-10-GM und die alphaID-SE und zukünftig ggf. weitere wie ASK und ATC-GM sowie die in der Referenzdatenbank verwendeten Darreichungsformen. Die Diskussion, welche Canonical URLs verwendet werden sollen, muss noch abschließend geführt und Festlegungen getroffen werden, um ev. Redirects vorzubereiten.
Wir schlagen vor, die abschließend festzulegenden Canonical URLs im MIO Medikationsplan zu berücksichtigen. Den Softwareherstellern soll die Möglichkeit gegeben, diese über den Terminologieserver aufzulösen, und damit die Sicherheit zu haben, dass korrekte Kodiersysteme und Wertelisten verwendet werden.

Nutzung des Kodiersystem Alphaid
Betrifft: Profil <span class="nobr"><a href="https://simplifier.net/epa-medication/epamedicationstatement" class="external-link" rel="nofollow">https://simplifier.net/epa-medication/epamedicationstatement^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Kommentar: Im Profil Medication Statement wird die alphaID neben ICD-10-GM, SNOMED CT und Orphacodes vorgeschlagen, um Gründe für eine Medikation zu kodieren. Hier sollte spezifiziert werden, welche Inhalte mit der alphaID transportiert werden sollen. Ist hier das Alphabet der ICD-10-GM gemeint, um Inhalte über die ICD-10-GM hinaus genauer abbilden zu können? Ist die Nutzung als Alpha-ID-SE gemeint als Brücke den Orphacodes, um seltene Erkrankungen in der Patientendokumentation zu dokumentieren? Welche veröffentlichte Quelle soll durch Softwarehersteller verwendet werden?
Sofern der Informationsbaustein „alphaID“ dazu genutzt werden soll, seltene Erkrankungen zu dokumentieren, wäre die alphaID als Kodiersystem entbehrlich, da seltene Erkrankungen in der Patientendokumentation mit Orphacodes abgebildet werden.

Handlungsempfehlungen für die Verwendung von Kodiersystemen
Betrifft: Alle im MIO verwendeten CodeSystems und ValueSets (s. <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>)

Kommentar:
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.

Referenz zu EDQM-Standardterms für Darreichungsformen
Betrifft: Profil <span class="nobr"><a href="https://simplifier.net/epa-medication/epamedicationpharmaceuticalproduct" class="external-link" rel="nofollow">https://simplifier.net/epa-medication/epamedicationpharmaceuticalproduct^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> und Element Medication.form.coding:edqm mit preferred Binding zu <span class="nobr"><a href="http://hl7.org/fhir/uv/ips/ValueSet/medicine-doseform" class="external-link" rel="nofollow">http://hl7.org/fhir/uv/ips/ValueSet/medicine-doseform^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Kommentar: Das referenzierte Valueset ist eine Sekundärquelle, deren Aktualität und Korrektheit nicht sichergestellt werden kann. Dieser Verweis sollte durch das in der Referenzdatenbank verwendete BfArM-Valueset für Darreichungsformen ersetzt werden, das die EDQM Standard Terms sowie nationale Erweiterungen enthält.

Harmonisierung mit EU Austauschformaten - Darstellung Allergien sollte harmonisiert mit EU PatientSummary Allergies sein
Betrifft: EPA Allergy Intolerance Profile <span class="nobr"><a href="https://simplifier.net/packages/de.gematik.epa/1.1.0-rc1/files/2464957" class="external-link" rel="nofollow">https://simplifier.net/packages/de.gematik.epa/1.1.0-rc1/files/2464957^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> und EPAAllergyReactionSnomedCTVS <span class="nobr"><a href="https://simplifier.net/packages/de.gematik.epa/1.1.0-rc1/files/2464973" class="external-link" rel="nofollow">https://simplifier.net/packages/de.gematik.epa/1.1.0-rc1/files/2464973^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Kommentar: Im Hinblick auf den Europäischen Gesundheitsdatenraum sollte bei der Darstellung von Informationen, die Teil der Priority Categories Art. 5 EHDS sind, darauf geachtet und darauf hingewirkt werden, dass diese potentiell austauschbar sind. Dies betrifft z.B. Allergien und Intoleranzen und das Valueset AllergyReaction.

Nicht benötigte / referenzierte Ressourcen sollten entfernt werden
Betrifft: Valueset <span class="nobr"><a href="https://simplifier.net/epa-medication/epa-medication-reason-snomed-ct-vs" class="external-link" rel="nofollow">https://simplifier.net/epa-medication/epa-medication-reason-snomed-ct-vs^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Kommentar: Das ValueSet wird innerhalb der Spezifikation (wahrscheinlich) nicht referenziert. Nicht benötigte/verwendete Ressourcen sollten entfernt werden.

Einbeziehung der National Edition von SNOMED CT
Betrifft: Alle codings, die SNOMED CT nutzen

Kommentar: 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, 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.

Liebes Team der MIO42,
wir möchten auf folgenden Punkt hinweisen, der aus unserer Sicht essenziell ist, damit eMP und AMTS-rZI für Privatversicherte überhaupt genutzt werden können: Das Grobkonzept zum Medication Service sieht in seiner aktuellen Fassung vor, dass die Planungsfunktionalität für einzunehmende und zu verordnende Medikamente „erst nach entsprechender Anspruchsvoraussetzung durch ein Primärsystem genutzt werden“ kann. Diese technische Beschränkung darf bei privatversicherten Patientinnen und Patienten nicht zum Einsatz kommen, da Leistungserbringer ansonsten keine Möglichkeit haben, die Funktionalität für diesen Personenkreis zu nutzen.

Die nachfolgende Stellungnahme wird unterstützt durch den Bundesverband Deutscher Apotheken-Softwarehäuser e.V. (ADAS).
Der Deutsche Apothekerverband e.V. (DAV) stimmt der Spezifikation des MIO „Medikationsplan“ 1.0.0 aus den folgenden Gründen nicht zu:

1.) Nicht abgestimmte Einführung neuer Codesysteme
Bei der Vorgabe von Codesystemen wurde nicht berücksichtigt, ob zulässige Codes derzeit von den Primärsystemen verarbeitet werden können. Es ist davon auszugehen, dass Apothekensysteme zum Zeitpunkt der aktuell geplanten Einführung des MIO „Medikationsplan“ (ePA Release 3.1: 15.07.2025) Codes aus den Codesystemen SNOMED CT, LOINC, ALPHA-ID, ORPHANET, UCUM nicht in eine technisch unterstützte AMTS-Prüfung einbeziehen können (ggf. ausgenommen Elemente, bei denen ein stark eingeschränktes und fest definiertes Value Set vorgegeben ist). Damit ist es nicht möglich, z.B. mit SNOMED CT codierte Allergien bei der AMTS-Prüfung zu berücksichtigen. Elektronisch nicht auswertbare Informationen können zu Fehlinterpretationen bei einer AMTS-Prüfung führen und somit die AMTS des Patienten verschlechtern. Die Einführung des MIO „Medikationsplan“ ohne die Möglichkeit einer digital unterstützten AMTS-Prüfung unter Einbeziehung bzw. Verarbeitung aller enthaltenen Daten in der Apotheke lehnen wir daher ab.
Aus unserer Sicht wird damit die gesetzliche Vorgabe nach § 355 Abs. 3a SGB V, die besagt, dass sicherzustellen ist, dass „Daten nach § 31a Absatz 2 Satz 1 sowie Daten des elektronischen Medikationsplans nach § 341 Absatz 2 Nummer 1 Buchstabe b 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“, nicht erfüllt.
Die gesetzliche Vorgabe, grundsätzlich internationale Standards zu verwenden, entbindet nicht von der Pflicht, die Eignung neu zu verwendender Standards in jedem Anwendungsfall zu prüfen und nachvollziehbar darzulegen, weshalb der jeweils ausgewählte Standard am besten geeignet ist bzw. besser als in den jeweiligen Sektoren bereits genutzte Codierungen. Diese Analyse, eine transparente Veröffentlichung und sektorübergreifende Diskussion der Ergebnisse müssen erfolgen, bevor neue Codierungen in Betracht gezogen werden.
Werden neue Codierungen mit entsprechender Begründung zur Nutzung vorgeschlagen, ist es unerlässlich, eine Einführungsstrategie zu erarbeiten und mit den relevanten Sektoren abzustimmen. Dies kann z.B. auch die Vereinbarung eines begrenzten ValueSet beinhalten.
Die Einführung neuer Codierungen darf nicht allein dem Markt überlassen werden, da die vorhersehbaren Umsetzungsprobleme einer interoperablen Anwendung entgegenstehen. Die negativen Folgen technisch nicht verwertbarer oder fehlerhafter Codierungsangaben betreffen sowohl Patienten als auch Leistungserbringer unmittelbar.

2.) Mangelnde Praxistauglichkeit
Das MIO „Medikationsplan“ erlaubt an zahlreichen Stellen die parallele Angabe mehrerer verschiedener Codierungen für das gleiche Element eines Eintrags. Da ein technisch unterstützter Abgleich aufgrund fehlender Mappings derzeit jedoch nicht möglich ist, sind widersprüchliche Angaben möglich, die ggf. durch den lesenden Leistungserbringer nicht erkannt werden bzw. ohne technische Unterstützung nicht erkannt werden können. Gleiches gilt für die parallele Angabemöglichkeit von Code und Freitext. Daraus ergibt sich unmittelbar eine Patientengefährdung. Folgendes Beispiel soll dies verdeutlichen:
Im Implementierungsleitfaden von gematik und mio42 (Stand 17.07.2024) ist eine Inkonsistenz im Beispiel für Allergien (Profil EPAAllergyIntolerance) enthalten. So wurde eine textuell beschriebene Penicillinallergie mit dem SNOMED CT Konzept der Cashewnuss codiert:
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"version": "http://snomed.info/sct/900000000000207008/version/20240501",
"code": "227493005",
"display": "Allergy to penicillin"
}
==> SCITD: 227493005 = Cashew nut (substance)
Selbst wenn man davon ausgeht, dass bei fehlerfreier Implementation Code und Displaywert konsistent sind und dieser Fehler somit nicht auftreten wird, ist es ein durchaus realistisches Szenario, dass beispielsweise „Penicillin-Allergie“ im Freitextfeld (Element AllergyIntolerance.code.text) eingetragen ist, während gleichzeitig Cashewnuss codiert ist. Algorithmisch ist ein derartiger Fehler nicht zu erkennen. Wer trägt hier die Verantwortung für etwaige Schäden von Patienten, wenn Risiken, wie in diesem Beispiel eine Allergie, nicht erkannt werden können, obwohl sie hinterlegt wurden?
Sofern Widersprüche zwischen zwei Angaben bei einer intellektuellen Prüfung erkannt werden, ist die Frage zu klären, welche der Angaben zutrifft. Die Auflösung der Inkonsistenz erfordert die Kontaktaufnahme mit dem eintragenden Leistungserbringer und ist mit einem erwartbar hohen zeitlichen Mehraufwand verbunden, der im Routinebetrieb einer Apotheke nicht leistbar ist.
Es ist daher zwingend erforderlich, in den Profilen die Freiheitsgrade für das eintragende System zu begrenzen, um Redundanzen und potenzielle Widersprüche soweit wie möglich auszuschließen. Sofern potenziell divergierende Angaben nicht gänzlich vermieden werden können, müssen in den von den Primärsystemen verwendeten Datenbanken Mappings verfügbar sein, damit ein technisch unterstützter Abgleich im Primärsystem implementiert werden kann. Es ist unabdingbar, eine anwenderfreundliche Nutzung des MIO „Medikationsplan“ zum Einführungsstart zu ermöglichen, daher ist die Verfügbarkeit der erforderlichen Mappings in den Datenbanken der Primärsysteme zwingend bei der zeitlichen Planung zu berücksichtigen.

3.) Zu hohe Komplexität beim Start der Anwendung
Die Einführung des E-Rezepts hat gezeigt, dass mit dem Auftreten verschiedenster Implementierungsfehler in den Primärsystemen in der Startphase gerechnet werden muss. Das umfangreiche MIO „Medikationsplan“ lässt entsprechend vielfältige Probleme insbesondere bei den eMP lesenden Leistungserbringern erwarten. Damit verbunden sind ein hohes Risiko für einerseits vermeintliche AMTS-Probleme und andererseits unerkannte AMTS-Probleme und daraus resultierend eine mangelnde Akzeptanz des eMP auf Seite der Leistungserbringer.
Bereits zum Start der Implementierung durch die Primärsystemhersteller müssen in den verwendeten Arzneimitteldatenbanken alle im MIO „Medikationsplan“ vorgesehenen Codierungen unterstützt werden. Der dadurch zusätzlich benötigte zeitliche Vorlauf ist mit den Datenbankherstellern abzustimmen. Wird dies bei der Einführung ignoriert, ist die geforderte Interoperabilität zum Start der Anwendung ausgeschlossen.
Grundsätzlich wird für die Umsetzung in den Primärsystemen ein umfassender Implementierungsleitfaden mit einer hohen Zahl realistischer Beispiele benötigt. Abhängig von der Komplexität des MIO „Medikationsplan“ ist von einer Implementierungszeit von 6-12 Monaten ab dem Zeitpunkt der Verfügbarkeit der erforderlichen gematik-Komponenten und von Arzneimitteldatenbanken, die den vollen Leistungsumfang des MIO unterstützen, für die Version 1.0.0 auszugehen.
Wir begrüßen grundsätzlich die Angabemöglichkeiten zu komplexen Dosierungen, in Hinblick auf die AMTS von Patienten sind diese ein wichtiges Element im MIO „Medikationsplan“.
Jedoch bedeuten diese umfassenden Angabemöglichkeiten zu komplexen Dosierungen einen hohen Aufwand durch die Primärsysteme, sodass zum Startzeitpunkt insbesondere auch vor dem Hintergrund der weiteren genannten Umsetzungsaspekte, eine geeignete Umsetzung durch die Primärsysteme nicht erwartet werden kann.
Aus den genannten Gründen ist dringend geboten, die Komplexität des MIO in der ersten Ausbaustufe wesentlich zu verringern und Rahmenbedingungen für eine geordnete Einführung in mehreren Schritten mit den betreffenden Sektoren abzustimmen.

4.) Patientenindividuelle Festlegung der Reihenfolge von Medikationseinträgen bei Anzeige und Ausdruck nicht nutzerübergreifend möglich
Im eMP und somit auch im daraus generierte Bundeseinheitlichen Medikationsplan (BMP) ist es für das Wiederfinden von Informationen für Patienten und damit eine korrekte Arzneimittelanwendung essenziell, dass Leistungserbringer eine patientenindividuelle Reihenfolge der Medikationszeilen festlegen können, die dann systemübergreifend erhalten bleibt, insbesondere damit die Zeilenreihenfolge im BMP-Ausdruck sowie auch im Frontend des Versicherten identisch ist. Bisher sieht die gematik eine zentrale Druckfunktion in der ePA mit einer unveränderbaren vorgegebenen Zeilenreihenfolge vor sowie eine dezentrale Druckfunktion in den Primärsystemen, die zwar eine individuelle Sortierung ermöglichen kann, die jedoch nicht in der PA hinterlegt wird und somit nicht nutzerübergreifend erhalten bleibt. Beide Lösungen werden den Anforderungen an einen Medikationsplan für Patienten nicht gerecht und stellen eine Verschlechterung gegenüber dem bisherigen BMP-Format dar. Dies gefährdet die Akzeptanz des Medikationsplans durch Patienten sowie bei Nichtauffinden bzw. Verwechslung von Informationen deren AMTS. Zudem muss von deutlich höherem Aufwand für den Leistungserbringer durch Nachfragen des Patienten, durch Erklärungsbedarf bzw. erneute Sortierung der Zeilenreihenfolge im jeweiligen Primärsystem ausgegangen werden.
Wir schlagen vor, das MIO „Medikationsplan“ um ein entsprechendes Feld zu ergänzen, zum Beispiel im Element List.entry (Profil EPAMedicationList), um eine individuelle Sortierung zu ermöglichen, die systemübergreifend und bei Nutzung der zentralen Druckfunktion in der ePA erhalten bleibt.
Zudem muss durch ein zentrales Regelwerk systemübergreifend definiert werden, welche Änderungen an der Medikation eine Änderung innerhalb einer Medikationszeile bedeuten, in der Regel jedoch keinen Einfluss auf die Reihenfolge haben, und in welchen Fällen eine neue Medikationszeile angelegt wird, deren Position dann wiederum individuell festgelegt wird.

5.) Patientenverständliche Zwischenüberschriften nicht ausreichend möglich
Wir begrüßen die Aufnahme der definierten Zwischenüberschriften aus der BMP-Spezifikation in das MIO „Medikationsplan“, um den Ausdruck eines Medikationsplans im für Patienten etablierten BMP-Format zu unterstützen. Damit wird auch die entsprechende strukturierte Anzeige im Frontend des Versicherten ermöglicht. Zwischenüberschriften dienen der Strukturierung und Veranschaulichung der Medikationsinformationen für den Patienten. Untersuchungen zum BMP zeigen, dass darin auch individuelle, patientenverständliche Zwischenüberschriften (Freitext) genutzt werden, z.B. indem Medikation für bestimmte Erkrankungen, von bestimmten Ärzten oder mit bestimmten Einnahmeintervallen von der übrigen Medikation abgegrenzt wird, um das Verständnis des Patienten und damit die AMTS zu gewährleisten. Hierzu sind Nachbesserungen im MIO „Medikationsplan“ erforderlich, die auch die im BMP mögliche Variante von Freitextzwischenüberschriften beinhalten sollten.

6.) Zu kurze Frist für die Benehmensherstellung
Aufgrund des beträchtlichen Umfangs des MIO und der im Vergleich zum Kommentierungsverfahren gänzlich anderen Darstellung der inhaltlichen Festlegungen zum Informationsmodell ist eine auf 9 Arbeitstage verkürzte Frist zur Benehmensherstellung (laut Verfahrensordnung: in der Regel 4 Wochen) inakzeptabel. Eine vollständige Prüfung der Spezifikation war in dieser Zeit nicht möglich.

Darüber hinaus haben wir folgende Anmerkungen (nicht abschließend):

• Codesysteme für die Abbildung von Arzneimitteln: Verpflichtende Angabe der PZN
  Der elektronische Medikationsplan sieht für die Abbildung von Arzneimitteln neben PZN auch ATC-DE, ASK und SNOMED CT vor. Es wird jedoch nur durch die PZN immer ein konkretes Arzneimittel definiert.
  SNOMED CT kann dies näherungsweise durch Konzepte des semantic tags „clinical drug“, ist dort allerdings eher auf den anglo-amerikanischen Markt fokussiert. Die „clinical drug“ sind eine generische Ebene, die den Arzneimittelmarkt in Deutschland nur unzureichend abbildet. Zudem wären derzeit auch SNOMED CT-codierte Substanzen, also Arzneistoffe, und weitere, deutlich unpräzisere generische Arzneimittelebenen (z.B. Arzneimittel enthält Ibuprofen <span class="error">[aber nicht nur Ibuprofen]</span>) zulässig.
  (Arznei-)Stoffe, wie in ATC-DE, ASK oder auch SNOMED CT substance beschrieben, sind jedoch keine Arzneimittel, sondern deren Bestandteile.
  Für die Angabe von Arzneimitteln sollte entsprechend immer die Angabe einer PZN verbindlich sein – schon allein wegen der Prüfung auf Allergien und Unverträglichkeiten von Hilfsstoffen.
  Im Falle von Rezepturen, also durch die Apotheke hergestellte individuelle Anfertigungen, und Import-Arzneimittel ohne eigene Markt-PZN, können analog dem Vorgehen beim E-Rezept Sonder-PZN (Sonderkennzeichen) entsprechend der Technischen Anlage 1 (inkl. Anlagen) zur Arzneimittelabrechnungsvereinbarung gemäß § 300 Absatz 3 SGB V eingetragen werden, verbunden mit einer Freitextangabe zur Rezeptur bzw. dem Import-Arzneimittel (entspricht der Verordnung auf E- und Papierrezept).

• Abbildung von Stoffen durch SNOMED CT: Begrenzung auf real existierende Substanzen
  Im Bereich von Allergien sind 28.000 Nachkommen des SNOMED CT Konzepts „substance“ zulässig. Hierunter liegen konkrete Stoffe, aber auch abstrakt aggregierende Konzepte, beispielsweise zu nennen wäre „312415009 | Chemical categorized by structure (substance) |“. Eine derartige Codierung hätte allerdings keinerlei Informationsgehalt.
  Es sollte mittels ValueSets sichergestellt werden, dass nur real existierende Substanzen codiert werden dürfen.

• ValueSet Binding grundsätzlich „required“
  Das Binding von ValueSets muss grundsätzlich „required“ sein, da offene ValueSets nicht vertretbare Implementierungsaufwände bedingen. Die Einschränkung auf das Binding „extensible“ ist nicht ausreichend. Wenn im ValueSet kein geeigneter Code vorhanden ist, kann eine Angabe im Freitext erfolgen.
  Beispiele:
  • Element AllergyIntolerance.reaction.manifestation.coding:snomed: ValueSet EPAAllergyReactionSnomedCTVS
  • Element AllergyIntolerance.reaction.exposureRoute.coding:snomed ValueSet EPARouteOfAdministrationSnomedCTVS
  • Element MedicationStatement.statusReason.coding:snomed ValueSet EPADrugTherapyStatusSnomedCTVS

• Profil EPAObservationBodyWeight
  Elemente Observation.value<span class="error">[x]</span> und Observation.value<span class="error">[x]</span>:valueQuantity besitzen das Binding package/ValueSet-VitalSignDE-Body-Weigth-UCUM.json (required) während das Element Observation.value<span class="error">[x]</span>:valueQuantity.code das Binding package/ValueSet-UcumVitalsCommonDE.json (required) vorgibt. Es darf ausschließlich das ValueSet ValueSet-VitalSignDE-Body-Weigth-UCUM.json (required) nutzbar sein.

Sehr geehrtes dgMP-Team,
wir nehmen im Rahmen der Benehmensherstellug nochmals Bezug auf zwei Punkte, die wir bereits im Rahmen der öffentlichen Kommentierung angemerkt haben.

1) Migration der bestehenden Informationen (eMP auf eGK sowie BMP) in dgMP
Die Migration der bestehenden Informationen wird in der Leistungserbringerumgebung erheblichen Aufwand auslösen. Die Unterschiedlichkeit der Primärsysteme ist uns bewusst, ebenso wie die unterschiedliche lokale Datenhaltung. Dennoch möchten wir eindringlich darum bitten, allgemeingültige Vorgaben in das MIO aufzunehmen, die den Leistungserbringern die Migration erleichtern. Konkret kann z.B. aufgenommen werden, dass das Primärsystem alle Pflichtfelder des dgMP bei der initialen Erstellung bereits automatisiert vorab befüllt, sofern Daten vorhanden sind, und diese dann händisch ergänzt bzw. korrigiert werden. Solche Vorgaben können unabhängig vom einzelnen Primärsystem dennoch eine Arbeitserleichterung in der Leistungserbringerumgebung ermöglichen.

2) Ausdruck eMP übergangsweise mit QR-Code bis Verbreitung des dgMP hoch genug ist
In der Kommentierung haben Sie die Ablehnung dieses Punktes mit der Gefahr begründet, dass der gedruckte BMP nicht die aktuellsten Daten enthält. Ein Umweg der Datensynchronisation am aktuellen Datenstand der ePA vorbei soll aus Ihrer Sicht nicht etabliert werden.
In den Fällen, in denen der Leistungserbringer keine Berechtigung zur Einsicht des dgMP in der ePA hat oder der Patient dem dgMP nicht zustimmt, steht ihm nur der Ausdruck des BMP zur Verfügung. In solchen Fällen wäre es sinnvoll, wenn der Leistungserbringer den vorliegenden Plan in sein Primärystem übernehmen kann.
Wir halten die Annahme, dass es zeitnah viele rein digital nutzbare Medikationspläne geben wird, nicht für realistisch und sehen daher die Notwendigkeit einer Übergangslösung.

Generell möchten wir die Gelegenheit der Benehmensherstellung nutzen, um anzuregen, das MIO dgMP nochmal kritisch auf die Aspekte „einfache Bedienbarkeit“ und „nahtlose Integration in die bestehenden Primärsysteme“ zu prüfen. Dies beinhaltet auch das Zusammenspiel zw. Primärsystem und MIO. Eine Aktualisierung des Datenbestandes im einen System sollte z.B. zur Folge haben, dass eine Aktualisierung des Anderen schon automatisiert im Hintergrund erfolgt und eine Übernahme der Daten nur noch bestätigt werden muss.

Aufnahme von Meldungen von Nebenwirkungen:
Der Aktionsplan AMTS 2021 – 2024 des Bundesministeriums für Gesundheit sieht eine aufwandsarme systematische Erfassung von Nebenwirkungen vor. Wir regen an, diese im Rahmen der MIO AMTS-eZI zu implementieren.

Speicherung von der AMTS-rZI in der eML:
Gemäß des Dokuments gemKPT_FK_ePAfueralle_V1.1.0 CC_Aend, S.66 ist eine Dokumentation der AMTS-rzI auch in der eML und nicht nur im eMP möglich. Bitte diese Aktualisierung in den Prozessen und bei der Datenabfrage berücksichtigen.

Liebe MIO 42, wir bedanken uns für die umfangreiche und engagierte Spezifikationsarbeit.

Leider wurden nicht alle Kommentare der Bundesärztekammer berücksichtigt (z.B. objektivierbare Beschreibung einer allergischen Reaktion) bzw. eingepflegt (eingereichter Vorschlag zu einer versorgungsadäquaten Reihenfolge ärztlicher Tätigkeiten in den Fallbeispielen).
Grundsätzlich ist anzumerken, dass die Medizinischen Informationsobjekte vor ihrem Einsatz ausreichend getestet werden sollten, da ein einheitliches Verständnis zu den einzelnen Informationen nicht per se vorausgesetzt werden kann und das Restrisiko einer Patientengefährdung durch missverständliche Kommunikation umso höher ist, je weniger die Informationsobjekte vorab getestet (Praktikabilität der Eingabe, gemeinsames Verständnis der Inhalte) wurden.

Liebe Kolleg:innen der mio42,
vielen Dank für die Erstellung der Festlegungen zu den MIOs "elektronischer Medikationsplan" und "AMTS relevante Zusatzinformationen".

Im Zuge der Benehmensherstellung sollten aus Sicht der gematik dringend folgende Arbeiten durchgeführt werden:
• Erstellung von eingeschränkten Profilen für die Use Case spezifische Absicherung der in die ePA geschriebenen Inhalte.
• Erstellung des Profils EPAPractitionerRole
• Prüfung aller -Ressourcen auf Korrektheit und Fehlerbehebung
• Prüfung der IG Inhalte auf Korrektheit und Fehlerbehebung

Diese Arbeiten sind bis zur Festlegung des MIO eMP und AMTS-rZI durch die KBV abzuschließen.

Wir bedanken uns für die Möglichkeit der Stellungnahme.