Das University of Pennsylvannia Health System hat mit Hilfe der Enterprise Edition der Orcale Corp’s Business Intelligence Suite ein Single Data Storehouse aufgebaut, in dem Patienten-, Verwaltungs-, Finanz- und Lieferkettendaten auf eine standardisierte Weise angezeigt werden. Hohe Ziele hat das Klinikum sich in verschiedenen Bereichen gesetzt - von der Qualität der Patientenversorgung über Sicherheit und Compliance bis hin zu Research und Finance. Nicht allen, aber vielen Anforderungen der Anwender sei mit vordefinierten Dashboards beizukommen gewesen, berichtet das Zentrum. Gegenüber computerworld.com verriet CTO Brian Wells die acht Phasen, in denen die Aufbauarbeit gelang:
1. Treffen mit den Anwendern, um die wichtigsten Anforderungen an die Daten zu bestimmen: Zunächst galt es, die Mitarbeiter vom größeren Nutzen leistungsstärkerer Tools gegenüber nicht interaktiven Spreadsheets und Grafiken zu überzeugen. Das gelang mit Hilfe ausgewählter Dashboard-Proben. Beispielsweise war das medizinische Personal höchst interessiert an Übersichten darüber, ob Medikationslisten einzelner Patienten bei der Visite tatsächlich gemeinsam kontrolliert wurden. In dieser Phase wurden auch Anregungen der Mitarbeiter aufgenommen.
2. Design der Präsentationsoberfläche: Bei diesem Schritt legten die IT-Experten im Dialog mit den Anwendern erst einmal eine sinnvolle Hierarchie der Daten fest. Zu entscheiden war etwa, welcher Mitarbeiter Einblick in welche Patientendaten bekommen soll. Darauf aufbauend konnte eine ansprechende und übersichtliche grafische Darstellung entwickelt werden.
3. Design der semantischen Oberfläche: Speziellen Anforderungen bei der Verknüpfung von Präsentationsoberfläche und physische Schichte waren beispielsweise die Gruppierung der Patienten nach Krankheitsarten oder der Arzneimittel nach Thearpie-Ansätzen.
Pilotierung hat sich bewährt
4. Design der physischen Schicht: Hier rät die Klinik aus ihrer Erfahrung dazu, Veränderungen möglichst zu vermeiden. Sollten sie doch nötig sein, empfiehlt sich tunlichst eine saubere Dokumentation des Bedarfs und der getätigten Schritte.
5. Entwicklung und Test aller drei Schichten: Als probates Mittel erwies sich die Vorführung eines funktionierenden Prototypen für die Mitarbeiter, gefolgt von wöchentlichen Demonstrationen und Review Sessions. Wünsche der Anwender sollten erst im jeweils folgenden Release des Dashboards und keinesfalls im Hauruckverfahren berücksichtigt werden.
6. Durchführung der Qualitätssicherung: In der Praxis erwies es sich unter anderem als sinnvoll, reale Daten aus dem Warehouse statt bloßer Testdaten zu verwenden. Vergleiche der Dashboard-Daten mit den Original-Daten waren ebenso unabkömmlich wie Tests mit möglichst großen Datenmengen.
7. Durchführung von Pilot-Tests: In mehrwöchigen Tests mit einer kleinen Gruppe ausgewählter Anwender konnten letzte Probleme identifiziert und behoben werden.
8. Beginn des unternehmensweiten Rollouts: Für ungeübte Anwender sind kurze Schulungen einzuplanen. Wer bereits in der Vergangenheit mit Dashboards gearbeitet hat, sollte auch ohne Trainingsrunden klar kommen. Auf Support-Seite sollten Spezifikationen gepostet werden. Darüber hinaus sollten dem Help-Desk Skripts an die Hand gegeben werden - als Orientierungshilfe bei Fragen der Anwender.