Design und Architektur klinischer Data Warehouses

Ein klinisches Data Warehouse ist ein integriertes, abfrageorientiertes Repository, das Daten aus den Transaktionsquellen eines Gesundheitssystems konsolidiert, um sie analysieren zu können, ohne den operativen Versorgungsbetrieb zu stören. Sein Design und seine Architektur bestimmen, wie Quelldaten extrahiert, modelliert und für Forschung, Qualitätsmessung und operatives Reporting bereitgestellt werden.

Definition

Das Design klinischer Data Warehouses ist die Architektur und das Engineering integrierter Repositories, die Gesundheitsdaten aus mehreren operativen Quellen in einer Struktur konsolidieren, die für Abfragen, Analysen und Wiederverwendung optimiert ist, anstatt für transaktionale Versorgung.

Scope

Dieses Thema behandelt die architektonischen Muster hinter klinischen Data Warehouses: die Trennung von analytischen und transaktionalen Systemen, Extract-Transform-Load (ETL)-Pipelines, dimensionale versus normalisierte Modellierung und die Verwendung gemeinsamer Datenmodelle zur Portabilität von Abfragen. Es behandelt das Warehouse-Design als ein Thema der Informatik und des Data Engineering, nicht als operative Anweisungen für eine bestimmte Plattform.

Key concepts

• Trennung von analytischen und transaktionalen (OLAP vs. OLTP) Arbeitslasten
• Extract-Transform-Load (ETL)-Pipelines
• Dimensionale Modellierung (Stern- und Schneeflockenschemata)
• Normalisiertes (dritte Normalform) Enterprise-Warehouse-Design
• Gemeinsame Datenmodelle
• Data Marts
• Metadaten und Datenherkunft
• Langsam veränderliche Dimensionen

Mechanisms

Operationale Systeme wie elektronische Gesundheitsakten sind für schnelle Einzeltransaktionen optimiert, was sie für große analytische Abfragen ungeeignet macht. Ein klinisches Data Warehouse begegnet diesem Problem, indem es Daten periodisch aus diesen Quellen extrahiert, transformiert und bereinigt und sie in ein separates, für die Analyse strukturiertes Repository lädt. Zwei einflussreiche Designtraditionen prägen die Modellierungsschicht: der normalisierte Enterprise-Warehouse-Ansatz, der mit Inmon assoziiert wird, und der dimensionale Sternschema-Ansatz, der mit Kimball assoziiert wird und Daten in Fakten- und Dimensionstabellen für eine effiziente Aggregation organisiert. In Forschungsumgebungen organisieren Plattformen wie i2b2 Patientendaten um ein Sternschema und eine kontrollierte Ontologie, damit Forscher Kohorten abfragen können. Die Abbildung des Warehouses auf ein gemeinsames Datenmodell ermöglicht es, dieselbe Abfrage über verschiedene Institutionen hinweg auszuführen.

Clinical relevance

Die Architektur eines klinischen Data Warehouse prägt, welche Analysen machbar sind und wie zuverlässig Kohorten identifiziert werden können, was wiederum die Qualitätsmessung und die forschungsbasierte Versorgung beeinflusst. Das Verständnis des Warehouse-Designs hilft Benutzern zu interpretieren, woher analytische Daten stammen und welche Transformationen sie durchlaufen haben. Dies ist eine Referenzbeschreibung der Infrastruktur und bietet keine individuelle klinische Anleitung.

History

Data Warehousing entstand in allgemeinen Informationssystemen im späten zwanzigsten Jahrhundert, wobei Inmons normalisiertes Unternehmensmodell und Kimballs dimensionales Modell die große Design-Debatte prägten. Das Gesundheitswesen übernahm diese Muster, als elektronische Aufzeichnungen wiederverwendbare Daten ansammelten; forschungsorientierte Plattformen wie i2b2 demonstrierten 2010 Warehouse-Architekturen, die auf die Entdeckung klinischer Kohorten zugeschnitten waren, und gemeinsame Datenmodelle standardisierten später die institutionsübergreifende Abfrage.

Debates

Normalisiertes Enterprise Warehouse versus dimensionale Modellierung

Designer unterscheiden sich darin, ob sie ein normalisiertes, integriertes Enterprise Warehouse (die Inmon-Tradition) aufbauen, aus dem Data Marts abgeleitet werden, oder dimensionale Sternschema-Marts direkt aufbauen (die Kimball-Tradition); die Wahl tauscht Integration und Flexibilität gegen Abfrageeinfachheit und -geschwindigkeit.

Key figures

• William H. Inmon
• Ralph Kimball
• Shawn N. Murphy
• Isaac Kohane

Seminal works

• inmon-2005
• kimball-ross-2013
• murphy-2010

Frequently asked questions

Warum nicht einfach Analysen direkt auf der Datenbank der elektronischen Gesundheitsakte durchführen?

Transaktionssysteme sind auf viele kleine Lese- und Schreibvorgänge abgestimmt, die die Live-Versorgung unterstützen, sodass große analytische Abfragen sie verlangsamen und das Risiko bergen können, den klinischen Betrieb zu beeinträchtigen. Ein Data Warehouse trennt die Analyse von der Versorgungsleistung und strukturiert die Daten für effiziente Abfragen.

Was ist ein gemeinsames Datenmodell und warum ist es für das Warehouse-Design wichtig?

Ein gemeinsames Datenmodell ist ein geteiltes Schema und Vokabular, das mehrere Institutionen für ihre Warehouses übernehmen. Die Abbildung darauf ermöglicht es, dieselbe analytische Abfrage über verschiedene Standorte hinweg ohne Umschreiben auszuführen, was die multiinstitutionelle Forschung und Reproduzierbarkeit unterstützt.