Specyfikacja techniczna DOTYCZĄCA UMOWY NA DOSTAWĘ OPROGRAMOWANIA NA POTRZEBY PROJEKTU POPRAWA DOSTEPNOŚCI I JAKOŚCI USŁUG MEDYCZNYCH W RAMACH POPULACYJNEGO PROGRAMU WCZESNEGO WYKRYWANIA RAKA PIERSI 1
1. Słownik pojęć i skrótów Tabela 1. Skróty i pojęcia użyte w dokumencie wraz z objaśnieniami. Lp. Pojęcie/skrót Objaśnienie 1 Beneficjentka Beneficjentka PPWWRP 2 CAL Client Access License 3 4 CD CRM Centrum dostępów narzędzie do zarzadzania uprawnieniami użytkowników do aplikacji stosowane przez Zamawiającego Customer Relationship Management w tym wypadku system do wspierania zarządzania relacjami z klientami. 5 Dzień roboczy Osiem godzin roboczych 6 DMS Document Management System narzędzie wykorzystywane przez zamawiającego do zarządzania szablonami dokumentów oraz dostarczaniem dokumentów do odbiorców z wykorzystaniem różnych kanałów dostępu. 7 Dostawca Wykonawca 8 9 ewuś System NFZ służący do elektronicznej weryfikacji uprawnień świadczeniobiorców Godzina robocza Okres trwający godzinę zegarową w ramach Godzin pracy Zamawiającego. 10 11 Godziny pracy Zamawiającego LDAP Od godziny 8:15 do 17:00, od poniedziałku do piątku, z wyłączeniem dni ustawowo wolnych od pracy. Lightweight Directory Access Protocol (LDAP) protokół przeznaczony do korzystania z usług katalogowych, bazujący na standardzie X.500. Jest to również nazwa usługi katalogowej pozwalającej na wymianę informacji za pośrednictwem TCP/IP. W tym wypadku ActiveDirectory 2
12 13 14 15 16 PPWWRP Projekt RIS SLA SIMP Populacyjny Program Wczesnego Wykrywania Raka Piersi realizowany przez oddziały wojewódzkie Narodowego Funduszu Zdrowia Projekt Poprawa dostępności i jakości usług medycznych w ramach Populacyjnego Programu Wczesnego Wykrywania Raka Piersi współfinansowany ze środków Mechanizmu Finansowego EOG i Norweskiego Mechanizmu Finansowego realizowany przez LUX MED. Diagnostyka Sp. z o.o.. Radiology Information System w tym wypadku system Medicom wykorzystywany przez Zamawiającego jako podstawowy system medyczny w zakresie dotyczącym Projektu. Service Level Agreement umowa dotycząca poziomów jakościowych usług System Informatyczny Monitorowania Profilaktyki - system NFZ obsługujący sprawdzenie uprawnień beneficjentki, rejestrację świadczeń, rejestrację wyników badań i rozliczenia z NFZ System Zamawiane narzędzie informatyczne opisany w niniejszym opracowaniu. Przez System należy rozumieć całość przedmiotu zamówienia, a w tym: 17 a. system informatyczny, dla którego wymagania opisano w niniejszym dokumencie; b. interfejsy i integracje wymagane do prawidłowego działania zamawianego narzędzia; c. Licencje wymagane przez System. 18 UAT User Acceptance Tests testy akceptacyjne. 19 UML Unified Modeling Language standardowy język modelowania (notacji) elementów architektury systemów informacyjnych. 20 Umowa Umowa, która zostanie podpisana na realizację niniejszego Zamówienia. 21 Wykonawca Podmiot, który ubiega się o wykonanie Zamówienia, złoży ofertę na jego wykonanie, albo zawrze z Zamawiającym Umowę w sprawie wykonania Zamówienia. 3
22 Zamawiający LUX MED. Diagnostyka Sp. z o.o. 23 Zamówienie Zamówienie publiczne, którego przedmiot w sposób szczegółowy został opisany w niniejszym dokumencie. 2. Organizacja projektu Dostarczenie systemu realizowane będzie w trybie projektowym, co oznacza, że wszelkie działania kontrolowane będą przez powołany do jego kierowania zespół. Zakłada się, że po stronie Zamawiającego i Dostawcy do kontroli i zarządzania projektem powołani zostaną Kierownicy Projektu, a sam projekt prowadzony będzie zgodnie z metodyką obowiązującą u Zamawiającego. 3. Przedmiot zamówienia Przedmiotem zamówienia jest dostarczenie systemu (System), realizacja wymaganych dla poprawnego funkcjonowania systemu integracji, dostarczenie wymaganych licencji, dostarczenie wymaganej infrastruktury potrzebnej do pracy systemu, opracowanie wymaganej dokumentacji oraz przeprowadzenie szkoleń. Wraz z systemem dostarczona zostanie usługa wsparcia. 3.1. Ogólna lista produktów wytworzonych w ramach Przedmiotu Zamówienia Realizacja przedmiotu zamówienia obejmuje: a. Implementację i wdrożenie Systemu, którego minimalnych zakres funkcjonalny i koncepcja opisane są w rozdziałach 6 i 7. b. Dostarczenie wymaganych do poprawnego funkcjonowania systemu licencji obejmujących, co najmniej listę wyspecyfikowana w rozdziale 7.1.4 (z wyłączeniem tych, które zostaną poza udostępnionymi udostępnione przez Zamawiającego. Lista udostępnionych przez Zamawiającego narzędzi, platform, standardów i licencji wskazana została w rozdziale 6.2. c. Przygotowanie dokumentacji systemu w zakresie wskazanym w rozdziale 7.4.1. d. Implementację i wdrożenie integracji wymaganych do poprawnego funkcjonowania Systemu, które są opisane w rozdziale 4.1.1. e. Przekazanie praw autorskich do części Systemu dedykowanych i implementowanych na potrzeby Zamawiającego. f. Zwymiarowanie i dostarczenie wymaganej do poprawnego działania Systemu infrastruktury. g. Gwarancję oraz usługę wsparcia dla systemu na warunkach opisanych w rozdziale 7.5. h. Szkolenia dla użytkowników oraz administratorów Systemu. 4
4. Terminy realizacji prac 4.1. Ramowy harmonogram prac Wykonawca skalując zasoby oraz przygotowując harmonogram prac musi uwzględniać datę 31 grudnia 2015roku, jako nieprzekraczalną datę zakończenia całości wdrożenia. Szczegółowe daty zakończenia poszczególnych etapów projektu wskazuje Tabela nr 2. Ramowy harmonogram projektu przedstawia poniższa tabela. Tabela 2 Ramowy harmonogram prac. Numer etapu Zakres etapu Szacowany czas trwa w dniach roboczych (do uszczegółowienia na etapie 1 projektu) Etap 1 Weryfikacja zakresu 10 Przygotowanie harmonogramu prac Etap 2 Opracowanie projektu funkcjonalnego 10 Projektu technicznego Planu testów Systemu Etap 3 Dostawa sprzętu i licencji Przygotowanie środowisk Etap 4 Implementacja Systemu (zakłada się implementację systemów w 4 iteracjach (zakresach I-IV) 20 60 Opracowanie scenariuszy testowych Testy i odbiory poszczególnych zakresów (I-IV) Etap 5 Szkolenia użytkowników dla oddawanych sukcesywnie iteracji (zakresów I-IV) wdrożenia 45, zakończone nie później niż 31/12/2015) Wdrożenie produkcyjne systemu 5
Numer etapu Zakres etapu Szacowany czas trwa w dniach roboczych (do uszczegółowienia na etapie 1 projektu) 4.2. Rzeczowy harmonogram prac Poniższa tabela definiuje produkty etapów zarządczych Projektu. Tabela 3 Harmonogram rzeczowy. Numer etapu Etap 1 Produkty etapu Harmonogram prac Procedura dostarczania Produktów Zakres prac product back log Etap 2 Projekt funkcjonalny Systemu; Projekt techniczny systemu Wymiarowanie systemu i projekt infrastruktury wraz z zapotrzebowaniem na sprzęt i licencje Plany i scenariusze testów Etap 3 Zakupiony sprzęt i oprogramowanie gotowe (licencje) Skonfigurowane środowiska Oprogramowanie (Zamawiany System) Etap 4 Raporty z testów Dokumentacja użytkownika (w tym administratora). Dokumentacja wdrożeniowa (plan wdrożenia) Dokumentacja powykonawcza (zaktualizowana dokumentacja projektowa z Etapu 3) 6
Numer etapu Etap 5 Produkty etapu Wdrożony system Protokoły odbioru 4.3 Podział wdrożenia na iteracje (Zakresy) Zakłada się realizację systemu w 4 iteracjach, każda zakończona testami i odbiorami. Zakresy funkcjonalne dla każdej iteracji przedstawiają się następująco (bazują na wymaganiach funkcjonalnych opisanej w rozdziale 7.3 dokumentu) 4.3.1 Zakres I Wymagania funkcjonalne wchodzące w skład realizacji dla tej iteracji to: Moduł administracyjny CRM (wymagania WF-0220 do WF-0250) Moduł zarządzania relacjami z Klientami CRM (wymagania WF-0300 do WF-0356) 4.3.2 Zakres II Wymagania funkcjonalne wchodzące w skład realizacji dla tej iteracji to: Moduł Call Center (wymagania WF-0360 do WF-0390) Wymaganie WF-0190 4.3.3 Zakres III Wymagania funkcjonalne wchodzące w skład realizacji dla tej iteracji to: Moduł planowania CRM (wymagania WF-0010 do WF-0145) Moduł grafików (interfejsy) (wymaganie WF-0420) Integracja Altar (WF-0151) 4.3.4 Zakres IV Wymagania funkcjonalne wchodzące w skład realizacji dla tej iteracji to: Moduł zadań CRM (wymagania WF-0160 do WF-0180) Moduł raporty (wymagania WF-0200 do WF-0210) 7
Integracja RIS (WF-0150) Integracja SIMP (WF-0155) Integracja CRV (WF-0154, jeśli OPCJA realizowana) 5. Organizacja procesu dostarczenia produktów Niniejszy rozdział opisuje wymagania Zamawiającego w zakresie organizacji procesu wytwarzania i dostarczania Systemu. 5.1. Proces dostarczania oprogramowania Proces wytwórczy Systemu oraz przygotowania dokumentacji Systemu, w tym również postać wyników prac, musi być zgodny z wymaganiami i procedurami Zamawiającego przedstawionymi w niniejszym dokumencie. Prace w Projekcie dotyczący realizacji zamawianego Systemu będą realizowane przez Wykonawcę zgodnie z opracowanym przez niego oraz zaakceptowanym przez Zamawiającego harmonogramem realizacji prac. Harmonogram prac musi uwzględniać kamienie milowe wynikające z dostaw wymaganych produktów opisanych w punkcie 4.2. terminy wynikające z harmonogramu nie mogą przekraczać dat wskazanych w punkcie 4.1. W uzasadnionych i ustalonych z zamawiającym wypadkach będzie mógł podlegać aktualizacją, które jednak nie mogą modyfikować dat wskazanych w punkcie 4.1. Wykonawca będzie prowadził prace tak, aby wykonanie każdego obszaru funkcjonalnego kończyło się dostarczeniem produktów poszerzających funkcjonalność dostarczanego Systemu. Wykonanie każdego obszaru funkcjonalnego powinno być podzielone co najmniej na następujące fazy, tj.: a. Wytworzenie funkcjonalności obejmuje projekt Systemu i jego implementację, który realizuje Wykonawca pod nadzorem Zamawiającego. b. Testy wykonawcy testy realizowane na środowisku testowym Wykonawcy. Wyniki testów w postaci raportu będą przedstawiane Zamawiającemu. Pozytywny wynik testów jest podstawą do dopuszczenia Systemu do testów technicznych. Testy wykonawcy mogą być realizowane, jako testy automatyczne zgodnie ze scenariuszami przygotowanymi przez Wykonawcę i zaakceptowanymi przez Zamawiającego. c. Wdrożenie testowe na potrzeby przeprowadzenia testów funkcjonalnych (w środowisku testowo szkoleniowym). d. Testy techniczne (funkcjonalne) obejmują weryfikację, czy dostarczona funkcjonalność spełnia wymagania funkcjonalne. Weryfikacja na tym etapie obejmuje również testy integracji. Testy techniczne będą przeprowadzane na środowisku testowo szkoleniowym. 8
Pozytywne wyniki testów technicznych są warunkiem dopuszczenie Systemu do dalszych weryfikacji. Testy techniczne realizuje Zamawiający. e. Testy akceptacyjne (UAT) będą przeprowadzane przed Wdrożeniem produkcyjnym. Pozytywny wynik Testów akceptacyjnych jest warunkiem koniecznym do rozpoczęcia Wdrożenia produkcyjnego. Celem Testów Akceptacyjnych jest potwierdzenie, że wytworzone oprogramowanie spełnia wymagania funkcjonalne oraz pozafunkcjonalne (w szczególności wydajnościowe, bezpieczeństwa, powiązania z innymi obszarami funkcjonalnymi/systemami). Testy Akceptacyjne będą prowadzone na środowisku preprodukcyjnym. Testy akceptacyjne warunkują podpisanie Protokołu Odbioru Końcowego, którego formularz jest w załączniku nr 7 f. Wdrożenie produkcyjne obejmuje migrację danych, przygotowanie materiału wymaganego do wdrożenia oraz wsparcie we wdrożeniu i przekazanie do eksploatacji wytworzonego obszaru funkcjonalnego. Prawidłowość realizacji wdrożenia zostanie potwierdzone protokołem odbioru końcowego. Środowiska wskazane w powyższych zapisach zostaną dostarczone zgodnie z zestawieniem i zasadami wskazanymi w rozdziale 7.1.5 Zamawiający oczekuj, iż proces wytwarzania oprogramowania zaproponowany przez Wykonawcę będzie zgodny z: a. Metodyką SCRUM; b. Wskazanymi powyżej wytycznymi. 6. Wizja systemu Planowany system będzie realizował zadania typowe dla systemów typu CRM oraz CallCentre. Ze względu na specyfikę działalności prowadzonej przez Zamawiającego system będzie rozbudowany o elementy charakterystyczne dla systemów obsługujących logistykę w zakresie realizacji transportu kołowego oraz elementy rozwiązań GIS. 6.1. Otoczenie systemu Zamawiany System będzie rozwinięciem rozwiązań już wykorzystywanych przez Zamawiającego. W tej sytuacji System będzie zarówno umieszczony w infrastrukturze z Zamawiającego jak również zintegrowany z istniejącymi rozwiązaniami Zamawiającego. Poniższy diagram prezentuje powiązania Systemu z aplikacjami Zamawiającego oraz otoczeniem zewnętrznym. 9
pkg Mamobusy_V3_OPZ RIS «use» «file» RIS 4Net Optional CRV Teryt «use» «HL7» Work schedule, Visit Schedule PatientData «use» «ESB» «use» «ESB» PatientData Consent Activ edirectory «use» «LDAP» CRM PatientData «use» «ESB» «use» «LDAP» Grafiki Work schedule Orders «use» «WCF» «use» «file» «use» MSWIA «use» «WCF» Inv itation A «flow» External lead DB CD «flow» Invitation «use» «file» DMS «use» «WS» «use» Location Moduł GIS «use» «WCF» «use» «WS» Orders «use» «WS» Kurier MS Outlook Invitation, PatientData ewuś «use» «WS» Obszar rozwiązania Obszar dostarczanego System CallCentre SIMP «use» «HTML» Systemy zewnętrzne objęte integracją Dokumenty Diagram 1 Otocznie Systemu wraz z najważniejszymi powiązaniami 10
6.1.1. Opis elementów otoczenia Systemu Poniższa tabela opisuje komponenty otoczenia zamawianego Systemu przedstawione na poprzednim diagramie. Tabela 4 Komponenty otoczenia Systemu Lp. Komponent/ aplikacja Status Umiejscowienie Opis/ Zakres odpowiedzialności 1 RIS Istniejący Siedziba Zmawiającego - Gdynia 2 DMS Istniejący Siedziba Zmawiającego - Warszawa System Medicom wykorzystywany przez Zamawiającego jako podstawowy system medyczny w zakresie dotyczącym Projektu. Narzędzie wykorzystywane przez zamawiającego do zarządzania szablonami dokumentów oraz dostarczaniem dokumentów do odbiorców z wykorzystaniem różnych kanałów dostępu. Zarządzanie szablonami pism i generowanie wysyłki pism Zaproszenia: Listy tradycyjne, emails, SMS 3 CD (Centrum dostępu) Istniejący Siedziba Zmawiającego - Warszawa System Zamawiającego zarządzający autoryzacją użytkowników oraz dostępem i uprawnieniami użytkowników w aplikacjach biznesowych. 4 ActiveDirectory Istniejący Siedziba Zmawiającego - Warszawa LDAP oparty o MS Windows 2008 11
Lp. Komponent/ aplikacja Status Umiejscowienie Opis/ Zakres odpowiedzialności 5 Grafiki Projektow any Siedziba Zmawiającego - Warszawa Element Systemu oparty o interfejs WWW wykonany w technologii 4Net (MS.Net/ EJS/IIS/MS SQL Server) realizujący udostępnienie grafików dla techników, kierowców oraz pozwalający na przesłanie zamówienia dotyczącego obsługi logistycznej (kurier, odbiór śmieci, itp.) Aplikacja będzie wykorzystywała usługę sieciową wystawioną przez zamawiany System do pobierania i przesyłania danych. 6 MSOutlook Istniejący Siedziba Zmawiającego - Warszawa 7 CallCentre Istniejący Siedziba Zmawiającego - Warszawa System pocztowy oparty o MS Exchange, z którym System będzie się integrował w zakresie kalendarza oraz zadań. System CallCentre firmy Altar 8 SIMP Istniejący System NFZ System Informatyczny Monitorowania Profilaktyki - system NFZ obsługujący sprawdzenie uprawnień beneficjentki, rejestrację świadczeń, rejestrację wyników badań i rozliczenia z NFZ 9 ewuś Istniejący System NFZ Elektroniczna weryfikacja uprawnień świadczeniobiorców 10 Kurier Istniejący Zewnętrzny: TNT/ Pocztex Usługa sieciowa udostępniana przez firmy kurierskie służąca zamawiania i obsługi przesyłek kurierskich 11 External lead DB Istniejący Zewnętrzny bazy statystyczne zawierające dane o liczbie uprawnionych, wielkość populacji w miejscowości 12
Lp. Komponent/ aplikacja Status Umiejscowienie Opis/ Zakres odpowiedzialności 12 MSWIA Istniejący Zewnętrzny Plik udostępniany przez MSWIA zawierający dane osób uprawnionych do badania. 13 4Net Istniejący Siedziba Zmawiającego - Warszawa 14 CRV Istniejący Siedziba Zmawiającego - Warszawa Podstawowy System medyczny, wykorzystywany przez Zmawiającego w obszarach związanych z obsługą produktów ambulatoryjnych. Aplikacja będzie dodatkowym źródłem danych statystycznych dla zamawianego Systemu. Master Data Rekord dla danych dotyczących osób fizycznych. Aplikacja będzie wykorzystywana do przetwarzania danych pacjentów oraz zbierania zgód marketingowych. 15 Teryt Istniejący Zewnętrzny Dane TERYT będą wykorzystywane do klasyfikowania danych adresowych przesyłanych w pliku MSWIA zawierających kody TERYT oraz do weryfikacji wprowadzanych danych teleadresowych. 13
Lp. Komponent/ aplikacja Status Umiejscowienie Opis/ Zakres odpowiedzialności 16 CRM Projektow any Siedziba Zmawiającego - Warszawa System CRM jest jednym z obszarów Zamawianego rozwiązania. Obecnie Zamawiający dysponuje system CRM opartym o MS Dynamics, który zamawiany System ma rozszerzyć o wymagania opisane w rozdziale 7. Główne odpowiedzialności tego modułu to część logistyczna (planowanie i zarządzanie zasobami) oraz zarządzanie kontaktami z kontrahentami i beneficjentkami, a w tym: a. zarządzanie kalendarzem mammobusów b. definicja danych potrzebnych do planowania: mammobusy, technicy c. baza lokalizacji (kontrahentów) d. predykcja lokalizacji 'tras" e. potwierdzenie lokalizacji f. zarządzenie kontaktami z potencjalnymi pacjentkami z wybranych lokalizacji g. wygenerowanie zaproszeń i harmonogramu wizyt h. wygenerowanie listy lokalizacji dla NFZ i. raportowanie j. zarządzenie zgodami marketingowymi (pozyskanymi od przebadanych pacjentek) 14
Lp. Komponent/ aplikacja Status Umiejscowienie Opis/ Zakres odpowiedzialności 17 Moduł GIS Projektow any Siedziba Zmawiającego - Warszawa Moduł mapowy odpowiedzialny za: a. Prezentację danych statystycznych b. Prezentację wyników predykcji lokalizacji mammobusów c. Wyliczenie propozycji tras mammobusów. 6.2. Standardy i wytyczne Poniższy rozdział przestawia wytyczne jakimi Zmawiający kierował się przy opracowaniu architektury oraz wymagań dla Systemu. Kluczowym wymaganiem, którym musi się kierować Wykonawca Systemu jest spełnienie standardów technologicznych Zamawiającego. 6.2.1. Standardy technologiczne Zamawiający dysponuje infrastrukturą oraz rozwiązaniami wykorzystywanymi produkcyjnie, które zamawiany System będzie uzupełniał. Te względy dyktują konieczność dostarczenia rozwiązań kompatybilnych spełniających poniższe standardy. Tabela 5 Standardy technologiczne Zamawiającego. Nr Obszar/ Komponent Technologia S001 CRM MS Dynamics 2013 S002 Repozytorium plików MS Sharepoint 2013 S003 Bazy danych Microsoft SQL Server 2008R2 Enterprise Edition S004 RIS.Net 4.0/ WPF Microsoft SQL Server 2008R2 Standard Edition 2012 S005 Serwery aplikacyjne/ WWW IIS 7.5 S006 DMS GMC Inspire 15
Nr Obszar/ Komponent Technologia S007 Mail MS Exchange 2007/ MS Outlook S008 CallCentre Altar S009 Wirtualizacja VMWare 5.0 lub nowszy S010 Systemy operacyjne MS Windows 2008 S011 Asynchroniczna wymiana danych NServiceBus z kolejkami realizowanymi w bazie danych S012 Usługi sieciowe Webservice z binding typu BasicHttpBinding WCF S013 Przeglądarki WWW Interfejsy aplikacje oparte o ASP.NET/EJS pracujące w przeglądarkach: a. FireFox w wersji 24.0.0 ESR wymagana jako podstawowa przeglądarka wykorzystywana przez Zamawiającego; b. MS Internet Explorer w wersji 10. 6.2.2. Wytyczne architektoniczne Zamawiający podczas przygotowania założeń kierował się poniższymi pryncypiami architektonicznymi. Wytyczne te są również wiążące dla Dostawcy Systemu. Nr wytycznej Wytyczna Opis uwagi P001 Otwarty kod aplikacji Wszystkie obszary/ moduły Systemu implementujące warstwę integracji oraz algorytmy wymagane przez Zamawiającego, a w szczególności: a. definiujące grafiki, b. kalendarze pracy mammobusów, c. typujące zbiory beneficjentek i miejscowości postojów, 16
Nr wytycznej Wytyczna Opis uwagi d. realizujące tworzenie rankingu miejscowości e. realizujące predykcje tras mammobusów, f. zarządzające kolejkami i kampaniami dla CallCentre, muszą być otwarte dla Zamawiającego. Oznacza to możliwość modyfikacji przez Zamawiającego. P002 Wykorzystanie standardów Zamawiającego Zamawiany System musi być projektowany i implementowany w oparciu o standardy technologiczne przedstawione przez Zamawiającego P003 Baza danych Wszystkie rozwiązania wymagające magazynów danych składowanych w bazach danych muszą być kompatybilne z MS SQL Server 2008R2 P004 Integracja asynchroniczna Komunikacja asynchroniczna musi być oparta o NServiceBus P005 Usługi sieciowe Webservice z binding typu BasicHttpBinding WCF P006 LDAP Autoryzacja w przypadku dostarczenia rozwiązań gotowych musi być oparta o LDAP (ActiveDirectory) udostępniony przez Zamawiającego. Uprawnienia oparte powinny być o grupy domenowe i uwzględniać polisy domenowe. P007 Centrum dostępów Autoryzacja i zarządzanie uprawnieniami dla aplikacji implementowanych (nie gotowych) na zlecenie Zamawiającego oparte powinno być o narzędzie utrzymywane i rozwijane przez Zamawiającego. Narzędziem tym jest Centrum dostępów dostarczające usługi autoryzacji poprzez usługi sieciowe. P008 Wymienność algorytmów planowania i predykcji Algorytmy predykcji powinny zbudowane w sposób umożliwiający ich rozszerzanie, wymianę oraz dodawanie kolejnych bez zmiany funkcjonalności CRM. Możliwość rozbudowy algorytmów powinna zostać wykonana jako 17
Nr wytycznej Wytyczna Opis uwagi API realizujące włączanie/ wyłączanie algorytmów w postaci plugin ów. W przypadku, gdy Wykonawca zdecyduje się na implementację Systemu Zamawiający dostarczy standardy dotyczące: a. Zasad i standardów kodowania; b. Zasad i standardów dotyczących implementowania obiektów bazy danych; c. Zasad dokumentowania kodu; d. Zasad zarządzania repozytoriami kodu. 6.3. Koncepcja systemu W ramach Projektu dostarczone zostaną narzędzia usprawniające planowanie i zarządzanie realizacją badań przy wykorzystaniu floty mammobusów, jakimi dysponuje Zamawiający. Dostarczone narzędzie powinno umożliwi wykorzystanie możliwie najefektywniej zasobów Zamawiającego. Zamawiający zakłada maksymalne wykorzystanie istniejącej infrastruktury. Zamawiane narzędzie składać się będzie funkcjonalnie z następujących obszarów: a. Algorytmy predykcji lokalizacji oraz planowania logistycznego; b. Moduł prezentacji i planowania lokalizacji mammobusów; c. Moduł zarządzania relacjami z beneficjentkami oraz kontrahentami; d. Zarządzanie grafikami. Każdy ze wspomnianych modułów może być wykonany jako niezależny komponent ale pod warunkiem możliwości jego współpracy rozwiązaniem wybranym przez Zamawiającego, jako platforma CRM. Przez współpracę należy rozumieć takie umieszczenie modułu w ramach CRM, aby z punktu widzenia użytkownika było to rozwiązanie stanowiące część CRM Algorytmy predykcji i planowania powinny zostać dostarczone jako niezależne moduły z otwartym kodem możliwym do modyfikowania przez Zamawiającego. Algorytmy powinny być możliwe do podłączenia do funkcjonalności planowania dostępnych przez CRM w sposób pozwalający na ich rozszerzanie, wymianę oraz dodawanie kolejnych bez zmiany funkcjonalności CRM (API realizujące ideę plugins). Realizacja modułu GIS oraz logistyki powinna być oparta o rozwiązania OpenSource umożliwiające integrację z rozwiązaniem wybranym przez Zamawiającego, jako platforma CRM. Moduł zarządzania relacjami (CRM) zbudowany powinien być o platformę wybraną i wykorzystywaną przez Zamawiającego w obszarze CRM. Moduł powinien zapewnić realizację zadań związanych z: 18
a. koordynowaniem wysyłki zaproszeń wraz z odpowiednią personalizacją treści zaproszenia; b. wspieraniem procesów operacyjnych związanych z planowaniem i organizowaniem badań; c. rejestracją na badania; d. obsługą beneficjentek; e. zarządzeniem kalendarzem dostępności mammobusów; f. procesem raportowania, sprawozdawczością oraz monitorowaniem faktycznych rezultatów Projektu. 6.4. Założenia i ograniczenia Wykonawca projektując i implementując System musi uwzględnić co najmniej założenia i ograniczenia jakie zostały przyjęte i zidentyfikowane przy definiowaniu architektury Systemu oraz identyfikowaniu wymagań dla niego. Zidentyfikowane założenia i ograniczenia opisu tabela poniżej. Tabela 6 Założenia o ograniczenia Systemu. Nr wymagania OG001 Opis założenia lub ograniczenia Kod aplikacji RIS wykorzystywanej przez Zamawiającego jest zamknięty. Podczas projektowania integracji należy: 1. Założyć w przypadku przekazywania danych do sytemu RIS konieczność porozumienia się z dostawcą systemu RIS w zakresie wykorzystania API aplikacji do wstawienia danych; 2. Założyć w przypadku pobierania danych własną warstwę integracji opartą o pobranie danych bezpośrednio z bazy danych OG002 OG003 OG004 OG005 Liczba licencji CAL dla systemu jest ograniczona do wartości podanych rozdziale 7.1.4. Dodatkowe dostępy dla funkcji statycznych lub rzadko wykorzystywanych (np. prezentacje zestawień) należy projektować jako usługi sieciowe dostarczające odpowiednie metody możliwe do wykorzystania przez zewnętrzne aplikacje. System CRM musi być przygotowany, jako rozbudowa rozwiązania istniejącego u Zamawiającego Autoryzacja w RIS oparta o uprawnienia SQL Server Przepustowość łącza pomiędzy biurem zlokalizowanym w Gdynia a Centralą Zamawiającego, gdzie planowana jest infrastruktura dla Systemu, ograniczona do 10 Mbit 19
7. Szczegółowe wymagania 7.1. Architektura rozwiązania 7.1.1. Umiejscowienie w architekturze zamawiającego Projektując rozwiązanie Wykonawca powinien wziąć pod uwagę, iż infrastruktura, na której posadowiony będzie System znajduje się w innej lokalizacji niż użytkownicy systemu. Rozwiązanie musi uwzględniać dostępne pasmo oraz uwarunkowana odnośnie bezpieczeństwa i dostępności systemów. Poniższy diagram prezentuje lokalizacje geograficzną istotnych komponentów Systemu oraz dostępne połączenia. deployment Location «executionenvironment» MS Windows 2008 RIS::RIS Gdynia CRM::CRM Warszawa «executionenvironment» MS Windows 2008 CRM::DMS 10 Mbit CRM::CallCentre Diagram 2. Umiejscowienie komponentów w infrastrukturze Zamawiającego 7.1.2. Komponenty i interfejsy Poniższy diagram pokazuje minimalny zakres interfejsów, jakie System będzie realizował. Szczegółowy zakres integracji opisuje Tabela 8. 20
composite structure CRM Kurier Request for service WS Orders External lead DB Statistical file ewuś CRM Eligibility WS Eligibility MSWIA Logistics Population coverage Moduł administracyjny Moduł planowania Grafiki Grafiki WS SIMP GUI Rejestracja wizyt Orders Work schedule Mammographic findings, Location, Eligibility Visit Schedule Zamówienie usługi Uprawnienia Grafiki techników Rejestracja badań Rejestracja wizyt Usługi CRM Moduł zarządzania Moduł CallCentre relacjami z klientem Moduł zadań Moduł raportowy Statistical data Pliki statystyczne Pliki MSWiA Lokalizacje Dane beneficjentek Dane techników Import_WCF Employee data Statistical data Location PatientData Teryt Localization 4Net Patient data Grafiki GIS Kampanie Wydruki Eksport_WCF Location PatientData RIS Kalendarz Patient data Schedule WCF Location Location, Statistical data Invitation Invitation Calendar Visit Schedule, Work schedule Dane pracowników CRM_WCF GIS Wizualizacja danych statystycznych Wybór miejsc do odwiedzenia CRM WS CallCentre Printouts WS DMS Calendar Plugin Outlook Diagram 3 Interfejsy i podział odpowiedzialności w zamawianym Systemie. 21
Tabela 7 Komponenty zamawianego Systemu. Lp. Komponent Opis/ Zakres odpowiedzialności CRM Logistyka Moduł (przestrzeń) w CRM realizująca wymagania z zakresu modułu zarządzania relacjami z klientem, modułu CallCentre (moduł współpracy z Altar), modułu zadań oraz modułu raportowego. Moduł, który może zostać zaimplementowany jako część CRM. Moduł odpowiedzialny na wprowadzenie danych potrzebnych do działania algorytmów predykcji potencjalnych lokalizacji mammobusów oraz predykcji tras przewozu mammobusów do potencjalnych lokalizacji Moduł będzie wspierał typowanie lokalizacji (miejscowości) interesujących z punktu widzenia planowania badań oraz za wspieranie planowania badań, które obejmuje planowanie logistyki związanej z przemieszczaniem i postojem mammobusów. Moduł musi mieć otwarty kod w zakresie budowy algorytmów predykcji GIS Moduł realizujący wizualizację danych statystycznych, lokalizacji oraz tras mammobusów. Dodatkowo narzędzie musi umożliwić wskazywanie optymalnych lokalizacji. 22
Poniższa tabela prezentuje minimalną listę interfejsów jakie ma obsługiwać system Tabela 8 Zidentyfikowane interfejsy Nr Nazwa interfejsu Wymagany Kierunek integracji Integrowany system Sposób realizacji Zdarzenie sterujące/ częstotliwość Opis/ Zakres odpowiedzialności Odniesienie do wymagania I001 Pliki statystyczne Wymagany projekt i implement acja usługi do pobierania danych Do CRM Systemy backoffice Zmawiająceg o lub własne dane statystyczne Import plików excel lub csv dostarczany na płycie CD Raz w miesiącu Dane statystyczne na potrzeby typowania lokalizacji mammobnusów Zakres danych obejmuje: a. informacje o lokalizacji przygotowany per województwo zawierające miejscowość oraz potencjalne objęcie populacji WF-0080 informacje o miejscowościach krytycznych statystycznie współczynnik beneficjentek nigdy nie korzystających z badań (zaproszeń na badania) 23
I002 Pliki MSWiA Wymagany projekt i implement acja usługi do pobierania danych Do CRM MSWiA Import plików excel lub csv dostarczany na płycie CD Udostępniany raz w roku dla podmiotów mających umowę z MSWIA Dane potencjalnych beneficjentek Programu Zakres danych obejmujących listę beneficjentek potencjalnie uprawnionych do badań. Plik przygotowywane jest per województwo i zawiera: a. Imię, WF-0300 a. Nazwisko, b. Rocznik (data urodzenia) c. Pesel d. Dane adresowe w oparciu o kody TERYT 24
I003 Lokalizacje Wymagany projekt i implement acja usługi do pobierania danych Do CRM TERYT Pliki xml dostarczany na płycie CD Raz w miesiącu nie rzadziej niż pliki z informacją o objęciu populacji np. z MSWiA Przesłanie danych lokalizacyjnych na potrzeby powiązania danych pacjentek z adresami np. dla danych przesłanych z MSWiA Zakres interfejsu zgodny ze specyfikacja udostępnioną na stronach GUS WF-0240 I004 Dane beneficjentek OPCJA Wymagany projekt i implement acja usługi po stronie CRM Do CRM 4Net NSB Zmiana danych pacjentki z zakresie wykonanych badań zbieżnych z Projektem Przesłanie danych potencjalnych beneficjentek badań. Zakres danych podobny do MSWiA ale adres jest podany bez kodów Teryt. Dodatkowo przesyłana jest flaga statusu uprawnienia i data wykonania badania. WF-0301 Interfejs należy zaprojektować i wykonać po stronie zamawianego Systemu. 25