UX-Visualisierungen, Phase II (informativ)

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 idealerweise 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.