Komplexe klinische Daten sichtbar machen, bevor sie zum Modell werden
Ein Blutdruckwert erscheint einfach, bis Ian McNicoll fragt, was er in einer Krankenakte bedeuten muss. Welche Einheiten soll er unterstützen? Wie war die Position des Patienten? Welcher Kontext muss mit dem Wert übertragen werden? Für Ian, einen klinischen Informatiker und ehemaligen schottischen Allgemeinmediziner, liegen Fragen wie diese an der Schnittstelle zwischen Medizin und Software.
Als Gründer und CEO von freshEHR Clinical Informatics sowie Vorstandsmitglied und ehemaliger Co-Vorsitzender von openEHR International hilft Ian dabei, klinisches Wissen in wiederverwendbare Datenmodelle zu übersetzen. Lange bevor diese Modelle ein technisches System erreichen, nutzen er und die openEHR-Community Xmind, um deren Struktur sichtbar zu machen.
Eine einzelne Messung kann einen ganzen Entscheidungsbaum enthalten
Wenn Ian die klinische Datenmodellierung erklärt, beginnt er oft mit etwas Vertrautem: dem Körpergewicht. Die Erfassung scheint nur eine einzige Zahl zu erfordern. Doch dann beginnen die Fragen. Sollte das Modell Kilogramm und imperiale Maßeinheiten akzeptieren? Wurde ein Kind mit Kleidung gewogen? Erfordert die Messung einen Kommentar? Wie wird dasselbe Konzept in verschiedenen Sprachen funktionieren?
Der Blutdruck bringt eigene Verzweigungen mit sich: systolische und diastolische Werte, die Körperhaltung des Patienten, die Umstände der Messung und der klinische Kontext. Jede Antwort kann eine weitere Entscheidung offenbaren, die klar dargestellt werden muss.
Ian beschreibt medizinische Daten und Konzepte als baumartig und fraktal. Ihre Bedeutung hängt nicht nur von einzelnen Datenpunkten ab, sondern auch davon, wie diese Punkte zueinander in Beziehung stehen. Für die Entwickler gemeinsamer klinischer Modelle besteht die Herausforderung nicht nur im Sammeln von Informationen. Es geht darum, eine Struktur zu finden, die Kliniker verstehen, hinterfragen und verfeinern können, bevor etwas in der Software festgeschrieben wird.
Ein Diagramm schlägt die Brücke zwischen Tabellenblatt und System
Ians Diagramme nehmen einen bestimmten Platz im Modellierungsprozess ein. Sie stehen zwischen den von Klinikern gelieferten Anforderungen und den formalen Modellen, die Softwaresysteme letztendlich verwenden.
Von klinischen Anforderungen zur sichtbaren Struktur
Die Arbeit beginnt oft mit einer Tabellenkalkulation einer klinischen Arbeitsgruppe. Ein Augenarzt kann beispielsweise alle Informationen auflisten, die zum Glaukom erfasst werden müssen. Die Zeilen erfassen die Anforderungen, zeigen aber nicht unbedingt die klinische Struktur dahinter.
Ian baut dieses Material in Xmind neu auf. Eine gemischte Struktur – ein Organigramm im oberen Bereich und ein Baumdiagramm weiter unten – ermöglicht es ihm, von der groben Organisation eines Datensatzes zu den detaillierteren klinischen Verzweigungen überzugehen. Er kann geforderte Datenpunkte mit bestehenden openEHR-Modellen verknüpfen und sehen, wo neue Arbeit nötig ist.
Jede visuelle Entscheidung hat eine praktische Bedeutung:
Marker zeigen, welche Datenpunkte bereit sind und welche noch bearbeitet werden müssen.
Abgrenzungen halten zusammengehörige Codelisten beieinander.
Notizen bewahren Erklärungen aus der Originalquelle.
Die Gliederungsansicht stellt dieselbe Struktur linear dar, wenn dies einfacher zu überprüfen ist.
Zusammen helfen diese Details Ian, eine flache Tabelle in eine Struktur zu verwandeln, die das klinische Verständnis der Daten widerspiegelt.
Vom Arbeitsdiagramm zum formalen Datenmodell
Das Diagramm ist noch nicht das fertige klinische Modell. Es ist der Vorbereitungsraum, in dem die Community eine Tabelle interpretiert, Beziehungen ordnet und entscheidet, wie jeder Teil in ein größeres klinisches Bild passt.
Sobald die Struktur klar ist, werden spezielle openEHR-Tools verwendet, um formale Archetypen und Templates zu erstellen, mit denen Softwaresysteme arbeiten können. Diese Modelle können dann überprüft, übersetzt, versioniert und einer gemeinsamen Bibliothek hinzugefügt werden.
Xmind ersetzt weder klinische Expertise noch technische Modellierung. Es bietet beiden Seiten eine gemeinsame Plattform, um zu entscheiden, was das Modell bedeuten soll, bevor diese Bedeutung in Code ausgedrückt wird.
Eine Struktur wird zur Sprache für eine Community
Ian hat Xmind vor mindestens einem Jahrzehnt in den Arbeitsablauf integriert, nachdem die Community ein anderes Tool ausprobiert hatte. Die Möglichkeit, Strukturen zu kombinieren, passte perfekt zur Entwicklung ihrer Modelle. Ohne formelle Vorgabe wurde Xmind allmählich zu dem, was Ian den „De-facto-Standard“ der Community für diese frühe Phase der Toolkette nennt.
Die openEHR-Community ist international und kollaborativ. Kliniker und Modellierer teilen .xmind-Dateien in ihrem Diskussionsforum, prüfen Modelle, übersetzen sie und führen die fertige Arbeit in einer gemeinsamen Bibliothek zusammen. Erfahrene Mitglieder empfehlen Xmind, wenn Neueinsteiger nach ihren Werkzeugen fragen. Das Tool ist wichtig, weil die Struktur nützlich ist, nicht weil die Teilnahme davon abhängt.
Diese gemeinsame visuelle Sprache hilft Menschen mit unterschiedlichen Hintergründen, sich in der Mitte zu treffen. Ein Kliniker muss keine technische Modellierungssprache lesen, um zu prüfen, ob die Zweige der realen Praxis entsprechen. Ein Modellierer kann nachvollziehen, wie jedes geforderte Feld in das größere klinische Bild passt.
Die durch diesen breiteren Prozess erstellten formalen Modelle unterstützen Gesundheitsprojekte in mehreren Ländern, darunter der Universal Care Plan in London sowie openEHR-Initiativen in Deutschland, Slowenien und Irland. Die Skalierung kommt später. Der erste Schritt ist immer eine Gruppe von Menschen, die sicherstellt, dass sie dasselbe meinen.
Das Modell beginnt mit einer Frage, die man sehen kann
Für Ian ist eine mind map am nützlichsten, bevor die Antworten endgültig wirken. Sie hält klinische Annahmen sichtbar, solange sie noch hinterfragt, neu geordnet und verbessert werden können. Wenn ein Modell eine Datenbank erreicht, ist ein Großteil seiner Bedeutung bereits festgelegt.
Das fertige System kann einen Blutdruck, ein Körpergewicht oder die Wünsche eines Patienten enthalten. Hinter jedem Feld steht ein Entscheidungsbaum, den jemand explizit machen musste. Ians Arbeit beginnt damit, diesen Entscheidungen eine Form zu geben, die Kliniker und Technologen gemeinsam sehen können.
