Opis Przedmiotu Zamówienia

a) Portal PSBK – Podstawowym zadaniem portalu będzie prezentowanie w sposób jak najbardziej ergonomiczny dla pracowników ABM oraz członków PSBK informacji o realizowanych badaniach klinicznych w ośrodkach należących do PSBK. Ponadto Portal PSBK ma umożliwić wymianę wiedzy, doświadczeń oraz stanowić platformę do komunikacji pomiędzy Sygnatariuszami Porozumienia w sprawie utworzenia Polskiej Sieci Badań Klinicznych.

b) System eCRF ABM umożliwi przygotowanie, wytwarzanie, konfigurację, udostępnienie oraz utrzymanie usystematyzowanego zestawu formularzy do zapisu wymaganych protokołem badania klinicznego informacji o każdym uczestniku badania - elektronicznej Karty Obserwacji Pacjenta (ang. eCRF, Electronic Case Report Form). ABM będzie nadawał dostęp do systemu poszczególnym użytkownikom systemu. System eCRF ma pozwolić uruchomić dowolną liczbę instancji pod wiele różnych badań prowadzonych przez różne ośrodki.

Zakładana wizja działania Systemu eCRF ABM w ramach prowadzonego badania klinicznego:

• Użytkownik przygotowuje wzór elektronicznej karty obserwacji pacjenta zgodnie z wymaganiami protokołu badania klinicznego.

• Akceptacja wzoru przez Głównego Badacza lub osobę przez niego wyznaczoną.

• Rozpoczęcie badania klinicznego.

• Rozpoczęcie rekrutacji uczestników do badania klinicznego.

• Uzupełnianie indywidualnej elektronicznej karty obserwacji pacjenta danymi pozyskiwanymi w trakcie badania klinicznego.

• Zakończenie badania klinicznego.

• Zamknięcie bazy danych badania klinicznego.

• Przekazanie danych do sponsora badania klinicznego.

• Przez cały okres trwania badania klinicznego i po jego zakończeniu ABM na bieżąco będzie miał wgląd w postęp realizacji badania klinicznego.

2. Słownik

2.1. Definicje

Ilekroć w niniejszej OPZ zostanie użyte którekolwiek z poniższych słów pisane dużą literą, intencją Zamawiającego jest interpretowanie danego słowa zgodnie z poniższymi definicjami:

• Administrator Systemu Teleinformatycznego PSBK – Osoba pełniąca funkcję administratora wykonanego systemu PSBK, mająca za zadanie nadawanie uprawnień użytkownikom i ich szkolenie, kontrolowanie funkcjonowania systemu PSBK w celu ochrony i bezpieczeństwa zasobów użytkowników i zasobów systemowych oraz czuwanie nad niezawodnością i maksymalną wydajnością działania systemu.

• Aplikacja - Oprogramowanie użytkowe, oprogramowanie aplikacyjne, każdy samodzielny program lub element pakietu oprogramowania, który nie jest zaliczany do oprogramowania systemowego lub programów usługowych (narzędziowych).

• Awaria - Wada polegająca na braku działania Systemu lub nieprawidłowym funkcjonowaniu Systemu powodującym zawieszanie się pracy Systemu lub sytuację, w której System w ogóle nie funkcjonuje.

• Błąd – dysfunkcja powodująca że System działa:

1. niezgodnie z dokumentacją,

2. błędnie w wyniku awarii sprzętu,

3. błędnie w wyniku działania oprogramowania systemowego,

4. błędnie w wyniku niewłaściwej obsługi.

• Błąd Krytyczny – Wada polegająca na nieprawidłowym funkcjonowaniu Systemu, w tym działanie niezgodne z Dokumentacją, skutkujące niemożnością uzyskania dostępu przez użytkowników do danych, niemożnością realizacji głównych zadań Systemu PSBK lub brakiem dostępu do danych niezbędnych dla realizacji tych zadań.

• Błąd Ważny - Wada polegająca na nieprawidłowym funkcjonowaniu Systemu, w tym działanie niezgodne z Dokumentacją, skutkujące błędnymi zapisami w bazie danych Systemu lub błędnym albo nieskutecznym wprowadzaniem, przetwarzaniem lub wyprowadzaniem informacji.

• CWBK – Centrum Wsparcia Badań Klinicznych utworzone przez Beneficjenta konkursu na „Tworzenie i rozwój Centrów Wsparcia Badań Klinicznych”.

• Czas Naprawy – czas, jaki upłynął od pierwszego kontaktu z Zamawiającym w sprawie zgłoszenia Wady do przywrócenia bezbłędnej pracy w środowisku produkcyjnym.

• Czas Reakcji – czas, jaki upłynął od przyjęcia zgłoszenia przez Wykonawcę do pierwszego kontaktu z Zamawiającym w zgłaszanej sprawie.

• Xxxx Xxxxxxx – Dane osobowe w rozumieniu ustawy z dnia z ustawą z dnia

10 maja 2018 r. o ochronie danych osobowych oraz Rozporządzenia Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (RODO).

• Dokumentacja – wszelkie dokumenty sporządzone samodzielnie przez Wykonawcę, przekazywane Zamawiającemu lub przygotowane wspólnie z Zamawiającym. Obejmuje w szczególności: ~~Plan Realizacji Przedsięwzięcia~~, Szczegółowy Harmonogram, analizę przedwdrożeniową, dokumentację użytkową Systemu – do każdego Modułu, techniczną dokumentację powdrożeniową.

• Dokumenty Poufne – Dokumenty stanowiące Tajemnicę Przedsiębiorstwa.

• Dzień – wszędzie, gdzie mowa o dniu, Strony dla uniknięcia wątpliwości mają na myśli dzień kalendarzowy.

• Dzień Roboczy – to każdy dzień od poniedziałku do piątku z wyłączeniem dni ustawowo wolnych od pracy.

• eCRF – Elektroniczna Karta Obserwacji Klinicznej – to elektroniczny kwestionariusz specjalnie używany w badaniach klinicznych. Formularz opisu przypadku jest narzędziem wykorzystywanym przez sponsora badania klinicznego do zbierania danych od każdego uczestniczącego pacjenta. Wszystkie dane dotyczące każdego pacjenta uczestniczącego w badaniu klinicznym są przechowywane i/lub udokumentowane w eCRF, w tym zdarzenia niepożądane.

• Gwarancja – udzielona przez Wykonawcę, w ramach wynagrodzenia gwarancja jakości działania Systemu, w ramach której Wykonawca zobowiązany jest do usuwania Wad w Systemie na warunkach oraz w zakresie opisanym w OPZ. Gwarancja zostanie również udzielona na dostarczony przez Wykonawcę sprzęt.

• Kierownik Projektu – osoba wyznaczona przez ABM do pełnienia funkcji Kierownika Projektu Systemów Teleinformatycznych PSBK.

• Kierownik Projektu Wykonawcy – osoba wyznaczona przez Wykonawcę do pełnienia funkcji Kierownika Projektu Wykonawcy.

• Kod randomizacyjny – indywidualny i specyficzny kod nadawany pacjentowi w procesie randomizacji, czyli procedurze doboru uczestników badania do grupy otrzymującej produkt badany lub grupy kontrolnej w sposób losowy.

• Konfiguracja systemu – dokonanie wyboru oraz ustawienie zestawu parametrów Systemu pozwalające sterować działaniem Systemu w zakresie opisanym w Dokumentacji Powykonawczej. Konfiguracja dotyczy zarówno Oprogramowania Dedykowanego, jak i oprogramowania firm trzecich .

• Opis Przedmiotu Zamówienia (OPZ) – niniejszy Zestaw wymagań i parametrów technicznych dla poszczególnych elementów Systemu PSBK.

• Oprogramowanie Dedykowanego – program komputerowy stworzony na potrzeby działania Systemu Teleinformatycznego PSBK, o ile Wykonawca wykaże, że jest ono niezbędne do prawidłowego działania Systemu teleinformatycznego PSBK.

• Ośrodek PSBK – podmiot, uprawniony do prowadzenia czynności związanych z badaniem klinicznym, na mocy Porozumienia, należący do Polskiej Sieci Badań Klinicznych. Członkami Polskiej Sieci Badań Klinicznych są: instytuty badawcze uczestniczące w systemie ochrony zdrowia, uczelnie publiczne uprawnione do prowadzenia kształcenia na kierunku lekarskim, podmioty lecznicze utworzone przez Skarb Państwa reprezentowany przez ministra, centralny organ administracji rządowej albo jednostki samorządu terytorialnego, które posiadają kontrakt z NFZ.

• Poprawki - to zmiany oprogramowania, naprawiające Wady produktu, które ujawniły się po jego sprzedaniu. Wady te powodują, że program nie posiada gwarantowanych przez Wykonawcę funkcjonalności. Dokonywane w ramach gwarancji.

• Prawo zamówień publicznych – PZP – ustawa z dnia 11 września 2019 r. Prawo zamówień publicznych.

• Protokół Odbioru Etapu – dokument stwierdzający dostarczenie Rezultatu Prac w ramach danego Etapu.

• Protokół Odbioru Końcowego – dokument potwierdzający prawidłową realizację przedmiotu Umowy, sporządzony przez Strony po przeprowadzeniu Testów Końcowych. Protokół zostanie podpisany przez Zamawiającego po zakończeniu realizacji.

• Protokół Odmowy Odbioru – dokument stwierdzający fakt nieprawidłowej realizacji Etapu, wskazujący na Wady i określający termin ich usunięcia.

• PSBK – Polska Sieć Badań Klinicznych utworzona na mocy Porozumienia, którego sygnatariuszami są Beneficjenci konkursów na utworzenie i wsparcie Centrów Wsparcia Badań Klinicznych oraz Agencja Badań Medycznych. Celem działalności Xxxxx jest współpraca pomiędzy instytucjami ją tworzącymi, polegająca na sprawnej wymianie informacji, doświadczeń, wspólnym opracowaniu narzędzi informatycznych dedykowanych badaniom klinicznym, tworzeniu procedur i dokumentów oraz zarządzaniu badaniami.

• Raport Modyfikacyjny – dokument podsumowujący wykonane modyfikacje w Systemie Teleinformatycznym PSBK.

• Siła Wyższa – zdarzenie, o którym mowa w treści projektowanych postawień Umowy.

• SWZ – Specyfikacja Warunków Zamówienia na system teleinformatyczny PSBK.

• Sprzęt – sprzęt dostarczony przez Wykonawcę w celu umożliwienia pełnej funkcjonalności przedmiotu niniejszego zamówienia.

• System teleinformatyczny PSBK, System PSBK, System – rozwiązanie teleinformatyczne będące przedmiotem zamówienia.

• System zarządzania treścią – oprogramowanie pozwalające na łatwe utworzenie i prowadzenie serwisu WWW, a także jego późniejszą aktualizację i rozbudowę, również przez redakcyjny personel nietechniczny.

• Tajemnica Przedsiębiorstwa – dokumenty poufne, dokumenty stanowiące tajemnicę przedsiębiorstwa w rozumieniu ustawy z dnia 16 kwietnia 1993 r. o zwalczaniu nieuczciwej konkurencji.

• Testy Końcowe – testy przeprowadzone przez Xxxxxxxxxxxxx wraz z powołanym zespołem eksperckim, które nastąpią po oddaniu przez Wykonawcę przedmiotu zamówienia do odbioru końcowego. W przypadku nieprzedstawienia przez Wykonawcę przedmiotu zamówienia do odbioru, Zamawiający przystąpi do testów zgodnie ze Szczegółowym Harmonogramem.

• Umowa – Umowa zawarta w wyniku przeprowadzenia niniejszego postępowania o udzielenie zamówienia wraz ze wszystkimi załącznikami, w tym załącznikami z Dokumentacją Przetargową.

• Usterka – w szczególności działanie niezgodne z Dokumentacją lub inna przyczyna niedziałania Systemu niż Awaria, Błąd Krytyczny lub Błąd Ważny polegająca na nieprawidłowym funkcjonowaniu Systemu, nieograniczająca zakresu funkcjonalnego Systemu, ale utrudniająca pracę Użytkownikom.

• Użytkownik Systemu (Użytkownik/Użytkownik zalogowany/Użytkownik zarządzający) – osoba posiadający dostęp do modułów Systemu (funkcji, widoków, pól lub wydzielonych grup/podzbiorów danych) w zakresie przyznanych mu uprawnień opisanych w OPZ.

• Wada – nieprawidłowe działanie sprzętu, Systemu lub jego elementu, w szczególności działanie niezgodne z jego Dokumentacją lub podstawowymi założeniami działania sprzętu lub systemu. Wada może mieć postać Awarii, Błędu Krytycznego, Błędu Ważnego, Usterki.

• Wsparcie powdrożeniowe – obejmuje pełny zakres usług techniczno- programowych służących do obsługi, nadzoru poprawności działania Systemu Teleinformatycznego PSBK, wsparcia programowego, dostosowania do zmian przepisów prawa a także rozwój dodatkowych funkcjonalności w ramach zaplanowanych godzin programistycznych.

2.2. Skróty

• ABM – Agencja Badań Medycznych,

• CPU – ang. central processing unit, centralna jednostka przetwarzająca,

• CRO – ang. Clinical Research Organization, Contract Research Organization,

organizacja prowadząca badanie kliniczne na zlecenie,

• CRP – ang. C-reactive protein, białko C-reaktywne,

• CTCAE – ang. Common Terminology Criteria for Adverse Events, powszechne kryteria terminologiczne dla zdarzeń niepożądanych,

• CWBK – Centrum Wsparcia Badań Klinicznych,

• DQ – ang. Design Qualification, Kwalifikacja Projektowa,

• EAN – ang. European Article Number, Europejski Kod Towarowy,

• eCRF – ang. electronic case report form, elektroniczna karta obserwacji pacjenta,

• EDC – ang. Electronic Data Capture, Elektroniczne pozyskiwanie danych

• EEG – elektroencefalografia,

• FAT – ang. Factory Acceptance Tests, fabryczne testy akceptacyjne,

• FTPS – ang. File Transfer Protocol, Zabezpieczony Protokół transferu plików

• GAMP5 – ang. Good Automated Manufacturing Practice,

• GMP – ang. Good Manufacturing Practice, Xxxxx Xxxxxxxx Wytwarzania,

• GUI – ang. graphical user interface, graficzny interfejs użytkownika,

• ICD-10 – ang. International Classification of Diseases Tenth Revision, Międzynarodowa Klasyfikacja Chorób wersja 10,

• ICD-9 – ang. International Classification of Diseases Ninth Revision,

Międzynarodowa Klasyfikacja Chorób wersja 9,

• ICD-O-3 – ang. International Classification of Diseases for Oncology, 3rd Edition, Międzynarodowa Klasyfikacja Chorób dla Onkologii, wydanie 3,

• ICH-GCP – ang. International Council for Harmonisation of Technical Requirements for Pharmaceuticals for Human Use- Good Clinical Practice, Międzynarodowa Rada Harmonizacji Wymagań Technicznych dla Rejestracji Produktów Leczniczych Stosowanych u Ludzi – Dobra Praktyka Kliniczna,

• IP – ang. investigational product, produkt badany,

• ITS – ang. information technology system – Infrastruktura informatyczna

• MedDRA SOC – ang. Medical Dictionary for Regulatory Activities System Organ Class, Klasyfikacja układów i narządów MedDRA - baza danych,

• OB – odczyn Biernackiego,

• PSBK – Polska Sieć Badań Klinicznych,

• SAE – ang. serious adverse event, ciężkie zdarzenie niepożądane,

• Sql – ang. Structured Query Language, strukturalny oraz deklaratywny język zapytań,

• SSL – ang. Secure Sockets Layer

• TNM – klasyfikacja TNM, której nazwa pochodzi od pierwszych liter słów angielskich: tumour – guz (pierwotny), node – węzeł (chłonny), metastasis – przerzut (odległy),

• UAT – ang. User Acceptance Testing, test akceptacyjny – test oprogramowania,

• WBC – ang. White blood cells, liczba białych krwinek.

3. Zgodność Systemu z przepisami prawa

System musi zawierać rozwiązania zgodne z przepisami prawa obowiązującymi na 30 dni przed terminem oddania do użytkowania Systemu

3.1. Ustawy

System musi być zgodny x.xx. z następującymi aktami prawnymi, przede wszystkim w zakresie w jakim dotyczą one systemów teleinformatycznych:

a) Ustawa z dnia 21 lutego 2019 r. o Agencji Badań Medycznych;

b) Ustawa z dnia 27 sierpnia 2009 r. o finansach publicznych;

c) Ustawa z dnia 17 grudnia 2004 r. o odpowiedzialności za naruszenie dyscypliny finansów publicznych;

d) Ustawa z dnia 10 maja 2018 r. o ochronie danych osobowych;

e) Ustawa z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych;

f) Ustawa z dnia 30 października 2002 r. o ubezpieczeniu społecznym z tytułu wypadków przy pracy i chorób zawodowych;

g) Ustawa z dnia 27 sierpnia 2004 r. świadczeniach opieki zdrowotnej finansowanych ze środków publicznych;

h) Ustawa z dnia 14 lipca 1983 r. o narodowym zasobie archiwalnym i archiwach;

i) Ustawa z dnia 6 września 2001 r. o dostępie do informacji publicznej;

j) Ustawa z dnia 5 września 2016 r. o usługach zaufania oraz identyfikacji elektronicznej;

k) Ustawa z dnia 27 lipca 2001 r. o ochronie baz danych;

l) Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne;

m) Ustawa z dnia 19 lipca 2019 r. o zapewnianiu dostępności osobom ze szczególnymi potrzebami.

4. Opis przedmiotu zamówienia

4.1. Przedmiotem zamówienia jest dostawa, instalacja, wdrożenie i wsparcie powdrożeniowe Systemu Teleinformatycznego PSBK składającego się z Portalu PSBK oraz Systemu eCRF ABM.

4.2. Zakres dostawy obejmuje dostarczenie niezbędnej infrastruktury teleinformatycznej, w tym usługi kolokacji w Centrum Danych, łączy i sprzętu sieciowego sprzętu sieciowego (np.: przełączniki, urządzenie brzegowe), serwerów i macierzy oraz oprogramowania wymaganego do uruchomienia Systemu teleinformatycznego PSBK, wraz z niezbędnym zakresem majątkowych praw autorskich i zależnych.

4.3. Zakres instalacji obejmuje uruchomienie dostarczonego sprzętu, usług sieciowych oraz konfiguracji oprogramowania zgodnie z wymaganiami opisanymi w OPZ.

4.4. Zakres wdrożenia obejmuje uruchomienie produkcyjne Systemu Teleinformatycznego PSBK.

4.5. Zakres wsparcia powdrożeniowego obejmuje pełny zakres usług techniczno- programowych służących do obsługi, nadzoru poprawności działania Systemu Teleinformatycznego PSBK, wsparcia programowego, dostosowania do zmian przepisów prawa a także rozwój dodatkowych funkcjonalności ramach zaplanowanych godzin programistycznych.

4.6. Naprawa Wad dotyczących sprzętu oraz oprogramowania, które wystąpią w okresie gwarancyjnym.

4.7. Dostawa Dokumentacji.

4.8. W ramach dostawy Portalu PSBK Wykonawca zobowiązany jest do:

a) Stworzenia projektów graficznych stron internetowych wraz z przekazaniem praw autorskich;

b) Stworzenia w pełni responsywnych szablonów HTML5 i CSS3;

c) Wdrożenia i konfiguracji stron na serwerze (usługa hostingu) Zamawiającego, wdrożenia systemu zarządzenia treścią (system CMS);

d) Rozwoju obejmującego wykonywanie modyfikacji stron internetowych i systemu zarządzania treścią (system CMS) polegających na wykonywaniu nowych funkcjonalności bądź modyfikacje istniejących, w tym tworzenie projektów graficznych;

e) Instalacji, skonfigurowania oraz wdrożenia wytworzonego Portalu PSBK na wskazanej przez Zamawiającego infrastrukturze techniczno-systemowej Agencji Badań Medycznych.

4.9. W ramach dostawy eCRF ABM, Wykonawca zobowiązany jest do:

a) Xxxxxxx, dostosowania i wdrożenia Systemu eCRF ABM;

b) Dostawy licencji wieczystej na System eCRF ABM;

c) Dostawy oraz instalacji niezbędnego Sprzętu do Centrum Danych (kolokacji).

5. Wymagania Systemu Teleinformatycznego PSBK

5.1. Wymagania jakościowe

a) Zamawiający oczekuje, że System Teleinformatyczny PSBK będzie udostępniać wyniki kwerend oraz widoki wywoływanych stron bez zauważalnych opóźnień przy założeniu jednoczesnego przetwarzania danych przez co najmniej 30 użytkowników.

b) Widok Aplikacji musi automatycznie dostosowywać się do rozmiaru ekranu użytkownika. Zmawiający przyjmuje, iż minimalna rozdzielczość będzie nie mniejsza niż 1024 x 600.

c) System musi umożliwiać Administratorowi przy użyciu panelu administracyjnego monitorowanie aktualnego obciążenia (z podziałem na procesy użytkowników) oraz ~~możliwość zatrzymania~~ zatrzymanie odpowiednich procesów, w związku z tym Zamawiający wymaga, aby istniała możliwość monitorowania aktywności poszczególnych użytkowników Systemu, generowanych przez nich procesów lub sesji oraz zarządzania tego typu zdarzeniami w tym możliwością zatrzymywania lub ich blokowania. Funkcjonalność ta nie dotyczy CMS Portalu PSBK.

d) System Teleinformatyczny PSBK musi spełniać kryteria pracy całodobowej. Czynności polegające na naprawie Wad, Wykonawca powinien wykonywać od momentu pierwszego kontaktu w sprawie zgłoszenia zgodnie z zapisami wskazanymi w punkcie

9.2 lit. o OPZ. Wszelkie pozostałe czynności techniczne Wykonawca musi wykonywać w ~~czasie najmniejszego ruchu do Systemu PSBK~~ w godzinach 20:00 – 6:00.

5.2. Wymagania użytkowe dla interfejsu

a) System Teleinformatyczny PSBK musi działać w polskiej oraz angielskiej wersji językowej.

b) Użytkownik musi mieć możliwość wybrania wersji językowej.

c) Musi istnieć możliwość przypisania użytkownikowi lub grupie użytkowników domyślnej wersji językowej, tak aby dla tego użytkownika System Teleinformatyczny PSBK uruchamiał się we właściwym dla niego języku.

d) System Teleinformatyczny PSBK musi zapamiętywać kryteria wybrane przez użytkownika (np. filtrowanie tabeli), przynajmniej na cały czas trwania sesji użytkownika.

e) Widoki w Aplikacji muszą mieć optymalny rozmiar marginesów po lewej i prawej stronie ekranu.

f) System Teleinformatyczny PSBK musi posiadać podręcznik użytkownika dla Administratora Systemu Teleinformatycznego PSBK w polskiej oraz angielskiej wersji językowej.

g) System Teleinformatyczny PSBK musi być wyposażony w wyszukiwarkę do przeglądania podręcznika użytkownika.

h) System Teleinformatyczny PSBK musi być zgodny z WACG 2.1, w szczególności uwzględniać specyfikę estetyki właściwej dla stron internetowych urzędów administracji publicznej oraz umożliwiać powiększenie rozmiaru czcionki interfejsu graficznego.

i) W Systemie Teleinformatycznym PSBK musi zostać zachowana zasada jednokrotnego wprowadzania danych. ~~Wymiana danych pomiędzy modułami musi odbywać się~~ ~~na poziomie bazy danych.~~

j) W formularzach wszystkie błędy, niewypełnienie pól obligatoryjnych oraz błędne wypełnienia muszą być prezentowane w jednym, jasno określającym te błędy, komunikacie z możliwością szybkiego przejścia do miejsca Aplikacji, gdzie te błędy wystąpiły.

5.3. Wymagania bezpieczeństwa danych

W celu zapewnienia odpowiedniego stopnia zabezpieczenia danych Wykonawca zobowiązuje się do stosowania co najmniej niżej wymienionych środków technicznych oraz organizacyjnych przy przetwarzaniu danych:

a) Korzystanie z powierzonych im informacji i aktywów wspierających ich przetwarzanie, zgodnie z oraz wyłącznie do celów wynikających z zapisów zawartej umowy, w tym zachowanie szczególnej ostrożności przy bieżącym korzystaniu z tych aktywów, w tym: zadbanie o zabezpieczenie ich przed utratą, kradzieżą, nieuprawnionym udostępnieniem, nieuprawnioną modyfikacją, uszkodzeniami mechanicznymi;

b) Niepowielanie, w tym niekopiowanie informacji chronionych, udostępnionych i opracowanych w trakcie Umowy w zakresie szerszym, niż jest to potrzebne do jej realizacji oraz niezwłocznie po zakończeniu niniejszej Umowy trwale usunięcie i/lub zniszczenie informacji chronionych przetwarzanych w ramach jej realizacji, chyba że obowiązek ich dalszego przetwarzania wynika wprost z przepisów prawa powszechnie obowiązującego;

c) Opracowanie i stosowanie dokumentacji z obszaru ochrony danych osobowych oraz bezpieczeństwa informacji zgodnie z mającymi zastosowanie powszechnie obowiązującymi przepisami prawa oraz najlepszymi praktykami branżowymi;

d) Zapewnienie obsługi zdarzeń i naruszeń bezpieczeństwa informacji, w tym danych osobowych oraz informowanie Zamawiającego o każdym podejrzeniu naruszenia bezpieczeństwa informacji i/lub aktywów wspierających ich przetwarzanie, udostępnionych im przez Zamawiającego;

e) Przeprowadzenie i regularne aktualizowanie oceny ryzyka związanej z bezpieczeństwem informacji przetwarzanych w ramach realizacji Umowy oraz analizy ewentualnych zakłóceń, które mogą wystąpić po stronie Wykonawcy;

f) Dane muszą być chronione przed niepowołanym dostępem. Każdy użytkownik systemu musi mieć odrębny login i hasło. Jakakolwiek funkcjonalność systemu (niezależnie od ilości modułów) będzie dostępna dla użytkownika dopiero po jego zalogowaniu (z wykorzystaniem podwójnego uwierzytelnienia);

g) System Teleinformatyczny PSBK musi umożliwiać dodawanie, zablokowanie, usuwanie oraz edycję kont użytkowników.

h) System Teleinformatyczny PSBK, musi być zgodny z „Rozporządzeniem Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych";

i) Identyfikacja użytkowników, musi odbywać się w sposób bezpieczny np. poprzez indywidualne loginy i hasła z możliwością przypisania uprawnień do konta;

j) Przy konfigurowaniu mechanizmów logowania System musi uwzględniać następujące zasady:

• Użytkownik zobowiązany jest do podania swojego identyfikatora oraz hasła;

• W polu logowania nie jest prezentowana ostatnio użyta nazwa Użytkownika (o ile system to umożliwia);

• Wpisywane hasło nie jest widoczne na ekranie logowania;

• W trakcie procedury logowania nie są wyświetlane komunikaty pomocnicze, które mogłyby pomóc w dostępie osobie nieuprawnionej;

• W przypadku wystąpienia błędu nie jest wskazywane, która z informacji jest niepoprawna;

• Do chwili pomyślnego zalogowania się nie są wyświetlane identyfikatory systemu lub Aplikacji;

• System logowania chroni przed próbami zalogowania się przez podanie wszystkich możliwych kombinacji;

• Wykonywane są zapisy prób logowania (zarówno udanych, jak i nieudanych);

• W przypadku wykrycia próby lub udanego przełamania zabezpieczeń logowania generowany jest alert. Każda próba logowania odpisywana jest odpowiednią informacją w logu z rozróżnieniem na logowanie udane lub zakończone niepowodzeniem.

• Nieaktywne sesje są zamykane po określonym czasie nieaktywności tj. zdefiniowanym przez Administratora Systemu Teleinformatycznego;

• Liczba nieudanych prób logowania do systemu jest ograniczona, tj. po maksymalnie pięciu następujących po sobie nieudanych próbach logowania konto jest blokowane;

• O ile to zasadne – możliwości zalogowania się do systemu są ograniczone do określonych przedziałów czasowych („okna logowania”);

• Możliwość blokowania adresu IP, z którego wykryta zostanie próba przełamania zabezpieczeń.

k) Szyfrowanie przesyłanych haseł:

• Hasła są przechowywane w bazie danych w sposób zaszyfrowany. Ponad to hasła ustawiane przez użytkowników powinny być weryfikowane pod kątem bazy wyciekłych haseł lub popularnych haseł;

• System Teleinformatyczny PSBK musi wylogować lub blokować sesję użytkownika po określonym czasie braku aktywności. Konfiguracji czasu bezczynności dokonuje Zamawiający.

l) System Teleinformatyczny PSBK jest zgodny z wymaganiami RODO na dzień 25 maja 2018 roku oraz musi być przygotowany zgodnie z zasadami ochrony danych w fazie projektowania oraz domyślnej ochrony danych (Privacy by design i Privacy by default). System musi przewidywać możliwość korzystania osób ze swoich praw, np. prawo do sprostowania, prawo dostępu do danych, umieszczenia obowiązków informacyjnych wynikających z art. 13 lub 14 RODO.

m) System Teleinformatyczny PSBK musi odnotowywać wszelką działalność użytkowników

– każde wprowadzenie/zmianę danych oraz pierwotne dane wraz z informacją, kto i kiedy je wprowadził. Żadne dane raz wprowadzone nie mogą zostać nadpisane w sposób trwały powodujący ich nieodwracalne utracenie.

n) System Teleinformatyczny PSBK musi tworzyć i utrzymywać log systemu przez co najmniej 6 miesięcy, rejestrujący wszystkich użytkowników systemu i wykonane przez nich czynności z możliwością analizy historii zmienianych wartości danych.

o) Administrator Systemów Teleinformatycznych PSBK musi mieć dostęp do Dziennika Zdarzeń, który obejmować będzie rejestr wszystkich logowań, zmian, cofnięć i skreśleń/ usunięcia danych.

p) System Teleinformatyczny PSBK musi być wyposażony w zabezpieczenia przed nieautoryzowanym dostępem. Zabezpieczenia muszą funkcjonować na poziomie klienta (Aplikacja) i serwera (serwer baz danych).

q) System Teleinformatyczny PSBK musi być zgodny ze standardami ICH-GCP (5.5.3) lub równoważnymi.

r) System musi mieć wbudowane elementy kontrolujące poprawność i bezpieczeństwo wprowadzania i przetwarzania danych.

s) Dla wprowadzanych danych krytycznych, wymagane jest dodatkowe sprawdzenie przy użyciu narządzi do walidacji zgodnie z zasadami opartymi na analizie ryzyka.

t) System musi umożliwić eksport danych lub migracji Systemu PSBK na nowe środowisko serwerowe.

6. Portal PSBK

6.1. Obecna infrastruktura techniczna Zamawiającego

a) Xxxxxxxxxxx informuje, iż obecnie dysponuje przestrzenią dyskową w usłudze hostingu współdzielonego serwowanego przez Xxxx.xx. Premium.

b) Zaproponowane przez Wykonawcę rozwiązanie musi obejmować wszelkie koszty (z wyłączaniem kosztu hostingu) usług, sprzętu, licencji, certyfikatów, gwarancji i innych niezbędnych składowych na cały okres trwania umowy.

c) Zamawiający dopuszcza CMS na licencji Open Source. Oferowany CMS musi być zgodny z usługą hostingu Zamawiającego.

6.2. Wymagania funkcjonalne

a) Portal PSBK musi się składać z części (interfejsów) dostępnych dla Użytkowników w zależności od posiadanych przez nich uprawnień z wyszczególnieniem części ogólnodostępnej dla niezalogowanych Użytkowników sieci Internet, części dostępnej wyłącznie dla Użytkowników zalogowanych oraz części niejawnej służącej do zarzadzania i administrowania Portalem PSBK.

b) Zamawiający wymaga, aby Użytkownik posiadający uprawnienia Użytkownika Zarządzającego lub Administrator Systemów Teleinformatycznych PSBK miał możliwość tworzenia nowych, edycji oraz usuwania dokumentów w Portalu PSBK (np. umów, dokumentów, ankiet dostępnych z zakładce „Dokumenty”) za pomocą dedykowanego dla Portalu system zarządzania treścią.

c) Zamawiający wymaga, aby Użytkownik Zalogowany miał możliwość tworzenia nowych formularzy dotyczących szkoleń, konferencji, webinariów, ankiet (np. z menu

„Wydarzenia branżowe->Utwórz szkolenie” poprzez tworzenie formularzy, opisów, tworzenie plików odpowiedzi, dołączanie dokumentów) na Portalu PSBK z poziomu dostępnego dla Użytkownika Zalogowanego.

d) Zamawiający wymaga, aby Użytkownik posiadający uprawnienia Użytkownika Zarządzającego lub Administrator Systemów Teleinformatycznych PSBK miał możliwość dostępu do portalu zarządzania treścią, tworzenia treści, dodawania plików, budowania formularzy, widocznych dla użytkowników zalogowanych i niezalogowanych.

e) Zastosowana przez Wykonawcę architektura oraz technologia wykonania Portalu PSBK muszą uwzględniać możliwość rozszerzenia zakresu funkcjonalności Portalu PSBK w przyszłości. Takie rozszerzenie funkcjonalności powinno być realizowane za pomocą dodatkowego modułu, plug-inu bądź częściowej modyfikacji kodu źródłowego.

f) Zakładanie kont i nadawanie uprawnień Użytkownikom w Portalu możliwe będzie tylko dla Użytkowników o statusie Administrator Systemów Teleinformatycznych PSBK.

g) Zamawiający wymaga, aby Portal PSBK był kompatybilny w jak największej liczbie przeglądarek internetowych, w tym co najmniej z następującymi przeglądarkami: Mozilla Firefox, Google Chrome, MS Edge, Opera, Safari.

h) Portal musi umożliwiać korzystanie z wymienionych w pkt 6.2.g) przeglądarek w wersjach aktualnych na dzień podpisania protokołu odbioru oraz w okresie wsparcia, przy czym wymagane jest od Wykonawcy zapewnienie 100% działania funkcjonalności Portalu dla wymienionych przeglądarek, z wyłączeniem okresu przystosowania do danej aktualizacji przeglądarki. W przypadku korzystania przez Użytkowników sieci Internet ze starszych i niekompatybilnych przeglądarek, na stronie głównej Portalu PSBK musi wyświetlać się komunikat o sposobie poprawnego prezentowania interfejsów Portalu PSBK oraz producenta i wersji przeglądarek, do których Portal PSBK jest zoptymalizowany.

i) Portal PSBK musi być responsywny, czyli poprawnie prezentować treści niezależnie od użytej rozdzielczości ekranu oraz działać zarówno na stacjach roboczych umożliwiających przeglądanie Internetu za pomocą przeglądarek internetowych jak i na tabletach oraz smartfonach dla co najmniej dwóch systemów operacyjnych (Android i iOS).

j) Na każdym etapie wyszukiwania Użytkownik Zalogowany i Użytkownik Niezalogowany musi mieć możliwość powrotu „o jeden krok” do wcześniejszej zakładki / „o kilka kroków” do wcześniejszych zakładek.

k) Prezentowane w zakładkach Portal PSBK xx.xx. grafiki, schematy, mapy, tabele oraz wykresy, filmy, pliki audio powinny prezentować treść w sposób atrakcyjny np. animowany i dynamiczny poprzez zastosowanie technologii reagującej na ruch myszy (np. JavaScript).

l) Portal PSBK musi być wyposażony w generator dokumentów w formacie pliku .pdf i umożliwiać taką funkcjonalność w miejscach określonych przez Zamawiającego (np. generowanie dokumentów, wzorów umów, informacji w formie dokumentów do wydruku dotyczących szkoleń, webinariów, konferencji, zaświadczeń o ukończeniu szkoleń itp.).

m) Portal musi być wyposażony w mechanizm umożliwiający wyświetlenie zaprojektowanej przez Wykonawcę informacji o czasowej niedostępności Portalu PSBK z powodów technicznych.

6.3. Portal musi umożliwiać co najmniej czterostopniową strukturę ról oraz stosowanych dla nich uprawnień:

a) Użytkownik Niezalogowany Portalu PSBK ma prawa do:

• swobodnego poruszania się po zakładkach ogólnodostępnego Portalu PSBK bez konieczności logowania się do Portalu.

b) Użytkownik Zalogowany Portalu PSBK ma prawa do:

• swobodnego poruszania się po wszystkich zakładkach ogólnodostępnego Portalu PSBK;

• wyszukiwania haseł w Portalu PSBK;

• edytowania, zapisywania i drukowania dokumentów (w tym formularzy, umów, itd.);

• generowania informacji na temat szkoleń, konferencji i webinariów w postaci dokumentu w formacie pliku .pdf;

• dołączania plików w zakładce, szkolenia/webinaria/konferencje w formacie plików .pdf, .pptx, .mp3, itp.;

• używania formularza do tworzenia testów jednokrotnego, wielokrotnego wyboru oraz pytań otwartych w zakładce szkolenia oraz ankiet.

c) Użytkownik Zarządzający ma prawo w szczególności do:

• pobierania dołączanych plików do formularzy/ankiet;

• tworzenia formularzy, ankiet;

• tworzenia raportów;

• dostępu do statystyk;

• zmiany wyświetlanych treści, plików, ikonografii w określonych do tego celu częściach Portalu;

• moderowania i akceptacji działań wykonywanych przez Użytkowników Zalogowanych w celu prezentowania na stronie wprowadzanych przez nich treści, formularzy, ankiet, plików itd.;

• zakładania, modyfikowania i kasowania kont z uprawnieniami Użytkowników Zalogowanych.

d) Administrator Systemów Teleinformatycznych PSBK posiada wszystkie uprawnienia Użytkownika Zarządzającego oraz w szczególności:

• możliwość zakładania, zarządzania, blokowania, kasowania kont dla Użytkowników Zarządzających i Użytkowników Zalogowanych;

• możliwość dodawania modyfikacji i patchy dla Portalu PSBK;

• dostęp do dziennika zdarzeń i logów Portalu.

6.4. Wymagania dotyczące interfejsu graficznego

W ramach zamówienia Wykonawca przedstawi do akceptacji Zamawiającego trzy propozycje projektu graficznego Portalu spełniające wymagania zawarte poniżej:

a) Projekt graficzny musi jednoznacznie wskazywać na charakter instytucji i dziedzin, którymi się zajmuje.

b) Zamawiający przewiduje, że grupą użytkowników Portalu PSBK mogą być osoby o częściowej niepełnosprawności co powoduje, że zaoferowane Zamawiającemu do oceny projekty muszą uwzględniać wszelkie możliwe ułatwienia w użytkowaniu Portalu PSBK wynikające z tego faktu. Ważne jest zatem uwzględnienie możliwości skalowania czcionki oraz sterowania kontrastem w każdej propozycji projektowej layoutu.

c) Zamawiający wymaga aby Wykonawca uwzględnił utworzenie wszystkich odnośników, linków i zakładek na stronie Portalu PSBK wykazanych w Załączniku nr 1 do OPZ oraz zamieścił w nich informacje, treści i znaki graficzne określone przez Zamawiającego.

d) Wszystkie przedstawione Zamawiającemu projekty layoutu muszą być w polskiej wersji językowej, a także być w pełni responsywne umożliwiając poprawne wyświetlanie Portalu PSBK na ekranach o różnych rozdzielczościach. Wykonawca musi również uwzględnić wszelkie uwagi wynikające z koncepcji Zamawiającego, a także zastosować się do zaleceń z księgi znaków Agencji Badań Medycznych, którą Zamawiający przekaże Wykonawcy.

e) Wykonawca przygotuje w ramach projektu poza głównym layoutem Portalu PSBK również dwie wersje okolicznościowe, w tym wersję żałobną i świąteczną – właściwą dla świąt o charakterze państwowym. Przełączanie layoutu Portalu powinno odbywać się poprzez jego wybór z panelu administracyjnego jak również mieć możliwość przełączania wyglądu Portalu automatycznie zgodnie z zadanym harmonogramem np. okres świąteczny według daty przełącza automatycznie na layout świąteczny.

f) Zamawiający wymaga, aby elementem wyświetlanego Portalu był pasek/ścieżka zawierająca informację o miejscu w strukturze Portalu, w którym aktualnie znajduje się użytkownik z możliwością wyboru i cofnięcia się do innego miejsca w strukturze (tzw. Oś menu krokowego).

g) Zaoferowany przez Wykonawcę layout Portalu musi zawierać odnośnik przekierowujący do strony głównej/startowej oraz „przyciski” pozwalające na cofanie się użytkownikom o jeden krok.

6.5. Wymagania dla panel zarządzający

a) Administrator Systemów Teleinformatycznych PSBK z poziomu panelu zarządzającego musi mieć możliwość wyświetlania, moderowania i weryfikacji danych wprowadzanych za pomocą formularza. Dane w taki sposób wprowadzane powinny być oznaczane odpowiednim statutem. Akceptacja będzie równoznaczna z wprowadzeniem (commit) danych do Portalu PSBK.

b) Administrator Systemów Teleinformatycznych PSBK musi mieć możliwość sporządzania raportów z zakresu danych wskazanych przez Zamawiającego oraz możliwość generowania zestawień rocznych i kwartalnych. Dotyczy to raportów i statystyk z wyświetlanych wyników, np. możliwości oszacowania najczęściej poszukiwanych haseł, statystyki odwiedzin poszczególnych zakładek i podzakładek i poszczególnych części Portal PSBK itp.

c) Portal PSBK musi mieć możliwość publikacji treści w określonych przez Zamawiającego miejscach layoutu, w tym również załączników w postaci plików MS Office, OpenOffice, co najmniej .rtf, .odt, plików tekstowych, plików .pdf, .jpg, .gif, .png, .swf, .mpg, .mp3, .avi,

.wmv, .zip, .rar, opatrzonych odpowiednimi ikonkami (np. podświetlenie załącznika po najechaniu na niego myszą), oraz innych plików dowolnego formatu i rozmiaru do 25 MB opatrzonych właściwą dla nich wspólną ikonką (dotyczy wgrywania na serwer plików z rozszerzeniami zapisanymi małymi i wielkimi literami). Portal PSBK musi zapewniać możliwość wyświetlania dla użytkowników wielkości pliku w KB oraz MB przy ikonie pliku. Zamawiający szacuje, że w ciągu doby zostanie zaimportowanych nie więcej niż 100 plików. Import plików musi być możliwy do przeprowadzenia wielokrotnie w ciągu doby. Zamawiający spodziewa się największego obciążenia Portalu PSBK w godzinach 8:00 – 16:00. Zamawiający przewiduje, że maksymalny dzienny import wyniesie 10 GB.

d) Wykonawca zapewni taką strukturę katalogową oraz zachowa nazewnictwo plików użytkowników, aby uprawniony pracownik Agencji miał możliwość również fizycznego usuwania plików z serwera oraz ich podmiany za pomocą szyfrowanego protokołu.

e) Z panelu zarządzającego Użytkownik o roli Administrator Systemów Teleinformatycznych PSBK musi mieć możliwość podglądu, filtrowania w zależności od zastosowanych kryteriów i eksportowania do pliku tekstowego danych z dziennika zdarzeń.

f) Z panelu zarządzającego Użytkownik o roli Administrator Systemów Teleinformatycznych PSBK musi mieć możliwość zakładania, edycji, blokowania i usuwania kont oraz nadawania uprawnień Użytkownikom Zarządzającym oraz innym Administratorom Systemów Teleinformatycznych PSBK.

g) Z panelu zarządzającego Użytkownik o roli Administrator Systemów Teleinformatycznych PSBK musi mieć możliwość instalacji patchy lub innych modułów rozszerzających lub poprawiających pracę Portalu. Zamawiający dopuszcza zastosowanie metody uaktualnienia i rozbudowy Portalu poprzez dogranie z poziomu dostępu plikowego odpowiedniego pliku/plików z nowym kodem pod warunkiem przeprowadzenia wcześniej procedury testowej zaakceptowanej przez Zamawiającego oraz przeprowadzeniu prac w sposób bezprzerwowy bez konieczności czasowego wyłączania Portalu PSBK z eksploatacji.

h) Z panelu zarządzającego Użytkownik o roli Administrator Systemów Teleinformatycznych PSBK musi mieć możliwość wykonywania w pełni odtwarzalnej kopii bezpieczeństwa

„na żądanie” na nośnik zewnętrzny lub szyfrowanego transferu zarówno danych i zawartości strony wraz z kodem źródłowym.

i) Z panelu zarządzającego Użytkownik w roli Administratora Systemów Teleinformatycznych PSBK musi mieć możliwość wygenerowania danych, oznaczenia danych użytkowników, w związku z realizacją praw użytkowników, których prawa dotyczą oraz realizacji obowiązków administratora danych osobowych w rozumieniu rozporządzenia Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016

r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (ogólne rozporządzenie o ochronie danych – RODO), np. określenia okresu retencji danych.

6.6. Wymagania dodatkowe

a) Portal PSBK musi także stosować mechanizmy szyfrowania danych przesyłanych między Aplikacją, a Użytkownikiem, przy czym całość Portalu PSBK musi wykorzystywać stosowanie protokołu szyfrowanego, co najmniej SSL.

b) Portal musi stosować uprawnienia umożliwiające ograniczenie Użytkownikowi Końcowemu (sieci Internet), Użytkownikowi Zarządzającemu i Administratorowi Systemów Teleinformatycznych PSBK dostęp do danych oraz operacje na funkcjach Portalu PSBK tylko dla tej roli, do której jest upoważniony (autoryzacja).

c) W przypadku formularzy (ankiet) wymagane jest zabezpieczenie Portalu PSBK poprzez zastosowanie portalów antyspamowych i antybotowych, lub po konsultacji z Zamawiającym innego rozwiązania i portalu weryfikacyjnego polegającego na weryfikacji osób korzystających z Portalu PSBK, eliminacji botów i automatów internetowych.

d) Zamawiający dopuszcza przez cały czas trwania umowy możliwość zdalnego dostępu dla Wykonawcy do ITS Zamawiającego, na którym będzie zlokalizowany Portal PSBK z jednoczesnym wprowadzeniem rozwiązań do zarządzania i monitorowania sesji zdalnych.

e) Każda operacja na danych osobowych dokonana w Portalu PSBK powinna być rozliczana, co oznacza możliwość określenia kto i kiedy podjął konkretne działanie na danych, np. usunął dane osobowe.

f) W ramach wykonywania Portalu PSBK będzie zawarta z Wykonawcą umowa powierzenia danych osobowych.

g) Wykonawca zapewni, iż Portal PSBK będzie zawierał funkcjonalności związane z plikami cookies.

7. System eCRF ABM

7.1. Podstawowe funkcje

a) Tryb pracy z dokumentami - formularzami karty obserwacji pacjenta (tworzenie, złożenie, rewizja, odrzucenie, modyfikacje, zatwierdzenie, podpisanie).

b) Możliwość tworzenia raportów/zestawień/listingów (tworzenie, filtrowanie, eksportowanie) wg bieżących potrzeb użytkownika.

c) Możliwość eksportu ~~i importu~~ danych w do plików Excel, CSV. Możliwość importu plików pdf (np. instrukcja wypełnienia eCRF, zasady RECIST) do rozmiaru 100MB. Zamawiający szacuje, że w ciągu doby zostanie zaimportowanych nie więcej niż 100 plików. Import plików musi być możliwy do przeprowadzenia wielokrotnie w ciągu doby. Zamawiający spodziewa się największego obciążenia Portalu PSBK w godzinach 8:00 – 16:00. Zamawiający przewiduje, że maksymalny dzienny import wyniesie 2,5 GB.

d) Możliwość wydruku danych, raportów w formacie PDF.

7.2. Architektura i administracja systemu

a) System eCRF ABM musi działać w architekturze trójwarstwowej.

b) System eCRF ABM musi posiadać interfejs graficzny dla wszystkich modułów.

c) System eCRF ABM musi pracować w środowisku graficznym MS Windows na stanowiskach użytkowników (minimum Windows 7 Professional).

d) Interfejs użytkownika musi być dostępny z poziomu przeglądarek internetowych (co najmniej FireFox w wersji 72.0.1 i wyżej, Google Chrome w wersji 79.0. i wyżej oraz kompatybilnych).

e) Wykonawca zobowiązany jest dostarczyć system zarządzania relacyjną bazą danych, wykorzystywaną przez System eCRF ABM w oparciu o licencję Open Source zgodnie z ~~aktualnymi~~ rekomendacjami Kancelarii Prezesa Rady Ministrów lub innego odpowiedniego ministerstwa (zgodnie z kompetencjami) obowiązującymi w dniu podpisania umowy. Wykonawca upoważniony jest do korzystania, w toku realizacji niniejszego Zamówienia z elementów programów komputerowych licencjonowanych na wolnych licencjach (oprogramowania typu Open Source) jedynie wówczas, gdy wykorzystanie takich programów komputerowych do stworzenia Rezultatów Prac opisanych w niniejszym dokumencie nie uniemożliwi Wykonawcy udzielenia Zamawiającemu licencji na korzystanie ze stworzonego przez Wykonawcę oprogramowania na zasadach określonych w projektowanych postanowieniach umowy, jak również jedynie wówczas, gdy warunki licencji oprogramowania open source nie zawierają tzw. klauzuli copyleft. Niniejsze postanowienie nie ma zastosowania do systemu zarządzania relacyjną bazą danych, wykorzystywaną przez System eCRF ABM w oparciu o licencję Open Source.

f) Wykonawca zobowiązany jest w ramach oferowanego rozwiązania dostarczyć licencję na System eCRF ABM operacyjny serwera, wymagany przez System eCRF ABM będący przedmiotem zamówienia.

g) Mechanizmy logistyki oprogramowania muszą umożliwiać implementowanie, co najmniej 2 niezależnych instancji środowisk: testowo-szkoleniowego i produkcyjnego. Wykonawca musi zapewnić niezbędne licencje na oprogramowanie do obsługi tych środowisk (baza danych, System eCRF ABM operacyjny) bez ograniczenia na liczbę CPU (dostarczone oprogramowanie, będące przedmiotem zamówienia, nie może posiadać wewnętrznego ograniczenia, co do liczby rdzeni, na których pracuje, w przypadku większej liczby rdzeni oprogramowanie musi być w stanie je wykorzystać i zwiększyć swoją wydajność).

h) System eCRF ABM musi zapewniać odporność struktur danych (baz danych) na uszkodzenia oraz musi pozwalać na szybkie odtworzenie ich zawartości i właściwego stanu. System eCRF ABM musi posiadać łatwy i szybki w obsłudze mechanizm wykonania kopii bieżących oraz odtwarzania z kopii.

i) System eCRF ABM musi być wykonany w technologii klient-serwer, dane muszą być przechowywane w modelu relacyjnym baz danych z wykorzystaniem aktywnego serwera baz danych.

j) ~~System eCRF ABM musi mieć możliwość automatycznego oczyszczania danych~~ ~~pobieranych z systemu źródłowego do potrzeb analitycznych na poziomie importu~~ ~~danych. Automatyczne oczyszczanie danych podczas importu ma na celu~~ ~~uporządkowanie importowanych danych po przez np. usunięcie zbędnych spacji,~~ ~~przecinków, pustych kolumn itp.~~

k) System eCRF ABM musi umożliwiać monitorowanie aktualnego obciążenia systemu (z podziałem na procesy użytkowników).

l) System eCRF ABM musi posiadać historię importowania danych i innych operacji użytkowników limitowaną jedynie przestrzenią dyskową.

m) System eCRF ABM musi pracować w oparciu o dynamiczne ładowanie treści do GUI np. w technologii AJAX.

7.3. Funkcjonalności

System eCRF ABM musi umożliwiać tworzenie nieograniczonej liczby grup użytkowników i nadawanie grupom uprawnień w zakresie:

• Grup użytkowników:

▪ Tworzenie nowej grupy;

▪ Usuwanie grup;

▪ Edytowanie grup i zmiana uprawnień w obrębie grupy;

▪ Podgląd definicji grupy;

• Użytkowników:

▪ Tworzenie nowego użytkownika;

▪ Edytowanie danych użytkownika;

▪ Podgląd danych użytkownika;

• Dostępu do poszczególnych modułów:

▪ Dostęp do modułu eCRF;

▪ Dostęp do modułu zarządczego;

▪ Generowania plików programu typu xlsx, csv.

▪ Administrator Systemu Teleinformatycznego PSBK ma możliwość nadawania użytkownikom uprawnień do określonych modułów i określonych funkcji w ramach danego modułu niezależnie.

7.4. Moduł eCRF musi posiadać następujące funkcje:

Wymagana funkcja

E-1

Moduł musi pozwalać na kompleksowe zarządzanie poszczególnymi

etapami prowadzonego badania wszystkim osobom uprawnionym według zdefiniowanego protokołu klinicznego.

E-2

Moduł musi umożliwiać dostęp poprzez stronę www na podstawie zdefiniowanych uprawnień w module administracyjnym.

E-3

Moduł musi umożliwiać zdefiniowanie i edycję protokołu badania poprzez graficzny interfejs użytkownika.

E-4

Użytkownik będzie mógł zdefiniować w Aplikacji:

• Liczbę i harmonogram wizyt;

• Zakres usług wykonywanych na poszczególnych wizytach;

• Formularze wypełniane dla poszczególnych usług;

• Kryteria widoczności formularzy dla określonych grup użytkowników;

• Reguły widoczności określonych typów wizyt, w zależności od aktualnego statusu pacjenta.

E-5

Moduł musi umożliwiać przygotowanie odrębnych schematów wizyt dla różnych faz badania (Np. faza kliniczna, faza follow-up), różnych typów badań w ramach jednego projektu (np. badanie obserwacyjne, badanie klinicznie) jak również dla odrębnych grup klinicznych w przypadku badań

otwartych.

E-6

Moduł umożliwia zdefiniowanie reguł przejść pacjenta z jednej fazy badania do innej, np. z fazy zaślepionej do fazy otwartej.

E-7

Moduł w ramach protokołu musi umożliwiać zdefiniowanie listy wizyt wymaganych w badaniu wraz z harmonogramem. Dla każdej wizyty można zdefiniować następujące informacje:

• Nazwa wizyty;

• Kod wizyty;

• Typ wizyty (planowa lub dodatkowa);

• Planowany termin wykonania wizyty określony w protokole (Moduł informuje o wprowadzeniu wizyty poza oknem zdefiniowanym w protokole badania);

• Okno czasowe wykonania wizyty względem planowego terminu.

E-8

Moduł musi umożliwiać zdefiniowanie w protokole wizyt dodatkowych, które odbywają się w terminach innych niż wizyty określone w

harmonogramie.

E-9

Moduł w ramach pojedynczej wizyty w protokole musi umożliwiać zdefiniowanie usług jakie należy wykonać i zakodować w ramach danej wizyty (np. EEG, Wywiad, Leki, Morfologia itp.).

E-10

Moduł musi umożliwiać wprowadzenie zdarzeń niepożądanych oraz informację o stosowaniu dodatkowych leków po każdej wizycie.

E-11

Moduł musi umożliwiać dostosowanie widoczności poszczególnych usług w ramach wizyty w protokole dla wybranych grup użytkowników.

E-12

Moduł musi wylogować lub blokować sesję użytkownika po zadanym czasie braku aktywności. Aktywność powinna być mierzona nie tylko poprzez przechodzenie pomiędzy poszczególnymi polach Modułu, ale także na podstawie aktywności użytkownika w obecnie wybranym polu.

E-13

Moduł musi uniemożliwiać wprowadzanie lub modyfikację danych w sposób anonimowy.

E-14

Moduł musi tworzyć i utrzymywać logi Modułu, rejestrujący wszystkich

użytkowników Modułu i wykonane przez nich najważniejsze czynności z możliwością analizy historii zmienianych wartości danych.

E-15

Moduł w momencie rozpoczęcia czynności np. wypełniania formularza tworzy ten obiekt jako szkic umożliwiając powrót i kontynuację edycji

po zamknięciu okna.

E-16

Moduł musi umożliwiać dodawanie, zablokowanie, usuwanie oraz edycję kont użytkowników.

E-17

Moduł musi umożliwiać dodawanie, usuwanie i edycję grup użytkowników.

Konfiguracja grup użytkowników, wraz z możliwością przypisania

im użytkowników musi być możliwa poprzez moduł Administratora.

E-18

Administrator Systemu Teleinformatycznego PSBK musi mieć możliwość nadawania grupom użytkowników uprawnień do określonych modułów i określonych funkcji w ramach danego modułu niezależnie. Moduł uprawnień powinien być tak zaprojektowany i wdrożony, aby można było grupie użytkowników nadać uprawnienia z dokładnością do rodzaju wykonywanej operacji tj. osobne uprawnienie na odczyt danych i osobne

na wprowadzanie/modyfikację danych.

E-19

Moduł musi umożliwiać pełne odwzorowanie protokołu badania wraz regułami uwzględniającymi:

• Jakie usługi mają być wykonane w ramach danej wizyty;

• W jakich odstępach czasu mają być wykonane poszczególne wizyty;

• Która grupa użytkowników ma dostęp do wypełnienia i podglądu danych usług w ramach wizyty;

• Kiedy nie jest możliwe wykonanie danej wizyty lub usługi.

E-20

Moduł musi umożliwiać za pomocą interfejsu graficznego zdefiniowanie formularza dla każdej usługi zdefiniowanej w protokole.

E-21

Moduł musi umożliwiać przypisanie pacjentowi następujących atrybutów:

• Kod pacjenta;

• Podane leki (EAN lub równoważny);

• Wykonane procedury medyczne;

• Diagnozy (ICD-10 wraz z nazwą i rodzajem diagnozy);

• Wyniki laboratoryjne (dla każdego z atrybutów);

• Dane tekstowe (notatki lekarskie, opisy badań diagnostycznych);

• Wizyty;

• Pobyty szpitalne;

• Klasyfikacja TNM;

• Płeć;

• Rok urodzenia;

• Data zgonu;

• Status (słownik definiowany w Module);

• Data dołączenia do badania;

• Lekarz prowadzący (słownik definiowany w Module);

• Jednostka badawcza.

E-22

Moduł musi umożliwiać zdefiniowanie aktywnych atrybutów pacjenta, które będą używane w danym badaniu. Pozostałe atrybuty będą niewidoczne w Module.

E-24

Moduł musi posiadać funkcjonalność archiwizacji danych. Po założeniu blokady na dany okres czasu modyfikacja danych wprowadzonych w zablokowanym okresie czasu będzie niemożliwa.

E-25

Moduł musi posiadać moduł słowników umożliwiający dodawanie, usuwanie i modyfikowanie pozycji słownikowych z poziomu interfejsu

graficznego Aplikacji.

E-26

Moduł musi automatyczne generować unikalny kod pacjenta dla każdego nowowprowadzonego pacjenta zgodnie z określonymi regułami.

E-27

Moduł musi umożliwić wyszukiwanie pacjenta/-ów po parametrach takich jak: kod pacjenta, kod randomizacyjny, status, jednostka badawcza.

E-28

Moduł musi informować o próbie opuszczenia formularza bez zapisania zmian.

E-29

Moduł musi posiadać możliwość monitorowania regularności leczenia – każde zdarzenie w historii pacjenta musi być zaznaczone w Module (wizyta, badanie kontrolne, zdarzenie niepożądane, leczenie). Wizualizacja zdarzeń musi być graficzna na osi czasu np. przy wizytach pacjenta powinna być podana data oraz statusu wizyty (np. wykonana,

zaplanowana, opuszczona).

E-30

Wszystkie zdarzenia muszą być weryfikowane i odpowiednio zaznaczane na osi czasu, jeśli są realizowane zgodnie z terminami wykazanymi w protokole badania klinicznego, bądź od nich odbiegają.

E-31

Moduł musi na osi czasu prezentować przyszłe wizyty wraz z informacją

o terminie wykonania wizyty wynikającym z protokołu badania.

E-32

Moduł musi być wyposażony w submoduł audit trail, który będzie odpowiedzialny za rejestrowanie zmian w wypełnionych formularzach. Wszystkie zmiany będą dostępne na ekranie podglądu historii zmian danego formularza. Rejestrowana będzie zmiana wartości poszczególnych

atrybutów wraz z datą i nazwą użytkownika, który dokonał zmian.

E-33

Moduł musi automatycznie przypisywać kod randomizacyjny na podstawie kryteriów określonych przez zamawiającego. Moduł musi obsługiwać randomizację prostą, blokową oraz stratyfikację z randomizacją blokową

dla określonych przez zamawiającego kategorii pacjentów.

E-34

Moduł musi umożliwiać zmianę przypisania pacjenta do wybranego protokołu.

E-35

Moduł musi umożliwiać dodanie do kartoteki pacjenta dowolną ilość danych opisowych zrealizowanych w formie dynamicznych formularzy.

E-36

Moduł musi umożliwiać wyeksportowanie do pliku pdf wybraną wizytę lub usługę.

E-37

Moduł w kartotece pacjenta musi prezentować wszystkie usługi wykonane pacjentowi pogrupowane na kategorie usług, np. EKG, Badanie neurologiczne itd.

E-38

Moduł musi umożliwiać zgłoszenie zdarzeń niepożądanych dla pacjenta zgodnie z klasyfikacją CTCAE i musi zawierać wszystkie wymagane w klasyfikacji kryteria:

• MedDRA SOC;

• CTCAE Term;

• Czy zdarzenie miało związek z zastosowaniem leczenia?;

• Czy spełnia kryteria SAE?;

• Data rozpoczęcia + Data zakończenia;

• Alerty kierowane do głównego badacza przy każdym zgłoszonym zdarzeniu niepożądanym.

E-39

Moduł musi umożliwiać wprowadzenie do kartoteki pacjenta formularza SAE i przesłanie informacji mailowej o wystąpieniu SAE do koordynatorów badania.

E-40

Moduł ma być wyposażony jest w submoduł dynamicznych formularzy. Moduł taki zapewnia pełną elastyczność narzędzia w zakresie formy zbierania danych oraz łatwość modyfikowania formularzy w trakcie trwania projektu.

E-41

Submoduł dynamicznych formularzy za pomocą metody Drag&Drop ma umożliwić użytkownikowi stworzenie dowolnej liczby formularzy. Formularze te później są używane w całym Module do gromadzenia danych o pacjencie, usługach i zdarzeniach związanych z badaniem.

E-42

Tworząc lub modyfikując formularz za pomocą kreatora w GUI użytkownik ma mieć do dyspozycji predefiniowane konfigurowalne typy atrybutów:

• Pole tekstowe jednowierszowe – atrybut umożlwiający konstruowanie pytań w których odpowiedzią zazwyczaj jest krótki tekst;

• Pole tekstowe wielowierszowe – atrybut umożlwiający konstruowanie pytań w których odpowiedzią jest dłuższy opis;

• Tekst;

• Sekcja;

• Pole liczbowe – atrybut dedykowany do wprowadzania wartości liczbowych, wyposażony w odpowiednie walidatory i formatowanie;

• Pole logiczne – atrybut dedykowany dla odpowiedzi TAK/NIE;

• Słownik jednokrotnego wyboru – atrybut umożliwiający wybór jednej wartości spośród wszystkich zdefiniowanych w danym słowniku;

• Słownik wielokrotnego wyboru – atrybut umożliwiający wybór wielu wartości spośród wszystkich zdefiniowanych w danym słowniku;

• Pole daty – atrybut wyposażony w zintegrowany selektor daty z kalendarza;

• Pole wgrywania plików – atrybut umożliwiający przesyłanie za pomocą formularza plików z dysku użytkownika;

• Grafika – atrybut umożlwiający osadzenie w formularzu dowolnej grafiki.

Wymienione atrybuty umieszczane są w definicji formularza za pomocą metody Drag&Drop. Atrybuty można układać w dowolnej pozycji na siatce formularza oraz dostosować ich wygląd oraz funkcjonalności za pomocą

dedykowanego dla atrybutu konfiguratora.

E-43

Podczas definiowania formularza Moduł za pomocą interfejsu graficznego dla każdego atrybutu ma umożliwiać zdefiniowanie:

• Nazwy atrybutu;

• Kodu atrybutu;

• Etykiety;

• Atrybutu nadrzędnego (rodzica);

• Wyrównania;

• Pozycji w pionie i poziomie;

• Marginesów;

• Rozmiaru czcionki tekstów w atrybucie;

• Pozycji etykiety.

E-44

Podczas definiowania formularza Moduł za pomocą interfejsu graficznego dla każdego z atrybutów musi umożliwiać zdefiniowanie walidatorów dla wprowadzanych wartości. Minimalny zestaw walidatorów:

• Maksymalna liczba znaków;

• Minimalna liczba znaków;

• Maksymalna wartość;

• Minimalna wartość;

• Pole wymagane.

E-45

Moduł musi umożliwiać za pomocą interfejsu graficznego zdefiniowanie warunków logicznych miedzy poszczególnymi atrybutami w formularzu. Możliwe jest dzięki temu wprowadzenie interakcji pomiędzy aktywnością poszczególnych atrybutów w zależności od wartości wprowadzonych w innych atrybutach danego formularza.

Moduł musi obsługiwać następujące reguły:

• Jeżeli wartość atrybutu równa…

• Jeżeli wartość atrybutu większa…

• Jeżeli wartość atrybutu większa lub równa…

• Jeżeli wartość atrybutu mniejsza…

• Jeżeli wartość atrybutu mniejsza lub równa…

• Jeżeli wartość atrybutu pusta…

• Jeżeli wartość atrybutu niepusta…

E-46

Moduł musi umożliwiać za pomocą interfejsu graficznego zdefiniowanie typowych wartości dla poszczególnych atrybutów formularza (edit checks). Definiując regułę dla atrybutu, należy określić warunek oraz komunikat jaki będzie w Module wyświetlony, gdy wartość atrybutu wykroczy poza

określoną normę.

E-47

Moduł musi informować użytkownika o wszystkich potencjalnych błędach lub brakach we wprowadzonych danych poprzez zestaw czytelnych oznaczeń i komunikatów.

E-48

Moduł ma być wyposażony jest w rewizjonowanie definicji formularzy. Funkcjonalność ta zapewnia możliwość modyfikacji definicji formularza z zachowaniem pełnej zgodności danych ze starszymi rewizjami danego formularza.

E-49

Moduł musi umożliwiać dokonanie modyfikacji definicji dowolnego formularza za pomocą interfejsu graficznego Aplikacji. Po zatwierdzeniu zmodyfikowanej definicji formularza, zmiany są automatycznie dostępne dla wszystkich użytkowników wprowadzających dane za pomocą

formularza.

E-50

Moduł musi być tak skonstruowany, aby wszystkie dane były wprowadzane do Modułu z użyciem formularzy definiowanych w graficznym interfejsie

użytkownika. Zapewnia to użytkownikowi możliwość zdefiniowania

struktury zbieranych danych w pełni zgodną z protokołem danego badania, bez znajomości zaawansowanych narzędzi programistycznych.

E-51

Moduł musi umożliwiać dodawanie nowego pacjenta do badania i wymagać uzupełninia tylko tych danych, których wymaga dane badanie. Wymagane atrybuty pacjenta będą konfigurowalne w module administracji

Aplikacji.

E-52

Moduł musi umożliwiać przypisanie lekarza prowadzącego do pacjenta. W module administracji dostępny musi być słownik personelu z

możliwością edycji i dopisania nowych pozycji.

E-53

Moduł musi umożliwiać użytkownikom wprowadzanie danych wskazanych w protokole badania klinicznego z następującymi zasadami:

• Wszystkie dane wprowadzane są za pomocą dynamicznych formularzy;

• Dane wprowadzane są w sposób ustandaryzowany (np. wgrane słowniki, kalendarz, dedykowane pola liczbowe).

E-54

Moduł musi podpowiadać i kontrolować jaką wizytę należy wykonać

pacjentowi oraz jakie usługi należy wykonać na danej wizycie by spełnić założenia protokołu badania.

E-55

Moduł musi umożliwiać przypisanie pacjentowi statusu informującego na jakim etapie jest dany pacjent. Słownik statusów jest edytowalny

z poziomu modułu administracyjnego.

E-56

Moduł w kartotece pacjenta musi prezentować wszystkie wizyty wykonane pacjentowi z możliwością łatwego podglądu wybranej wizyty. W ramach podglądu prezentowane są wszystkie dane wprowadzone w ramach usług

wykonanych podczas wizyty.

E-57

Moduł z poziomu kartoteki pacjenta ma umożliwiać dodanie nowej wizyty lub zaplanowanie terminu nowej wizyty.

E-58

Moduł musi być wyposażony w moduł kalendarza. W module kalendarza możliwe jest zaplanowanie terminu kolejnych wizyt. Moduł automatycznie sugeruje termin wykonania wizyty wraz z określeniem okna czasowego na podstawie protokołu badania.

E-59

Moduł ma pozwalać na utworzenie szkiców wizyty i późniejszy powrót do uzupełnienia danych aż do momentu zatwierdzenia wizyty.

E-60

Moduł po zatwierdzeniu wizyty ma umożliwić za pomocą przycisku wydrukowanie informacji o wizycie wraz z uwzględnieniem wszystkich usług i danych wprowadzonych podczas wizyty.

E-61

Moduł ma przechowywać historię przeglądanych kartotek pacjentów i za pomocą podręcznego menu umożliwia szybki powrót do wcześniej przeglądanych kartotek bez konieczności ponownego wyszukiwania pacjentów na liście.

E-62

Moduł ma umożliwić wygenerowanie plików PDF z poziomu wizyty, usługi oraz pojedynczego formularza dla danego pacjenta.

E-63

Moduł ma umożliwić pobranie danych wprowadzonych do eCRFa w postaci arkuszy kalkulacyjnych XLSX. Użytkownik ma możliwości zdefiniowania zakresu pobieranych danych, poprzez ograniczenie zbioru usług, zakresu dat lub konkretnych formularzy. Moduł przechowuje historię

wygenerowanych plików.

E-64

Moduł ma umożliwić pobranie formularzy zdefiniowanych w graficznym interfejsie użytkowników w postaci plików szablonów, umożliwiających przenoszenie zdefiniowanych szablonów formularzy do innych instancji Aplikacji i wykorzystywanie ponownie w innych badaniach klinicznych.

E-65

Moduł ma umożliwić obsługę badań prowadzonych w kilku jednostkach badawczych poprzez rozbudowany Moduł uprawnień użytkowników. Moduł ma umożliwić ograniczenie widocznych danych tylko do pacjentów z danej jednostki dla określonych grup użytkowników.

E-66

Moduł ma posiadać submoduł do monitorowania wprowadzanych danych. Submoduł obejmuje prowadzenie rejestru zmian (audit trail), zadawanie pytań do wprowadzonych danych (data query), jak również zatwierdzanie wprowadzonych danych na kolejnych poziomach uprawnień: lekarz, monitor, koordynator badana i zabezpieczanie ich przed niekontrolowaną

edycją.

E-67

Moduł eCRF, ma pozwalać na uruchomienie dowolnej ilość instancji pod wiele różnych badań prowadzonych przez różne ośrodki.

7.5. Moduł zarządczy musi posiadać następujące funkcje:

Wymagana funkcja

Z-1

Moduł musi mieć zaimplementowaną obsługę Drag&Drop przy tworzeniu zapytań (tj. przeciąganie kafelków, które układają się w warunki zapytania). Musi istnieć możliwość każdorazowej zmiany wszystkich kafelków w dowolnym momencie tworzenia zapytania. Dodatkowo musi istnieć możliwość każdorazowego określenia zakresów parametrów

wyszukiwanych i ich zmiany w dowolnym momencie tworzenia zestawienia.

Z-2

Zakres możliwych danych do uzyskania w ramach modułu:

• Liczba badań w module eCRF;

• Liczba ośrodków w badaniu;

• Dane statystyczne z rekrutacji (płeć, podział na grupy wiekowe);

• Informacja o prowadzącym badanie;

• Liczba pacjentów w module eCRF;

• Liczba wizyt w module eCRF;

• Określenie numeru wizyty;

• Dziedzina medycyny, w której jest prowadzone badanie;

• Postęp rekrutacji;

• Drop out;

• Opóźnienia;

• Zdarzenia niepożądane (zbiorczo oraz indywidualnie na badanie);

• Ciężkie zdarzenia nieporządne (zbiorczo oraz indywidualnie na badanie).

Z-3

Moduł ma umożliwić pobranie wygenerowanych raportów w postaci arkusza kalkulacyjnego (xlsx, csv) oraz pliku w formacie PDF.

8. Wymagania techniczne dla środowiska pracy Systemu

8.1. Zamawiający wymaga aby System był zainstalowany na zasobach dostarczonych przez Wykonawcę w ramach zamówienia.

8.2. Zamawiający wymaga dostarczenie pełnego asortymentu sprzętowo- programowego, sprzętu sieciowego, routerów, firewalli, switchy kompletu okablowania oraz zestawu usług niezbędnych do uruchomienia, poprawnej pracy i świadczenia usług przez cały okres obowiązywania umowy oraz zapewnienia pełnego bezpieczeństwa Systemu Teleinformatycznego PSBK. Wykonawca ma zapewnić niezbędną infrastrukturę dobraną zgodnie z wymaganiami OPZ. ABM w Centrum Danych zapewni przestrzeń kolokacyjną, zasilanie oraz łącza. Po stronie Wykonawcy konieczne będzie skorelowanie usług z dostarczonym sprzętem tj. zapewnienie np.: niezbędnych przełączników oraz urządzenia brzegowego do połączenia z Internetem.

8.3. Zamawiający zakłada, że System będzie pracował zarówno w ramach wewnętrznej sieci lokalnej ABM jak również z możliwością pracy na odległość Użytkowników za pośrednictwem sieci Internet. Zamawiający oczekuje zastosowania rozwiązania opartego na dwóch serwerach zapewniających ciągłość pracy typu high availability.

8.4. Zamawiający wymaga aby każdy z oferowanych dla Systemu serwerów spełniał poniższe kryteria minimalne:

Nazwa elementu, parametru lub cechy	Opis wymagań serwerów
Obudowa	Serwery – obudowa RACK 19", wysokość nie więcej niż 1U, głębokość maksymalnie 85 cm. Wyposażone w zestaw szyn i organizator do kabli do mocowania w szafie i wysuwania do celów serwisowych. Zaproponowane serwery muszą swobodnie mieścić się wraz z organizerami okablowania i okablowaniem w szafie RACK 600x1000.
Procesor	Dobrane pod względem wydajności do Systemu PSBK wielordzeniowe w architekturze x86.
Pamięć operacyjna	Ilość pamięci XXX określona przez Wykonawcę dla wydajnej i poprawnej jakościowo pracy Systemu PSBK w modułach RDIMM i pracy w trybie pełnej wydajności (tzw. Performance Mode). Nie mniej niż 16 gniazd pamięci DIMM DDR4 na płycie głównej serwerów.
Procesor Graficzny	Karty graficzne VGA. Minimalna rozdzielczość wyświetlanego obrazu 1280x1024 pikseli.
Dyski systemowe	Zainstalowane minimum 2 dyski M.2 240 GB skonfigurowane w RAID 1.
Dyski	Każdy serwer powinien umożliwiać instalacje w obudowie. 10 dysków 2,5” SAS/SATA/SSD/NVMe. Wykonawca musi dobrać wielkość i technologię dysków do wymagań jakościowych Systemu. Zamawiający wymaga aby każdy z serwerów był wyposażony w dyski SSD w RAID5. Minimalna dostępna przestrzeń w Systemie PSBK nie może być mniejsza niż 8TB.
Kontroler dyskowy	Serwery/macierze muszą umożliwiać instalacje kontrolera obsługującego dodatkowe dyski z obsługą RAID 0, 1, 10, 5, 50, 6, 60 min 4Gb/;s.
Zasilacz	Minimum dwa redundantne zasilacze w każdym urządzeniu o mocy zapewniającej prawidłową pracę urządzenia.

Interfejsy sieciowe	Zamawiający oczekuje rozwiązania o wysokiej przepustowości transferowej opartej o technologie światłowodowe. Rozwiązanie powinno być dobrane pod względem wydajności do Systemu PSBK jednak wymaga się przepustowości nie mniejszej niż 1Gb Ethernet. Każde urządzenie serwerowe/storage musi posiadać jeden port typu Base-T dedykowany dla obsługi konsoli zarządzającej. Możliwość instalacji lub dodanie modułów udostępniających: -interfejsy sieciowe 1Gb Ethernet w standardzie BaseT; -interfejsy sieciowe 10Gb Ethernet ze złączami w standardzie SFP+
Dodatkowe sloty I/O	Serwery muszą umożliwiać instalację kart PCIe x16 czwartej generacji. W oferowanym rozwiązaniu muszą być dostępny minimum jeden slot wolny pod dalsze rozszerzenia.
Dodatkowe porty	• z przodu obudowy: 1x USB oraz dedykowany port USB zarządzania; • z tyłu obudowy: 2x USB, dedykowany port sieciowy zarządzania.
Chłodzenie	Wentylatory wspierające wymianę Hot-Swap, redundantne.
Zarządzanie niskopoziomowe	• Zintegrowany z płytą główną serwera, niezależny od systemu operacyjnego, sprzętowy kontroler zdalnego zarządzania; • Monitoring statusu i zdrowia systemu; • Logowanie zdarzeń; • Umożliwiający Update systemowego firmware; • Możliwość przywrócenia poprzednich wersji firmware; • Możliwość zdalnej konfiguracji serwera; • Zdalne włączanie/wyłączanie/restart; • Zrzut ekranu w momencie zawieszenia systemu; • Możliwość zdalnej instalacji systemu operacyjnego; • Wyświetlanie danych aktualnych i historycznych dla użycia energii i temperatury serwera nie mniej niż 7 dni wstecz; • Zdalny dostęp do graficznego interfejsu Web karty zarządzającej; • Szyfrowane połączenie (TLS) oraz autentykacje i autoryzację

użytkownika;

• Możliwość podmontowania zdalnych wirtualnych napędów;

• Wirtualną konsolę z dostępem do myszy, klawiatury;

• Wsparcie dla IPv6;

• Wsparcie dla SNMP; IPMI2.0, VLAN tagging, SSH;

• Możliwość zdalnego ustawienia limitu poboru prądu przez konkretny serwer;

• Integracja z Active Directory;

• Wsparcie dla automatycznej rejestracji DNS;

• Wsparcie dla LLDP;

• Wysyłanie do administratora maila z powiadomieniem o awarii lub zmianie konfiguracji sprzętowej;

• Możliwość podłączenia lokalnego poprzez złącze RS-232;

• Możliwość zarządzania bezpośredniego poprzez złącze microUSB umieszczone na froncie obudowy;

• Monitorowanie zużycia dysków SSD;

• Możliwość monitorowania z jednej konsoli min. 100 serwerami fizycznymi;

• Możliwość eksportu eksportu/importu konfiguracji (ustawienie karty zarządzającej, BIOSu, kart sieciowych, HBA oraz konfiguracji kontrolera RAID) serwera do pliku XML lub JSON;

• Możliwość zaimportowania ustawień, poprzez bezpośrednie podłączenie plików konfiguracyjnych.

Urządzenia hot swap

Dyski twarde, zasilacze oraz wentylatory.

Certyfikaty

Serwer musi być wyprodukowany zgodnie z normą ISO- 9001:2015 oraz ISO-14001 lub normy równoważne. Serwer musi posiadać deklarację CE.

Urządzenia wyprodukowane są przez producenta, zgodnie z normą PN-EN ISO 50001 lub normy równoważne lub oświadczenie producenta o stosowaniu w fabrykach polityki zarządzania energią, która jest zgodna z obowiązującymi przepisami na terenie Unii Europejskiej.

Oferowany serwer musi znajdować się na liście Windows Server Catalog lub posiadać status „Certified for Windows” dla systemów Microsoft Windows 2016, Microsoft Windows 2019 x64.

Oferowane serwery/macierze muszą znajdować się na liście zgodności Vmware.

Ograniczenia produkcyjne

Oferowane serwery muszą być wyprodukowane maksymalnie do 6 miesięcy przed datą dostawy.

Oferowane serwery muszą pochodzić wyłącznie z polskiej dystrybucji.

9. Gwarancja

9.1. Gwarancja sprzętu

a) 36 miesięcy gwarancji producenta, z czasem reakcji do następnego dnia roboczego (NBD) od przyjęcia zgłoszenia. Możliwość zgłaszania Wady 24h/dobę przez 365 dni w roku poprzez ogólnopolską linię telefoniczną producenta (firma serwisująca musi posiadać ISO 9001:2008 na świadczenie usług serwisowych oraz posiadać autoryzacje producenta urządzeń).

b) Wymagane jest dołączenie oświadczenia Producenta do protokołu odbioru Etapu II – Dostawa (sprzęt, kolokacja, łącza danych) oraz instalacja w infrastrukturze niezbędnej do wdrożenia, uruchomienia i zapewnienia prawidłowego działania Systemu, potwierdzające, że Serwis urządzeń będzie realizowany bezpośrednio przez Producenta i/lub we współpracy z Autoryzowanym Partnerem Serwisowym Producenta.

c) ~~W przypadku Wady dysków nośnik pozostaje u Zamawiającego. W przypadku awarii~~ ~~dysków twardych Zamawiający nie dopuszcza możliwości przekazania dysku do naprawy~~ ~~poza siedzibę Zamawiającego.~~ Zamawiający korzysta z usługi kolokowanej przestrzeni w Centrum Danych przez co należy rozumieć, że dostęp do przestrzeni kolokowanej ograniczony będzie wyłącznie dla Zamawiającego, tym samym należy traktować tą przestrzeń jako siedzibę Zamawiającego. Uszkodzony nośnik ze względu na konieczność zabezpieczenia danych pozostaje do dyspozycji Zamawiającego. Zamawiający informuje, że w takiej sytuacji wszystkie nośniki uznane za uszkodzone będą przechowywane w siedzibie Zamawiającego.

d) Usługi serwisowe muszą być świadczone w miejscu instalacji urządzenia oraz wymagana jest możliwość szybkiego zgłaszania Wad przez portal internetowy.

e) Dostęp do portalu/wsparcia technicznego producenta, który umożliwi zamawianie części zamiennych i/lub wizyt technika serwisowego, mający na celu przyśpieszenie i procesu diagnostyki i skrócenia czasu usunięcia Wady.

f) W przypadku wystąpienia Wady wsparcie techniczne ma rozwiązywać problemy z fabrycznie zainstalowanym oprogramowaniem.

g) W przypadku wystąpienia Wady wymagana jest natychmiastowa reakcja wsparcia technicznego (diagnostyka zaraz po wystąpieniu awarii).

h) Zamawiający wymaga aby sprzęt był objęty gwarancją od momentu podpisania protokołu odbioru Etapu II – Dostawa (sprzęt, kolokacja, łącza danych) oraz instalacja w infrastrukturze niezbędnej do wdrożenia, uruchomienia i zapewnienia prawidłowego działania Systemu.

i) Komunikacja serwisu musi odbywać się w języku polskim.

j) Zamawiający musi mieć możliwość sprawdzenia statusu gwarancji poprzez stronę producenta po podaniu unikatowego numeru urządzenia, oraz możliwość pobierania uaktualnień mikrokodu i sterowników nawet w przypadku wygaśnięcia gwarancji serwera

k) W przypadku braku możliwości naprawy sprzętu w siedzibie Zamawiającego, Wykonawca zapewni inny sprzęt o nie gorszych parametrach, do wykorzystania w czasie naprawy. Czas uruchomienia, w tym przypadku, w pełni sprawnego, systemu w pełnej wydajności i funkcjonalności nie może przekraczać 120 godzin uwzględniając zarówno wymianę uszkodzonego sprzętu i uruchomienie Systemu Teleinformatycznego PSBK. Natomiast w przypadku wystąpienia Wady dysku twardego, Wykonawca wymieni uszkodzony dysk twardy na inny, dysk twardy o nie gorszych parametrach, wolny od Wad. Czas uruchomienia, w tym przypadku, w pełni sprawnego, systemu w pełnej wydajności i funkcjonalności nie może przekraczać 120 godzin uwzględniając zarówno wymianę uszkodzonego dysku twardego i uruchomienie Systemu Teleinformatycznego PSBK. Inne komponenty sprzętu nie będące nośnikami danych (dotyczy także pamięci operacyjnej) naprawiane będą zgodnie z warunkami/zaleceniami (gwarancja) producenta oferowanego rozwiązania.

l) Koszty dojazdu serwisu lub transport uszkodzonego urządzenia nie obciążają Zamawiającego w okresie gwarancyjnym.

9.2. Gwarancja oprogramowania

a) Wykonawca zobowiązuje się do udzielenia gwarancji na oprogramowanie i współdziałanie oprogramowania Systemu oraz świadczenia serwisu minimum 24 miesięcy od daty zakończenia wdrożenia i odbioru całości oferowanego oprogramowania ~~i sprzętu~~.

b) Wykonawca zobowiązuje się do zapewnienia Zamawiającemu możliwości stabilnego i bezawaryjnego korzystania z Systemu. Poziom bezawaryjności, na poziomie 99,45% liczony dla każdego roku kalendarzowego obowiązywania umowy.

c) Wykonawca zapewnia, że w dniu podpisania Protokołu odbioru przedmiotu zamówienia System działa poprawnie oraz że jest zgodny z ~~obowiązującymi~~ przepisami prawa obowiązującymi na 30 dni przed terminem oddania do użytkowania Systemu ~~na dzień podpisania Protokołu odbioru przedmiotu zamówienia~~.

d) Zamawiający wymaga aby Wykonawca ~~zapewnił~~ w okresie gwarancji przyjmował zgłoszenia serwisowe od Zamawiającego ~~wsparcie powdrożeniowe polegające na~~ ~~diagnostyce zgłaszanych problemów eksploatacyjnych, oraz ich rozwiązywaniu~~. Wykonawca zobowiązany jest do ~~świadczenia Wsparcia w tym zakresie~~ przyjmowania zgłoszeń serwisowych w dni robocze w godzinach 8.00-16:00 pod numerem telefonu przez niego wskazanym. Do korzystania ~~ze wsparcia~~ z możliwości składania zgłoszeń serwisowych uprawnieni będą Administratorzy Systemu Teleinformatycznego PSBK.

e) Zamawiający wymaga od Wykonawcy pełnej obsługi zgłoszeń serwisowych zarówno w trybie pracy zdalnej jak i w siedzibie Zamawiającego ~~w celu wsparcia~~ ~~posprzedażowego~~ dla dostarczonego ~~sprzętu i~~ oprogramowania w okresie obowiązywania umowy.

f) Wykonawca zobowiązany jest do ~~świadczenia~~ podejmowania czynności serwisowych, rozumianych jako naprawę Wad, ~~przyjmowania zgłoszeń i podejmowania czynności~~ ~~serwisowych~~ w trybie minimum 8 godzin dziennie przez 5 dni w tygodniu i 365 dni rocznie z wyłączeniem dni przewidzianych ustawowo jako dni świąteczne.

g) Wszelkie ~~błędy~~ Wady będą ~~mogą~~ mogły być zgłaszane przez Zamawiającego, drogą elektroniczną lub telefonicznie.

h) Wykonawca będzie zobowiązany do niezwłocznego potwierdzania otrzymanego zgłoszenia drogą elektroniczną.

i) Wykonawca będzie zobowiązany do niezwłocznego podjęcia działań na każde potwierdzone zgłoszenie.

j) Za przyjęte uznaje się zgłoszenie, któremu nadano odpowiedni, unikalny numer zlecenia serwisowego przez Zamawiającego. W przypadku braku otrzymania potwierdzenia przyjęcia zgłoszenia wysłanego drogą elektroniczną, Zamawiający zobowiązany jest do przekazania zgłoszenia telefonicznie. Powtórne telefoniczne zgłoszenie uważa się za przyjęte w momencie tej rozmowy telefonicznej.

k) Informacja o usunięciu Wady zostanie każdorazowo po wykonaniu naprawy przesłana e- mailowo przez osobę upoważnioną po stronie Wykonawcy.

l) Po zarejestrowaniu zgłoszenia Wady za pośrednictwem poczty e-mail Zamawiający otrzyma potwierdzenie przyjęcia zgłoszenia. Czas rozpoczęcia naprawy jest liczony od potwierdzenia przyjęcia zgłoszenia przez Wykonawcę.

m) Pracownik Wykonawcy jest zobowiązany do kontaktu ze zgłaszającym Wadę w celu przekazania informacji o podjęciu działań naprawczych.

n) W przypadku Wady Wykonawca niezwłocznie przystąpi do jej usunięcia dokonując w tym celu Poprawki.

o) Zamawiający wymaga aby Wykonawca dotrzymał poniżej wymienionych czasów naprawy i usuwania ~~Błędów~~ Wad podanych w godzinach zegarowych (z wyłączaniem sprzętu):

• Awaria:

• dostęp zdalny – reakcja na zgłoszenie maksymalnie w ciągu 8 godzin, usunięcie w ciągu 24 godzin od momentu przywrócenia do pracy serwera po Awarii,

• naprawa w siedzibie Zamawiającego (w przypadku braku możliwości naprawy z wykorzystaniem dostępu zdalnego) – reakcja na zgłoszenie maksymalnie w ciągu 24 godzin, usunięcie do 48 godzin od momentu przywrócenia do pracy serwera po Awarii;

• Błąd krytyczny:

• dostęp zdalny – reakcja na zgłoszenie maksymalnie w ciągu 4 godzin, usunięcie w ciągu 16 godzin od momentu zgłoszenia do Wykonawcy wystąpienia Błędu,

• naprawa w siedzibie Zamawiającego (w przypadku braku możliwości naprawy z wykorzystaniem dostępu zdalnego) – reakcja na zgłoszenie maksymalnie w ciągu 8 godzin, usunięcie do 36 godzin od momentu zgłoszenia do Wykonawcy wystąpienia Błędu;

• Błąd ważny:

• dostęp zdalny – reakcja na zgłoszenie maksymalnie do 8 godzin, usunięcie do 48 godzin od momentu zgłoszenia do Wykonawcy wystąpienia wady,

• naprawa w siedzibie Zamawiającego (w przypadku braku możliwości naprawy z wykorzystaniem dostępu zdalnego) – reakcja na zgłoszenie maksymalnie do 8 godzin, usunięcie do 72 godzin od momentu zgłoszenia do Wykonawcy wystąpienia wady;

• Usterka:

• dostęp zdalny – reakcja na zgłoszenie maksymalnie do 8 godzin, usunięcie do 72 godzin od momentu zgłoszenia do Wykonawcy wystąpienia wady,

• naprawa w siedzibie Zamawiającego (w przypadku braku możliwości naprawy z wykorzystaniem dostępu zdalnego) – reakcja na zgłoszenie maksymalnie do 8 godzin, usunięcie do 96 godzin od momentu zgłoszenia do Wykonawcy wystąpienia wady.

p) W przypadku braku możliwości naprawy sprzętu w siedzibie Zamawiającego, Wykonawca zapewni inny sprzęt o nie gorszych parametrach, do wykorzystania w czasie naprawy. Czas uruchomienia, w tym przypadku, w pełni sprawnego, systemu w pełnej wydajności i funkcjonalności nie może przekraczać 120 godzin uwzględniając zarówno wymianę uszkodzonego sprzętu i uruchomienie Systemu Teleinformatycznego PSBK.

q) ~~Koszty dojazdu serwisu lub transport uszkodzonego urządzenia nie obciążają~~ ~~Zamawiającego w okresie gwarancyjnym.~~

10. Licencje

10.1.Zamawiający wymaga aby Wykonawca dostarczył pełen zestaw licencji wieczystych na System Teleinformatyczny PSBK, koniecznych do uruchomienia i poprawnej pracy opisanych w OPZ funkcjonalności. Wymaga się w szczególności dostarczenia: licencji na systemy operacyjne dostarczanych serwerów, licencji na komponenty Aplikacji, licencje bazy danych, licencje na technologie firm trzecich wspierające pracę Systemu.

10.2.Wszystkie dostarczone licencje nie mogą nakładać ograniczeń czasowych na prawo do użytkowania oprogramowania.

10.3.Dla oprogramowania wymagającego licencji obcych, nie będącego własnością Wykonawcy, ma on dostarczyć klucze licencyjne, nośniki oprogramowania lub wskazać miejsce umożliwiające pobranie oprogramowania w trybie online, dokumentację, licencje oraz wszelkie inne składniki dołączone do oprogramowania przez jego producenta. Licencje muszą być wystawione na Zamawiającego, a Wykonawca dopełni wszystkich formalności wymaganych prawem, licencją i innymi wymogami producenta zapewniających, że Zamawiający będzie pełnoprawnym użytkownikiem dostarczonego Systemu.

10.4.Udzielenie licencji wieczystej na korzystanie z całego Systemu oraz wszelkiego innego oprogramowania niezbędnego do prawidłowego działania dostarczonego rozwiązania.

11. Kopie zapasowe Systemu Teleinformatycznego PSBK

a) Dostarczone rozwiązanie programowo-sprzętowe musi być wyposażone w mechanizm automatycznego tworzenia kopii zapasowych wszystkich danych gromadzonych przez System Teleinformatyczny PSBK a także gwarantować odtworzenie całego systemu PSBK w przypadku Awarii.

b) Dostarczone rozwiązanie musi umożliwiać gromadzenie kopii zapasowych na niezależnym urządzeniu dyskowym typu Storage/Data Protection dostarczonym przez Wykonawcę.

c) Zamawiający musi mieć możliwość swobodnego ustalania harmonogramu automatycznego tworzenia kopii zapasowych. Maksymalna, dopuszczalna przez System częstotliwość wykonywania kopii automatycznych nie może być mniejsza, niż raz na dobę. Poza mechanizmem automatycznym System musi umożliwiać wykonanie kopii zapasowych w dowolnej chwili, na żądanie Administratora Systemu.

d) System musi zapewniać możliwość tworzenia kopii bezpieczeństwa w harmonogramie dobowym z retencją co najmniej 30 dniową.

e) Wykonawca musi zagwarantować bezpieczeństwo informacji znajdujących się w Systemie. W projekcie Systemu Teleinformatycznego PSBK opracowanym przez Wykonawcę musi znajdować się dokładny opis proponowanych rozwiązań w zakresie bezpieczeństwa Systemu oraz projekt konfiguracji infrastruktury Systemu i sposób jej zabezpieczenia.

f) System musi spełniać wymogi bezpieczeństwa zgodne ze standardem PN- ISO/IEC- 27001.

12. Opis i przebieg wdrożenia, harmonogram.

12.1.Zamawiający przewiduje wykonanie zamówienia w następujących Etapach oraz ramach czasowych:

a) Etap I – Analiza przedwdrożeniowa ~~– do 10 dni od podpisania umowy~~.

b) Etap II – Dostawa (sprzęt, kolokacja, łącza danych) oraz instalacja w infrastrukturze niezbędnej do wdrożenia, uruchomienia i zapewnienia prawidłowego działania Systemu – ~~do 60 dni od podpisania umowy.~~

c) Etap III – Testy poprawności Systemu ~~– do 7 dni od zakończenia etapu II~~.

d) Etap IV – Wdrożenie Poprawek – ~~do 7 dni od zakończenia etapu III~~.

e) Etap V – Optymalizacja i produkcyjna konfiguracja Systemu ~~- do 80 dni od podpisania~~ ~~umowy~~.

f) Etap VI – Odbiór Systemu i przekazanie do eksploatacji - do 90 dni od podpisania umowy.

g) Etap VII – Wsparcie Powdrożeniowe – 24 miesiące od zakończenia Etapu VI. ~~Etap I oraz II Wykonawca może realizować równocześnie.~~

Termin odbioru Systemu teleinformatycznego PSBK (Etap VI) nie może przekroczyć 90 dni od podpisania umowy za wyjątkiem przypadków przewidzianych umową. Zaproponowany czas realizacji Etapu VI przez Wykonawcę podlega ocenie na etapie oceny ofert.

12.2.Etap I Analiza przedwdrożeniowa

Wdrożenie Systemu ma poprzedzać przygotowanie przez Wykonawcę, we współpracy z Zamawiającym, analizy przedwdrożeniowej dla Systemu teleinformatycznego PSBK. W ramach realizacji niniejszego etapu Wykonawca dostarczy Zamawiającemu x.xx:

a) Dokładny opis proponowanych rozwiązań w zakresie bezpieczeństwa Systemu oraz projekt konfiguracji infrastruktury Systemu PSBK i sposób jej zabezpieczenia;

b) Przygotowany szczegółowy opis sposobu realizacji wszystkich wymagań funkcjonalnych związanych z Systemem określonych w niniejszym OPZ;

c) Opracowanie wykazu prac wdrożeniowych oraz niezbędnych prac programistycznych;

d) Opracowanie koncepcji uprawnień zawierającej opis ról systemowych wraz z relacjami pomiędzy poszczególnymi rolami systemowymi;

e) Wskazanie punktów krytycznych i zagrożeń mających wpływ na niezawodne działanie Systemu;

f) Projekt testowania Systemu, w tym scenariusze testowe;

g) Projekt importowania danych z systemów Ośrodków do Systemu PSBK;

h) Opracowanie Szczegółowego Harmonogramu.

Przedłożone dokumenty zostaną ocienione pod względem kompletności, aktualności, poprawności oraz szczegółowości. ~~Wykonawca musi dostarczyć powyższe dokumenty~~ ~~do 10 dnia od podpisania umowy.~~ Zamawiający po zapoznaniu się i akceptacji podpisze Protokół odbioru.

12.3.Etap II - Dostawa (sprzęt, kolokacja, łącza danych) oraz instalacja w infrastrukturze niezbędnej do wdrożenia, uruchomienia i zapewnienia prawidłowego działania Systemu:

a) Dostawa Systemu Informatycznego PSBK musi zawierać instalację pełnego i niezbędnego do pracy oprogramowania, dostawę i aktywację wszystkich niezbędnych licencji, oprogramowanie bazodanowe wraz niezbędną ilością licencji zarówno na instancje serwerowe jak i licencje typu CAL, oraz pełne wdrożenie, utrzymanie i stałe aktualizacje.

b) Zaproponowane przez Wykonawcę rozwiązanie musi obejmować wszelkie koszty pełnego zakresu usług, sprzętu, licencji, certyfikatów, gwarancji i innych niezbędnych składowych wymaganych do realizacji Przedmiotu zamówienia oraz wszystkie koszty związane z instalacją, konfiguracją oraz utrzymaniem usługi/serwera dedykowanego przez cały okres trwania umowy.

c) Zintegrowany System Informatyczny pod względem zasobów sprzętowych i programowych powinien składać się z:

• usługi kolokacyjnej (w Centrum Danych, szafa RACK);

• usług teletransmisji (łącza danych lokalnych i Internetowych);

• urządzeń komunikacyjnych (wymagane switche, routery, łączniki, okablowanie);

• adekwatnych do wymagań jakościowych i infrastrukturalnych urządzeń serwerowych zaproponowanych przez Wykonawcę;

• oprogramowania systemowego (systemy operacyjne serwerów);

• oprogramowania bazodanowego (baza danych – zaproponowana i dostarczona przez Wykonawcę);

• oprogramowania Aplikacyjnego (oprogramowanie będące głównym przedmiotem Umowy);

• oprogramowania dodatkowego (o ile będzie niezbędne do pracy użytkownika w Systemie lub określone w wymaganiach - zaproponowane i dostarczone przez Wykonawcę).

d) Xxxxxxxxxxx informuje, że korzysta obecnie z usługi kolokacji serwerów w Centrum Danych ATMAN Xxxxxxxx-0 xxxx xxxxx Xxxxxxxxxxxx 00x gdzie utrzymywana jest infrastruktura serwerowa Zamawiającego. Informacja jest podana wyłącznie w celu określenia możliwości i kosztów wybudowania przez Wykonawcę łącza L2 pomiędzy Centrum Danych i szafą RACK Systemu PSBK a farmą serwerów i siecią LAN Zamawiającego. Zamawiający jest odpowiedzialny za uzyskanie zgody od ATMAN na kolokację w Centrum Danych ATMAN Warszawa-1 przy ulicy Grochowskiej 21a, 04- 186 Warszawa, gdzie utrzymywana jest infrastruktura serwerowa Zamawiającego.

e) Wykonawca ma zapewnić niezbędną infrastrukturę techniczną dobraną zgodnie z wymaganiami OPZ. Zamawiający w Centrum Danych zapewni przestrzeń kolokacyjną, zasilanie oraz łącza. Po stronie Wykonawcy konieczne będzie skorelowanie usług z dostarczonym sprzętem tj. zapewnienie np.: niezbędnych przełączników oraz urządzenia brzegowego do połączenia z Internetem.

12.4.Etap III – Testy poprawności Systemu

Testy akceptacyjne Systemu będą wykonywane przez Zamawiającego w Środowisku testowym Zamawiającego.

a) Testy akceptacyjne mają na celu upewnienie się, że wszystkie elementy Systemu zostały poprawnie zaimplementowane.

b) Testy mają również potwierdzić, że System spełnia określone wymagania i nie zawiera Wad uniemożliwiających jego użycie.

c) Wykonawca ma obowiązek wspierać Zamawiającego w przeprowadzaniu Testów akceptacyjnych.

d) W trakcie prowadzenia Testów w Środowisku testowym Zamawiającego Wykonawca nie może wprowadzać zmian i Poprawek chyba, że taka zmiana lub Poprawka umożliwi ponowne Wznowienie przerwanych Testów i Zamawiający wyrazi na to zgodę.

e) Zamawiający przeprowadzi także inne testy w celu sprawdzenia czy System spełnia postawione przez Zamawiającego wymagania (testy niefunkcjonalne obejmujące testy wydajnościowe i testy bezpieczeństwa).

f) Przy realizacji etapu testowania może być obecny przedstawiciel Wykonawcy.

g) W razie potrzeby na wniosek Administratora Systemów Teleinformatycznych PSBK Wykonawca ma zapewnić obecność specjalistów w celu omówienia i rozwiązania przyczyn problemów.

h) Kryteria akceptacji Testów uznaje się za spełnione, gdy w wyniku przeprowadzenia Testów nie zgłoszono żadnej Wady.

i) Za błąd na etapie testowania uznaje się:

• nie spełnienie, tj. np. niezastosowanie lub niewprowadzenie, któregoś z wymagań funkcjonalnych i niefunkcjonalnych zawartymi w niniejszym dokumencie;

• nieprawidłowe działanie którejkolwiek funkcji opisanej w niniejszym dokumencie, tj. np. brak możliwości odczytu zaimportowanego pliku w wymaganym formacie do Systemu lub nieodczytywanie znaków specjalnych przez System;

• działanie Systemu niezgodnie z ~~przedstawioną~~ dokumentacją dostarczoną na zakończenie Etapu I, tj. np. System nie będzie posiadał funkcjonalności i właściwości opisanych w dokumentacji dostarczonej na zakończenie Etapu I;

• wystąpienie zdarzenia uniemożliwiającego poprawne wykonanie funkcji Systemu, tj. np. wystąpienie Wady na etapie testowania.

j) Po zakończeniu Testów akceptacyjnych Wykonawca przygotowuje raport z testów.

k) Zamawiający poprzez wskazanie testów wydajności rozumie określenie parametrów efektywności:

• zbadanie zależności czasowych jakie mogą wystąpić podczas eksploatacji oprogramowania. Zamawiającemu zależy na uzyskaniu maksymalnego komfortu i zadowolenia użytkownika (np.: krótki czas odpowiedzi, przeładowania strony, uzyskania wyników kwerendy),

• oszacowanie zużycia zasobów podczas eksploatacji.

l) Zamawiający poprzez przeprowadzenie testów bezpieczeństwa zamierza określić parametry: autentykacji, autoryzacji, integralności oraz poufności.

12.5.Etap IV – Wdrożenie poprawek

Wykonawca zobowiązany jest do usuwania wszystkich Wad wykrytych podczas prowadzenia Testów.

12.6.Etap V - Optymalizacja i produkcyjna konfiguracja Systemu

Etap ten obejmuje realizację prac konfiguracyjnych Systemu, mających na celu dostarczenie przez Wykonawcę gotowego, sparametryzowanego Systemu po odbytych Testach Akceptacyjnych.

Wykonawca jest zobowiązany do uwzględnienia w opracowaniu wszelkich uwag przedłożonych przez Zamawiającego w okresie realizacji przedmiotowego Etapu.

Po odebraniu Systemu, Zamawiający, będzie miał prawo do wykorzystywania Systemu na platformie testowej do testowania np. nowych rozwiązań, aktualizacji, szkolenia nowych użytkowników.

12.7.Etap VI - Odbiór Systemu i przekazanie do eksploatacji

Etap można rozpocząć w momencie odebrania wszystkich do tej pory zrealizowanych, etapów (we wszystkich wdrażanych częściach/modułach Systemu). Do czasu jego zakończenia wszystkie błędy w zainstalowanych i działających modułach będą zgłaszane na zasadach określonych w Umowie dla usług realizowanych po odebraniu Systemu. W związku z powyższym będą obowiązywały zasady i zapisy Umowy tak, jakby System został odebrany z tą różnicą, że dotyczą odebranego modułu.

a) Akceptacja etapu:

• Strony traktować będą odbiór Systemu jako ostatnie sprawdzenie poprawności funkcjonowania Systemu.

• W czasie odbioru System musi poprawnie działać spełniając wszystkie wymagania funkcjonalne jak i niefunkcjonalne, które zostały umieszczone w niniejszym dokumencie.

• Za niepoprawną pracę Systemu uważać się będzie wystąpienie Wady w czasie trwania odbioru Systemu.

b) W przypadku niepomyślnego wyniku odbioru Systemu, Wykonawca w terminie 8 dni kalendarzowych dokona stosownych poprawek Systemu i aktualizacji dokumentacji.

c) W okresie trwania odbioru Systemu Zamawiający wymaga wsparcia Konsultantów Wykonawcy w formie osobistej obecności specjalistów w siedzibie Zamawiającego.

d) Wykonawca nie może dokonywać w czasie odbioru Systemu żadnych poprawek lub zmian konfiguracyjnych w Systemie bez zgody upoważnionego przedstawiciela Zamawiającego.

e) Wykonawca nie może mieć bezpośredniego dostępu do Systemu (w tym logować się do Systemu na konta serwisowe) bez zgody upoważnionego przedstawiciela Zamawiającego.

12.8.Etap VII Wsparcie Powdrożeniowe

a) Wykonawca zobowiązuje się do zapewnienia nadzoru autorskiego i asysty w wymiarze 300 godzin programistycznych przez okres 24 miesięcy począwszy od zakończenia Etapu VI – Odbioru systemu i przekazania do eksploatacji

12.9.Modyfikacje w ramach etapu VII

a) Zamawiający oczekuje od Wykonawcy zapewnienia zgodności działania Systemu Teleinformatycznego PSBK z aktualnym stanem prawnym w obszarze problematyki udostępniania danych x.xx. z badań klinicznych, w szczególności dostosowanie Systemu Teleinformatycznego PSBK do powszechnie obowiązujących przepisów prawa, modyfikacji wynikających ze zmiany przepisów prawa w ramach 300 godzin programistycznych.

b) Pakiet modyfikacji modyfikowania Systemu Teleinformatycznego PSBK zgodnie z potrzebami Zamawiającego obejmuje wykonywanie, w okresie realizacji przedmiotu umowy, modyfikacji Systemu Teleinformatycznego PSBK wynikających z potrzeb i wymagań funkcjonalnych użytkowników Systemu Teleinformatycznego PSBK, w tym dostosowywanie portalu do nowych technologii informatycznych.

c) Każda modyfikacja Systemu Teleinformatycznego PSBK wykonywana będzie w sposób następujący:

• Zamawiający przygotuje merytoryczne założenia do modyfikacji Systemu Teleinformatycznego PSBK i przekaże je via e-mail do Wykonawcy, dalej

„wniosek”.

• Strony uzgodnią zakres modyfikacji oraz termin jej realizacji na podstawie wniosku przedstawionego przez Zamawiającego. Zamawiający na etapie postępowania przewiduje, że wniosek ten będzie wynikał z zapotrzebowania użytkowników na dodatkowe funkcje, niemniej Zamawiający nie wyklucza wniosku o modyfikację wynikającego z przyczyn innych. Termin realizacji będzie uwzględniał czas przewidziany na testy akceptacyjne Zamawiającego.

• Strony uzgodnią via e-mail realny termin na wprowadzenie zmian oraz wymiar roboczogodzin potrzebnych na ich implementacje.

• Jeżeli na etapie realizacji umowy wystąpi taka konieczność, Wykonawca na żądanie Zamawiającego opracuje dokumentację techniczną zleconej modyfikacji Systemu Teleinformatycznego PSBK i przekaże ją w ustalonej przez Strony formie Zamawiającemu.

• Zamawiający dokona akceptacji przekazanej dokumentacji technicznej zleconej modyfikacji Systemu Teleinformatycznego PSBK albo przekaże via e- mail i zastrzeżenia do Wykonawcy.

• Wykonawca będzie zobowiązany do uwzględnienia uwag i zastrzeżeń do dokumentacji technicznej zleconej modyfikacji Systemu Teleinformatycznego PSBK i przekazania jej do Zamawiającego w celu ostatecznej akceptacji.

• Wykonawca wykona modyfikację Systemu Teleinformatycznego PSBK na podstawie zaakceptowanej dokumentacji technicznej.

• Wykonawca zaktualizuje i przekaże Zamawiającemu dokumentację techniczną, administracyjną i użytkową zgodnie z zakresem wynikającym z modyfikacji. Ostateczny zakres dokumentacji zostanie uzgodniony z Zamawiającym.

• Wykonawca przygotuje i przekaże Zamawiającemu patch lub upgrade Systemu Teleinformatycznego PSBK zawierający modyfikację wraz z instrukcją jego implementacji.

• Zamawiający po sprawdzeniu kompletności doręczonego patcha lub upgrade Systemu Teleinformatycznego PSBK wraz z Wykonawcą wdrożą go do Systemu Teleinformatycznego PSBK.

• Wszystkie modyfikacje wprowadzone do Systemu Teleinformatycznego PSBK będą stanowiły integralną jego część.

• Oszacowanie wykorzystanych roboczogodzin za modyfikacje nastąpi na podstawie podpisanego przez Xxxxxx protokołu odbioru, do którego konieczne jest załączenie zaakceptowanej przez Zamawiającego dokumentacji technicznej danej modyfikacji Systemu Teleinformatycznego PSBK.

d) Każda wykonana praca przez Wykonawcę na rzecz Zamawiającego będzie udokumentowana Raportami Modyfikacyjnymi .

e) Raport Modyfikacyjny będzie zawierał szczegółowe informacje, co najmniej:

• numer zgłoszenia,

• informacja o przyjęciu zgłoszenia w formie telefonicznej lub email,

• data i godzina zgłoszenia (w formacie yyyy-mm-dd hh:mm),

• określenie zgłaszającego Administratora wraz z numerem telefonu kontaktowego i poczty elektronicznej,

• określenie poziomu zgłoszenia,

• opis zgłoszonego problemu,

• imię i nazwisko osoby przyjmującej zgłoszenie,

• data i godzina rozwiązania problemu (w formacie yyyy-mm-dd hh:mm),

• sposób rozwiązania problemu,

• czas poświęcony na realizację danego zgłoszenia,

• liczbę godzin wykorzystanych na dany moment – narastająco,

Dodatkowo w raporcie tym Wykonawca zobowiązany jest do podania przyczyn przekroczenia wymaganego terminu.

f) Klasyfikacja zmian oprogramowania możliwych do wykonywania w trakcie eksploatacji:

• udoskonalenia - zmiany oprogramowania mające na celu poprawienie funkcjonalności, stabilności lub bezpieczeństwa użytkowania. Nie zmieniają cech podstawowych produktu, poprawiają jego funkcjonowanie, objęte realizowanym zamówieniem,

• modyfikacje – zmiany w oprogramowaniu na życzenie Zamawiającego, celem zaspokojenia jego indywidualnych potrzeb, objęte realizowanym zamówieniem,

• uaktualnienia - zmiany prowadzące do uaktualnienia wersji oprogramowania objęte realizowanym zamówieniem,

12.10. Ogólne zasady współpracy z Wykonawcą

a) Regularne spotkania Zamawiającego z Wykonawcą będą odbywać się nie rzadziej niż raz na 2 tygodnie.

b) W przypadku obopólnej zgody Zamawiający i Wykonawca mogą zrezygnować z organizacji regularnych spotkań.

c) Termin każdego regularnego spotkania zostanie ustalony co najmniej z tygodniowym wyprzedzeniem.

d) W przypadku potrzeby, Zamawiający ma prawo zorganizować dodatkowe spotkanie. Zamawiający musi poinformować Wykonawcę o planowanym spotkaniu co najmniej z 3- dniowym wyprzedzeniem.

e) W przypadku potrzeby, Wykonawca ma prawo zorganizować dodatkowe spotkanie. Wykonawca musi poinformować Zamawiającego o planowanym spotkanku co najmniej z 3-dniowym wyprzedzeniem.

f) Spotkania mogą być organizowane w formie on-line oraz stacjonarnej. Zamawiający preferuje spotkania w formie on-line.

g) Spotkania stacjonarne muszą odbywać się w siedzibie Zamawiającego.

h) Wykonawca musi informować na bieżąco Zamawiającego o stanie realizacji Zamówienia.

i) Wykonawca musi na bieżąco informować Zamawiającego o problemach i ryzykach w powstałych w trakcie realizacji Zamówienia.

13. Personel

13.1.Zamawiający wymaga od Wykonawcy, że skieruje do realizacji zamówienia publicznego:

a) Kierownika Projektu – 1 osoba, który:

• posiada kwalifikacje potwierdzone certyfikatem: PRINCE2 lub Project Management Professional (PMP) lub ~~wyższym~~ równoważnym w innej technice zarządzania;

• pełnił funkcję kierownika projektu w co najmniej jednym zakończonym wdrożeniem produkcyjnym projekcie informatycznym w sektorze ochrony zdrowia przez okres nie krótszy niż 3 miesiące w ciągu ostatnich 5 lat;

b) Analityk – 1 osoba, który:

• posiada co najmniej 12 miesięczne doświadczenie w zakresie: zbierania i specyfikacji wymagań funkcjonalnych i niefunkcjonalnych w sektorze

ochrony zdrowia, opracowywaniu założeń i identyfikowania ograniczeń systemowych;

• posiada co najmniej 12 miesięczne doświadczenie w zakresie opracowywania: modelu danych (zakresu gromadzonych i przetwarzanych danych) wraz z modelem przepływu danych pomiędzy systemami w sektorze ochrony zdrowia;

• posiada co najmniej 12 miesięczne doświadczenie w zakresie znajomości elementów semantyki (w tym klasyfikacji: ICD-9, ICD-10, ICD-O-3, sprawozdawczości NFZ).

13.2.Zamawiający wymaga od Wykonawcy skierowania do realizacji wystarczającej liczby osób aby zrealizować Zamówienie zgodnie z harmonogramem.

W dowolnym momencie w toku realizacji Zamówienia Zamawiający jest uprawniony do weryfikacji kwalifikacji Personelu, a Wykonawca jest zobowiązany na każde wezwaniem Zamawiającego niezwłocznie udokumentować te kwalifikacje.

14. Dokumentacja

a) Najpóźniej w pierwszym dniu Etapu VI odbioru Systemu i przekazania do eksploatacji, Wykonawca dostarczy Zamawiającemu dokumentację techniczną, w szczególności powykonawczą, wyniki testów oraz dokumentację z procesu wdrożenia Systemu Teleinformatycznego PSBK oraz dokumentację Systemu Teleinformatycznego PSBK w wersjach:

• Dokumentacja dla Administratora Systemu Teleinformatycznego PSBK zawierająca opis i działanie poszczególnych elementów Systemu;

• Dokumentacja programistyczna zawierająca opis technologii, umożliwiającą wdrożenie programisty w celu późniejszego jej rozwoju.

b) Dodatkowo, w ramach każdorazowej aktualizacji Wykonawca dostarczy dokumentację po aktualizacji w wersji jednolitego dokumentu. Takiej dokumentacji oczekuje Zamawiający po każdorazowej zmianie wersji oprogramowania lub modyfikacji kodu źródłowego z wyliczeniem wykorzystanego czasu pracy programisty jak i pozostałego czasu do wykorzystania.

Document Metadata

Table of Contents

Opis Przedmiotu Zamówienia

Document Metadata