Opis Przedmiotu Zamówienia

Załącznik nr 6 do SIWZ

Załącznik nr 7 do Umowy

Opis Przedmiotu Zamówienia

Przedmiot zamówienia

Przedmiotem zamówienia jest
1. dostawa dedykowanego oprogramowania, w tym wykonanie, wdrożenie oraz przekazanie majątkowych praw autorskich systemu informatycznego (zwanego dalej Systemem)
2. hosting i utrzymanie Systemu na dedykowanych serwerach Wykonawcy.
W zakres zamówienia z pkt. 1 lit. a „dostawa dedykowanego oprogramowania” wchodzi w szczególności:
1. wykonanie Systemu;
2. testowanie Systemu;
3. wdrożenie Systemu;
4. szkolenie z obsługi Systemu;
5. udzielenie Zamawiającemu rękojmi i gwarancji na zasadach określonych we wzorze umowy oraz wykonania wszelkich usług wynikających z udzielonej gwarancji;
6. utrzymanie systemu na serwerach Wykonawcy Przez cały okres trwania projektu.
W zakres zamówienia z pkt. 1 lit. b „hosting i utrzymanie Systemu” wchodzi w szczególności::
1. Zapewnienie infrastruktury pozwalającej na prawidłowe funkcjonowanie Systemu;
2. Instalację Systemu na zabezpieczonej Infrastrukturze Wykonawcy
3. Udostępnienie Użytkownikom sieci Internet Systemu na zabezpieczonej Infrastrukturze Wykonawcy wraz z zapewnieniem ciągłości działania i dostępności Systemu;
4. Świadczenie usługi hostingu dla Systemu (Hostowanie) i zapewnienie dostępności Systemu;
5. Świadczenie usług wsparcia technicznego dla Systemu, w tym np. administracji serwerami, aktualizacjami komponentów systemu operacyjnego serwerów (baz danych, modułów itp.), instalacja aktualizacji i łatek systemu operacyjnego, itp. W zakres usług wsparcia nie wchodzi modyfikacja Systemu dostarczonego przez Zamawiającego;
6. Świadczenie usług konsultacyjnych/wsparcia w okresie obowiązywania Umowy. Usługi konsultacyjne objąć mają m. in obszar związany ze środowiskiem hostingowym: np. uruchomienia nowych aplikacji i baz danych, instalacja/konfiguracja vhostów oraz maszyn wirtualnych, odzyskiwanie utraconych danych, upgrade działających usług/serwisów, modyfikacje działających usług/serwisów.

Wykonanie Systemu

Wykonawca odbędzie z Zamawiającym spotkania warsztatowe w siedzibie Zamawiającego mające na celu omówienie i analizę sposobu wykonania Przedmiotu Zamówienia opisanego w niniejszym OPZ. Na podstawie odbytych spotkań warsztatowych Wykonawca opracuje i dostarczy Specyfikację Wymagań Systemowych (SWS). Na podstawie SWS Wykonawca opracuje i dostarczy do akceptacji Zamawiającego następujące artefakty projektowe:

makietę klikalną Systemu zaktualizowaną o uwagi Zamawiającego,
projekty interfejsów graficznych Systemu,
projekt bazy danych systemu.

Wykonawca przedłoży wymienione powyżej elementy do akceptacji Zamawiającego.

Na podstawie zaakceptowanych artefaktów Wykonawca wykona (zaprogramuje) System.

Testowanie systemu

W ramach testowania Systemu Wykonawca przeprowadzi testy akceptacyjne wszystkich modułów i funkcjonalności Systemu opisanych w SWS, w tym również testy akceptacyjne integracji z systemami zewnętrznymi za pomocą interfejsów API.

Wdrożenie Systemu

Wykonawca dokona wdrożenia Systemu na dzierżawionych przez siebie serwerach dedykowanych.
Wykonawca wdroży System w postaci dwóch niezależnych instancji – deweloperskiej i produkcyjnej.
Wykonawca zapewni koncepcję i wykonanie odpowiednio wysokiej wartości HA (dostępności) dla wykonanego Systemu.

Szkolenie z obsługi Systemu

Wykonawca przeprowadzi szkolenie z obsługi oraz administrowania Systemem dla osób wskazanych przez Zamawiającego.
Szkolenie przeprowadzone zostanie w siedzibie biura projektu Zamawiającego.

Udzielenie rękojmi i gwarancji

Wykonawca zobowiązany będzie do świadczenia serwisu gwarancyjnego przez cały okres trwania projektu, tj. przez okres co najmniej do 31 grudnia 2022.
Okres świadczenia serwisu gwarancyjnego rozpocznie się z dniem podpisania końcowego protokołu odbioru Systemu bez uwag.
W okresie trwania serwisu gwarancyjnego Wykonawca jest zobowiązany do wykonywania świadczeń gwarancyjnych polegających na:
1. skutecznym rozwiązywaniu Zgłoszeń,
2. dostarczaniu, instalacji i wdrażaniu niezbędnych lub celowych poprawek (w tym tzw. łat programowych i bezpieczeństwa - ang. „patch") Systemu i oprogramowania wspierającego;
3. niezwłocznym instalowaniu poprawek bezpieczeństwa wszystkich elementów Systemu bez zgłoszenia zamawiającego
4. podnoszenie wersji bazy w ramach serwisu gwarancyjnego;
5. innych koniecznych działaniach zapewniających prawidłowe - tzn. nieograniczone czasowo i funkcjonalnie działanie Systemu.
Wykonawca będzie zobowiązany zrealizować wszelkie świadczenia w ramach serwisu gwarancyjnego w taki sposób, aby zapewnić pełną funkcjonalność Systemu w trakcie i po zrealizowaniu świadczenia.
Wszelkie działania związane ze świadczeniem serwisu gwarancyjnego wykonywane będą wyłącznie z wiedzą i akceptacją Zamawiającego.
W okresie trwania serwisu gwarancyjnego Wykonawca zobowiązany będzie do:
1. dostarczania nowych wersji lub uaktualnienia oprogramowania wchodzącego w skład Systemu, w przypadku, gdy nastąpią zmiany w obowiązującym prawodawstwie, wymagające nowszej wersji lub uaktualnienia oprogramowania,
2. instalacji nowych wersji lub uaktualnień oprogramowania w terminach uzgodnionych z Zamawiającym,
3. usprawniania obsługi Systemu poprzez wprowadzanie autorskich udoskonaleń w technologii i funkcjonalności oprogramowania,
4. szkolenia użytkowników i administratorów z zakresu nowych funkcjonalności, o których mowa w ppkt. a-d oraz aktualizacji Dokumentacji w tym zakresie.
Awarie, problemy, incydenty i zdarzenia w działaniu Systemu będą usuwane przez Wykonawcę na podstawie zgłoszeń dokonywanych przez Zamawiającego na piśmie, wysłanych na adres Wykonawcy lub w formie elektronicznej poprzez system helpdesk bądź pocztę elektroniczną na wskazany przez Wykonawcę adres email.

Przekazanie majątkowych praw autorskich

W ramach realizacji przedmiotu zamówienia Wykonawca przekaże zamawiającemu wszelkie majątkowe prawa autorskie do wytworzonego Systemu.
Szczegółowy zakres i warunki przekazania majątkowych praw autorskich zawarte zostaną w umowie.

Cel Systemu

Do głównych celów projektowanego Systemu należeć będą:

obsługa dedykowanych (głównych i kontekstowych) procesów projektu zgodnie z opisem procesów i procedur opracowanym przez Xxxxxxxxxxxxx,
automatyzacja i skalowanie procesu naboru uczestników projektu,
automatyzacja procesów związanych z wytwarzaniem i obsługą dokumentacji projektowej i procesowej,
automatyzacja procesów związanych z raportowaniem wymaganym w ramach obsługi projektów finansowanych ze środków Europejskiego Funduszu Społecznego oraz budżetu państwa poprzez wdrożenie właściwych interfejsów API lub innych niezbędnych mechanizmów raportowania,
umożliwienie szczegółowego nadzoru nad środkami finansowymi projektu oraz automatyzacja procesów decyzyjnych związanych z zarządzaniem budżetem projektu, w tym raportowanie i rozliczanie Wykonawców Medycznych działających w ramach projektu,
nadzorowanie i koordynowanie procesu uczestnictwa uczestników projektu na każdym jego etapie,
ewaluacja wyników projektu.

Udziałowcy i użytkownicy systemowi

Wstępnie zidentyfikowani zostali następujący udziałowcy Systemu i użytkownicy w ramach zidentyfikowanych udziałowców:

Realizator
1. Administrator
2. Koordynator
3. Lekarz
4. Pielęgniarka
5. Fizjoterapeuta
6. Psycholog
7. Callcenter
8. Rejestrator
9. Pacjent/Uczestnik
Użytkownik anonimowy

Liczba oraz podział udziałowców i użytkowników Systemu może ulec zmianie na skutek warsztatów projektowych w trakcie opracowania SWS. W skutek prac analitycznych wyodrębnione mogą zostać dodatkowe instancje, a inne mogą ulec połączeniu. Wykonawca projektując i wdrażając System nie może określać dostępu licencjonowanego do poszczególnych grup użytkowników, ich ilości, modułów, funkcjonalności itp. Dostęp do Systemu w zakresie licencjonowania musi pozostawać wolny.

Moduły systemowe

Wstępnie zidentyfikowane zostały następujące moduły funkcjonalne Systemu:

Moduł przesiewowy
Moduł rejestracyjny
Moduł badań medycznych
Moduł edukacyjny
Moduł interwencji behawioralnych
Moduł statystyczny
Moduł koordynacyjny
Moduł repozytorium
Moduł sprawozdawczy

Ilość i zakres modułów może ulec zmianie na skutek warsztatów projektowych w trakcie opracowania SWS. W skutek prac analitycznych wyodrębnione mogą zostać dodatkowe moduły, a inne mogą ulec scaleniu.

Wymagania ogólne

System musi zostać wykonany w zgodnie z wymaganiami Rozporządzenia Parlamentu Europejskiego i Rady 2016/679 o ochronie danych osobowych (RODO).
System musi spełniać wymagania w zakresie bezpieczeństwa systemów informatycznych na poziomie wysokim w sposób opisany w Załącznik do rozporządzenia Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych.
System w całości wykonany będzie w języku polskim.
System wykonany zostanie w architekturze klient-serwer i musi być dostępny za pośrednictwem sieci Internet z rozproszonych terminali Użytkowników.
Cała logika, kod i bazy danych Systemu zlokalizowane będą na serwerze.
System wykonany zostanie zgodnie ze wzorcem MVC (model-view-controller).
System wykonany zostanie zgodnie z paradygmatem programowania obiektowego OOP (object-oriented programming).
W przypadku wykorzystania frameworków programistycznych (np. Symfony, Zend itp.) zapewnione zostanie wykorzystanie frameworka w najnowszej wydanej wersji i posiadającego aktualne wsparcie środowiska wytwórczego dla danego frameworka.
System zostanie wytworzony z zastosowaniem systemu kontroli wersji (GIT) oraz narzędzia wspierającego kontrolę dostępu i przechowywania repozytorium (np. Github, Bitbucket itp.), do którego wyłączny dostęp administracyjny zostanie po zakończeniu prac przekazany Zamawiającemu. Zamawiający dopuszcza możliwość zamieszczenia repozytorium GIT na własnym serwerze hostingowym dostarczonym przez Zamawiającego. Wszelkie zmiany dokonywane podczas Wykonawcę w okresie trwania gwarancji w strukturach programistycznych Systemu muszą być wersjonowane i odzwierciedlane w repozytoriach GIT.
Kod źródłowy Systemu opatrzony musi zostać niezbędnymi komentarzami na poziomie klas, metod i zmiennych, umożliwiając szybszą i wygodniejszą konserwację i modyfikację kodu źródłowego w przyszłości.
Użytkowanie Systemu odbywać się będzie za pośrednictwem przeglądarki internetowej, jako cienkiego klienta. System nie może wymagać instalacji dodatkowego, innego niż przeglądarka, oprogramowania lub wtyczek po stronie klienta. System musi być kompatybilny z przeglądarkami Firefox, Chrome i Edge w ich aktualnych wersjach.
Wykonawca do celów akceptacji dostarczy Zamawiającemu klikalną makietę lo-fi (low fidelity) obrazującą schematy wszystkich planowanych interfejsów aplikacji.
Wszystkie połączenia realizowane oraz dane przesyłane przez System za pośrednictwem publicznej sieci Internet muszą być szyfrowane (certyfikat SSL Zamawiającego).
Wszystkie interfejsy graficzne Systemu muszą zostać wykonane:
1. w zgodności ze standardem ISO 9241,
2. z uwzględnieniem najlepszych praktyk UX Design,
3. w zgodności z najnowszymi standardami określonymi przez W3C dla HTML, XHTML, CSS,
4. z optymalizacją pod kątem czasu ładowania,
5. w technologii RWD (responsive web design) gwarantując pełną czytelność i użyteczność na różnych rodzajach urządzeń i w różnych rozdzielczościach,
6. zgodnie z ustawą o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (Dz.U. 2019 poz. 848) oraz Dyrektywą Parlamentu Europejskiego i Rady (UE) 2016/2102 z dnia 26 października 2016r. w sprawie dostępności stron internetowych i mobilnych aplikacji organów sektora publicznego (Dz.Urz. UE L 327 z 02.12.2016), z zachowaniem co najmniej minimalnego standardu dostępności cyfrowej na poziomie WCAG 2.,.
7. z zastosowaniem asynchronicznego przesyłania danych wszędzie tam, gdzie będzie istniała zasadność zastosowania tej metody.
System musi spełniać wszelkie standardy bezpieczeństwa wymagane prawnie na dzień przekazania go do użytkowania. W tym najlepsze praktyki branżowe odnośnie bezpieczeństwa, w szczególności dokładną walidację danych pobieranych z formularzy, przekazywanych przez URL oraz być odporny między innymi na następujące zagrożenia:
1. ataki semantyczne na adres URL,
2. ataki związane z ładowaniem plików,
3. ataki typu cross-site scripting,
4. podrabianie zatwierdzenia formularza,
5. ujawnienie uwierzytelnień dostępu,
6. wstrzykiwanie kodu SQL,
7. ujawnienie danych przechowywanych w bazie,
8. trawersowanie katalogów,
9. wstrzykiwanie poleceń systemowych.
10. ataki na system operacyjny i oprogramowanie serwerowe
System musi logować i raportować powyższe zdarzenia bezpieczeństwa w formie logu systemowego zapisywanego lokalnie i do zdalnego serwera Syslog w czasie rzeczywistym. Zdarzenia powinny być opatrzone datą i godziną, opisem zdarzenia i adresem IP hosta źródłowego.
System musi mieć możliwość automatycznego reagowania na wybrane zdarzenia bezpieczeństwa poprzez czasową blokadę IP źródłowego na lokalnym firewallu.
Dostęp do Systemu musi być możliwy wyłącznie dla użytkowników do tego upoważnionych po uprzednim zalogowaniu za pomocą unikatowego loginu i hasła. Ilość użytkowników nie może być w jakikolwiek sposób ograniczana przez Wykonawcę w odniesieniu do licencji dostępowych.
System umożliwi użytkownikowi z najwyższymi uprawnieniami administracyjnymi tworzenie, zarządzanie i usuwanie kont innych użytkowników oraz zarządzanie uprawnieniami dla tych kont w pełnym zakresie elastyczności.
System musi dokonywać automatycznego wylogowania użytkownika po określonym czasie nieaktywności użytkownika.
Każdy użytkownik posiadający dostęp do Systemu musi być ograniczony wyłącznie do zakresu możliwości funkcjonalnych określonych ograniczeniami roli i uprawnień jakie otrzymał w Systemie.
Każdy uczestnik projektu musi posiadać status precyzyjnie określający na którym etapie projektu się znajduje, w tym również dokładną historię wcześniejszych statusów oraz ich zmian.
System musi zapewniać precyzyjne w pełni automatyczne zarządzanie, monitorowanie i raportowanie statusów uczestników projektu, w tym historii statusów.
System zamieszczony zostanie na serwerze dostarczonym dla tego celu przez Wykonawcę.
System musi umożliwiać instalację i działanie w oparciu o darmowe systemy operacyjne i bazodanowe.
System powinien umożliwiać integrację z zewnętrznym serwerem Zamawiającego udostępniającym możliwość masowej wysyłki wiadomości e-mail celem usprawnienia obsługi wysyłki powiadomień e-mail.
System powinien umożliwiać integrację z zewnętrznym operatorem oferującym usługę masowej wysyłki wiadomości tekstowych SMS celem usprawnienia obsługi wysyłki powiadomień SMS. Zamawiający wskaże na etapie wdrożeniowym tego operatora z podaniem stosownego API komunikacyjnego.
System dostarczony zostanie w dwóch niezależnych instancjach: produkcyjnej i deweloperskiej.
System powinien przechowywać wszystkie dane wprowadzone na każdym z poziomów przez każdy z typów użytkowników i umożliwiać wygodny i szybki wgląd oraz wyszukiwanie danych.
System powinien prowadzić procesy logowania operacji w nim dokonywanych, ze szczególnym uwzględnieniem wprowadzania, usuwania i modyfikacji danych przez użytkowników.
System musi zawierać wszelkie dane słownikowe oraz implementować algorytmy postępowania dotyczące obliczania, wprowadzania, oceny parametrów medycznych itp. na każdym etapie wprowadzania danych do Systemu.
Opracowanie algorytmów obliczeniowych, wdrożenie wartości referencyjnych oraz zapewnienie ich poprawności w oparciu o aktualne wytyczne i standardy instytucji i organizacji wymienionych w dalszej części Opisu Przedmiotu Zamówienia należeć będzie do odpowiedzialności Wykonawcy.
System powinien automatycznie pobierać i przesyłać określone typy danych do wybranych systemów zewnętrznych za pomocą dedykowanych interfejsów wymienionych w Opisie Przedmiotu Zamówienia.
Dostarczone rozwiązanie musi posiadać mechanizmy umożliwiające przeprowadzenie centralnej aktualizacji oprogramowania zarówno w środowisku produkcyjnym jak i testowo-szkoleniowym.
Oprogramowanie Systemu musi zostać dostarczone wraz z pełnym zestawem instalacyjnym obejmujący wszystkie niezbędne komponenty do prawidłowej pracy Systemu (w tym katalogi aplikacji, środowisko uruchomieniowe, czcionki, skróty itd.).
System do działania nie może wymagać instalacji żadnych wtyczek po stronie przeglądarki internetowej (w tym x.xx. Adobe Flash, Microsoft Shockwave, Oracle Java itp.).
Wykonawca dostarczy niezbędne licencje oprogramowania e-usług i bazy danych jeśli takowe będą wymagane.
Realizacja Systemu prowadzona będzie przy zastosowaniu zwinnej metodyki zarządzania (Agile), Zamawiający nie narzuca konkretnej metodyki zwinnej.
Warunkiem odbioru Systemu w wersji produkcyjnej jest możliwość wcześniejszego przetestowania i ewentualnego poprawiania wszystkich jego modułów i funkcjonalności, jego wydajności i stabilności.
Wykonawca zobowiąże się do serwisu gwarancyjnego przez cały okres trwania projektu, tj. okres co najmniej do 31 grudnia 2022.

Moduł screeningowy

Powinien umożliwiać realizację badania przesiewowego FINDRISK zgodnie z założeniami Regionalnego Programu Polityki Zdrowotnej dotyczący prewencji cukrzycy typu 2 (RPPZ) z uwzględnieniem indywidualnych modyfikacji wprowadzonych przez Zamawiającego.
Powinien posiadać interfejs graficzny dostępny z poziomu przeglądarki internetowej.
Powinien realizować proces automatycznej kwalifikacji uczestników do poszczególnych kategorii na podstawie ściśle określonych parametrów zgodnych z wymaganiami RPPZ, w szczególności pod kątem spełniania wymagań dotyczących grupy docelowej.
Powinien dokonywać szczegółowej rejestracji wszelkich wprowadzonych za jego pośrednictwem danych.
Powinien zawierać zestaw słowników realizujących podpowiedzi i automatyczne uzupełnianie wartości w polach formularza wszędzie tam, gdzie zaistnieje taka możliwość lub konieczność.
Powinien umożliwiać wybranym użytkownikom spełniającym kryteria kwalifikacji do badania OGTT dobrowolne uzupełnienie danych projektowych wymaganych na dalszych etapach procesu projektowego, w szczególności danych niezbędnych do rejestracji jako uczestnika projektu dofinansowanego z EFS zgodnie z dokumentację zawartą w Podręczniku Beneficjenta SL2014 stanowiącym załącznik nr 4 do Opisu Przedmiotu Zamówienia.
Powinien posiadać możliwość wdrożenia interfejsu API umożliwiającego dostarczenie danych screeningowych uczestników z zewnętrznego systemu Wykonawcy Medycznego, z zachowaniem wszelkich wymagań procesowych oraz kryteriów kwalifikacji.

Moduł rejestracyjno-koordynacyjny

Powinien umożliwiać realizację wszelkich procesów związanych z rejestracją pacjenta jako uczestnika projektu dofinansowanego z EFS zgodnie z dokumentację zawartą w Podręczniku Beneficjenta SL2014.
Powinien umożliwiać wypełnianie i wydruk wszelkich dokumentów formalnych wymaganych w ramach realizacji projektu dofinansowanego z EFS.
Powinien umożliwiać weryfikację i uzupełnienie danych wstępnie wypełnionych dobrowolnie przez uczestnika za pośrednictwem interfejsu modułu screeningowego.
Powinien realizować maksymalną możliwą automatyzację wypełniania dokumentacji projektowej.
Powinien umożliwiać maksymalnie zautomatyzowaną koordynację uczestnikiem w procesie udziału w każdym z etapów projektu.
Powinien dostarczać wszelkich niezbędnych informacji koordynacyjnych na temat udziału uczestnika w procesie, umożliwiających koordynację manualną wszędzie tam, gdzie nie jest możliwa automatyzacja procesu koordynacji..
Procesy i formularze związane z koordynowaniem udziału uczestników projektu na każdym jego etapie powinny zostać opracowane w oparciu o Regionalny Program Polityki Zdrowotnej dotyczący prewencji cukrzycy typu 2 stanowiący załącznik nr 1 do Opisu Przedmiotu Zamówienia.

Moduł badań medycznych

Powinien umożliwiać rejestrację wyników badania OGTT dla poszczególnych uczestników projektu na odpowiednich etapach procesu uczestnictwa, w tym poprzez dedykowany interfejs API zintegrowany z systemem laboratoryjnym Wykonawcy Medycznego (jeśli zostanie udostępniony przez Wykonawcę Med.). Powinien umożliwiać zarówno ręczną, jak i automatyczną (API) rejestrację wszelkich składowych wyniku badania OGTT.
Powinien umożliwiać realizację wszelkich procesów i procedur medycznych wymaganych przez RPPZ w tym w szczególności zaprojektowanych przez Zamawiającego w ramach opracowania procesów i procedur medycznych, w tym w szczególności:
1. rejestracja wyników OGTT wstępnych w tym x.xx.:
  1. stężenie glukozy we krwi na czczo;
  2. stężenie glukozy we krwi w 120 minucie;
2. realizacja wstępnego badania pielęgniarskiego w tym x.xx.:
  1. ocena fazy gotowości do zmiany zgodnie z transteoretycznym modelem zmiany Prochaski i DiClemente;
  2. ocena przestrzegania zaleceń terapeutycznych w skali Likerta;
  3. wprowadzenie wyników pomiarów antropometrycznych (x.xx. wysokość ciała, masa ciała, obwód talii, masa tkanki tłuszczowej, masa tkanki beztłuszczowej, zawartość wody, masa mięśni, masa tkanki kostnej, wiek metaboliczny, odsetek tkanki tłuszczowej, tętno spoczynkowe);
  4. automatyczne obliczenie BMI;
  5. automatyczna ocena masy ciała w oparciu o wytyczne WHO;
  6. automatyczna ocena otyłości brzusznej w oparciu o kryteria diagnostyczne IDF;
  7. automatyczna ocena odsetka tkanki tłuszczowej w oparciu o wytyczne WHO;
  8. wprowadzenie wyników pomiarów ciśnienia tętniczego zgodnie z wytycznymi PTNT (System powinien wymuszać poprawność realizacji procedury pomiarowej);
  9. automatyczna ocena ciśnienia tętniczego w oparciu o wytyczne PTNT;
  10. pełna procedura i algorytmy oraz automatyczna ocena poziomu aktywności fizycznej w oparciu o wytyczne badania IPAQ;
  11. pełna procedura analizy zachowań żywieniowych w zróżnicowanych skalach (ok. 20 pytań różnego rodzaju);
  12. automatyczna ocena statusu zachowań żywieniowych w oparciu o wytyczne dostarczone przez Zamawiającego;
3. realizacja wstępnego badania lekarskiego w tym x.xx.:
  1. automatyczna klasyfikacja uczestnika do odpowiedniej kategorii na podstawie wyników badania OGTT;
  2. wskazanie dodatkowych czynników wykluczających (ok. 30);
4. realizacja końcowego badania pielęgniarskiego w tym x.xx.:
  1. ocena fazy gotowości do zmiany zgodnie z transteoretycznym modelem zmiany Prochaski i DiClemente;
  2. ocena przestrzegania zaleceń terapeutycznych w skali Likerta;
  3. wprowadzenie wyników pomiarów antropometrycznych (x.xx. wysokość ciała, masa ciała, obwód talii, masa tkanki tłuszczowej, masa tkanki beztłuszczowej, zawartość wody, masa mięśni, masa tkanki kostnej, wiek metaboliczny, odsetek tkanki tłuszczowej, tętno spoczynkowe);
  4. automatyczne obliczenie BMI;
  5. automatyczna ocena masy ciała w oparciu o wytyczne WHO;
  6. automatyczna ocena otyłości brzusznej w oparciu o kryteria diagnostyczne IDF;
  7. automatyczna ocena odsetka tkanki tłuszczowej w oparciu o wytyczne WHO;
  8. wprowadzenie wyników pomiarów ciśnienia tętniczego zgodnie z wytycznymi PTNT (System powinien wymuszać poprawność realizacji procedury pomiarowej);
  9. automatyczna ocena ciśnienia tętniczego w oparciu o wytyczne PTNT;
  10. pełna procedura i algorytmy oraz automatyczna ocena poziomu aktywności fizycznej w oparciu o wytyczne badania IPAQ;
  11. pełna procedura analizy zachowań żywieniowych w zróżnicowanych skalach (ok. 20 pytań różnego rodzaju);
5. automatyczna ocena statusu zachowań żywieniowych w oparciu o wytyczne dostarczone przez Zamawiającego;,
6. realizacja końcowego badania lekarskiego (opis procedury dostarczony zostanie przez Xxxxxxxxxxxxx),
7. rejestracja wyników OGTT końcowych w tym x.xx.:
  1. stężenie glukozy we krwi na czczo;
  2. stężenie glukozy we krwi w 120 minucie.
Powinien umożliwiać wgląd lekarza w wyniki badania pielęgniarskiego.
Powinien umożliwiać transfer wszelkich danych wprowadzonych przez pielęgniarkę oraz lekarza do systemu HIS Wykonawcy Medycznego (poprzez interfejs API lub za pomocą alternatywnej metody ustalonej z Wykonawcą Medycznym na etapie wdrożenia).

Moduł edukacyjny

Powinien umożliwiać udostępnienie wybranym użytkownikom treści edukacyjnych w postaci szkoleń SCORM 1.2.
Powinien umożliwiać dostęp za pośrednictwem przeglądarki internetowej z dowolnej lokalizacji z dostępem do sieci Internet na podstawie określonych danych identyfikujących podanych przez użytkownika.
Powinien umożliwiać precyzyjną identyfikację czasu i użytkownika korzystającego z zasobów edukacyjnych oraz identyfikację użytkowanych zasobów.
Powinien umożliwiać wykonanie testów wiedzy wraz z rejestracją wszystkich udzielonych odpowiedzi, wyników testów, użytkownika oraz wszelkich pozostałych danych. Testy wiedzy oraz właściwy czas ich przeprowadzenia określone zostały w Regionalnym Programie Polityki Zdrowotnej dotyczącym prewencji cukrzycy typu 2 stanowiącym załącznik nr 1 do Opisu Przedmiotu Zamówienia.
Powinien umożliwiać precyzyjną identyfikację użytkowników, którzy zaliczą wszelkie wymagane etap/rodzaje szkoleń.

Moduł interwencji behawioralnych

Powinien umożliwiać realizację procedur związanych w wykonaniem interwencji behawioralnych wymaganych przez RPPZ oraz zaprojektowanych przez Zamawiającego w ramach opracowania procesów i procedur medycznych w tym w szczególności:
1. interwencja dietetyczna (I, II, III) w tym x.xx.:
  1. ocena fazy gotowości do zmiany zgodnie z transteoretycznym modelem zmiany Prochaski i DiClemente;
  2. ocena przestrzegania zaleceń terapeutycznych w skali Likerta;
  3. wprowadzenie wyników pomiarów antropometrycznych (x.xx. wysokość ciała, masa ciała, obwód talii, masa tkanki tłuszczowej, masa tkanki beztłuszczowej, zawartość wody, masa mięśni, masa tkanki kostnej, wiek metaboliczny, odsetek tkanki tłuszczowej, tętno spoczynkowe);
  4. automatyczne obliczenie BMI;
  5. automatyczna ocena masy ciała w oparciu o wytyczne WHO;
  6. automatyczna ocena otyłości brzusznej w oparciu o kryteria diagnostyczne IDF;
  7. automatyczna ocena odsetka tkanki tłuszczowej w oparciu o wytyczne WHO;
  8. pełna procedura analizy zachowań żywieniowych w zróżnicowanych skalach (ok. 20 pytań różnego rodzaju);
  9. automatyczna ocena statusu zachowań żywieniowych w oparciu o wytyczne dostarczone przez Zamawiającego;
2. interwencja fizjoterapeutyczna (I, II, III) w tym x.xx.:
  1. ocena fazy gotowości do zmiany zgodnie z transteoretycznym modelem zmiany Prochaski i DiClemente;
  2. ocena przestrzegania zaleceń terapeutycznych w skali Likerta;
  3. pełna procedura oceny tolerancji wysiłku oraz automatyczna ocena wyniku zgodnie z procedurą YMCA ST;
  4. pełna procedura i algorytmy oraz automatyczna ocena poziomu aktywności fizycznej w oparciu o wytyczne badania IPAQ;
  5. subiektywna ocena wg skali Borga CR10;

Moduł statystyczny

Powinien umożliwiać wyświetlanie aktualnych oraz historycznych danych statystycznych z wybranego, dowolnie definiowanego okresu czasu w odniesieniu do poszczególnych danych uczestników zgromadzonych w Systemie, w szczególności:
- liczbę uczestników z określonym statusem;
- liczbę i rodzaj świadczeń zrealizowanych przez Wykonawcę Medycznego w tym x.xx.:
  - liczbę uczestników, którzy odbyli szkolenie wstępne on-line;
  - liczbę i szczegółowe wyniki wstępnych badań OGTT;
  - liczbę i wybrane wyniki wstępnych badań pielęgniarskich;
  - liczbę i wybrane dane z wstępnych badań lekarskich;
  - liczbę i wybrane wyniki końcowych badań pielęgniarskich;
  - liczbę i wybrane wyniki pierwszej, drugiej oraz trzeciej interwencji dietetycznej;
  - liczbę i wybrane wyniki pierwszej, drugiej oraz trzeciej interwencji fizjoterapeutycznej;
  - liczbę i wybrane dane z końcowych badań lekarskich;
  - liczbę i szczegółowe wyniki końcowych badań OGTT;
  - liczbę uczestników, którzy odbyli szkolenie końcowe on-line;
- liczbę i szczegółowe wyniki ankiet FINDRISK;
Powinien umożliwić uzyskanie dokładnych danych liczbowych niezbędnych do celów sprawozdawczości mierników efektywności Regionalnego Programu Polityki Zdrowotnej dotyczącej prewencji cukrzycy typu 2 opisanych w załączniku nr 1 do Opisu Przedmiotu Zamówienia.
Wszelkie informacje statystyczne powinny być realizowane z zachowaniem anonimizacji oraz wytycznych RODO.
Powinien umożliwiać szczegółową weryfikację statusu każdego z uczestników projektu na każdym jego etapie, w tym daty uzyskania poszczególnych statusów.

Powinien umożliwiać precyzyjną kontrolę nad wykorzystanymi środkami finansowymi poprzez automatyczną analizę i monitorowanie wykorzystanych zasobów i usług zrealizowanych na poczet uczestników projektu na każdym z jego etapów.
Powinien umożliwiać realizację horyzontalnych i wertykalnych zestawień, tj. umożliwiających analizę zasobów wykorzystanych w podziale na poszczególnych użytkowników oraz użytkowników którzy skorzystali z określonego zasobu lub usługi.
Powinien umożliwiać przypisanie określonych stawek finansowych dla kosztów poszczególnych zasobów i usług (świadczeń) dostarczanych uczestnikom projektu.
Powinien umożliwiać elastyczne pozyskiwanie szczegółowych raportów finansowych umożliwiających okresowe rozliczanie usług zrealizowanych przez Wykonawcę Medycznego w trakcie trwania całego projektu, w tym w szczególności:
- wstępnych szkoleń (każda z form);
- badań OGTT wstępnych;
- badań OGTT końcowych;
- wstępnych badań pielęgniarskich;
- wstępnych badań lekarskich;
- I, II i III interwencji dietetycznej;
- I, II i III interwencji fizjoterapeutycznej;
- końcowych badań pielęgniarskich;
- końcowych badań lekarskich;
- badań OGTT końcowych;
- końcowych szkoleń (każda z form).

Moduł repozytorium

Powinien umożliwiać ładowanie, przechowywanie, zarządzanie i usuwania plików cyfrowych wszelkiego typu.
Powinien umożliwiać tworzenie reguł udostępniania określonych plików określonym typom użytkowników w określonych momentach czasu, lub miejscach w procesie uczestnictwa w projekcie.

Moduł sprawozdawczy

Powinien umożliwiać integrację i komunikację za pomocą API lub alternatywną metodą eksportu danych za pomocą plików CSV z systemem Aplikacji głównej SL2014 w zakresie przesyłania danych związanych z realizacją i rozliczaniem dofinansowania (w szczególności w zakresie uczestników otrzymujących wsparcie). Dokumentacja integratora API systemu SL2014 oraz Podręcznik Beneficjenta SL2014 stanowią załączniki nr 2 i nr 3 do Opisu Przedmiotu Zamówienia.
Dane sprawozdawcze powinny pochodzić właściwych modułów Systemu i być poddane szczegółowej automatycznej weryfikacji przed realizacją wysyłki do SL2014.
Powinien umożliwiać generowanie i eksportowanie do plików (CSV) szczegółowych zestawień danych uczestników, którzy uzyskali jakikolwiek rodzaj świadczeń w wybranym, dowolnie definiowanym okresie czasu, wraz ze szczegółową informacją na temat uzyskanego świadczenia, w tym x.xx.:
- wstępnych szkoleń;
- badań OGTT wstępnych;
- badań OGTT końcowych;
- wstępnych badań pielęgniarskich;
- wstępnych badań lekarskich;
- I, II i III interwencji dietetycznej;
- I, II i III interwencji fizjoterapeutycznej;
- końcowych badań pielęgniarskich;
- końcowych badań lekarskich;
- badań OGTT końcowych;
- końcowych szkoleń.

HOSTING SYSTEMU

Minimalne wymagania dla Infrastruktury

Wykonawca zobowiązany jest do zapewnienia co najmniej niżej wymienionej Infrastruktury dedykowanej dla Systemu:

Dwa serwery fizyczne dedykowany tylko i wyłącznie do realizacji przedmiotu zamówienia, każdy z osobna zapewniający minimum:
1. 4 rdzenie / 8 wątków o częstotliwości minimalnej 3GHz
2. przestrzeń pamięci 32 GB RAM DDR4
3. przestrzeń na dyski systemowe o łącznej powierzchni minimum 2x2TB
4. sprzętowa macierz RAID
5. redundantny zasób dyskowy klasy NVMe dla baz danych o powierzchni minimum 2x240GB
6. karty sieciowe 1Gbit w każdej zastosowanej maszynie fizycznej
7. redundantne zasilacze hot-swap
Serwery, na których zainstalowane zostanie System, muszą znajdować się w obiekcie datacenter (serwerownia) o parametrach odpowiadających minimum klasie Tier 3 według normy TIA-942.
Obiekt datacenter (serwerownia) musi znajdować się na terenie Polski.
Redundantne łącze do Internetu o przepustowości minimum 1Gbit/s bez limitu danych.
Maszyny wirtualne dedykowane dla baz danych mysql/mariadb muszą funkcjonować w modelu replikacji typu Active-Active
Maszyny wirtualne dedykowane dla serwerów aplikacyjnych muszą mieć zainstalowany php w wersji co najmniej 7.2
Serwer www - Nginx w wersji najnowszej stabilnej
Preferowana dystrybucja systemu operacyjnego to Debian w wersji min. 9.8
Przygotowania usługi hostowania Systemu z ewentualną jej rekonfiguracją tak, aby dostępne były usługi: www, baza danych SQL, zabezpieczenie przed nieautoryzowanym dostępem, itp.
Administrowania serwerami, w szczególności systemami operacyjnymi, SQL, administrowanie strukturą katalogów, instalacja certyfikatów SSL.
Wykonywania kopii zapasowych. Cykliczny backup, wykonywany nie rzadziej niż raz na dobę z retencją 2 tygodnie. Zamawiający wymaga posiadania kopii zapasowej pozwalającej na powrót do stanu sprzed 24 godzin. Zamawiający wymaga by kopia zapasowa była przechowywana z wykorzystaniem odrębnej infrastruktury, nie używanej na potrzeby hostowania Systemu. Zamawiający wymaga by system wykonywania kopii zapasowych umożliwiał całościowe i selektywne odzyskiwanie danych, zarówno w zakresie całych maszyn, jak i poszczególnych plików.
Udostępnienia Systemu, zgodnie z zasadami i warunkami świadczenia usług dla Systemu (warunki SLA).
Wszystkie licencje niezbędne do realizacji przedmiotu zamówienia dostarcza Wykonawca bez dodatkowych opłat w ramach wynagrodzenia określonego w Umowie.
Dostęp do odczytu Systemu z sieci Internet - polega na możliwości odczytania stron statycznych i dynamicznych serwisów przez przeglądarkę komputera dołączonego do sieci Internet dowolnego operatora krajowego i zagranicznego.
Uwierzytelnienie dostępu do modyfikacji Systemu dla wytypowanych pracowników i podwykonawców Zamawiającego - polega na poprawnej weryfikacji uprawnień i otwarciu zabezpieczeń w dostępie do uzgodnionej w trybie roboczym zawartości dysków serwerów.
Zapewnienie możliwości dostępu do modyfikacji Systemu dla określonych aplikacji działających po stronie Zamawiającego, zgodnie z ustalonymi protokołami - polega na otwarciu zabezpieczeń w dostępie do uzgodnionej w trybie roboczym zawartości dysków serwerów dla serwerów o określonych adresach IP i jedynie dla ustalonych protokołów komunikacyjnych.
Dostęp do odczytu i modyfikacji produkcyjnych Systemu dedykowanym kanałem szyfrowanym (VPN) z uprawnionych stanowisk znajdujących się u Zamawiającego oraz wskazanych przez Zamawiającego podwykonawców pod nadzorem Wykonawcy - polega na możliwości odczytania lub zapisania dowolnego pliku Systemu z komputerów dołączonych do Sieci WAN Zamawiającego zgodnie z przydzielonymi uprawnieniami za pomocą VPN.
Ochrona zawartości Systemu przed niepożądanym dostępem - polega na niedopuszczeniu do modyfikacji Systemu przez nieuprawnionych użytkowników, a jeżeli takie zjawisko nastąpi, na dokładnym monitorowaniu i udaremnieniu takiej próby. Sprawdzenie tej funkcji może być wykonane:
1. na podstawie analizy zapisów zdarzeń serwera i firewalla oraz monitoringu on-line. Wymagane są funkcjonalności Web Application Firewall.
2. na podstawie testów penetracyjnych realizowanych na zlecenie Zamawiającego przez firmę trzecią. Zamawiający w takim przypadku poinformuje Wykonawcę o planowanej dacie przeprowadzenia testów z min. 7 dniowym wyprzedzeniem
Zapewnienie mechanizmu ochrony Systemu – polegającego na blokowaniu adresów IP powodujących największe obciążenie Systemu w danej jednostce czasu. Sprawdzenie tej funkcji może być wykonana na podstawie testów realizowanych na zlecenie Zamawiającego przez firmę trzecią. Zamawiający w takim przypadku poinformuje Wykonawcę o planowanej dacie przeprowadzenia testów z min. 7 dniowym wyprzedzeniem.
Przygotowanie i przekazanie do Zamawiającego statystyk pracy Systemu zgodnie z wymaganiami dla statystyk pracy Systemu określonych w dalszej części OPZ.
Utrzymywanie połączeń telekomunikacyjnych pomiędzy serwerami Wykonawcy oraz Internetem – zapewnienie łączy pozwalających na publikację Systemu w sieci Internet.

Minimalne wymagania dla serwerów DNS:

Zapewnienie dwóch różnych serwerów DNS o różnych publicznych adresach IP w celu delegacji domen wskazanych przez Zamawiającego.
Zamawiający musi mieć możliwość dodawania do serwerów DNS nowych domen lub poddomen. Kreowanie nowych domen lub poddomen przez Zamawiającego w konfiguracji serwerów DNS Wykonawcy będzie odbywało się z wykorzystaniem udostępnionego Zamawiającemu przez Wykonawcę panelu WWW.
Dostęp do panelu musi być zabezpieczony i odbywać się poprzez kanał szyfrowany.
Panel musi umożliwiać:
1. pełną obsługę w zakresie modyfikacji istniejących domen i subdomen oraz kreowanie nowych rekordów DNS
2. mechanizm ustawiania uprawnień dla logującego się użytkownika Zamawiającego do odczytu, modyfikacji, usuwania rekordów DNS w ramach domeny i jej subdomen.

Wymagania związane z bezpieczeństwem

W ramach świadczenia usługi hostingu Wykonawca zobowiązany jest do zapewnienia bezpieczeństwa dla hostowanego Systemu, przynajmniej z wykorzystaniem poniższych systemów:

WAF - Usługa polegająca na dostarczeniu rozwiązania Wall Application Firewall w postaci dedykowanego oprogramowania lub hardware:
1. Rozwiązanie będzie udostępniać funkcjonalności:
  1. pełne logowanie ruchu http/ HTTPS
  2. możliwość bezpośredniej integracji z Apache i ngnix
  3. możliwość pracy z każdym serwerem Web jako Reverse Proxy
  4. wsparcie dla wykrywania nieprawidłowości i słabości w zabezpieczeniach, które nie zostały jeszcze wykorzystane
  5. możliwość zasłaniania potencjalnych słabości/podatności po stronie aplikacji bez konieczności tworzenia czasochłonnych poprawek systemowych
2. Rozwiązanie musi być wyposażone w gotowe reguły filtracyjne (aktualizowane codziennie) umożliwiające ochronę przez znanymi zagrożeniami, w ramach których można wymienić:
  1. SQL Injection (SQLi)
  2. Cross Site Scripting (XSS)
  3. Local File Inclusion (LFI)
  4. Remote File Inclusion (RFI)
  5. Remote Code Execution (RCE)
  6. PHP Code Injection
  7. HTTP Protocol Violations
  8. HTTPoxy
  9. Shellshock
  10. Session Fixation
  11. Scanner Detection
  12. Metadata/Error Leakages
  13. Project Honey Pot Blacklist
  14. GeoIP Country Blocking
3. Rozwiązanie musi umożliwiać tworzenie własnych reguł.
4. Rozwiązanie musi wspierać mechanizmy bezpieczeństwa uwzględniające:
  1. reputację IP
  2. wykrywanie złośliwego oprogramowania na bazie ruchu Web
  3. wykrywanie złośliwego oprogramowania typu backdoor
  4. wykrywanie ataków typu Botnet
  5. wykrywanie ataków typu HTTP Denial of Service (DoS)
  6. Anti-Virus w zakresie plików
5. Rozwiązanie musi mieć możliwość wspierania technik wykrywania ataków:
  1. ochrona ruchu HTTP - wykrywanie naruszeń protokołu HTTP oraz lokalnie zdefiniowanych zasad użytkowania
  2. wykrywanie znanych ataków na aplikacje Web
  3. automatyzacja detekcji – Wykrywanie robotów, skanerów oraz innej złośliwej aktywności
  4. ochrona przed zagrożeniami typu koń trojański
  5. Ukrywanie komunikatów o błędach wysyłanych przez serwery
Anty DDoS - usługa musi pozwalać na skuteczne identyfikowanie oraz izolowanie podejrzanego ruchu w zakresie ataków typu DDoS. (np. sinkholing) Usługa musi być świadczona w dwóch warstwach dostępowych:
1. warstwa pierwsza – operator telekomunikacyjny – Wykonawca musi posiadać stosowne umowy z operatorami telekomunikacyjnymi w celu ochrony własnej sieci przed atakami wolumetrycznymi o bardzo dużym nasileniu mogącymi w skrajnym przypadku wysycić w całości łącze operatora. W takim przypadku ochrona jest realizowana w warstwie operatora.
2. warstwa druga – Wykonawca musi posiadać własne rozwiązanie przed atakami DDoS dzięki czemu jest wstanie w całości zarządzać konfiguracją filtrów i poziomów ochrony. Zastosowane rozwiązanie musi spełniać funkcję drugiej warstwy ochrony operującą w ramach ataków wolumetrycznych w warstwie 3 i 4 modelu IOS/OSI.
Ochrona DNS – Wykonawca musi zapewnić mechanizmy zabezpieczeń usługi DNS przed zagrożeniami takimi jak:
1. Cache poisoning,
2. DNS amplification,
3. Fast-flux DNS,
4. DoS,
5. DDoS,
6. DNS tunnelling,
7. TCP SYN floods,
8. Distributed reflection DDoS.

Warunki SLA

Zasady i warunki świadczenia usług dla Serwisów świadczone będą przez Wykonawcę ze szczególnym uwzględnieniem:

poziomu obsługi,
parametrów jakościowych,
procedur postępowania w usuwaniu Usterek i Awarii,
zasad naliczania kar umownych za niedotrzymanie poziomu obsługi.

Wykonawca zobowiązuje się do świadczenia Usług o parametrach jakościowych zadeklarowanych w złożonej ofercie, jednak nie gorszych niż:
1. Okres gotowości: 24 godziny na dobę przez wszystkie dni w roku.
2. Dostępność: 99,7%.
3. Usunięcie usterki: 6 godzin.
Za przyjmowanie zgłoszeń o Usterkach i Awariach odpowiadać będzie Biuro Obsługi Klienta (BOK).
Wykonawca zobowiązany będzie do zapewnienia działania BOK w systemie 24/7/365 (dwadzieścia cztery godziny na dobę przez wszystkie dni w roku).
Definicje:
1. Awaria – Brak dostępności Serwisów WWW lub dostępności do Serwisów WWW albo dostęp ograniczający korzystanie z Serwisów WWW lub każda nieuprawniona zmiana treści serwisów internetowych dokonana przez osoby nieuprawnione.
2. BOK – Biuro Obsługi Klienta.
3. Czas Reakcji – jest to czas od zgłoszenia Usterki lub Awarii przez Zamawiającego do podjęcia czynności rejestracyjnych przez BOK i poinformowania Zamawiającego o przyjęciu Zgłoszenia.
4. Dostępność Serwisów (DS) - jest parametrem wyrażonym procentowo obliczanym wg poniższego wzoru:

𝑂𝑘𝑟𝑒𝑠𝑃𝑜𝑚𝑖𝑎𝑟𝑜𝑤𝑦 −Σ(𝑂𝑘𝑟𝑒𝑠𝑁𝑖𝑒𝑑𝑜𝑠𝑡ę𝑝𝑛𝑜ś𝑐𝑖−𝑂𝑘𝑟𝑒𝑠𝑊𝑦ł𝑎𝑐𝑧𝑜𝑛𝑦)
DS = ------------------------------------------------------------------------------------------ x 100
𝑂𝑘𝑟𝑒𝑠𝑃𝑜𝑚𝑖𝑎𝑟𝑜𝑤𝑦

Okres Pomiarowy - jest to okres pełnego miesiąca kalendarzowego wyrażony w minutach.
Okres Niedostępności – okres niedostępności Serwisów wyrażony w minutach w trakcie Okresu Pomiarowego. Okres Niedostępności mierzony jest na podstawie monitoringu niedostępności stron Serwisów z systemów zewnętrznych kontrolujących niedostępność stron internetowych Serwisów w sieci Internet. System jest niedostępny, jeśli co najmniej trzy punkty pomiarowe w sieci Internet, wykażą równoczesną nieosiągalność strony internetowej Serwisów.
Okres Wyłączony - jest to łączny czas trwania przerw w dostępności Serwisów, wyrażony w minutach w Okresie Pomiarowym spowodowanych przyczynami określonymi w rozdziale „Planowane prace serwisowe” oraz postępowaniem Zamawiającego przedłużającym czas usuwania Awarii. Są to przerwy, których czas trwania nie wlicza się do obliczania parametru Dostępności Serwisów.
SLA – Service Level Agreement - niniejszy dokument określający zasady i warunki świadczenia usług dla Serwisów WWW („Warunki SLA”).
Usterka – Zdarzenie zagrażające, również potencjalnie, prawidłowemu świadczeniu jednej lub wielu funkcji Systemu, niestanowiące zagrożenia dla utrzymania krytycznych procesów Systemu, ale wnoszące utrudnienia do jego eksploatacji.
Niedostępność Systemu – sytuacja, kiedy System lub którakolwiek jego część, jest niedostępna dla użytkowników.

Zakres świadczonych Usług:
1. Mając na względzie krytyczny charakter funkcjonowania Systemu dla celów realizacji działań Zamawiającego, Wykonawca zobowiązuje się świadczyć Usługi z zachowaniem najwyższej profesjonalnej staranności.
2. Strony ustalają następujące parametry monitorowania:
  1. Częstotliwość odpytywania Serwisów wynosi jedną minutę.
  2. Lista Serwisów (max. 10), o których mowa powyżej zostanie dostarczona Wykonawcy w chwili podpisania umowy i może ulegać zmianie. Zmiana taka nie będzie wymagać formy aneksu do Umowy, a jedynie pisemnego poinformowania Wykonawcy.
  3. Zamawiający monitoruje dostępność stron za pomocą co najmniej trzech punktów monitorowania.

Procedura postępowania w sytuacjach awaryjnych

Usterka, Awaria lub przerwa w dostępności Systemu.

Zgłoszenie Usterki lub Awarii:
1. Zgłoszenia Usterki lub Awarii przyjmuje BOK przez całą dobę we wszystkie dni w roku. Usterki i Awarie zgłaszane są e-mailem na adres poczty elektronicznej Wykonawcy wskazany w umowie.
2. Zgłaszający Usterkę lub Awarię powinien przedstawić następujące informacje:
  1. swoje imię, nazwisko, oraz numer telefonu kontaktowego,
  2. opis objawów Usterki lub Awarii i czas jej wystąpienia.
Przyjęcie zgłoszenia Usterki lub Awarii
1. BOK rejestruje zgłoszenie Usterki lub Awarii i za pośrednictwem poczty e-mail potwierdza Zamawiającemu przyjęcie zgłoszenia.
2. Czas rozpoczęcia Usterki lub Awarii jest liczony od potwierdzenia przyjęcia zgłoszenia przez Wykonawcę.
Podjęcie działań naprawczych przez pracowników Wykonawcy
1. Pracownik Wykonawcy jest zobowiązany do kontaktu ze zgłaszającym Usterkę lub Awarię w celu przekazania informacji o podjęciu działań naprawczych.
Usunięcie Usterki.
1. Wykonawca usunie zgłoszoną Usterkę w czasie nieprzekraczającym 6 godzin.
Usunięcie Awarii.
1. Wykonawca niezwłocznie usunie zgłoszoną Awarię. Czas usunięcia awarii uwzględniony jest w obliczeniu dostępności Serwisów i powiązany z opisanym powyżej parametrem dostępności dotyczącym danego produktu, stanowi podstawę do naliczenia ewentualnych kar umownych.

Planowane prace serwisowe

Zamawiający dopuszcza możliwość czasowego wyłączenia przez Wykonawcę urządzeń z eksploatacji w celu przeprowadzenia testów lub innych niezbędnych prac serwisowych związanych z zapewnieniem poprawnej pracy Systemu. W przypadku, gdy wyżej wymienione prace mogą spowodować przerwy w korzystaniu przez Zamawiającego z Systemu, termin i czas trwania czasowego wyłączenia urządzeń będą każdorazowo wymagały zgody Zamawiającego.
Prace serwisowe mogą się odbywać jedynie w godzinach 22:00-6:00.
O powyższych pracach Wykonawca jest zobowiązany poinformować Zamawiającego i uzyskać jego zgodę, na co najmniej 5 dni roboczych przed terminem rozpoczęcia prac.
Czas przerw z tytułu planowanych prac serwisowych nie będzie uwzględniany do obliczania parametrów jakościowych, mających wpływ na wielkość kar umownych.

Załączniki

Załącznik nr 1 – (RPPZ) Regionalny Program Polityki Zdrowotnej dotyczący prewencji cukrzycy typu 2
Załącznik nr 2 – Dokumentacja integratora API systemu SL2014
Załącznik nr 3 – Podręcznik Beneficjenta SL2014

Document Metadata

Table of Contents

Opis Przedmiotu Zamówienia

Document Metadata