Fachbeitrag

In wenigen Schritten zu einem gewinnbringenden Data Warehouse

Uhr
von Andrea Sommer Consultant, Indema, MSc in Biostatistik und Anna Hitz Partnerin Health, Indema, MSc in Business Information Systems

In Spitälern kommen immense Datenmengen zusammen. Mit Data Warehousing (DWH) ist es möglich, alle Daten zentral zur Verfügung zu stellen. Dies bringt jedoch Herausforderungen mit sich. Eine Herangehensweise in Etappen hilft jedoch, diese Herausforderungen in realisierbare Aufgaben herunterzubrechen.

Der Begriff des Data Warehousing wird seit den 90er-Jahren häufig erwähnt. Die Idee, im Moment des Informationsbedarfs alle Daten vereint an einem Ort zur Verfügung zu haben, ist somit nicht neu oder überraschend. Die Notwendigkeit und die Vorteile eines Data Warehouse Systems sind bereits viel besprochen und beschrieben worden. Doch gerade in kleineren Organisationen mit beschränkten IT-Ressourcen wird oft auf ein solches Data Warehouse verzichtet, aus Respekt vor der Komplexität oder aus finanziellen Gründen. Dies führt zum Problem, dass für Auswertungen und Reports keine standardisierten und bereinigten Daten zur Verfügung stehen. Mehraufwände, inkonsistente Datengrundlagen und nicht nachvollziehbare Datenänderungen sind die unschönen Folgen.

Unter dem Stichwort "Data Warehouse" (DWH) versteht man einen unternehmensinternen Datenbestand, der durchgängig konsistente, zuverlässige, genaue und aktuelle Daten beinhaltet. Diese zentral gelagerten Daten, die als Single Point of Truth fungieren, können von autorisierten Nutzern jederzeit abgerufen werden. In Spitälern kommen immense Datenmengen zusammen. Die Daten werden in administrative und klinische Daten unterteilt. Ein DWH kann beide Bereiche umfassen oder es können zwei dedizierte Systeme für die jeweiligen Bereiche geführt werden. Eine strikte Trennung ist aber in vielen Fällen nicht möglich und auch nicht sinnvoll. Für Use Cases, etwa im Bereich der Qualitätssicherung oder Planung, werden Daten aus beiden Bereichen benötigt.

Wo die administrativen Daten gewissen, teils auch branchenübergreifenden Standards folgen, stellen die klinischen Daten oftmals eine grössere Herausforderung dar. Etliche Quellsysteme verfügen über sehr unterschiedliche Datentypen und -modelle, auch bedingt durch die diversen Funktionalitäten, die abgedeckt werden müssen. Wir zeigen, wie der pragmatische, aber sehr wichtige Start mit einem DWH in kleineren und mittleren Spitälern gelingt und dass dieser Start Sinn ergibt. Denn dieser gesetzte Grundstein ermöglicht die stetige und ressourcenschonende Erweiterung dieses Systems.

Unsere Erfahrungen zeigen, dass alle Fachbereiche eines Spitals Bedarf haben für Grafiken, Reports und Auswertungen, die gewisse Daten aus zentralen oder bereichsübergreifenden Systemen benötigen. Als konkretes Beispiel dient eine Erregerüberwachung aus dem Bereich der Spitalhygiene. Für viele Auswertungen reichen die Daten aus dem Laborinformationssystem (LIS) nicht. Es werden zusätzliche Daten aus dem Krankenhausinformationssystem (KIS) oder dem ERP benötigt, um vollständige und aussagekräftige Analysen generieren zu können. Doch auch für einfache Auswertungen über die Erreger, für die Daten aus dem Laborinformationssystem (LIS) genügen, sind die Berichte und Grafiken einfacher zu generieren und verfügen über eine viel höhere Qualität und Nachverfolgbarkeit, wenn die Daten aus dem DWH kommen.

Etappenweise Einführung bietet grosses Potenzial

Etliche Anbieter liefern eine gute und einfach einzurichtende Software für das Data Warehousing. Solche Applikationen können laufend weiter ergänzt und aufgebaut werden. Durch die gegebene Skalierbarkeit werden allzu detaillierte und zeitraubende Anforderungsanalysen vermieden. Einzig das Datenmodell sollte von Beginn an so designt werden, dass es einfach zu warten und leicht zu erweitern ist. Des Weiteren sollte die Dokumentation des umgesetzten Modells stets aktuell und genau gehalten werden. Verschiedene Notationen und Diagrammtypen existieren, um diese Anforderung abzudecken.

Tatsächlich lohnt sich ein DWH auch dann schon, wenn nur ein Quellsystem angeschlossen ist. Die Anbindung an ein DWH gewährleistet nämlich die komplette Änderungshistorie der Daten. Zusätzlich gibt dies die Möglichkeit, die Daten einer selbstdefinierten Qualitätsprüfung zu unterziehen und die Daten, falls nötig, ­entsprechend aufzubereiten. So kann man zum Beispiel sicherstellen, dass ein Code für positive Testresultate einheitlich ist und nicht einmal auf Englisch, einmal auf Deutsch und einmal als Plus-Zeichen gespeichert wird. Ebenfalls kann man Prüfungen auf fehlende Daten durchführen und gleich entsprechende Aktionen für die manuelle oder automatisierte Vervollständigung anstossen.

Sobald zwei oder mehrere Datenquellen an das DWH angeschlossen sind, kommen weitere Vorteile hinzu und der Aspekt von bereinigten Daten bekommt besondere Wichtigkeit. Die Existenz von bereinigten und soweit möglich vereinten Daten in einem DWH bringt neue Möglichkeiten für vereinfachte Auswertungen und spannende Analysen. Die Daten kommen in Dashboards zusammen und dienen zum Steuern und Überwachen der Geschäftsprozesse, der Patientendaten oder Auslastungszahlen. Abweichungen werden sofort bemerkt und es kann schnell gehandelt werden.

Somit lohnt sich der Initialaufwand, in die ursprünglichen Quellsysteme einzutauchen, die Datenstrukturen zu verstehen, eine standardisierte Verknüpfung zu Daten aus anderen Quellsystemen auszuarbeiten und die Datenkodierung den internen Kodierungsstandards anzupassen. Der Initialaufwand, der anfangs immens zu sein scheint, gleicht sich rasch aus mit dem Zeitaufwand, den man ansonsten für jede neue Auswertung und für erneute Validierung und Qualitätsüberprüfung hat.

Die Transformation und Qualitätsprüfung in der Schlüsselrolle

Bevor das DWH mit sauberen Daten zur Verfügung steht, gibt es einige Dinge in der Transformationsphase zu berücksichtigen und zu überprüfen. Dies bedeutet Arbeit. Diese Arbeit öffnet aber nicht nur neue Türen, sie ersetzt Aufwände, die bisher nachgelagert, oft unstrukturiert und dezentral erledigt werden mussten. Die Standardisierung von Masseinheiten ist ein anschauliches Beispiel. Viele numerische Merkmale besitzen eine solche Masseinheit, etwa Länge, Gewicht, Temperatur oder Geschwindigkeit. Die Verwendung einer skalierten Masseinheit je Merkmal ist essenziell, um die Daten vereinen zu können. Dasselbe gilt für Datumsangaben. "MM-DD-YYYY" oder "DD.MM.YYYY" sind beides gängige Datumsformate. Moderne Datenbanksysteme unterscheiden mittlerweile zwischen einer internen und externen Darstellung. So wird oft auch ein bestimmtes, proprietäres Datenformat für die interne Datumsdarstellung erwartet. Eine entsprechende Konvertierung in das benötigte Format, die zusätzlich berücksichtigt, dass der Datentyp der Datumsangabe aus dem Quellsystem als "date" hinterlegt ist und nicht als "character", ist somit unvermeidbar.

Das Überprüfen und Vereinheitlichen sind auch zentral für codierte Attribute. Viele Attribute liegen codiert vor, dies kommt insbesondere auch in medizinischen Datenbanken sehr häufig vor. Für gewisse Codierungen haben sich bereits Standards etabliert, so zum Beispiel, dass bei einem binären Ja/Nein-Attribut stets "Ja" als 1 und "Nein" als 0 codiert sein sollte. Anders sieht es aber aus mit Codierungen für "männlich" und "weiblich". Oft wird die alphabetische Reihenfolge zu Hilfe genommen. Dies bringt aber den Nachteil, dass es sprachabhängig ist. So ist es nicht unwahrscheinlich, dass das eine Quellsystem mit deutschem Hintergrund "männlich" als 0 und "weiblich" als 1 codiert hat und das andere Quellsystem "female" als 0 (oder auch 1) und "male" als 1 (oder 2) codiert hat.

Auch uncodierte Attribute bedürfen einer eingehenden Überprüfung. Umlaute und verschiedene Schreibweisen sind Quellen für Inkonsistenzen auch bei vordefinierten Antwortelementen. Sind die Antworten als Freitext durch einen Benutzer erfasst, sind die Varietäten oft unzählig. Abhängig davon, ob bereits Validierungen im Quellsystem bei der Dateneingabe gemacht wurden oder nicht, reicht bei solchen Freitext-Datenfeldern eine systematische Transformation nicht. Sie muss ergänzt werden durch Prüfungen, die eine Warnung geben, falls unbekannte Werte ins DWH importiert werden.

Dies verdeutlicht, dass jedes Attribut, egal ob codiert oder nicht, numerisch oder nicht, entsprechend überprüft werden muss, bevor es ins Data Warehouse integriert werden kann. Nicht nur die Vereinheitlichung der Daten ist zentral. Auch die Qualität, Granularität und Konsistenz sind wichtige Stichworte für die Datenbereitstellung. Wichtig ist dabei, dass diese Aufwände für die Transformation und Überprüfung keine vergebene Arbeit sind. Dieser Aufwand wird später gespart, wenn zu jeder Zeit saubere, überprüfte und vereinte Daten zur Verfügung stehen, die zusätzlich dank der kompletten Änderungshistorie jederzeit nachvollziehbar sind.

Das Monitoring eines Data Warehouses

Abhängig von den Produkteigenschaften des Data Warehouse kann das Monitoring ausgebaut und ergänzt werden. Das Monitoring löst nicht nur den Datenbeschaffungsprozess (Extraktion, Transformation und Laden) aus, es überwacht auch die Datenquelle und liefert bei Datenänderungen Hinweise darauf. Datenänderungen können auf verschiedene Art und Weise überwacht, verfolgt und dargestellt werden. Abhängig von der Wichtigkeit der Daten und ihrer individuellen Änderungen können so komplexere Techniken, die dafür jede Mutation detektieren und auch abbilden können, oder einfachere Techniken, die nur die Differenzen zwischen definierten Zeitintervallen anhand der beiden Daten-Snapshots detektieren können, implementiert werden. Die Möglichkeiten und Aufwände sind auch abhängig von den Funktionalitäten der Quellsysteme.

Sind diese Möglichkeiten im Data Warehouse nicht gegeben, wird dies ohne grösseren Aufwand später in externen Applikationen implementiert. Denn mit dem befüllten DWH wurde die aufwändigste Arbeit, das Analysieren und Aufbereiten der Daten, bereits erledigt. Es stehen saubere, abgestimmte und historisierte Daten zur Verfügung, die für viele weitere Anwendungen genutzt werden können.

Fazit

Es ist eine Herausforderung, Daten von den unterschiedlichen Quellsystemen in einem Data Warehouse zu vereinen. Eine Herangehensweise in Etappen hilft jedoch, diese Herausforderungen in realisierbare Aufgaben herunterzubrechen. Die Arbeit lohnt sich. Saubere, überprüfte und konsolidierte Daten sind das Ziel, sie bieten viele Vorteile für den Betrieb, die Verbesserung und die Weiterentwicklung von kleineren und mittleren Spitälern. Dieses Ziel wird bereits mit einem "kleinen" DWH, das nur wenige Quellsysteme vereint, erfolgreich angestrebt und erreicht. Der Nutzen eines solchen DWH wird überzeugen. Dank diesem Nutzen werden weitere Quellsysteme folgen und das Data Warehouse wird wachsenn

Webcode
DPF8_188130

Kommentare

« Mehr