Kommentierungsergebnisse

Zusammenspiel zwischen eMP und eML:

Es erreichten uns konkrete Rückfragen zum Gesamtkonzept des dgMP. Vor allem ob 

• Änderungen an der Medikation im eMP in die eML übernommen werden
• der eMP bei Vorhandensein das führende Dokument ist
• die Datenübernahme aus der eML bei der eMP-Erstellung und Pflege möglich ist
• Informationsdeltas angezeigt werden
  • Anzeige der Unterschiede zwischen der letzten durch einen Leistungserbringer gesichteten und der in der ePA verfügbaren aktuellsten Version (für eML und eMP)
  • Anzeige der Medikation die in der eML, aber nicht im eMP ist

Zum Zusammenspiel zwischen eML und eMP wollen wir folgende Punkte nochmals zusammenfassend darstellen:

ab ePA 3.0

• eML ist als Übersicht aller über den eRezept-Fachdienst verfügbaren Verordnungs- und Dispensierdaten (Muster 16) verfügbar
• es werden keine weiteren Informationen in der eML angezeigt
• eMP als MIO ist noch nicht Bestandteil der ePA

ab ePA 3.1

• eML und eMP haben eine gemeinsame Datenbasis im Medication Service
• eML enthält immer alle Medikation: alle Medikationsdaten, die im Medication Service gespeichert werden, werden in der eML angezeigt, unabhängig davon, ob sie einem Medikationsplan zugeordnet sind oder nicht. Die eML stellt somit immer die Gesamtheit aller Medikationsdaten dar.
• Standardmäßig werden immer die letzten 12 Monate der eML angezeigt. Dieser Zeitraum kann auf Wunsch der Anwender:innen verändert werden
• eMP enthält nur die planrelevante Medikation (die Anlage, Befüllung und Pflege des eMP ist eine bewusste Entscheidung und Leistung der Leistungserbringenden)
• Alle Veränderungen, die im eMP erfolgen, werden automatisch in die eML übertragen.
• Wird ein Medikament der eML hinzugefügt (z.B. OTC), muss bewusst entschieden werden, ob es planrelevant ist. Somit taucht nicht jede Medikation automatisch im Medikationsplan auf.
• Änderungen einer Medikation, die dem eMP zugeordnet ist, führen immer zu einer Aktualisierung des gesamten eMPs. Dabei ist es egal. ob die Anwender:innen diese Information aus der Ansicht der eML oder des eMP ändern.

Lösung / Vorgehen:

• Das oben beschriebene Zusammenspiel zwischen eML und eMP wird im Rahmen der technischen Spezifikation des ePA Medication Service umgesetzt
• Die mio42 empfiehlt zudem in UX-Visualisierungen und im Prozessleitfaden:
  • Wenn vorhanden, soll der eMP als führendes Dokument ersichtlich sein
  • Um die Komponenten des dgMP optimal zu nutzen, wird eine integrierte Ansicht von eML und eMP empfohlen, in der klar ersichtlich ist, welche Inhalte zum eMP gehören und welche nicht. 
  • Anzeige von Veränderungen/Abweichungen zwischen eML und eMP
  • Anzeige der Unterschiede zum letzten bekannten Stand von eML und eMP
  • Übernahme aus Daten von eML in eMP (Ergänzung ist notwendig!)
  • Rezepterstellung aus eMP und eML

→ Diese Funktionen können von der mio42 nur als Empfehlungen ausgesprochen werden. Zudem sind diese Funktionen nur möglich, wenn die eML nativ im Primärsystem implementiert wird. Die Umsetzung der eML als PDF oder XHTML ermöglicht diese Funktionalitäten nicht. Eine Umsetzung muss durch die Primärsysteme selbst geschehen und kann sich in den einzelnen Primärsystemen unterscheiden. Um die Implementierung zu unterstützen, geben wir Hinweise im Implementierungsleitfaden für Primärsystemhersteller und im FHIR-Implementation Guide als Teil des Simplifier-Projekts und bieten mit UX-Designs und Prozessleitfäden Vorschläge möglicher Umsetzungen.

Roll-Out des eMP und AMTS-rZI:

bzgl. der Einführungsphase des eMP und AMTS-rZI haben wir folgende Kommentare erhalten:

• Wunsch nach technischen Vorgaben und Tools zur Migration der Daten des eMP auf der eGK und BMP zum MIO eMP und AMTS-rZI
• Hinweis auf fehlenden Zugriff auf die ePA und den dgMP im Notfall durch Notärzt:innen und -sanitäter:innen und im mobilen Szenario allgemein
• gesetzliche Vorgabe der Löschung des eMP von eGK bei Vorhandensein des MIO eMP nach § 358 Ab. 8 SGB V

Lösung / Vorgehen Migration:

• Im Rahmen der MIO-Entwicklung werden wir keine konkreten Vorgaben für die Migration der Daten vom eMP (eGK) oder BMP in das MIO eMP und AMTS-rZI machen.
• Die Migration kann im jeweiligen Primärsystem erfolgen. Da die lokale Datenhaltung zu unterschiedlich ist, sehen wir es nicht als sinnvoll an, hierfür übergreifende Vorgaben zu machen.
• Eine 1:1-Übernahme der Daten aus dem BMP oder eMP auf der eGK in das MIO ist generell nicht möglich. Dies liegt daran, dass das MIO ein höheres Strukturierungsniveau und mehr verpflichtende Angaben als in den alten Formaten erfordert. Daher ist es in jedem Fall notwendig, die Daten des BMP oder eMP (eGK) für die Überführung in ein MIO nochmal anzupassen. Dies kann unterstützt durch das Primärsystem passieren. Die Implementierung liegt jedoch bei den Herstellern.
• Zur Erleichterung der initialen MIO-Erstellung kann zudem die eML genutzt werden, die mindestens 6 Monate vor dem Start des MIO eMP zur Verfügung steht.

Lösung / Vorgehen Notfallszenario/mobiler Zugriff:

• Der fehlende Zugriff auf die ePA im mobilen Szenario sowie der fehlende Zugriff für Rettungssanitäter:innen ist bekannt. Die gematik arbeitet am mobilen Szenario. In den ePA-Stufen 3.0 und 3.1 wird das mobile Szenario jedoch noch nicht verfügbar sein. 
• Wir passen unsere Darstellung in den Versorgungsprozessen und im Prozessleitfaden dahingehend an und ergänzen einen Verweis auf zukünftig denkbare Szenarien.
• Ja, es ist gesetzlich vorgesehen, dass bei Vorhandensein eines eMPs in der ePA der eMP auf der eGK gelöscht wird (§ 358 Ab. 8 SGB V). Dies ist grundsätzlich sinnvoll, um doppelte Datenhaltung und auseinanderlaufende Informationen in den Medikationsdaten zu vermeiden.
• Für die Übergangsphase kann es sinnvoll sein, den Notfalldatensatz (NFDS) zu nutzen. Dieser ist von der Löschung laut § 358 Ab. 8 SGB V nicht betroffen und enthält theoretisch auch Medikationsdaten. Äquivalent zu BMP und eMP (eGK) weisen wir auf die Herausforderung hin, den NFDS mit den Daten in der ePA synchron zu halten bzw. die Daten zu überführen. Dies ist über die Primärsysteme umzusetzen und kann durch diese technisch unterstützt werden.

Umgang mit dem BMP:

In der Kommentierung erreichten uns folgende Hinweise zum BMP:

• wird das MIO eMP als BMP ausgedruckt, so muss dieser Druck einheitlich sein
• Wunsch, dass der Barcode auf dem Druck des BMP auf Basis des MIO eMP beibehalten wird in der Roll-Out-Phase
• Wunsch, dass der Barcode auf dem Druck des BMP auf Basis des MIO eMP entfernt wird

Lösung / Vorgehen:

• Vorgaben für den Druck des BMP auf Basis des MIO eMP werden aktuell mit gematik und AG BMP erarbeitet
• Die Beibehaltung des Barcodes im BMP Druck auf Basis des MIO eMP halten wir für nicht sinnvoll
• Es besteht die Gefahr, dass der gedruckte BMP nicht die aktuellsten Daten enthält
• Ein Umweg der Datensynchronisation am aktuellen Datenstand der ePA vorbei soll nicht etabliert werden.
• Umgang mit BMP liegt grundsätzlich bei AG BMP und wird von dieser geklärt

Rolle der Pflege bei der Medikationsdokumentation:

bzgl. der Einbindung der Pflege im dgMP erreichten uns folgende Wünsche:

• Schreibrechte für die Pflege für
• Statusänderung einer Medikation
• Hinzufügen von Kommentaren / Einnahmehinweisen
• Aufnahme OTC und Selbstmedikation
• spezifischere Abbildung der Pflege in Prozessen und UX-Visualisierungen

Lösung / Vorgehen:

• Die Verarbeitungsrechte für Daten der ePA für die Pflege ergeben sich aus § 352 SGB V: Medikationsdaten dürfen lediglich gelesen werden
• OTC können nur von Verordnenden, Abgebenden und Versicherten ergänzt werden
• Die Spezifikation des MIO und die gematik-Spezifikation der ePA berücksichtigen 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

Harmonisierung mit ISiK:

Es erreichten uns Kommentare, die auf eine stärkere Harmonisierung mit anderen Standardisierungsprojekten, vor allem mit ISiK hinweisen:

• Eine Abstimmung der Profile des Medikationsplans und von ISiK Stufe 4 ist wünschenswert
• Harmonisierung mit ISiK erleichtert den Implementierungsaufwand für Primärsystemhersteller
• FHIR-Spezifikationen zum gleichen Thema sollten nicht zu stark voneinander abweichen

Lösung / Vorgehen:

• Es findet aktuell eine gegenseitige Abstimmung unserer Spezifikation mit der von ISiK Stufe 4 im Rahmen der jeweiligen Kommentierungsprozesse statt.
• Erklärtes Ziel ist es, eine möglichst hohe Kompatibilität zwischen den Spezifikationen herzustellen. Die Spezifikationen haben teilweise jedoch unterschiedliche Anwendungsfälle und Vorgaben, daher können Abweichungen der Spezifikationen erforderlich sein.
• Es müssen auch andere Spezifikationen als nur ISiK berücksichtigt werden, wie beispielsweise eRezept, ePA MedicationService, andere MIOs, MII.

Komplexität des Modells, v.a. Dosierung:

Bzgl. der Komplexität des Informationsmodells und der damit einhergehenden Implementierungsaufwände für Primärsystemhersteller erreichten uns folgende Hinweise:

• Die strukturierte Angabe der Dosierung in der Medikationsinformation ist für die erste Ausbaustufe zu komplex.
• Die Ausgestaltung mancher Profile scheint übermäßig komplex.
• Es fehlen Beispiele für komplexe Dosierungen um die Nutzung zu veranschaulichen.

Lösung / Vorgehen:

• Aus Sicht des Arbeitskreis „Analyse der Medikationsprozesse" des Interop Council ist die strukturierte Abbildung von Dosierungen zentral für interoperablen Austausch einer Medikationsinformation. Zum gleichen Ergebnis kamen wir auch im Rahmen unserer Bedarfsanalyse, die wir zu Beginn des MIO-Projekts mit Anwender:innen aller Sektoren sowie mit unserem Beirat durchgeführt haben.
• Komplexe Dosierungen sind auch in anderen Spezifikationen bereits vorhanden (z.B. ISiK und MII) und müssen von Herstellern künftig umgesetzt werden.
• Beispiele für komplexe Dosierungen sind aktuell in Arbeit und werden spätestens mit der Benehmensherstellung veröffentlicht.

Abstimmung mit gematik Spezifikation für ePA MedicationService:

Es erreichten uns Kommentare, die auf Abweichungen des Grobkonzepts der gematik für den ePA MedicationService und der MIO Spezifikation für den eMP und AMTS-rZI hingewiesen haben. Zudem wurde der Wunsch nach einem konsistenten fachlichen Konzept für den gesamten dgMP geäußert.

Lösung / Vorgehen:

• Im Rahmen der gemeinsamen Arbeit stimmen wir uns eng mit der gematik ab.
• Aktuell arbeiten wir gemeinsam an der Spezifikation des ePA Medication Service und bringen die individuellen Vorarbeiten zusammen. 
• Das fachliche Konzept des dgMP wird im ePA-Fachkonzept beschrieben.

Zwischenüberschriften:

• Die explizite Angabe von Zwischenüberschriften ist aktuell im MIO eMP nicht möglich.
• Die Unterscheidung in Beispielsweise "Dauermedikation" anhand der vorhandenen Zeitpunkte erscheint nicht sinnvoll und aufwändig.

Lösung / Vorgehen:

• Die medikationsrelevanten Zwischenüberschriften werden aus der BMP Spezifikation übernommen und über eine Extension in die Medikationsinformation eingebunden.
• Folgende Zwischenüberschriften sind geplant:
  • Bedarfsmedikation
  • Dauermedikation
  • Intramuskuläre Anwendung
  • Besondere Anwendung
  • Intravenöse Anwendung
  • Anwendung unter die Haut
  • Fertigspritze
  • Selbstmedikation
  • zu besonderen Zeiten anzuwendende Medikamente
  • zeitlich befristet anzuwendende Medikamente
• In ISiK Stufe 4 können ebenfalls Zwischenüberschriften angegeben werden. Es wird allerdings nur zwischen Dauer- und Akutmedikation unterschieden.

offene vs. geschlossene Spezifikation:

Die FHIR-Profile in der Kommentierungsversion wurden anders als in bisherigen KBV-Spezifikationen offen spezifiziert. Bisherige KBV-Spezifikationen schließen alle Datenfelder, die für den bestimmten Anwendungsfall nicht notwendig sind, explizit aus. Primärsystemhersteller wissen dadurch genau, mit welchen Informationen sie umgehen können müssen. In der Kommentierungsversion sind nicht benötigte Elemente nicht explizit ausgeschlossen. Stattdessen haben nicht benötigte Elemente kein MustSupport bekommen. Dies führt dazu, dass im MIO Elemente enthalten sind, die von einem schreibenden System zwar befüllt werden können, aber von lesenden Systemen nicht zwangsläufig ausgelesen werden können.

Dazu erreichten uns folgende Hinweise und Fragen:

• Warum sind Felder enthalten, die von Zielsystemen nicht umgesetzt werden sollen?
• Es führt zu fehlender Interoperabilität und dem Risiko von Fehlinterpretationen wenn beispielsweise lokale Codesysteme übertragen werden, die den Zielsystemen nicht bekannt sind und nicht interpretiert werden können.
• Durch eine gezielte Definition der Inhalte wird die Datenqualität in der ePA erhöht.
• Gibt es eine konkrete Auswahl an Feldern, die implementiert werden müssen, führt dies zu geringeren Implementierungsaufwänden. Bei Bedarf können diese Felder erweitert werden.
• Die Aufnahme der Nutzung neuer Felder sollte immer zu einer Anpassung der Spezifikation führen, damit alle implementierenden Systemen die gleiche Datenbasis verwenden.

Lösung / Vorgehen:

Wir halten die eingegangenen Einwände bzgl. der offenen Spezifikation für berechtigt und prüfen eine Schließung der Profile derzeit mit der gematik.

Gleichzeitige Angabe mehrerer Codes bzw. Code und Freitext möglich (beim FHIR-Datentyp "CodeableConcept"):

Die Abbildung bestimmter Informationen (z.B. Wirkstoff) kann über einen Freitext, einen Code (z.B. ASK-Nummer), mehrere Codes (z.B. ASK-Nummer und SNOMED CT-Code) oder einen Code und Freitext erfolgen. Dabei gibt es keine Einschränkung, dass z.B. ein weiterer Code angegeben werden darf, wenn bereits ein Code im MIO eMP erfasst wurde.

Im Rahmen der Kommentierung erreichten uns dazu folgende Hinweise:

• Durch die gleichzeitige Angabe mehrerer Codes und der gleichzeitigen Angabe von Code und Freitext sind  widersprüchliche Angaben möglich.
• Um dies zu verhindern ist eine manuelle Überprüfung notwendig. Der damit verbundene Aufwand ist im Versorgungsalltag nicht leistbar.

Hintergrund:

• Die technische Einschränkung auf einen Code oder nur Freitext ist nicht möglich, da das Risiko der Inkompatibilität mit anderen Spezifikationen besteht.
• An bestimmten Stellen ist die Angabe mehrerer Codes bzw. Codes und Freitext fachlich sinnvoll (z.B. zusätzliche Eingabe patient:innen-verständlicher Begriffe).
• Die Verantwortung zur Eingabe inhaltlich korrekter, zueinander passender Informationen liegt allgemein bei der bearbeitenden Person.

Lösung/ Vorgehen:

→ keine Anpassung der Spezifikation

• Es besteht keine Verpflichtung zur Angabe mehrerer Codes bzw. Code und Freitext.
• Wir geben Vorgaben an die Implementierenden in der Spezifikation zum Umgang mit dem FHIR-Datentyp "CodeableConcept".
• Bei der Strukturierung von Daten und der Auswahl geeigneter Codes können die Anwender:innen durch Primärsysteme (Warnhinweise, etc.) unterstützt werden. 
• Langfristig ist die (teil-)automatisierte Befüllung und Überprüfung mehrerer Angaben mithilfe von Mappings, Arzneimittelreferenzdatenbank, etc. denkbar. Diese müssen jedoch an übergeordneter Stelle erarbeitet werden. Die mio42 beteiligt sich gern.

Umgang mit der Referenzdatenbank nach §31b SGB V:

Es erreichte uns der Wunsch, die Referenzdatenbank (§31b SGB V) bzw. die dort vorgehaltenen Daten in die MIO Spezifikation einzubeziehen. Zudem soll die Datenbank als Bezugsquelle für bestimmte Codesysteme/Mappings genutzt werden.

Hintergrund: 

• Die Datenfelder Wirkstoffbezeichnung, Darreichungsform und Wirkstärke aus der Referenzdatenbank nach §31b sind prinzipiell im MIO eMP abbildbar.
• Uns fehlen aktuell noch Informationen zur konkreten Umsetzung der Datenbank in der Spezifikation.
• Aktuell befinden sich noch fehlerhafte Angaben in der Referenzdatenbank.
• Die Referenzdatenbank in ihrer jetzigen Ausgestaltung beinhaltet Begrifflichkeiten wie Wirkstoffstärke, Darreichungsform etc. in patient:innenverständlicher und einheitlicher Form (nicht unbedingt in Form eines bereits bestehenden Codesystems). Die Erwartungen, die sich auch in den Kommentaren widerspiegeln, gehen darüber hinaus, z.B. dass die Datenbank die Informationen auch in codierter Form enthält (z.B. EDQM-Codes) oder Mappings zwischen verschiedenen Codesystemen bereitstellt. Dies ist jedoch aktuell noch nicht der Fall.
• Aufgrund von Lizenz-Problematiken sind nicht alle gewünschten Codesysteme/Mappings problemlos in die Referenzdatenbank integrierbar.

Lösung/ Vorgehen:

→ Ergänzung von Hinweisen in unserer Spezifikation, wo entsprechende Daten aus der Datenbank in unserem MIO abgebildet werden können

• Wir sind in engem Austausch mit dem BfArM, u.a. zur Erarbeitung der konkreten Einbindung der Referenzdatenbank in unser MIO.
• Im Zuge unserer Arbeit leiten wir Anforderungen/Probleme aus dem Versorgungsalltag (auch mit dem Ziel den Scope der Referenzdatenbank zu erweitern) kontinuierlich an das BfArM weiter.

Vorgabe der Version eines Codesystems:

Zur Angabe konkreter Versionen eines Codesystems in der MIO Spezifikation erreichte uns folgender Hinweis:

• Es sollte keine konkrete Version eines Codesystems angegeben werden, stattdessen sollte die Vorgabe erfolgen, dass immer die aktuellste Version eines Codesystems zu verwenden ist.

Lösung/ Vorgehen:

→ ggf. Anpassung der Spezifikation in einer der Fortschreibungen

• (zumindest teilweise) Abschaffung der strengen Vorgabe einer Version aktuell in Diskussion (MIO-übergreifend und gemeinsam mit der KBV)

Verwendung von SNOMED CT:

In unserer Spezifikation verwenden wir oftmals SNOMED CT als Codesystem. Dazu erreichte uns folgender Hinweis:

• Es besteht die Sorge vor mangelnder Tauglichkeit des Codesystems und eine erschwerte Verarbeitung in Primärsysteme (z.B. für AMTS-Prüfung). 
• SNOMED CT sollte daher nicht für das MIO eMP verwenden bzw. stark einschränken werden.
• zudem sollten Mapping von gängigen Codesystemen zu SNOMED CT bereitgestellt werden.

Hintergrund:

• Die Anzeige der menschenlesbaren Wiedergabenamen ist immer möglich
• In der Spezifikation ist die Codierung mit SNOMED CT®-Codes entweder als ValueSet mit vorgegebenen Codes oder eine alternative Abbildung mit anderen Codesystemen oder als Freitext möglich

Argumente für SNOMED CT:

• Teilweise einzige passende Terminologie zur Abbildung bestimmter Informationen
• Gewährleistung der Interoperabilität (auch im Hinblick auf internationalen Austausch)
• Gesetzliche Verpflichtung zur Verwendung internationaler Standards (§355 SGB V)
• Empfehlungen des Interop Councils und Richtlinien für den EHDS

Aktuelle Hindernisse:

• Mangelnde Erfahrungswerte im Umgang mit SNOMED CT® in der Praxis
• Fehlende Klarheit über den Umgang und die Abbildung komplexer Datenstrukturen (z.B. verschiedene Granularitätslevel bei der Abbildung von Medikamenten)
• Fehlende feste Prozesse bzgl. Erstellung/Pflege von ValueSets 

Lösung/ Vorgehen:

→ keine Anpassung der Spezifikation

• Erarbeitung von Prozessen zum Thema verbindliche ValueSets zur leichteren Umsetzung von SNOMED CT®
• Begleitung der Umsetzung von SNOMED CT® in Primärsystemen bzw. Zusammenarbeit mit Systemen, die bereits mit SNOMED CT® arbeiten
• Mittel- bis langfristige Maßnahmen (ohne direkten Einfluss durch mio42): 
  • Mappings, Referenzdatenbank, nationaler Terminologie-Server
  • Annotationstools, leistungsstarke Suchmaschinen für passende Codes