Das CDR könnte wichtiger werden als die nächste Gesundheits-App – aber was ist das eigentlich?

Wir digitalisieren das Gesundheitswesen seit Jahren und produzieren dabei immer mehr Daten. Das eigentliche Problem ist längst nicht mehr, dass wir zu wenige davon haben. Das Problem ist, dass sie überall herumliegen. Im Krankenhaus, in der Arztpraxis, beim Pflegedienst, in der Pflegeeinrichtung, bei Therapeut:innen, in Apps, auf Wearables und in immer neuen Plattformen. Was wir dagegen noch viel zu selten besitzen, ist ein gemeinsames klinisches Gedächtnis. Genau hier kommt das Clinical Data Repository ins Spiel.

CDR gehört zu jenen Abkürzungen, die auf Architekturfolien beeindruckend aussehen und außerhalb der Health-IT zunächst kaum jemand versteht. Dabei steckt dahinter eine ziemlich einfache Idee: Ein Clinical Data Repository, kurz CDR, führt gesundheitsbezogene und klinische Informationen aus unterschiedlichen Quellen zusammen und stellt sie so bereit, dass sie anschließend von unterschiedlichen Anwendungen und für unterschiedliche Zwecke genutzt werden können.

Das Entscheidende daran ist nicht das Speichern. Daten speichern können wir schon ziemlich lange. Entscheidend ist, sie aus ihren Anwendungssilos herauszulösen.

Ein Mensch, zehn Systeme, zehn Versionen seiner Geschichte

Nehmen wir eine 82-jährige Patientin mit Herzinsuffizienz und Diabetes. Nach einem Sturz kommt sie ins Krankenhaus. Dort entstehen Diagnosen, Laborwerte, Medikationsinformationen, Vitalwerte, Pflegeinformationen und ein Entlassbrief. Anschließend geht sie für einige Wochen in die Kurzzeitpflege, danach nach Hause. Der Hausarzt übernimmt die weitere Behandlung, ein ambulanter Pflegedienst kommt zweimal täglich und eine Physiotherapeutin arbeitet an ihrer Mobilität. Die Patientin selbst misst Gewicht und Blutdruck mit vernetzten Geräten.

Aus menschlicher Sicht handelt es sich um eine Versorgungsgeschichte.

Aus Sicht unserer heutigen IT-Landschaft können daraus allerdings sechs, acht oder zehn verschiedene Datengeschichten werden.

Jede beteiligte Anwendung weiß etwas über die Patientin, aber keine kennt zwangsläufig das Ganze. Und selbst wenn Informationen technisch ausgetauscht werden, heißt das noch lange nicht, dass sie anschließend strukturiert und maschinenverständlich für weitere digitale Prozesse verfügbar sind.

Genau dieses Problem adressiert ein CDR.

Man könnte es sich als gemeinsames klinisches Gedächtnis einer digitalen Versorgungsarchitektur vorstellen. Informationen aus unterschiedlichen Quellsystemen werden zusammengeführt, dem richtigen Menschen und Versorgungskontext zugeordnet und so gespeichert beziehungsweise verfügbar gemacht, dass weitere Anwendungen darauf zugreifen können.

Ein CDR muss dabei nicht auf ein einzelnes Krankenhaus beschränkt sein. Je nach Architektur und organisatorischem Kontext kann es innerhalb einer Einrichtung, eines Versorgungsverbundes oder einer Plattform eingesetzt werden. Entscheidend ist das Prinzip: Daten werden von der Anwendung entkoppelt, in der sie ursprünglich entstanden sind.

Und das ist ein größerer Paradigmenwechsel, als es zunächst klingt.

Bisher kaufen wir Software und bekommen Datensilos gratis dazu

Die traditionelle IT-Logik im Gesundheitswesen funktioniert vereinfacht so: Wir benötigen eine neue Funktion und kaufen dafür eine Anwendung. Diese Anwendung besitzt eine eigene Datenbank. Soll sie Informationen aus anderen Systemen bekommen, bauen wir Schnittstellen. Kommt eine weitere Anwendung hinzu, entstehen weitere Schnittstellen.

Das Ergebnis kennen praktisch alle, die schon einmal hinter die Kulissen einer größeren Gesundheitsorganisation geschaut haben: eine historisch gewachsene Landschaft aus Anwendungen, Datenbanken und Schnittstellen, die irgendwie miteinander kommunizieren.

Ein CDR dreht diese Perspektive zumindest teilweise um.

Nicht mehr jede Anwendung soll klinische Informationen ausschließlich für sich selbst besitzen. Stattdessen entsteht eine gemeinsame Datenebene, auf der unterschiedliche Anwendungen aufsetzen können.

Das führt zu einer ziemlich spannenden Vorstellung:

Die Daten gehören nicht mehr zur Anwendung. Die Anwendung arbeitet mit den Daten.

Damit könnte beispielsweise eine neue KI-Anwendung relevante Informationen verwenden, ohne zunächst zehn proprietäre Integrationen bauen zu müssen. Eine Pflegeanwendung könnte auf bereits vorhandene Diagnosen, Medikationsinformationen oder Beobachtungen zugreifen. Ein Entscheidungsunterstützungssystem könnte Informationen verschiedener Berufsgruppen kombinieren und Forschungs- oder Qualitätsanwendungen könnten auf einen strukturierten klinischen Datenbestand zugreifen.

Das CDR wird damit zur Dateninfrastruktur hinter den sichtbaren Anwendungen.

Und dann kommt FHIR ins Spiel

Wer über moderne CDRs spricht, landet ziemlich schnell bei HL7 FHIR. Dabei sollte man beide Begriffe nicht verwechseln.

FHIR ist nicht das CDR.

FHIR liefert vielmehr standardisierte Strukturen für Gesundheitsinformationen. HL7 definiert dafür sogenannte Resources. Eine Person kann beispielsweise als `Patient`, eine Beobachtung als `Observation`, eine Diagnose als `Condition` und ein Versorgungskontakt als `Encounter` repräsentiert werden. Diese Ressourcen bilden eine gemeinsame technische Sprache, mit der unterschiedliche Systeme Gesundheitsinformationen austauschen können.

Ein modernes CDR kann diese Sprache nutzen und Informationen FHIR-basiert speichern oder über entsprechende APIs verfügbar machen. Dadurch weiß eine andere Anwendung nicht nur, dass irgendwo der Wert „135/80“ steht. Sie kann verstehen, dass es sich um einen Blutdruck handelt, zu welchem Menschen er gehört, wann er erhoben wurde und in welchem Kontext er entstanden ist.

Allerdings gilt auch hier: Nur weil irgendwo FHIR draufsteht, haben wir noch keine Interoperabilität.

Für wirklich nutzbare Daten benötigen wir zusätzlich gemeinsame Profile, Terminologien, Identitäten, Einheiten, Kontextinformationen und Regeln zur Datenqualität. Und wir müssen nachvollziehen können, woher eine Information stammt und wer sie verändert hat.

Ein FHIR-Server allein ist deshalb noch kein funktionierendes CDR und ein CDR ist weit mehr als eine besonders große FHIR-Datenbank.

Warum ein CDR gerade jetzt interessant wird

Die Idee zentraler klinischer Datenbestände ist nicht neu. Ihre strategische Bedeutung verändert sich aber gerade erheblich.

Der Grund heißt unter anderem KI.

Solange Software hauptsächlich dafür gebaut wurde, einen bestimmten Prozess abzubilden, konnte man akzeptieren, dass die dafür benötigten Daten innerhalb dieser Anwendung lagen. Wenn wir künftig jedoch KI-Agenten, Clinical Decision Support, automatische Dokumentation, Risikomodelle, Versorgungssteuerung und personalisierte digitale Dienste einsetzen wollen, benötigen diese Anwendungen Informationen aus vielen unterschiedlichen Quellen.

Ein KI-System zur Erkennung einer drohenden Verschlechterung interessiert sich nicht dafür, welche Herstellergrenzen unsere IT-Landschaft besitzt. Relevant könnten Laborwerte, Medikation, Vitalparameter, Diagnosen, Mobilität, Nahrungsaufnahme, pflegerische Beobachtungen und Daten eines Wearables sein.

Genau deshalb ist die aktuelle KI-Euphorie ohne eine Diskussion über Datenarchitektur erstaunlich kurzsichtig.

Je intelligenter unsere Anwendungen werden sollen, desto besser müssen die Daten darunter organisiert sein.

Ein Large Language Model kann zwar erstaunlich gut unstrukturierte Informationen interpretieren. In der Versorgung sollten wir intelligente Systeme aber möglichst wenig darüber raten lassen, was ein Datum, ein Messwert oder eine klinische Aussage eigentlich bedeutet.

Für die Pflege wird das besonders spannend

Hier kommt Pflegeinformatik ins Spiel.

Denn wenn wir von Clinical Data sprechen, denken wir erstaunlich schnell an Diagnosen, Laborwerte, Medikamente und medizinische Befunde. Der Gesundheitszustand eines Menschen besteht allerdings aus deutlich mehr.

Wie mobil ist jemand? Kann die Person selbstständig essen? Hat sich ihre Orientierung verändert? Besteht ein Dekubitus- oder Sturzrisiko? Wie entwickelt sich eine Wunde? Wie viel Unterstützung benötigt sie bei alltäglichen Aktivitäten? Welche pflegerischen Interventionen wurden durchgeführt und mit welchem Ergebnis?

Solche Informationen entstehen im Krankenhaus genauso wie in stationären Pflegeeinrichtungen, in der ambulanten Pflege, Rehabilitation oder anderen Versorgungssettings.

Wenn wir künftig sektorenübergreifende Datenräume und CDR-Architekturen aufbauen, darf deshalb nicht wieder eine Welt entstehen, in der „klinische Daten“ faktisch „medizinische Daten plus ein bisschen Pflege“ bedeuten.

Pflegeinformationen müssen strukturiert und semantisch verständlich Teil dieser Datenarchitekturen werden.

Das ist nicht nur für die Pflegedokumentation wichtig. Es entscheidet darüber, ob pflegerische Informationen später für KI, Entscheidungsunterstützung, Qualitätsmessung, Forschung oder sektorenübergreifende Versorgung überhaupt sinnvoll genutzt werden können.

CDR, ePA und Data Warehouse: Ist das nicht alles dasselbe?

Nein. Die Begriffe beschreiben unterschiedliche Dinge, auch wenn sich ihre Funktionen teilweise überschneiden können.

Die ePA ist auf die personenbezogene, sektorenübergreifende Bereitstellung bestimmter Gesundheitsinformationen im deutschen Gesundheitswesen ausgerichtet. Ein CDR ist dagegen ein Architekturkonzept für einen nutzbaren klinischen Datenbestand und kann beispielsweise innerhalb eines Versorgungsunternehmens oder einer Plattform betrieben werden.

Ein Clinical Data Warehouse ist wiederum stärker auf analytische Nutzung ausgerichtet. Daten werden dort typischerweise zusammengeführt und für Forschung, Reporting, Business Intelligence oder andere Auswertungen aufbereitet. Ein CDR kann dagegen auch operative Anwendungen mit aktuellen klinischen Informationen versorgen.

Und ein KIS oder eine Pflegesoftware ist eine Anwendung, mit der Menschen konkrete Prozesse bearbeiten.

Man könnte es stark vereinfachen:

Die Anwendung ist der Arbeitsplatz. Das CDR ist der gemeinsame klinische Datenbestand darunter. Das Data Warehouse analysiert Daten. Die ePA transportiert und erschließt definierte Informationen über Organisations- und Sektorengrenzen hinweg.

In einer modernen Gesundheits-IT-Architektur können diese Ebenen miteinander zusammenspielen.

Das Spannendste am CDR ist deshalb gar nicht das Repository

Interessant wird es, wenn man das Konzept konsequent weiterdenkt.

Heute diskutieren wir häufig darüber, welches Krankenhausinformationssystem, welche Praxissoftware, welche Pflegedokumentation oder welche Plattform die beste ist. In Zukunft könnte eine mindestens ebenso wichtige Frage lauten:

Wie unabhängig sind unsere Daten von diesen Anwendungen?

Wenn ein Gesundheitsunternehmen einen hochwertigen, interoperablen und semantisch strukturierten klinischen Datenbestand besitzt, können Anwendungen darüber wesentlich leichter ausgetauscht oder ergänzt werden. Neue Apps können auf vorhandenen Daten aufsetzen und KI-Dienste müssen nicht jedes Mal die komplette Integrationsarbeit neu beginnen.

Damit verschiebt sich ein Teil der strategischen Macht von der Anwendung zur Datenplattform.

Das ist allerdings kein Selbstläufer. Wer ein CDR aufbaut, muss sich mit Patient:innenidentitäten, Berechtigungen, Datenschutz, Informationssicherheit, Terminologien, Datenqualität, Versionierung und Provenance beschäftigen. Außerdem muss geklärt sein, welches System für welche Information führend ist und was passiert, wenn zwei Quellen widersprüchliche Informationen liefern.

Ein schlechter gemeinsamer Datenbestand ist schließlich nicht besser als zehn schlechte Datensilos. Er verteilt die Probleme nur effizienter.

Vielleicht wird das CDR zur unsichtbaren Schlüsseltechnologie der digitalen Versorgung

Das macht Clinical Data Repositories zu einem interessanten Thema für die nächsten Jahre. Nicht weil Menschen künftig morgens ihre CDR-App öffnen werden. Im Gegenteil: Die meisten Patient:innen und wahrscheinlich auch viele Beschäftigte werden niemals bewusst mit einem CDR arbeiten.

Gerade darin könnte seine Bedeutung liegen.

Während wir über spektakuläre KI-Anwendungen, Ambient Scribe, humanoide Roboter und digitale Assistenten diskutieren, entsteht darunter eine viel unspektakulärere Frage: Haben wir überhaupt eine Datenarchitektur, auf der all diese Anwendungen sinnvoll arbeiten können?

Vielleicht werden deshalb nicht die sichtbarsten Technologien über den Erfolg der nächsten Digitalisierungsphase entscheiden. Vielleicht wird es die Infrastruktur sein, die niemand sieht.

Ein gutes Clinical Data Repository könnte genau so eine Infrastruktur sein: ein gemeinsames klinisches Gedächtnis, das Informationen aus unterschiedlichen Teilen der Versorgung zusammenführt, ihre Bedeutung erhält und sie für die jeweils nächste sinnvolle Anwendung verfügbar macht.

Und für die Pflegeinformatik ergibt sich daraus eine entscheidende Aufgabe: dafür zu sorgen, dass dieses gemeinsame Gedächtnis auch wirklich weiß, was Pflege weiß.

Wie sieht es in euren Einrichtungen aus? Wird bereits über CDRs oder FHIR-basierte Datenplattformen gesprochen und spielen pflegerische Daten bei diesen Überlegungen eine gleichwertige Rolle?

Dieser Text wurde mit Unterstützung von KI erstellt.

Beispiel:

https://nursit.de/smile-cdr