Wie eine nutzerzentrierte Softwareschicht entsteht

Im vorherigen Artikel haben wir argumentiert: Digitale Patientenversorgung ist keine Sammlung von Kanälen, sondern die Fähigkeit eines Klinikums, aus Patientensicht als ein zusammenhängendes System aufzutreten. Wer das akzeptiert, hat den bequemen Teil hinter sich. Die nutzerzentrierte Softwareschicht zu benennen ist einfach. Die eigentliche Arbeit beginnt dort, wo sie gebaut, verantwortet und schließlich gegen die Systeme und Anbieter gemessen wird, die Ihr Haus heute betreiben.

Um diese Arbeit geht es hier: um die Architektur und die Kennzahlen, die aus Kohärenz etwas machen, das ein Enterprise Architect entwerfen und ein CIO steuern kann. FHIR spielt dabei eine kleinere Rolle als erwartet. Größer ist der Anteil jener Fragen, die entscheiden, ob das Vorhaben den Kontakt mit dem Organigramm überlebt. Die meisten Initiativen für eine nutzerzentrierte Softwareschicht scheitern, weil niemand den digitalen Patientenweg verantwortet, während die Kennzahlen weiterhin die Leistung einzelner Systeme belohnen. Die erste harte Architekturentscheidung wird dann still von dem überstimmt, der das größte System besitzt.

Wie Sie aus dieser Blockade herauskommen, zeigen die folgenden drei Punkte.

Executive Summary

Eine nutzerzentrierte Softwareschicht für Patienten aufzubauen ist zuerst eine Architektur- und Governance-Frage, erst danach eine Technologiefrage. Die schwierigen Teile sind: zu entscheiden, wer den digitalen Patientenweg  von Anfang bis Ende verantwortet, Integration so anzulegen, dass sie Kontext transportiert statt nur Daten, und Systemkennzahlen durch Kennzahlen entlang der digitalen Patientenversorgung zu ersetzen.

• Behandeln Sie die nutzerzentrierte Softwareschicht als dauerhafte Architekturebene über Ihren Systemen, nicht als Projekt, das einmal ausgeliefert wird und endet.
• Integration muss Bedeutung bewegen, nicht nur Datensätze. An dieser Stelle bleiben die meisten rein FHIR-getriebenen Vorhaben stecken.
• Die Politik ist der Kern der Sache: Eine patientenorientierte Schicht verschiebt Kontrolle weg von System- und Anbieterverantwortlichen. Die eigentliche Aufgabe des CIO besteht darin, diese Verschiebung zu vermitteln.

Beginnen Sie mit einer Schicht, nicht mit einem Projekt

Der erste Fehler besteht darin, die Transformation als Integrationsprojekt mit Enddatum zu behandeln. Eine Punkt-zu-Punkt-Integration löst genau eine Übergabe und verfällt danach. Mit jedem neuen System vervielfacht sich die Zahl der brüchigen Verbindungen, die Sie pflegen müssen. Eine nutzerzentrierte Softwareschicht ist anderer Natur: Sie ist eine dauerhafte Ebene, die die digitale Patientenversorgung  über alle Systeme hinweg verantwortet, und sie überlebt jedes einzelne Werkzeug darunter.

Konkret hält die Schicht die Steuerungslogik. Sie entscheidet über die Reihenfolge, in der sich ein Patient bewegt, und verfolgt laufend, wo er steht, um den nächsten Schritt zu bestimmen. Die angebundenen Systeme werden damit zu Fähigkeiten, die orchestriert werden, statt zu Endpunkten, an denen Patienten abgeladen werden. Darunter liegt die FHIR-basierte Integrationsschicht aus dem ersten Artikel.

Kurz gefasst: Transport und Datenform sind FHIR und ISiK. Die Nutzer-Logik liegt eine Ebene darüber.

Technisch gesprochen ist diese Schicht eine Orchestrierungsebene, keine Datenbank und erst recht kein Screen. Sie erfüllt mehrere Funktionen:

• Sie hält den Status der digitalen Patientenversorgung, also die Position jedes Patienten in jedem Pfad, in einem eigenen Speicher.
• Sie stellt eine kleine Menge an APIs bereit, die die Frontend-Kanäle aufrufen.
• Sie steuert die darunterliegenden Systeme über die Integrationsschicht.

Ohne nutzerzentrierte Softwareschicht wird jedes System zur Einbahnstraße

Zwei Fähigkeiten, auf die es ankommt

Ob das funktioniert, entscheidet sich an zwei Fähigkeiten.

Die erste ist eine gemeinsame Patientenidentität, die dieselbe Person über alle Systeme hinweg auflöst. In der Regel ist das ein Enterprise Master Patient Index. Ohne ihn können Sie einen Patienten nicht über Touchpoints hinweg verfolgen.

Die zweite ist ein Weg, die Logik der Schicht in die klinischen Werkzeuge einzubetten, statt sie danebenzustellen. Genau dafür existieren Standards wie SMART on FHIR und CDS Hooks: Das klinische Personal erhält Hinweise in dem System, das es ohnehin nutzt, und nicht auf einem weiteren separaten Bildschirm.

Entscheidend ist, dass sich all das auf dem, was Sie heute betreiben, aufbauen lässt. Am Universitätsklinikum Frankfurt hat das Fraunhofer-Projekt OneViewMed über mehrere getrennte Krankenhausinformationssysteme eine einheitliche Sicht gelegt, mithilfe eines FHIR-Repositorys und ohne eines der Systeme zu ersetzen. Genau darum geht es: eine Schicht über dem Stack, kein Komplettaustausch des Stacks.

Integration heißt Kontextfluss, nicht Systemanbindung

Am Wort ‘Integration’ gehen die meisten dieser Vorhaben still zugrunde. Zwei Systeme zu verbinden bewegt Datensätze zwischen ihnen, und das reicht nicht. Kohärenz erfordert, dass der Kontext sich bewegt. Die Schicht muss also Identität, Patientenweg-Status, das bereits Geschehene und das Kommende transportieren, damit jede Interaktion mehr weiß als das, was in seiner eigenen Datenbank steht.

Nehmen Sie die Aufnahme. Ein angebundenes System kann nachschlagen, dass ein Patient in der Termindatenbank existiert. Eine kohärente Schicht weiß, dass dieser Patient

• einen bestimmten Eingriff gebucht hat,
• seine Anamnese bereits am vergangenen Dienstag übermittelt hat,
• nun an dem Schritt steht, an dem die Voruntersuchungen stattfinden.

Sie kann die erneute Eingabe deshalb überspringen und direkt auf den nächsten Schritt verweisen.

Anders formuliert: Ein angebundenes System beantwortet, ob ein Datensatz existiert. Eine kohärente Schicht beantwortet, wo der Patient in seinem digitalen Patientenweg steht und was als Nächstes passieren soll.

Warum Standards allein nicht ausreichen

Auch deshalb bringt FHIR allein Sie nicht ans Ziel. FHIR standardisiert, wie Daten strukturiert und ausgetauscht werden. Das ist notwendig, transportiert aber keinen Patientenweg-Status und orchestriert nichts. Standardisierungsbemühungen wie ISiK haben bislang entsprechend nur begrenzte reale Interoperabilität erzeugt. Semantik und Sequenz müssen oberhalb der Transportebene verantwortet werden, nämlich von der nutzerzentrierten Softwareschicht selbst.

In der Praxis führen Sie das schrittweise ein. Das Strangler-Fig-Pattern passt hier gut: Sie leiten eine Journey nach der anderen über die nutzerzentrierte Softwareschicht, lassen die darunterliegenden Systeme unangetastet und erweitern sie, sobald sich eine Journey bewährt hat. Das ist nicht nur technische Vorsicht. Lock-in bei Kernsystemen ist real, und einzelne Anbieter widersetzen sich aktiv der Öffnung ihrer Systeme. Sie konstruieren also um die Bestandslandschaft herum, statt das gesamte Programm auf deren Ablösung zu setzen.

Das Betriebsmodell: Jemand muss den digitalen Patientenweg  verantworten

Eine Schicht ohne Verantwortlichen wird binnen eines Jahres zum nächsten Silo. Die Lücke in der Verantwortung des digitalen Patientenweges, die wir im vorherigen Artikel beschrieben haben, schließt genau eine Sache: eine Rolle oder ein Team, das eine digitale Patientenversorgung  von Anfang bis Ende verantwortet und oberhalb der Verantwortlichen für die einzelnen durchlaufenen Systeme angesiedelt ist.

Praktisch bedeutet das, Teams entlang der digitalen Patientenversorgung zu organisieren statt entlang von Systemen. Heute gibt es bei Ihnen vermutlich eine Verantwortung für das KIS und eine für das Terminsystem, die jeweils ihren eigenen Kasten optimieren. Der Wechsel führt zu einem Team, das Aufnahme oder Nachsorge als Ganzes verantwortet und die Systeme als Komponenten behandelt, die es zusammensetzt. Dieses Team legt die Standards fest, die ein neues System erfüllen muss, bevor es Teil der Schicht werden darf. Damit wird Beschaffung still zu einer Erfahrungsentscheidung. Die zentrale Beschaffungsfrage lautet dann nicht mehr, welche Funktionen ein Produkt mitbringt, sondern ob es zur Logik der digitalen Patientenversorgung passt.

Nichts davon hält ohne Budget, das an der digitalen Patientenversorgung hängt und nicht nur an Systemen. Wird jeder Euro pro System zugeteilt, zieht jeder Anreiz zurück zur lokalen Optimierung, und die Schicht verhungert. Den digitalen Patientenweg wie ein Produkt zu finanzieren, ist das, was Verantwortliche tatsächlich in die Pflicht nimmt.

Der Verantwortliche der digitalen Patientenversorgung sitzt über einzelnen System-Verantwortlichen

Einwilligung und Zugriff werden zu Architekturentscheidungen

In Schichten zu denken erzwingt eine Kategorie von Entscheidungen, der man in einer Ansammlung getrennter Systeme ausweichen kann: Einwilligung und Zugriff. Sobald eine Ebene den Kontext eines Patienten über mehrere Systeme hinweg zusammenführt, sind Zweckbindung und Zugriffskontrolle keine Haken an jeder einzelnen Station mehr, sondern Eigenschaften der Schicht selbst.

• Welche Personalrolle sieht welchen Ausschnitt des digitalen Patientenweges?
• Wozu hat der Patient wann eingewilligt?
• Wie wirkt sich ein Widerruf zurück auf die angeschlossenen Systeme aus?

Das sind nun Designfragen, keine Fußnoten in einer Richtlinie.

Unter der DSGVO ist das nicht optional, und ein nachträglicher Einbau ist teuer. Sie müssen Einwilligungsstatus und rollenbasierten Zugriff von der ersten Interaktion an in die nutzerzentrierte Softwareschicht bauen, genauso wie Identität. Eine kohärente Sicht auf den Patienten ist zugleich eine konzentrierte Sicht, und genau diese Konzentration ist der Grund, aus dem die Regulierung existiert.

Kennzahlen wechseln vom System zur digitalen Patientenversorgung

Die digitale Patientenversorgung lässt sich nicht mit Systemkennzahlen steuern. Verfügbarkeit je System, Login-Zahlen und Feature-Nutzung können sämtlich grün sein, während der tatsächliche Weg des Patienten gebrochen ist. Jede dieser Größen misst einen Kasten, nicht den Fluss zwischen den Kästen. Zeigen Ihre Dashboards nur Systeme, sind Sie strukturell blind für genau das, was Sie reparieren wollen.

Patientenweg-Kennzahlen messen die Übergaben statt der Knoten. Ein tragfähiger Startsatz:

• Wie oft ein Patient Informationen erneut eingibt, die die Organisation bereits besitzt.
• Abbrüche zwischen zwei Interaktionen, etwa gebucht, aber nie zur Voruntersuchung erschienen.
• Zeit bis zu einem klaren nächsten Schritt nach jedem Kontakt, und wie oft der Patient damit allein gelassen wird.
• Anteil der digitalen Patientenwege, die ohne manuelles Überbrücken einer Systemlücke durch Personal abgeschlossen werden.

Betrachten Sie das nicht als weiche Werte, denn jede dieser Größen bildet direkt Betriebskosten ab. Jede manuelle Überbrückung ist Personalzeit, die Sie nicht übrig haben, wenn zwei Drittel der Kliniken ihre Pflegestellen nicht besetzen können. Und jeder Reibungspunkt wiegt schwerer, je stärker die Ambulantisierung die Pfade zu Tagesfällen mit hoher Taktung und ohne Puffer verdichtet. Diese Kennzahlen sind der Weg, Kohärenz mit der Bilanz zu verbinden.

Architekturentscheidungen werden politisch

Und hier ist der Teil, den Referenzarchitekturen auslassen: Eine Patientenweg-orientierte Schicht verteilt Autorität neu. Sie setzt eine querschnittliche Verantwortung über einflussreiche System- und Abteilungsleitungen und begrenzt die Anbieter, deren Produkte sie orchestriert. Damit werden mehrere Ihrer Architekturentscheidungen politisch, lange bevor sie technisch werden. Das zu ignorieren ist der Weg, auf dem gute Entwürfe im Gremium sterben.

Am schärfsten zeigt sich das beim Lock-in. Einzelne Anbieter von Kernsystemen öffnen ihre Systeme nicht für Wettbewerber und umgehen Schnittstellen, zu denen sie gesetzlich verpflichtet sind. Wenn Sie die nutzerzentrierte Softwareschicht im Produkt eines Anbieters leben lassen, haben Sie das Monopol lediglich eine Ebene nach oben verschoben. Die strategische Haltung lautet deshalb: Die nutzerzentrierte Softwareschicht gehört Ihnen, gebaut auf offenen Standards und unabhängig von jedem einzelnen System darunter. Die Systeme können Sie kaufen. Die Kohärenz müssen Sie besitzen.

Das verschiebt die Rolle des CIO auf eine Weise, die man klar aussprechen sollte. Ihre Aufgabe besteht nicht mehr darin, die besten Systeme auszuwählen und zu verbinden. Sie besteht darin, eine digitale Patientenversorgung zu vermitteln, deren Bruchstellen der Patient nie sieht, über Abteilungen und Anbieter hinweg, deren Anreize überwiegend in die andere Richtung zeigen. Die Architektur ist der einfache Teil. Die eigentliche Arbeit ist, jede dieser Parteien dazu zu bringen, ein Stück Kontrolle über den digitalen Patientenweg abzugeben.

Ein pragmatischer erster Schritt

Versuchen Sie nicht, alle digitalen Patientenwege auf einmal zu modellieren. Wählen Sie einen Pfad mit hoher Reibung und hohem Volumen und richten Sie die nutzerzentrierte Softwareschicht zunächst nur dafür ein. Sorgen Sie dafür, dass sie vom ersten Tag an mit Kennzahlen für den digitalen Patientenweg instrumentiert ist. Elektive Tageschirurgie ist häufig das richtige erste Ziel: Der Pfad ist verdichtet, und die Reibung ist sichtbar und teuer zugleich.

Eine digitale Patientenversorgung gut zu machen liefert Ihnen drei Dinge, die Sie in den späteren großen Auseinandersetzungen brauchen:

• eine funktionierende Referenzimplementierung,
• einen Governance-Präzedenzfall dafür, wie Systeme Teil der Schicht werden,
• eine Kennzahlenbasis, die den betrieblichen Effekt in Zahlen zeigt.

Auf einem Pfad bewiesene Kohärenz ist ein deutlich stärkeres Argument als über alle Pfade hinweg versprochene Kohärenz.

Wie Cloudflight unterstützt

Cloudflight baut Individualsoftware genau dafür: eine nutzerzentrierte Softwareschicht, die um eine konkrete digitale Patientenversorgung  herum entsteht, aufgesetzt auf eine FHIR-basierte Integrationsschicht über Ihren bestehenden Systemen, und so entworfen, dass die Kohärenz Ihnen gehört und nicht bei einem Produktanbieter gemietet ist. Weil wir Digital Engineers sind und kein Anbieter eines einzelnen Produkts, können wir mit einer Journey beginnen, das Modell belegen und Sie dabei unterstützen, Verantwortung und Kennzahlen zu definieren, die dem Ganzen Bestand geben.

Mit dem Engineering sind wir vertraut. Gemeinsam mit Ihnen arbeiten wir daran, die Kombination aus Architektur, Betriebsmodell und Messung richtig zu treffen.

Werfen Sie auch einen Blick auf unser Gesundheitsportal: health.portal.

Was das für Sie bedeutet

Was also tun Architekten und CIOs am Montag konkret? Vier Schritte, von denen keiner bereits eine Plattformentscheidung erfordert:

1. Wählen Sie einen digitalen Patientenweg mit hoher Reibung als Referenzimplementierung.
2. Benennen Sie eine einzelne Verantwortung für diesen Patientenweg von Anfang bis Ende, oberhalb der Systemverantwortlichen.
3. Definieren Sie drei bis vier Kennzahlen und beginnen Sie zu messen, auch grob.
4. Legen Sie fest, dass jedes neue System zu den Bedingungen der Schicht beitritt, nicht zu seinen eigenen.

Schicht, Verantwortung und Kennzahlen verstärken sich gegenseitig, und keines von ihnen wirkt allein. Wenn ein digitaler Patientenweg vorliegt, haben Sie ein Argument und eine Blaupause für jeden weiteren.