Nach Abschluss der Benehmensherstellung (vom 15.07.2024 bis zum 26.07.2024) und der Prüfung sowie Bewertung aller eingegangenen Stellungnahmen ist im Folgenden ein Überblick zu den eingegangenen Stellungnahmen und den Bewertungsergebnissen einsehbar. Die Antworten wurden im September 2024 an die Organisationen versendet. Entwicklungen der ePA-Spezifikation oder Veränderungen anderer Rahmenbedingungen nach September 2024 sind in den Antworten oder Stellungnahmen nicht berücksichtigt.
| Organisation | Stellungnahme | Beantwortung durch mio42 |
|---|---|---|
| Bundesinstitut für Arzneimittel und Medizinprodukte | ||
Wir bedanken uns für die Gelegenheit zur Stellungnahme und möchten folgende Rückmeldungen zum MIO Medikationsplan Version 1.0.0 geben: 1) Genauere Beschreibung des Usecases „Verwaltung aller Medikationsdaten“: Allgemein: Betrifft https://simplifier.net/guide/medication-service?version=current Kommentar: Aus dem Scope „Verwaltung aller Medikationsdaten“ unter https://simplifier.net/guide/medication-service?version=current 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. | 1) Genauere Beschreibung des Usecases „Verwaltung aller Medikationsdaten“: Allgemein: Betrifft https://simplifier.net/guide/medication-service?version=current Um den Scope der Spezifikation zu verdeutlichen wurde der Einleitungstext der Spezifikation überarbeitet und konkretisiert. Die Spezifikation ermöglicht auch die Abbildung von Rezepturarzneimitteln, dazu zählen aus unserer Sicht auch patient:innen-individuell hergestellte Arzneimittel wie Zytostatika. Auch eine wirkstoffbasierte Dokumentation ist möglich. Das Profil "Pharmaceutical Product" im Kontext MedicationService ist nicht zu aktuell noch etwas enger gefasst als das Konzept "Pharmaceutical Product" aus der Referenzdatenbank. Das Profil ist auf die Abbildung von Komponenten einer Kombinationspackung auslegt. Eine weitere Anpassung an die Referenzdatenbank wird für die Fortschreibung diskutiert. Eine entsprechende Referenzierung ist im Informationsmodell vorhanden. Das FHIR Profil für Pharmaceutical Product des Medication Service wurde in das Informationsmodell mit aufgenommen. An der entsprechenden Stelle ist der Verweis auf die Referenzdatenbank hinterlegt. | |
2) Strukturierte Kennzeichnung von Kombinationspackungen Betrifft: Valueset Medication Type https://simplifier.net/epa-medication/epa-medication-type-vs bzw. https://simplifier.net/epa-medication/epa-medication-type-pharmaceutical-product-vs Kommentar: Das Valueset Medication Type https://simplifier.net/epa-medication/epa-medication-type-vs bzw. https://simplifier.net/epa-medication/epa-medication-type-pharmaceutical-product-vs kennzeichnet Fertigarzneimittel und Rezepturarzneimittel und auch, ob es sich beim Fertigarzneimittel um eine Kombinationspackung aus mehreren Darreichungsformen handelt [781405001 Medicinal product package (product); 1208954007 Extemporaneous preparation (product); 373873005 Pharmaceutical / biologic product (product)] 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 https://confluence.ihtsdotools.org/display/IAP/Reference+Documentation+-+Medicinal+Product+Model?preview=/31987859/115874595/SNOMED%20CT%20Medicinal%20Product%20Model%20Specification%20v3.pdf. | 2) Strukturierte Kennzeichnung von Kombinationspackungen Betrifft: Valueset Medication Type https://simplifier.net/epa-medication/epa-medication-type-vs bzw. https://simplifier.net/epa-medication/epa-medication-type-pharmaceutical-product-vs Aktuell gibt es nicht für alle Konzepte bei "Medication type" einen passenderen Code. Um einen proprietären Code zu vermeiden haben wir uns dazu entschieden, einen allgemeiner gefassten Code zu verwenden. Als Übergangslösung werden wir einen Hinweis zur Verwendung der Codes ergänzen und mittelfristig einen neuen, passenden SNOMED CT-Code beantragen. | |
3) Anwendung der Referenzdaten gemäß § 31b SGB V nicht nur für Inhalte der Kombinationspackungen Betrifft: Profil https://simplifier.net/epa-medication/epamedicationpharmaceuticalproduct Kommentar: Gemäß Constraint „epa-med-2“ sind Inhalte von Kombinationspackungen – und nur diese - durch das Profil https://simplifier.net/epa-medication/epamedicationpharmaceuticalproduct 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.
| 3) Anwendung der Referenzdaten gemäß § 31b SGB V nicht nur für Inhalte der Kombinationspackungen Betrifft: Profil https://simplifier.net/epa-medication/epamedicationpharmaceuticalproduct Das Profil "EPA Pharmaceutical Product Medication" ist für den Fall gedacht, dass einzelne Arzneimittel, die Teil einer Kombinationspackung sind, abgebildet werden müssen. Das separate Profil wurde aufgenommen, um bei den unterschiedlichen enthaltenen Arzneimitteln jeweils eine seperate Dosierung angeben zu können und dennoch gleichzeitig eine Zuordnung zu dem übergeordnetem Produkt zu ermöglichen. Andere Arzneimittel, die lediglich ein Medikament enthalten, können weiterhin über das "EPA Medication" - Profil abgebildet werden. Unabhängig davon können hierfür die Referenzdaten gemäß § 31b SGB V verwendet werden.
| |
4) Anpassung des Modells für das Pharmazeutische Produkt (für Kombinationpackungen) an die aktuelle Ausbaustufe der Referenzdatenbank § 31b SGB V Betrifft: Profil https://simplifier.net/epa-medication/epamedicationpharmaceuticalproduct Kommentar:
| 4) Anpassung des Modells für das Pharmazeutische Produkt (für Kombinationpackungen) an die aktuelle Ausbaustufe der Referenzdatenbank § 31b SGB V Betrifft: Profil https://simplifier.net/epa-medication/epamedicationpharmaceuticalproduct und Referenz zu EDQM-Standardterms für Darreichungsformen Betrifft: Profil https://simplifier.net/epa-medication/epamedicationpharmaceuticalproduct und Element Medication.form.coding:edqm mit preferred Binding zu http://hl7.org/fhir/uv/ips/ValueSet/medicine-doseform Die Referenzdatenbank für Fertigarzneimittel gemäß § 31b SGB V ist eine sinnvolle und begrüßenswerte valide Datenquelle, um langfristig die einheitliche Dokumentation von Medikationen zu fördern und einen unkomplizierten Austausch zwischen den Systemen zu gewährleisten. Da noch nicht alle Details zur Umsetzung der Datenbank abschließend geklärt sind, halten wir eine enge Anpassung der Spezifikation aktuell nicht für zielführend. Zumal andere Anforderungen zur Abbildung weiterer Prozesse (z.B. eRezept) weiterhin bestehen bleiben. Für die Folgeversionen werden wir die Referenzdatenbank und die Abbildung der Daten in unserer Spezifikation gemeinsam mit der gematik noch näher beleuchten und ggf. Anpassungen vornehmen. Dazu zählen beispielsweise auch die Einbindung passender ValueSets und Codesysteme, sobald diese vom BfArM zur Verfügung gestellt werden. Bestimmte Anpassungen können jedoch aus Gründen der Interoperabilität nicht erfolgen. Dazu gehört z.B. die Abbildung der Wirkstärke als Textfeld statt in strukturierter Form wie in unserer Spezifikation definiert. Die verpflichtende Angabe des Product-Keys im o.g. Profil ist dafür bereits jetzt möglich. FHIR-Beispiele werden im Nachgang zur Spezifikation veröffentlicht. Perspektivisch werden auch Beispiele mit Daten der Referenzdatenbank zur Verfügung gestellt.
| |
5) Redundante Datenfelder für Stoffbezeichnungen Betrifft: Profil https://simplifier.net/epa-medication/epamedication 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. | 5) Redundante Datenfelder für Stoffbezeichnungen Betrifft: Profil https://simplifier.net/epa-medication/epamedication Das Profil "Medication" ermöglicht unterschiedliche Ebenen, auf denen ein Arzneimittel abgebildet werden kann, daher erlauben wir dieselben Codesysteme an mehreren Stellen. Die Wirkstoff-basierte Dokumentation ist ein Beispiel davon, aber auch die Abbildung von Arzneimitteln mit mehreren Inhaltstoffen kann so erfolgen. Des weiteren erfolgte die Aufnahme bestimmter Codesysteme auch aus Gründen der Kompatibilität zu anderen Spezifikationen (z.B. ISiK).
| |
6) Versionierung von Kodiersystemen und Wertelisten Betrifft: Alle verwendeten CodeSystems und ValueSets (s. https://mio.kbv.de/pages/viewpage.action?pageId=251297970) Kommentar:
| 6) Versionierung von Kodiersystemen und Wertelisten Betrifft: Alle verwendeten CodeSystems und ValueSets (s. Verwendete Code-Systeme, Phase I) Die von Ihnen zitierte Seite "Verwendete Codesysteme" bezieht sich auf die Kommentierungsversion des MIO Medikationsplan und nicht auf die zuletzt veröffentliche und umfangreich überarbeitete Benehmensversion. In der Spezifikation wird die Version eines Codesystems entweder im dazugehörigen ValueSet festgelegt oder über die Version des verwendeten Packages.c Das Thema Versionierung wird weiterhin von uns diskutiert und bearbeitet. Die Vorgabe einer bestimmten Version wird aus unserer Sicht allerdings auch zukünftig bestehen.
| |
7) 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. https://mio.kbv.de/pages/viewpage.action?pageId=251297970) 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.
| 7) 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. Verwendete Code-Systeme, Phase I) Da die genaue Vorgehensweise zur Einführung der neuen Canonical-URLs noch nicht abschließend geklärt ist, werden wir die URLs zunächst nicht ändern.
| |
8) Nutzung des Kodiersystem Alphaid Betrifft: Profil https://simplifier.net/epa-medication/epamedicationstatement 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.
| 8) Nutzung des Kodiersystem Alphaid Betrifft: Profil https://simplifier.net/epa-medication/epamedicationstatement Das Thema wurde auch von uns diskutiert. In Absprache mit dem BfArM und der gematik haben wir uns dazu entschieden, die Alpha-ID zu entfernen.
| |
9) Handlungsempfehlungen für die Verwendung von Kodiersystemen Betrifft: Alle im MIO verwendeten CodeSystems und ValueSets (s. https://mio.kbv.de/pages/viewpage.action?pageId=251297970) 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.
| 9) Handlungsempfehlungen für die Verwendung von Kodiersystemen Betrifft: Alle im MIO verwendeten CodeSystems und ValueSets (s. Verwendete Code-Systeme, Phase I) Handlungsempfehlungen und Priorisierungen sowie Kurzbeschreibungen zu bestimmten Codesystemen zur erstellen kann für die Implementierung sicherlich sinnvoll sein. Dies ist aber aktuell nur schwer oder nur in intensiver Abstimmung möglich. Eine eindeutige Priorisierung eines bestimmten Codesystems bzw. einer Terminologie ist nicht pauschal möglich. Manche Codesysteme eignen sich zwar inhaltlich besser zur Abbildung bestimmter Informationen, sind aber z.B. aufgrund mangelnder Verbreitung in der Versorgung zum gegenwärtigen Zeitpunkt schwer umsetzbar. Andere wiederum sind weit verbreitet und daher gut einsetzbar, aber aus medizinisch-fachlicher Perspektive nicht ganz passend oder nicht international nutzbar. Eine Entscheidung, welches Codesystem wann anzuwenden ist, ist also immer vom Use-Case und den zur Verfügung stehenden Codesystemen abhängig.
| |
10) Referenz zu EDQM-Standardterms für Darreichungsformen Betrifft: Profil https://simplifier.net/epa-medication/epamedicationpharmaceuticalproduct und Element Medication.form.coding:edqm mit preferred Binding zu http://hl7.org/fhir/uv/ips/ValueSet/medicine-doseform 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.
| siehe Antwort 4 | |
11) Harmonisierung mit EU Austauschformaten - Darstellung Allergien sollte harmonisiert mit EU PatientSummary Allergies sein Betrifft: EPA Allergy Intolerance Profile https://simplifier.net/packages/de.gematik.epa/1.1.0-rc1/files/2464957 und EPAAllergyReactionSnomedCTVS https://simplifier.net/packages/de.gematik.epa/1.1.0-rc1/files/2464973 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.
| 11) Harmonisierung mit EU Austauschformaten - Darstellung Allergien sollte harmonisiert mit EU PatientSummary Allergies sein Betrifft: EPA Allergy Intolerance Profile https://simplifier.net/packages/de.gematik.epa/1.1.0-rc1/files/2464957 und EPAAllergyReactionSnomedCTVS https://simplifier.net/packages/de.gematik.epa/1.1.0-rc1/files/2464973 Die Berücksichtigung der Abbildung von Allergien in der EU PatientSummary ist aktuell nur bedingt möglich. Bestimmte Datenfelder dürfen nur mit von HL7 FHIR vorgegeben Werten befüllt werden und können daher nicht ohne weiteres auf ValueSets der PatientSummary abgeändert werden. Bei der Abbildung der Substanz, die eine Allergie auslöst, werden aktuell SNOMED CT-Codes aus dem MVC in der EU PatientSummary verwendet. Das ValueSet in unserer Spezifikation wird für die Folgeversionen bereits überarbeitet, wird aber zum einen voraussichtlich umfangreicher werden und zum anderen unter Verwendung der SNOMED CT Germany Edition definiert werden. | |
12) Nicht benötigte / referenzierte Ressourcen sollten entfernt werden Betrifft: Valueset https://simplifier.net/epa-medication/epa-medication-reason-snomed-ct-vs Kommentar: Das ValueSet wird innerhalb der Spezifikation (wahrscheinlich) nicht referenziert. Nicht benötigte/verwendete Ressourcen sollten entfernt werden.
| 12) Nicht benötigte / referenzierte Ressourcen sollten entfernt werden Betrifft: Valueset https://simplifier.net/epa-medication/epa-medication-reason-snomed-ct-vs Nicht verwendete Ressourcen, die noch versehentlich in der Spezifikation vorhanden waren, wurden entfernt.
| |
13) 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: http://snomed.info/sct/11000274103, siehe https://www.hl7.org/fhir/R4/snomedct.html 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: https://simplifier.net/packages/kbv.mio.emp/1.0.0-kommentierung.1/files/2383000) führt dazu, dass nicht ohne Probleme die internationale Version durch die National Edition ersetzt werden kann.
| 13) Einbeziehung der National Edition von SNOMED CT Betrifft: Alle codings, die SNOMED CT nutzen Die SNOMED CT Germany Edition wird in unserer Spezifikation verwendet.
| |
| Gematik GmbH | ||
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:
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.
| Die genannten Punkte wurden bei der Überarbeitung der Inhalte berücksichtigt. | |
| Bundesverband Gesundheits-IT – bvitg e. V. | ||
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. | Da wir die Spezifikation zum MIO eMP und AMTS-rZI gemeinsam mit der Spezifikation der gematik für die ePA3.1 erstellt und veröffentlicht haben, war es zwingend notwendig, dass die beiden Beteiligungsverfahren synchron ablaufen. Wir waren daher an den Fristen und zeitlichen Vorgaben der gematik gebunden. Das dies eine Herausforderung für die Gesellschafter der gematik bzw. die benehmensrelevanten Organisationen der mio42 ist, ist uns bewusst. Wir sehen die Erarbeitung eines Roll-Out-Konzepts für den dgMP in der ePA 3.1 als zwingend notwendig an. Dies ist übergreifend im Rahmen des Roll-Out der ePA 3.1 zu erarbeiten. Auch wir danken für die konstruktive Zusammenarbeit mit dem bvitg während der Entwicklungsphase des MIO eMP und AMTS-rZI.
| |
| Bundesärztekammer | ||
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. | Im Rahmen der Fallbeispiele ist es uns leider nicht möglich alle Realitäten abzubilden. Es besteht daher kein Anspruch auf Allgemeingültigkeit. Die von uns gewählten Fallbeispiele berücksichtigen u.a. Ergebnisse aus dem Arbeitskreis Medikationsprozesse des Interop Councils sowie aus der Beiratsarbeit zum MIO eMP und AMTS-rZI. Aufgrund Ihres Kommentars aus der Kommentierung haben wir die Reihenfolge im Fallbeispiel Notfallversorgung einer gestürtzten Patientin (Fallbeispiel 3) angepasst. Wir bemühen uns weitere Fallbeispiele zu erarbeiten. Zur objektiven Beschreibung des Schweregrads einer Allergischen Reaktion liegt derzeit leider keine auf alle Allergischen Reaktionen anwendbare Leitlinie vor. Wir befürworten ebenfalls eine zeitlich und im Umfang ausreichende Testung und Pilotierung des MIO eMP und AMTS-rZI sowie des dgMP allgemein. Leider ist dies vom BMG aktuell nicht in ausreichendem Maße vorgesehen. Wir setzen uns weiterhin für die Testung und Pilotierung der MIOs vor der flächendeckenden Einführung ein. | |
| GKV-Spitzenverband | ||
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. | Wir können den Bedarf nach einer aufwandsarmen und systematischen Erfassung von Nebenwirkungen nachvollziehen. Eine inhaltliche und prozessuale Einbindung in den dgMP kann für Folgestufen diskutiert werden. Die Angaben zur Anzeige von AMTS-rZI in der eML wurden angepasst.
| |
| HÄVG | ||
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. 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. 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. | Grundsätzlich sehen wir die Erarbeitung eines Roll-Out-Konzepts für den dgMP in der ePA 3.1 als zwingend notwendig an. Die Migration von Daten aus bisherigen Medikationsplan-Formaten sowie der Umgang mit einem QR-Code sollte dabei betrachtet werden. Die Argumentation der mio42 bleibt diesbezüglich bestehen. Ein konkretes Konzept ist jedoch übergreifend im Rahmen des Roll-Out der ePA 3.1 zu erarbeiten. Unseres Wissens wird es keine Änderungen an den Prozessen und der Handhabung für den BMP geben. Dieser steht für den Roll-Out des dgMP und für alle Versicherte, die dem dgMP widersprechen weiterhin zur Verfügung. Nähere Informationen hierzu sind bitte mit der AG BMP zu klären. | |
| Deutscher Apothekerverband e.V. (ABDA) | ||
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. | 1) Bei der Auswahl von Codesystemen folgen wir zum gegenwärtigen Zeitpunkt gültigen Empfehlungen und Vorgaben,. auf die wir als Organisation nur bedingt Einfluss haben. Die Einführung und Etablierung international gültiger Codesysteme muss an übergeordneter Stelle diskutiert und durchgeführt werden. Da sich bereits auf dem Markt befindliche Primärsysteme mit der Integration der genannten Codesysteme beschäftigen, gehen wir davon aus, dass eine Umsetzung, wenn auch sicherlich mit nicht zu unterschätzendem Aufwand, grundsätzlich möglich ist. Ob Primärsysteme die Codes für ihre jeweiligen Anwendungen (z.B. AMTS-Prüfung) weiternutzen können oder nicht liegt nicht im Verantwortungsbereich der Spezifikation. | |
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. | 2) Die Problematik, dass Daten inhaltlich nicht zu einander passen, oder schlicht falsch sind, wird immer bestehen, ein Code kann nicht zu dem dazugehörigen Freitext passen oder aber auch ein Verabreichungsweg nicht zum Arzneimitte. Das Eintragen korrekter Informationen und eventuell folgende Prüfung, Anpassung, oder Entfernung anderer Elemente liegen daher weiterhin bei der bearbeitenden Person, oder müssen vom schreibenden System gewährleistet werden. In bestimmten Fällen kann eine doppelte Codierung aber sinnhaft sein, da verschiedene Codesysteme die Information auf unterschiedlichen Granularitätsleveln abbilden können. Sollten zukünftig passende Mappings vorliegen, können die Informationen technisch geprüft werden. | |
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. | 3) Die Komplexität des MIOs wurde schon möglichst gering gehalten. Gleichzeitig war es aber auch wichtig, dass wir uns nicht in der ersten Version alles verbauen wie beispielsweise die komplexen Dosierungen. | |
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. | 4) Wir haben die Festlegung einer patientenindividuellen Reihenfolge intensiv mit der gematik diskutiert. Diese lehnt generell eine direkte Bearbeitbarkeit der internen Management Ressourcen (Lists und Composition) des ePA MedicationService ab. Zudem führt eine im ePA MedicationService festgelegte Reihenfolge zu zusätzlichen Problemen, die die Akzeptanz bei Leistungserbringenden reduzieren können. Wenn es eine zentrale Reihenfolge gibt, kann diese einfach überschrieben werden von einer anderen leistungserbringenden Person. Als Leistungserbringer:in muss ich mich bei der nächsten Bearbeitung erneut damit beschäftigen. Es ist uns leider nicht möglich ein zentrales Regelwerk für die Abgrenzung zwischen "Bearbeitung einer Zeile" vs. "neue Zeile anlegen" anzubieten. Dies ist ein hochkomplexes Thema. Dies war auch das Ergebnis der Diskussion mit der AG BMP da die gleiche Problematik auch für den BMP gilt. | |
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. | 5. Diese Thematik wurde, unter anderem, auch mit der AG BMP besprochen. Wir haben uns dafür entschieden, erstmal die Zwischenüberschriften aus dem BMP zu übernehmen da diese einen Großteil des Bedarfs abdeckt. Wir stimmen Ihnen zu, dass weitere Zwischenüberschriften sinnvoll sein können, würden diese aber lieber, falls möglich, kodiert abbilden. Hierfür bedarf es einer Analyse der Nutzung und gegebenenfalls eines Workshops zu dem Thema. Aufgrund des Zeitdrucks sehen wir dies als Thema für eine Fortschreibung. | |
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. | 6) Da wir die Spezifikation zum MIO eMP und AMTS-rZI gemeinsam mit der Spezifikation der gematik für die ePA3.1 erstellt und veröffentlicht haben, war es zwingend notwendig, dass die beiden Beteiligungsverfahren synchron ablaufen. Wir waren daher an den Fristen und zeitlichen Vorgaben der gematik gebunden. Das dies eine Herausforderung für die Gesellschafter der gematik bzw. die benehmensrelevanten Organisationen der mio42 ist, ist uns bewusst. | |
7) Darüber hinaus haben wir folgende Anmerkungen (nicht abschließend): a) 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 [aber nicht nur Ibuprofen]) 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). b) 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. c) 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 d) Profil EPAObservationBodyWeight Elemente Observation.value[x] und Observation.value[x]:valueQuantity besitzen das Binding package/ValueSet-VitalSignDE-Body-Weigth-UCUM.json (required) während das Element Observation.value[x]: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. | 7) a) Mittelfristig soll der Fokus bei der Abbildung von Arzneimittel im Rahmen eines Medikationsprozesses ohnehin nicht mehr ausschließlich auf der PZN liegen, da die Abbildung auf Packungsebene nicht immer die optimale Variante darstellt (siehe auch Positionspapier "Analyse der Medikationsprozesse" des InteropCouncil). Die Einbindung der PZN ist v.a. der weiten Verbreitung geschuldet. Darüber hinaus ist bereits jetzt bei einer Wirkstoff-Verordnung die Angabe einer PZN nicht sinnvoll. Für die AMTS-Prüfung von Hilfsstoffen ist der Produkt-Bezug hier natürlich relevant, steht aber nicht für alle Allergien (v.a. die nicht-medikamentösen) im Vordergrund. b) Wie die Ausgestaltung eines ValueSets aussehen könnte steht zur Zeit noch zur Diskussion. Prinzipiell sollte diese Aufgabe eine sog. ValueSet Authority übernehmen, also eine übergeordnete, zentrale, für die Erstellung und Pflege terminologischer Inhalte zuständige Stelle, die dann mit den nötigen Kapazitäten ausgestattet ist. c) Das ValueSet-Binding "extensible" schränkt zumindest das zu verwendende Codesystem ein. Ist kein passender Code vorhanden wird die Information zumindest in codierter Form und nicht als kaum interpretierbarer Freitext übermittelt. d) Es können nur Codes eingetragen werden, die in beiden ValueSets vorkommen; in diesem Fall die Einheiten für Körpergewicht. | |
| Verband der Privaten Krankenversicherung | ||
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. | Ihre Anmerkungen wurden aufgenommen. Die entsprechenden Textpassagen wurden angepasst. | |
| SITIG | ||
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: 1) 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. | 1) Aktuell existiert ein Glossar zu den verwendeten Begriffen im Kontext Versorgungsprozesse: Glossar & Abkürzungsverzeichnis. An einem übergreifenden Glossar arbeiten wir in Abstimmung mit der gematik. | |
2) 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 ungeprüfte Datenübernahmen erwogen werden. | 2) Es werden keine automatischen beziehungsweise ungeprüfte Datenübernahmen aus dem Verordnungs- und Dispensierdatensatz erwogen. Die Daten aus dem Verordnungs- und Dispensierdatensatz können als Vorlage genutzt werden aber bedürfen immer einer manuellen Prüfung und Anpassung bei einer Weiternutzung für den eMP. In der Regel sollten Einträge jedoch von den Systemen gleichzeitig für beide Anwendungsfälle eingestellt werden. | |
3) Ergänzung/Prüfung einer Dokumentationsmöglichkeit der Freisetzungsart (Retardierung Ja/Nein) (gem. https://www.aps-ev.de/hempfehlungen/verordnungspraxis/) Prüfung der verwendeten FHIR Ressource (Medication.form?) ob diese eine Differenzierung von retardiert und unretardierter Form zulässt. | 3) Die bereitgestellten ValueSets für Medication.form enthalten diese Angaben schon. z.B. "Retard-Tabletten" und "Retard-Kapseln" aus der KBV Schlüsseltabelle "KBV_CS_SFHIR_KBV_DARREICHUNGSFORM" | |
4) Vermeidung zusätzlicher automatischer und insbes. manuellen Dokumentationsmöglichkeiten in der eML außer der Verordnungs- und Dispensierdaten. | 4) Wir haben das Thema weitergegeben an die gematik. | |
5) 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 zentral abgelegten BMP/eMP nicht verändern dürfen. | 5) Für die Ausarbeitung einer Standardansicht für die Anzeige bzw. den Druck ist unserer Ansicht nach die AG BMP verantwortlich. | |
6) 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) | 6) Bei unserer Spezifikation orientieren wir uns auch an den Vorgaben und Richtlinien der EU oder dem IDMP-Standard. Dazu zählen beispielsweise Anforderungen an die Codierung der Darreichungsform und des Verabreichungsweges mittels EDQM Standard Terms oder von Einheiten mit UCUM Codes. Eine Angleichung bzw. Anpassung an die vom IDMP geforderten IDs kann erst erfolgen, sobald abschließend geklärt ist, wie diese auf nationaler Ebene umgesetzt und zur Verfügung gestellt werden. In den bisher festgelegten MIOs haben wir für alle Codesysteme die zu verwendende Version mit angegeben. Um zukünftig eine zeitgerechte und unkompliziertere Aktualisierung verwendeter Codesysteme zu gewährleisten, wird dieses, bisher etablierte Vorgehen, aktuell MIO-übergreifend diskutiert und eventuell angepasst. Dabei berücksichtigen wir auch die sich daraus ergebenden Konsequenzen für die Primärsystem-Hersteller. | |
7) 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. https://www.aps-ev.de/hempfehlungen/verordnungspraxis/). Möglicherweise sind dazu Ergänzungen der verfügbaren FHIR Ressourcen nötig. | 7) Das Thema ist komplex und muss in einer zukünftigen Ausbaustufe analysiert und berücksichtigt werden. | |
8) Einbindung von Therapiegrund und Therapieziel in die AMTSrTI (gem. https://www.aps-ev.de/hempfehlungen/verordnungspraxis/) 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) | 8) MedicationStatement.reasonCode ist schon enthalten in der Spec und soll auch immer befüllt werden. Therapieziele sind komplex und müssen in einer zukünftigen Ausbaustufe analysiert und berücksichtigt werden. | |
9) Bitte die Spec. auseinander halten. Liste, Plan, AMTS etc sind in sich geschlossene Specs, die mit anderen Specs (zB Labor) zusammengeführt werden sollen. | 9) Die Spezifikation erfolgt gesamthaft für den dgMP der als ePA MedicationService abgebildet wird. | |
10) Der bestehende Medikationsplan (BMP) mit Barcode muss erhalten bleiben. Es muss eine Übergangslösung / Rückfalloption (z.B. bei Stromausfall) geben. | 10) Der aktuelle BMP bleibt vorerst erhalten da auch PatientInnen die der ePA widersprechen, weiterhin einen Anspruch auf einen Medikationsplan haben. | |
11) Alle FHIR Spezifikationen müssen über HL7 Germany abgestimmt werden. AG AIS und AG SIE und SITIG Spitzenverband | 11) Wir befinden uns derzeit im Austausch mit HL7 Germany zur Ausgestaltung unserer Kommentierungsverfahren. Dies ist übergreifend für alle MIOs zu klären. | |
bpa.Bundesverband privater Anbieter sozialer Dienste e.V. | ||
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:
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. | Die Verarbeitungsrechte für Daten der ePA für die Pflege ergeben sich aus §352 SGB V: Medikationsdaten dürfen lediglich gelesen werden. Die Spezifikation des MIO und die gematik Spezifikation der ePA berücksichtigt diese Vorgaben. Grundsätzlich ist es sinnvoll für Folgeversionen über die Rechte der Pflege zu diskutieren. Dazu ist eine übergeordnete Diskussion, sowohl auf regulatorischer als auch auf prozessualer Ebene, notwendig. Sowohl das Absetzen eines Medikament als auch die Dosisänderung für ein Medikament haben wir prozessual in den Medikationsbezogenen Grundprozessen https://mio.kbv.de/display/EMP1X0X0/Medikationsbezogene+Grundprozesse beschrieben. Es handelt sich dabei um eine Medikationsentscheidung und Verordnung bzw. um eine Aktualisierung dieser. Die Umsetzung dieser Punkte ist technisch und prozessual angelegt. Es obliegt natürlich den Leistungserbringern, diese Prozesse auch einzuhalten. Eine mögliche UX/UI Umsetzung zur guten Kenntlichmachung von abgesetzten Medikamenten und / oder Dosisänderungen wurde gemeinsam mit der gematik technisch und graphisch durchdacht sowie entsprechend im Implementation Guide bzw. Prozessleitfaden und den UX Beispielen beschrieben und graphisch dargestellt. Die Umsetzung obliegt jedoch den Primärsystemherstellern. Wir möchten eindringlich darauf hinweisen, dass wir im Rahmen der Erarbeitung der Spezifikation des MIO eMP und AMTS-rZI diverse Anwendergruppen, insbesondere auch die Pflege (stationär und ambulant) einbezogen haben. Der Bundesverband privater Anbieter sozialer Dienste sowie die Bundesarbeitsgemeinschaft der Freien Wohlfahrtspflege sind in unserem Beirat aktiv. Der Beirat begleitet unsere Entwicklungsarbeit von Beginn an. Sowohl für die Durchführung der Kommentierung als auch die Besprechung der Ergebnisse dieser war der bpa involviert und informiert. Eine Vertreterin des bpa hat an diesen Besprechungen teilgenommen. Ihre Aussage, dass der bpa nicht in der Kommentierung involviert war, können wir daher nicht nachvollziehen. Weiterhin haben wir im Rahmen der Prozess- und Bedarfsanalyse Interviews mit Pflegekräften geführt. Vertreter:innen der Pflege haben an Workshops teilgenommen. Wir haben uns intensiv mit Expert:innen für Pflegeverwaltungssysteme ausgetauscht. Weiterhin haben alle Interessierten im Rahmen des Beteiligungsverfahrens, vor allem der Kommentierung, stets die Möglichkeit unsere Arbeitsergebnisse einzusehen und ihr Rückmeldung an uns heranzutragen. Neben den Bereits erwähnten Möglichkeiten zur Partizipation bietet die mio42 einen Newsletter an, der regelmäßig über unsere Aktivitäten informiert und ebenfalls auf Kommentierungsmöglichkeiten hinweist. Wie all diese Möglichkeiten genutzt werden, obliegt natürlich den Fachorganisationen, Verbänden und einzelnen Personen selbst. Da wir die Spezifikation zum MIO eMP und AMTS-rZI gemeinsam mit der Spezifikation der gematik für die ePA3.1 erstellt und veröffentlicht haben, war es zwingend notwendig, dass die beiden Beteiligungsverfahren synchron ablaufen. Wir waren daher an den Fristen und zeitlichen Vorgaben der gematik gebunden. Das dies eine Herausforderung für die Gesellschafter der gematik bzw. die Benehmensrelevanten Organisationen der mio42 ist, ist uns bewusst. Wir befürworten ebenfalls eine zeitlich und im Umfang ausreichende Testung und Pilotierung des MIO eMP und AMTS-rZI sowie des dgMP allgemein. Leider ist dies vom BMG aktuell nicht in ausreichendem Maße vorgesehen. Wir setzen uns weiterhin für die Testung und Pilotierung der MIOs vor der flächendeckenden Einführung ein. | |
