Intersektorale Versorgung Warum die sektorenübergreifende Versorgung eine Steuerungsinstanz braucht

Anbieter zum Thema

Atos Information Technology GmbH

secunet Security Networks AG

CLYSO GmbH

30 Systeme, 30 Dienstleister, aber keine gemeinsame Steuerung: Warum Deutschlands Gesundheitswesen einen neutralen Orchestrator braucht, der Architektur, Sicherheit und Versorgungspfade zusammenführt.

Ein Befund aus dem Krankenhaus muss in der behandelnden Praxis verfügbar sein. Die Pflegeeinrichtung sollte wissen, welche Medikamente verordnet wurden. sollten ihre Informationen nicht jedes Mal neu zusammensuchen müssen, wenn sie zwischen Krankenhaus, Praxis, MVZ und Pflege wechseln. Die politische Richtung ist vorgegeben. Die elektronische Patientenakte soll Informationen verfügbar machen, Hybrid-DRG sollen Leistungen über Sektorengrenzen hinweg abbilden und die Versorgung soll zusammenhängender werden.

Trotzdem beginnt die Suche nach einer Information im Alltag häufig an mehreren Stellen. Das Krankenhaus arbeitet mit einem Krankenhausinformationssystem, die Praxis mit einer anderen Lösung, das MVZ mit einem weiteren Portal. Hinzu kommen Anwendungen für Abrechnung, Diagnostik, Medikation, Terminsteuerung und Pflege. Jede dieser Lösungen kann für sich funktionieren. Zusammen ergeben sie noch keinen durchgängigen Versorgungsprozess.

Viele Systeme, kein gemeinsames Betriebsmodell

Deutschlands Gesundheitswesen hat in den vergangenen Jahren viel in Digitalisierung investiert. Neue Anwendungen wurden eingeführt, Portale aufgebaut und Integrationsprojekte gestartet. Im Arbeitsalltag erleben Beschäftigte trotzdem Medienbrüche und Doppeldokumentation. Daten werden mehrfach erfasst und Befunde manuell aus einem System in ein anderes übertragen.

Das ist die Folge einer gewachsenen Struktur. Viele Beteiligte tragen Verantwortung für ihren jeweiligen Ausschnitt. Für den Ablauf über Einrichtungs- und Sektorengrenzen hinweg gibt es häufig keine Stelle, die das gesamte Bild im Blick behält.

Ein Krankenhaus kann seine IT kaum allein auf die Anforderungen einer Pflegeeinrichtung ausrichten. Eine Praxis kann neben dem laufenden Betrieb nicht die Datenarchitektur eines gesamten regionalen Versorgungsraums festlegen. Und ein Anbieter, der eine einzelne Anwendung liefert, konzentriert sich verständlicherweise auf deren Funktionen und Betrieb. So entstehen Lösungen, die innerhalb einer Einrichtung sinnvoll sind, an den Übergängen aber nicht reibungslos zusammenspielen.

Was ein neutraler Orchestrator leisten kann

Eine übergreifende Instanz lässt sich als Orchestrator beschreiben. Der Begriff stammt aus der Musik: Ein Orchestrator sorgt dafür, dass verschiedene Instrumente zu einem stimmigen Zusammenspiel finden. Er spielt nicht jedes Instrument selbst und ersetzt auch keines. Übertragen auf das Gesundheitswesen hält der Orchestrator die Verbindungen zwischen Leistungserbringern, Anwendungen und Datenpfaden zusammen. Er legt Regeln für den Austausch von Informationen fest und überwacht ihre Einhaltung. Wenn ein Prozess technisch oder organisatorisch ins Stocken gerät, muss er sichtbar machen, wo das Problem liegt und wer es bearbeitet.

Sein Auftrag beginnt bei Architektur und Standards. Der Orchestrator entwickelt kein weiteres isoliertes Portal, sondern ein Zielbild für die gesamte Versorgungslandschaft. Dazu gehören Schnittstellen, Datenmodelle und Identitätsmanagement. Ebenso muss festgelegt werden, welche Funktionen zentral und welche dezentral erbracht werden.

Ein weiterer Bereich ist das Vertrauen in den Umgang mit Gesundheitsdaten. Verschlüsselung allein reicht dafür nicht aus. Es muss nachvollziehbar sein, wer auf welche Information zugreift und aus welchem Grund. Berechtigungen müssen sich über Einrichtungsgrenzen hinweg verwalten lassen. Sicherheit gehört deshalb in den Prozess und darf nicht erst am Ende eines Integrationsprojekts geprüft werden. Auch die Verantwortung für den Prozess selbst muss geklärt sein. Ein digitaler Ablauf endet nicht an der Grenze einer Anwendung. Wird ein Befund im Krankenhaus erstellt, in einer Praxis benötigt und in einer Pflegeeinrichtung weiterverarbeitet, braucht es eine Stelle, die den vollständigen Weg im Blick behält.

Hinzu kommt der laufende Betrieb. Integration ist mit dem Go-live nicht abgeschlossen. Schnittstellen werden angepasst, Anwendungen aktualisiert und neue Leistungserbringer kommen hinzu. Ein funktionierendes Modell braucht deshalb Monitoring, Servicelevels und eine Stelle, die Probleme bis zu ihrer Lösung verfolgt. Schließlich muss die Struktur offen für Veränderungen bleiben. Neue Versorgungsmodelle, weitere Einrichtungen und regulatorische Vorgaben sollten sich integrieren lassen, ohne die gesamte Architektur neu aufzubauen.

Damit unterscheidet sich die Rolle des Orchestrators klar von der eines Vendors. Ein Vendor verantwortet in der Regel eine konkrete Lösung und deren Betrieb. Der Orchestrator trägt Verantwortung für das Zusammenspiel mehrerer Lösungen. Seine technische Kompetenz dient dabei dem Versorgungsprozess und nicht dem Verkauf eines bestimmten Produkts.

Was Deutschland vom Mayo-Clinic-Modell lernen kann

Ein Beispiel für diese Perspektive ist die Mayo Clinic. Gemeinsam mit Atos hat sie ein cloudbasiertes Gesundheitsdatenökosystem aufgebaut, das nach Unternehmensangaben mehr als sieben Millionen Patientinnen und Patienten versorgt. Eine zentrale Steuerungsinstanz verbindet dabei Leistungserbringer, Systeme und Datenpfade. Für Deutschland wäre eine technische Kopie dieses Modells nicht passend. Die Gesundheitssysteme, rechtlichen Rahmenbedingungen und Organisationsstrukturen unterscheiden sich deutlich. Übertragbar ist jedoch das zugrunde liegende Prinzip: Die Integration wird als eigene, dauerhaft zu steuernde Aufgabe behandelt.

Im Mittelpunkt steht damit der Versorgungspfad. Entscheidend ist, ob eine Information im richtigen Moment bei der zuständigen Stelle ankommt, vollständig vorliegt und im Arbeitsalltag genutzt werden kann. Ob diese Information über ein bestimmtes Portal oder eine andere Anwendung übertragen wird, ist dafür zweitrangig. Für Deutschland ergeben sich daraus einige klare Konsequenzen. Ein digitales Ökosystem braucht einen erkennbaren Kern. Dieser Kernmuss nicht alle Daten zentral speichern und nicht jede Entscheidung an sich ziehen. Er muss Regeln für das Zusammenspiel festlegen und nachvollziehbar machen, ob sie eingehalten werden.

Außerdem muss die Integration vom Versorgungspfad her gedacht werden. Die technische Anbindung einer Einrichtung ist nur ein Baustein. Im Alltag zählt, ob die Aufnahme in der Notaufnahme, die Weiterbehandlung in der Praxis, die Abrechnung einer Hybrid-DRG und die Übergabe in die Pflege ohne unnötige Doppelarbeit funktionieren. Schließlich braucht die Integration dauerhaft Aufmerksamkeit. Viele Vorhaben scheitern nach der ersten technischen Verbindung. Wenn Zuständigkeiten offenbleiben, Datenqualität nicht gemessen wird und niemand die gesamte Kette überwacht, kehren alte Arbeitsweisen schleichend zurück.

Der nächste Schritt ist kein neues Portal

Deutschland braucht für die intersektorale Versorgung vor allem eine Instanz, die bestehende Systeme in einen belastbaren Zusammenhang bringt. Sie muss technische Architektur, Sicherheitsanforderungen und Versorgungspraxis zusammenführen. Dafür braucht sie ausreichend Unabhängigkeit, um auch unbequeme Fragen zu stellen.

Das ist anspruchsvoller, als eine weitere Anwendung zu beschaffen. Es verlangt Entscheidungen über Zuständigkeiten, Standards und den laufenden Betrieb. Vor allem braucht es ein gemeinsames Verständnis davon, dass Integration eine Infrastrukturaufgabe des gesamten Versorgungssystems ist.

Die elektronische Patientenakte, Hybrid-DRG und neue sektorenübergreifende Versorgungsmodelle können wichtige Impulse geben. Ihr Potenzial hängt jedoch davon ab, ob die Systeme dahinter dauerhaft zusammenspielen. Die offene Frage lautet deshalb: Wer übernimmt die Verantwortung dafür, dass die vielen digitalen Lösungen des Gesundheitswesens im entscheidenden Moment gemeinsam funktionieren?

Telematikinfrastruktur

TI 2030: Abwarten ist keine Strategie

Gesundheitsdaten

Forschung zu FHIR-Datenmodell

(ID:50981604)