Lastenheft Data Warehouse

Transkript

1 Lastenheft Data Warehouse Kassenärztliche Vereinigung Saarland Körperschaft des öffentlichen Rechts Europaallee Saarbrücken Telefon: Telefax: Internet:

2 Inhaltsverzeichnis 1. Projektbeschreibung 1.1. Projekteinführung 1.2. Warum ein Data Warehouse 2. Ist-Zustand 2.1. Problemdefinition 2.2. Welche Probleme treten auf 2.3. Unter welchen Bedingungen treten die Probleme auf 3. Soll-Zustand 3.1. Aufbau des Data Warehouse 3.2. Reports 4. Zielkonzeption 4.1. Welche Ziele sollen erreicht werden 5. Anforderungen an Durchführung, Inbetriebnahme und Einsatz 5.1. Prioritäten und Randbedingungen des Projektes 5.2. Zeitlicher Rahmen 5.3. Abnahmekriterien 5.4. Anforderungen an externe Dienstleister Data Warehouse Lastenheft V1.1 Seite 2

3 1. Projektbeschreibung Zunächst werden einleitend die Beweggründe für die Einführung eines Data Warehouse in die Strukturen der Kassenärztlichen Vereinigung Saarland erläutert Projekteinführung Die fortschreitende Digitalisierung bringt eine Flut von Daten unterschiedlichster Art mit sich. Diese Daten werden meist an unterschiedlichen Quellen gespeichert. In diesen riesigen Datenbeständen sind wertvolle Informationen enthalten. Künftig wird der Erfolg des Unternehmens stark von den zur Verfügung stehenden Informationen abhängig sein. Daher sollte entsprechend moderne Technologien eingesetzt werden. Besonders das Management kann von genauen Daten und Analysen profitieren, um zeitnahe Prognosen für die Zukunft zu erstellen, welche den Entscheidungsfindungsprozess oftmals deutlich vereinfachen. Daher ist es für den Erfolg entscheidend, sich für effiziente Datenanalysesysteme zu entscheiden und die operativen Prozesse darauf aufzubauen. Dies ist jedoch eine äußerst umfangreiche Aufgabe. Das Data Warehouse ist eine zentrale Datenbank, in der alle Daten der jeweiligen Bereiche in aufbereitetem Format, zentral archiviert werden. Dazu ist es notwendig Daten aus unterschiedlichsten Quellen mittels ETL-Prozessen (Extraktion/Transformation/Laden) auf ein einheitliches Format zu konvertieren. Das Erstellen des Data Warehouse alleine ist jedoch nicht der größte Teil der Arbeit. Der Focus liegt auch auf dem Analytical Processing. Ein leistungsfähiges Analyse-Tool ist der Motor eines jeden Data Warehouse Systems. Somit sollte eine Synergie dieser beiden Komponenten hergestellt werden, um ein effizientes System herzustellen Warum ein Data Warehouse Aus einer einfachen Datensammlung lassen sich nur schwer Informationen gewinnen. Dafür benötigt man verschiedenste Werkzeuge, welche die Informationen analysieren können. Operative Systeme eines Unternehmens sollten dafür nicht genutzt werden. Ein weiterer Grund warum operative Systeme für entsprechende Analysen nicht geeignet sind, ist der Performance-Verlust. Diese Systeme sind nur zur schnellen Datenverarbeitung konstruiert. Derzeit werden diese Systeme jedoch für Analysen und Abfragen genutzt, was zu langen Laufzeiten führt, da diese Systeme für mehrdimensionale Prozesse nicht konzipiert sind. Bei mehrdimensionalen Abfragen, die zur effizienten Datenanalyse nötig sind, brechen die operativen Systeme ein. Daher sollten relevante Daten in einer separaten Datenbank, ausschließlich für Analysezwecke, gespeichert werden. Die für Analysen relevanten Daten sind derzeit auf verschiedensten Systemen und Inseln verteilt, und nur in unterschiedlichen Formaten verfügbar. Deshalb sollten diese Daten in einem zentralen Datenpool archiviert werden. Data Warehouse Lastenheft V1.1 Seite 3

4 Die Grundlagen eines Data Warehouse sind Zentrale Datenverwaltung Die Daten sind zentral gespeichert und nicht über viele verschiedene Systeme des Unternehmens verteilt. Dies erhöht die Performance und den Überblick. Archivierung der Daten Auch historische Daten, die für die operativen Systeme meist bedeutungslos sind, werden in einem Data Warehouse gespeichert, um den Analysen mehr Aussagekraft zu verleihen. Schneller Zugriff Mehrdimensionale Abfragen auf dem Data Warehouse sind meist schneller als dieselben Abfragen auf den Quellsystemen. Von vielen Benutzern nutzbar Das Data Warehouse sollte von allen Mitarbeitern genutzt werden können. Unabhängigkeit zwischen Datenquellen und Analysesystemen Diese Unabhängigkeit bringt einige Vorteile. Beispielsweise werden die Daten innerhalb des Data Warehouse nicht verändert, sondern nur erweitert, das hat den Vorteil, dass dieselbe Abfrage zu unterschiedlichen Zeiten auch dasselbe Ergebnis liefert. Ein anderer Vorteil ist, dass die Datenanalyse nicht das operative Geschäft der Quellsysteme belastet. Die Vorgehensweise bei der Erstellung eines Data Warehouse ist nicht klar vorgegeben, sondern orientiert sich an den Bedürfnissen des Unternehmens. Beim Erstellen des Data Warehouse hat man die Wahl zwischen verschiedenen Architekturen. Man muss entscheiden welche Architektur für die Bedürfnisse des Unternehmens am geeignetsten ist und am besten zu den bestehenden IT-Systemen passt. Nachfolgend wird die derzeitige Situation der Kassenärztlichen Vereinigung Saarland im Bezug auf die Datenhaltung und die Abfragen geschildert. Data Warehouse Lastenheft V1.1 Seite 4

5 2. Ist-Zustand Wie bereits geschildert, werden die derzeit genutzten operativen Systeme für Datenanalysen/Auswertungen/Abfragen zweckentfremdet. Die genutzten Clients sind für Arbeiten mit bis zum 3,5 Mio. Datensätzen nicht konzipiert. Die Datenbankmodelle der Firma Gradient sind primär auf deren Systeme KV.net (Erstellung der Endabrechnung) und AIS.net (Arztregister) ausgelegt. Diese Datenbankmodelle haben keine multidimensionale Ausrichtung und sind somit beim Abruf von Daten stark eingeschränkt, was unter anderem zu langen Laufzeiten führt. Weiterhin sind die Daten derzeit nicht Zentral archiviert, sondern in verschiedene Bereiche verteilt. Ein zusätzliches Problem ist, dass derzeit auch verschiedene Basissysteme genutzt werden. Hier muss oftmals zunächst eine Kompatibilität hergestellt werden. Die aktuell genutzten Basissysteme können für ein Data Warehouse genutzt werden, sind jedoch in Sachen Performance sehr stark eingeschränkt. Darüber hinaus müssen die Daten aus diesem Modell für eine Auswertung mittels Access oder JasperReports zuerst aufbereitet werden. JasperReports greift wie bereits geschildert auf eine Datenbankstruktur zu, die nicht für eine solche Nutzung konzipiert ist, sodass auch hier lange Laufzeiten entstehen. Diese Aufbereitung ist meist sehr Zeitaufwändig, da Abfragen erstellt und entsprechende ETL-Prozesse durchgeführt werden müssen. Zu unterscheiden ist hierbei jedoch zwischen der Auswertung und der Produktion. Die Berechnungen die von den Referaten Verträge/Honorar/Kostenträger und Abrechnungssteuerung/Datenanalyse durchgeführt werden, können nicht Teil eines Data Warehouse sein, ausschließlich deren Ergebnisse können darin abgebildet werden. Das derzeit genutzte Frontend Jaspersoft bringt den Referaten Verträge/Honorar/Kostenträger und Abrechnungssteuerung/Datenanalyse nicht die notwenige Flexibilität. Die KVS setzt zurzeit im Serverbereich eine Virtualisierung auf der Basis von VMware 5.5 ein. Im Desktop-Bereich wird eine Virtualisierung auf der Basis von Citrix XenDesktop eingesetzt. Die Leistungsfähigkeit der virtuellen Clients muss zur Realisierung dieses Projektes gegebenenfalls angepasst werden. Als Betriebssysteme werden im Serverbereich Microsoft Server 2008 R2 und Microsoft Server 2012 R2 eingesetzt, im Client-Bereich wird Windows 7 Professional in der 32 Bit Version eingesetzt. Zur Softwarebeschaffung im Microsoft-Umfeld besitzt die KVS einen Microsoft Enterprise-Agreement-Vertrag Problemdefinition/Situationsanalyse Die Abrechnungsdatenbank der Kassenärztlichen Vereinigung Saarland, ist derzeit primär für Abrechnungsprozesse optimiert. Die von unseren Mitgliedern gelieferten Daten werden in eine Architektur implementiert, welche für Abfragen und Analysen eher ungeeignet ist. Daher müssen diese Daten mittels aufwändiger ETL-Prozesse (Extraktion/Transformation/Laden) entsprechend umgewandelt bzw. verdichtet werden, um die Daten für Analysen zugänglich zu machen. Diese ETL-Prozesse werden derzeit vor jeder Datenanalyse durchgeführt und sind mit ein Grund, für lange Laufzeiten einzelner Aufträge. Nachfolgend werden die primären Probleme definiert. Data Warehouse Lastenheft V1.1 Seite 5

6 2.2. Welche Probleme treten auf? 1. Überlastung der Hardware (Client s Access) Wie bereits geschildert, sind die operativen Systeme nicht für mehrdimensionale Abfragen geeignet, werden jedoch derzeit für solche Abfragen genutzt. 2. Daten können nicht fristgerecht geliefert werden Durch aufwendige ETL-Prozesse und das erstellen individueller Berichte und notwendiger Datenanalysen, entstehen derzeit vereinzelt Laufzeiten von Stunden. 3. Die notwendigen Daten liegen nicht in der gewünschten Komplexität bzw. Gliederung vor Die Anpassung der Daten muss je Anforderung (Bsp. Berechnung von Altersklassen), die sich auch für gleiche Basisdaten von Auftrag zu Auftrag unterscheiden kann, umgesetzt werden. 4. Komplexität der Auswertungen (einfache/direkte Bereitstellung nicht möglich) bzw. der Auftragsstellung (mehrere Optimierungsstufen) Nach der Bereitstellung der Schnittstellen erfordern teilweise neue Erkenntnisse (auf Basis erster Analysen) die Umstellung der Auswertung. 5. Daten liegen nicht in der gewünschten Form vor, müssen zunächst konvertiert werden Unterschiedliche Datenformate (Bsp. externe Schnittstellen) werden bei Bedarf für die Datenaufbereitung angepasst. 6. Teilweise zeitintensive Datenanalyse notwendig Für einzelne Auswertungen ist die Datengrundlage nicht direkt ersichtlich 7. Speicherplatz oft nicht ausreichend (für unbegrenzte Datenvorhaltung), ggf. Rücksicherung/Neueinlagerung notwendig Die Datenbestände werden turnusmäßig ausgelagert und müssen für länger zurückliegende Datenbestände entsprechend wieder hergestellt werden. 8. Lange Laufzeiten zur Aufbereitung der Schnittstellen Zeitfaktor bei der Erstellung der Schnittstellen (Bsp. mehrere Abrechnungsquartale) 9. Datenhaltung in unterschiedlichen Systemen Oracle / Microsoft Werden unterschiedliche Datenbanksysteme (ggf. auch unterschiedliche Versionen) gehalten, müssen bei Auswertungen spezifische Besonderheiten berücksichtigt werden, was einen zusätzlichen Aufwand darstellt. Data Warehouse Lastenheft V1.1 Seite 6

7 2.3. Unter welchen Bedingungen treten die Probleme auf Wie bereits zuvor geschildert ist die Datenhaltung der KVS nicht für entsprechende Abfragen und Analysen konzipiert, sodass das eigentliche Problem, die Architektur der genutzten Datenbank grundsätzlich besteht. Daraus folgt, dass die grundlegende Problemstellung bedingungsunabhängig Bestand hat. Die Konvertierung von Daten mittels ETL-Prozessen betrifft derzeit jede Abfrage, solange die Abfragen und Analysen auf der Grundlage der derzeit genutzten Abrechnungsdatenbank durchgeführt werden. Durch die nachfolgenden genannten Faktoren kann der Aufbereitungs- und Analyseprozess noch zusätzlich negativ beeinflusst werden. - Zeitgleiche Anfragen aus verschiedenen Bereichen - Daten liegen in gewünschter Form nicht vor - Außerplanmäßige Abfragen (Bspw. während der Abrechnung) - Priorisierung der Terminvorgaben Produktion vs. Auswertung 3. Soll-Zustand Nachfolgend eine Schilderung des gewünschten Ergebnisses Aufbau des Data Warehouse Durch den Aufbau einer gesonderten Datenbank, soll eine Architektur aufgebaut werden, welche schnelle Abfragen und Analysen ermöglicht. Die zentrale Datenhaltung soll es ermöglichen die ETL-Prozesse auf ein Minimum zu reduzieren, da die Daten beim übertragen in das Data Warehouse, in ein einheitliches Format konvertiert werden. Dieser Vorgang sollte beispielsweise einmal wöchentlich automatisiert durchgeführt werden, somit müssen für Abfragen und Analysen keine weiteren ETL-Prozesse mehr durchgeführt werden. Zusätzlich sollten einzelne Bereiche entlastet werden, indem Standardabfragen von den zuständigen Sachbearbeitern direkt abgefragt werden können. Bisher mussten die Auswertungen zunächst bei einem weiteren Sachbearbeiter oder Referatsleiter angefordert werden. Ein weiterer Punkt der zur Verbesserung beitragen könnte, wäre die Nutzung eines zusätzlichen Analysetools. Neben dem derzeit eingesetzten JasperReports, welches als Frontend für Standard-User zum Einsatz kommt, sollte ein weiteres Tool für Power-User die Arbeit deutlich erleichtern, da diese entsprechende Berichte kurzfristig selbständig anpassen könnten, ohne eine Anfrage an die EDV zu stellen Reports Alle Reports werden mit einem Data Warehouse nicht erfüllt werden können. Für individuelle Abfragen werden immer gesonderte Reports durch die EDV erstellt werden müssen. Doch das Groh der Abfragen, die nachfolgend genannten Standardabfragen haben einen Anteil von etwa 75% der derzeit genutzten Reports. Diese Standardabfragen sollen künftig über das Data Warehouse mittels vorprogrammierten Reports jederzeit ohne Aufwand abgefragt werden können. Data Warehouse Lastenheft V1.1 Seite 7

8 Spezifische einmalige Abfragen haben derzeit einen Anteil von etwa 25% der angefragten Reports. Diese Abfragen werden immer durch die EDV bearbeitet werden müssen, da individuelle Berichte erstellt oder Daten aufbereitet werden müssen. Eine Übersicht der derzeit genutzten Standardabfragen ist im Anhang beigefügt (Anlage 1). Die zukünftigen Reports sollten, pixelperfekt erstellt werden können und als Webservice in vorhandene Anwendungen integrierbar sein. 4. Zielkonzeption Die Nachfolgenden Ziele sollten mit der Implementierung eines Data Warehouse in die technischen Strukturen der KVS erreicht werden Welche Ziele sollen erreicht werden Primärziele (obligat) 1. Ad hoc Datenzugriff Den jeweiligen Mitarbeitern sollte der direkte Zugriff auf die relevanten Daten ermöglicht werden, ohne einen Auftrag an die EDV oder das Referat Abrechnungssteuerung/Datenanalyse zu erteilen. 2. Zentrale Datenhaltung (bis auf Fall-/Patientenebene) Die derzeit fragmentierte Datenhaltung auf mehreren Systemen, soll auf eine Datenquelle reduziert werden. 3. Hohes Maß an Automatisierung Die notwendigen Prozesse wie Datenübertragung in das Data Warehouse oder Datensicherung, sollten automatisiert werden, um einen Mehraufwand in der EDV möglichst zu vermeiden. Komplementärziele 1. Datenanalyse / Auswertung in time (Rechenlaufzeiten reduzieren) Durch eine einheitliche Datenhaltung, sollte die Laufzeiten von Auswertungen und Analysen deutlich reduziert werden, da ggf. zeitaufwändige ETL Prozesse wegfallen und aufgrund des einheitlichen Formates - keine Kompatibilitätsprobleme auftreten. Sekundärziele (fakultativ) 1. Modernisierung der technischen Infrastruktur Durch den Einsatz neuer Hard- und Software in Verbindung mit einer zeitgemäßen Datenhaltung, soll die technische Infrastruktur dem Stand der Technik entsprechend modernisiert werden. Data Warehouse Lastenheft V1.1 Seite 8

9 2. Unabhängigkeit zwischen Datenquelle und Analysesystemen Die Architektur einer entsprechenden Datenquelle sollte so geschaffen werden, dass mit verschiedenen Analysesystemen darauf zugegriffen werden kann. 3. Von allen Mitarbeitern nutzbar sein Auf Dauer sollte solch ein Data Warehouse für alle Mitarbeiter denen ein Mehrwert durch die Nutzung entsteht, nutzbar gemacht werden. Darüber hinaus sollte eine zeitgleiche Nutzung eines Reports durch mehrere Mitarbeiter möglich sein. 5. Anforderungen an die Durchführung, Inbetriebnahme und Einsatz Durch die Etablierung eines Data Warehouse in den Strukturen der KVS, kann eine deutliche Erleichterung sowohl im operativen Geschäft als auch bei der strategischen und mittelfristigen Planung bewirkt werden. Bei der Entwicklung sollte der Fokus nicht nur auf dem Data Warehouse selbst, sondern auch auf den dazugehörigen Analysetools und der Zugrunde gelegten Software/Betriebssystemen liegen. In diesem Zusammenhang wäre auch ein schrittweiser Aufbau des Data Warehouse empfehlenswert, um auch letztendlich auf die erzielten Erkenntnisse kurzfristig in den einzelnen Projektphasen zu reagieren. Die aktuellen Informationsquellen XXSUM und GNR-Anzahlstatistik müssen zunächst abgebildet und bereits frühzeitig in der Einführungsphase (Test, Schulung) eingebunden werden, was dazu führt das bereits frühzeitig eine erhebliche Arbeitserleichterung/Mehrwert erzeugt wird. Weitere unkritische Schnittstellen (Bspw. Honorarstatistik) müssen nach und nach folgen. Die eher zeitkritische und sicherlich auch aufwändige Abbildung der Abrechnungsdatenbank mit Patientenbezug BatchDatabase, der Honorarabrechnung mit BHT-Bezug und die Datenbestände im Rahmen der Kassenrechnung (VDX) sollten die Projektumsetzung zunächst abschließen. Ein wichtiger Aspekt für den Erfolg des Projektes wird es sein, sowohl die DBA s in Bezug auf den Datenbankaufbau, als auch die Anwender in Bezug auf die Nutzung des Data Warehouse zu schulen. Das Data Warehouse sollte soweit automatisiert werden, damit der personelle Mehraufwand nur partiell entsteht Prioritäten und Randbedingungen des Projektes Die Priorität des Projektes ist es, ein funktionierendes Data Warehouse aufzubauen, um die KVS interne Datenhaltung und die Arbeitsabläufe in Bezug auf Datenauswertungen und Datenanalyse zu optimieren. Darüber hinaus gilt es die definierten Ziele entsprechend umzusetzen. Da ein Data Warehouse sehr vielseitig nutzbar ist, sind Grenzen schwer zu definieren. Es ist immer auch eine Frage des monetären Aufwandes der betrieben werden kann und welchen Nutzen das Endprodukt erzeugt. Als Ausblick wäre im Anschluss an die Fertigstellung, eine Nutzung des Data Warehouse auch auf mobilen Endgeräten oder im Sharepoint möglich. Data Warehouse Lastenheft V1.1 Seite 9

10 5.2. Zeitlicher Rahmen Der Zeitansatz für die Entwicklung eines Data Warehouse beträgt 24 Monate. Das Projekt sollte dabei in drei Phasen gegliedert sein. Erste messbare Erfolge sollten bereits nach 6 Monaten erreicht sein Abnahmekriterien Der Maßstab für den Erfolg des Projektes sollte neben der Einhaltung der monetären und zeitlichen Planung auch die Realisierung der definierten Ziele sein. Darüber hinaus sollte das Data Warehouse so gestaltet sein, dass die in Anlage 1 definierten Standardabfragen abgebildet werden können. Die Konsequenz bei Nichteinhaltung der monetären oder zeitlichen Planung ist, dass das Projekt fehlgeschlagen ist. Gleiches gilt für die Nichteinhaltung der definierten Ziele Anforderungen an externe Dienstleister Grundvoraussetzung ist die Kompetenz in Sachen Business Intelligence und Data Warehouse. Diese Bereiche sollten zu den Kernkompetenzen eines externen Dienstleister gehören und darüber hinaus mit entsprechenden Referenzen belegt werden können. Weitere Anforderungen an einen externen Dienstleister lauten wie folgt. Bewerber sollten im Bereich CITRIX XEN Desktop, VMWARE und Microsoft zertifiziert sein. Weiterhin wäre ein Partnerstatus bei Microsoft, Partnerstatus bei VMWare-Enterprise und eine XEN-Desktop-Kompetenz Zertifizierung wünschenswert. Bewerber sollten langjährige Erfahrung im Durchführen von Schulungen im BI-Umfeld haben und 5 Referenzen benennen können. Grundsätzlich sollte der Bewerber Referenzen von vergleichbaren BI- Projekten (> 50 Manntagen, mind. 200 User) nachweisen können und auch hier 5 Referenzprojekte beschreiben. Data Warehouse Lastenheft V1.1 Seite 10