4 Schritte zu strukturierten medizinischen Fachanforderungen

Wie in meinem letzten Artikel zu den Stolpersteinen der PDMS-Einführung angedeutet, verdient mein Unternehmen seinen Unterhalt damit, Kliniken zu beraten, Projekte im Gesundheitswesen zu managen und Software zur Integration und Digitalisierung herzustellen.

All diese Themen beinhalten einen wichtigen Schritt: das strukturierte Erheben und Dokumentieren von Anforderungen der Kollegen aus dem medizinischen Fachbereich.

Auf dem Papier klingt das einfach, aber spätestens wenn man als junger Consultant zum ersten Mal versucht einen kurzen Termin von 2-3 Stunden mit dem zuständigen Chefarzt und seinen Kollegen zu vereinbaren stellt man fest, dass Kliniken ein wenig anders ticken. Meine Kollegin im Terminmanagement könnte eigene Artikel zu den Odysseen verfassen, die mit dem Versuch einhergehen, mich mit Pflegern, Ärzten und anderen klinischen Entscheidern zur gleichen Zeit in denselben (digitalen Meeting-)Raum zu bringen.

Eins vorweg: nicht jeder Consultant kann ein Mediziner sein, aber nichts hat mir in meiner beruflichen Karriere größere Dividende eingebracht, als mich trotz meines IT-Hintergrunds in medizinisches Fachwissen einzuarbeiten.

Das New England Journal of Medicine, Onlinekurse zu medizinischen Grundlagen (z.B. via Stanford Medicine), nächtelange Gespräche mit Ärzten und Pflegern während der Einführung von PDMS und angestrengtes Googlen von jedem Begriff, den ich nicht verstehe, führten dazu, dass ich heutzutage den meisten Ausführungen soweit folgen kann, dass ich die Konversation nicht alle vier Minuten unterbrechen muss, um mich zu versichern, dass es sich bei den letzten 3 Abkürzungen noch immer um Dialyseformen handelte.

Und für die Ärzte, die ich damals noch alle vier Minuten unterbrochen habe, um auf dieses Niveau zu kommen: vielen Dank!

Wenn Sie jemals die Gelegenheit für ein Praktikum auf einer Intensivstation oder in der Anästhesiepflege haben sollten: zögern Sie nicht. Der Schlafmangel wird mit Erfahrungen und einer neuen Sympathie für alle verwandten Berufe belohnt, die Sie für den Rest Ihres Lebens begleiten wird.

Wir haben mittlerweile zahlreiche Kliniken dabei beraten, ihre Oberflächen für PDMS und KIS zu planen oder zu optimieren. Das Fazit? Viele Fachkollegen wünschen sich eigentlich nicht mehr als eine zeitlich strukturierte Freitextdokumentation, damit man sich nicht umständlich durch allzu viele Oberflächen, Felder und Checkboxen klicken muss.

Dem entgegen steht allerdings die erste und für mich wichtigste Frage: welche Daten werden erhoben und wie sollen sie verarbeitet werden? Wenn man alle Limitationen kennt, bevor man sich in den Dialog mit den Kollegen aus dem Fachbereich stürzt, dann spart man allen Parteien wertvolle Zeit.

Auch hier sind die Anforderungen seitens der fachlichen Kollegen oft einfacher Natur: die erhobenen Texte müssen zeitlich orientierbar sein und optimalerweise für gewisse Anwendungsfälle gruppiert werden können. (z.B. alles zum Thema Diabetes, Delirprävention, …)

Beide Bereiche basieren darauf, große Mengen an Daten automatisiert auszuwerten, um die Klinik vor dem Bankrott zu sichern und die Weiterentwicklung in der Medizin zu unterstützen.

Aus diesem Grund ist Freitext für diese beiden Berufsgruppen wenig attraktiv: die Analyse von Fließtexten ist fehleranfällig und die KI-gestützten Auswertungsmöglichkeiten zwar auf dem Vormarsch, aber nicht für jedes kleine Anwendungsfeld realistisch.

Deshalb sind diese Disziplinen mein erster Halt: obwohl das Fachpersonal später die Prozesse und Oberflächen vorgibt, so müssen wir am Ende Daten produzieren, die zumindest so strukturiert sind, dass sie ausreichend detailliert für die notwendigen, automatischen Auswertungen sind.

Der Austausch von Daten via Schnittstellen ist der letzte limitierende Faktor, der möglichst früh berücksichtigt werden muss. Wenn Diagnosen strukturiert per HL7-Nachricht verschickt werden sollen, dann ist eine Erhebung im täglichen Arztbericht leider nur schwer realisierbar.

Legt man Schnittstellenbedarfe, notwendige Controllinginhalte und die Wünsche der Forschung übereinander, so entsteht ein Regelset, in dem man sich für alle folgenden Diskussionen bewegen darf.

War der vorige Punkt noch in den eigenen vier Wänden und lediglich mit kurzen Anrufen bei Controlling und Forschung zu erledigen, so geht es bei diesem Punkt um das erste Gespräch mit den Fachkollegen.

In der Realität findet der erste Austausch lange vor der Klärung der Datenstruktur statt, da die meisten Anforderungen aus einer schriftlichen Anfrage oder einem produktiven Austausch beim Kaffeeautomaten entspringen. Diese erste Idee muss jetzt allerdings konkretisiert werden.

Die erste Aufgabe ist das Gliedern in Prozesse. Ohne zu sehr ins Requirement Engineering abzudriften (Buchempfehlung „Software Requirements“ von Karl Wiegers) müssen wir zumindest kurz über das Ziel sprechen, das man in diesen Gesprächen verfolgt:

Die fachliche Beschreibung des Problems muss in abbildbare Prozesse zerteilt werden. Wichtig hierbei sind die einzelnen Prozessschritte mit klar definierbarem Start und Ziel, die notwendigen Arbeiten pro Prozessschritt, beteiligte Personen und die Ein- und Ausstiegspunkte in den Prozess.

Die erfahrungsgemäß größte Herausforderung dieses Schritts ist es, die komplexen fachlichen Inhalte auf eine möglichst einfache, vereinheitlichte Sprache herunterzubrechen.

Aus medizinischer Sicht stark unterschiedliche Indikatoren, Aufgaben oder Dokumentationen lassen sich aus technischer Perspektive oft dennoch unter einen Hut bringen.

Die Aufgabe zählt für mich dann als bewältigt, wenn sich die aufgestellten Prozesse anhand einiger Beispielfälle aus dem alltäglichen Leben durchspielen lassen und keine notwendigen Informationen auf dem Papier fehlen. Sätze wie „Ah, dazu muss man wissen, […]“ deuten darauf hin, dass die gezeichneten Prozessbeschreibungen noch nicht ausführlich genug sind.

Behalten Sie auch das Team im Kopf, das die Anforderungen umsetzt — Ihre Aufgabe beinhaltet nicht nur, dass Sie Ihren Gegenüber verstehen, sondern dass das Ergebnis vom späteren Produktteam verstanden wird.

Viele meiner Ausführungen für firmeninterne Kollegen sind mit Links zu relevanten Artikeln und Beschreibungen zu medizinischen Sachverhalten versehen, wenn es für den Anwendungsfall unabdingbar ist, dass sie verstanden werden.

Nachdem das „Wie“ und „Was“ abgehakt wurden, geht es um das „Womit“. Beinahe jede Anforderung lässt sich auf zu nutzende oder zu erhebende Daten reduzieren.

In den meisten meiner Projekte kommt ein Data Dictionary mit Spalten für den Namen, den Datentyp, einer Beschreibung, Beispielinhalten, Relevanz Forschung, Relevanz Controlling, Relevanz Schnittstellen und einer Fremd-ID (für Schnittstellenzwecke) aus. Bei komplexen Daten finden sich Spalten, um Referenzen zwischen verschiedenen Daten darzustellen (wenn sich beispielsweise Werte wie der Horovitz-Index aus anderen Werten berechnen, die sich im Data Dictionary befinden).

Es wirkt ein wenig abstrakt, sich mit den Kollegen an einen Tisch zu setzen und erst einmal über die Daten zu sprechen, die man für seine Prozesse und Ideen braucht, allerdings hilft der Perspektivenwechsel von klinischem Prozess zu einer Betrachtung der Daten oft dabei, dass einige implizite Zusammenhänge aufgedeckt werden, bevor man 3/4 seiner Oberflächenplanungen über den Haufen werfen muss, weil man konträr zu den Ärzten nicht daran gedacht hat, welche Laborwerte ganz klar für die Beurteilung der aktuellen Beatmungsqualität benötigt werden.

Ein weiterer angenehmer Nebeneffekt von Data Dictionaries: sie sind eine ausgesprochen gute Grundlage für die spätere technische Dokumentation, da eine der häufigsten Fragen ist, welche Prozesse und Oberflächen betroffen sind, wenn man etwas an seinen Daten verändert. Selbst ohne komplexes Dokumentationssystem sind sogar Excel-Dateien mit gleichbleibenden Datenbezeichnern sehr gut durchsuchbar, um solche Querverweise aufzudecken.

Sind Daten und Prozesse beieinander, dann kann endlich der Stift in die Hand genommen werden. Oder ein anderes angemessenes Werkzeug.

Das Arbeitsmittel ist eine nicht zu unterschätzende Entscheidung — obwohl wir für unsere internen Projekte auf Mockuptools zurückgreifen, nutzen wir für die direkte Zusammenarbeit mit Fachpersonal gerne Software, mit der jeder umgehen kann.

Von Screenshots mit Paint-Annotationen bis zu in Excel gebauten Oberflächenprototypen ist alles denkbar, das es den ärztlichen und pflegerischen Kollegen ermöglicht, ohne das Lernen neuer Software oder gar notwendigen Online-Anmeldungen am Designprozess teilzuhaben.

Es klingt nach einer trivialen Entscheidung, aber als externe Projektleitung ist das einer der Punkte, aus dem häufig Projektverzögerungen entstehen. Wenn Feedback zu Oberflächenentwürfen immer auf Prosa und Terminen basiert, dann braucht selbst eine kurze Anmerkung oder das Vergrößern/Verkleinern von zwei Elementen plötzlich mehrere Tage statt ein paar kurzen Klicks in Excel und einer E-Mail.

Davon abgesehen folgt man in diesem Schritt seinen Prozessbeschreibungen: zuerst legt man fest, welche Prozessschritte eine eigene Oberfläche benötigen, definiert die Übergänge zwischen diesen (Speichern → nächste Maske, Abbrechen → vorige Maske) und beginnt dann damit, die einzelnen Oberflächen zu konzipieren.

Auch das Entwerfen einer Oberfläche ist eine Wissenschaft, die eine ganze Serie an Artikeln oder ein Studium verdient, weshalb wir uns nur kurz auf unseren Standardprozess beschränken:

Zuerst entnehmen wir unserem Data Dictionary alle notwendigen Daten und definieren die Arbeitsschritte, die auf unserer Oberfläche erledigt werden sollen.

Als nächstes teilen wir unsere Oberfläche in Zonen ein: jeder Arbeitsschritt wird einer Zone zugewiesen. Da wir in Zentraleuropa daran gewöhnt sind, von links nach rechts und von oben nach unten zu lesen, sollte auch unsere Oberfläche oben links beginnen und unten rechts aufhören.

Zu guter Letzt platzieren wir alle Daten in den zugehörigen Zonen und definieren den Platz pro Element — entscheiden, was bei der Interaktion mit verschiedenen Elementen passiert, und legen Regeln für Sondersituationen fest (was passiert z.B., wenn der Bericht länger wird als die dafür vorgesehene Textbox?).

Wir wissen alle, dass diese stark gekürzte Beschreibung deutlich einfacher ist, als es in der Realität ist. Da mein PR-Manager allerdings vom Fluchen in Artikeln abrät, beschränken wir uns auf eine perfekte Welt, in der es keine zu kleinen Flächen für zu viele Informationen gibt.

Allerdings: wenn Sie Glück haben, dann stehen Ihnen einige professionelle Oberflächendesigner zur Verfügung. Wenn das der Fall ist, dann können Sie die Daten, notwendigen Zonen und Elemente später an jemanden weiterreichen, der auf die mit dieser Arbeit verbundenen emotionalen Schwierigkeiten über lange Jahre vorbereitet wurde.

Das Erarbeiten von fachlichen Anforderungen mit Ärzten, Pflegern und anderen Kollegen aus der Klinik ist der Part meines Berufs, in den ich mich zuerst verliebt habe. Er erfordert Fingerspitzengefühl und eine gewisse Demut im ständigen Kontakt mit Themen, die man gelegentlich nur oberflächlich versteht, und oft erhitzte Diskussionen in dem Versuch, das Fachpersonal vor sich selbst zu schützen.

Ganz grundlegend: Vorbereitung ist alles.

Klinische Prozesse in eine zu einem Produkt entwickelbare Struktur zu bringen ist eine Herausforderung, auf die sich viele jahrelang vorbereiten. Kombiniert man das mit dem komplexen, medizinischen Inhalt, dann entstehen vielschichtige Gespräche. Umso weniger man sich selbst korrigieren muss und umso sicherer man seine Meinung vortragen kann, umso mehr lässt man Platz für das, was wirklich zählt: das Kondensieren der medizinischen Fachmeinung.

Zusammengefasst hat unser grundlegender Prozess die folgenden vier Schritte:

Gelegentlich werden es mehr, manchmal brauchen einige der Schritte mehr Zeit als andere, aber im Wesentlichen lässt es sich immer mit diesem Vier-Phasen-Prozess zusammenfassen.

Wie gehabt: melden Sie sich gerne bei mir, wenn Sie Fragen, Erfahrungsberichte oder Wünsche haben — bis zum nächsten Mal!

Herzlichst,