Sie zeigen eine alte Version dieser Seite an. Zeigen Sie die aktuelle Version an.

Unterschiede anzeigen Seitenhistorie anzeigen

« Vorherige Version anzeigen Version 5 Nächste Version anzeigen »

To Do


Die Kommentierung für das MIO Medikationsplan und AMTS-relevante Zusatzinformationen fand vom 25.03 - 26.04.2024 statt. Nach Abschluss der Kommentierung und der Prüfung sowie Bewertung aller eingegangenen Kommentare ist hier ein Überblick zum eingegangenen Feedback und den Bewertungsergebnissen einsehbar. Das überarbeitete MIO wird im Rahmen der Benehmensherstellung dargestellt.

Kommentare zum Gesamtkonzept

KommentarthemaErgebnis

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 
Umgang mit dem BMP
Rolle der Pflege bei der Medikationsdokumentation


Kommentare zu normativen Vorgaben: Spezifikation

KommentarthemaErgebnis
Harmonisierung mit ISiK
Komplexität des Modells, v.a. Dosierung
Abstimmung mit gematik Spezifikation für ePA MedicationService
Zwischenüberschriften
offene vs. geschlossene Spezifikation

Kommentare zu normativen Vorgaben: Codierung

KommentarthemaErgebnis

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

  • technische Einschränkung auf einen Code oder nur Freitext nicht möglich, da Risiko der Inkompatibilität mit anderen Spezifikationen
  • an bestimmten Stellen Angabe mehrerer Codes bzw. Codes und Freitext fachlich sinnvoll (z.B. zusätzliche Eingabe patient:innen-verständlicher Begriffe)
  • Verantwortung zur Eingabe inhaltlich korrekter, zueinander passenden Informationen allgemein bei bearbeitender 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: (teil-)automatisierte Überprüfung mehrere Angaben mithilfe von Mappings, Arzneimittelreferenzdatenbank, etc.

Umgang mit der Referenzdatenbank nach §31b SGB V

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


  • 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 Lizenz-Problematik bestimmte Codesysteme nicht problemlos integrierbar

Lösung/ Vorgehen

(Frage) 

  • enger Austausch mit dem BfArM, u.a. zur Erarbeitung der konkreten Umsetzung
  • Weiterleiten der Anforderungen/Probleme aus dem Versorgungsalltag (auch mit dem Ziel den Scope zu erweitern)
Vorgabe der Version eines Codesystems

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

Erläuterungen

  • Anzeige des menschenlesbaren Wiedergabename immer möglich
  • in der Spezifikation 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
  • Empfehlungen des InteropCouncils und Richtlinien für den EHDS

Aktuelle Hindernisse 

  • mangelnde Erfahrungswerte
  • 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