Allgemeine Informationen zu UX-Visualisierungen


Als UX-Visualisierungen bezeichnen wir die visuellen, meist interaktiv erfahrbaren, Ergebnisse unserer UX-Design-Arbeit zu den MIOs. UX-Design, kurz für User Experience Design, befasst sich mit der Analyse, Kreation und Optimierung der Nutzer:innenerfahrung. Wie können die Nutzer:innen (das heißt bei uns: alle Personen in der Versorgung, die mit den MIOs arbeiten werden) so einfach und schnell wie möglich an das gewünschte Ziel kommen, obwohl die von ihnen genutzten Systeme teilweise sehr komplexen Anforderungen unterliegen.

Unsere UX-Visualisierungen haben in der Regel die Form von Userflows: Damit meinen wir Abfolgen von Screens, die einen bestimmten Prozess aus der Versorgung abbilden. Meistens stellen wir die Userflows so zur Verfügung, dass sie Schritt für Schritt und mit Hilfe von zusätzlichen Erklärtexten nachvollzogen werden können. Wenn wir die Flows so konfigurieren, dass sie durch freies Klicken erkundet werden können, sprechen wir auch von "Klickdummys".


Mit den UX-Designs wollen wir zeigen, wie MIOs zukünftig in der Versorgung aussehen können und gleichzeitig der umsetzenden Industrie eine mögliche Visualisierung unserer Spezifikationen an die Hand geben. Die UX-Visualisierungen sind ein wichtiges Tool bei der Entwicklung der MIOs weil sie...

...die Kommunikation mit unseren Stakeholdern erleichtern

MIOs sind Datenformate. Wollen wir mit Anwender:innen über die Inhalte und Funktionsweisen von MIOs sprechen, helfen uns UX-Visualisierungen die Vision der MIOs zu transportieren. Statt über abstrakte Datenfelder im Informationsmodell oder in der FHIR®-Spezifikation zu sprechen, macht eine UX-Visualisierung das MIO erlebbar. Sie verbinden die Spezifikation mit den Versorgungsprozessen und helfen so, über die fachlichen Inhalte und die technischen Funktionen eines MIO zu sprechen.

...Umsetzungshilfe für die Industrie sind

Die UX-Visualisierungen zeigen unsere Vision einer guten, sinnvollen und tiefen (nativen) Integration des MIO in ein Primärsystem. Sie haben keinen normativen oder verbindlichen Charakter und sind reine Vorschläge für eine mögliche Umsetzung. Für implementierende Unternehmen können sie als Orientierungshilfe dienen und zeigen, wie Prozesse im Primärsystem durch das MIO idealer Weise unterstützt werden können.

...wichtige Erkenntnisse für die Entwicklung unserer Spezifikation liefern

Im Rahmen der Entwicklung unserer UX-Designs beschäftigen wir uns intensiv anhand konkreter medizinischer Fallbeispiele mit dem MIO, seinen Inhalten, technischen Funktionen und den Prozessen, die das MIO bei den jeweiligen Anwender:innen unterstützen soll. Durch diese Einbindung der Nutzer:innen-Perspektive können wir inhaltliche und technische "Denkfehler" aufdecken und erhalten immer wieder wertvollen Input für unsere Spezifikation und Implementierungsleitfäden. 


Unser Ziel ist es, UX-Visualisierungen für jedes MIO zu entwickeln. Einerseits erarbeiten wir pro MIO ein Standardanzeigemodul, das den Inhalt eines MIO vollständig und unter Berücksichtigung von Usability-Gesichtspunkten abbildet. Andererseits wollen wir eine Vision davon zeichnen, wie die Workflows in den unterschiedlichen Primärsystemen aussehen können, wenn die MIOs vollständig implementiert sind.

MIO Viewer als Standardanzeigemodul:

Der MIO Viewer ist eine Software-Komponente, die es IT-Systemherstellern ermöglichen soll, die Inhalte eines MIO zur Anzeige zu bringen. Die MIO Viewer werden, pro MIO, als Open Source Code auf Github zur freien Verfügung gestellt und können so einfach heruntergeladen und an geeigneter Stelle in das eigene System integriert werden. Die Inhalte eines MIO werden hier in einem isolierten Rahmen abgebildet, somit ist es vor allem für die Systeme relevant, die rein lesend auf die MIOs zugreifen müssen und keine Notwendigkeit zur Weiterverarbeitung der enthaltenen Daten haben. Gegebenenfalls sind zwar auch kleinere Interaktionen (Suchen, Filtern) innerhalb der Komponente möglich – eine Übernahme in das eigene System oder Bearbeitung der Inhalte des MIO allerdings nicht. So kann beispielsweise aus dem MIO Viewer eines Medikationsplans heraus kein Folgerezept erstellt werden. Solche Funktionen sind nur bei einer nativen Integration der MIOs in den Primärsystemen möglich.


Userflows für die native Integration des MIO im Primärsystem:

Der wahre Nutzen der MIOs kommt erst dann zum Vorschein, wenn wir annehmen, dass die unterschiedlichen Primärsysteme zur vollständigen Handhabung der MIOs in der Lage sind. Es bedeutet, dass die MIOs nicht nur lesbar gemacht werden, sondern die strukturierten Inhalte sinnvoll in den jeweiligen Systemkontext einfließen und somit der Arbeitsalltag für die Anwender:innen auf bestmögliche Weise erleichtert wird. Auch das Bearbeiten und Erstellen von MIOs ist zwingend Teil dieser Vision und Gegenstand unserer UX-Betrachtungen.

In unseren Userflows bilden wir anhand konkreter Fallbeispiele und im Rahmen von "Dummy-Primärsystemen" ab, wie die Workflows in der Versorgung der Zukunft aussehen könnten. Dabei betrachten wir komplette Versorgungsprozesse entlang der Patient Journey über unterschiedliche Akteure in unterschiedlichen Sektoren hinweg und versuchen nicht nur, die praktischen Vorteile innerhalb des Nutzungskontextes herauszuarbeiten, sondern auch, Lösungsansätze für mögliche entstehende Schwierigkeiten in einem digitalisierten Gesundheitssystem mitzuliefern (z. B.  bei der Synchronisierung lokaler Datenstände mit "ePA-Datenständen" usw.).


Bei der Entwicklung der UX-Visualisierungen gehen wir iterativ vor. Nachdem ein erster Entwurf erarbeitet wurde, wird dieser mit Endnutzer:innen getestet, diskutiert und angepasst. Dieser Prozess wiederholt sich über den gesamten MIO-Entwicklungsprozess hinweg und wird auch nach der Festlegung eines MIO noch weiter fortgeführt, da sich hier aufgrund der dynamischen Umfeldbedingungen (z. B. technische Spezifikation der ePA) fortlaufend Bedarfe zu Anpassung ergeben.


Die UX-Visualisierungen erstellen wir mit dem Designtool Figma. Es handelt sich also nicht um eine echte, programmierte Umsetzung des MIO. Es werden keine Daten im Hintergrund verarbeitet und es sind keine Logiken implementiert. Dadurch kann es sein, dass Flächen, die zunächst interaktiv aussehen, nicht interaktiv sind. Erkennbar sind die interaktiven Flächen daran, dass sie kurz blau aufblinken, wenn beliebig auf den Bildschirm geklickt wird.




Übersicht über alle UX-Visualisierungen zum dgMP

Wie könnte der dgMP in der Praxis aussehen? Damit Sie sich besser vorstellen können, wie der digital gestützte Medikationsprozess in der Versorgung wirken wird und welche Veränderungen er für die einzelnen Anwender:innen und die Versicherten mit sich bringt, finden Sie unter den folgenden Links UX-Visualisierungen, die eine Umsetzung der einzelnen Komponenten des dgMP, teilweise in unterschiedlichen fiktiven Primärsystemen, zeigen. 



Medikationsplan (isolierte Anzeige)


Szenario: nicht spezifisch

Hier wird die reine Anzeige des Medikationsplans durch die MIO-Viewer-Komponente gezeigt. Innerhalb der Komponente können eine Stichwortsuche sowie verschiedene Filter angewendet werden. 



Medikationsliste (isolierte Anzeige)

 

Szenario: nicht spezifisch

Hier wird die reine Anzeige der Medikationsliste gezeigt. Innerhalb der Komponente können eine Stichwortsuche sowie verschiedene Filter angewendet werden. 

⚠ Es handelt sich bei der Medikationsliste technisch gesehen nicht um ein MIO, die standardmäßige Anzeige der Daten ist daher nicht Aufgabe der mio42. Trotzdem wollen wir, für ein besseres Gesamtbild, entsprechende Visualisierungen zur Verfügung stellen, die zeigen, wie die Elemente des dgMP aussehen und ineinandergreifen können.

⚠ Die kürzliche Neuerung, dass die Medikationsliste auch alle Informationen des Medikationsplans enthalten soll, ist in diesem Arbeitsstand noch nicht enthalten.




Umsetzung des dgMP (Medikationsplan, Medikationsliste) in einer Rettungsdienstsoftware (eingebettete Anzeige)


Szenario: Notärztin sichtet Inhalte der elektronischen Patientenakte auf dem Tablet (Fallbeispiel Isolde Meinhardt)

In dieser Visualisierung wird davon ausgegangen, dass die Rettungssoftware als rein lesendes System konzipiert ist. Die Inhalte der ePA werden, nach Einlesen der eGK und erfolgreichem Verbindungsaufbau, gesichtet und einzelne Dokumente daraus (Medikationsplan, Medikationsliste, Patientenkurzakte) geöffnet oder genauer gesagt: heruntergeladen und geöffnet. Hier zeigen wir, wie es aussehen könnte, wenn die MIOs mit Hilfe der jeweiligen entsprechenden Viewer-Komponente zur Anzeige gebracht werden. 

Die Viewer-Komponente wurde hier in die Software eingebettet, sodass sie zunächst nicht als isolierter Baustein erkennbar ist. Darüber hinaus wurde sie leicht angepasst: Der Header mit den Patientendaten, der eigentlich standardmäßig Teil der Komponente ist, wurde entfernt, da wir uns hier in einem Primärsystem bewegen, welches die Patientendaten sinnvollerweise bereits übergeordnet aufführt.

Es sind bei dieser Konfiguration also keine weiteren Funktionen auf Basis der geöffneten MIOs möglich. Obgleich das zu befüllende Notfallprotokoll sicherlich ein denkbarer Usecase für eine Übertragung von strukturierten Daten wäre...







Umsetzung des dgMP in einem Praxisverwaltungssystem (volle MIO Integration)


Szenario: Hausärztin sichtet Inhalte der elektronischen Patientenakte und importiert relevante Daten in das PVS (Fallbeispiel Isolde Meinhardt)


Szenario: Hausärztin bearbeitet Medikationsplan und erstellt neue Rezepte (Fallbeispiel Isolde Meinhardt)




Umsetzung des dgMP in einem Krankenhausinformationssystem (volle MIO Integration)


Szenario: Ärztin und Krankenhausapotheker stellen Medikation auf die Hausliste des Krankenhauses um  (Fallbeispiel Isolde Meinhardt)


Szenario: Stationsarzt stellt Medikation auf Entlassmedikation um (Fallbeispiel Isolde Meinhardt)



Umsetzung des dgMP in einem Apothekenverwaltungssystem (volle MIO Integration)


Szenario: Apothekerin dispensiert Medikamente zu eRezepten und überprüft Medikationsplan (Fallbeispiel Isolde Meinhardt)




Kommentierungen

    • Key

    • EMP1X0X0-309

    • Erstellt

    • 26.04.2024

    • Name

    • Dr. Karl Sydow

    • Organisation

    • Bundesverband der Arzneimittel-Hersteller BAH

    • Zusammenfassung

    • Farbliche Hinterlegung der Arzneimittelkategorien, insbesondere des Grünen Rezeptes/OTC-AM

    • Beschreibung

    • Die papiergebundenen Muster sind je nach Arzneimittelkategorie farblich kodiert (Grün - OTC; Rosa - Muster 16; Blau - PKV; Gelb - BtM). Die farbliche Einteilung der Rezepte und den damit verbundenen Arzneimittel ist bei allen Beteiligten des Arzneimittelverordnungsprozesses verinnerlicht. Sie bietet Patienten darüber hinaus eine Orientierung iS "Was erwarte ich für ein Arzneimittel?".

      Der BAH weißt darauf hin, dass die Erfassung, Verarbeitung und Darstellung von OTC-Arzneimitteln noch nicht im vollen Umfang bei der MIO berücksichtigt wurde. Die Bedeutung von OTC-Arzneimittel im Rahmen des Medikationsplans/ AMTS wurde jedoch gesetzlich mit dem DigiG untermauert. Über das Grüne Rezept werden jährlich rund 41 Mio. ärztliche Empfehlungen Patienten ausgestellt. OTC Arzneimittel sind für Patienten eng verbunden mit der Farbe des Grünen Rezeptes. Aus Sicht des BAH gilt es, diesen Wiedererkennungswert Patienten und Leistungserbringern weiterhin zu ermöglichen. Dies gilt auch für die Darstellung anderer Arzneimittelkategorien.

      Farbliche Kodierungen helfen, die Relevanz von Arzneimitteln im Rahmen der AMTS schnell einzuordnen. Die aktuelle Darstellung macht es den Patienten schwer einfach Arzneimittel/ Rezepte in Ihrer Relevanz/ Wirkung zuzuordnen. Dies kann zu AMTS Problemen führen.

      Daneben bietet das Grüne Rezept bzw. in Zukunft das elektronische Grüne Rezept mehrere niederschwellige Vorteile:

      • Adhärenz-Förderung und zusätzliche Therapieoption für die Ärzte
      • Orientierung, Information und Sicherheit für Patienten
      • Aktive Beratungsangebote in Apotheken
      • Entlastung der GKV

    • Key

    • EMP1X0X0-308

    • Erstellt

    • 26.04.2024

    • Name

    • Helmut Ristok

    • Organisation

    • FINSOZ e.V.

    • Zusammenfassung

    • Visualisierung der Standes des letzten eMP in der eML

    • Beschreibung

    • Die komplexen Abhängigkeiten zwischen eML und eMP lassen sich für den Benutzer leichter berücksichtigen, wenn in der eML das Datum es letztgültigen eMP mit angezeigt wird und dies auch visuell in der eML berücksichtigt wird.

      UMSETZUNG:
      Hinweis: „Letzter eMP vom 26.4.204“ im Kopfbereich der eML
      +
      Darstellung der alten (schon im eMP berücksichtigen) Teile der eML abgedunkelt in grau,
      während die aktuellen Bestandteile der eML (Datum nach Erstellung eMP) deutlich mit vollem Kontrast in Schwarz dargestellt werden.
      ggf. noch zusätzlich durch eine horizontale Linie getrennt

      NUTZEN:
      Der Benutzer sieht zum einen dass es ggf. schon einen eMP gibt und zu welchem Datum dieser erstellt worden ist.
      Zusätzlich wird er visuell geführt, welche Teile der eML noch nicht im eMP berücksichtigt worden sind. Dafür treten die schon im eMP berücksichtigten Teile der eML in den Hintergrund

    • Key

    • EMP1X0X0-203

    • Erstellt

    • 26.04.2024

    • Name

    • Henrik Henke

    • Organisation

    • Sonnen-Apotheke Bad Kötzting

    • Zusammenfassung

    • AVS - Verordnungsart / Dokumentation BRV

    • Beschreibung

    • Die UX-Visualisierungen sind sehr hilfreich, sollten jedoch um folgende Aspekte ergänzt werden:

      • Verordnungsart: Hier sollte zwischen PZN-, Wirkstoff- und Freitext-VO unterschieden werden. Alle drei haben unterschiedliche Input- und Output-Größen (unstrukturierte Rezeptur als Freitext hat in der Abgabe keine Daten außer "Rezeptur").
      • Rahmenvertrag zur AM-Abgabe: Es ist nicht dargestellt, dass die Auswahl des Fertig-AM nicht nach Lagerbestand o.ä. ausgewählt wird, sondern nach klaren Regeln des entsprechenden Rabattvertrages. Hierfür ist z.B. bei Lieferengpässen eine Abweichung von der Verordnung möglich. Diese Änderungen sollten enthalten / gekennzeichnet sein.
      • Chargennummern: OTC-Artikel benötigen in der Abgabe keine Chargennummern / Scan.
        Insgesamt ist der Kassenprozess viel komplexer und kann sicher nicht Teil dieser Visualisierungen sein.

    • Key

    • EMP1X0X0-169

    • Erstellt

    • 25.04.2024

    • Name

    • Constanze Pappert

    • Organisation

    • Bundesverband Gesundheits-IT - bvitg e.V.

    • Zusammenfassung

    • Fragen zur Darstellungen BMP im eMP / zum Druck BMP

    • Beschreibung

    • 1. Wo werden gebundene Zusatzzeilen aus einem BMP im MIO eMP abgespeichert?
      2. Was passiert mit Überschriften bzw. Zwischenüberschriften aus einem BMP?
      3. Kann das Druck-Kennzeichen, ob z.B. das Geschlecht gedruckt wird, erst beim erstellen eines BMPs erfolgen?
      4. Die Patient:innen werden nur über die KVNR identifiziert, wie ist die Regelung zum Druck eines BMPs? Die Daten zu den Patient:innen müssen dann aus dem Stammdaten eines PVS ausgelesen werden. Ist diese Annahme richtig?

    • Key

    • EMP1X0X0-141

    • Erstellt

    • 24.04.2024

    • Name

    • Ralf Bialojahn

    • Organisation

    • TRB Chemedica AG

    • Zusammenfassung

    • AMTS-Prüfung im Klick-Dummy Hausärztin bearbeitet Medikationsplan

    • Beschreibung

    • Guten Tag, Ihre Isolde Meinhardt hat keine Allergien/Unverträglichkeiten. Bei vorhandenen Allergien sollte eine automatische Prüfung unter AMTS-Gesichts-punkten erfolgen. Beispiel: Patientin mit Glaukom und neu eingetragener Konservierungsmittelunverträglichkeit (Benzalkoniumchlorid, BAC), Therapie mit Antiglaukomatosa (Dorzolamid + Timolol), Darreichungsform ATR. Es gibt Medikamente mit/ohne BAC. Es müsste zumindest ein cave kommen und den Verschreiber um Bestätigung der Rezeptierung mit einem BAC-haltigen Präparat bitten. Bei einem NEIN zeigt die Medikationsliste idealerweise dann nur die vier Präparate (von x Anbietern) ohne Konservierungsmittel und sollte ein aut idem-Kreuz setzen, um den Austausch in der Apotheke zu verhindern, sofern das ausgewählte Präparat kein Rabattvertragsprodukt ist.

    • Key

    • EMP1X0X0-134

    • Erstellt

    • 22.04.2024

    • Name

    • Mark Langguth

    • Organisation

    • Langguth.Digital

    • Zusammenfassung

    • UMSETZUNG DES DGMP IN EINEM APOTHEKENVERWALTUNGSSYSTEM

    • Beschreibung

    • Die UX-Darstellung im AVS umfasst hinsichtlich der Tätigkeiten eines Apothekers leider ausschließlich die heutigen Aktivitäten im Rahmen der eRX-Einlösung. Die hier eigentlich relevanten Aspekte der Aktualisierung des Medikationsplans (aus einer eRX-Dispensierung oder einer OTC-Abgabe heraus) werden nicht thematisiert. Damit ist die Visualisierung zwar interessant aber leider weitgehend ohne Mehrwert für die Apotheken-Aspekte im Rahmen des dgMP.

      Hier wäre es wünschenswert, wenn (gemeinsam) Vorschläge erarbeitet werden könnten, wie eine Pflege / Aktualisierung des eMP direkt aus dem Auswahl und Verkaufsvorgang heraus stattfinden sollten, damit der eMP tatsächlich immer aktuell vorliegt. Eine nachgelagerte Pflege der Einträge nach dem Verkaufsvorgang, erhöht den Aufwand für den Apotheker und trägt die Gefahr, dass die Aktualisierung unterbleibt.

    • Key

    • EMP1X0X0-106

    • Erstellt

    • 17.04.2024

    • Name

    • Mark Langguth

    • Organisation

    • Langguth.Digital

    • Zusammenfassung

    • Szenario Bearbeitung eMP und Erstellung eRX: Integration mit VOS-Vorgaben fehlt

    • Beschreibung

    • Hallo liebes dgMP-Team,

      die Klickdummys sind unglaublich hilfreich!
      Als konstruktive Kritik:
      Für die Erstellung eines (e)Rezepts gelten die Vorgaben der KBV hinsichtlich der Verordnungssoftware. Dies inkludiert Anzeige-, Filter- und Auswahlvorgaben bei der Auswahl des (konkreten) Medikaments.
      Entsprechend muss der Workflow die Vorgaben der KBV an ein solches VOS beinhalten. Dies ist mit dem Auslösen der Verordnung auf dem eMP heraus (nach aktuellen Vorgaben!) vermutlich nicht umsetzbar.

      Hinzu kommt, dass das Verordnungsmodul ein vom PVS unabhängiges Modul sein kann. Entsprechen sind der Ort der ePA-eMP-Datendarstellung und -Fortschreibung sowie der Ort zur Erstellung eines (e)Rezepts unterschiedlich.

      Es ist daher dringend angezeigt, dass
      a) der Prozess unter Berücksichtigung der KBV-Vorgaben zum VOS erfolgen
      b) die VOS-Vorgaben der KBV auf die sinnvollen Prozesse unter Nutzung des dgMP angepasst werden!

    • Key

    • EMP1X0X0-105

    • Erstellt

    • 17.04.2024

    • Name

    • Mark Langguth

    • Organisation

    • Langguth.Digital

    • Zusammenfassung

    • Szenario Bearbeitung eMP und Erstellung eRX: PVS-internen Daten & Prozesse fehlen

    • Beschreibung

    • Hallo liebes dgMP-Team,

      die Klickdummys sind unglaublich hilfreich!
      Als konstruktive Kritik:
      Wie an anderer Stelle kommentiert, ist die ePA und damit der dortige eMP für die ärztliche Arbeit nur additiv zu sehen - und selbst für den einzelnen Patienten teilweise nicht erreichbar, selbst wenn der Patient eine ePA hat (z.B. weil eine Befugnis abgelaufen ist und der Patient bzw. seine eGK nicht vor Ort ist).

      Das bedeutet, dass die führende Arbeit des Arztes nicht in den Daten der ePA (dem dortigen eMP) erfolgen kann, sondern in den lokal im PVS gehaltenen Daten - die um die Daten der ePA angereichert werden, SOFERN die ePA und ein dortigen eMP in dieser Situation erreichbar ist.
      Dabei wird der Arzt immer im angezeigten eMP sehen wollen, welche Einträge des eMP aus seiner Praxis kommen und welche Einträge aus seiner Sicht Fremdeinträge sind.
      Dies inkludiert, dass das PVS im Behandlungsfall darstellen muss, welchen Stand der lokale eMP hat und welche Informationen des ePA-eMP sich seit dem letzten Mal geändert haben - und damit für den Arzt prüfrelevant sind.

      Dieses Zusammenspiel zwischen lokalen Daten im PVS (Verordnungsliste, MP) und den Daten in der ePA (eMP, eML) ist anspruchsvoll und muss prozessseitig durch entsprechend Datenfelder unterstützt werden, die eine Synchronisation erlauben.

      Es wäre wünschenswert, wenn die UX-Simulation dieses Zusammenspiel abbilden würde, um mögliche "Knackpunkte" in den Festlegung finden zu können. Die "letzten eigenen Rezepte" neben dem Medikationsplan darzustellen, wird vermutlich den Ärzten nicht ausreichen.

    • Key

    • EMP1X0X0-100

    • Erstellt

    • 07.04.2024

    • Name

    • Prof. Dr. Dietmar Wolff

    • Organisation

    • FINSOZ e.V.

    • Zusammenfassung

    • Einbezug der Pflege

    • Beschreibung

    • Auch hier wäre es wünschenswert, sofern die Übernahme in die Primärsysteme der Pflege vorgesehen, diese mit entsprechenden Visualisierungen zu hinterlegen.