Veröffentlichung - Kommentarbeantwortung

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 im Feld

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.
• per Default werden immer die letzten 12 Monate der eML angezeigt. Dieser Zeitraum kann auf Wunsch der Anwender verändert werden
• eMP enthält nur die planrelevante Medikation (Entscheidung der Leistungserbringer)
• 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ührt immer zu einer Aktualisierung des gesamten eMPs. Dabei ist es egal. ob ich diese Information aus der Ansicht der eML oder des eMP ändere.

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. Eine Umsetzung durch die Primärsysteme ist zwingend notwendig 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.

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
• Löschung des eMP von eGK bei Vorhandensein des MIO eMP

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 PVS 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 möglich 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) (BMG). Dies ist grundsätzlich sinnvoll, damit wir keine doppelte Datenhaltung von Medikationsdaten haben und damit die Gefahr auseinanderlaufender Informationen.
• Für die Übergangsphase kann es sinnvoll sein, den Notfalldatensatz zu nutzen. Dieser ist von der Löschung laut § 358 Ab. 8 SGB V  nicht betroffen und enthält theoretisch auch Medikationsdaten. Aus den oben genannten Gründen weisen wir aber auf die Herausforderung hin, diese mit Daten in der ePA synchron zu halten. 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 gedruckter BMP nicht die aktuellsten Daten enthält
• Workaround für Systeme und Anwender:innen 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ücksichtigt diese Vorgaben
• grundsätzlich ist es sinnvoll für Folgeversionen über die Rechte der Pflege zu diskutieren

  → dazu ist eine übergeordnete Diskussion notwendig

Gleichzeitige Angabe mehrerer Codes bzw. Code und Freitext (beim FHIR-Datentyp "CodeableCondept")

→ Angaben widersprüchliche Angaben möglich, manuelle Überprüfung notwendig und damit verbundener Aufwand

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

• keine Verpflichtung zur Angabe mehrere Codes bzw. Code und Freitext
• Vorgaben an die Implementierenden in der Spezifikation zum Umgang mit dem Datentyp "CodeableConcept"
• Unterstützung der Anwender:innen durch Primärsysteme (Warnhinweise, etc.)
• Langfristig ist die (teil-)automatisierte Überprüfung mehrere 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

→ Einbezug der dort vorgehaltenen Daten, Nutzen der Datenbank als Bezugsquelle für bestimmte Codesysteme/Mappings

Hintergrund: 

• Wirkstoffbezeichnung, Darreichungsform und Wirkstärke aus der Referenzdatenbank nach §31b prinzipiell im MIO eMP abbildbar
• teilweise noch fehlende Informationen zur konkreten Umsetzung der Datenbank in der Spezifikation
• aktuell noch fehlerhafte Angaben in der Referenzdatenbank
• Scope der aktuellen Referenzdatenbank (Patientenverständliche und vereinheitliche Informationen) vs. Erwartungen/ Möglichkeiten einer solchen Referenzdatenbank
• aufgrund von Lizenz-Problematiken sind bestimmte Codesysteme nicht problemlos in die Referenzdatenbank   integrierbar

Lösung/ Vorgehen:

• wir sind in engem Austausch mit dem BfArM, u.a. zur Erarbeitung der konkreten Umsetzung 
• 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

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

→ Sorge vor mangelnder Tauglichkeit des Codesystems, erschwerte Verarbeitung in Primärsysteme (z.B. für AMTS-Prüfung) möglich

Hintergrund:

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

Argumente für SNOMED CT:

• teilweise einziges 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 InteropCouncils und Richtlinien für den EHDS

Aktuelle Hindernisse:

• mangelnde Erfahrungswerte im Umgang mit SNOMED CT in der Praxis
• Fehlende Klarheit über den Umgang und 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, Terminologie-Server
  • Annotationstools, leistungsstarke Suchmaschinen für passende Codes