Die Grundlagen von Health Tech baut man im Krankenhaus

Eine schriftliche Fassung meiner Keynote vom Digital Health World Congress in London für alle, die nicht im Saal waren, und für alle, die da waren und mich gebeten haben, die Gedanken nochmal aufzuschreiben.

Von Evelina Arushanova, Ph.D. — Senior Product Designer bei elmeas

Letzte Woche stand ich in London auf einer Keynote-Bühne und habe eine These vertreten, die ich seit Jahren leise wiederhole: Die meisten digitalen Gesundheitsprodukte scheitern in Krankenhäusern nicht, weil die Technologie schlecht ist, sondern weil sie nie dafür entworfen wurden, in einem Krankenhaus zu leben.

Dieser Satz bekam zustimmendes Nicken von Leuten, von denen ich Widerspruch erwartet hatte, und Pushback von Leuten, von denen ich Nicken erwartet hatte. Die Fragen danach waren schärfer als alles, worauf ich mich vorbereitet hatte. Zwei Klinikerinnen sind vierzig Minuten geblieben, um mir genau zu zeigen, an welchen Stellen elio, das Produkt an dem ich täglich arbeite, nach wie vor zu kurz greift.

Das ist der Teil des Vortrags, der nicht in 25 Bühnenminuten gepasst hat. Und es ist genau der Teil, von dem ich glaube, dass die Branche ihn am meisten braucht.

Wo Healthtech tatsächlich gebaut wird

Öffnen Sie das Büro eines beliebigen Healthtech-Startups, und Sie finden Designer:innen, Entwickler:innen, Product Manager:innen, manchmal eine Klinikerin in Resident-Rolle. Was Sie meistens nicht finden: die Stationen, Übergaberäume und Nachtschichten, in denen das Produkt später tatsächlich benutzt wird. Das Nächste, was die meisten Teams an die Realität herankommen, ist Nutzerforschung, ein paar Interviews, vielleicht eine Beobachtungssession, ein Usability-Test in einem sterilen Raum.

Das ist nicht dasselbe wie tatsächlich dort zu sein.

In einem kontrollierten Test ist die Nutzerin auf Ihre Software konzentriert. Auf einer realen Station ist sie auf eine Patientin konzentriert, deren Zustand sich gerade verschlechtert, auf einen Kollegen, der nach Hilfe ruft, ein Telefon, das nicht aufhört zu klingeln, einen Alarm zwei Betten weiter. Ihre Software ist eines von fünfzig Dingen, die um ihre Aufmerksamkeit konkurrieren und die meisten dieser fünfzig Dinge sind höherrangig als das, was Sie gebaut haben.

Software, die für die Ruhe eines Testraums entworfen wurde, verhält sich unter diesem Druck schlecht. Workflows werden verbogen, um auf den Bildschirm zu passen, statt umgekehrt. Klinikerinnen entwickeln Workarounds. Das Produkt ist technisch eingeführt. Es ist faktisch unsichtbar.

Was "im Krankenhaus beginnen" wirklich heißt

Bei elmeas war die Frage, die wir immer wieder gestellt haben, nicht "welche Features sollte elio haben?", sondern "was muss diese Klinikerin in genau diesem Moment tun, wenn niemand zuschaut?"

Das klingt weich. Ist es nicht. Es verändert alles daran, wie das Produkt gebaut wird.

Es bedeutet, User Stories mit einem Pfleger am Patientenbett zu schreiben, nicht mit einem Product Manager im Meetingraum. Es bedeutet, zu fragen: "Was war das Letzte, das dich diese Schicht deinen Bildschirm hat beschimpfen lassen?"  und die Antwort als Roadmap-Eintrag zu behandeln, nicht als Anekdote. Es bedeutet, für müde Hände um 3 Uhr morgens zu designen, nicht für ausgeruhte Hände um 10 Uhr vormittags.

Es bedeutet auch zu akzeptieren, dass einige der wichtigsten Workflows im Krankenhaus diejenigen sind, die niemand vollständig beschreiben kann. Sie werden im Kopf getragen, durch Jahre auf Station gelernt, und werden erst dann sichtbar, wenn jemand Neues in die Schicht kommt und sie falsch macht. Wenn Sie diese Workflows nicht sehen können, können Sie nicht für sie designen. Und wenn Sie nicht für sie designen, ist das Beste, was Sie bauen können, Software, die fast funktioniert.

Das Almost-worked-Problem

Das ist der Failure-Mode, über den wir in Healthtech zu wenig reden.

Die meisten digitalen Gesundheitsprodukte scheitern nicht lautstark. Sie stürzen nicht ab, sie geben keine Daten preis, sie schaffen es nicht in die Nachrichten. Sie werden einfach leise nie so genutzt, wie sie genutzt werden sollten. Eine Pflegerin öffnet die App, um eine Sache zu dokumentieren, und greift dann für alles andere zurück zur Papierakte. Ein Arzt nutzt sie in der Sprechstunde, umgeht sie aber auf Station. Die Einführung steht auf dem Papier als erfolgreich. Die Verhaltensänderung steht nicht.

Almost-worked-Software ist schwieriger zu lernen als gescheiterte Software, weil niemand sie als Scheitern bezeichnet. Sie steht in Dashboards als Adoption-Kennzahl, die okay aussieht, bis man fragt, was die Leute tatsächlich mit ihr machen. Und je länger sie dort steht, desto schwerer ist sie zu ersetzen, weil jedes Krankenhaus die Disruption des letzten Roll-outs noch im Gedächtnis hat.

Die Kosten von Almost-worked sind nicht nur die verschwendete Lizenzgebühr. Es ist das Vertrauen, das das nächste Produkt zurückgewinnen muss, bevor es überhaupt ausgeliefert wird.

Was bei uns auch nicht funktioniert hat

Ich möchte das nicht so klingen lassen, als hätte elmeas das alles durchschaut. Haben wir nicht.

Einiges, was wir früh gebaut haben, war falsch. Wir haben Prototypen zu viel zugetraut. Wir haben für die schnellste, klügste Klinikerin auf Station designt und gemerkt, dass die schnellste, klügste Klinikerin nicht der Engpass ist. Der Engpass ist die Berufsanfängerin in der Nachtschicht. Wir haben angenommen, dass die Art, wie ein Workflow in einer SOP-Dokumentation aussieht, die Art ist, wie er tatsächlich passiert. (Das ist sie selten.)

Eine Klinikerin auf dem Congress hat mir von einem elio-Feature erzählt, das sie wirklich nützlich findet und dann sofort drei Stellen aufgelistet, an denen sie noch immer drumherum arbeitet. Das ist kein Scheitern. Das ist der ehrliche Zustand jedes Produkts, das versucht, in einem echten Krankenhaus zu leben. Wir behandeln diese Liste als wichtigsten Roadmap-Input des nächsten Quartals.

Wie die nächsten fünf Jahre aussehen

Wenn ich darauf wetten müsste, welche Healthtech-Teams in den nächsten fünf Jahren etwas bewegen werden, würde ich nicht auf die mit den besten KI-Demos wetten. Ich würde auf die wetten, die die unglamouröse Arbeit machen.

Designer:innen und Entwickler:innen wochenlang in Krankenhäusern einbetten. Durch Nachtschichten sitzen. Dumme Fragen in den falschen Räumen stellen, bis jemand erklärt, was wirklich passiert. Frieden damit schließen, dass der Workflow, den man verstanden zu haben glaubte, sechs Edge Cases hat, von denen niemand erzählt hat.

Diese Arbeit ist nicht glamourös. Sie fundraised nicht gut. Sie taucht in keiner Feature-Vergleichstabelle auf. Aber sie ist das, was Software, die genutzt wird, von Software, die eingeführt wird, trennt. Und in einem Sektor, in dem jede Stunde Aufmerksamkeit von Klinikerinnen kostbar ist, sind "genutzt" und "eingeführt" nicht dasselbe Wort.

Eine offene Einladung

Der hilfreichste Satz, den ich auf dem Congress gehört habe, kam nicht von einer Folie. Er kam von einer Pflegerin in der Kaffeepause: "Ich brauche keine Software, die schneller ist. Ich brauche Software, die mich nicht bestraft, wenn ich kurz wegschauen muss."

Das ist die Messlatte. Dafür baue ich lieber als für jede Benchmark in jedem Pitchdeck.

Wenn Sie Healthtech bauen und Ihnen davon irgendetwas richtig vorkommt oder wenn Sie denken, dass ich an Stellen falsch liege, würde ich gerne von Ihnen hören. Einige der schärfsten Rückmeldungen, die wir je zu elio bekommen haben, kamen von Leuten, die uns zuerst öffentlich widersprochen haben. Das Gespräch ist wichtiger als die Übereinstimmung.

Bis zum nächsten Jahr, auf der nächsten Bühne.