Datawarehouse im UKL - Universität Leipzig

Transcription

Datawarehouse im UKL - Universität Leipzig
Datawarehouse im UKL
Ein Überblick über das Berichtswesen uns
Kennzahlensystem
Vorlesung
„Spezielle Gebiete zum Informationsmanagement im Krankenhaus“
IMISE / Universität Leipzig
Dr. Robert Waschipky
Universitätsklinikum Leipzig AöR
©
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 1
Datawarehouse – Fallbeispiel I
Betrachtet wird ein Automobilzulieferer mit 500 Werken in 60 Landesgesellschaften, einem Umsatz von 27 Mrd. Dollar und 136.000 Mitarbeitern.
Geprägt wird dessen Geschäft von der Organisation der Produktion und den
Beziehungen zu den Automobilherstellern und Lieferanten.
Situation eines Automobilzulieferers
500 Werke in 60 Ländern
Ständiger Kauf und Verkauf von einzelnen Werken
Sehr verschiedene regulatorische Bedingungen
Häufige Wechsel in den Lieferanten- und
Kundenbeziehungen
Mit folgenden Konsequenzen für die IT-Landschaft des Unternehmens
Eine Reihe von IT-Systemen zur Produktionssteuerung
Eine heterogene Systemlandschaft in den ERP-Systemen (FI, CO, MM, SD,
HR)
Ein zentrales ERP-System zur Konsolidierung im Konzern
Was sind zentrale Herausforderungen für dieses Unternehmen
(und damit die IT)?
©
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 2
Datawarehouse – Fallbeispiel I
Über den Erfolg eines Unternehmens in der Automobil-Zulieferindustrie
entscheiden Qualität und Management der Logistik sowie der Produktions- und
Einkaufsprozesses. Letzter kann mit Hilfe von BI-Instrumentarien optimiert
werden.
Was sind zentrale Herausforderungen für dieses Unternehmen
(und damit die IT)?
Konsolidierung in den Materialstämmen über alle Werke und Landesgesellschaften hinweg (20.000 Einträge)
Integrierte Steuerung der Einkaufsprozesse im Konzern
Beurteilen der Lieferanten- und Kundenbeziehungen
Messen und Bewerten (Qualitätsmanagement) der Einkaufsprozesse
Und ein Datawarehouse?
Konsolidiert die Materialstämme innerhalb aller ERP-Systeme
Macht in einem zusammenfassenden Berichtswesen die Einkäufe des
Unternehmens transparent (Wieviel kaufe ich von Wem?)
Zeigt die Qualität des Einkaufsprozesses über den Vergleich mit Benchmarkdaten (Dunn&Bradstreet)
©
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 3
Datawarehouse – Fallbeispiel II
Betrachtet wird ein Telekommunikationskonzern, welcher unter so genannten
„0190-Nummern“ Dienste weiterer Anbieter an seine Kunden vermittelt. Hier
werden spezielle Überwachungsmechanismen im Zahlungsverkehr benötigt.
Geschäftsmodell der „0190-Nummern“
Das Telekommunikationsunternehmen führt 50% der Erträge im täglichen
Geschäft an den Dienstleister ab.
Die Belastung der Kunden erfolgt durch das Telekommunikationsunternehmen im Rahmen der monatlichen Abrechung.
Meine Idee
Ich gründe einen „0190-Dienstleister“.
(Ich ☺) melde 1.000 Telefonanschlüsse bei verschiedenen Telekommunikationsunternehmen an.
Die Anschlüsse lasse ich 30 Tage / 24h meine 0190-Nummer anrufen.
Und dann?
©
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 4
Datawarehouse – Fallbeispiel II
Verschiedene Überwachungsmechanismen können helfen, eine missbräuchliche Nutzung der Dienste der Telefondienstleister zu verhindern. Diese
Analysen müssen unternehmensübergreifend durchgeführt werden.
Überwachungslogiken?
Überwachungslogiken
Kundenstammdaten
Wer hat welche Verträge bei welchem Telefondienstleister
Überwachung der Dienstleistungsnummern
Welche Nummer wird wie oft angerufen
Überwachung der Kunden
Wer nutzt wann und wie lange welche Dienstleistungen
Auffinden von Korrelationen in den oben aufgeführten Analysen!
Und ein Datawarehouse?
Zusammenführung aller Stammdaten (Kunden- und Dienstleisterdaten)
Zusammenführung / Filterung in den Bewegungsdaten (Telefonvorgänge,
Abrechnungen.
Analyselogiken / Clusterung, Mustererkennung, neuronales Lernen.
Und wer betreibt das Datawarehouse?
©
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 5
Datawarehouse Allgemein
©
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 6
Datawarehouse – Allgemein I
Ein Datawarehouse ist eine zentrale Datensammlung (meist eine Datenbank),
deren Inhalt sich aus Daten unterschiedlicher Quellen zusammensetzt. Die
Daten werden von den Datenquellen in das Datawarehouse geladen und dort
vor allem für die Datenanalyse und zur betriebswirtschaftlichen Entscheidungshilfe in Unternehmen langfristig gespeichert. Der Begriff stammt aus dem
Informationsmanagement in der Betriebswirtschaft.
Ein Datawarehouse dient der Informationsintegration.
Der Erstellung eines Datawarehouses liegen zwei Leitgedanken zugrunde:
Integration von Daten aus verteilten und unterschiedlich strukturierten
Datenbeständen, um im Datawarehouse eine globale Sicht auf die Quelldaten und
damit übergreifende Auswertungen zu ermöglichen.
Separation der Daten, die für das operative Geschäft genutzt werden, von solchen
Daten, die im Datawarehouse z. B. für Aufgaben des Berichtswesens, der
Entscheidungsunterstützung, der Geschäftsanalyse sowie des Controllings und der
Unternehmensführung verwendet werden.
Quelle: Wikipedia
©
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 7
Datawarehouse – Allgemein II
Ein Data Warehouse sammelt zentralisiert Daten aus verschiedenen Quellen
und hält diese historisch vor. Es dient als Quelle für Berichte und Analysen, in
denen komplexe Logiken abgebildet sein können. Es ist kein transaktionales
System.
Einsatz eines Data Warehouse für:
• Extraktion und Speicherung von Daten aus verschiedenen Quellen
(SAP FI, MM, IS-H, COPRA, LDS)
• Datenmodellierung (Zusammenführung der Daten aus verschiedenen
Quellen unter einheitlichen Merkmalen: Fall- oder Patientennummer)
• Erstellung von Berichten und Analysen
• Berichtsdistribution
• Überwachungen / Data Mining
Was ein Data Warehouse nicht kann:
• Eingabe / Erzeugen von Stamm- und Bewegungsdaten (kein R/3!!!)
• Anpassungen in den geladenen Stammdaten und Kennzahlen
©
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 8
Datawarehouse – Allgemein III
Das SAP BW Data Warehouse ist unterteilt in einen Berichtsbereich (FrontEnd) zur Anzeige der Daten/Analysen und einen Modellierungsbereich (BackEnd) zur Daten-speicherung.
Aufbau eines SAP BW:
Front-End
- Rollenmenu der verfügbaren Berichte über eine WebSeite
- Web-Anzeige der Berichte im Internet-Explorer
- BEx-Browser: Selektion der Berichte in einem BWTool der SAP-GUI
Back-End
- Speicherung der Stammdaten (Patient, Fall,
Org.Einheit)
- Speicherung der Bewegungsdaten (DRG,
Belegungen) in Cubes
Schnittstellen aus den Umsystemen
UKL: Tägliches Laden der Stammdaten (z.B.
Patienten- und Fallinformationen) sowie der
Bewegungsdaten aus dem IS-H (z.B. Status der
Dokumentation)
©
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 9
Datawarehouse – Allgemein IV
Die Speicherung der Daten in einem Data Warehouse erfolgt in einem
multidimensionalen Schema, in sogenannten Cubes. Stammdaten werden als
Merkmale und Attribute abgelegt, Bewegungsdaten als Kennzahlen mit
zugeordneten Merkmalen.
Anzahl der Abverkäufe
Mehrdimensionale Datenspeicherung im DWH:
Cube
Datencontainer für eine Quelle/ einen Typ Daten,
bspw. Im UKL Bewegungen oder DRG-Abrechnung
Filiale
Merkmal
Zeit
P
kt
u
rod
Beispiel eines einfachen Daten-Cubes für
ein Retail-Unternehmen
©
Stammdatum, welches eine Kennzahl charakterisiert,
bspw. im UKL Patient, Fall, Org.Einheit
Kennzahl
Auch Fluss- oder Bewegungsgröße. Die durch
mehrere Stammdaten beschriebene und einen
Vorgang / eine Buchung beschreibende Zahl,
bspw. im UKL Anzahl Aufnahmen, DRG-Fallzahlen,
Diagnosezählungen
Attribut
Die ein Merkmal weiter beschreibenden Stammdaten,
bspw. im UKL Patient
Geschlecht, Alter
Fall
Aufnehmende fachl. Org.Einheit, Aufnahmeart,
-typ, Patient
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 10
Das Datawarehouse im UKL
©
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 11
Der Bereich Informationsmanagement / SAP
Der Bereich Informationsmanagement betreut mit 30 Mitarbeitern die ITAnwendungen des UKL und unterstützt alle Bereiche bei der Optimierung von
Betriebs- und Geschäftsprozessen.
COPRA
Überwachung Intensivmedizin
MCC
Dokumentation im OP-Bereich
LDS
Labordatensystem
RIS/PACS
Bildspeicherung / -verwaltung
Kommunikationsserver
SAP
SAPim
imUKL
UKL
- Buchhaltung
- Materialwirtschaft
- Patientenverwaltung
- Klinisches Info.-System
SAP R/3
SAP
- FI / CO
- MM
- Apotheke
(MM erweitert)
- IS-H
- IS-H* MED
SAP BW
- - produktiv
produktivseit
seit1998
1998
- - ca.
2.500
Anwender
ca. 2.500 Anwender
- - ca.
ca.800.000
800.000Fälle
Fälle
- - 300
300GB
GBDatenbank
Datenbank
- - Systemund
System- undApplikationsApplikationsmanagement
durch
management durchperdata
perdata
SAP
SAP IS-H und i.s.h.*med bilden den Kern des Krankenhausinformationssystems.
©
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 12
Agenda
In den folgenden Folien wird der Prozess zur Implementierung eines Datawarehouse im UKL sowie der aktuelle Ausbauzustand dargestellt. Es wird ein
Ausblick auf die geplanten Entwicklungsschritte gegeben.
Ein Datawarehouse im UKL – Warum?
Toolselektion und Pilot-Implementierung
SAP BW im UKL heute
Ausblick auf weitere Entwicklungen im Datawarehouse
©
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 13
Ein Datawarehouse im UKL – Warum?
Die Einführung eines Datawarehouse im UKL wurde notwendig, da die
Anforderungen an ein modernes und effektives Berichtswesen nicht durch die
vorhandenen IT-Systeme erfüllt werden konnten.
Anforderungen an das Berichtswesen im UKL:
Aufbau eines abteilungs-, prozess- und systemübergreifenden Berichtswesens
- Konsolidierte Sichten auf medizinische Daten, Finanzen, Controlling und Materialwirtschaft
- Berichtswesen integriert SAP (R/3 und IS-H) sowie Operationsmanagement und Systeme der
Intensivmedizin
Aufbau eines „Single Point of Truth“
Etablierung einer Quelle für Berichte, welche dem Management, den Kliniken und den Fachbereichen
zur Verfügung gestellt werden.
Erhöhung der Qualität in den Berichten
Etablierung eines Berichtswesens, welches nicht vom Tagesgeschäft in den Kliniken und den damit
verbundenen Bewegungen in den IT-Systemen abhängig ist.
Aktualität Datawarehouse: Tagesaktuelle Daten mit einem Versatz von 24 Stunden.
©
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 14
Toolselektion und Pilot-Implementierung (I)
Die Entscheidung zur Einführung von SAP BW als Datawarehouse im UKL
wurde über eine Toolselektion verschiedener Anbieter und die Bewertung von
zwei Prototypen getroffen.
6
Definition
Prototyp UKL
1
Funktionale
Anforderungen
2
Technische
Anforderungen
4
Präsentation
Anbieter
5
Evaluation
Anbieter
(Shortlist)
3
Marktübersicht
(Longlist)
Identifikation von 4 Anbietern mit:
Identifikation von 4 Anbietern mit:
- Datawarehouse inkl. klinischem Reporting
- Datawarehouse inkl. klinischem Reporting
- SAP-Anbindung
- SAP-Anbindung
- Möglichkeit eines flexiblen Reportings
- Möglichkeit eines flexiblen Reportings
©
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 15
7
Aufbau /
Bewertung
Prototyp
8
Finaler
Beschluss
Aufbau von UKL-definierten Prototypen
Aufbau von UKL-definierten Prototypen
durch 2 Anbieter:
durch 2 Anbieter:
- Patientenbewegungen
- Patientenbewegungen
- Operatives Reporting
- Operatives Reporting
Toolselektion und Pilot-Implementierung (II)
Zur Selektion des für das UKL am besten geeigneten Datawarehouse wurde
eine Bewertungsmatrix entwickelt, anhand deren gewichteter Kriterien eine
objektive Toolauswahl durchgeführt werden konnte.
Toolbewertung
Toolbewertung Datawarehouse
Datawarehouse im
im UKL
UKL
Bewertung (zwischen 0 – 15)
0
3
6
9
12
15
Geforderte Funktionalität
Ergonomie
Flexibilität
Systemintegrationsfähigkeit
Preis
SAP BW
Weiterer Anbieter
©
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 16
0
10
20 30 40
Gewichtung (in %)
Toolselektion und Pilot-Implementierung (III)
Die Umsetzung der Pilot-Ausbaustufe des Datawarehouse im UKL wurde in
Zusammenarbeit mit der perdata durchgeführt. Neben der Aktivierung der BWInfrastruktur wurden Datenstrukturen und Berichte im BW aufgebaut.
UKL
perdata
- Definition fachlicher Anforderungen
- Begleitung Umsetzung
- Test der Berichte
- Distribution und Rollout der
Berichte im UKL
- Inbetriebnahme BW,
Anbindung R/3, IS-H
- fachl. und techn. Konzept
- Aufbau Datenstrukturen, Berichte und
Web-Template
Applikationsmanagement
Systemmanagement
Allgemeiner Projektrahmen (Pilotberichte):
Inbetriebnahme des Datawarehouse, Aufbau der Datenstrukturen und Entwicklung der
Berichte
18 Wochen
Inbetriebnahme Pilot im UKL
4 Wochen
Rollout der Berichte in den Kliniken
12 Wochen
©
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 17
SAP BW im UKL heute (I)
Das Datawarehouse im UKL stellt den Kliniken und Fachbereichen ein abteilungsund prozessübergreifendes Berichtssystem zur Verfügung, welches sowohl
medizinische wie betriebswirtschaftliche Kennzahlen umfasst.
„Going Live“ zum 15. September 2005
Gegenwärtige Nutzung in den Kliniken, in den Bereichen Finanzen und
Materialwirtschaft sowie in der Apotheke und im Medizinischen Controlling
Zur Zeit Rollout in den Geschäftsbereichen und Kliniken (ca. 70 Prozent der
Kliniken wurde das Datawarehouse vorgestellt)
Ca. 150 Nutzer zur Zeit, geplante 250 Nutzer nach vollständigem Rollout
Vortagsaktuelles Berichtswesen über das Intranet
©
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 18
SAP BW im UKL heute (II)
In der ersten Phase liegt der Schwerpunkt der Entwicklung im DWH auf der
Erstellung operativer Berichte zu Patientenbewegungen, DRG-Kennzahlen
sowie zur Darstellung der Verbräuche medizinischen Bedarfs.
Berichte im Datawarehouse (I)
Blitzbericht Aufnahmen / Entlassungen
- Wöchentliche Statistik zu den Aufnahmen und Entlassungen in den einzelnen Kliniken
Bericht „Unvollständig verschlüsselte Fälle“
- Statistik zu den entlassenen Fällen, welche aufgrund unvollständiger Bearbeitung im IS-H nicht
abgerechnet werden können (inkl. Auflistung der einzelnen Fälle).
Einweiserstatistik
- Statistik zu den ein- und überweisenden Ärzten und Kliniken (ambulante und stationäre Fälle)
©
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 19
SAP BW im UKL heute (III)
In der ersten Phase liegt der Schwerpunkt der Entwicklung im DWH auf der
Erstellung operativer Berichte zu Patientenbewegungen, DRG-Kennzahlen
sowie zur Darstellung der Verbräuche medizinischen Bedarfs.
Berichte im Datawarehouse (II)
DRG-Statistiken
- Anzahl Fälle mit CMI, CM pro DRG / pro Klinik (Kurz- und Langlieger ausgewiesen)
- Anzahl Fälle mit Liegezeiten im Vergleich zur InEK-Liegezeit pro DRG / pro Klinik
- Zeitliche Entwicklung der Fallzahlen
E-Statistiken
- E1Plus-, E2- und E3-Statistiken
Apothekenberichte
- Hochrechung der aktuellen Apothekenverbräuche auf das gesamte Geschäftsjahr
- Listung der verbrauchten Medikamente
- Zeitliche Entwicklung der Verbrauchszahlen
Berichte „Verbräuche medizinischer Bedarf“
- Pendant der Warenwirtschaft zu den Apothekenberichten
©
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 20
SAP BW im UKL heute (IV)
In der nahen und mittleren Zukunft sind ein Ausbau des klinischen Kennzahlensystems, der Aufbau von Berichten zur Kodierqualität sowie eine Weiterentwicklung des betriebswirtschaftlichen Berichtswesens geplant.
Berichtsthemen in Entwicklung
Medizinische Scorecard
Statistiken ambulanter Fälle
Statistiken zu Diagnosen und Prozeduren
(Anzahl Diagnosen / Anzahl OPs, Prozeduren)
Berichte zur Kodierqualität
Einbindung externer Marktdaten
(VUD, InEK)
©
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 21
SAP BW im UKL heute – Apothekenreporting
In den Apothekenberichten steht den Kliniken eine Hochrechung der aktuellen
Arzneimittelverbräuche auf das GJ sowie verschiedene Auswertungen bis hin
zu einzelnen Medikamenten zur Verfügung.
Apothekenberichtswesen:
Darstellung von Lagerausgängen und Durchläufern
Abbildung der Belieferung externer Häuser durch
das UKL
Abbildung einer 4stufigen Arzneimittelhierarchie
(Aufbau durch die Apotheke)
Hochrechung des Jahresverbrauchs
ABC-Analyse einzelner Medikamente
Arzneimittelverbräuche auf ATC-Code
Zeitliche Entwicklung der Verbräuche
Geplante Entwicklungen:
- Reporting auf Wirkstoffebene
- Kopplung der Arzneimittelverbräuche und Statistiken
zu Zusatzentgelten
©
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 22
SAP BW im UKL heute – Klinisches Reporting
In dem integrierten DRG-Kennzahlensystem wird die Verbindung zwischen
einzelnen Berichten geschaffen. Ausgehend von „high level“-Berichten wird
eine Verfeinerung bis hin zur Fallübersicht im KIS möglich sein.
Integrierte DRG-Statistiken:
Kennzahlen
- Fallzahlen (Langlieger, Kurzlieger, Verlegungen)
- CMI / CM
- Verweildauer
- PCCL
- Unspezifische / DRG-relevante Diagnosen und
Prozeduren
Klinische Scorecard
Verweildauer
CMI / CM
Fallzahlentwicklung
Diagnosen &
Prozeduren
Statistiken einzelner Fälle
(Langlieger / Kurzlieger)
Verfügbar in den Kliniken und Fachbereichen
Integration von Planzahlen und Vorjahresvergleich
Tagesaktuelle Statistiken
Geplante Entwicklungen:
- Verbindung der einzelnen Berichte
- Ausbau der Logik in den Berichten
Fallübersicht im IS-H
©
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 23
Ausblick auf weitere Entwicklungen (I)
Der Ausbau des Datawarehouse im UKL erfolgt auf drei verschiedenen Zeitebenen: einem Ad-hoc-Reporting, einem mittelfristigen Ausbau neuer Berichtsthemen und anhand einer zu erstellenden langfristigen (strategischen) Planung.
Ad-hoc-Reporting
Neue Berichtsthemen
DWH-Planung
Kurzfristiger Aufbau von
Berichten nach Anforderungen
aus den Kliniken / Fachbereichen
Aufbau von Berichten in neuen
Themen / Einbindung neuer
Inhalte aus R/3 und IS-H
Langfristige Planung und
Konzeption neuer Themen im
DWH.
Zeithorizont: 20 Tage
Zeithorizont: 3 – 6 Monate
Zeithorizont: > 6 Monate
Bisherige Projekte:
- Statistiken Verweildauern
- Freier Bericht
Patientenbewegungen
Projekte für die nächsten Monate:
- Warenwirtschaftsreporting
- Berichte für Prozeduren und
Diagnosen
- Analyse offener Forderungen
(Debitorenstatistiken)
- evtl. externe Berichte klinische
Studien
Angedachte Themen:
- Abgleich interne Kosten mit
Kosten nach InEK
- Einbindung HR
- Scorecard im UKL
Perspektivisch in den Händen
der Power-User des UKL
- Personalisierungskonzept DWH
Aufbau eines integrierten Steuerungsreportings im UKL
©
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 24
Ausblick auf weitere Entwicklungen (II)
Der Ausbau des DWH im UKL erfolgt zunächst sowohl in klinikrelevanten wie
auch allgemeinen steuerungsrelevanten Bereichen. Eine Konsolidierung aller
Berichtsthemen wird zu einem integrierten Steuerungsreporting im UKL führen.
Krankenhausreporting:
- Monitoring der abrechenbaren Leistungen
- Qualitätsreporting
- Monitoring Operationen (Planung, Auslastung, Abrechnung)
- Auswertungen nach DRG (Liegezeiten, Bewertungsrelationen)
- Marktanalysen (Patientenbewegungen)
Basisreporting:
- Materialwirtschaftsanalysen
(Einkauf, Warenverbräuche, Verkäufe extern)
- Berichte Kreditoren- / Debitorenbuchhaltung
- Ergebnis-, Leistungs- und Kostenreporting
- HR-Reporting
©
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 25
Aufbau eines
integrierten
Steuerungsreportings im UKL
Ansprechpartner
Ihre Ansprechpartner auf Seiten UKL
Dirk Jaeckel
Bereichsleiter Informationsmanagement
+49 (0)341 15800
dirk.jaeckel@medizin.uni-leipzig.de
Robert Waschipky
Projektleiter Datawarehouse
+49 (0)341 15827
robert.waschipky@medizin.uni-leipzig.de
©
Universitätsklinikum Leipzig – AöR 2006
Bereich Informationsmanagement, Datawarehouse im UKL, 23. Juni 2006, Dr. Robert Waschipky • 26