BUDOWA MODELI WYMAGAŃ DLA REGIONALNYCH SYSTEMÓW INFORMACJI MEDYCZNEJ OPARTYCH O HURTOWNIĘ DANYCH

Transkrypt

1 Dr Jerzy ROSZKOWSKI 1 BUDOWA MODELI WYMAGAŃ DLA REGIONALNYCH SYSTEMÓW INFORMACJI MEDYCZNEJ OPARTYCH O HURTOWNIĘ DANYCH Wstęp Definiowanie wymagań biznesowych oraz wymagań na system jest fundamentalną rzeczą dla przyszłych jego uŝytkowników. Ze względu na coraz bardziej skomplikowaną architekturę systemów i sposób ich wytwarzania często nie jest wystarczający sam opis słowny konieczne jest stworzenie odpowiednich modeli. W artykule na przykładzie wymagań na Systemy Informacji Medycznej pokazano jak przełoŝyć skomplikowane zaleŝności pomiędzy elementami wymagań na system na powiązany zestaw modeli umoŝliwiający odzwierciedlenie zaleŝności pomiędzy nimi oraz mierzalność samych wymagań. 1. Potrzeba zbudowania Regionalnych Systemów Informacji Medycznej (RSIM). Definicja RSIM Potrzeba zbudowania RSIM wynika z bezpośrednio z Ustawy o Samorządzie Terytorialnym 2. Zgodnie z tą ustawą: samorządy przejęły rolę organu załoŝycielskiego samodzielnych publicznych zakładów opieki zdrowotnej, przeniesiono na samorządy obowiązek planowania i realizacji lokalnej polityki zdrowotnej. W związku z pełnieniem przez samorządy roli organu załoŝycielskiego, szczegółowe ich kompetencje w tym zakresie wynikają z Ustawy o Zakładach Opieki Zdrowotnej i są regulowane rozporządzeniem Ministra Zdrowia. Zakres funkcjonalny tych kompetencji jest pokazany na rysunku 1. Zakres ten sprowadza się do sprawowania funkcji organu załoŝycielskiego samodzielnych publicznych zakładów opieki zdrowotnej. Ustawa o zakładach opieki zdrowotnej wylicza szczegółowo funkcje związane z pełnieniem roli organu załoŝycielskiego, a mianowicie: nadzór nad zakładami, zatwierdzanie statutów, prowadzenie spraw związanych z zatrudnianiem kierowników zakładów, planowanie prowadzenie i nadzór nad realizacją zadań inwestycyjnych, sprawowania przez samorządy funkcji planowania i realizacji lokalnej polityki zdrowotnej. Do wypełnienia tych zadań potrzebna jest budowa Regionalnych Systemów Informacji Medycznej spełniająca następujące wymagania: 1 Management Systems Consulting, Łódź, Poznańska 28/1. jerzy.roszkowski@neostrada.pl. Autor współpracował w latach jako ekspert zewnętrzny z Urzędem Marszałkowskim w Łodzi przy budowie wymagań i przetargach na Regionalny System Informacji Medycznej. 2 Ustawa o samorządzie województwa z dnia 5 czerwca 1998 r. (Dz. U. z 2001 r., Nr 142, poz j.t., ze zmianami. Ustawa o statystyce publicznej z dnia 29 czerwca 1995r. (Dz. U. z 1995 r., Nr 88, poz. 439, ze zmianami) 1

2 Organ załoŝycielski Planowanie i realizacja polityki zdrowotnej Samorząd Funkcja nadzoru i kontroli nad zakładami OZ Zatwierdzanie statutów Zatrudnianie Kierowników Obsługa zadań inwestycyjnych Kontrola realizacji zadań statutowych Kontrola prawidłowości gospodarowania mieniem Kontrola gospodarki finansowej Rys. 1. Kompetencje samorządów w zakresie realizacji polityki zdrowotnej jako procesy biznesowe. Źródło: Opracowanie własne zaprojektowania i wdroŝenia regionalnej platformy integrującej dane z placówek ochrony zdrowia z terenu województwa, platformy wykorzystującej technologię hurtowni danych, kontynuacji procesu informatyzacji samorządowych placówek ochrony zdrowia, związanego z koniecznością uporządkowania i wystandaryzowania systemów informatycznych istniejących w ZOZ, aby w ten sposób moŝliwe było jak najefektywniejsze elektroniczne ładowanie danych do regionalnej hurtowni danych. 2. Model formalny wymagań dla Regionalnych Systemów Informacji Medycznej Budowa tego rodzaju modeli dotyczących wymagań do tej pory zazwyczaj oparta była o model przypadków uŝycia biznesowych i systemowych (Use Case) wywodzący się z UML. To podejście jest prawidłowe jednak niekompletne poniewaŝ przypadek uŝycia reprezentuje tylko jedną perspektywę (widok) systemu informatycznego oparty o widoczną funkcjonalność systemu dla uŝytkownika końcowego. Reprezentowane w tym artykule podejście zakłada budowę wielowymiarowego i wielokryterialnego modelu (bądź modeli wymagań) będącego w swej istocie grafem skierowanym bądź teŝ zbiorem wzajemnie powiązanych grafów. Zwykle wymiarami tego modelu są róŝne widoki systemu np.: techniczny, architektury, funkcji biznesowych, bazy wiedzy. Graf taki pokazuje rysunek 2. 2

3 V 1 V 2 V 3 V 4 V 5 V 6 V 7 V 8 V 9... V n Rys. 2.Ogólny model wymagań jako graf skierowany z wartościami mierzalnymi (punktowymi) wymagań w węzłach. W węzłach grafu wpisana być powinna specyfikacja wymagania oraz przydzielona liczba punktów za to wymaganie wynikającą z jego wagi i roli. Z jednej strony punkty te przydziela zamawiający system traktując je jako maksymalną liczbę punktów za konkretne wymaganie węźle moŝliwą do osiągnięcia. Z drugiej strony kaŝda oferta potencjalnych wykonawców jest oceniana w ten sam sposób. Za opis jak konkretne wymaganie będzie spełnione przez wykonawcę przydziela się konkretną liczbę punktów nie większą niŝ w modelu przedstawionym przez zamawiającego. Zamawiający szuka najlepszej oferty, a zatem szuka wykonawcy, który zdobędzie największą liczbę punktów. Z punktu widzenia formalnej teorii grafów model pokazany na rysunku 2.1 moŝe być przedstawiony w postaci tzw. macierzy incydencji [lit.1] przedstawionej formułą (2). Znalezienie najlepszej oferty z punktu widzenia macierzy incydencji, w której zarejestrowane są wymagania oznacza spełnienie następującej formuły: Max ΣV ij (1) o i O i=j ID 1 ID 2 ID 3 ID 4 ID 5 ID 6 ID 7 ID 8 ID 9 ID n ID 1 v v 1n ID 2 1 v v 2n ID v v 3n ID v v 4n [V ij ]= ID v v 5n ID v v 6n ID v v 7n ID v 8 0..v 8n ID v 9..v 9n.. ID n v n1 v n2 v n3 v n4 v n5 v n6 v n7 v n8 v n9 v nn (2) 3

4 Wartości ID 1,,ID n oznaczają identyfikatory węzłów, macierzy incydencji, - kwantyfikator ogólny, o i oznacza ofertę klienta, naleŝącą do zbioru ofert O rozpatrywanych w procedurze przetargowej, sumowanie jest po wszystkich wartościach wymagań V ij wpisanych w węzłach dla danej. Jedynki w macierzy incydencji oznaczają fakt, Ŝe odpowiednie węzły oznaczone identyfikatorami są ze sobą połączone w grafie modelu wymagań, natomiast, dla połączeń węzłów samych z sobą (znajdujących sie na przekątnej macierzy wpisano wartości punktowe wymagań. Zakłada się niewystępowanie pętli własnych w tym grafie tzn strzałek wychodzących i następnie wchodzących do tego samego węzła. 3. Model rzeczywisty wymagań dla Regionalnych Systemów Informacji Medycznej (przykłady) PoniŜej przedstawiono kilka przykładów z rozwiniętego modelu wymagań. Szczegóły opracowane przez autora moŝna znaleźć w specyfikacji wymagań na RSIM 3. Jako narzędzie i architekturę modelowania wykorzystano IDS Scheer ARIS 4 [lit.5,6]. Model został przedstawiony jako diagram typu eepc (Event-driven Process Chain). Wykonawcy powinni opisać w swoich ofertach jaki sposób zamierzają spełnić wszystkie przedstawione w modelu wymagania zachowując przedstawiony w modelu podział na ich kategorie i rodzaje. Niektóre z wymagań przedstawionych dają się dekomponować na bardziej szczegółowe, co zostało przedstawione w postaci modeli cząstkowych będących rozwinięciem wymagania bazowego, które w tym wypadku jest korzeniem drzewa wymagań. Rysunek 3 pokazuje główny model wymagań. RSIM będzie umoŝliwiał zagregowane raportowanie danych przechowywanych w systemach informatycznych podmiotów raportujących. Docelowa hurtownia danych będzie zasilana z systemów źródłowych, przy załoŝeniu, Ŝe dane będą udostępniane w postaci plików płaskich z częstotliwością nie częściej niŝ raz na tydzień. Przedstawiona tutaj koncepcja modelowania wymagań i architektury Jest w pełni zgodna z TOGAF 5, Schemat tworzenia architektury zgodnej z tym standardem pokazano na rysunku 3. WyŜej wspomniana metodologia ARIS jest zgodna z TOGAF. 3 Specyfikacja wymagań na RSIM, dokumentacja przetargowa Urząd Marszałkowski w Łodzi, 2008 r 4 ARIS - ang. Architecture of Integrated Information Systems, metodologia architektury i narzędzia rozwijane przez firmę IDS Scheer 5 TOGAF ang. The Open Group Architecture Framework szkielet dla architektury korporacyjnej, który zapewnia kompleksowe podejście do projektowania, planowania, implementacji oraz zarządzania informacyjną architekturą przedsiębiorstwa. Architektura jest modelowana typowo na czterech poziomach (domenach): Procesy biznesowe, Zastosowanie, Dane, Technologia. Grupa The Open Group udostępnia specyfikację TOGAF bezpłatnie dla organizacji do ich własnego, niekomercyjnego wykorzystania. 4

5 Rys 3. Schemat budowania architektury korporacyjnej TOGAF sterowany wymaganiami. Źródło: 4. Model rzeczywisty wymagań: wymagania na architekturę aplikacji i architekturę informacyjną PoniŜej w celach prezentacyjnych pokazano kilka rozwinięć modelu. Pełna jego wersja znajduje się w specyfikacji wymagań na RSIM. Wymagana architektura aplikacji i architektura informacyjna jest rozwinięciem węzła AI-01 głównego modelu wymagań z rysunku 4. Węzeł ten moŝe być reprezentowany jako kolejny graf typu drzewo (niŝszego poziomu). Jego reprezentacja jest pokazana na rys. 5 w postaci diagramu aplikacji i rys. 6 w postaci modelu wymagań na architekturę informacyjną. Projekt systemu RSIM wynikający z modelu wymagań powinien uwzględniać następujące cele informacyjne, funkcjonalne, technologiczne i techniczne: informatyzacja i wspieranie podstawowych procesów w zakresie gromadzenia, analizy i raportowania danych, gromadzenie w hurtowni danych i udostępnianie informacji niezbędnych do wypełnienia ustawowych funkcji uŝytkowników systemu. Informacje te powinny być cyklicznie pozyskiwane z systemów działających w zewnętrznych podmiotach raportujących, za pośrednictwem plików płaskich o ściśle określonej strukturze zdefiniowanej przez Wykonawcę. Docelowo w wersji eksploatacyjnej RSIM do plików tych informacje będą cyklicznie ładowane przez podmioty raportujące, 5

6 moŝliwość zaawansowanej analizy wielowymiarowej posiadanych informacji za pośrednictwem narzędzi klasy bussines intelligence, informatyczne wspieranie funkcji planowania i prognozowania. AI-01 CB-01 Struktura celów biznesowych Zamówienia Architektura informacyjna aplikacji WYMAGANIA OGÓLNE BW-06 Wymagania podmiotowoprzedmiotowe Metodyka modelowania procesów biznesowych BW-01 WO-01 RSIM Metodyka modelowania HD BW-02 WYMAGANIA TECHNICZNE I TECHNOLOGICZNE WT-01 Obsługa administracji systemem WYMAGANIA BIZNESOWE Obsługa bazy normatywnej Metodyka modelowania procesów systemowych (przetwarzania danych) BW-03 WT-02 Architektura techniczna systemu RSIM WB-01 Prawo miejscowe BW-04 WT-03 Funkcje Techniczne ETL Obsługa zarządzania procesem wytwórczym WB-03 Metodyka zarządzania projektem BW-05 WT-04 WT-05 Obsługa modelowania hurtowni danych Funkcje techniczne narzędzi raportowania Architektura biznesowa WB-02 Obsługa wymagań biznesowych raportowania WB-04 WT-06 Funkcje techniczne SZBD WO-02 Licencjonowanie oprogramowania LEGENDA Kategorie obiektów Funkcja techniczna IT Funkcja biznesowa Wiedza udokumentowana Kategoria wiedzy Klaster informacyjny Obiekt biznesowy Atrybut eerm (opisujący) Cel Rys. 4. Główny model wymagań na Regionalny System Informacji Medycznej. Źródło: Opracowanie własne 6

7 Jednostki ZOZ Aplikacje ZOZ NFZ SZBD ETL Aplikacja ETL Urząd Marszałkowski RSIM Hurtownia Danych Narzędzia analiz i raportowania analitycznego Pracownik Uprawniony Urzędu Marszałkowskiego Internet Portal z klientem internetowyn Pracownik uprawniony ZOZ Rys. 5. Ogólny schemat architektury docelowego systemu RSIM jako Diagram aplikacji ARIS. Źródło: Opracowanie własne Architektura systemu RSIM przedstawiona na rysunku 4 powinna składać się czterech warstw : źródeł udostępniających dane do pobrania za pośrednictwem plików płaskich, narzędzi ETL i aplikacji zbudowanej w środowisku ETL słuŝących do pobierania danych ze źródeł udostępnionych przez podmioty raportujące podmiotów raportujących, czyszczenia oraz ładowania pobranych danych do hurtowni danych, hurtowni danych będącej instancją bazy danych funkcjonującą w środowisku systemu zarządzania bazą danych, narzędzi raportowania wielowymiarowego, zawierających mechanizmy drąŝenia danych i data mining. Część warstwy pierwszej w postaci źródeł jest określona dla Wykonawcy (zakłady opieki zdrowotnej posiadają juŝ własne systemy i aplikacje). Prototyp RSIM powinien być systemem zintegrowanym informacyjnie i funkcjonalnie. Prototyp systemu RSIM powinien mieć następujące cechy funkcjonalne: dostęp do większości funkcji RSIM (określonych w zaleŝności od zaproponowanego rozwiązania technologicznego Wykonawcy) z poziomu przeglądarki internetowej (po uwzględnieniu odpowiednich uprawnień dostępu), przy czym Zamawiający wymaga by był zapewniony dostęp przeglądarkowy do funkcji raportowania, architektura wielowarstwowa z uwzględnieniem tzw. cienkiego klienta. 7

8 Architektura informacyjna docelowa RSIM AI-0101 Informacje o kostce Modele referencyjne przetwarzana danych Ŝródłowych Tabela hierarchii Tabela faktów Wymiary Tabele danych źródłowych Struktura przepływów i mapowanie Struktura transferu (pliki płaskie) Atrybut eerm (klucz) Atrybut eerm (opisujący). Rys. 6. Obiekty architektury informacyjnej w modelu wymagań. Źródło: Opracowanie własne Model wymagań na architekturę informacyjną reprezentowany na rys. 6 składa się z dwóch gałęzi. Gałąź lewa pokazuje wymagania na hurtownię danych, która składać się ma z wielowymiarowych kostek, kaŝda reprezentowana przez tabele faktów i wymiary opisane przez atrybuty. Gałąź prawa opisuje wymagania na aplikację ETL (ang. Extraction Transformation Load) słuŝącą ekstrakcji, transformacji i ładowaniu danych z aplikacji źródłowych. Do budowy tej aplikacji potrzebna są: struktura tabel źródłowych, z których pobierane są dane (ekstrakcja), struktury danych docelowych (pliki płaskie), mapowanie danych źródłowych na dane docelowe. 5. Architektura aplikacji i architektura informacyjna przykład rozwiązania technicznego PoniŜej na rysunku 7 pokazano mapowanie ogólnej architektury RSIM na strukturę organizacyjną (w zakresie obsługi danych związanych z usługami medycznymi). Przykładowym rozwiązaniem moŝe być rozwiązanie oparte o system zarządzania bazą danych Oracle 10g oraz narzędzie raportowania klasy business intelligence Business Objects XI. [lit. 9] Architektura takiego rozwiązania RSIM składa się z 4 warstw: źródeł danych w postaci bazy sprawozdań, aplikacji Oracle Warehouse Builder (OWB) do ekstrakcji i czyszczenia danych z bazy sprawozdań ładowania ich do plików płaskich, a nastepnie do hurtowni danych, Centralnej Hurtownia Danych oparta o platformę Oracle 10g, narzędzi do przetwarzania analitycznego i raportowania w postaci Business Objects Enterprise XI. 8

9 ODDZIAŁ SZPITALA Dane do raportów Aplikacja Dedykowana (zarządzanie szpitalem) Dane do rozliczeń Pakiet Świadcze -niodawcy Plik XML Oddział NFZ Dodatkowe usługi dla nieubezpieczonych dodać Przeliczenie z układu świadczeń na układ l. pacjentów Rejestr RZOZ Urząd Marszałkowski jest technicznie odpowiedzialny za *.XLS RSIM Narzędzie Raportowania Raport dedykowany jest uŝytkownikiem Dział Statystyki szpitala Rys. 7. Mapowanie architektury docelowego RSIM (część wyszarzana rysunku) na strukturę organizacyjną. Źródło: Opracowanie własne Poglądowy rysunek tej architektury pokazuje rysunek 8. Rys. 8. Poglądowy rysunek ogólnej przykładowej technicznej architektury dla RSIM. Źródło: Opracowanie własne 9

10 Szczegółowy opis rozmieszczenia poszczególnych komponentów rozwiązania następnym rysunku. zamieszczono na Rys.9. Szczegółowa, poglądowa, przykładowa architektura HD dla RSIM. Źródło: Opracowanie własne. W proponowanym przykładowym rozwiązaniu naleŝy wyróŝnić dwa szczególne obszary: obszar hurtowni danych z narzędziami ETL do pobierania i transformacji danych z bazy sprawozdań, obszar raportowy - do prowadzenia analiz, budowy raportów i graficznej prezentacji danych. W przykładowym rozwiązaniu zakłada się, Ŝe będzie to hurtownia danych oparta na kostkach wielowymiarowych typu ROLAP (oparta na relacyjnej strukturze tablic). W szczególnych przypadkach, dla niektórych obszarów biznesowych moŝna zastosować tworzenie kostek wielowymiarowych typu MOLAP. W obrębie przestawionej powyŝej platformy raportowej Business Objects realizowane są następujące funkcje: Portal Business Intelligence (InfoView) scentralizowany i personalizowany dostęp dla uŝytkowników platformy poprzez sieć internetową. Personalizacja i odpowiednie 10

11 mechanizmy bezpieczeństwa gwarantują udostępnianie właściwej informacji właściwym osobom bez niebezpieczeństwa, iŝ trafi ona w niepowołane ręce. usługi raportowania elastyczne podejście do raportowania umoŝliwia uŝytkownikom zarówno korzystanie z gotowych raportów, jak i tworzenie własnych zestawień i zapytań do baz danych (WebIntelligence, Desktop Intelligence). Bogate moŝliwości swobodnego formatowania pozyskanych informacji zwiększają ich czytelność i prawidłową interpretację, usługi analityczne (Web Intelligence, Desktop Intelligence, Predictive Analysis, Set Analysis) umoŝliwiają uŝytkownikom zrozumienie nie tylko tego, co dzieje się w biznesie, ale takŝe gdzie, kiedy i jak. Wykorzystanie analiz wielowymiarowych pozwala wyjść od zestawień ogólnych i następnie zagłębiać się w szczegóły poprzez opcję drąŝenie danych (drill down), pulpity kierownicze (Dashboard Manager) dają moŝliwość koncentrowania się na wybranych kluczowych zagadnieniach biznesowych i szybkiej oceny sytuacji, usługi data mining (Set Analysis) odkrywanie korelacji, wzorców i trendów w danych z systemów transakcyjnych, jak np. wpływ poszczególnych czynników na zyskowność, strukturę kosztów czy ocenę wydajności, narzędzia współpracy (InfoView, Encyclopedia, panele dyskusyjne) tworzą miejsce swobodnej wymiany informacji pomiędzy uŝytkownikami, dają lepsze zrozumienie oraz właściwą interpretację prezentowanych wyników. Istotna jest moŝliwość przełączania się pomiędzy poszczególnymi narzędziami (odpowiedzialnymi za poszczególne funkcje) i dzięki temu osiąganie optymalnych rezultatów pracy z informacją (np. analizy wychodzące od znacznego poziomu ogólności a zakończone szczegółowym raportem dotyczącym jednego konkretnego zagadnienia). 6. Podsumowanie Koncepcja RSIM jest w ciągłym rozwoju. Szczegółowe informacje dotyczące jej rozwoju i zdarzeń z tym związanych moŝna znaleźć na stronach internetowych RSIM - Łódź. 6. Zastosowanie do niej zaawansowanego modelowania wymagań zgodnego zarówno z koncepcją architektury korporacyjnej (TOGAF) oraz z architekturami zgodnymi z tą koncepcją (ARIS) pozwala uporządkować wszystkie rodzaje wymagań i uczynić je mierzalnymi w sensie podanym w punkcie 2. Powinno to takŝe się przyczynić do usprawnienia procedur przetargowych poprzez zmniejszenie liczby protestów poniewaŝ tak przedstawione wymagania stają się bardziej zrozumiałe dla przyszłych wykonawców i pozwalają składać w ofertach propozycje rozwiązań bardziej zgodnych z oczekiwaniami zamawiającego przedstawionymi właśnie za pomocą takich modeli. LITERATURA: [1] DEO. N., Teoria grafów i jej zastosowania, PWN, [2] JACOBSON I., Object Oriented Software Engineering, Addison-Wesley Publishing Company, 1995, ISBN: [3] ROSZKOWSKI J., Analiza i projektowanie strukturalne, Helion, 2004, ISBN: [4] ROSZKOWSKI J., The Formal Approach to Definition of the Requirements for the Needs of Computer Application Selection and Implementation, Proc. of the 16th International Conference on Systems Science ICSS'07, 2007 [5] SCHEER A. W.: Business Process Modeling, Springer-Verlag, Berlin, Heidelberg,New York, 2000, ISBN: [6] SCHEER A.W., Business Process Engineering, Springer-Verlag, Berlin, Heidelberg, New York, 1994,

12 ISBN: [7] SIPSER M., Introduction to the Theory of Computation, An International Thompson Publishing Company, Boston, 1997, ISBN: X. [8] TOGAF Version Enterprise Edition, 2007, ISBN: Van Haren Publishing. [9] BUSINESS OBJECTS DEVELOPER LIBRARY, 2006 Business Objects SA 12