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.
| Organisation | Stellungnahme | Beantwortung |
|---|---|---|
| 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. | 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. | ||
