Lubuskie...Projekt współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju...

Projekt współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego w ramach Lubuskiego Regionalnego Programu Operacyjnego na lata 2007 – 2013.

Strona 1 z 208

Znak sprawy: DA.III.272.1.1.2015 Załącznik Nr 2 do SIWZ

Województwo Lubuskie

Urząd Marszałkowski Województwa Lubuskiego w Zielonej Górze

OPIS PRZEDMIOTU ZAMÓWIENIA w postępowaniu o udzielenie zamówienia publicznego na realizację projektu pod nazwą:

„Lubuskie e - Zdrowie”

„Dostawa i wdrożenie systemów informatycznych oraz infrastruktury IT

dla Urzędu Marszałkowskiego Województwa Lubuskiego”

Dokument opracowany przez:

Europejskie Centrum Technologii Informatycznych i Zarządzania ITmed Sp. z o.o.

Zielona Góra, ………….. 2014 r.


Strona 2 z 208

Spis treści

I. Cel realizacji Projektu 3 II. Ogólny opis Projektu Lubuskie e - Zdrowie 4 III. Wymagania ogólne wdrożenia Projektu „Lubuskie e –Zdrowie” 8 III.1. Akty prawne i normy, z którymi musi być zgodne dostarczane oprogramowanie 8 III.2. Wymagania w zakresie zarządzania, dokumentacji Projektu oraz komunikacji 9 III.3. Słownik pojęć 10 III.4. Procedura testowania urządzeń oraz wdrożonego oprogramowania 19

III.4.1. Testy funkcjonalne. 19 III.4.2. Testy integracyjne Systemu 21 III.4.3. Testy wydajnościowe Systemu 21

III.5. PROCEDURA ODBIORU SPRZĘTU ORAZ WDROŻEŃ OPROGRAMOWANIA 22 III.5.1. Odbiór komponentów 22 III.5.2. Odbiór etapu. 23 III.5.3. Odbiór końcowy 23

III.6. Organizacja wdrożenia 24 III.6.1. Przygotowanie Projektu struktury Systemu „Lubuskie e - Zdrowie” 26 III.6.2. Dostawa i instalacja infrastruktury sieciowej 27 III.6.3. Dostawa i instalacji infrastruktury sprzętowej 27 III.6.4. Dostawa i instalacja Oprogramowania systemowego i narzędziowego 28 III.6.5. Dostawa, instalacja i konfiguracja Oprogramowania aplikacyjnego 28 III.6.6. Integracja Data Center z Uczestnikami Projektu (podmiotami leczniczymi) 28 III.6.7. Szkolenia 28 III.6.8. Testy 33 III.6.9. Promocja 33 III.6.10. Odbiór końcowy 33

IV. Miejsce realizacji dostaw i usług 34 V. Termin wykonania zamówienia - harmonogram 35 VI. Szczegółowy opis przedmiotu zamówienia 36 VI.1. Zadanie I: Elektroniczne wysłanie wniosku do jednostek ochrony zdrowia o powtórzenie recepty w przypadkach chorób przewlekłych oraz portal informacyjny 36

VI.1.1. Opis ogólny usługi 36 VI.1.2. Wymagania 37

VI.2. Zadanie II: System zarządzania i raportowania jednostek służby zdrowia na potrzeby samorządu województwa 50

VI.2.1. Systemy medyczne klasy HIS 50 VI.2.2. Systemy administracyjne klasy ERP 65 VI.2.3. Centralna aplikacja BI 81

VI.3. Zadanie III: Infrastruktura techniczna niezbędna dla realizacji projektu 113 VI.3.1. Adaptacja pomieszczenia na potrzeby serwerowni oraz DataCenter w UMWL 113 VI.3.2. Modernizacja i doposażenie serwerowni u Uczestników Projektu 147 VI.3.3. Rozbudowa infrastruktury na potrzeby projektu 189


Strona 3 z 208

I. Cel realizacji Projektu

Celem nadrzędnym Projektu jest stworzenie infrastruktury teleinformatycznej umożliwiającej

uruchomienie e-usług z zakresu ochrony zdrowia na poziomie regionalnym oraz służącej

upowszechnianiu stosowania technik ICT (ang. Information and Communication Technologies –

technologie informacyjne i komunikacyjne).

Wśród celów szczegółowych, na poziomie rezultatów długoterminowych wymienić należy:

rozwój usług elektronicznych związanych z e-Zdrowiem,

poprawę jakości i efektywności ochrony zdrowia w regionie,

poprawę dostępności do świadczeń zdrowotnych dla mieszkańców województwa lubuskiego,

usprawnienie procesu gromadzenia danych i informacji,

przyspieszenie dostępu do danych i informacji,

zdobycie nowych umiejętności przez pracowników sektora ochrony zdrowia,

wspomaganie podejmowania decyzji medycznych i zarządczych,

kreowanie polityki zdrowotnej regionu,

poprawę jakości nadzoru właścicielskiego.


Strona 4 z 208

II. Ogólny opis Projektu Lubuskie e - Zdrowie

Zakres rzeczowy Projektu obejmuje realizację 3 zadań merytorycznych:

1. Zadanie I - Wykonanie portalu informacyjnego z wdrożeniem usługi elektronicznego

wysłania wniosku do jednostek ochrony zdrowia o powtórzenie recepty w przypadkach

chorób przewlekłych.

2. Zadanie II - Wdrożenie systemu zarządzania i raportowania jednostek służby zdrowia na

potrzeby Samorządu Województwa.

3. Zadanie III - Dostawa infrastruktury technicznej niezbędnej dla realizacji projektu.

Zadanie I: Wykonanie portalu informacyjnego z wdrożeniem usługi elektronicznego wysłania

wniosku do jednostek ochrony zdrowia o powtórzenie recepty w przypadkach chorób przewlekłych

Usługa wytworzona w ramach zadania I ma umożliwić pacjentom składanie przez Internet wniosków

dotyczących recept o stałej, długoterminowej ordynacji lub zarejestrowanie się do lekarza jeśli

konieczna będzie taka wizyta przed wypisaniem recepty. Jest to możliwe tylko w przypadku chorób o

długotrwałym przebiegu, w których sposób leczenia został ściśle zdefiniowany. W takich przypadkach

pacjenci najczęściej otrzymują recepty na leki o identycznym składzie i takim samym dawkowaniu.

Usługa musi być realizowana na poziomie placówek zgodnie z art. 42. ustawy z dnia 5 grudnia 1996 r.

o zawodach lekarza i lekarza dentysty(tekst jednolity Dz. U. 2008, nr 136, poz. 857 z późn. zm.) oraz z

zachowaniem przepisów określonych w art. 20 ustawy z dnia 27 sierpnia 2004 r. o świadczeniach opieki

zdrowotnej finansowanych ze środków publicznych (tekst jednolity Dz. U. 2008, nr 164, poz. 1027 z

późn. zm.).

Uruchomienie usługi wymaga stworzenia internetowego portalu informacyjnego. Projektowany portal

ma również pełnić rolę platformy informacyjno-komunikacyjnej i stanowić bazę wiedzy dla pacjentów.

Będzie można w nim zamieścić informacje o wszelkiego rodzaju zdrowotnych inicjatywach

profilaktycznych, o organizacji ochrony zdrowia w regionie lub o ewentualnych zmianach w organizacji

opieki zdrowotnej dla pacjentów, kalkulatory zdrowotne, informacje o interakcjach i zamiennikach

leków, porady i artykuły specjalistów z różnych dziedzin medycyny oraz informacje o rodzaju zakresie

i świadczonych przez podmiot leczniczy usług medycznych.

Podstawowa usługa portalu zostanie zaimplementowana w oparciu o regionalną platformę integrującą

lokalne portale intranetowe. Obsługa recept musi zostać zrealizowana w taki sposób, aby

zminimalizować ryzyko naruszenia bezpieczeństwa danych medycznych.

Do przeglądania treści ogólnych portalu informacyjnego nie będzie wymagane konto. Ta część portalu

będzie dostępna dla wszystkich użytkowników Internetu, przy czym w celach statystycznych należy

wdrożyć oprogramowanie analityczne i raportujące, które pozwoli zebrać informacje dotyczące wejść

na poszczególne podstrony z uwzględnieniem pory dnia oraz struktury regionalnej poprzez

wykorzystanie adresów IP.

Część portalu związana z obsługą recept będzie wymagała założenia konta. Składanie wniosku o

receptę lub rejestracja na wizytę przez pacjenta po zalogowaniu do systemu, odbywać się będzie


Strona 5 z 208

poprzez formularz elektroniczny, na podstawie którego będą kierowane żądania do odpowiednich

podmiotów leczniczych.

Zadanie II: System zarządzania i raportowania jednostek służby zdrowia na potrzeby Samorządu

Województwa.

System zarządzania i raportowania jednostek ochrony zdrowia na potrzeby Samorządu Województwa

obejmuje przygotowanie systemu wspomagającego zarządzanie w podmiotach leczniczych oraz

wspierającego podejmowanie decyzji z zakresu kreowania polityki zdrowotnej regionu z poziomu

organu właścicielskiego. System będzie posiadał funkcjonalność zbiorczego, analitycznego

raportowania dla ustalonych przekrojów danych dostępnych w systemach informatycznych jednostek

(analityka zarządcza) – wprowadzony jako usługa dla UMWL oraz e-usługa dla Uczestników Projektu.

Funkcjonowanie e-Usługi będzie oparte o lokalne systemy dziedzinowe oraz przepływ informacji

pomiędzy jednostkami uczestniczącymi w projekcie a Urzędem Marszałkowskim poprzez pliki

strukturalne z raportami o określonej zawartości. Dane będą przetwarzane na poziomie regionalnym

przez system BI. Podstawową funkcją systemu będzie przygotowywanie raportów analitycznych. W

systemie będą dostępne raporty predefiniowane (zgodne z już funkcjonującymi w zakresie ochrony

zdrowia, sprawozdawczości finansowej, rachunkowości zarządczej oraz mechanizmów budżetowania i

controllingu oraz opartymi na doświadczeniu osób wdrażających system) a także raporty na życzenie.

Po wdrożeniu aplikacji możliwe będzie przygotowywanie i opracowywanie tematycznych raportów

zgodnie z oczekiwaniem Urzędu Marszałkowskiego i kierowników podmiotów leczniczych a także

przygotowanie i opracowanie dowolnego raportu możliwego do uzyskania na podstawie danych

umieszczonych w repozytorium.

Zadanie III: Infrastruktura techniczna niezbędna dla realizacji projektu

Zakres inwestycyjny dotyczący infrastruktury technicznej można podzielić na dwa obszary:

doposażenie placówek medycznych dla potrzeb Projektu,

dostarczenie i uruchomienie sprzętu w celu zapewnienia możliwości uruchomienia e-usług. Zakres rzeczowy tego zadania jest następujący :

modernizacja serwerowni głównej – w 12 jednostkach ochrony zdrowia: o Samodzielny Publiczny Zakład Opieki Zdrowotnej „Przychodnia Dworcowa” w

Gorzowie Wielkopolskim. o Samodzielna Publiczna Wojewódzka Stacja Pogotowia Ratunkowego w Gorzowie

Wielkopolskim. o Wielospecjalistyczny Szpital Wojewódzki w Gorzowie Wlkp. Sp. z o.o.. o Samodzielny Publiczny Szpital dla Nerwowo i Psychicznie Chorych w Międzyrzeczu o Wojewódzki Szpital Specjalistyczny dla Nerwowo i Psychicznie Chorych Samodzielny

Publiczny Zakład Opieki Zdrowotnej w Ciborzu o Ośrodek dla Osób Uzależnionych Samodzielny Publiczny Zakład Opieki Zdrowotnej

„Nowy Dworek” o Lubuski Ośrodek Rehabilitacyjno - Ortopedyczny im. dr Lecha Wierusza Samodzielny

Publiczny Zakład Opieki Zdrowotnej w Świebodzinie


Strona 6 z 208

o Wojewódzka Stacja Pogotowia Ratunkowego Samodzielny Publiczny Zakład Opieki Zdrowotnej w Zielonej Górze

o Samodzielny Publiczny Zakład Opieki Zdrowotnej „MEDKOL” w Zielonej Górze o Wojewódzki Ośrodek Terapii Uzależnień i Współuzależnienia w Zielonej Górze o Szpital Wojewódzki Samodzielny Publiczny Zakład Opieki Zdrowotnej w Zielonej Górze o SP ZOZ Centrum Leczenia Dzieci i Młodzieży w Zaborze

modernizacja infrastruktury sieci LAN – w 7 jednostkach ochrony zdrowia: o Wojewódzka Stacja Pogotowia Ratunkowego Samodzielny Publiczny Zakład Opieki

Zdrowotnej w Zielonej Górze, o Samodzielna Publiczna Wojewódzka Stacja Pogotowia Ratunkowego w Gorzowie

Wielkopolskim. o Wojewódzki Ośrodek Medycyny Pracy w Zielonej Górze, o Wojewódzki Ośrodek Medycyny Pracy w Gorzowie Wielkopolskim, o Samodzielny Publiczny Szpital dla Nerwowo i Psychicznie Chorych w Międzyrzeczu o Wojewódzki Ośrodek Terapii Uzależnień i Współuzależnienia w Zielonej Górze o Samodzielny Publiczny Zakład Opieki Zdrowotnej Centrum Leczenia Dzieci i Młodzieży

w Zaborze

zakup sprzętu komputerowego – w 15 jednostkach ochrony zdrowia: o Samodzielny Publiczny Zakład Opieki Zdrowotnej „Przychodnia Dworcowa” w

Gorzowie Wielkopolskim. o Wojewódzki Ośrodek Medycyny Pracy w Gorzowie Wielkopolskim. o Samodzielna Publiczna Wojewódzka Stacja Pogotowia Ratunkowego w Gorzowie

Wielkopolskim. o Wielospecjalistyczny Szpital Wojewódzki w Gorzowie Wielkopolskim Sp. z o.o. o Samodzielny Publiczny Szpital dla Nerwowo i Psychicznie Chorych w Międzyrzeczu o Lubuski Szpital Specjalistyczny Pulmonologiczno-Kardiologiczny w Torzymiu o Wojewódzki Szpital Specjalistyczny dla Nerwowo i Psychicznie Chorych Samodzielny

Publiczny Zakład Opieki Zdrowotnej w Ciborzu o Ośrodek dla Osób Uzależnionych Samodzielny Publiczny Zakład Opieki Zdrowotnej

„Nowy Dworek” o Lubuski Ośrodek Rehabilitacyjno - Ortopedyczny im. dr Lecha Wierusza Samodzielny

Publiczny Zakład Opieki Zdrowotnej w Świebodzinie o Wojewódzka Stacja Pogotowia Ratunkowego Samodzielny Publiczny Zakład Opieki

Zdrowotnej w Zielonej Górze o Wojewódzki Ośrodek Medycyny Pracy w Zielonej Górze o Samodzielny Publiczny Zakład Opieki Zdrowotnej „MEDKOL” w Zielonej Górze o Wojewódzki Ośrodek Terapii Uzależnień i Współuzależnienia w Zielonej Górze o Szpital Wojewódzki Samodzielny Publiczny Zakład Opieki Zdrowotnej w Zielonej Górze o Samodzielny Publiczny Zakład Opieki Zdrowotnej Centrum Leczenia Dzieci i Młodzieży

w Zaborze

Inwestycje związane z uruchomieniem e-Usług będą natomiast różne dla jednostek ochrony zdrowia

oraz dla Urzędu Marszałkowskiego Województwa Lubuskiego w Zielonej Górze.

Dla podmiotów leczniczych konieczne będzie:

zakup i uruchomienie platformy serwerowej o średniej wydajności i wysokim stopniu niezawodności w celu uruchomienia lokalnego portalu.

Dla Urzędu Marszałkowskiego konieczne będzie:


Strona 7 z 208

wyposażenie pomieszczenia na potrzeby serwerowni – modernizacja Data Center,

konfiguracja urządzeń chroniących styk z siecią publiczną zapewniających zestawienie bezpiecznych (szyfrowanych) kanałów transmisji,

zakup odpowiednich licencji dla oprogramowania systemowego.

W projekcie bierze udział 15 podmiotów leczniczych - Uczestników Projektu oraz Województwo

Lubuskie. Aby osiągnąć założone cele i rezultaty należy doprowadzić zasoby informatyczne wszystkich

Uczestników do poziomu niezbędnego do ich realizacji. W przypadku Urzędu Marszałkowskiego

konieczne będzie uruchomienie odpowiedniego wyposażenia serwerowego dedykowanego do obsługi

komponentów centralnych czyli portalu oraz systemu raportowania zarządczego klasy (BI). W

placówkach medycznych należy natomiast uruchomić lokalne portale a także zapewnić zasilenie

danymi systemu BI co oznacza zakup oprogramowania oraz przygotowanie systemów dziedzinowych

do eksportowania danych w określonych formatach i zakresach.


Strona 8 z 208

III. Wymagania ogólne wdrożenia Projektu „Lubuskie e –Zdrowie”

III.1. Akty prawne i normy, z którymi musi być zgodne dostarczane

oprogramowanie

1) Ustawa z dnia 15 kwietnia 2011r. o działalności leczniczej (Dz. U. z 2011r. nr 112 poz. 654 z późn. zm.),

2) Ustawa z dnia 27 sierpnia 2004 roku o świadczeniach opieki zdrowotnej finansowanych ze środków publicznych (Dz. U. z 2008 r., Nr 164, poz. 1027 z późn. zm.)

3) Ustawa z dnia 29 września 1994r. o rachunkowości (tekst jednolity z 2009r. Dz. U. nr 152 poz. 1223 z późn. zm.),

4) Ustawa z dnia 11 marca 2004r. o podatku od towarów i usług (tekst jednolity z 2011r. Dz. U. nr 177 poz. 1054 z późn. zm.),

5) Rozporządzenie Ministra Finansów z dnia 17 grudnia 2010r. w sprawie przesyłania faktur w formie elektronicznej, zasad ich przechowywania oraz trybu udostępniania organowi podatkowemu lub organowi kontroli skarbowej (Dz. U. z 2010r. nr 249 poz. 1661),

6) Ustawa z dnia 26 lipca 1991r. o podatku dochodowym od osób fizycznych (tekst jednolity z 2012r. nr 0 poz. 361 z późn. zm.),

7) Rozporządzenie Ministra Zdrowia i Opieki Społecznej z dnia 22 grudnia 1998 r. w sprawie szczególnych zasad rachunku kosztów w publicznych zakładach opieki zdrowotnej (Dz.U. z 1998r. nr 164 poz. 1194 z późn. zm.).W związku z tym, iż to rozporządzenie zostało uchylone, a nie wydano w tym zakresie nowych przepisów Wykonawca jest zobowiązany dostarczyć Oprogramowanie uwzględniające zasady określone w treści tego aktu lub w wydanych w toku realizacji zamówienia odpowiednich przepisów prawa.

8) Ustawa z dnia 5 grudnia 2008r. o zapobieganiu oraz zwalczaniu zakażeń i chorób zakaźnych u ludzi (Dz. U. nr 234 poz. 1570 z późn. zm.) – dotyczy Systemu medycznego HIS - Monitorowanie zakażeń zakładowych.

9) Ustawa z dnia 29 sierpnia 1997r. o ochronie danych osobowych (tekst jednolity z 2002r. Dz. U. nr 101 poz. 926 z późn. zm.), System musi przechowywać informacje o:

a) dacie wprowadzenia danych osobowych,

b) identyfikator użytkownika wprowadzającego dane osobowe,

c) źródło danych (o ile dane nie pochodzą od osoby, której te dane dotyczą),

d) informacje o odbiorcach danych, którym dane osobowe zostały udostępnione,

e) dacie i zakresie tego udostępnienia,

f) data modyfikacji danych osobowych.

10) Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz.U. z 2004r. nr 100 poz.1024),

11) Rozporządzenie Ministra Zdrowia z dnia 20 września 2012r w sprawie warunków, sposobu i trybu zaopatrywania pacjentów szpitala w znaki identyfikacyjne oraz sposobu postępowania w razie stwierdzenia ich braku (Dz. U. z 2012r. nr 0 poz. 1098) – dotyczy Systemu medycznego HIS),


Strona 9 z 208

12) Rozporządzenie Ministra Zdrowia z dnia 21 grudnia 2010r. w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej przetwarzania (Dz. U. z 2010r. nr 252 poz. 1697 z późn. zm.),

13) Ustawa z dnia 6 listopada 2008 r. o prawach pacjenta i rzeczniku praw pacjenta (Dz. U. 2009r. Nr 52 poz. 417 z późn. zm.),

14) Ustawa z dnia 26 czerwca 1974r. Kodeks pracy (Dz.U. 1998 nr 21 poz. 94 z późn. zm.),

15) Ustawa z dnia 23 stycznia 2003r. o powszechnym ubezpieczeniu w Narodowym Funduszu Zdrowia (Dz.U. 2003 nr 45 poz. 391 z późn. zm.),

16) Ustawa z dnia 25 czerwca 1999r. o świadczeniach pieniężnych z ubezpieczenia społecznego w razie choroby i macierzyństwa (tekst jednolity z 2010r. Dz.U. nr 77 poz. 512 z późn. zm.),

17) Ustawa z dnia 13 października 1998r. o systemie ubezpieczeń społecznych (tekst jednolity z 2009r. Dz.U. nr 205 poz. 1585 z późn. zm.),

18) Ustawa z dnia 17 lutego 2005r o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz.U z 2005r. nr 64 poz. 565 z późn. zm.),

19) Ustawa z 28 kwietnia 2011r. o systemie informacji w ochronie zdrowia (tekst jednolity Dz.U. 2011r. Nr 112, poz.654 z późn. zm.),

20) Rozporządzenie Ministra Zdrowia z dnia 20 czerwca 2008 r. w sprawie zakresu niezbędnych informacji gromadzonych przez świadczeniodawców, szczegółowego sposobu rejestrowania tych informacji oraz ich przekazywania podmiotom zobowiązanym do finansowania świadczeń ze środków publicznych (Dz.U. 2008 nr 123 poz. 801 z późn. zm.),

21) Rozporządzenie Ministra Zdrowia z dnia 23 marca 2006 r. w sprawie standardów jakości dla medycznych laboratoriów diagnostycznych i mikrobiologicznych (Dz.U. 2006 nr 61 poz. 435 z późn. zm.),

22) Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012r. 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 (Dz. U. z 2012r. nr 0 poz.526),

23) Zarządzenie Nr 14/2013/DSOZ Prezesa Narodowy Funduszu Zdrowia z dnia 21 marca 2013 r. zmieniające zarządzenie w sprawie określenia szczegółowych komunikatów sprawozdawczych XML dotyczących świadczeń ambulatoryjnych i szpitalnych,

24) Zarządzenie Nr 56/2014/DI Prezesa Narodowego Funduszu Zdrowia z dnia 29 sierpnia 2014 r. zmieniające zarządzenie w sprawie szczegółowego komunikatu XML dotyczącego przekazywania dokumentów rozliczeniowych w postaci dokumentu elektronicznego,

25) Wytyczne i standardy opublikowane przez Centrum Systemów Informacyjnych Ochrony Zdrowia dla Platformy P1 obowiązujące na dzień składania ofert.

III.2. Wymagania w zakresie zarządzania, dokumentacji Projektu oraz

komunikacji

Projekt ma być realizowany z wykorzystaniem metodyki zarządzania projektami PRINCE2 lub

równoważnej. PRINCE2 jest strukturalną metodyką efektywnego zarządzania projektami. Zgodnie z

metodyką realizacja Przedmiotu Zamówienia jest projektem, którego realizacja ma wytworzyć

określone produkty. W związku z tym Wykonawca zobowiązany jest postępować w trakcie realizacji


Strona 10 z 208

zgodnie z metodyką PRINCE2 lub równoważną oraz przedstawić w terminie 10 dni roboczych po

podpisaniu umowy harmonogram Projektu zgodny z tą metodyką.

Współpraca Zamawiającego z Wykonawcą będzie prowadzona zgodnie z „Planem Wdrożenia Projektu”

w zakresie dotyczącym:

osób funkcyjnych i ich zakresów odpowiedzialności,

komunikacji w projekcie pomiędzy Stronami,

obiegu dokumentów,

zarządzania zmianami i ryzykiem.

W razie audytu lub kontroli realizacji prac Wykonawca zobowiązany jest do współpracy z

Zamawiającym oraz Inżynierem Kontraktu, a w szczególności w celu przygotowania niezbędnych

dokumentów dla instytucji kontrolujących.

W celu obniżenia kosztów związanych z komunikacją pomiędzy Wykonawcą a Zamawiającym

Wykonawca zobowiązany jest dostarczyć Zamawiającemu na czas realizacji Umowy 4 aparaty telefonii

komórkowej GSM. Przekazanie aparatów telefonicznych ma nastąpić w terminie 14 dni od dnia

podpisania Umowy. Z przekazanych aparatów telefonicznych będą korzystać wyznaczone przez

Zamawiającego osoby odpowiedzialne za nadzorowanie z jego strony realizacji Projektu. Wykonawca

zobowiązany jest do pokrywania kosztów opłat abonamentowych związanych z użytkowaniem tych

aparatów telefonicznych. Opłacany przez Wykonawcę abonament ma zapewnić bezpłatne połączenia

telefoniczne z osobami wyznaczonymi przez niego do realizacji Przedmiotu Umowy. Zamawiający

zwróci przekazane aparaty telefoniczne w dniu podpisania Protokołu Odbioru Końcowego Projektu.

Zapis usunięty przez Zamawiającego.

Wykonawca zobowiązany jest przeprowadzać konsultacje z Zamawiającym w siedzibie Zamawiającego

lub wskazanym przez Zamawiającego miejscu w liczbie min. 500 godzin w całym okresie realizacji

zamówienia, nie rzadziej niż raz na tydzień. Zamawiający ma prawo w każdym momencie zażądać od

Wykonawcy przeprowadzenia konsultacji, podając termin i miejsce nie później niż 3 dni przed

planowanymi konsultacjami. Dodatkowo (poza określonym powyżej 500 godzinnym limitem) możliwe

jest prowadzenie konsultacji za pośrednictwem poczty, poczty elektronicznej, faksu, telefonu w

godzinach pracy Zamawiającego. Ze strony Wykonawcy we wszystkich konsultacjach musi brać udział

Kierownik Projektu lub z-ca Kierownika Projektu ze strony Wykonawcy, o którym mowa w §3 ust 1

Umowy (zgodnie ze wzorem stanowiącym załącznik nr 3 do SIWZ). Na prośbę Zamawiającego w

wybranych konsultacjach będą brali udział inni eksperci ze strony Wykonawcy.

III.3. Słownik pojęć

Ilekroć w Specyfikacji Istotnych Warunków Zamówienia jest mowa o:

1) Administratorze – należy przez to rozumieć pracownika wykonującego zadania związane z konfiguracją Systemu, w tym Oprogramowania aplikacyjnego, narzędziowego i systemowego w zakresie niezbędnym do prawidłowej pracy Systemu.

2) Analizie Przedwdrożeniowej – należy przez to rozumieć zakres czynności do wykonania przez Wykonawcę, mający na celu rozpoznanie i analizę środowiska biznesowego i informatycznego Zamawiającego, Uczestników Projektu (podmiotów leczniczych), w wyniku której zostanie przygotowana Dokumentacja analizy przedwdrożeniowej wraz z Harmonogramem wdrożenia Projektu.


Strona 11 z 208

3) Asyście stanowiskowej (szkoleniu) – należy przez to rozumieć konsultacje merytoryczne udzielane przez Wykonawcę dla Użytkowników Wewnętrznych w trakcie realizacji Projektu rozumiane jako przekazanie użytkownikom pełnej wiedzy niezbędnej do poprawnego użytkowania modułów, potrzebnej do wykonywania obowiązków służbowych na zajmowanym stanowisku pracy.

4) Awarii – należy przez to rozumieć: a) Wadę Oprogramowania aplikacyjnego lub narzędziowego powodującą funkcjonowanie

Oprogramowania niezgodnie z opisem SIWZ oraz Dokumentacji, która uniemożliwia pracę Systemu lub Lokalnych systemów informatycznych u Uczestników Projektu, wprowadza niespójność w bazie danych lub zaburzenia w integralności danych. Sytuacja, w której System w ogóle nie funkcjonuje lub nie jest możliwe realizowanie istotnych funkcjonalności Systemu, a w szczególności: - nie działa którakolwiek z e-Usług, - nie ma możliwości prowadzenia obsługi pacjenta w obszarze przyjęć, wypisów oraz zlecania i wykonywania badań z wykorzystaniem Oprogramowania aplikacyjnego u Uczestników Projektu, - nie ma możliwości poprawnego generowania istotnych raportów, wyciągów z Oprogramowania aplikacyjnego, - brak możliwości wymiany danych pomiędzy Systemem a którymkolwiek z Uczestników Projektu, - nie ma alternatywnego sposobu wykonania operacji w Oprogramowaniu (nie istnieje możliwość obejścia).

b) Wadę urządzenia w obszarze Infrastruktury sprzętowej, oznaczającą brak działania lub niepoprawne działanie urządzenia lub jego części w tym sterowników, uniemożliwiające jego użytkowanie.

c) Wadę urządzenia lub elementu w obszarze Infrastruktury sieciowej, oznaczające brak działania lub niepoprawne działanie urządzenia lub jego części w tym sterowników, uniemożliwiające jego użytkowanie.

5) Błędzie - należy przez to rozumieć Wadę Oprogramowania aplikacyjnego lub narzędziowego, oznaczającą jego funkcjonowanie niezgodne z opisem w Dokumentacji oraz SIWZ, powodujące błędne zapisy w bazie danych lub uniemożliwiające działanie dowolnej funkcjonalności w Systemie lub w Lokalnych systemach informatycznych u Uczestników Projektu, dla której istnieje alternatywny sposób wykonania operacji w Oprogramowaniu (istnieje możliwość obejścia) w Systemie lub w Lokalnych systemach informatycznych u Uczestników Projektu.

6) Błędzie blokującym – należy przez to rozumieć Wadę występującą wyłącznie podczas przeprowadzania testów Oprogramowania lub Nowej wersji, oznaczającą Wadę Oprogramowania aplikacyjnego lub narzędziowego niezgodną z Dokumentacją lub SIWZ, uniemożliwiającą realizację pojedynczego scenariusza testowego.

7) Błędzie Krytycznym – należy przez to rozumieć błąd Oprogramowania, dla którego nie ma alternatywnego sposobu wykonania operacji w Oprogramowaniu (nie istnieje możliwość obejścia). Zapis usunięty przez Zamawiającego.

8) Błędzie Poważnym - należy przez to rozumieć błąd Oprogramowania, dla którego istnieje alternatywny sposób wykonania operacji w Oprogramowaniu (istnieje możliwość obejścia). Zapis usunięty przez Zamawiającego.

9) Błędzie Drobnym– należy przez to rozumieć każdy inny błąd niebędący Błędem Poważnym ani Błędem Krytycznym. Zapis usunięty przez Zamawiającego.

10) Cenie – należy przez to rozumieć cenę w rozumieniu art. 3 ust. 1 pkt 1 ustawy z dnia 5 lipca 2001r. o cenach (Dz. U. Nr 97, poz. 1050 z późn.zm.).


Strona 12 z 208

11) Czasie Naprawy – należy przez to rozumieć czas, jaki może upłynąć pomiędzy pierwszym zgłoszeniem Wady, a Usunięciem Wady.

12) Czasie Reakcji Wykonawcy – należy przez to rozumieć maksymalny czas jaki może upłynąć pomiędzy pierwszym zgłoszeniem Wady a podjęciem działań przez Wykonawcę. Przez działania Wykonawcy rozumie się co najmniej:

a) dla Oprogramowania: potwierdzenie przyjęcia zgłoszenia oraz wykonanie wstępnej analizy zgłoszonej Wady, potwierdzenie klasyfikacji Wady oraz podanie przewidywanego terminu jej usunięcia.

b) dla infrastruktury sprzętowej i sieciowej: podjęcie czynności w miejscu instalacji komponentu zmierzających do usunięcia Wady.

13) Dniach Roboczych – należy przez to rozumieć dni od poniedziałku do piątku, z wyłączeniem dni ustawowo wolnych od pracy, wskazanych w ustawie z dnia 18 stycznia 1951 r o dniach wolnych od pracy (Dz. U z 1951r. Nr 4, poz. 28 z późn. zm.).

14) Dokumentacji Systemu– należy przez to rozumieć wszelką dokumentację dostarczoną przez Wykonawcę, związaną z przedmiotem Projektu i powstałą w wyniku realizacji Umowy. Dokumentacja zawiera:

Dokumentację analizy przedwdrożeniowej,

Dokumentację projektową,

Dokumentację powykonawczą,

Dokumentację szkoleniową,

Dokumentację użytkową.

15) Dokumentacji analizy przedwdrożeniowej - należy przez to rozumieć dokumentację, która powstanie w wyniku wykonanej Analizy przedwdrożeniowej,.

16) Dokumentacji projektowej – należy przez to rozumieć dokumentację wraz z późniejszymi zmianami, na podstawie której będzie budowany System i która będzie podlegała akceptacji Zamawiającego.

17) Dokumentacji powykonawczej – należy przez to rozumieć dokumenty zawierające dokładną konfigurację Systemu na moment podpisania Protokołu odbioru końcowego, w tym co najmniej:

a) Schemat architektury infrastruktury sieciowej i sprzętowej wraz z połączeniami poszczególnych ich elementów;

b) Wykaz elementów Infrastruktury sprzętowej, Infrastruktury sieciowej, Oprogramowania niezbędnego do działania Systemu, w tym również serwerów baz danych, serwerów aplikacyjnych;

c) Instrukcje instalacji wszystkich elementów Infrastruktury sprzętowej, Infrastruktury sieciowej, Oprogramowania niezbędnego do działania Systemu;

d) Wykaz zalecanych parametrów Oprogramowania niezbędnych do działania Systemu ;

e) Wykaz konfiguracji Systemu adresowany do Administratora, pozwalającej na samodzielne administrowanie Systemem przez Zamawiającego po dokonaniu jego Odbioru końcowego;

f) Inne dokumenty wytworzone w trakcie realizacji Projektu dotyczące rozwiązań technicznych i projektowych.

18) Dokumentacji szkoleniowej – należy przez to rozumieć dokumenty zawierające zestaw ćwiczeń szkoleniowych.


Strona 13 z 208

19) Dokumentacji użytkowej - należy przez to rozumieć dokumenty będące instrukcją obsługi, które w przystępny sposób pokazują jak Użytkownik wewnętrzny ma się posłużyć Oprogramowaniem aplikacyjnym, aby obsłużyć procesy jakie System może realizować. Dokumentacja użytkowa powinna zawierać: a) opis procesów biznesowych realizowanych przez System ;

b) dokładny opis funkcjonalny Modułów;

c) opis Formatek w poszczególnych Modułach wraz z opisem ich przeznaczenia;

d) opis wszystkich funkcji dostępnych na pojedynczej Formatce Modułu Oprogramowania aplikacyjnego;

e) opis poruszania się pomiędzy Formatkami poszczególnych Modułów;

f) procedury rozpoznawania przyczyn wystąpienia Wady;

g) sposób korzystania z systemu pomocy;

h) dodatkową dokumentację dotyczącą e-Usług obejmującą wsparcie dla Użytkowników końcowych, w postaci instrukcji obsługi sporządzonej w sposób przystępny i zrozumiały dla osób po raz pierwszy korzystających z Systemu .

20) Dostawach – należy przez to rozumieć nabywanie rzeczy, praw oraz innych dóbr, w szczególności na podstawie umowy sprzedaży, dostawy, najmu, dzierżawy oraz leasingu.

21) e-Usłudze – należy przez to rozumieć

a) Oprogramowanie aplikacyjne opisane w SIWZ umożliwiające pacjentom składanie przez Internet wniosków dotyczących recept o stałej, długoterminowej ordynacji, e-Rejestracji, Portalu Informacyjnym.

b) Wdrożenie systemu zarządzania i raportowania jednostek służby zdrowia na potrzeby Samorządu Województwa

22) Formatce – należy przez to rozumieć wydzieloną część Oprogramowania aplikacyjnego, narzędziowego i systemowego. Jest to element interfejsu graficznego służącego do interakcji z użytkownikiem.

23) Funkcjonalności podstawowej – należy przez to rozumieć funkcjonalność Systemu dostępną na dzień składania ofert.

24) Harmonogramie wdrożenia Projektu - szczegółowy harmonogram wdrożenia, opracowany przez Wykonawcę w ramach Analizy Przedwdrożeniowej, na podstawie Harmonogramu Rzeczowego Projektu.

25) Help Desku - należy przez to rozumieć część organizacji Wykonawcy (dział, sekcja, zespół lub wyznaczona grupa osób) odpowiedzialną za przyjmowanie Zgłoszeń od osób uprawnionych do ich dostarczania oraz kontrolę ich rozwiązania.

26) HL7 – należy przez to rozumieć (Health Level Seven), standard elektronicznej wymiany informacji w środowiskach medycznych.

27) Identyfikatorze użytkownika – należy przez to rozumieć rekord lub zespół rekordów w bazie danych pozwalających na jednoznaczną identyfikację użytkownika Systemu .

28) IK lub Inżynierze Kontraktu – należy przez to rozumieć Podmiot działający na zlecenie Zamawiającego, odpowiedzialny za nadzór nad prawidłowym wykonaniem Projektu przez Wykonawcę oraz rozliczenie Projektu.


Strona 14 z 208

29) Infrastrukturze sieciowej – należy przez to rozumieć urządzenia i elementy składające się na część aktywną i pasywną sieci komputerowej wyspecyfikowanej w SIWZ.

30) Infrastrukturze sprzętowej – należy przez to rozumieć sprzęt komputerowy wyspecyfikowany w OPZ, a w tym urządzenia takie jak: serwery, stacje robocze, urządzenia administracyjne, macierze dyskowe, urządzenia UPS,

31) Istniejącym systemie informatycznym – należy przez to rozumieć Oprogramowanie wraz z infrastrukturą sieciową i sprzętową, które obecnie funkcjonuje u Uczestnika Projektu lub Podmiotu leczniczego, wdrożone w ramach innych projektów.

32) Kierownik Projektu Wykonawcy - osoba z ramienia Wykonawcy uprawomocniona do jego reprezentowania w zakresie realizacji Umowy odpowiedzialna za jej prawidłową realizację.

33) Kierownik Projektu Zamawiającego - osoba reprezentująca Zamawiającego w zakresie realizacji Umowy, odpowiedzialna za jej prawidłową realizację.

34) Komponencie – należy przez to rozumieć integralne części dostaw, budowy i wdrożenia Systemu , który będzie podlegał odbiorowi. Komponent powinien się składać przynajmniej z jednego Produktu. Wyróżnione komponenty muszą być wspólne dla UMWL, Uczestników Projektu (podmiotów leczniczych).

35) Komitecie Sterującym – należy przez to rozumieć zespół osób składający się z przedstawicieli Zamawiającego, Wykonawcy i IK, których zadaniem jest podejmowanie kluczowych decyzji oraz nadzorowanie realizacji Projektu.

36) Licencji – należy przez to rozumieć licencję na użytkowanie Oprogramowania.

37) Licencji dostępowej (per user) – należy przez to rozumieć rodzaj licencji na użytkowanie Oprogramowania, uprawniającą do jednoczesnego korzystania z zasobów określonego Oprogramowania przez wskazaną liczbę użytkowników. Licencja może być udzielona na zasadzie „open” dla nielimitowanej liczby użytkowników.

38) Licencji stanowiskowej (per seat) – należy przez to rozumieć rodzaj licencji na użytkowanie Oprogramowania uprawniającą do korzystania z zasobów określonego Oprogramowania przez wskazaną liczbę użytkowników nazwanych.

39) Lokalnym systemie informatycznym – należy przez to rozumieć Oprogramowanie wraz z Infrastrukturą sieciową i sprzętową, które będzie funkcjonowało u Uczestnika Projektu na dzień odbioru Systemu .

40) Luce bezpieczeństwa- oznacza Wadę Oprogramowania wchodzącego w skład Systemu , która może powodować nielegalny dostęp do danych Systemu .

41) Migracji – należy przez to rozumieć przeniesienie danych z Istniejącego systemu informatycznego, funkcjonującego u Uczestnika Projektu w zakresie umożliwiającym zachowanie ciągłości kluczowych procesów biznesowych Systemu . Zapis usunięty przez Zamawiającego.

42) Module – należy przez to rozumieć wyodrębnioną część funkcjonalną Oprogramowania aplikacyjnego, opisaną w OPZ.

43) Modyfikacji – należy przez to rozumieć nowe Wymagania funkcjonalne do aktualnie zainstalowanego i użytkowanego Oprogramowania, również wynikające ze zmian przepisów prawa, wykonane przez Wykonawcę bez wezwania lub na wniosek Zamawiającego.

44) Nowej wersji – należy przez to rozumieć aktualizację Oprogramowania dostarczoną przez Wykonawcę zawierającą Poprawki lub Modyfikację.


Strona 15 z 208

45) Obsłudze - należy przez to rozumieć zgłoszenie usługi z prośbą o konsultacje w zakresie funkcjonowania Systemu lub inne zadania realizowane w ramach tej usługi nie będące zgłoszeniem Wady.

46) Odbiorze etapu - należy przez to rozumieć odbiór etapu Projektu, zgodny z Planem wdrożenia Projektu.

47) Odbiorze końcowym – należy przez to rozumieć odbiór końcowy dla Projektu zgodny z wymogami SIWZ w tym z postanowieniami Analizy Przedwdrożeniowej.

48) Odbiorze komponentu - należy przez to rozumieć odbiór komponentu, w którego skład wchodzi Produkt lub Produkty, zgodnie z przewidzianym zakresem oraz Planem wdrożenia Projektu.

49) Okresie dostępności Wykonawcy – należy przez to rozumieć przedział czasu w jakim Wykonawca jest gotowy do przyjęcia zgłoszenia Wad i Obsług.

50) Opiece – należy przez to rozumieć usługi Wykonawcy świadczone w zakresie wprowadzania Modyfikacji do Oprogramowania.

51) Oprogramowaniu – należy przez to rozumieć Oprogramowanie aplikacyjne, narzędziowe i systemowe, Oprogramowanie warstwy integracji Systemu .

52) Oprogramowaniu aplikacyjnym – należy przez to rozmieć współpracujące ze sobą oprogramowanie dostarczone przez Wykonawcę wyspecyfikowane poniżej i wdrożone w UMWL i u Uczestników Projektu, składające się z:

a) Systemu administracyjnego (ERP),

b) Systemu medycznego (HIS),

c) Centralnej aplikacji BI,

d) e-Usług.

53) Oprogramowaniu narzędziowym – należy przez to rozumieć Oprogramowanie niezbędne do prawidłowej pracy Oprogramowania aplikacyjnego, Infrastruktury sprzętowej i sieciowej.

54) Oprogramowaniu systemowym - należy przez to rozumieć oprogramowanie, w którego skład wchodzi: oprogramowanie systemów operacyjnych, oprogramowanie baz danych, oprogramowanie serwerów aplikacyjnych.

55) Oprogramowanie warstwy integracji- należy przez to rozumieć oprogramowanie niezbędne do integracji UMWL z Uczestnikami Projektu (podmiotami leczniczymi).

56) OPZ – należy przez to rozumieć „Opis przedmiotu zamówienia Systemu ” stanowiący załącznik Nr 2 do SIWZ.

57) Podmiocie leczniczym – należy przez to rozumieć podmioty lecznicze: Uczestników Projektu.

58) Poprawce – należy przez to rozumieć zmiany w kodzie Oprogramowania aplikacyjnego lub narzędziowego usuwające Wady.

59) Produkcie – należy przez to rozumieć elementarny efekt działań/prac wykonanych przez Wykonawcę podczas realizacji Projektu w ramach poszczególnych etapów określonych w Planie wdrożenia Projektu.

60) Projekcie – należy przez to rozumieć budowę i wdrożenie systemu informatycznego pn.: „Lubuskie e - Zdrowie ”.


Strona 16 z 208

61) Projekcie struktury Systemu - należy przez to rozumieć etap realizacji Projektu składający się z wykonania Analizy Przedwdrożeniowej wraz z przygotowaniem Dokumentacji analizy przedwdrożeniowej oraz przygotowania Dokumentacji projektowej.

62) Protokole odbioru komponentu – należy przez to rozumieć protokół, który po podpisaniu bez zastrzeżeń przez Zamawiającego, stanowi potwierdzenie odebrania Produktu.

63) Protokole odbioru etapu - należy przez to rozumieć protokół, który po podpisaniu bez zastrzeżeń przez Zamawiającego, stanowi potwierdzenie wykonania prac przewidzianych w ramach etapów określonych w SIWZ i uszczegółowionych w Planie wdrożenia Projektu.

64) Protokole odbioru końcowego – należy przez to rozumieć protokół, który po podpisaniu bez zastrzeżeń przez Zamawiającego, stanowi potwierdzenie wykonania i odbioru Projektu.

65) Protokole Rozbieżności – należy przez to rozumieć, protokół w którym Zamawiający wskazuje zastrzeżenia, co do zakresu i jakości wykonanych prac, które uniemożliwiają dokonanie odbioru wykonanych prac.

66) PWP - należy przez to rozumieć Plan wdrożenia Projektu - dokument zawierający informacje na temat struktury organizacyjnej zarządzania Projektem, skład Zespołu Wdrożeniowego z podziałem na role i zadania poszczególnych członków zespołu, plan komunikacji, zasady jakości, elementy sterowania Projektem i określanie ryzyk projektowych.

67) Rozwiązaniu zastępczym – należy przez to rozumieć awaryjne procedury postępowania w wykorzystaniu Systemu lub dodatkowe oprogramowanie dostarczone przez Wykonawcę, które ma za zadanie podtrzymać ciągłość działania Sytemu do czasu usunięcia Wady.

68) SIK – należy przez to rozumieć System Informowania Kierownictwa, oprogramowanie którego zadaniem jest wsparcie obszaru zarządzania i kontrolingu.

69) SIWZ – należy przez to rozumieć Specyfikację Istotnych Warunków Zamówienia.

70) Stacji roboczej – należy przez to rozumieć zestawy komputerowe klasy PC dostarczone w ramach realizacji przedmiotu zamówienia.

71) Systemie (System Lubuskie e-Zdrowie ) – należy przez to rozumieć system zbudowany w ramach projektu „Lubuskie e-Zdrowie ”, w którego skład wchodzi cała Infrastruktura sieciowa, Infrastruktura sprzętowa wraz z Oprogramowaniem aplikacyjnym, Oprogramowaniem narzędziowym i Oprogramowaniem systemowym, dostarczonym w ramach przedmiotu zamówienia.

72) Szynie usług– należy przez to rozumieć rozwiązanie umożliwiające komunikacje i wymianę danych w tym działanie e-Usług pomiędzy UMWL a Uczestnikami Projektu.

73) Uczestniku Projektu (warstwa lokalna) – należy przez to rozumieć jeden z piętnastu niżej wymienionych podmiotów leczniczych będących Uczestnikami Projektu, wymienionych w SIWZ:

a) Samodzielny Publiczny Zakład Opieki Zdrowotnej „Przychodnia Dworcowa” w Gorzowie Wielkopolskim.

b) Wojewódzki Ośrodek Medycyny Pracy w Gorzowie Wielkopolskim.

c) Samodzielna Publiczna Wojewódzka Stacja Pogotowia Ratunkowego w Gorzowie Wielkopolskim

d) Wielospecjalistyczny Szpital Wojewódzki w Gorzowie Wielkopolskim Sp. z o.o.

e) Samodzielny Publiczny Szpital dla Nerwowo i Psychicznie Chorych w Międzyrzeczu

f) Lubuski Szpital Specjalistyczny Pulmonologiczno - Kardiologiczny w Torzymiu


Strona 17 z 208

g) Wojewódzki Szpital Specjalistyczny dla Nerwowo i Psychicznie Chorych Samodzielny Publiczny Zakład Opieki Zdrowotnej w Ciborzu

h) Ośrodek dla Osób Uzależnionych Samodzielny Publiczny Zakład Opieki Zdrowotnej „Nowy Dworek”

i) Lubuski Ośrodek Rehabilitacyjno - Ortopedyczny im. dr Lecha Wierusza Samodzielny Publiczny Zakład Opieki Zdrowotnej w Świebodzinie

j) Wojewódzka Stacja Pogotowia Ratunkowego Samodzielny Publiczny Zakład Opieki Zdrowotnej w Zielonej Górze

k) Wojewódzki Ośrodek Medycyny Pracy w Zielonej Górze

l) Samodzielny Publiczny Zakład Opieki Zdrowotnej „MEDKOL” w Zielonej Górze

m) Wojewódzki Ośrodek Terapii Uzależnień i Współuzależnienia w Zielonej Górze

n) Szpital Wojewódzki Samodzielny Publiczny Zakład Opieki Zdrowotnej w Zielonej Górze

o) Samodzielny Publiczny Zakład Opieki Zdrowotnej Centrum Leczenia Dzieci i Młodzieży w Zaborze

74) Umowie – należy przez to rozumieć umowę w sprawie zamówienia publicznego pomiędzy Zamawiającym i Wykonawcą, na wykonanie przedmiotu zamówienia.

75) UMWL – należy przez to rozumieć, Zamawiającego, Województwo Lubuskie - Urząd Marszałkowski Województwa Lubuskiego.

76) Usługach – należy przez to rozumieć wszelkie świadczenia, których przedmiotem nie są roboty budowalne lub dostawy, a są usługi określone w przepisach wydanych na podstawie art. 2a u.p.z.p.

77) Usterce – należy przez to rozumieć Wadę Oprogramowania aplikacyjnego lub narzędziowego, oznaczającą jego funkcjonowanie niezgodne z opisem Dokumentacji oraz SIWZ, nie wpływającą istotnie na pracę Systemu lub lokalnych systemów informatycznych u Uczestników Projektu, utrudniającą pracę Użytkownikowi wewnętrznemu. Należy przez to rozumieć każdą inną wadę niebędącą Awarią lub Błędem.

78) Usunięciu Wady – należy przez to rozumieć dostarczenie Poprawki lub Nowej wersji lub wykonanie innych prac (w tym w zakresie Infrastruktury sprzętowej i sieciowej) przez Wykonawcę, w wyniku których nastąpi przywrócenie Systemu do stanu sprzed wystąpienia Wady wraz z usunięciem jej skutków.

79) Użytkowniku końcowym – należy przez to rozumieć osobę korzystającą on-line z e-usług.

80) Użytkowniku wewnętrznym – należy przez to rozumieć pracownika lub osobę upoważnioną przez Zamawiającego lub Uczestnika Projektu, posiadającą uprawnienia do korzystania z Oprogramowania.

81) Wadzie – należy przez to rozumieć Awarię, Błąd, Błąd blokujący, Usterkę.

82) Wdrożeniu –całokształt prac wykonanych przez Wykonawcę w celu umożliwienia samodzielnej

eksploatacji Oprogramowania przez pracowników Zamawiającego, a w szczególności czynności

takich jak: dostawa, instalacja, konfiguracja Oprogramowania, przygotowanie danych

testowych, wykonanie testów weryfikacyjnych i wydajnościowych, przygotowanie szablonów

oraz scenariuszy testowych, współudział w testach akceptacyjnych, opracowanie i dostarczenie

Dokumentacji Technicznej i użytkownika, przeprowadzenie prezentacji funkcjonalności

Systemu, szkolenie pracowników Zamawiającego oraz świadczenie usług Asysty Technicznej na


Strona 18 z 208

etapie uruchomienia Modułów Systemu celem doprowadzenia do normalnej, prawidłowej

eksploatacji Systemu.

83) Wykonawcy – należy przez to rozumieć podmiot, osobę fizyczną, osobę prawną albo jednostkę nie posiadającą osobowości prawnej, która ubiega się o udzielenie zamówienia publicznego, złożyła ofertę lub zawarła umowę w sprawie zamówienia publicznego.

84) Wymaganiu funkcjonalnym – należy przez to rozumieć wymagania dla Systemu zawarte w SIWZ wraz z Dokumentacją projektową.

85) Zadaniu – czynności opisanych w Studium Wykonalności i rozdziale 2 niniejszego OPZ

86) Zadaniu cząstkowym – czynności do wykonania w ramach Projektu dla Uczestników Projektu

87) Zamawiającym – należy przez to rozumieć Województwo Lubuskie - Urząd Marszałkowski Województwa Lubuskiego reprezentowane przez Zarząd Województwa Lubuskiego.

88) Zdarzenie - Zapytanie, Modyfikacja oraz każde nienormalne działanie Systemu, które ma negatywny wpływ na działanie Systemu, jego elementów lub funkcjonalności, tzn. sytuacja, w której zachowanie Oprogramowania albo wynik działania jest odmienny od zamierzonego określonego w Dokumentacji Użytkowej Oprogramowania, które nie jest spowodowane niezgodnym z Dokumentacją działaniem Użytkownika Końcowego. Kategorie Zdarzeń:

• Kategoria A (sytuacja awaryjna / Awaria) (Zdarzenie Krytyczne) – Zdarzenie wynikające z

przyczyn leżących po stronie Systemu lub po stronie prawidłowej obsługi i użytkowania

Systemu - powodujące całkowite zatrzymanie pracy lub niedostępność Systemu lub

jednego z Modułów, utratę danych, naruszenie ich spójności lub zdarzenie

uniemożliwiające działanie jednej z funkcji Systemu lub Modułu, tak, że dalsza praca

dowolnej części Systemu lub jednego z Modułów uniemożliwia prowadzenie bieżącej

działalności Zamawiającego przy użyciu Systemu.

Do kategorii A należą, między innymi takie zdarzenia jak:

o spadek wydajności Systemu (Wydłużenie czasu odpowiedzi Systemu powyżej 1

minuty);

o Użytkownik Końcowy nie może zapisać lub odtworzyć wyników pracy;

o System nie odpowiada na żądania Użytkownika;

o System generuje komunikat błędu;

o System pomimo posiadanych przez Użytkownika Końcowego uprawnień odmawia

dostępu, lub udostępnia zasób osobie nieuprawnionej;

o działania w Systemie nie są możliwe do zrealizowania;

o nastąpiła utrata Zasobów Informacyjnych z Systemu.

• Kategoria B – Zdarzenie wynikające z przyczyn leżących po stronie Systemu lub po stronie

prawidłowej obsługi i użytkowania Systemu - powodujące nieprawidłowe działanie

Systemu lub jednego z Modułów, ale umożliwiające jego użytkowanie. Zdarzenie

kategorii B charakteryzuje się zmniejszeniem funkcjonalności Systemu, znacząco

utrudniającym korzystanie z Systemu.

Do kategorii B należą, między innymi takie zdarzenia jak:

o spadek wydajności Systemu (Wydłużenie czasu odpowiedzi Systemu od 10 do 60

sekund)


Strona 19 z 208

o nieprawidłowe działanie Systemu, lub jego części tj. każde działanie niezgodne z

przeznaczeniem Systemu, Modułu, usługi Systemu, lub niespełnienie wymogów

stawianych Systemowi przez Zamawiającego w Dokumentacji.

o występują istotne ograniczenia w działaniu Systemu, (ale nie powodujące

przeciążenia systemu);

o nastąpiła awaria powodująca ograniczenie wydajności Systemu lub konieczność

przełączenia się na rozwiązanie zapasowe z wyłączeniem sytuacji objętych

kategorią A;

o wystąpiły błędy odczytu/zapisu danych- bez utraty danych; tzn. nieprawidłowe

wyświetlanie odczytanych danych, lub niepoprawna forma zapisania danych;

• Kategoria C – Zdarzenie wynikające z przyczyn leżących po stronie Systemu lub po stronie

prawidłowej obsługi i użytkowania Systemu lub inne niż w kategoriach A i B, w wyniku,

którego, dowolna część Systemu - oprogramowanie, platforma sprzętowa, akcesoria,

itp.; utraciła swoją funkcjonalność.

Do kategorii C należą, między innymi takie zdarzenia jak :

o spadek wydajności Systemu (Wydłużenie czasu odpowiedzi Systemu od 5 do 10

sekund);

o każdy inne Zdarzenie niebędące Zdarzeniem Kategorii A lub B. Zapis usunięty

przez Zamawiającego

89) Zespole Wdrożeniowym – należy przez to rozumieć wyznaczone osoby po stronie Wykonawcy i Zamawiającego, których zadaniem jest Wdrożenie Systemu zgodnie z zapisami Umowy, OPZ oraz Analizy Przedwdrożeniowej.

90) Zespole Zarządzania Projektem (tożsame z Komitetem Sterującym) – należy przez to rozumieć wyznaczone osoby po stronie Zamawiającego, Inżyniera Kontraktu i Wykonawcy, których zadaniem jest podejmowanie decyzji operacyjnych dotyczących realizacji Umowy.

91) Zgłoszeniu Wady – należy przez to rozumieć zdarzenie, w wyniku którego nastąpiło powiadomienie Wykonawcy o zaistniałej Wadzie.

III.4. Procedura testowania urządzeń oraz wdrożonego oprogramowania

III.4.1. Testy funkcjonalne.

1) Procedura dotyczy testów funkcjonalnych Komponentów poprzedzających Odbiór komponentu, zgodnie z Harmonogramem wdrożenia Projektu.

2) Termin i czas przeprowadzenia poszczególnych testów funkcjonalnych zostanie określony w Harmonogramie wdrożenia Projektu.

3) Przygotowania do testów funkcjonalnych: Wykonawca w terminie uzgodnionym z Zamawiającym (nie później jednak niż 20 dni roboczych przed planowany terminem rozpoczęcie testów funkcjonalnych zgodnie z Harmonogramem wdrożenia Projektu) dla poszczególnych testów funkcjonalnych przekaże do akceptacji Zamawiającemu plan i zakres testów.

a) Plan testów musi zawierać co najmniej:

proponowany czas trwania testu wraz z iteracjami, o których mowa w pkt 6,

podstawowe informacje na temat przedmiotu testów,

nazwę Komponentu, nazwę Modułu, nazwę Funkcjonalności,


Strona 20 z 208

scenariusz testów danej Funkcjonalności, wraz z informacją o konfiguracji (jeżeli jest wymagana dodatkowa), kryteria akceptacyjne.

b) Zamawiający wniesie ewentualne uwagi do przedstawionego Planu testu w ciągu 7 dni roboczych.

c) Wykonawca uwzględni uwagi Zamawiającego oraz przekaże poprawiony Plan testów w ciągu 3 dni roboczych.

d) Brak akceptacji Planu testu uniemożliwia rozpoczęcie testów funkcjonalnych danego Komponentu.

4) Zakres testów funkcjonalnych, będzie odpowiadał zakresowi realizacji prac w ramach wykonania lub dostarczenia danego Komponentu w ramach danego etapu i musi obejmować co najmniej:

a) funkcjonowanie Oprogramowania aplikacyjnego w części Oprogramowania medycznego (HIS) u Uczestników Projektu,

b) funkcjonowanie Oprogramowania aplikacyjnego w części oprogramowania administracyjnego u Uczestników Projektu,

c) kompletność, poprawność instalacji i działania Oprogramowania narzędziowego i systemowego u Uczestników Projektu i w UMWL,

d) kompletność, poprawność budowy, instalacji i działania Infrastruktury sieciowej u Uczestników Projektu i w UMWL,

e) kompletność, poprawność instalacji i działania Infrastruktury sprzętowej u Uczestników Projektu i w UMWL,

f) funkcjonowania e-Usług.

5) Przed przystąpieniem do testów funkcjonalnych Wykonawca jest zobowiązany przedstawić Dokumentację użytkową zgodną z wersją testowanego Komponentu.

6) Warunkiem rozpoczęcia testów funkcjonalnych jest przedstawienie przez Wykonawcę Raportów z testów wewnętrznych Wykonawcy potwierdzających pozytywne wyniki wszystkich przypadków testowych.

7) Iteracje testów i reakcja na Wady w trakcie wykonywania testów funkcjonalnych:

a) Pierwsza iteracja testów:

w trakcie testów Zamawiający na bieżąco zgłasza Wady.

jeżeli w trakcie testów wystąpi Błąd blokujący, zostanie on usunięty przez Wykonawcę niezwłocznie, w trakcie pierwszej iteracji testów, celem kontynuacji i zakończenia realizacji scenariusza testowego.

po zakończeniu realizacji całego scenariusza testowego, Wykonawca przekaże Zamawiającemu protokół rozbieżności, zawierający zastrzeżenia wraz z Wadami.

czas usunięcia wszystkich zastrzeżeń w tym Wad po pierwszej iteracji: do 5 dni roboczych od przekazania protokołu rozbieżności.

b) Druga iteracja testów - weryfikacja usuniętych zastrzeżeń w tym Wad zgłoszonych w pierwszej iteracji testów:



czas usunięcia wszystkich zastrzeżeń w tym Wad po drugiej iteracji: do 3 dni roboczych od przekazania protokołu rozbieżności.

c) Trzecia iteracja testów - weryfikacja usuniętych zastrzeżeń w tym Wad zgłoszonych w poprzednich iteracjach testów:



Strona 21 z 208


czas usunięcia wszystkich zastrzeżeń w tym Wad po trzeciej iteracji: do 2 dni roboczych od przekazania protokołu rozbieżności.

d) Czwarta iteracja testów - weryfikacja usuniętych zastrzeżeń w tym Wad zgłoszonych w poprzednich iteracjach testów.

8) W sytuacji, gdy pomimo dokonania iteracji testów wskazanych w pkt 7, testy nie zakończą się pomyślnie, a zastrzeżenia są istotne – uniemożliwiające prawidłowe korzystanie z Oprogramowania i/lub infrastruktury sieciowej lub sprzętowej, Zamawiający może odstąpić od realizacji umowy lub zażądać obniżenia należnego Wykonawcy wynagrodzenia.

9) Zakończenie testów funkcjonalnych z wynikiem pozytywnym umożliwia Odbiór komponentu, etapu i końcowy.

10) Wszelkie powiadomienia przez Strony, w trakcie testów funkcjonalnych, odbywać się będą w formie pisemnej z wykorzystaniem systemu zgłaszania i przyjmowania uwag i wad lub poczty elektronicznej w ramach ustalonego w Planie Wdrożenia Projektu kanału komunikacyjnego.

11) Testy Funkcjonalne zakończą się Raportem z testów funkcjonalnych, który musi być przyjęty przez Zamawiającego bez zastrzeżeń z zastrzeżeniem zapisów przedstawionych w III.4.1. pkt 8.

III.4.2. Testy integracyjne Systemu

1) Zamawiający w terminie uzgodnionym w Harmonogramie wdrożenia Projektu przeprowadzi testy integracyjne Systemu.

2) Zakres testów integracyjnych, będzie odpowiadał zakresowi realizacji prac w ramach wykonania lub dostarczenia danych Komponentów w ramach danego etapu i musi obejmować co najmniej testy warstwy integracji Systemu , w tym szyny usług i interfejsów integracji regionalnej.

3) Testy integracyjne będą przeprowadzone wraz z testami funkcjonalnymi w odniesieniu do zakresu prac w ramach wykonania danego Komponentu w ramach danego etapu.

4) Przed rozpoczęciem testów integracyjnych Wykonawca musi przedstawić do akceptacji scenariusze testów.

5) Wyniki Testu integracyjnego będą wchodzić w skład raportu testu funkcjonalnego.

III.4.3. Testy wydajnościowe Systemu

Wykonawca w terminie do 30 dni przed przystąpieniem do Odbioru końcowego, przeprowadzi testy

wydajnościowe Systemu w oparciu o poniższe zasady:

1) Wykonawca przeprowadzi testy wydajnościowe dla Lokalnych systemów informatycznych u poszczególnych Uczestników Projektu, oraz testy wydajnościowe działania e-Usług.

2) Wykonawca przeprowadzi testy na przygotowanych w miejscu wdrożenia środowiskach testowych polegające na sprawdzeniu szybkości działania zbudowanego przez Wykonawcę Systemu, w zakresie wskazanym w pkt 4 i 5.

3) Środowiska testowe będą przygotowane w oparciu o wersję oprogramowania, z którego Zamawiający oraz Uczestnicy Projektu rozpoczną korzystanie z Systemu po dokonaniu Odbioru końcowego.


Strona 22 z 208

4) W ramach testów wydajnościowych Systemu zostaną przeprowadzone co najmniej cztery grupy testów:

a) test szybkości działania warstwy bazodanowej,

b) testy działania warstwy sieciowej,

c) testy działania Oprogramowania aplikacyjnego, w tym e-Usług.

d) testy obciążeniowe, przeciążeniowe

5) Parametry środowiska testowego oraz wszystkie parametry testów wskazanych w pkt 4 zostaną uzgodnione z Wykonawcą na poziomie Analizy Przedwdrożeniowej i będą wymagane w trakcie odbiorów.

6) W Analizie Przedwdrożeniowej zostanie uzgodniony zakres testów wydajnościowych, ich harmonogram oraz kryteria oceny i zaliczenia testów.

7) Jeżeli wynik testów nie będzie spełniał określonych kryteriów, po usunięciu Wad, Wykonawca w terminie uzgodnionym z Zamawiającym, powtórzy testy wydajnościowe.

8) Aby testy mogły być przeprowadzone, Wykonawca musi przygotować rozwiązanie, które będzie mogło zasymulować sytuacje występujące w produkcyjnej pracy Systemu.

9) Testy wydajnościowe będą wykonywane przy nadzorze Inżyniera Kontraktu. Inżynier Kontraktu będzie również opiniował rezultaty testów.

10) Testy wydajnościowe będą wykonywane zgodnie z zaakceptowanymi scenariuszami testów.

11) Testy wydajnościowe zakończą się Raportem z testów wydajności, który musi być przyjęty przez Zamawiającego bez zastrzeżeń.

III.5. PROCEDURA ODBIORU SPRZĘTU ORAZ WDROŻEŃ OPROGRAMOWANIA

Procedura dotyczy odbiorów dokonywanych w ramach realizacji Projektu, określonych w Harmonogramie wdrożenia Projektu, w tym również Odbioru końcowego Projektu.

III.5.1. Odbiór komponentów

1) Odbiory Komponentów dokonywane są w terminach wskazanych w Harmonogramie wdrożenia Projektu.

2) W ramach Odbioru Komponentu, dokonuje się weryfikacji ilościowej, czy w ramach odbieranego Komponentu zostały dostarczone lub wytworzone wszystkie Produkty zgodnie z założeniami określonymi w Harmonogramie wdrożenia Projektu.

3) W ramach Odbioru Komponentu zostaną przeprowadzone odpowiednie testy funkcjonalne, opisane w Procedurze testowania urządzeń oraz wdrożonego oprogramowania.

4) Odbiór Komponentu potwierdzony jest Protokołem odbioru komponentu podpisanym bez zastrzeżeń przez Zamawiającego, IK i Wykonawcę.

5) Wykonawca przystępując do odbioru Komponentu musi przedstawić Zamawiającemu:

1) Raport z przeprowadzonych testów funkcjonalnych, przyjęty przez Zamawiającego bez zastrzeżeń,

2) Komplet Dokumentacji użytkowej dotyczącej Komponentu.


Strona 23 z 208

3) W przypadku Komponentu dotyczącego Infrastruktury sieciowej lub sprzętowej karty katalogowe dla każdego urządzenia.

6) Jeżeli Protokół Odbioru Komponentu będzie zawierał zastrzeżenia, Komponent uważa się za nieodebrany.

7) Dokonanie odbioru Komponentu, nie pozbawia Zamawiającego praw do roszczenia wobec Wykonawcy o usunięcie wad, które ujawnią się w odebranych już Komponentach, w trakcie realizacji kolejnych etapów przedmiotu Umowy, a także w okresie gwarancji.

8) Protokół Odbioru Komponentu, zostanie sporządzony w czterech jednobrzmiących egzemplarzach - dwóch dla Zamawiającego, jednym dla IK i jednym dla Wykonawcy. Protokół jest dokumentem poświadczającym prawidłowe wykonanie prac.

III.5.2. Odbiór etapu.

1) Odbiory etapów dokonywane są w terminach wskazanych w Harmonogramie wdrożenia Projektu.

2) W ramach Odbioru etapu dokonuje się weryfikacji ilościowej, czy w ramach odbieranego etapu zostały wytworzone wszystkie Komponenty, zgodnie z założeniami określonymi w Harmonogramie wdrożenia Projektu.

3) W ramach Odbioru etapu, jeżeli jest to zaplanowane, zostaną przeprowadzone odpowiednie testy funkcjonalne, opisane powyżej.

4) Wykonawca przystępując do Odbioru etapu musi przedstawić:

1) Raport z przeprowadzonych testów funkcjonalnych, przyjęty przez Zamawiającego bez zastrzeżeń (jeżeli były wykonywane w ramach Odbioru etapu),

2) Komplet Dokumentacji użytkowej (jeżeli nie był dostarczony w ramach Odbioru komponentu),

3) Wszystkie Protokoły odbiorów Komponentów wymagane w ramach Odbioru etapu,

4) Gwarancje na Komponenty wykonane i dostarczone w trakcie trwania odbieranego etapu,

5) Licencje na Komponenty wykonane i dostarczone w trakcie trwania odbieranego etapu,

5) Odbiór etapu potwierdzony jest Protokołem odbioru etapu podpisanym przez Wykonawcę, Inżyniera Kontraktu i Zamawiającego bez zastrzeżeń.

6) Jeżeli Protokół odbioru etapu będzie zawierał zastrzeżenia, etap uważa się za nieodebrany.

7) Protokół Odbioru etapu, zostanie sporządzony w czterech jednobrzmiących egzemplarzach - dwóch dla Zamawiającego, jednym dla IK i jednym dla Wykonawcy. Protokół jest dokumentem poświadczającym prawidłowe wykonanie prac i stanowi podstawę do wystawienia faktury VAT na zasadach określonych w Umowie.

8) Dokonanie Odbioru etapu, nie pozbawia Zamawiającego roszczenia wobec Wykonawcy o usunięcie wad, które ujawnią się w odebranych już Produktach i Komponentach wykonanych i dostarczonych w ramach etapu, w trakcie realizacji kolejnych etapów przedmiotu Umowy, a także w okresie gwarancji.

9) Wady Produktów i Komponentów wykonanych i dostarczonych w ramach konkretnego etapu, zdiagnozowane w etapach późniejszych, zostaną niezwłocznie (jednak nie później niż w terminie wskazanym przez Zamawiającego) usunięte przez Wykonawcę bez odrębnego wynagrodzenia. Zamawiający nie przewiduje, w związku z opisanymi w zdaniach poprzednich okolicznościami, zmiany terminów wykonywania przedmiotu Umowy, w tym kolejnych etapów.

III.5.3. Odbiór końcowy


Strona 24 z 208

1) Odbiór końcowy odbędzie się w terminie wskazanym w Harmonogramie wdrożenia Projektu.

2) W ramach Odbioru końcowego dokonuje się weryfikacji ilościowej, czy w czasie trwania Wdrożenia zostały odebrane wszystkie etapy i zostały wytworzone wszystkie Komponenty, zgodnie z założeniami określonymi w Harmonogramie wdrożenia Projektu.

3) Wykonawca przystępując do Odbioru końcowego musi przedstawić:

1) Wszystkie Protokoły odbioru etapów wymagane w ramach Odbioru końcowego,

2) Raport z testów wydajnościowych Systemu, przyjęty przez Zamawiającego bez zastrzeżeń,

3) Komplet Dokumentacji,

4) Potwierdzenie usunięcia wszystkich wad ujawnionych po Odbiorach komponentów i Odbiorach etapów,

5) Potwierdzenie wykorzystania uzgodnionych godzin w ramach Asysty stanowiskowej.

4) Odbiór końcowy potwierdzony jest Protokołem odbioru końcowego podpisanym przez Wykonawcę, Inżyniera Kontraktu i Zamawiającego bez zastrzeżeń. Protokół zostanie sporządzony w czterech jednobrzmiących egzemplarzach - dwóch dla Zamawiającego, jednym dla IK i jednym dla Wykonawcy i stanowi podstawę do wystawienia faktury VAT.

5) Jeżeli Protokół odbioru końcowego będzie zawierał zastrzeżenia, Projekt uważa się za nieodebrany.

III.6. Organizacja wdrożenia

Wdrożenie należy rozumieć jako szereg uporządkowanych i zorganizowanych działań mających na celu

wybudowanie opisanego w OPZ Systemu „Lubuskie e – Zdrowie”. Wdrożenie będzie realizowane w

ramach powołanych do tego celu struktur organizacyjnych po stronie Zamawiającego oraz

Wykonawcy.

W ramach wdrożenia zostaną przygotowane informacje na temat struktury organizacyjnej zarządzania

projektem, w tym muszą zostać powołane minimum następujące role w projekcie:

1) Kierownik Projektu ze strony Zamawiającego

2) Zastępca Kierownika Projektu ze strony Zamawiającego

3) Kierownik Projektu ze strony Wykonawcy

4) Zastępca Kierownika Projektu ze strony Wykonawcy

W ramach struktury organizacyjnej procesu wdrożenia musi zostać również powołany Komitet

Sterujący minimum w składzie:

1) Przewodniczący – przedstawiciel Zamawiającego

2) Główny Dostawca – przedstawiciel Wykonawcy

3) Główny Odbiorca – przedstawiciel Zamawiającego

Każda z tych ról ma prawo powołać swoich specjalistów dziedzinowych odpowiadających za operacyjną

realizację Projektu. Szczegółowe zadania i kompetencje Komitetu Sterującego zostaną szczegółowo

opisane w Planie Wdrożenia Projektu.


Strona 25 z 208

Wdrożenie muszą realizować osoby wymienione w ofercie Wykonawcy w Wykazie osób

zamieszczonym w ofercie:

1) Prace instalacyjne i wdrożeniowe systemu muszą być przeprowadzane przez osoby posiadające doświadczenie w zakresie produktów, których dotyczyć będzie instalacja oraz wdrożenie.

2) Osoby wykonujące prace instalacyjne i wdrożeniowe muszą być dyspozycyjne w trakcie trwania prac instalacyjnych i wdrożeniowych. Wymagany jest stały kontakt roboczy z Zamawiającym w godzinach pracy Zamawiającego.

3) Wykonawca przekaże Zamawiającemu wykaz numerów telefonów kontaktowych do osób wykonujących prace instalacyjne, wdrożeniowe i szkolenia.

4) Zamawiający wymaga, by wszelkie zastępstwa lub trwała zmiana w osobach instalujących i wdrażających zgłaszana była niezwłocznie przez Wykonawcę, z zastrzeżeniem, że osoba zastępująca musi posiadać nie mniejsze kwalifikacje niż osoba zastępowana oraz spełniać wymagania SIWZ. Zastępstwo lub trwała zmiana danej osoby wymaga akceptacji ze strony Zamawiającego.

5) Zamawiający może zażądać zmiany osoby wdrażającej.

Po dokonaniu wdrożenia docelowo system powinien spełniać wymagania określone niniejszym SIWZ oraz uwzględniać charakter prowadzonej przez Uczestników Projektu działalności, jak również spełniać wymagania obowiązujących przepisów prawa, w szczególności ustaw i rozporządzeń dotyczących:

1) Rachunkowości i sposobu liczenia kosztów u Zamawiającego,

2) Podatków,

3) Prawa Pracy

4) Ochrony danych osobowych,

5) Informatyzacji podmiotów realizujących zadania publiczne,

6) Systemu informacji w ochronie zdrowia.

Po wdrożeniu Wykonawca zapewni asystę techniczną Zamawiającemu oraz Uczestnikom Projektu

w wymiarze min. 500 roboczogodzin łącznie dla całego Projektu. Zamawiający każdorazowo przy

wykorzystaniu puli godzin asyst technicznej zwróci się do wykonawcy celem zlecenia odpowiednich

prac łącznie z wymiarem godzinowym przeznaczonym na zadanie. Asysta techniczna obejmuje

w szczególności:

1) pomoc użytkownikom w miejscu instalacji,

2) pomoc w administracji i konfiguracji systemu,

3) wykonywanie dodatkowych prac konfiguracyjnych,

4) konsultacje,

5) dodatkowe funkcjonalności systemu.

Wykonawca do 5 dnia kalendarzowego każdego miesiąca sporządzi i przekaże Zamawiającemu raport

z wykorzystania liczby godzin asysty w poprzedzającym miesiącu kalendarzowym. Raport musi

obejmować co najmniej saldo godzin asysty na pierwszy dzień miesiąca objętego raportem, zlecone

zadania wraz z liczbą godzin przeznaczoną na ich realizację oraz saldo godzin asysty na ostatni dzień

miesiąca objętego raportem. Pierwszy raport musi obejmować okres od dnia podpisania umowy do


Strona 26 z 208

końca miesiąca kalendarzowego, w którym nastąpiło podpisanie umowy. Ostatni raport (raport

końcowy) musi obejmować okres od dnia podpisania umowy do dnia, w którym nastąpił Odbiór

Końcowy przedmiotu umowy.

Zamawiający wymaga, aby dostarczony system (licencje) posiadał określone dla w SIWZ

funkcjonalności. Jeżeli w dostarczanych systemach nie jest ewidencjonowany zakres danych

niezbędnych dla wygenerowania poprawnego raportu, raport ten będzie mógł zostać wytworzony przy

udziale rozwiązania regionalnego

Proces wdrożenia dla modułów części medycznej jest rozumiany jako:

1) Instalacja

2) Konfiguracja

3) Szkolenia dla administratorów

4) Szkolenia dla użytkowników

Celem wdrożenia modułów części medycznej jest przygotowanie dostarczanego systemu do ewidencji

zdarzeń medycznych służących do rozliczenia podmiotu z NFZ. Rozwiązanie dedykowane dla

medycznej części podmiotu uznaje się za wdrożone w momencie poprawnego testowego rozliczenia

placówki z NFZ.

Proces wdrożenia dla modułów części administracyjnej jest rozumiany jako:

1) Instalacja

2) Konfiguracja

3) Szkolenia dla administratorów

4) Szkolenia dla użytkowników

Celem wdrożenia jest przygotowanie dostarczanego systemu do ewidencji zdarzeń gospodarczych

wspomagających pracę podmiotu. Rozwiązanie dedykowane dla administracyjnej części podmiotu

uznaje się za wdrożone w momencie rozliczenia kosztów za okres przynajmniej 3 miesięcy, przy czym

czas ten wlicza się do czasu wykonania przedmiotu zamówienia. Wykonawca musi uruchomić

produkcyjnie system w części administracyjnej w takim terminie, aby możliwe było rozliczenie kosztów

dla pełnych 3 miesięcy przed przystąpieniem do odbioru.

III.6.1. Przygotowanie Projektu struktury Systemu „Lubuskie e - Zdrowie”

Pierwszym zadaniem do wykonania w ramach procesu wdrożenia jest opracowanie przez Wykonawcę

w porozumieniu z Zamawiającym oraz Inżynierem Kontraktu Projektu struktury Systemu „Lubuskie e

- Zdrowie”, który zgodnie z umową składa się z następujących części:

Analizy przedwdrożeniowej

Dokumentacji Projektowej

Harmonogramu Realizacji Projektu

Harmonogramu Rzeczowo-Finansowego


Strona 27 z 208

Powyższe dokumenty stanowią bazowy zapis opisujący budowany System „Lubuskie e - Zdrowie”. Na

podstawie zapisów w tych dokumentach będą prowadzone i odbierane poszczególne zadania

realizowane przy budowie Systemu „Lubuskie e - Zdrowie”.

Dokumenty te wraz z SIWZ będę stanowiły podstawę do weryfikacji funkcjonalnej i jakościowej

Systemu „Lubuskie e - Zdrowie” w trakcie odbiorów.

III.6.2. 78Dostawa i instalacja infrastruktury sieciowej

Dostawa i instalacja infrastruktury sieciowej jest zadaniem mającym na celu modernizację sprzętu

sieciowego oraz dostawę, instalację i konfigurację aktywnego sprzętu sieciowego do wskazanych

lokalizacji według harmonogramu w porozumieniu z Zamawiającym i Uczestnikami Projektu. Zadanie

to wymaga odpowiedniego zaplanowania dostaw i prac w taki sposób, aby nie kolidowało to z bieżącą

pracą Uczestników Projektu.

Wymagania w zakresie organizacji prac instalacyjnych:

Wykonawca będzie dostarczał aktywny sprzęt sieciowy sukcesywnie w terminie bezpośrednio

poprzedzającym jego instalację i w sposób dopasowany do możliwości logistycznych

Zamawiającego i Uczestników Projektu. Zakres i wielkości dostaw należy każdorazowo

uzgodnić z Zamawiającym i Uczestnikami Projektu. Dostawy sprzętu teleinformatycznego,

Oprogramowania, Oprogramowania Narzędziowego oraz Oprogramowania Systemowego a

także usługi montażu, uruchomienia, konfiguracji, prac wdrożeniowych Systemów będą

realizowane w Dni Robocze, w terminie i godzinach uzgodnionych z Zamawiającym i

Uczestnikami Projektu. Uzgodnienie dokładnej daty i godziny dostawy musi nastąpić w formie

pisemnej co najmniej 3 dni robocze przed dostawą.

Za przechowywanie narzędzi i materiałów (w tym pasywnego i aktywnego sprzętu sieciowego)

w miejscu instalacji odpowiada Wykonawca. Wykonawca zobowiązany jest zagwarantować

przechowywanie materiałów zgodnie z wymaganiami producenta.

III.6.3. Dostawa i instalacji infrastruktury sprzętowej

Dostawa i instalacja infrastruktury sprzętowej jest zadaniem mającym na celu dostarczenie

zamawianego sprzętu do wskazanych lokalizacji według harmonogramu w porozumieniu z

Zamawiającym i Uczestnikami Projektu.

Zadanie to wymaga odpowiedniego zaplanowania dostaw i prac w taki sposób, aby nie kolidowało to

z bieżącą pracą Uczestników Projektu.

Wymagania w zakresie logistyki dostaw:

Wykonawca ma zapewnić wniesienie dostarczonego sprzętu do miejsca (pomieszczenia) u

Uczestnika Projektu lub Zamawiającego.

Wykonawca będzie dostarczał sprzęt sukcesywnie w terminie bezpośrednio poprzedzającym

jego instalację i w sposób dopasowany do możliwości logistycznych zamawiającego i

Uczestników Projektu. Zakres i wielkości dostaw należy każdorazowo uzgodnić z

Zamawiającym.


Strona 28 z 208

III.6.4. Dostawa i instalacja Oprogramowania systemowego i narzędziowego

W ramach zadania dostawy i instalacji Oprogramowania systemowego i narzędziowego Wykonawca

ma dokonać instalacji wymaganego oprogramowania systemowego i narzędziowego na dostarczonym

uprzednio sprzęcie. Dostawa i instalacja ma być wykonana we wskazanych lokalizacjach zgodnie z

Planem Wdrożenia Projektu. Dostarczane licencje muszą umożliwiać w pełni funkcjonalne

uruchomienie Oprogramowania Aplikacyjnego zgodnie ze złożoną ofertą - w szczególności dotyczy to

baz danych, systemów operacyjnych i licencji dostępowych zgodnie z przyjętym dla systemów

operacyjnych sposobem licencjonowania oraz oprogramowania narzędziowego. Po zakończeniu

instalacji, zainstalowane oprogramowanie musi zostać skonfigurowane tak aby działało poprawnie

zgodnie z jego przeznaczeniem i wymaganą architekturą rozwiązania Systemu „Lubuskie e - Zdrowie”

oraz zapewnić prawidłową pracę Oprogramowania aplikacyjnego.

III.6.5. Dostawa, instalacja i konfiguracja Oprogramowania aplikacyjnego

W ramach zadania dostawy i instalacji Oprogramowania aplikacyjnego Wykonawca ma dokonać

instalacji zamawianego oprogramowania aplikacyjnego. Dostawa i instalacja ma być wykonana we

wskazanych lokalizacjach oraz zgodnie z Planem Wdrożenia Projektu. Po zakończeniu prac

instalacyjnych oprogramowanie musi zostać skonfigurowane tak aby oferowało funkcjonalność

opisaną w SIWZ oraz zgodnie z wymaganą architekturą rozwiązania Systemu „Lubuskie e - Zdrowie”.

III.6.6. Integracja Data Center z Uczestnikami Projektu (podmiotami leczniczymi)

Zadania te polegają na integracji wskazanych jednostek ochrony zdrowia i Data Center w ramach

Systemu „Lubuskie e - Zdrowie”, zgodnie z wymaganą architekturą rozwiązania systemu „Lubuskie e -

Zdrowie” oraz określonymi elementami warstwy integracji Systemu „Lubuskie e - Zdrowie”. Głównym

celem integracji jest uruchomienie e-Usług w zakresie synchronizacji i wymiany danych pomiędzy Data

Center a systemami użytkowanymi u Uczestników Projektu oraz systemami użytkowanymi przez

Podmioty lecznicze.

III.6.7. Szkolenia

III.6.7.1. Zakres ramowy szkoleń


Strona 29 z 208

Uczestnik Projektu

Wo

jew

ód

ztw

o L

ub

usk

ie, U

rząd

Mar

szał

kow

ski W

oje

wó

dzt

wa

Lub

usk

iego

w Z

ielo

nej

Gó

rze,

65

-05

7 Z

ielo

na

Gó

ra, u

l. P

od

górn

a 7

SPZO

Z „P

rzyc

ho

dn

ia D

wo

rco

wa”

w G

orz

ow

ie W

ielk

op

ols

kim

, 66

-40

0 G

orz

ów

Wlk

p.,

ul.

Dw

orc

ow

a 1

3

Wo

jew

ód

zki O

śro

dek

Med

ycyn

y P

racy

, 66

-40

0 G

orz

ów

Wlk

p.,

ul.

Fab

rycz

na

71

Sam

od

ziel

na

Pu

blic

zna

Wo

jew

ód

zka

Stac

ja P

ogo

tow

ia R

atu

nko

weg

o, 6

6-4

00

Go

rzó

w W

lkp

., u

l. K

azim

ierz

a

Wie

lkie

go 7

Wie

losp

ecja

listy

czn

y Sz

pit

al W

oje

wó

dzk

i w G

orz

ow

ie W

lkp

. Sp

. z o

.o.,

66

-40

0 G

orz

ów

Wlk

p.,

ul.

Wal

czak

a

42

Sa

mo

dzi

eln

y P

ub

liczn

y Sz

pit

al d

la N

erw

ow

o i

Psy

chic

znie

Ch

ory

ch, 6

6-3

00

Mię

dzy

rzec

z, u

l. P

ozn

ańsk

a 1

09

Lub

usk

i Szp

ital

Sp

ecja

listy

czn

y P

ulm

on

olo

gicz

no

- K

ard

iolo

gicz

ny

Sam

od

ziel

ny

Pu

blic

zny

Zakł

ad O

pie

ki

Zdro

wo

tnej

, 66

-23

5 T

orz

ym, u

l. W

ojs

ka P

ols

kieg

o 5

2

Wo

jew

ód

zki S

zpit

al S

pec

jalis

tycz

ny

dla

Ner

wo

wo

i P

sych

iczn

ie C

ho

rych

Sam

od

ziel

ny

Pu

blic

zny

Zakł

ad

Op

ieki

Zd

row

otn

ej, 6

6-2

13

Cib

órz

5

Ośr

od

ek d

la O

sób

Uza

leżn

ion

ych

Sam

od

ziel

ny

Pu

blic

zny

Zakł

ad O

pie

ki Z

dro

wo

tnej

„N

ow

y D

wo

rek”

, 66

-

20

0 N

ow

y D

wo

rek

46

;

Lub

usk

i Ośr

od

ek R

ehab

ilita

cyjn

o -

Ort

op

edyc

zny

im. d

r Le

cha

Wie

rusz

a SP

ZOZ,

66

-20

0 Ś

wie

bo

dzi

n, u

l.

Zam

kow

a 1

Wo

jew

ód

zka

Stac

ja P

ogo

tow

ia R

atu

nko

weg

o S

amo

dzi

eln

y P

ub

liczn

y Za

kład

Op

ieki

Zd

row

otn

ej, 6

5-0

43

Ziel

on

a G

óra

, ul.

B. C

hro

bre

go 2

Wo

jew

ód

zki O

śro

dek

Med

ycyn

y P

racy

, 65

-09

6 Z

ielo

na

Gó

ra, u

l. D

ąbró

wki

15

C

SP Z

OZ

„M

EDK

OL”

, 65

-02

0 Z

ielo

na

Gó

ra, u

l. P

lac

Ko

leja

rza

1

Wo

jew

ód

zki O

śro

dek

Ter

apii

Uza

leżn

ień

i W

spó

łuza

leżn

ien

ia, 6

5-0

44

Zie

lon

a G

óra

, ul.

Waz

ów

36

Szp

ital

Wo

jew

ód

zki S

PZO

Z w

Zie

lon

ej G

órz

e, 6

5-0

46

Zie

lon

a G

óra

, ul.

Zyty

26

SP Z

OZ

Cen

tru

m L

ecze

nia

Dzi

eci i

Mło

dzi

eży

w Z

abo

rze,

66

-00

3 Z

abó

r, u

l. Za

mko

wa

1

Raz

em

Użytkownicy systemu HIS 53 29 40 51 74 247

Użytkownicy systemu ERP 10 11 27 8 8 4 6 74

Użytkownicy systemu raportowego 10 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 40

Administratorzy systemu HIS/ERP 2 1 1 1 1 1 1 1 1 10

Administratorzy systemu raportowego 1 1

Użytkownicy portalu umożliwiającego elektroniczne wysłanie wniosku do jednostek ochrony zdrowia o powtórzenie recepty w przypadkach chorób przewlekłych oraz portalu informacyjnego

1 2 2 2 2 2 2 2 2 2 3 2 24

Administratorzy portalu umożliwiającego elektroniczne wysłanie wniosku do jednostek ochrony zdrowia o powtórzenie recepty w przypadkach chorób przewlekłych oraz portalu informacyjnego

2 1 1 1 1 1 1 1 1 1 2 1 14

III.6.7.2. Wymagania ogólne

III.6.7.2.1. Na potrzeby szkoleń Wykonawca uruchomi bazy testowe systemów u Uczestników

Projektu tak, by umożliwić użytkownikom testowanie funkcjonalności modułów.


Strona 30 z 208

III.6.7.2.2. Szkolenia z użytkowania systemów muszą odbywać się w środowisku testowym na

wersji, której funkcjonalności nie różnią się w znaczący sposób od wersji

produkcyjnej. Dopuszczalne jest wykorzystanie tej samej instalacji produkcyjnej

oprogramowania aplikacyjnego przy zachowaniu odrębnej instancji bazy danych

(baza testowa) dla potrzeb szkoleń.

III.6.7.2.3. Szkolenie należy przeprowadzać w grupach szkoleniowych dla minimalnej liczby osób

zgodnie z wykazem zamieszczonym w punkcie III.6.7.1.

III.6.7.2.4. Grupy szkoleniowe należy tworzyć dla każdego Uczestnika Projektu.

III.6.7.2.5. Dopuszcza się stosowanie szkoleń indywidualnych, pod warunkiem sporządzenia

protokołu z realizacji takiego szkolenia podpisanego przez Uczestnika szkolenia.

III.6.7.2.6. Dopuszcza się łączenie grup szkoleniowych w szczególnych przypadkach (np.

sąsiadujące lokalizacje) pod warunkiem uzyskania pisemnej zgody Zamawiającego.

III.6.7.2.7. Wymaga się, aby szkolenia przeprowadzały:

dla grup szkoleniowych liczących do 10 osób – min. 1 osoba szkoląca,

dla grup szkoleniowych liczących do 20 osób – min. 2 osoby szkolące.

III.6.7.2.8. Każde szkolenie grupowe winno zakończyć się testem sprawdzającym wiedzę

szkolonego personelu uzyskaną podczas szkolenia oraz podpisaniem protokołu z

realizacji szkolenia zawierającym: czas trwania szkolenia, jego zakres merytoryczny,

wyniki testu końcowego, wykaz Uczestników. Protokół winien być podpisany przez

wszystkie osoby szkolące i uczestniczące w szkoleniu.

III.6.7.2.9. Po zakończeniu wszystkich szkoleń należy sporządzić i przekazać Zamawiającemu

raport zawierający co najmniej:

wykaz szkoleń obejmujący co najmniej:

o datę szkolenia

o miejsce

o czas trwania szkolenia

o zakres szkolenia

o liczbę Uczestników

o oznaczenie osób szkolących

o średni wynik testu z danego szkolenia

dokumenty potwierdzające zakończenie cyklu szkoleń u każdego Uczestnika

Projektu

ankieta satysfakcji

podsumowanie.

III.6.7.3. Szkolenia użytkowników systemu HIS – szkolenie podstawowe

III.6.7.3.1. Szkolenie podstawowe musi objąć wszystkich użytkowników przewidzianych do

szkolenia w tym zakresie zgodnie z wykazem przedstawionym w punkcie III.6.7.1.

III.6.7.3.2. Liczebność grupy szkoleniowej – maks. 20 osób.

III.6.7.3.3. Łączny czas szkolenia jednej grupy – min. 20 godzin.

III.6.7.3.4. Forma szkolenia – wykłady i warsztaty


Strona 31 z 208

III.6.7.3.5. Zakres szkolenia – wiedza na temat obsługi systemu HIS zgodnie z zakresem

wdrożenia.

III.6.7.4. Szkolenia użytkowników systemu HIS – szkolenie dodatkowe

III.6.7.4.1. Szkolenie dodatkowe musi objąć osoby, które w wyniku testu po zakończeniu

szkolenia podstawowego uzyskały mniej niż 75% punktów oraz osoby, które

samodzielnie zgłoszą potrzebę szkolenia dodatkowego.

III.6.7.4.2. Liczebność grupy szkoleniowej – maks. 5 osób lub szkolenia indywidualne.

III.6.7.4.3. Łączny czas szkolenia dla całego wdrożenia (wszystkich Uczestników Projektu) – min.

400 godzin.

III.6.7.4.4. Forma szkolenia – trening na stanowisku pracy.

III.6.7.4.5. Zakres, wymiar i termin szkolenia – ustalany indywidualnie z użytkownikami po

zakończeniu szkolenia podstawowego.

III.6.7.5. Szkolenia użytkowników systemu ERP – szkolenie podstawowe

III.6.7.5.1. Szkolenie podstawowe musi objąć wszystkich użytkowników przewidzianych do

szkolenia w tym zakresie zgodnie z wykazem przedstawionym w punkcie III.6.7.1.



III.6.7.5.4. Forma szkolenia – wykłady i warsztaty

III.6.7.5.5. Zakres szkolenia – wiedza na temat obsługi systemu ERP zgodnie z zakresem

wdrożenia.

III.6.7.6. Szkolenia użytkowników systemu ERP – szkolenie dodatkowe

III.6.7.6.1. Szkolenie dodatkowe musi objąć osoby, które w wyniku testu po zakończeniu

szkolenia podstawowego uzyskały mniej niż 75% punktów oraz osoby, które

samodzielnie zgłoszą potrzebę szkolenia dodatkowego.

III.6.7.6.2. Liczebność grupy szkoleniowej – maks. 5 osób lub szkolenia indywidualne.

III.6.7.6.3. Łączny czas szkolenia dla całego wdrożenia (wszystkich Uczestników Projektu) – min.

200 godzin.


III.6.7.6.5. Zakres, wymiar i termin szkolenia – ustalany indywidualnie z użytkownikami po

zakończeniu szkolenia podstawowego.

III.6.7.7. Szkolenia użytkowników systemu raportowego

III.6.7.7.1. Szkolenie musi objąć wszystkich użytkowników przewidzianych do szkolenia w tym

zakresie zgodnie z wykazem przedstawionym w punkcie III.6.7.1.



III.6.7.7.4. Forma szkolenia – warsztaty.

III.6.7.7.5. Zakres szkolenia – wiedza na temat obsługi systemu raportowego zgodnie z zakresem

wdrożenia.


Strona 32 z 208

III.6.7.8. Szkolenia administratorów systemu HIS/ERP

III.6.7.8.1. Szkolenie musi objąć wszystkich administratorów przewidzianych do szkolenia w tym


III.6.7.8.2. Szkolenie indywidualne, minimalny czas szkolenia 20 godzin na osobę.


III.6.7.8.4. Zakres szkolenia:

administrowanie wdrożoną bazą danych,

administrowanie wdrożonymi modułami oprogramowania aplikacyjnego,

eksploatacja wdrożonych modułów oprogramowania aplikacyjnego,

rozwiązywanie typowych problemów.

III.6.7.9. Szkolenia administratorów systemu raportowego

III.6.7.9.1. Szkolenie musi objąć wszystkich administratorów przewidzianych do szkolenia w tym


III.6.7.9.2. Szkolenie indywidualne, minimalny czas szkolenia 20 godzin na osobę.


III.6.7.9.4. Zakres szkolenia:

administrowanie bazą danych systemu BI,

administrowanie serwerem raportowym,

zarządzanie modelem danych,

obsługa systemu raportowego w tym konfiguracja i tworzenie raportów,

rozwiązywanie typowych problemów.

III.6.7.10. Użytkownicy portalu e-rejestracji i umożliwiającego elektroniczne wysłanie wniosku do

jednostek ochrony zdrowia o powtórzenie recepty w przypadkach chorób przewlekłych

oraz portalu informacyjnego






III.6.7.10.5. Zakres szkolenia – wiedza na temat obsługi portalu zgodnie z zakresem wdrożenia.

III.6.7.11. Administratorzy portalu umożliwiającego elektroniczne wysłanie wniosku do jednostek

ochrony zdrowia o powtórzenie recepty w przypadkach chorób przewlekłych oraz

portalu informacyjnego






III.6.7.11.5. Zakres szkolenia – wiedza na temat obsługi portalu zgodnie z zakresem wdrożenia.


Strona 33 z 208

III.6.7.12. Harmonogram szkoleń określający co najmniej zakres szkoleń dla każdego spotkania,

grupy szkoleniowe, szkoleniowców oraz dokumentacja szkoleniowa musi być

elementem Harmonogramu wdrożenia Projektu.

III.6.8. Testy

W ramach tego zadania zostaną przeprowadzone wszystkie testy opisane w SIWZ. Celem

przeprowadzenia testów jest weryfikacja przez Zamawiającego, czy wszystkie prace wykonane w

trakcie budowania Systemu „Lubuskie e - Zdrowie” zostały wykonane prawidłowo i zgodnie z

założeniami funkcjonalnymi i jakościowymi. Testy będą przeprowadzane zarówno przez wyznaczonych

pracowników Uczestników Projektów jak i wskazanych przez Zamawiającego osób i podmiotów

zewnętrznych.

Pozytywne zakończenie testów wraz z usunięciem wskazanych Wad jest niezbędne aby dla

poszczególnych komponentów oraz Systemu „Lubuskie e - Zdrowie” dokonać odbiorów w ramach

poszczególnych etapów oraz odbioru końcowego.

III.6.9. Promocja

W ramach realizacji czynności montażu wraz z uruchomieniem sprzętu komputerowego (urządzeń

teleinformatycznych) wyspecyfikowanego w Zadaniach Cząstkowych Wykonawca zobowiązany jest do

oznakowania dostarczonego sprzętu komputerowego naklejkami wykonanymi zgodnie z „Wytycznymi

Instytucji Zarządzającej Lubuskim Regionalnym Programem Operacyjnym w zakresie informacji i

promocji dla beneficjentów”, dostępnymi pod adresem

http://www.lrpo.lubuskie.pl/index.php?option=com_content&view=article&id=871:zmiana-

wytycznych-instytucji-zarzdzajcej-lubuskim-regionalnym-programem-operacyjnym-w-zakresie-

informacji-i-promocji-dla-beneficjentow-&catid=54:dokumenty-regionalne&Itemid=120 .

III.6.10. Odbiór końcowy

Zadanie to ma na celu potwierdzenie wykonania wszystkich zadań wynikających z Projektu, w tym

odebrania wszystkich Komponentów i etapów Projektu oraz dostarczenia wszystkich wymaganych w

zamówieniu dokumentów. Dokonanie odbioru końcowego zakończy prace przy budowie Systemu

„Lubuskie e - Zdrowie” i będzie podstawą do przekazania Systemu „Lubuskie e - Zdrowie” do

użytkowania produkcyjnego.

http://www.lrpo.lubuskie.pl/index.php?option=com_content&view=article&id=871:zmiana-wytycznych-instytucji-zarzdzajcej-lubuskim-regionalnym-programem-operacyjnym-w-zakresie-informacji-i-promocji-dla-beneficjentow-&catid=54:dokumenty-regionalne&Itemid=120




Strona 34 z 208

IV. Miejsce realizacji dostaw i usług

Dostawy i usługi będą realizowane pod niżej wskazanymi adresami w zakresach określonych w

poszczególnych zadaniach cząstkowych.

Uczestnik Projektu Adres

Samodzielny Publiczny Zakład Opieki Zdrowotnej „Przychodnia Dworcowa” w Gorzowie Wielkopolskim

66-400 Gorzów Wlkp., ul. Dworcowa 13

Wojewódzki Ośrodek Medycyny Pracy w Gorzowie Wielkopolskim

66-400 Gorzów Wlkp., ul. Fabryczna 71

Samodzielna Publiczna Wojewódzka Stacja Pogotowia Ratunkowego w Gorzowie Wielkopolskim

66-400 Gorzów Wlkp., ul. Kazimierza Wielkiego 7

Wielospecjalistyczny Szpital Wojewódzki w Gorzowie Wielkopolskim Sp. z o.o.

66-400 Gorzów Wlkp., ul. Walczaka 42

Samodzielny Publiczny Szpital dla Nerwowo i Psychicznie Chorych w Międzyrzeczu

66-300 Międzyrzecz, ul. Poznańska 109

Wojewódzki Szpital Specjalistyczny dla Nerwowo i Psychicznie Chorych Samodzielny Publiczny Zakład

Opieki Zdrowotnej w Ciborzu 66-213 Cibórz 5

Ośrodek dla Osób Uzależnionych Samodzielny Publiczny Zakład Opieki Zdrowotnej "Nowy Dworek"

66-200 Nowy Dworek 46

Lubuski Ośrodek Rehabilitacyjno - Ortopedyczny im. dr Lecha Wierusza w Świebodzinie Samodzielny

Publiczny Zakład Opieki Zdrowotnej w Świebodzinie 66-200 Świebodzin, ul. Zamkowa 1

Wojewódzka Stacja Pogotowia Ratunkowego Samodzielny Publiczny Zakład Opieki Zdrowotnej w

Zielonej Górze 65-043 Zielona Góra, ul. B. Chrobrego 2

Wojewódzki Ośrodek Medycyny Pracy w Zielonej Górze

65-096 Zielona Góra, ul. Dąbrówki 15C

Samodzielny Publiczny Zakład Opieki Zdrowotnej "MEDKOL" w Zielonej Górze

65-020 Zielona Góra, ul. Plac Kolejarza 1

Wojewódzki Ośrodek Terapii Uzależnień i Współuzależnienia w Zielonej Górze

65-044 Zielona Góra, ul. Wazów 36

Szpital Wojewódzki Samodzielny Publiczny Zakład Opieki Zdrowotnej im. Karola Marcinkowskiego w

Zielonej Górze 65-046 Zielona Góra, ul. Zyty 26

Samodzielny Publiczny Zakład Opieki Zdrowotnej Centrum Leczenia Dzieci i Młodzieży w Zaborze

66-003 Zabór, ul. Zamkowa 1

Lubuski Szpital Specjalistyczny Pulmonologiczno - Kardiologiczny Niepubliczny Zakład Opieki Zdrowotnej

w Torzymiu 66-235 Torzym, ul. Wojska Polskiego 52


Strona 35 z 208

Uczestnik Projektu Adres

Województwo Lubuskie Urząd Marszałkowski Województwa Lubuskiego w Zielonej Górze

65-057 Zielona Góra, ul. Podgórna 7

V. Termin wykonania zamówienia - harmonogram

Przedmiot umowy musi być zrealizowany w terminie zgodnym ze złożoną przez Wykonawcę ofertą.

Przedmiot umowy będzie realizowany zgodnie z zatwierdzonym przez Zamawiającego

Harmonogramem wdrożenia Projektu. Wykonawca zobowiązany jest przedłożyć Zamawiającemu do

zatwierdzenia Harmonogram wdrożenia Projektu w terminie 14 dni roboczych od dnia podpisania

umowy. Zamawiający zatwierdzi Harmonogram wdrożenia Projektu w ciągu 5 dni roboczych od daty

jego przedłożenia do zatwierdzenia. Na wniosek każdej ze stron po uzyskaniu wzajemnej akceptacji

Harmonogram może ulec zmianie pod warunkiem, że terminy końcowe realizacji poszczególnych

zadań przedmiotu zamówienia przedstawione w tabeli nr 1 nie ulegną zmianie.

Wykonawca zobowiązany jest przedłożyć Zamawiającemu do zatwierdzenia Harmonogram Rzeczowo-

Finansowy w terminie 30 dni od dnia podpisania umowy. Zamawiający zatwierdzi Harmonogram

Rzeczowo-Finansowy w ciągu 3 dni roboczych od daty jego przedłożenia do zatwierdzenia.

Tabela 1 – Terminy końcowe realizacji zadań przedmiotu zamówienia

Lp. Produkt Projektu Termin

1. Zadanie I - Wykonanie portalu informacyjnego z wdrożeniem

usługi elektronicznego wysłania wniosku do jednostek ochrony

zdrowia o powtórzenie recepty w przypadkach chorób

przewlekłych

Zgodnie z ofertą

2. Zadanie II - Wdrożenie systemu zarządzania i raportowania

jednostek służby zdrowia na potrzeby Samorządu

Województwa

Zgodnie z ofertą

3. Zadanie III - Dostawa infrastruktury technicznej niezbędnej dla

realizacji projektu

Do 3 miesięcy od

daty podpisania

umowy


Strona 36 z 208

VI. Szczegółowy opis przedmiotu zamówienia

VI.1. Zadanie I: Elektroniczne wysłanie wniosku do jednostek ochrony

zdrowia o powtórzenie recepty w przypadkach chorób przewlekłych

oraz portal informacyjny

VI.1.1. Opis ogólny usługi

W ramach rozwiązania będą realizowane następujące e-Usługi:

Portal Informacyjny - udostępnia pacjentom informacje o podmiotach leczniczych

uczestniczących w projekcie oraz usługach medycznych realizowanych przez te podmioty

eRejestracja - umożliwia pacjentom elektroniczną rejestrację na usługi medyczne

udostępnione w tym celu przez podmioty lecznicze uczestniczące w projekcie; e-Usługa jest

zależna od Portalu Informacyjnego, który dostarcza niezbędnych informacji o usługach

medycznych, które podlegają elektronicznej rejestracji oraz udostępnia informację o

dokonanych elektronicznych rejestracjach

eRecepta - umożliwia odnotowanie (w ramach planowanej wizyty) pacjentowi chęci pobrania

recepty na leki odnawialne; e-usługa jest ściśle powiązana z elektroniczną usługą

eRejestracja.

Rozwiązanie musi zapewnić realizację powyższych elektronicznych usług. W tym celu zostanie

udostępniony portal WWW. W ramach tego portalu będą udostępniane dane o poszczególnych

podmiotach leczniczych (PP), usługach medycznych realizowanych przez te podmioty, personelu i

komórkach organizacyjnych realizujących te usługi. Dane tę będą pochodziły z podmiotów leczniczych

i będą przekazywane do warstwy regionalnej za pomocą interfejsu wymiany danych. Dla podmiotów

leczniczych, które chcą się zintegrować, ale nie będą mogły uruchomić ww. interfejsu wymiany danych

zostanie udostępnione dodatkowe rozwiązanie umożliwiające wprowadzenie niezbędnych danych za

pomocą aplikacji dostępnej z przeglądarki internetowej.

W celu uwiarygodnienia osób rejestrujących się na usługi medyczne będzie wymagane założenie konta

w Portalu Informacyjnym. Pacjenci posiadający takie konto będą mogli dokonywać elektronicznych

rejestracji, przeglądać historię swoich rejestracji oraz anulować zaplanowane rejestracje. Posiadający

konto będą zarazem opiekunami prawnymi będą mogli zakładać subkonta dla osób im podlegających.

Rozwiązanie umożliwi wykonywanie elektronicznej rejestracji na usługi medyczne w trybie on-line. W

tym celu podmioty lecznicze będą udostępniały swoje terminarze, które poprzez interfejs wymiany

danych będę dostępne dla e-usługi eRejestracja i eRecepta. Dla podmiotów, które nie będą mogły

uruchomić interfejsy wymiany danych udostępnione dodatkowe rozwiązanie umożliwiające

definiowanie i prowadzenie terminarzy w warstwie regionalnej tak, aby była możliwa elektroniczna

rejestracja na usługi realizowane przez te podmioty (w tym celu udostępnione do warstwy

regionalnej).


Strona 37 z 208

VI.1.2. Wymagania

VI.1.2.1. Wymagania ogólne

Nr wymagania

Wymaganie

EU.WO Wymagania ogólne

EU.WO.1 e-Usługi realizowane są w postaci portalu WWW

EU.WO.2 System do komunikacji pomiędzy jednostkami a centrum regionalnym musi wykorzystywać sieć Internet

EU.WO.3 Interfejs użytkownika jest dostępny z poziomu przeglądarki internetowej

EU.WO.4 System musi umożliwić pracę z poziomu najbardziej popularnych przeglądarek, co najmniej MS Internet Explorer, Mozilla Firefox, Google Chrome w wersjach aktualnych na dzień składania ofert

EU.WO.5 Komunikacja pomiędzy użytkownikiem a systemem odbywa się w języku polskim

EU.WO.6 e-Usługi Portal Informacyjny, eRejestracja oraz eRecepta są dostępne w ramach tego samego portalu WWW

EU.WO.7 System w zakresie e-Usług Portal Informacyjny, eRejestracja, eRecepta posiada jednolity interfejs użytkownika, w tym nagłówki i stopki

EU.WO.8 Funkcjonalności administracyjne i wspierające funkcjonowanie e-Usług dedykowane dla administratorów lub użytkowników wewnętrznych będących pracowników podmiotów leczniczych są udostępniane w sieci intranet.

EU.WO.9 Na formatkach wymagających edycji danych system musi prezentować użytkownikowi informację, które z danych są wymagane do wypełnienia

EU.WO.10 System musi weryfikować kompletności wypełnienia wymaganych danych, a w przypadku braku wypełnienia musi prezentować informację zwrotną z zaznaczeniem danych nie wypełnionych

EU.WO.11 System udostępnia użytkownikom system pomocy w języku polskim

EU.WO.12 Treść systemu pomocy jest kontekstowa do formatki, z której został on wywołany

EU.WO.13 e-Usługi Portal Informacyjny, eRejestracja oraz eRecepta są dostępne w wersji mobilnej portalu

EU.WO.14 System musi być gotowy do współpracy z serwerem pocztowym w celu wysyłania powiadomień email

EU.WO.15 System musi być gotowy do współpracy z bramką SMS w celu wysyłania powiadomień SMS

EU.WO.16 System musi być zintegrowany z ePUAP i zapewniać autoryzację użytkowników z wykorzystaniem Profilu Zaufanego.

VI.1.2.2. Portal informacyjny

Nr wymagania

Wymaganie

EU.PI Portal Informacyjny

EU.PI.1 System musi udostępniać pacjentom, bez konieczności logowania, następujące treści:

EU.PI.1.1 - aktualności

EU.PI.1.2 - informacje o projekcie

EU.PI.1.3 - ważne linki

EU.PI.1.4 - pliki do pobrania

EU.PI.1.5 - regulamin portalu

EU.PI.1.6 - informacje o podmiotach leczniczych zintegrowanych z centrum regionalnym oraz usługach medycznych realizowanych przez te podmioty

EU.PI.1.7 - informacje o usługach medycznych realizowanych przez podmioty lecznicze zintegrowane z centrum regionalnym

EU.PI.1.8 - informacje o komórkach organizacyjnych podmiotów leczniczych zintegrowanych z centrum regionalnym, w których realizowane są te usługi medyczne

EU.PI.1.9 - informacje o personelu medycznym wykonującym te usługi medyczne

EU.PI.1.10 - wyszukiwarkę usług medycznych

EU.PI.1.11 - informator o usługach medycznych dostępnych w podmiotach leczniczych zintegrowanych z centrum regionalnym

EU.PI.2 System musi umożliwiać pacjentom zapisywanie się na newsletter

EU.PI.3 System musi umożliwiać pacjentom wypisywanie się z newslettera

EU.PI.4 System musi udostępniać kanał RSS


Strona 38 z 208

Nr wymagania

Wymaganie

EU.PI.5 System musi umożliwiać pacjentom przeglądanie informacji o każdym z podmiotów leczniczych (zintegrowanych z centrum regionalnym) w zakresie:

EU.PI.5.1 - danych podstawowych

EU.PI.5.2 - realizowanych usług medycznych

EU.PI.5.3 - komórek organizacyjnych realizujących te usługi

EU.PI.5.4 - personelu medycznym realizującym te usługi

EU.PI.6 System musi umożliwiać przeglądanie katalogu podmiotów leczniczych zintegrowanych z centrum regionalnym

EU.PI.7 System musi prezentować następujące dane podstawowe o podmiocie leczniczym zintegrowanym z centrum regionalnym:

EU.PI.7.1 - nazwa

EU.PI.7.2 - adres siedziby – ulica

EU.PI.7.3 - adres siedziby - nr budynku

EU.PI.7.4 - adres siedziby - nr lokalu

EU.PI.7.5 - adres siedziby - miejscowość

EU.PI.7.6 - adres siedziby - kod pocztowy

EU.PI.7.7 - adres siedziby – poczta

EU.PI.7.8 - REGON

EU.PI.7.9 - telefon kontaktowy

EU.PI.7.10 - e-mail kontaktowy

EU.PI.7.11 - adres strony WWW

EU.PI.7.12 - opis podmiotu leczniczego

EU.PI.8 System musi umożliwiać wyszukiwanie podmiotów leczniczych w katalogu podmiotów leczniczych co najmniej wg następujących kryteriów:

EU.PI.8.1 - nazwa

EU.PI.8.2 - adres siedziby - miejscowość

EU.PI.8.3 - adres siedziby – ulica

EU.PI.8.4 - REGON

EU.PI.8.5 - adres strony www

EU.PI.8.6 - fragment opisu podmiotu leczniczego

EU.PI.8 System musi umożliwiać przeglądanie katalogu usług medycznych realizowanych przez podmioty lecznicze i udostępnionych w tym celu do centrum regionalnego

EU.PI.9 System musi prezentować następujące dane o każdej usłudze medycznej realizowanej przez podmiot leczniczy:

EU.PI.9.1 - nazwa usługi

EU.PI.9.2 - opis usługi

EU.PI.9.3 - warunki wykonania usługi

EU.PI.9 - rodzaj usługi rozumiany jako zestaw następujących cech opisujących usługę medyczną: a) jednostka statystyczna świadczenia - dana wymagana, b) specjalność komórki organizacyjnej realizującej usługę - dana wymagana, c) zakres - dana opcjonalna; zawartość słownika zakresu musi zostać ustalona z zamawiającym na etapie analizy przedwdrożeniowej)

EU.PI.9.1 - czy wymagane skierowanie od lekarza?

EU.PI.9.2 - czy usługa jest dostępna do elektronicznej rejestracji w ramach e-Usługi eRejestracja

EU.PI.9.3 - podmiot leczniczy, w którym usługa jest realizowana

EU.PI.10 System musi umożliwiać wyszukiwanie usług medycznych w katalogu usług medycznych wg następujących kryteriów (co najmniej):

EU.PI.10.1 - podmiot leczniczy, w którym usługa jest realizowana

EU.PI.10.2 - rodzaj usługi

EU.PI.10.3 - fragment nazwy usługi medycznej

EU.PI.11 System musi umożliwiać przeglądanie katalogu komórek organizacyjnych, w których realizowane są (udostępnione w tym celu do Portalu Informacyjnego) usługi medyczne realizowane przez podmioty lecznicze zintegrowane z centrum regionalnym

EU.PI.12 System musi prezentować następujące dane o komórce organizacyjnej podmiotu leczniczego realizującej usługi medyczne

EU.PI.12.1 - kod komórki organizacyjnej - cz. VII kodu resortowego

EU.PI.12.2 - nazwa komórki organizacyjnej

EU.PI.12.3 - kod specjalności komórki organizacyjnej - cz. VIII kodu resortowego

EU.PI.12.4 - specjalność komórki organizacyjnej


Strona 39 z 208

Nr wymagania

Wymaganie

EU.PI.12.5 - adres komórki organizacyjnej - miejscowość

EU.PI.12.6 - adres komórki organizacyjnej - ulica

EU.PI.12.7 - adres komórki organizacyjnej - nr domu

EU.PI.12.8 - adres komórki organizacyjnej - nr lokalu

EU.PI.13 System musi umożliwiać wyszukiwanie komórek organizacyjnych w katalogu komórek organizacyjnych co najmniej wg następujących kryteriów:

EU.PI.13.1 - nazwa komórki organizacyjnej

EU.PI.13.2 - kod komórki organizacyjnej - cz. VII kodu resortowego

EU.PI.13.3 - specjalność komórki organizacyjnej

EU.PI.13.4 - kod specjalności komórki organizacyjnej - cz. VIII kodu resrotowego

EU.PI.13.5 - miejscowość

EU.PI.13.6 - ulica

EU.PI.14 System musi umożliwiać przeglądanie katalogu personelu medycznego (udostępnionego w tym celu do Portalu Informacyjnego) realizującego usługi medyczne

EU.PI.15 System musi prezentować nastepujące dane o personelu medycznym realizującym usługi medyczne:

EU.PI.15.1 - nazwisko

EU.PI.15.2 - imię

EU.PI.15.3 - numer PWZ

EU.PI.15.4 - specjalność

EU.PI.15.5 - grupa zawodowa

EU.PI.15.6 - stopień naukowy

EU.PI.16 System musi umożliwiać wyszukiwanie personelu w katalogu usług medycznych co najmniej wg następujących kryteriów:


EU.PI.16.2 - imię

EU.PI.16.3 - numer PWZ

EU.PI.16.4 - specjalność

EU.PI.16.5 - grupa zawodowa

EU.PI.16.6 - stopień naukowy

EU.PI.17 Dane podstawowe o podmiotach leczniczych, realizowanych przez nie usługach medycznych, komórkach organizacyjnych, w których realizowane są te usługi i personelu realizującym te usługi muszą być pobierane (przez system) okresowo z podmiotów leczniczych i gromadzone w centrum regionalnym

EU.PI.18 System musi udostępniać Wyszukiwarkę usług medycznych umożliwiającą pacjentom wyszukiwanie usług medycznych realizowanych przez podmioty lecznicze zintegrowane z centrum regionalnym

EU.PI.19 Wyszukiwarka usług medycznych wyszukuje dane o usługach medycznych przechowywane w centrum regionalnym udostępnione w tym celu przez podmioty lecznicze zintegrowane z centrum regionalnym

EU.PI.20 Wyszukiwarka usług medycznych udostępnia (co najmniej) następujące kryteria wyszukiwania:



EU.PI.20.3 - fragment opisu usługi medycznej

EU.PI.20.4 - nazwa podmiotu leczniczego

EU.PI.20.5 - miejscowość (siedziby podmiotu leczniczego)

EU.PI.20.6 - ulica (siedziby podmiotu leczniczego)

EU.PI.20.7 - specjalność komórki organizacyjnej realizującej usługę

EU.PI.20.8 - nazwisko pracownika medycznego (personelu medycznego) realizującego usługę medyczną

EU.PI.20.9 - nazwa specjalności personelu realizującego usługę medyczną

EU.PI.20.10 - numer PWZ personelu realizującego usługę medyczną

EU.PI.20.11 - dostępność usługi medycznej dla elektronicznej rejestracji

EU.PI.20.12 - orientacyjny pierwszy wolny termin realizacji usługi medycznej dostępnej dla elektronicznej rejestracji

EU.PI.21 Dane w opcji wyszukiwania podpowiadane są listy rozwijanej z możliwością zaznaczenia wszystkich, jednej lub kilku opcji wyboru.

EU.PI.22 W wyniku wyszukiwania Wyszukiwarka usług medycznych prezentuje listę usług medycznych spełniających kryteria wyszukiwania zawierającą (co najmniej) następujące dane:



EU.PI.22.3 - opis usługi medycznej

EU.PI.22.4 - warunki wykonania usługi medycznej

EU.PI.22.5 - czy wymagane skierowanie od lekarza?

EU.PI.22.6 - podmiot leczniczy, w którym jest realizowana usługa medyczna


Strona 40 z 208

Nr wymagania

Wymaganie

EU.PI.22.7 - komórka organizacyjna (wraz z adresem), w której jest realizowana usługa medyczna

EU.PI.22.8 - personel realizujący usługę medyczną

EU.PI.22.9 - grupa zawodowa personelu realizującego usługę medyczną

EU.PI.22.10 - orientacyjny pierwszy wolny termin rejestracji na usługę (o ile usługa podlega elektronicznej rejestracji)

EU.PI.23 Dla każdej wyświetlonej na liście wyników wyszukiwania usługi medycznej podlegającej elektronicznej rejestracji system musi udostępniać opcję przejścia do eRejestracji.

EU.PI.24 System musi umożliwiać sortowanie (przez kliknięcie w nagłówek) danych wyświetlanych w wyniku wyszukiwania Wyszukiwarki usług medycznych

EU.PI.25 System musi udostępniać Informator o usługach medycznych prezentujący informacje o podmiotach leczniczych, realizowanych usługach medycznych, komórkach organizacyjnych, w których realizowane są te usługi oraz personelu medycznym realizującym te usługi

EU.PI.26 Informator umożliwia użytkownikowi wybór układu wg którego użytkownik będzie przeglądał dane (co najmniej):

EU.PI.26.1 - układ umożliwiający rozpoczęcie przeglądania danych od wyboru podmiotu leczniczego

EU.PI.26.2 - układ umożliwiający rozpoczęcie przeglądania danych od wyboru specjalności komórki organizacyjnej

EU.PI.26.3 - układ umożliwiający rozpoczęcie przeglądania danych od wyboru rodzaju usługi

EU.PI.26.4 - układ umożliwiający rozpoczęcie przeglądania danych od wyboru grupy zawodowej personelu realizującego usługi

EU.PI.27 System musi umożliwiać zalogowanym użytkownikom:

EU.PI.27.1 - przeglądanie historii rejestracji na wizyty

EU.PI.27.2 - przejście do elektronicznej rejestracji na wizyty

EU.PI.27.3 - przeglądanie listy subkont

EU.PI.27.4 - zakładanie subkont

EU.PI.28 System musi wymagać od pacjenta zalogowania się do jego konta w celu wykonywania elektronicznej rejestracji, przeglądania historii rejestracji, zarządzania subkontami

EU.PI.29 System musi umożliwiać pacjentom zakładanie konta

EU.PI.30 Dane wymagane dane do założenia konta to:

EU.PI.30.1 - imię


EU.PI.30.3 - data urodzenia

EU.PI.30.4 - płeć

EU.PI.30.5 - dane identyfikujące pacjenta

EU.PI.30.6 - nr telefonu komórkowego (na potrzeby powiadomień SMS)

EU.PI.30.7 - e-mail (na potrzeby powiadomień email)

EU.PI.30.8 - adres zamieszkania - ulica,

EU.PI.30.9 - adres zamieszkania - miejscowość

EU.PI.30.10 - adres zamieszkania - nr domu

EU.PI.30.11 - adres zamieszkania - nr lokalu

EU.PI.30.12 - adres zamieszkania - kod pocztowy

EU.PI.30.13 - adres zamieszkania - poczta

EU.PI.30.14 - adres zamieszkania - województwo

EU.PI.30.15 - adres zamieszkania - powiat

EU.PI.31 System musi obsługiwać następujące dane identyfikujące pacjentów:

EU.PI.31.1 - dla osoby posiadającej PESEL: PESEL

EU.PI.31.2 - dla noworodka nieposiadającego PESEL: PESEL opiekuna, data urodzenia noworodka, nr kolejny noworodka w przypadku ciąży mnogiej

EU.PI.31.3 - dla cudzoziemca: kraj pochodzenia i identyfikator pacjenta w kraju pochodzenia lub kraj pochodzenia i nr dokumentu tożsamości

EU.PI.32 System musi wymagać aby zakładający konto potwierdził zapoznanie się z regulaminem portalu oraz wyraził zgodę na przetwarzanie danych osobowych w celu rejestracji, w tym wysyłania powiadomień

EU.PI.33 System musi umożliwiać użytkownikowi będącemu opiekunem prawnym (rodzic , przedstawiciel ustawowy) zakładanie subkonta i zarządzanie tym subkontem:

EU.PI.33.1 - dla osoby niepełnoletniej

EU.PI.33.2 - dla osoby mającej ograniczoną zdolność do wykonywania czynności prawnych lub niemającej zdolności do wykonywania czynności prawnych

EU.PI.34 System musi wymagać, aby zakładający subkonto potwierdził zapoznanie się z regulaminem portalu oraz aby wyraził zgodę na przetwarzanie danych osobowych pacjenta, dla którego zakładane jest subkonto w celu rejestracji, w tym wysyłania powiadomień SMS/email

EU.PI.35 System musi nadawać dla zakładanego konta/subkonta unikalny login i hasło


Strona 41 z 208

Nr wymagania

Wymaganie

EU.PI.36 System musi na wysyłać powiadomienie o założeniu konta/subkonta na email podany przy rejestracji konta/subkonta

EU.PI.37 System musi umożliwiać zmianę hasła przy pierwszym logowaniu do konta/subkonta

EU.PI.38 System podczas logowania musi umożliwiać dla konta/subkonta obsługę "zapomniałem hasła"

EU.PI.39 System musi umożliwiać użytkownikowi logowanie się do konta lub subkonta za pomocą uzyskanych loginu i hasła

EU.PI.40 System musi umożliwiać użytkownikowi zmianę hasła (dla konta/subkonta)

EU.PI.41 System musi umożliwiać dostęp do subkonta:

EU.PI.41.1 - z poziomu konta głównego (przejście do subkonta nie wymaga podania loginu i hasła do subkonta)

EU.PI.41.2 - przez bezpośrednie zalogowanie się do subkonta za pomocą loginu i hasła związanego z subkontem

EU.PI.42 System musi umożliwiać użytkownikowi konta przekształcenie subkonta w konto, łącznie z przepisaniem historii rejestracji wizyt z subkonta na konto

EU.PI.43 System musi uniemożliwiać zakładanie więcej niż jednego konta/subkonta dotyczącego pacjenta (unikalność określana na podstawie danych identyfikujących pacjenta)

EU.PI.44 System musi umożliwiać zmianę danych konta (nazwisko, imię, data urodzenia, płeć , adres zamieszkania, nr telefonu komórkowego, adres email) z wyłączeniem danych identyfikujących pacjenta

EU.PI.45 System musi udostępniać funkcjonalność uzupełnienia PESEL dla subkonta założonego dla noworodka nieposiadającego PESEL

EU.PI.46 System musi umożliwiać zalogowanemu użytkownikowi przeglądanie skierowanych do niego wiadomości portalowych

EU.PI.47 System musi umożliwiać zalogowanemu użytkownikowi usuwanie skierowanych do niego wiadomości portalowych

EU.PI.48 System musi umożliwiać zalogowanemu użytkownikowi oznaczanie skierowanych do niego widomości portalowych jako przeczytane / nieprzeczytane

EU.PI.49 System musi umożliwiać zalogowanemu użytkownikowi przeglądanie historii jego (oraz jego subkont) rejestracji na usługi medyczne

EU.PI.50 W historii rejestracji mają być wyświetlane rejestracje wykonane za pomocą e-Usługi eRejestracja oraz rejestracje wykonane wyłącznie w systemie lokalnym podmiotu leczniczego, o których ten podmiot poinformował centrum regionalne

EU.PI.51 System musi umożliwiać użytkownikowi filtrowanie historii rejestracji w następującym zakresie:

EU.PI.51.1 - rodzaj konta: konto, subkonta, wszystkie

EU.PI.51.2 - data od i data do terminu wizyty

EU.PI.51.3 - numer rejestracji

EU.PI.51.4 - miejsce świadczenia usługi

EU.PI.51.5 - status rejestracji (otwarta, zamknięta, anulowana)


EU.PI.52 Dla każdej rejestracji wyświetlanej na liście historii rejestracji muszą być prezentowane co najmniej następujące dane:

EU.PI.52.1 - Imię i nazwisko pacjenta, którego dotyczy rejestracja



EU.PI.52.4 - miejsce świadczenia usługi

EU.PI.52.5 - termin wizyty

EU.PI.52.6 - numer rejestracji

EU.PI.52.7 - status rejestracji (otwarta, zamknięta, anulowana)

EU.PI.53 System musi umożliwiać sortowanie (przez kliknięcie w nagłówek) danych wyświetlanych w historii rejestracji

EU.PI.54 System musi prezentować historię zmian szczegółowych statusów danej rejestracji

EU.PI.55 System musi umożliwiać anulowanie rejestracji na wizytę udostępniając opcję anulowania dla pozycji wyświetlanych w historii rejestracji

EU.PI.56 System musi umożliwiać anulowanie wizyty tylko dla rejestracji wykonanych za pomocą eUslugi eRejestracja i tylko w przypadku, gdy jeszcze nie minął termin wizyty

EU.PI.57 System musi umożliwiać zalogowanemu użytkownikowi parametryzowanie swojego konta w następującym zakresie

EU.PI.57.1 - wysyłanie powiadomień email potwierdzających rezerwację, zmiany terminu, anulowanie rejestracji lub przypominające o zbliżającym się terminie wizyty

EU.PI.57.2 - wysyłanie powiadomień SMS potwierdzających rezerwację, zmiany terminu, anulowanie rejestracji lub przypominające o zbliżającym się terminie wizyty


Strona 42 z 208

Nr wymagania

Wymaganie

EU.PI.57.3 - wyświetlanie w historii rejestracji informacji o rejestracji wizyt dotyczących wyłącznie konta lub dotyczących konta i wszystkich subkont

EU.PI.58 System musi umożliwiać zalogowanemu użytkownikowi parametryzowanie subkonta w następującym zakresie:

EU.PI.58.1 - wysyłanie powiadomień email potwierdzających rezerwację, zmiany terminu, anulowanie rejestracji lub przypominające o zbliżającym się terminie wizyty

EU.PI.58.2 - wysyłanie powiadomień SMS potwierdzających rezerwację, zmiany terminu, anulowanie rejestracji lub przypominające o zbliżającym się terminie wizyty

EU.PI.59 System musi umożliwiać uruchomienie wersji mobilnej Portalu Informacyjnego

EU.PI.60 Wersja mobilna Portalu Informacyjnego musi udostępniać pacjentom, bez konieczności logowania, następujące treści:

EU.PI.60.1 - aktualności

EU.PI.60.2 - informacje o projekcie

EU.PI.60.3 - regulamin portalu

EU.PI.60.4 - informacje podstawowe o podmiotach leczniczych zintegrowanych z centrum regionalnym

EU.PI.60.5 - wyszukiwarka usług medycznych

EU.PI.61 Wersja mobilna musi umożliwiać zalogowanym użytkownikom:

EU.PI.61.1 - przeglądanie historii rejestracji na wizyty

EU.PI.61.2 - przejście do elektronicznej rejestracji na wizyty (wersji mobilnej eRejestracji) z poziomu wyszukiwarki usług medycznych

EU.PI.61.3 - przeglądanie listy subkont

EU.PI.62 Wersja mobilna musi umożliwiać dostęp do subkonta:

EU.PI.62.1 - z poziomu konta głównego (przejście do subkonta nie wymaga podania loginu i hasła do subkonta)

EU.PI.62.2 - przez bezpośrednie zalogowanie się do subkonta za pomocą loginu i hasła związanego z subkontem

EU.PI.63 Wersja mobilna uniemożliwia:

EU.PI.63.1 - zakładanie konta lub subkonta

EU.PI.63.2 - zmianę hasła

EU.PI.63.3 - podglądanie i edycję danych konta/subkonta

EU.PI.63.4 - przekształcenia subkonta w konto

VI.1.2.3. E-Rejestracja

Nr wymagania

Wymaganie

EU.ER eRejestracja

EU.ER.1 System musi umożliwiać elektroniczną rejestrację na usługi medyczne udostępnione w tym celu przez podmioty lecznicze zintegrowane z centrum regionalnym

EU.ER.2 Funkcjonalności elektronicznej rejestracji na usługi medyczne (eRejestracja) są dostępne wyłącznie dla zalogowanych użytkowników

EU.ER.3 Użytkownik może wykonać elektroniczną rejestrację na usługę medyczną w imieniu własnym lub w imieniu właściciela subkonta

EU.ER.4 Elektroniczna rejestracja na usługę medyczną w imieniu właściciela subkonta jest możliwa:

EU.ER.4.1 - po przejściu z własnego konta w kontekst pracy z subkontem

EU.ER.4.2 - lub po bezpośrednim zalogowaniu się do subkonta

EU.ER.5 System musi zapewniać synchronizację on-line rejestracji wizyty dla danej usługi medycznej w lokalnym systemie medycznym podmiotu leczniczego wykonanej przy pomocy e-Rejestracji

EU.ER.6 System musi zapewniać synchronizację on-line zmiany terminu wizyty dla danej usługi medycznej w lokalnym systemie medycznym podmiotu leczniczego z historią rejestracji dostępną w Portalu Informacyjnym

EU.ER.7 System musi zapewniać synchronizację on-line anulowania wizyty dla danej usługi medycznej w lokalnym systemie medycznym podmiotu leczniczego wykonanej przy pomocy e-Rejestracji.

EU.ER.8 System musi zapewniać synchronizację on-line zakończenia wizyty w lokalnym systemie medycznym podmiotu leczniczego z historią rejestracji dostępną w Portalu Informacyjnym, o ile system lokalny przekaże taką informację

EU.ER.9 Przejście do elektronicznej rejestracji następuje po wybraniu opcji rejestracji dostępnej w wyniku wyszukiwania Wyszukiwarki usług medycznych (Portal Informacyjny) lub w wyniku przeglądania Informatora usług medycznych (Portal Informacyjny)


Strona 43 z 208

Nr wymagania

Wymaganie

EU.ER.10 Przejście do elektronicznej rejestracji z wyników wyszukiwania Wyszukiwarki usług medycznych lub z Informatora o usługach medycznych następuje poprzez jedno kliknięcie, w wyniku czego zostanie wyświetlony terminarz pokazujący wolne terminy udostępnione on-line przez system lokalny podmiotu leczniczego zintegrowanego z centrum regionalnym

EU.ER.11 Przejście do elektronicznej rejestracji z wyników wyszukiwania Wyszukiwarki usług medycznych lub z Informatora o usługach medycznych jest możliwe tylko gdy wskazano usługę medyczną, komórkę organizacyjną i personel realizujący (o ile system lokalny wymaga wskazania personelu)

EU.ER.12 System musi umożliwiać użytkownikowi wybranie jednego z wolnych terminów

EU.ER.13 W przypadku, gdy użytkownik rezygnuje z wyboru wolnego terminu system musi umożliwiać powrót z terminarza do okna, z którego została zainicjowana elektroniczna rejestracja

EU.ER.14 Po wybraniu wolnego terminu przez użytkownika system prosi użytkownika o potwierdzenie rozpoczęcia rejestracji i w przypadku potwierdzenia w trybie on-line blokuje termin w systemie lokalnym podmiotu leczniczego na czas trwania sesji

EU.ER.15 Po wybraniu wolnego terminu i potwierdzeniu rozpoczęcia rejestracji przez użytkownika system prezentuje formatkę rejestracji na wizytę zawierającą co najmniej następujące informacje:

EU.ER.15.1 - dane pacjenta (użytkownika konta/subkonta): imię i nazwisko, dane identyfikujące

EU.ER.15.2 - miejsce wykonania usługi (podmiot leczniczy, komórka organizacyjna, adres)

EU.ER.15.3 - opis usługi

EU.ER.15.4 - warunki wykonania usługi

EU.ER.15.5 - czy wymagane skierowanie od lekarza

EU.ER.15.6 - dane personelu realizującego (o ile został wskazany)

EU.ER.15.7 - termin realizacji usługi

EU.ER.15.8 - dodatkowe dane do uzupełnienia niezbędne do rejestracji (o ile zostały zdefiniowane dla danej usługi medycznej i podmiotu leczniczego w module administracyjnym)

EU.ER.16 Dodatkowe dane do uzupełnienia muszą być podpowiadane do wyboru w postaci pola do uzupełnienia, listy rozwijanej z zaznaczeniem wszystkich, jednej lub kilku opcji wyboru (opcja w zależności od rodzaju listy rozwijanej)

EU.ER.17 System musi prezentować użytkownikowi, które z dodatkowych danych do uzupełnienia są wymagane do wypełnienia

EU.ER.18 System musi wymagać od użytkownika wypełnienia wymaganych dodatkowych danych

EU.ER.19 System musi wymagać wypełnienia nr skierowania o ile do realizacji danej usługi medycznej wymagane jest skierowanie

EU.ER.20 System musi weryfikować kompletności wypełnienia danych wymaganych na formatce rejestracji przed wysyłaniem danych do lokalnego systemu danego podmiotu leczniczego, a w przypadku braku wypełnienia musi prezentować informację zwrotną z zaznaczeniem danych nie wypełnionych

EU.ER.21 Na formatce rejestracji system musi udostępniać opcje potwierdzenia rejestracji (wysłania on-line do lokalnego systemu podmiotu leczniczego) lub rezygnacji z rejestracji:

EU.ER.21.1 - w przypadku rezygnacji z rejestracji następuje zamknięcie formatki rejestracji i zwolnienie zablokowanego terminu

EU.ER.21.2 - w przypadku potwierdzenia na formatce rejestracji prezentowana jest informacja graficzna o przetwarzaniu informacji o rezerwacji, z prośbą o oczekiwanie

EU.ER.22 System po zakończeniu przetwarzania informacji o rejestracji (tj. po potwierdzeniu dokonania rejestracji przez system lokalny danego podmiotu leczniczego, w którym będzie realizowana usługa) prezentuje użytkownikowi informację zwrotną:

EU.ER.22.1 - potwierdzającą przyjęcie rejestracji na wizytę lub

EU.ER.22.2 - informującą o odrzuceniu rejestracji na wizytę.

EU.ER.23 Potwierdzenie przyjęcia rejestracji na wizytę musi zawierać (poza danymi rejestracji):

EU.ER.23.1 - informację potwierdzająca przyjęcie rejestracji

EU.ER.23.2 - unikalny numer rejestracji z systemu medycznego w podmiocie leczniczym gdzie została zapisana rejestracja

EU.ER.24 System musi umożliwiać wydrukowanie (w czytelnej postaci) potwierdzenia rejestracji

EU.ER.25 Potwierdzenie przyjęcia rejestracji skutkuje pojawieniem się informacji o rejestracji w historii rejestracji użytkownika w Portalu Informacyjnym

EU.ER.26 Informacja o odrzuceniu rejestracji na wizytę musi zawierać:

EU.ER.26.1 - tekst informujący o odrzuceniu rejestracji

EU.ER.26.2 - tekst informujący o przyczynie odrzucenia (informacja generowana automatycznie np. zajęty termin)


Strona 44 z 208

Nr wymagania

Wymaganie

EU.ER.27 W przypadku braku możliwości zakończenia we wskazanym czasie przetwarzania (wysłania do lokalnego systemu danego podmiotu leczniczego) informacji o rezerwacji i braku z podmiotu leczniczego informacji zwrotnej o potwierdzeniu lub odrzuceniu rejestracji (np. niedostępne łącze pomiędzy centrum regionalnym a lokalnym systemem podmiotu leczniczego):

EU.ER.27.1 - następuje zamknięcie okna z informacją graficzną w oknie rejestracji o przetwarzaniu

EU.ER.27.2 - następuje zapisanie (z określonym statusem) rezerwacji w historii rejestracji na koncie użytkownika w Portalu Informacyjnym

EU.ER.27.3 - rezerwacja wysyłana jest do systemu lokalnego podmiotu leczniczego do skutku, celem potwierdzenia lub odrzucenia rejestracji

EU.ER.28 System musi umożliwiać walidację kolizji elektronicznych rezerwacji co najmniej w następujących przypadkach:

EU.ER.28.1 - użytkownik rejestruje się na różne usługi jednego dnia na tę samą godzinę

EU.ER.28.2 - użytkownik wielokrotnie rejestruje się na tę samą usługę w tym samym dniu

EU.ER.29 W przypadku wykrycia kolizji rejestracji użytkownikowi prezentowana jest stosowna informacja i rejestracja nie dochodzi do skutku

EU.ER.30 System musi umożliwiać użytkownikowi anulowanie wskazanej rejestracji

EU.ER.31 Wywołanie funkcjonalności anulowania jest dostępne z poziomu wskazanej rejestracji widocznej na liście historii rejestracji użytkownika w Portalu Informacyjnym

EU.ER.32 Wybór opcji anulowania wskazanej rejestracji powoduje wyświetlenie informacji potwierdzającej fakt anulowania otwartej Rejestracji.

EU.ER.33 Użytkownik potwierdza wysłanie anulowania rejestracji lub ją anuluje (w przypadku anulowania następuje zamknięcie okna informacyjnego)

EU.ER.34 W przypadku potwierdzenia przez użytkownika anulowania rejestracji system wyświetla kolejną informację potwierdzającą faktu anulowania otwartej rejestracji: a) w przypadku anulowania następuję zamknięcie okna informacyjnego b) w przypadku potwierdzenia, następuje wysłanie anulowania rejestracji do podmiotu leczniczego i następuje zamknięcie okna informacyjnego

EU.ER.35 Anulowanie rejestracji powoduje zapisanie zmiany statusu w historii rejestracji na koncie użytkownika w Portalu Informacyjnym

EU.ER.36 Anulowanie rejestracji wysyłane (do systemu medycznego podmiotu leczniczego) jest do skutku, celem potwierdzenia anulowania

EU.ER.37 Komunikaty systemowe SMS i e-mail dotyczące obsługi rejestracji przekazywane są z lokalnych systemów medycznych do centrum regionalnego, skąd są wysyłane

EU.ER.38 System musi umożliwiać obsługę komunikatów systemowych SMS i e-mail dla wszystkich sposobów (poprzez WWW, telefon, osobiście) rejestracji dla użytkowników posiadających konto użytkownika Portalu Informacyjnego

EU.ER.39 System musi umożliwiać obsługę komunikatów systemowych potwierdzających rejestrację

EU.ER.40 Potwierdzenie rejestracji wysyłane jest na wskazany przez Użytkownika końcowego adres e-mail o treści jak wyświetlonej na ekranie w wyniku potwierdzenia przyjęcia rejestracji wizyty.

EU.ER.41 Wiadomość e-mail jest generowana automatycznie i zawiera część:

EU.ER.41.1 - stałą (co najmniej): treść informacyjna, login użytkownika

EU.ER.41.2 - zmienną (co najmniej): unikalny numer rejestracji z systemu medycznego w jednostce gdzie została zapisana rejestracja, planowany termin wizyty

EU.ER.42 Wiadomość e-mail jest sformatowana w treści gotowej do wydruku

EU.ER.43 System powinien mieć funkcjonalność potwierdzenia Rejestracji, które wysyłane jest w postaci SMS na wskazany przez użytkownika nr telefonu o wskazanej treści

EU.ER.44 Wiadomości SMS jest generowana automatycznie i zawiera część:

EU.ER.44.1 - stałą (co najmniej): treść informacyjna, login użytkownika,


EU.ER.44 System musi umożliwiać obsługę komunikatów systemowych potwierdzających akcje obsługi Rejestracji

EU.ER.45 W wyniku zbliżającego się terminu wizyty system wysyła wiadomości SMS i/lub e-mail z powiadomieniem o zdarzeniu

EU.ER.47 Wiadomości e-mail jest generowana automatycznie i zawiera część:





Strona 45 z 208

Nr wymagania

Wymaganie

EU.ER.49 W wyniku anulowania wizyty w lokalnym Systemie medycznym HIS, system przekazuje wiadomość SMS i/lub e-mail z powiadomieniem o określonej treści.

EU.ER.50 Wiadomość SMS jest generowana automatycznie i zawiera część:







EU.ER.53 W wyniku zmiany terminu wizyty w lokalnym Systemie medycznym HIS, przekazuje on wiadomość SMS i/lub e-mail z powiadomieniem o określonej treści:

EU.ER.54 Wiadomości SMS jest generowana automatycznie i zawiera część:


EU.ER.54.2 - zmienną (co najmniej): unikalny numer rejestracji z systemu medycznego w jednostce gdzie została zapisana rejestracja, nowy termin wizyty



EU.ER.55.2 - zmienną (co najmniej): unikalny numer rejestracji z systemu medycznego w jednostce gdzie została zapisana rejestracja, stary termin wizyty, nowy termin wizyty


EU.ER.57 System musi odnotowywać zmianę terminu w historii rejestracji konta użytkownika w Portalu Informacyjnym

EU.ER.58 System musi umożliwiać odnotowanie zakończenia wizyty (zmiana statusu rejestracji wizyty na zakończona) w historii rejestracji użytkownika w Portalu Informacyjnym, przy czym stroną informującą centrum regionalne o zakończeniu wizyty jest system lokalny podmiotu leczniczego

EU.ER.59 System musi umożliwiać uruchomienie wersji mobilnej eRejestracji

EU.ER.60 Wersja mobilna eRejestracji musi zalogowanym pacjentom umożliwiać:

EU.ER.60.1 - wykonanie elektronicznej rejestracji na usługi medyczne udostępnione w tym celu przez podmioty lecznicze zintegrowane z centrum regionalnym

EU.ER.60.2 - anulowanie wskazanej elektronicznej rejestracji na usługę medyczną

EU.ER.61 Wersja mobilna musi umożliwiać użytkownik wykonanie elektronicznej rejestracji na usługę medyczną w imieniu własnym lub w imieniu właściciela subkonta

EU.ER.62 W wersji mobilnej elektroniczna rejestracja na usługę medyczną w imieniu właściciela subkonta jest możliwa:

EU.ER.62.1 - po przejściu z własnego konta w kontekst pracy z subkontem

EU.ER.62.2 - lub po bezpośrednim zalogowaniu się do subkonta

EU.ER.63 Wywołanie mobilnej funkcjonalności anulowania jest dostępne z poziomu wskazanej rejestracji widocznej na liście historii rejestracji użytkownika w wersji mobilnej Portalu Informacyjnego

EU.ER.64 Przejście do elektronicznej rejestracji (w wersji mobilnej) następuje po wybraniu opcji rejestracji dostępnej wyniku wyszukiwania Wyszukiwarki usług medycznych (w wersji mobilnej Portalu Informacyjnego)

VI.1.2.4. eRecepta

Nr wymagania

Wymaganie

EU.RC eRecepta

EU.RC.1 System musi umożliwiać odnotowanie chęci pobrania recepty na leki odnawialne w ramach planowanej wizyty

EU.RC.2 Funkcjonalność odnotowania chęci pobrania recepty na leki odnawialne jest dostępna w formatce rejestracji wizyty dostępnej w ramach e-Usługi eRejestracja

EU.RC.3 Informacja o chęci pobrania recepty na leki odnawialne jest przekazywana wraz z danymi elektronicznej rejestracji wysyłanymi on-line do podmiotu leczniczego


Strona 46 z 208

EU.RC.4 Funkcjonalność odnotowania chęci pobrania recepty na leki odnawialne jest dostępna wyłącznie dla zalogowanych użytkowników.

EU.RC.5 System musi udostępniać możliwość włączania/wyłączania (z dokładnością do usługi medycznej) opcji odnotowywania chęci pobrania recepty na leki odnawialne

VI.1.2.5. Wsparcie dla e-Usług

Nr wymagania

Wymaganie

EU.WS Wsparcie dla e-Usług

EU.WS.1 W ramach sieci intranet system udostępnia funkcjonalności dedykowane dla użytkowników wewnętrznych (pracowników podmiotów leczniczych) wspierające funkcjonowanie e-Usług

EU.WS.2 System musi udostępniać podmiotowi leczniczemu funkcjonalności wprowadzania i aktualizacji danych o podmiocie leczniczym, realizowanych usługach medycznych, komórkach realizujących te usługi i personelu realizującym te usługi w przypadku, gdy dany podmiot leczniczy nie posiada możliwości dostosowania system lokalnego do przekazywania tych danych do regionalnego centrum za pomocą interfejsu wymiany danych (przy czym dany podmiot leczniczy wykorzystuje wyłączenie interfejs wymiany danych albo wyłącznie ww. funkcjonalności).

EU.WS.3 Zakres danych wprowadzanych za pomocą tych funkcjonalności musi pokrywać zakres wymaganych do prawidłowej prezentacji w Portalu Informacyjnym (katalogi danych, informator o usługach medycznych, wyszukiwarka usług medycznych) danych o:

EU.WS.3.1 - podmiocie leczniczym

EU.WS.3.2 - usługach realizowanych przez podmiot leczniczy ze wskazaniem tych, które są dostępne do elektronicznej rejestracji (eRejestracji)

EU.WS.3.3 - komórkach organizacyjnych realizujących te usługi

EU.WS.3.4 - personelu medycznym realizującym te usługi

EU.WS.4 System musi udostępniać podmiotowi leczniczemu funkcjonalności definiowania terminarzy na potrzeby elektronicznej rejestracji w przypadku, gdy dany podmiot leczniczy nie posiada możliwości dostosowania systemu lokalnego do udostępniania terminarzy do regionalnego centrum za pomocą interfejsu wymiany danych (przy czym wszystkie terminarze danego podmiotu są prowadzone wyłącznie za pomocą tej udostępnionej funkcjonalności albo wyłącznie za pomocą interfejsu wymiany danych)

EU.WS.5 Udostępniona przez system funkcjonalność definiowania terminarzy musi wykorzystywać informacje zgromadzone w ramach Portalu Informacyjnego dotyczące podmiotu leczniczego, usług medycznych realizowanych w podmiocie, komórek realizujących te usługi, personelu medycznego realizującego te usługi.

EU.WS.6 System musi umożliwiać definiowanie wielu terminarzy dla danego podmiotu leczniczego.

EU.WS.7 Konstrukcja terminarzy musi umożliwiać poprawną współpracę z funkcjonalnościami dotyczącymi elektronicznej rejestracji

EU.WS.8 System musi umożliwiać przeglądanie listy terminarzy oraz szczegółów terminarzy

EU.WS.9 System musi umożliwiać (ręczne) dodawanie rejestracji w terminarzu

EU.WS.10 System musi umożliwiać rozróżnienie w terminarzu rejestracji dodanych ręcznie od rejestracji wykonanych za pomocą eRejestracji

EU.WS.11 System musi prezentować w terminarzu wszystkie zarezerwowane wizyty niezależnie czy były wykonane z poziomu eRejestracji czy ręcznie przez użytkownika

EU.WS.12 System musi umożliwiać dla zarejestrowanej (niezależnie od sposobu - ręcznie czy przez eRejestrację) wizyty wykonanie następujących akcji:

EU.WS.12.1 - anulowanie wizyty

EU.WS.12.2 - zmiana terminu wizyty

EU.WS.12.3 - zakończenie wizyty

EU.WS.13 System musi obsługiwać wysyłanie komunikatów systemowych email/SMS związanych z powyższymi akcjami (analogicznie jak w eRejestracja)

EU.WS.14 System musi udostępniać funkcjonalność odnotowania potwierdzania tożsamości pacjenta, dla którego zakładane jest konto/subkonto w Portalu Informacyjnym (w skutek potwierdzenia następuje aktywacja konta w Portalu Informacyjnym)

EU.WS.15 System musi umożliwiać wyszukiwanie konta/subkonta pacjenta wg danych identyfikujących pacjenta

EU.WS.15.1 - dla osoby posiadającej PESEL: PESEL

EU.WS.15.2 - dla noworodka nieposiadającego PESEL: PESEL opiekuna, data urodzenia noworodka, nr kolejny noworodka w przypadku ciąży mnogiej

EU.WS.15.3 - dla cudzoziemca: kraj pochodzenia i identyfikator pacjenta w kraju pochodzenia lub kraj pochodzenia i nr dokumentu tożsamości


Strona 47 z 208

Nr wymagania

Wymaganie

EU.WS.16 System udostępnia opcję potwierdzenia tożsamości pacjenta wyłącznie gdy wyszukane konto/subkonto pacjenta nie zostało jeszcze aktywowane

VI.1.2.6. Administracja

Nr wymagania

Wymaganie

EU.AD Administracja

EU.AD.1 Funkcjonalności administracyjne są dostępne tylko w sieci intranet dla zalogowanego administratora

EU.AD.2 Musi być możliwość włączenia/wyłączenia opcji potwierdzania dostępu jednorazowym kodem SMS podczas logowania się administratora do systemu

EU.AD.3 System musi umożliwiać zarządzanie e-Usługami tj. musi umożliwiać:

EU.AD.3.1 - aktywowanie e-Usług

EU.AD.3.2 - blokowanie e-Usług

EU.AD.3.3 - parametryzowanie e-Usług

EU.AD.4 System musi umożliwiać zarządzanie użytkownikami Portalu Informacyjnego tj. musi umożliwiać:

EU.AD.4.1 - dodawanie użytkowników

EU.AD.4.2 - aktywowanie i blokowanie użytkowników

EU.AD.4.3 - edycję danych użytkowników

EU.AD.4.4 - nadawanie i odbieranie uprawnień

EU.AD.5 System musi umożliwiać zarządzanie grupami użytkowników Portalu Informacyjnego, tj. musi umożliwiać:

EU.AD.5.1 - tworzenie grup

EU.AD.5.2 - dodawanie użytkowników do grupy

EU.AD.5.3 - usuwanie użytkowników z grupy

EU.AD.5.4 - edycję uprawnień grupy

EU.AD.6 System musi umożliwiać zarządzanie użytkownikami wewnętrznymi tj. musi umożliwiać:

EU.AD.6.1 - dodawanie użytkowników

EU.AD.6.2 - aktywowanie i blokowanie użytkowników

EU.AD.6.3 - edycję danych użytkowników

EU.AD.6.4 - nadawanie i odbieranie uprawnień

EU.AD.7 System musi umożliwiać zarządzanie grupami użytkowników wewnętrznych, tj. musi umożliwiać:

EU.AD.7.1 - tworzenie grup

EU.AD.7.2 - dodawanie użytkowników do grupy

EU.AD.7.3 - usuwanie użytkowników z grupy

EU.AD.7.4 - edycję uprawnień grupy

EU.AD.8 System musi umożliwiać zarządzanie złożonością hasła użytkowników

EU.AD.9 System musi umożliwiać zarządzaniem katalogiem podmiotów leczniczych zintegrowanych z centrum regionalnym tj. musi umożliwiać:

EU.AD.9.1 - dodawanie nowego podmiotu leczniczego

EU.AD.9.2 - edycję danych podmiotu leczniczego

EU.AD.9.3 - usuwanie podmiotu leczniczego z listy podmiotów zintegrowanych z centrum regionalnym

EU.AD.9.4 - konfigurowanie parametrów na potrzeby e-Usług, w tym określanie czy podmiot leczniczy korzysta wyłącznie z interfejsu wymiany danych, czy wyłącznie wykorzystuje funkcjonalności wspierające e-Usługi w zakresie wprowadzania danych katalogowych oraz zarządzania terminarzami

EU.AD.9.5 - aktywowanie/blokowanie dostępu do e-Usług

EU.AD.10 System musi umożliwiać monitorowanie e-Usług, w tym:

EU.AD.10.1 - monitorowanie działania danej e-Usługi

EU.AD.10.2 - monitorowanie akcji SMS

EU.AD.10.3 - monitorowanie akcji email

EU.AD.11 System musi umożliwiać publikację aktualności w Portalu Informacyjnym

EU.AD.12 System musi umożliwiać obsługę banerów w oknie głównym Portalu Informacyjnego

EU.AD.13 System musi umożliwiać zarządzanie plikami do pobrania dostępnymi w Portalu Informacyjnym

EU.AD.14 System musi umożliwiać administratorom edycję treści następujących katalogów (dostępnych w Portalu Informacyjnym):

EU.AD.14.1 - katalog podmiotów leczniczych

EU.AD.14.2 - katalog usług medycznych realizowanych przez te podmioty

EU.AD.14.3 - katalog komórek organizacyjnych realizujących te usługi


Strona 48 z 208

Nr wymagania

Wymaganie

EU.AD.14.4 - katalog personelu realizującego te usługi

EU.AD.15 Na potrzeby prezentacji aktualnej informacji w Portalu Informacyjnym system musi umożliwiać okresowe automatyczne oraz na żądanie zasilanie danych z systemów lokalnych podmiotów leczniczych do centrum regionalnego w następującym zakresie:

EU.AD.15.1 - dane o podmiotach leczniczych

EU.AD.15.2 - dane o usługach medycznych (udostępnianych w Portalu Informacyjnym), w tym informacje o orientacyjnych pierwszych terminach wykonania usług podlegających elektronicznej rejestracji (za pomocą e-Usługi eRejestracja)

EU.AD.15.3 - dane o komórkach organizacyjnych, w których realizowane są te usługi medyczne

EU.AD.15.4 - dane o personelu medycznym realizującym te usługi medyczne

EU.AD.16 System musi umożliwiać tworzenie szablonów formatek dla eRejestracji, które rozszerzają formularze rejestracji o dodatkowe dane

EU.AD.17 System musi umożliwiać tworzenie formatek dla eRejestracji, które rozszerzają standardowe formularze rejestracji o dodatkowe dane

EU.AD.17.1 - formatki mogą być tworzone ręcznie lub na podstawie szablonów formatek z możliwością korekty po utworzeniu

EU.AD.17.2 - możliwe jest utworzenie formatki na podstawie innej formatki

EU.AD.18 System musi umożliwiać definiowanie pól dostępnych na formatkach z określeniem:

EU.AD.18.1 - typu pola

EU.AD.18.2 - wymagalności pola

EU.AD.18.3 - słownika użytego do wskazania wartości pola (dla pól słownikowych)

EU.AD.19 Zdefiniowane pola dostępne są podczas tworzenia szablonów oraz formatek

EU.AD.20 System musi umożliwiać skojarzenie zdefiniowanego formularza z dowolną usługą danego podmiotu leczniczego

EU.AD.21 Jeśli z usługą medyczną podmiotu leczniczego nie skojarzono formularza rejestracji, to system wykorzystuje standardowy, domyślny formularz rejestracji zawierający: dane pacjenta (użytkownika konta/subkonta), miejsce wykonania usługi, opis usługi, warunki wykonania usługi, czy wymagane skierowanie od lekarza, dane personelu realizującego (o ile został wskazany), termin realizacji usługi

EU.AD.22 System musi umożliwiać tworzenie słowników wykorzystywanych na formularzach eRejestracji

EU.AD.23 System musi umożliwiać włączanie/wyłączanie automatycznego wysyłania wiadomości SMS i e-mail dla określonych rodzajów zdarzeń

EU.AD.23.1 - globalnie dla wszystkich podmiotów

EU.AD.23.2 - dla poszczególnych podmiotów

EU.AD.24 Musi być możliwość definiowania szablonów wiadomości SMS i e-mail dla poszczególnych rodzajów zdarzeń

EU.AD.24.1 - dla każdego rodzaju zdarzenia definiowany jest osobny szablon wiadomości e-mail i osobny szablon wiadomości SMS

EU.AD.24.2 - musi być możliwość użycia w treści szablonu zmiennych opisujących szczegóły zdarzenia (dane pacjenta, hasło pierwszego logowania itp.)

EU.AD.25 System musi umożliwiać wysyłanie informacyjnych wiadomości e-mail do użytkowników e-Usług

EU.AD.25.1 - wiadomość może być wysłana na adres e-mail lub na konto użytkownika w Portalu Informacyjnym

EU.AD.25.2 - musi być możliwość zaplanowania wysłania wiadomości w określonym czasie i dacie

EU.AD.26 System musi umożliwiać przeglądanie historii wiadomości, zawierającej zarówno wiadomości wysłane jak i zaplanowane do wysłania, z możliwością:

EU.AD.26.1 - usunięcia wiadomości

EU.AD.26.2 - edycji niewysłanych wiadomości

EU.AD.27 System musi obsługiwać logi systemowe z działania e-Usług

EU.AD.27.1 - logowaniu podlegają akcje użytkowników, zdarzenia, czas trwania zdarzeń, komunikaty i błędy

EU.AD.28 System musi umożliwiać konfigurowanie (co najmniej) następujących parametrów systemowych:

EU.AD.28.1 - czas trwania sesji systemowych dla zalogowanych użytkowników

EU.AD.28.2 - maksymalny czas wstępnej blokady wolnego terminu przy elektronicznej rejestracji na wizytę mierzony od momentu wybrania przez uzytkownika wolnego terminu w terminarzu do wysłania rejestracji do podmiotu leczniczego (e-Usługa eRejestracja).

EU.AD.28.3 - potwierdzanie dostępu do modułu administracyjnego za pomocą jednorazowego kodu SMS

EU.AD.28.4 - maksymalna liczba subkont możliwych do założenia przez jednego użytkownika (właściciela konta)

EU.AD.28.5 - włączenie/wyłączenie metody captcha dla zakładania konta użytkownika w Portalu Informacyjnym

EU.AD.28.6 - włączanie/wyłaczanie potwierdzania tożsamości pacjenta w procesie zakładania konta

EU.AD.28.7 - możliwość wysyłki e-mail z hasłem do pierwszego logowania


Strona 49 z 208

Nr wymagania

Wymaganie

EU.AD.28.8 - częstotliwość zasilania Portalu Informacyjnego danymi z podmiotów leczniczych (katalog podmiotów leczniczych, katalog usług medycznych, katalog komórek organizacyjnych, katalog personelu medycznego)

EU.AD.29 System musi umożliwiać wygenerowanie następujących raportów administracyjnych:

EU.AD.29.1 - raport występowania błędów podczas dostępu do e-Usług

EU.AD.29.2 - raport liczby zarejestrowanych użytkowników Portalu Informacyjnego

EU.AD.29.3 - raport częstotliwości wywołania e-Usług

EU.AD.29.4 - raport liczby użytkowników korzystających on-line z e-Usług w zadanym okresie

EU.AD.29.5 - raport uprawnień użytkowników

VI.1.2.7. Zakres prac:

VI.1.2.7.1. Instalacja i konfiguracja serwera HTTP wraz z niezbędnym oprogramowaniem

narzędziowym,

VI.1.2.7.2. Instalacja portalu na serwerze HTTP,

VI.1.2.7.3. Testy funkcjonalne portalu,

VI.1.2.7.4. Szkolenie użytkowników.

VI.1.2.8. Specyficzne warunki dostaw / prac:

VI.1.2.8.1. Brak.

VI.1.2.9. Serwis gwarancyjny:

VI.1.2.9.1. System musi być objęty min. 3 letnią gwarancją z zapewnieniem asysty

technicznej w dni robocze w godzinach od 8 do 15 z obsługą telefoniczną i

przy pomocy poczty elektronicznej.

VI.1.2.10. Etapy realizacji dostaw oraz prac podlegające formalnym odbiorom:

VI.1.2.10.1. Etap I – po pozytywnym zakończeniu testów funkcjonalnych.

VI.1.2.10.2. Etap II – po zakończeniu szkolenia.

VI.1.2.11. Wymagania odnośnie treści oferty:

VI.1.2.11.1. Brak.


Strona 50 z 208

VI.2. Zadanie II: System zarządzania i raportowania jednostek służby

zdrowia na potrzeby samorządu województwa

VI.2.1. Systemy medyczne klasy HIS

VI.2.1.1. Zakres ramowy zadania cząstkowego

W tabeli wskazano zakres wdrożenia dla podmiotów w odniesieniu do poszczególnych modułów

opisanych w dalszej części rozdziału. Znak „X” w tabeli oznacza, że danym podmiocie należy wdrożyć

dany moduł.

Pozycja

SPZO

Z „P

rzyc

ho

dn

ia D

wo

rco

wa”

w G

orz

ow

ie W

ielk

op

ols

kim

, 66

-40

0 G

orz

ów

Wlk

p.,

ul.

Dw

orc

ow

a 1

3

Wo

jew

ód

zki O

śro

dek

Med

ycyn

y P

racy

, 66

-40

0 G

orz

ów

Wlk

p.,

ul.

Fab

rycz

na

71

Sam

od

ziel

na

Pu

blic

zna

Wo

jew

ód

zka

Stac

ja P

ogo

tow

ia R

atu

nko

weg

o, 6

6-4

00

Go

rzó

w W

lkp

., u

l. K

azim

ierz

a W

ielk

iego

7

Wie

losp

ecja

listy

czn

y Sz

pit

al W

oje

wó

dzk

i w G

orz

ow

ie W

lkp

. Sp

. z o

.o.,

66

-40

0 G

orz

ów

Wlk

p.,

ul.

Wal

czak

a 4

2

Sam

od

ziel

ny

Pu

blic

zny

Szp

ital

dla

Ner

wo

wo

i P

sych

iczn

ie C

ho

rych

, 66

-30

0 M

ięd

zyrz

ecz,

ul.

Po

znań

ska

10

9

Lub

usk

i Szp

ital

Sp

ecja

listy

czn

y P

ulm

on

olo

gicz

no

- K

ard

iolo

gicz

ny

Sam

od

ziel

ny

Pu

blic

zny

Zakł

ad O

pie

ki

Zdro

wo

tnej

, 66

-23

5 T

orz

ym, u

l. W

ojs

ka P

ols

kieg

o 5

2

Wo

jew

ód

zki S

zpit

al S

pec

jalis

tycz

ny

dla

Ner

wo

wo

i P

sych

iczn

ie C

ho

rych

Sam

od

ziel

ny

Pu

blic

zny

Zakł

ad

Op

ieki

Zd

row

otn

ej, 6

6-2

13

Cib

órz

5

Ośr

od

ek d

la O

sób

Uza

leżn

ion

ych

Sam

od

ziel

ny

Pu

blic

zny

Zakł

ad O

pie

ki Z

dro

wo

tnej

„N

ow

y D

wo

rek”

,

66

-20

0 N

ow

y D

wo

rek

46

;

Lub

usk

i Ośr

od

ek R

ehab

ilita

cyjn

o -

Ort

op

edyc

zny

im. d

r Le

cha

Wie

rusz

a SP

ZOZ,

66

-20

0 Ś

wie

bo

dzi

n, u

l.

Zam

kow

a 1

Wo

jew

ód

zka

Stac

ja P

ogo

tow

ia R

atu

nko

weg

o S

amo

dzi

eln

y P

ub

liczn

y Za

kład

Op

ieki

Zd

row

otn

ej, 6

5-

04

3 Z

ielo

na

Gó

ra, u

l. B

. Ch

rob

rego

2

Wo

jew

ód

zki O

śro

dek

Med

ycyn

y P

racy

, 65

-09

6 Z

ielo

na

Gó

ra, u

l. D

ąbró

wki

15

C

SP Z

OZ

„M

EDK

OL”

, 65

-02

0 Z

ielo

na

Gó

ra, u

l. P

lac

Ko

leja

rza

1

Wo

jew

ód

zki O

śro

dek

Ter

apii

Uza

leżn

ień

i W

spó

łuza

leżn

ien

ia, 6

5-0

44

Zie

lon

a G

óra

, ul.

Waz

ów

36

Szp

ital

Wo

jew

ód

zki S

PZO

Z w

Zie

lon

ej G

órz

e, 6

5-0

46

Zie

lon

a G

óra

, ul.

Zyty

26

SP Z

OZ

Cen

tru

m L

ecze

nia

Dzi

eci i

Mło

dzi

eży

w Z

abo

rze,

66

-00

3 Z

abó

r, u

l. Za

mko

wa

1

Wdrożenie systemu medycznego ambulatoryjnego (HIS) do 100 użytkowników X X X X X

Sprzedaż usług medycznych X X X X X

Rozliczenia z NFZ X X X

JGP X X X

Kolejki oczekujących X X X

Rejestracja X X X X X

Gabinet lekarski X X X X X

Statystyka X X X X X


Strona 51 z 208

Administracja/konfiguracja X X X X X

Raporty X X X X X

Pulpit użytkownika X

Weryfikacja uprawnień świadczeniobiorców X X X

VI.2.1.2. Licencjonowanie

Wymagana jest dostawa bezterminowej licencji uprawniającej do eksploatacji oprogramowania

aplikacyjnego HIS przez Uczestnika Projektu jednocześnie dla co najmniej następującej liczby

użytkowników bez ograniczeń w odniesieniu do liczby jednocześnie uruchomionych modułów:

Uczestnik Projektu Liczba

użytkowników

Samodzielny Publiczny Zakład Opieki Zdrowotnej „Przychodnia Dworcowa” w Gorzowie Wielkopolskim, 66-400 Gorzów Wlkp., ul. Dworcowa 13 53

Wojewódzki Ośrodek Medycyny Pracy, 66-400 Gorzów Wlkp., ul. Fabryczna 71 29

Wojewódzki Ośrodek Medycyny Pracy, 65-096 Zielona Góra, ul. Dąbrówki 15C 40

Samodzielny Publiczny Zakład Opieki Zdrowotnej „MEDKOL”, 65-020 Zielona Góra, ul. Plac Kolejarza 1 51

Samodzielny Publiczny Zakład Opieki Zdrowotnej Centrum Leczenia Dzieci i Młodzieży w Zaborze, 66-003 Zabór, ul. Zamkowa 1 74

Razem 247

Wykonawca dostarczy także licencję uprawniającą Uczestnika Projektu do eksploatacji

oprogramowania bazodanowego z którym współpracuje system HIS i licencja musi umożliwiać

jednoczesną pracę liczby użytkowników zgodną z dostarczoną licencją na system HIS lub na

instalację na serwerze opisanym w punkcie VI.3.2.15 bez ograniczania użytkowników.

W zależności od liczby wymaganych licencji Wykonawca jest zobowiązany dobrać rodzaj

wdrażanego oprogramowania uwzględniający wszystkie wymagania funkcjonalne.

Oprogramowanie, Oprogramowanie Systemowe, Oprogramowanie Narzędziowe oraz sprzęt

teleinformatyczny będą przez cały okres trwałości projektu własnością Zamawiającego (Urząd

Marszałkowski Województwa Lubuskiego) i bezpłatnie użyczone przez niego dla Uczestników

Projektu. Uczestnicy Projektu będą je eksploatować w okresie wdrożenia i trwałości Projektu. Po

zakończeniu okresu trwałości Projektu Oprogramowanie, Oprogramowanie Systemowe,

Oprogramowanie Narzędziowe oraz sprzęt teleinformatyczny zostanie formalnie przekazany do

Uczestników Projektu i stanie się ich własnością.


Strona 52 z 208

Wykonawca zobowiązany jest uwzględnić powyższe wymagania przy doborze odpowiedniego

sposobu licencjonowania oferowanego Oprogramowania, Oprogramowania Systemowego oraz

Oprogramowania Narzędziowego a także oprogramowania systemowego sprzętu

teleinformatycznego.

VI.2.1.3. Wymagania

W opisie wymagań przyjęto następującą konwencję:

wymagania, dla których w kolumnie „Typ” wpisano P są to wymagania, które oferowany

system musi posiadać obligatoryjnie na dzień składania ofert,

wymagania dla których w kolumnie „Typ” wpisano D są to wymagania, które oferowany

system może posiadać na dzień składania ofert – Wykonawca deklaruje spełnianie tych

wymagań przez oferowany system na dzień składania ofert w formularzu zgodnym ze wzorem

określonym w Załączniku nr 13 do SIWZ, wagi punktowe przypisane poszczególnym

wymaganiom zostały określone w Załączniku nr 13 do SIWZ.

Funkcjonalności typu P oraz typu D zostaną zweryfikowane podczas badania ofert w oparciu o

procedurę określoną w Załączniku nr 12 do SIWZ na podstawie deklaracji Wykonawcy złożonej wraz z

ofertą zgodnie ze wzorem określonym w Załączniku nr 13 do SIWZ.

VI.2.1.3.1. Wymagania ogólne

Nr wymagania

Wymaganie Typ

HIS.WO. 1 System ma interfejs graficzny dla wszystkich modułów P

HIS.WO. 2 System działa w architekturze trójwarstwowej P

HIS.WO. 3 System pracuje w środowisku graficznym MS Windows na stanowiskach użytkowników (preferowane środowisko MS Windows XP/Vista/7)

P

HIS.WO. 4 System komunikuje się z użytkownikiem w języku polskim. Jest wyposażony w system podpowiedzi (help). W przypadku oprogramowania narzędziowego i administracyjnego serwera bazy danych - częściowa komunikacja w języku angielskim

P

HIS.WO. 5 W funkcjach związanych z wprowadzaniem danych system udostępnia podpowiedzi, automatyczne wypełnianie pól, słowniki grup danych (katalogi leków, procedur medycznych, danych osobowych, terytorialnych).

P

HIS.WO. 6 - ręczne wyróżnienie w słownika pozycji najczęściej używanych Zapis usunięty przez Zamawiającego

P

HIS.WO. 7 Kontrola/parametryzacja Wielkich/małych liter. Możliwość ustawienia w wybranych polach jak ma być sformatowany wpis Zapis usunięty przez Zamawiającego

P

HIS.WO. 8 System zapewnia odporność struktur danych (baz danych) na uszkodzenia oraz pozwala na szybkie odtworzenie ich zawartości i właściwego stanu, jak również posiada łatwość wykonania ich kopii bieżących oraz łatwość odtwarzania z kopii. System jest wyposażony w zabezpieczenia przed nie-autoryzowanym dostępem. Zabezpieczenia funkcjonują na poziomie klienta (aplikacja) i serwera (serwer baz danych).

P

HIS.WO. 9 System jest wykonany w technologii klient-serwer, dane są przechowywane w modelu relacyjnym baz danych z wykorzystaniem aktywnego serwera baz danych.

P

HIS.WO. 10 Interfejs użytkownika jest dostępny z poziomu przeglądarki internetowej i nie wymaga instalowania żadnego oprogramowania na stacjach klienckich. Na dzień złożenia musi być dostęp do aplikacji przez WWW, co najmniej, w zakresie obsługi rejestracji, gabinetu lekarskiego, rozliczeń z NFZ i komercyjnej sprzedaży usług medycznych.

D

HIS.WO. 11 System musi umożliwić pracę z poziomu najbardziej popularnych przeglądarek, co najmniej MS Internet Explorer, Mozilla Firefox, Google Chrome i Opera.

D


Strona 53 z 208

Nr wymagania

Wymaganie Typ

HIS.WO. 12 Musi istnieć możliwość nadania użytkowni uprawnień do pracy wyłącznie w kontekście wybranej/ wybranych jednostek organizacyjnych.

P

HIS.WO. 13 System musi umożliwić zmianę jednostki organizacyjnej na której pracuje użytkownik bez konieczności wylogowywania się z systemu

P

HIS.WO. 14 System musi być wyposażony w zabezpieczenia przed nieautoryzowanym dostępem. Zabezpieczenia muszą funkcjonować na poziomie klienta (aplikacja) i serwera (serwer baz danych),

P

HIS.WO. 15 System musi posiadać mechanizmy umożliwiające zapis i przeglądanie danych o logowaniu użytkowników do systemu

P

HIS.WO. 16 System musi umożliwiać podgląd aktualnie zalogowanych do systemu użytkowników. P

HIS.WO. 17 System musi tworzyć i utrzymywać log systemu, rejestrujący wszystkich użytkowników systemu i wykonane przez nich najważniejsze czynności z możliwością analizy historii zmienianych wartości danych.

P

HIS.WO. 18 Administrator musi posiadać możliwość z poziomu aplikacji z modułu administratora nadawania danemu użytkownikowi unikalnego loginu oraz hasła. Administrator musi posiadać możliwość ustawienia parametrów hasła: długość, czas żywotności, czas przed wygaśnięciem

P

HIS.WO. 19 Administrator musi posiadać z poziomu aplikacji możliwość wylogowania wszystkich użytkowników aplikacji

P

HIS.WO. 20 W przypadku przechowywania haseł w bazie danych, hasła muszą być zapamiętane w postaci niejawnej (zaszyfrowanej).

P

HIS.WO. 21 Dane powinny być chronione przed niepowołanym dostępem przy pomocy mechanizmu uprawnień użytkowników. Każdy użytkownik systemu powinien 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. System uprawnień powinien być tak skonstruowany, aby można było użytkownikowi nadać uprawnienia z dokładnością do rodzaju wykonywanej operacji tj. osobne uprawnienie na odczyt danych i osobne na wprowadzanie/modyfikację danych. System uprawnień powinien umożliwiać definiowanie grup uprawnień, które to mogłyby być przydzielane poszczególnym użytkownikom.

P

HIS.WO. 22 Równolegle musi istnieć możliwość nadawania użytkownikowi pojedynczych uprawnień z listy dostępnych. System musi umożliwiać definiowanie grup użytkowników i przydzielanie użytkowników do tych grup.

P

HIS.WO. 23 System musi umożliwić nadanie użytkownikowi lub grupie użytkowników uprawnień do wydruku dokumentu

P

HIS.WO. 24 System powinien umożliwiać nadawanie uprawnień użytkownikom do jednostek organizacyjnych w których pracują, np. lekarz pracujący w poradni chirurgicznej i pracowni endoskopowej powinien w swoich aplikacjach widzieć tylko pacjentów tej poradni i pracowni.

P

HIS.WO. 25 System umożliwia administratorowi z poziomu aplikacji definiowanie i zmianę praw dostępu dla poszczególnych użytkowników i grup użytkowników z dokładnością do poszczególnych modułów oraz funkcji systemu

P

HIS.WO. 26 Wyróżnienie pól: P

HIS.WO. 27 - których wypełnienie jest wymagane, P

HIS.WO. 28 - przeznaczonych do edycji, P

HIS.WO. 29 - wypełnionych niepoprawnie P

HIS.WO. 30 System umożliwia wykonanie nowej operacji w systemie bez konieczności przerywania czynności dotychczas wykonywanej (np. obsługa zdarzenie w trybie nagłym) i powrót do zawieszonej czynności bez utraty danych, kontekstu itp. bez konieczności ponownego uruchamiania aplikacji i wykorzystania licencji z puli dostępnych.

D

HIS.WO. 31 Wszystkie błędy niewypełnienia pól obligatoryjnych oraz błędnego wypełnienia powinny być sygnalizowane z możliwością szybkiego przejścia do miejsca aplikacji, gdzie te błędy wystąpiły.

P

HIS.WO. 32 System powinien umożliwić obsługę procesów biznesowych realizowanych w szpitalu tzn powinien Zapis usunięty przez Zamawiającego

P

HIS.WO. 33 - pokazywać tylko to, co w danym momencie jest najważniejsze, Zapis usunięty przez Zamawiającego

P

HIS.WO. 34 - udostępniać tylko te zadania, które na danym etapie powinny zostać wykonane, Zapis usunięty przez Zamawiającego

P

HIS.WO. 35 - umożliwić wprowadzenie tylko tych danych, które są niezbędne, Zapis usunięty przez Zamawiającego

P

HIS.WO. 36 - podpowiadać kolejne kroki procesu. Zapis usunięty przez Zamawiającego P

HIS.WO. 37 System powinien automatycznie wylogowywać lub blokować sesję użytkownika po zadanym czasie braku aktywności

P

HIS.WO. 38 System powinien wyświetlać czas pozostały do wylogowania (zablokowania) użytkownika P


Strona 54 z 208

Nr wymagania

Wymaganie Typ

HIS.WO. 39 Co najmniej w części medycznej użytkownik po zalogowaniu powinien widzieć pulpit zawierający wszystkie funkcje i moduły dostępne dla tego użytkownika

P

HIS.WO. 40 W systemie musi zostać zachowana zasada jednokrotnego wprowadzania danych. Wymiana danych pomiędzy modułami musi odbywać się na poziomie bazy danych

P

HIS.WO. 41 „Dostarczone oprogramowanie musi zagwarantować pełną integrację z systemem finansowo-księgowym dostarczanym przez Wykonawcę. Przekazywanie danych musi odbywać się automatycznie i na bieżąco bez konieczności wykonywania dodatkowych operacji przez użytkownika lub administratora. Wykonawca zobowiązany jest do integracji systemu HIS i ERP wyłącznie w trzech jednostkach, w których wdrażane są oba systemy: HIS i ERP, tj. • SPZOZ „Przychodnia Dworcowa" w Gorzowie Wielkopolskim, 66-400 Gorzów Wlkp., ul. Dworcowa 13 • Wojewódzki Ośrodek Medycyny Pracy, 65-096 Zielona Góra, ul. Dąbrówki 15C • SP ZOZ „MEDKOL", 65-020 Zielona Góra, ul. Plac Kolejarza 1”

P

HIS.WO. 42 System powinien zawierać wbudowany komunikator umożliwiający wymianę wiadomości pomiędzy użytkownikami. Zapis usunięty przez Zamawiającego

P

HIS.WO. 43 Komunikator musi umożliwić wysłanie wiadomości do: Zapis usunięty przez Zamawiającego P

HIS.WO. 44 - pracowników jednostki organizacyjnej Zapis usunięty przez Zamawiającego P

HIS.WO. 45 - wskazanego użytkownika Zapis usunięty przez Zamawiającego P

HIS.WO. 46 - użytkowników pełniących określoną funkcję (lekarze, pielęgniarki) Zapis usunięty przez Zamawiającego

P

HIS.WO. 47 - użytkowników wskazanego modułu Zapis usunięty przez Zamawiającego P

HIS.WO. 48 możliwość łączenia w/w grup adresatów Zapis usunięty przez Zamawiającego P

HIS.WO. 49 Musi istnieć możliwość nadania wiadomości statusu: zwykła, ważna, wymagająca potwierdzenia Zapis usunięty przez Zamawiającego

P

HIS.WO. 50 System powinien umożliwić definiowanie wiadomości, których wysłanie jest inicjowane zdarzeniem np. zlecenie leku, badania, wynik badania, zamówienie na lek do apteki. Zapis usunięty przez Zamawiającego

P

HIS.WO. 51 Wiadomości mogą być wysyłane przez użytkowników systemu Zapis usunięty przez Zamawiającego

P

HIS.WO. 52 Wiadomości powinny mieć określony termin obowiązywania podawany z dokładnością do godziny Zapis usunięty przez Zamawiającego

P

HIS.WO. 53 W każdym oknie, gdzie możliwa jest edycja powinien znajdować się klawisz <cofnij> lub <anuluj> powodujący powrót do poprzedniego okna bez zapisu danych

P

HIS.WO. 54 Musi istnieć możliwość obsługi aplikacji wyłącznie przy użyciu klawiatury, bez konieczności używania myszki

P

HIS.WO. 55 W każdym polu edycyjnym(opisowym) tj np. treść wywiadu powinna istnieć możliwość wybrania i skorzystania z dowolnego formularza, tekstu standardowego lub wczytania tekstu zapisanego w pliku zewnętrznym. Powinna również w tych miejscach istnieć możliwość zapisu do zewnętrznego pliku przygotowanego tekstu oraz powinny być udostępnione podstawowe narzędzia ułatwiające edycję np. kopiuj/wklej.

P

HIS.WO. 56 System powinien umożliwić przypisanie do komórki organizacyjnej jednostki, kodu technicznego NFZ. Powinna istnieć możliwość zmiany tego kodu w dowolnym momencie pracy systemu.

P

HIS.WO. 57 System musi umożliwić określenie jednostkom organizacyjnym oddzielnego numeru REGON, innego niż REGON zakładu opieki zdrowotnej

P

HIS.WO. 58 System powinien umożliwiać sprawdzanie poprawności pisowni w polach opisowych tj opis badania, wynik, epikryza

P

HIS.WO. 59 System musi umożliwiać automatyczną obsługę żądań przekazania danych do Centralnej Aplikacji BI zgodnie ze specyfikacją interfejsu wymiany danych opracowanego przez Wykonawcę w ramach Centralnej Aplikacji BI.

P

VI.2.1.3.2. Sprzedaż usług medycznych

Nr wymagania

Wymaganie Typ

HIS.SUM. 1 formułowanie oferty sprzedaży Uczestnika Projektu: P

HIS.SUM. 2 wprowadzanie struktury placówek medycznych Uczestnika Projektu, P

HIS.SUM. 3 wprowadzanie listy usług (oferta jednostek organizacyjnych), P

HIS.SUM. 4 wprowadzenie danych usługi: P


Strona 55 z 208

Nr wymagania

Wymaganie Typ

HIS.SUM. 5 - wymagalność skierowania, P

HIS.SUM. 6 - warunki dostępności, P

HIS.SUM. 7 - kody w umowach w zależności od płatnika np. przekodowanie usługi na kod używany w innej umowie z innym płatnikiem.

P

HIS.SUM. 8 - kody świadczeń NFZ . P

HIS.SUM. 9 grupowanie usług, D

HIS.SUM. 10 wprowadzanie cenników: D

- Okres obowiązywania,

- Godziny dostępności,

- Możliwość definicji cenników standardowych i specjalnych (np. na dni świąteczne),

- Miejsca realizacji, - Możliwość przyporządkowania cennika do personelu, Zapis usunięty przez Zamawiającego.

HIS.SUM. 11 obsługa skorowidza pacjentów D

HIS.SUM. 12 konstruowanie produktów (szablonów do wykorzystania w umowach) D

HIS.SUM. 13 wprowadzanie danych podstawowych produktu D

HIS.SUM. 14 wprowadzanie zakresów usług medycznych w ramach produktu D

HIS.SUM. 15 wprowadzanie usług medycznych w ramach zakresu D

HIS.SUM. 16 ewidencja i obsługa umów D

HIS.SUM. 17 obsługa umów na sprzedaż usług medycznych: D

HIS.SUM. 18 ewidencja różnego typu umów: P

HIS.SUM. 19 - umowy NFZ (w tym POZ) P

HIS.SUM. 20 - umowy ubezpieczeniowe, D

HIS.SUM. 21 - umowy abonamentowe (w tym Medycyny Pracy), D

HIS.SUM. 22 - umowy z innymi ZOZ-ami, Indywidualnymi Praktykami Lekarskimi, D

HIS.SUM. 23 wprowadzanie danych podstawowych umowy, P

HIS.SUM. 24 przypisywanie produktu do umowy, D

HIS.SUM. 25 definiowanie rabatów dla umowy, D

HIS.SUM. 26 definiowanie wzorów faktur i załączników do faktur dla umowy, D

HIS.SUM. 27 rozliczenia umów D

HIS.SUM. 28 automatyczne rozliczenia umów: P

HIS.SUM. 29 - rozliczenia NFZ w poszczególnych zakresach P

HIS.SUM. 30 - generowanie harmonogramów płatności umowy w oparciu o dane zakresów umowy, P

HIS.SUM. 31 możliwość współpracy z modułem Finanse-Księgowość: P

HIS.SUM. 32 raporty i wykazy dotyczące sprzedaży Punkt wykreślony przez Zamawiającego P

VI.2.1.3.3. Rozliczenia z NFZ

Nr wymagania

Wymaganie Typ

HIS.NFZ. 1 Zarządzanie umowami NFZ P

HIS.NFZ. 2 Import pliku umowy w postaci komunikatu UMX, P

HIS.NFZ. 3 Przegląd i modyfikacja szczegółów umowy: P

HIS.NFZ. 4 - Okres obowiązywania umowy, P

HIS.NFZ. 5 - Pozycje planu umowy, P

HIS.NFZ. 6 - Miejsca realizacji świadczeń P

HIS.NFZ. 7 - Limity na realizację świadczeń i ceny jednostkowe, P

HIS.NFZ. 8 - Słowniki związane z umowami (słownik zakresów świadczeń, świadczeń jednostkowych, pakietów świadczeń, schematów leczenia itd.)

P

HIS.NFZ. 9 - Parametry pozycji pakietów świadczeń P

HIS.NFZ. 10 Moduł korzysta bezpośrednio z danych zaewidencjonowanych w poradniach bez konieczności importu i kopiowania danych

P

HIS.NFZ. 11 Weryfikacja wprowadzonych pozycji rozliczeniowych pod kątem zgodności ze stanem, po wczytaniu aneksu umowy (ze wstecznym okresem obowiązywania). Możliwość zbiorczej modyfikacji pozycji rozliczeniowych, w których znaleziono różnice

P

HIS.NFZ. 12 - Różnica w cenie świadczenia, P

HIS.NFZ. 13 - Różnica w wadze efektywnej świadczenia, P

HIS.NFZ. 14 - Różnica w sposobie obliczania krotności i okresu sprawozdawczego, P

HIS.NFZ. 15 Definiowanie dodatkowych walidacji P

HIS.NFZ. 16 - Liczba realizacji świadczeń w okresie, P

HIS.NFZ. 17 - Liczba realizacji świadczeń w ramach zakresu w okresie, P

HIS.NFZ. 18 Możliwość ewidencji i rozliczenia realizowanych świadczeń P


Strona 56 z 208

Nr wymagania

Wymaganie Typ

HIS.NFZ. 19 - Ubezpieczonym, P

HIS.NFZ. 20 - Nieubezpieczonym a uprawnionym do świadczeń, P

HIS.NFZ. 21 - Uprawnionym na podstawie decyzji wójta/burmistrza P

HIS.NFZ. 22 - Uprawnionym na podstawie przepisów o koordynacji, P

HIS.NFZ. 23 - Uprawnionym na podstawie Karty Polaka P

HIS.NFZ. 24 - Kobietom w ciąży, w okresie połogu oraz młodzieży do 18 roku życia P

HIS.NFZ. 25 Możliwość zbiorczej modyfikacji pozycji rozliczeniowych w zakresie zmian dotyczących P

HIS.NFZ. 26 - Numeru umowy, P

HIS.NFZ. 27 - Zakresu świadczeń, P

HIS.NFZ. 28 - Wyróżnika P

HIS.NFZ. 29 - Świadczenia jednostkowego, P

HIS.NFZ. 30 Możliwość wprowadzenia dodatkowego poziomu kontroli wprowadzonych świadczeń poprzez funkcjonalność autoryzacji świadczeń przez osobę uprawnioną

P

HIS.NFZ. 31 Przegląd informacji o posiadanych przez pacjenta uprawnieniach do świadczeń w każdym dniu pobytu P

HIS.NFZ. 32 Po otrzymaniu informacji z NFZ, uprawniony użytkownik działu rozliczeń musi mieć możliwość modyfikacji danych

P

HIS.NFZ. 33 Sprawozdawczość z do oddziałów NFZ w zakresie komunikacji przez pocztę elektroniczną musi odbywać się automatycznie, z poziomu systemu HIS

P

HIS.NFZ. 34 W przypadku komunikatów, w których NFZ wymaga kompresowania lub szyfrowania danych, operacje te muszą odbywać się automatycznie w systemie HIS

P

HIS.NFZ. 35 System musi umożliwić harmonogramowanie eksportów danych: o wyznaczonej godzinie, co określoną liczbę godzin, za określoną liczbę godzin

P

HIS.NFZ. 36 Weryfikacja zestawów świadczeń pod kątem poprawności i kompletności wprowadzonych danych P

HIS.NFZ. 37 Wyszukiwanie pozycji błędnie potwierdzonych w komunikatach zwrotnych NFZ P

HIS.NFZ. 38 Wyszukiwanie po numerach w księgach P

HIS.NFZ. 39 Wyszukiwanie zestawów bez zaewidencjonowanych procedur ICD9 P

HIS.NFZ. 40 Wyszukiwanie zestawów po numerze paczki, w której wyeksportowano dane do NFZ P

HIS.NFZ. 41 Wyszukiwanie po instytucji kierującej P

HIS.NFZ. 42 Wyszukiwanie po personelu kierującym/ realizującym P

HIS.NFZ. 43 Wyszukiwanie zestawów bez pozycji rozliczeniowych P

HIS.NFZ. 44 Wyszukiwanie zestawów z niekompletnymi danymi rozliczeniowymi P

HIS.NFZ. 45 Wyszukiwanie pozycji rozliczeniowych, które nie zostały jeszcze rozliczone P

HIS.NFZ. 46 Wyszukiwanie po statusie rozliczenia P

HIS.NFZ. 47 Wyszukiwanie zestawów zawierających rozliczenia ze wskazanej umowy P

HIS.NFZ. 48 Wyszukiwanie zestawów zawierających wskazane świadczenie jednostkowe P

HIS.NFZ. 49 Wyszukiwanie zestawów świadczeń z JGP wyznaczoną w zadanej wersji P

HIS.NFZ. 50 Wyszukiwanie zestawów świadczeń ratujących życie i zdrowie P

HIS.NFZ. 51 Wyszukiwanie zestawów świadczeń zrealizowanych dla wybranych uprawnień pacjenta P

HIS.NFZ. 52 Wyszukiwanie świadczeń, które zostały skorygowane, a informacja o skorygowaniu nie została sprawozdana do systemu NFZ

P

HIS.NFZ. 53 Generowanie i eksport komunikatu fazy I (komunikat SWIAD) w aktualnie obowiązującej wersji publikowanej przez płatnika

P

HIS.NFZ. 54 Import potwierdzeń do danych przekazanych w komunikacie I fazy (komunikat P_SWI) P

HIS.NFZ. 55 Import danych z pliku z szablonami rachunków (komunikat R_UMX) P

HIS.NFZ. 56 Eksport komunikatów związanych ze sprawozdawczością POZ P

HIS.NFZ. 57 - Eksport komunikatu DEKL – informacje o deklaracjach P

HIS.NFZ. 58 - Eksport komunikatu ZBPOZ – informacje o świadczeniach zrealizowanych w ramach POZ P

HIS.NFZ. 59 Import potwierdzeń związanych ze sprawozdawczością POZ P

HIS.NFZ. 60 - Import komunikatu P_DEK – potwierdzenia danych dla przesłanych deklaracji P

HIS.NFZ. 61 - Import komunikatu Z_WDP – wyniki weryfikacji deklaracji P

HIS.NFZ. 62 - Import komunikatu Z_RDP – rozliczenia deklaracji P

HIS.NFZ. 63 Eksport komunikatów związanych ze sprawozdawczością kolejek oczekujących P

HIS.NFZ. 64 - Eksport komunikatu LIOCZ – informacje o statystykach kolejek oczekujących P

HIS.NFZ. 65 - Eksport komunikatu KOL – informacje o oczekujących na świadczenia wysokospecjalistyczne P

HIS.NFZ. 66 Import potwierdzeń związanych ze sprawozdawczością kolejek oczekujących P

HIS.NFZ. 67 Import komunikatu P_LIO – potwierdzenie statystyk przekazanych w komunikacie LIOCZ P

HIS.NFZ. 68 Przegląd szablonów rachunków wygenerowanych i przekazanych przez płatnika P

HIS.NFZ. 69 Generowanie i wydruk rachunków na podstawie szablonów P

HIS.NFZ. 70 Generowanie i wydruk faktur na podstawie rachunków P

HIS.NFZ. 71 Generowanie i wydruk zestawień i raportów związanych ze sprawozdawczością wewnętrzną (możliwość śledzenia postępów wykonania zakontraktowanych świadczeń w ciągu trwania okresu rozliczeniowego)

P

HIS.NFZ. 72 Raport z wykonanych świadczeń z możliwością ograniczenia danych do m.in.: P


Strona 57 z 208

Nr wymagania

Wymaganie Typ

HIS.NFZ. 73 - Numeru umowy, P

HIS.NFZ. 74 - Zakresu miesięcy sprawozdawczych, P

HIS.NFZ. 75 - Miesiąca rozliczeniowego, P

HIS.NFZ. 76 - Jednostki realizującej, P

HIS.NFZ. 77 - Zakresu świadczeń i wyróżnika, P

HIS.NFZ. 78 - Świadczenia, P

HIS.NFZ. 79 - Numeru szablonu P

HIS.NFZ. 80 - Uprawnienia pacjenta do świadczeń P

HIS.NFZ. 81 Zestawienie z realizacji planu umowy, P

HIS.NFZ. 82 Zestawienie wykonań przyrostowo, P

HIS.NFZ. 83 Zestawienie wykonań według miejsc realizacji P

HIS.NFZ. 84 Sprawozdanie rzeczowe powinno zawierać następujące informacje nagłówkowe: - świadczeniodawca (nazwa i adres) - numer umowy - okres, którego dotyczy sprawozdanie oraz w ujęciu tabelarycznym: - datę wykonanego świadczenia, - PESEL pacjenta, - miejsce zamieszkania pacjenta (nazwa miejscowości), - kod produktu, - wyróżnik, - nazwa produktu, - kod produktu jednostkowego, - rozpoznanie wg klasyfikacji ICD-10, - cena jednostkowa, - wartość świadczenia,

P

HIS.NFZ. 85 Eksport danych do popularnych formatów (XLS, TXT, CSV, HTML) P

HIS.NFZ. 86 Generowanie i wydruk dokumentów związanych ze sprawozdawczością wymaganą przez OW NFZ P

HIS.NFZ. 87 Sprawozdanie finansowe powinno zawierać następujące informacje nagłówkowe: - świadczeniodawca (nazwa i adres) - numer umowy - okres, którego dotyczy sprawozdanie oraz w ujęciu tabelarycznym: - kod produktu, nazwa produktu i wyróżnik - wartości zakontraktowane: liczba produktów w okresie obowiązywania, stawka jednostkowa w okresie obowiązywania, maksymalna wartość finansowania w okresie obowiązywania, - rozliczenie miesięczne: liczba zrealizowana w okresie, wartość zrealizowana w okresie (miesiącu), - rozliczenie narastająco: plan do realizacji od początku obowiązywania umowy, liczba zrealizowana od początku obowiązywania umowy, wartość zrealizowana od początku obowiązywania umowy Sprawozdanie musi być generowane z dokładnością do roku i miesiąca sprawozdawczego oraz umowy z uwzględnieniem okresów rozliczeniowych umowy. System musi mieć możliwość generacji sprawozdania dla wskazanego szablonu rachunku (w takiej sytuacji na wydruku powinien pojawić się także identyfikator szablonu).

P

HIS.NFZ. 88 Zestawienie świadczeń udzielonych świadczeniobiorcom innym niż ubezpieczeni, P

HIS.NFZ. 89 Zestawienie świadczeń wykonanych pacjentom na podstawie przepisów o koordynacji (UE), P

HIS.NFZ. 90 Zestawienie świadczeń wykonanych pacjentom na podstawie art. 2 ust. 1 ustawy (decyzja wójta/burmistrza), P

HIS.NFZ. 91 Zestawienie świadczeń wykonanych pacjentom nieubezpieczonym, rozliczanym na podstawie art. 12 lub art. 13 ustawy

P

HIS.NFZ. 92 Automatyczne wyliczanie kosztów porady u pacjenta nieubezpieczonego P

HIS.NFZ. 93 Załączniki do umów POZ P

HIS.NFZ. 94 Obsługa sprawozdawczości w zakresie POZ P

HIS.NFZ. 95 Integracja z innymi modułami systemu P

HIS.NFZ. 96 - ewidencja pozycji rozliczeniowych w Przychodni P

HIS.NFZ. 97 Eksport faktur rozliczeniowych do modułu Finansowo-Księgowego; dotyczy wyłącznie trzech podmiotów, w których wdrażane są oba systemy HIS i ERP tj.: - SPZOZ „Przychodnia Dworcowa" w Gorzowie Wielkopolskim, 66-400 Gorzów Wlkp., ul. Dworcowa 13 - Wojewódzki Ośrodek Medycyny Pracy, 65-096 Zielona Góra, ul. Dąbrówki 15C - SP ZOZ „MEDKOL", 65-020 Zielona Góra, ul. Plac Kolejarza 1

P

VI.2.1.3.4. JGP


Strona 58 z 208

Nr wymagania

Wymaganie Typ

HIS.JGP.1 Wyznaczanie Jednorodnych Grup Pacjentów na podstawie danych wizyty za pomocą wbudowanego grupera JGP

P

HIS.JGP.2 Import aktualnego słownika procedur medycznych ICD9 (komunikat ICD9), P

HIS.JGP.3 Zapewnienie sprawnego zasilania systemu w aktualne charakterystyki JGP wynikające z publikowanych Zarządzeń Prezesa NFZ

P

HIS.JGP.4 Wyznaczanie JGP za pomocą wbudowanego (lokalnego) grupera JGP w zakresie umów ambulatoryjna opieka specjalistyczna

P

HIS.JGP.5 Możliwość ręcznego wyznaczenia JGP P

HIS.JGP.6 Wsteczna weryfikacja poprawności wyznaczonych wcześniej JGP z możliwością automatycznej aktualizacji JGP na poprawną

P

HIS.JGP.7 Różnice wynikające z wczytania nowych wersji grupera, które opublikowano z wsteczną datą obowiązywania, które mogą obejmować

P

HIS.JGP.8 - Różnice w zaewidencjonowanych taryfach, P

HIS.JGP.9 - Różnice w zaewidencjonowanych JGP, P

HIS.JGP.10 Różnice wynikające z modyfikacji danych statystycznych i mające wpływ na wyznaczoną JGP: P

HIS.JGP.11 - Konieczność zmiany JGP, P

HIS.JGP.12 - Konieczność zmiany taryfy, P

VI.2.1.3.5. Kolejki oczekujących

Nr wymagania

Wymaganie Typ

HIS.KO. 1 Definicja kolejek oczekujących zgodnie z wymaganiami płatnika P

HIS.KO. 2 Kolejki oczekujących do komórek organizacyjnych P

HIS.KO. 3 Kolejki oczekujących do procedur medycznych lub świadczeń wysokospecjalistycznych zdefiniowanych przez płatnika

P

HIS.KO. 4 Prowadzenie kolejek oczekujących P

HIS.KO. 5 Wykaz osób oczekujących w kolejce P

HIS.KO. 6 Możliwość planowania daty z dokładnością do dnia lub tygodnia (w przypadku odległego terminu realizacji świadczenia)

P

HIS.KO. 7 Przyporządkowanie oczekujących do jednej z kategorii medycznych (przypadki pilne/przypadki stabilne) P

HIS.KO. 8 Rejestrowanie przypadków zmian terminu udzielenia świadczenia wraz z przyczyną zmiany P

HIS.KO. 9 Możliwość zbiorczego przenoszenia oczekujących pomiędzy kolejkami P

HIS.KO. 10 - Wszystkich aktywnych pozycji P

HIS.KO. 11 - Wybranych oczekujących P

HIS.KO. 12 Wskazanie tych definicji kolejek oczekujących, które po wczytaniu aneksu do umowy posiadają nieaktualne informacje o kodzie komórki wg NFZ wraz z możliwością automatycznej aktualizacji kodu komórki wg NFZ na podstawie aktualnych zapisów w umowie z NFZ

P

HIS.KO. 13 Generowanie statystyk kolejek z podziałem na przypadki pilne i stabilne P

HIS.KO. 14 - Liczba oczekujących P

HIS.KO. 15 - Szacunkowy czas oczekiwania w kolejce P

HIS.KO. 16 - Średni rzeczywisty czas oczekiwania w kolejce (zgodnie z algorytmem opublikowanym w rozporządzeniu) P

HIS.KO. 17 Generowanie i eksport komunikatów XML w aktualnie obowiązujących wersjach z zakresu sprawozdawczości związanej z kolejkami oczekujących

P

HIS.KO. 18 Komunikat LIOCZ – komunikat szczegółowy o kolejkach oczekujących P

HIS.KO. 19 Komunikat KOL – komunikat o kolejkach oczekujących do świadczeń wysokospecjalistycznych P

HIS.KO. 20 Import komunikatu „potwierdzeń odbioru” danych o kolejkach oczekujących P

HIS.KO. 21 Wydruk listy oczekujących z uwzględnieniem poniższych kryteriów P

HIS.KO. 22 - Rodzaj kolejki (do komórki organizacyjnej, do procedury medycznej/świadczenia wysokospecjalistycznego) P

HIS.KO. 23 - Kod kolejki P

HIS.KO. 24 - Stan wpisu w kolejce (aktywne, wykreślone, zakończone realizacją) P

HIS.KO. 25 - Kategoria medyczna (pilny, stabilny) P

HIS.KO. 26 - Data wpisu (od .. do ..) P

HIS.KO. 27 - Data planowanej realizacji (od .. do ..) P

HIS.KO. 28 - Data skreślenia z kolejki (od .. do ..) P

VI.2.1.3.6. Rejestracja


Strona 59 z 208

Nr wymagania

Wymaganie Typ

HIS.REJ. 1 Definiowanie dostępności usług placówki medycznej P

HIS.REJ. 2 Wprowadzanie cenników: D

- określanie dat obowiązywania cennika,

- określanie zakresu usług dla cennika,

- określanie cen usług,

- możliwość określenia cen widełkowych dla usługi,

- możliwość określenia zaliczki wymaganej przed wykonaniem usługi.

HIS.REJ. 3 Określanie dostępności zasobów w placówce (grafiki): P

HIS.REJ. 4 Definiowanie szablonu pracy zasobu typu gabinet : P

HIS.REJ. 5 - określenie szablonu dla każdego z dni tygodnia, P

HIS.REJ. 6 - określenie czasu pracy gabinetu, P

HIS.REJ. 7 - określenie zakresu usług realizowanych w gabinecie P

HIS.REJ. 8 - określanie ograniczeń grafika dla instytucji kierującej (płatnika), jednostki zlecającej, ilości wykonywanych usług,

P

HIS.REJ. 9 Definiowanie szablonu pracy zasobu typu lekarz: P

HIS.REJ. 10 - określenie szablonu dla każdego z dni tygodnia, P

HIS.REJ. 11 - określenie czasu pracy, P

HIS.REJ. 12 - określenie zakresu usług realizowanych przez lekarza, P

HIS.REJ. 13 - określenie gabinetu, w którym wykonywane są usługi (miejsce wykonania). P

HIS.REJ. 14 - generacja grafików dla lekarzy w powiązaniu z gabinetami w zadanym okresie czasu, P

HIS.REJ. 15 - blokada grafików (urlopy, remonty). P

HIS.REJ. 16 Obsługa skorowidza pacjentów P

HIS.REJ. 17 - możliwość przypisania pacjentowi uprawnień do obsługi poza kolejnością P

HIS.REJ. 18 - prezentacja uprawnienia do obsługi poza kolejnością na listach pacjentów P

HIS.REJ. 19 Wyszukiwanie pacjentów, co najmniej, wg kryterium: P

HIS.REJ. 20 - imię, nazwisko i PESEL pacjenta P

HIS.REJ. 21 - jednostka wykonująca P

HIS.REJ. 22 - osoba wykonująca P

HIS.REJ. 23 - osoba rejestrująca P

HIS.REJ. 24 - jednostka kierująca P

HIS.REJ. 25 - instytucja kierująca P

HIS.REJ. 26 - lekarz kierujący P

HIS.REJ. 27 - kartoteka P

HIS.REJ. 28 - identyfikator pacjenta P

HIS.REJ. 29 - świadczenie P

HIS.REJ. 30 - status na liście pacjentów (np.do obsłużenia, zaplanowany, zarejestrowany, anulowane, przyjęty/w realizacji) P

HIS.REJ. 31 - wizyty CITO P

HIS.REJ. 32 - status osoby: cudzoziemiec, VIP, uprawniony do obsługi poza kolejnością P

HIS.REJ. 33 Planowanie i rezerwacja wizyty pacjenta P

HIS.REJ. 34 Wyszukiwanie wolnych terminów jednoczesnej dostępności wymaganych zasobów: P

HIS.REJ. 35 - rezerwacja wybranego terminu lub „pierwszy wolny”. P

HIS.REJ. 36 - prezentowanie preferowanych terminów wykonania usługi dla zgłoszeń internetowych na zasadzie określenia godzin przeznaczonych do planowania zgłoszeń internetowych np. od 10 do 12

P

HIS.REJ. 37 - automatyczna rezerwacja terminów dla zgłoszeń internetowych wg preferencji pacjenta P

HIS.REJ. 38 - w przypadku braku wolnych terminów w preferowanych godzinach możliwość rezerwacji pierwszy wolny lub ręczny wybór terminu

P

HIS.REJ. 39 - rezerwacja terminów dla pacjentów przebywających na oddziale P

HIS.REJ. 40 - wstawianie terminu pomiędzy już istniejące wpisy w grafiku w przypadkach nagłych P

HIS.REJ. 41 - przegląd liczby zaplanowanych wizyt z podziałem na pierwszorazowe i kontynuacje leczenia P

HIS.REJ. 42 Przegląd rezerwacji P

HIS.REJ. 43 Rejestracja pacjenta do wykonania usługi P

HIS.REJ. 44 Nadanie numeru rezerwacji w ramach rejestracji i jednostki wykonującej (gabinetu) P

HIS.REJ. 45 Automatyczne wyliczanie kosztów porady u pacjenta nieubezpieczonego D

HIS.REJ. 46 Określenie miejsca wykonania usługi (wybór gabinetu) dla usług nie podlegających planowaniu i rezerwacji. P

HIS.REJ. 47 Zlecenie wykonania usługi pacjentowi we wskazanym (lub wynikającym z rezerwacji) miejscu wykonania, P

HIS.REJ. 48 Możliwość wykorzystania szablonów zleceń złożonych, P

HIS.REJ. 49 Obsługa kolejek oczekujących zgodnie z obowiązującymi przepisami, P

HIS.REJ. 50 Obsługa wyników: P

HIS.REJ. 51 - odnotowanie wydania wyniku, P

HIS.REJ. 52 - wpisywanie wyników zewnętrznych. P

HIS.REJ. 53 Wydruk recept i kuponów P


Strona 60 z 208

Nr wymagania

Wymaganie Typ

HIS.REJ. 54 raporty i wykazy Rejestracji. P

VI.2.1.3.7. Gabinet lekarski

Nr wymagania

Wymaganie Typ

HIS.GL. 1 dostęp do listy pacjentów zarejestrowanych do gabinetu P

HIS.GL. 2 - prezentacja uprawnienia do obsługi poza kolejnością P

HIS.GL. 3 rejestracja rozpoczęcia obsługi wizyty pacjenta w gabinecie (przyjęcie) P

HIS.GL. 4 wspomaganie obsługi pacjenta w gabinecie: P

HIS.GL. 5 przegląd danych pacjenta w następujących kategoriach: P

HIS.GL. 6 - dane osobowe, P

HIS.GL. 7 - podstawowe dane medyczne (grupa krwi, uczulenia, stale podawane leki, przebyte choroby, karta szczepień), P

HIS.GL. 8 - uprawnienia z tytułu umów, P

HIS.GL. 9 - Historia leczenia (dane ze wszystkich wizyt i pobytów szpitalnych pacjenta), P

HIS.GL. 10 - wyniki badań, P

HIS.GL. 11 - przegląd rezerwacji. P

HIS.GL. 12 obsługa pobytów wielodniowych P

HIS.GL. 13 obsługa domowego leczenia żywieniowego P

HIS.GL. 14 obsługa tlenoterapii w warunkach domowych P

HIS.GL. 15 możliwość użytkowania zdefiniowanych wcześniej wzorców dokumentacji dedykowanej do wizyty P

HIS.GL. 16 możliwość zdefiniowania elementów menu (zakładek) w zależności od potrzeb i rodzaju usługi P

HIS.GL. 17 możliwość zdefiniowania wzorów dokumentów dedykowanych dla gabinetu P

HIS.GL. 18 przegląd, wprowadzanie i modyfikacja danych wizyty w następujących kategoriach: P

HIS.GL. 19 - wywiad (na formularzu zdefiniowanym dla wizyty), P

HIS.GL. 20 - opis badania (na formularzu zdefiniowanym dla wizyty), P

HIS.GL. 21 - informacje ze skierowania, P

HIS.GL. 22 - kontrola daty ważności skierowania P

HIS.GL. 23 - możliwość przepisania skierowania już zarejestrowanego P

HIS.GL. 24 - skierowania, z możliwością skopiowania danych z innego pobytu w tej lub innej jednostce P

HIS.GL. 25 - usługi, świadczenia w ramach wizyty, P

HIS.GL. 26 - rozpoznanie (główne, dodatkowe), P

HIS.GL. 27 - kopiowanie wyników badania i danych wypisowych z poprzednich wizyt P

HIS.GL. 28 - zalecenia z wizyty (w tym zwolnienia lekarskie), P

HIS.GL. 29 - leki przepisane wg słownika leków, recepty (z rozmieszczaniem i nadrukiem na formularzach recept), P

HIS.GL. 30 - podczas wystawiania recepty możliwość sprawdzenia interakcji poszczególnych leków oraz podpowiadanie stopnia refundacji na podstawie weryfikacji z eWUŚ

P

HIS.GL. 31 - podczas wystawiania recepty podpowiadanie ilości i jednostki, w jakich powinien zostać wydany lek P

HIS.GL. 32 - kopiowanie recept z poprzednich wizyt z weryfikacją poziomu refundacji wg aktualnych danych ze słownika BAZYL lub słownika leków własnych

P

HIS.GL. 33 - wystawione skierowania, P

HIS.GL. 34 - ewidencja szczepień: P

HIS.GL. 35 - możliwość oznaczenia podania leku jako szczepienia, P

HIS.GL. 36 - możliwość wpisania przy podaniu leku danych charakteryzujących szczepienie, P

HIS.GL. 37 - automatyczny wpis do karty szczepień po oznaczeniu podania leku jako szczepienia. P

HIS.GL. 38 - wykonane podczas wizyty dodatkowych usług i badania P

HIS.GL. 39 - inne dokumenty (zaświadczenia, druki, na formularzach zdefiniowanych dla wizyty). P

HIS.GL. 40 możliwość stosowania słownika tekstów standardowych do opis danych wizyt P

HIS.GL. 41 Możliwość stosowania „pozycji preferowanych” dla użytkowników, jednostek organizacyjnych (wyróżnienie najczęściej wykorzystywanych pozycji słowników).

P

HIS.GL. 42 możliwość ewidencji wykonania usług rozliczanych komercyjnie: D

HIS.GL. 43 obsługa zakończenia wizyty: P

HIS.GL. 44 - autoryzacja medyczna wizyty, P

HIS.GL. 45 - automatyczne tworzenie karty wizyty. P

HIS.GL. 46 - możliwość bezpośredniego skierowania na IP Zapis usunięty przez Zamawiającego P

HIS.GL. 47 Kwalifikacja rozliczeniowa usług i świadczeń. P

HIS.GL. 48 - wiązanie rozliczanych badań do kolejnej zaplanowanej wizyty P

HIS.GL. 49 wgląd w rozliczenia NFZ z tytułu zrealizowanych w trakcie wizyty usług P

HIS.GL. 50 automatyczna aktualizacja i przegląd Księgi Głównej Przychodni P


Strona 61 z 208

Nr wymagania

Wymaganie Typ

HIS.GL. 51 raporty i wykazy Gabinetu P

VI.2.1.3.8. Statystyka

Nr wymagania

Wymaganie Typ

HIS.STAT. 1 obsługa statystyki rozliczeniowej i medycznej P

HIS.STAT. 2 automatyczna generacja Księgi Przychodni, P

HIS.STAT. 3 dostęp do wszystkich ksiąg placówki Uczestnika Projektu P

HIS.STAT. 4 Raporty i wykazy statystyczne, w tym: P

HIS.STAT. 5 - raport rozpoznań - zestawienie syntetyczne i analityczne ilości rozpoznań każdego rodzaju w rozbiciu na pacjentów i jednostki wykonujące

P

HIS.STAT. 6 - wykonane badania wg płatnika i jednostki kierującej - zestawienie ilości wykonanych badań poszczególnych rodzajów, z podziałem na jednostki wykonujące, dla wybranych instytucji i jednostek kierujących

P

HIS.STAT. 7 - lista pacjentów przyjętych przez lekarza - zestawienie pacjentów przyjętych w zadanym okresie, w wybranych gabinetach, przez wybranych lekarzy

P

HIS.STAT. 8 - zestawienie statystyczne pacjentów - zestawienie syntetyczne lub analityczne (dla poszczególnych di zadanego okresu) liczby pacjentów przyjętych w wybranych/wszystkich gabinetach w rozbiciu na dorosłych i dzieci z podziałem na płeć oraz pacjentów pierwszorazowych i kontynuację leczenia

P

HIS.STAT. 9 - raport obciążenia gabinetów - zestawienie liczby wykonanych badań w poszczególnych dniach zadanego okresu dla wybranych/wszystkich gabinetów, dla poszczególnych lekarzy

P

HIS.STAT. 10 - wykonane procedury - syntetyczne i analityczne (dla poszczególnych dni zadanego zakresu) zestawienie liczby procedur danego rodzaju wykonanych w zadanym okresie, w wybranych/wszystkich gabinetach, dla wybranego/wszystkich ubezpieczycieli i płatników

P

HIS.STAT. 11 - zestawienie zrealizowanych usług - zestawienie liczby usług wykonanych pacjentom (podstawowe dane pacjenta) wraz z rozpoznaniami i procedurami w wybranej/wszystkich jednostkach, dla wybranych instytucji i jednostek kierujących wykonanych przez wybranego/wszystkich lekarzy

P

HIS.STAT. 12 - lista zarejestrowanych/przyjętych pacjentów - zestawienie ilości zarejestrowanych pacjentów do wybranego gabinetu

P

HIS.STAT. 13 - liczba usług wykonanych przez lekarza - zestawienie ilości usług wykonanych w jednostce przez danego lekarza

P

HIS.STAT. 14 - zestawienie liczby przyjętych pacjentów - zestawienie liczby pacjentów przyjętych przez daną jednostkę i lekarza w ramach określonego pakietu świadczeń z podziałem na grupy wiekowe

P

HIS.STAT. 15 - lista wykonanych usług - lista usług wraz z danymi takimi jak: jednostka i lekarz kierujący, miejsce i data wykonania, dane o wartości usługi, opłacie kontrahenta, opłacie pacjenta dla wybranych lub wszystkich: umów, pacjentów, świadczeń, instytucji i lekarzy kierujących oraz jednostek i lekarzy wykonujących

P

HIS.STAT. 16 - zestawienie wystawionych skierowań - syntetyczne i analityczne (wg daty wystawienia) zestawienie ilości wystawionych skierowań na określone badania/usługi z podziałem na lekarzy wystawiających i/lub jednostki, w których wystawiono skierowanie dla wybranych lub wszystkich; jednostek, lekarzy kierujących, usług, statusów realizacji

P

HIS.STAT. 17 - deklaracje - raport personalny - zestawienie liczby osób zadeklarowanych w wybranym miesiącu danego roku dla wybranej lub wszystkich umów oraz dla wybranego lub wszystkich rodzajów deklaracji

P

HIS.STAT. 18 - kolejki oczekujących - zestawienie kolejek oczekujących w ujęciu syntetycznym (dane całej kolejki) i analitycznym (z danymi oczekujących pacjentów

P

HIS.STAT. 19 - zestawienie wykonanych usług - lista pacjentów z wykonanymi usługami i procedurami oraz z danymi o instytucji, jednostce i lekarzu kierującym dla wybranej jednostki wykonującej w zadanym okresie

P

HIS.STAT. 20 - zestawienie wykonanych usług pacjenta - lista usług wykonanych w określonym czasie dla wybranego pacjenta z wyszczególnieniem danych o wartości i opłatach

P

HIS.STAT. 21 - zestawienie udzielonych porad i przyjętych pacjentów - syntetyczne i analityczne (pacjenci) zestawienie liczby udzielonych porad danego rodzaju z podziałem na : miejscowości zamieszkania, pacjenta lub typ porady w zadanym okresie, dla wybranych lub wszystkich gabinetów i wybranego rodzaju wizyty (pierwszorazowa, kolejna)

P

VI.2.1.3.9. Administracja/konfiguracja

Nr wymagania

Wymaganie Typ

HIS.ADM. 1 Konfiguracja systemu: P

HIS.ADM. 2 zarządzanie słownikiem jednostek struktury organizacyjnej Uczestnika Projektu na poziomie całego systemu: P

HIS.ADM. 3 - tworzenie i modyfikacja listy jednostek organizacyjnych (recepcje, gabinety, pracownie itp.) P

HIS.ADM. 4 - powiązanie struktury jednostek organizacyjnych ze strukturą kosztów. P


Strona 62 z 208

Nr wymagania

Wymaganie Typ

HIS.ADM. 5 zarządzanie słownikami standardowymi (ogólnopolskimi): P

HIS.ADM. 6 - Międzynarodowa Klasyfikacja Procedur Medycznych ICD9 CM P

HIS.ADM. 7 - Klasyfikacja chorób wg ICD P

HIS.ADM. 8 - Słownik Kodów Terytorialnych GUS, P

HIS.ADM. 9 - Słownik Zawodów. P

HIS.ADM. 10 tworzenie, przegląd, edycja słowników własnych Zamawiającego: P

HIS.ADM. 11 - personelu, P

HIS.ADM. 12 - leków. P

HIS.ADM. 13 zarządzanie strukturą użytkowników i ich uprawnieniami: P

HIS.ADM. 14 - definiowanie listy użytkowników systemu, P

HIS.ADM. 15 - określenie uprawnień użytkowników, P

HIS.ADM. 16 - możliwość połączenia listy użytkowników ze słownikiem personelu, P

HIS.ADM. 17 dynamiczne definiowanie widoków słowników (zakresu danych wyświetlanych) dla jednostki organizacyjnej, dla użytkownika,

P

HIS.ADM. 18 definiowanie terminarzy zasobów: pomieszczeń, łóżek, urządzeń P

HIS.ADM. 19 zarządzanie parametrami na poziomie systemu, jednostki organizacyjnej, stacji roboczej, użytkownika, P

HIS.ADM. 20 definiowanie struktury dokumentów: P

HIS.ADM. 21 - ksiąg wykorzystywanych w przychodni , pracowniach, P

HIS.ADM. 22 - szablonów wydruków (pism), P

HIS.ADM. 23 definiowanie elementów leczenia i złożonych szablonów zleceń wykorzystywanych przez jednostki zlecające, P

HIS.ADM. 24 zarządzanie międzymodułowym systemem komunikacyjnym umożliwiający pobranie lub wysłanie komunikatów do:

P

HIS.ADM. 25 - innych modułów, P

HIS.ADM. 26 - innych użytkowników, P

HIS.ADM. 27 - innych stacji roboczych. P

HIS.ADM. 28 Pozostałe funkcje administratorskie: P

HIS.ADM. 29 - przegląd dziennika operacji (logi), P

HIS.ADM. 30 - funkcje optymalizacji bazy danych P

HIS.ADM. 31 - możliwość wyszukiwania i łączenia podwójnie wprowadzonych danych pacjentów, lekarzy, instytucji. P

HIS.ADM. 32 System musi zachowywać dane pacjenta "scalonego" mechanizmem scalania pacjentów. Pacjent którego dane zostały scalone z danymi innego pacjenta nie może być usunięty z systemu. Dane pacjenta powinny być dostępne do wyszukiwania w szczególności wyszukiwania wg identyfikatora pacjenta.

P

VI.2.1.3.10. Raporty

Nr wymagania

Wymaganie Typ

HIS.RAP. 1 System musi umożliwiać elastyczne dopasowanie systemu do potrzeb sprawozdawczych Zamawiającego poprzez:

P

HIS.RAP. 2 - definiowanie niestandardowych raportów pozwalających na tabelaryczne przedstawianie danych dostępnych w poszczególnych modułach, zapis stworzonych wzorców wykazów w celu wielokrotnego wykonywania raz zdefiniowanego raportu

P

HIS.RAP. 3 - wykonanie zdefiniowanych raportów i ich przedstawienie poprzez arkusz kalkulacyjny P

VI.2.1.3.11. Pulpit użytkownika

Nr wymagania

Wymaganie Typ

HIS.PU. 1 System powinien zawierać pulpity użytkowników umożliwiające bezpośredni dostęp do wszystkich niezbędnych funkcji, do jakich użytkownik posiada uprawnienia

D

HIS.PU. 2 System musi posiadać zdefiniowany pulpit lekarza D

HIS.PU. 3 Pulpit użytkownika powinien zawierać, co najmniej bezpośredni dostęp do D

- pacjentów zaplanowanych na wizytę i konsultacje, umówionych na dzisiaj

- wyników badań z podziałem na laboratoryjne, diagnostyczne i inne z możliwością wyświetlenia tylko najnowszych wyników (np. z ostatnich 24godzin)

- zaplanowane na dzisiaj: wizyty, konsultacje

- dokumentacji medycznej pacjentów umówionych na wizytę, z odbytych wizyt i konsultacji


Strona 63 z 208

Nr wymagania

Wymaganie Typ

- terminarz użytkownika uwzględniający jego: dyżury, nieobecności, zadania, zaplanowane dla niego lub zrealizowane przez niego: zabiegi, konsultacje, wizyty

HIS.PU. 4 Powinna istnieć możliwość samodzielnego, przez użytkowników lub administratorów, definiowania pulpitu lub jego modyfikacji

D

VI.2.1.3.12. Weryfikacja uprawnień świadczeniobiorców

Nr wymagania

Wymaganie Typ

HIS.WUS. 1 Weryfikacja uprawnień pacjenta do świadczeń refundowanych przez NFZ podczas rejestracji/planowania wizyty w przychodni lub pracowni, weryfikowany jest stan na dzień rejestracji

P

HIS.WUS. 2 Tworzenie harmonogramów weryfikacji grupowej P

HIS.WUS. 3 Weryfikacja uprawnień w oparciu o harmonogramy P

HIS.WUS. 4 Oznaczanie ikoną i kolorem statusu weryfikacji pacjenta P

HIS.WUS. 5 - na liście pacjentów P

HIS.WUS. 6 - w widocznym miejscu przy danych pacjenta P


VI.2.1.4.1. Instalacja, konfiguracja i inicjalizacja bazy danych

VI.2.1.4.2. Instalacja systemu medycznego na serwerach

VI.2.1.4.3. Konfiguracja systemu medycznego zgodnie z ustaleniami z Analizy

Przedwdrożeniowej

VI.2.1.4.4. Instalacja oprogramowania klienckiego na stacjach roboczych

VI.2.1.4.5. Testy funkcjonalne

VI.2.1.4.6. Szkolenia użytkowników i administratorów


VI.2.1.5.1. Organizacja wdrożenia nie może zaburzyć pracy personelu u Uczestników

Projektu.



technicznej w dni robocze w godzinach od 8 do 15 z obsługą telefoniczną i przy

pomocy poczty elektronicznej.


VI.2.1.7.1. Etap I – po uruchomieniu i inicjalizacji systemu,

VI.2.1.7.2. Etap II – po pozytywnym zakończeniu testów funkcjonalnych,

VI.2.1.7.3. Etap III – po zakończeniu szkoleń.


VI.2.1.8.1. Brak.


Strona 64 z 208


Strona 65 z 208

VI.2.2. Systemy administracyjne klasy ERP


SPZO

Z „P

rzyc

ho

dn

ia D

wo

rco

wa”

w G

orz

ow

ie W

ielk

op

ols

kim

, 66

-40

0 G

orz

ów

Wlk

p.,

ul.

Dw

orc

ow

a 1

3

Wo

jew

ód

zki O

śro

dek

Med

ycyn

y P

racy

, 66

-40

0 G

orz

ów

Wlk

p.,

ul.

Fab

rycz

na

71

Sam

od

ziel

na

Pu

blic

zna

Wo

jew

ód

zka

Stac

ja P

ogo

tow

ia R

atu

nko

weg

o, 6

6-4

00

Go

rzó

w W

lkp

., u

l. K

azim

ierz

a W

ielk

iego

7

Wie

losp

ecja

listy

czn

y Sz

pit

al W

oje

wó

dzk

i w G

orz

ow

ie W

lkp

. Sp

. z o

.o.,

66

-40

0 G

orz

ów

Wlk

p.,

ul.

Wal

czak

a 4

2

Sam

od

ziel

ny

Pu

blic

zny

Szp

ital

dla

Ner

wo

wo

i P

sych

iczn

ie C

ho

rych

, 66

-30

0 M

ięd

zyrz

ecz,

ul.

Po

znań

ska

10

9

Lub

usk

i Szp

ital

Sp

ecja

listy

czn

y P

ulm

on

olo

gicz

no

- K

ard

iolo

gicz

ny

Sam

od

ziel

ny

Pu

blic

zny

Zakł

ad O

pie

ki Z

dro

wo

tnej

, 66

-2

35

To

rzym

, ul.

Wo

jska

Po

lski

ego

52

Wo

jew

ód

zki S

zpit

al S

pec

jalis

tycz

ny

dla

Ner

wo

wo

i P

sych

iczn

ie C

ho

rych

Sam

od

ziel

ny

Pu

blic

zny

Zakł

ad O

pie

ki

Zdro

wo

tnej

, 66

-21

3 C

ibó

rz 5

Ośr

od

ek d

la O

sób

Uza

leżn

ion

ych

Sam

od

ziel

ny

Pu

blic

zny

Zakł

ad O

pie

ki Z

dro

wo

tnej

„N

ow

y D

wo

rek”

, 66

-20

0 N

ow

y

Dw

ore

k 4

6;

Lub

usk

i Ośr

od

ek R

ehab

ilita

cyjn

o -

Ort

op

edyc

zny

im. d

r Le

cha

Wie

rusz

a SP

ZOZ,

66

-20

0 Ś

wie

bo

dzi

n, u

l. Za

mko

wa

1

Wo

jew

ód

zka

Stac

ja P

ogo

tow

ia R

atu

nko

weg

o S

amo

dzi

eln

y P

ub

liczn

y Za

kład

Op

ieki

Zd

row

otn

ej, 6

5-0

43

Zie

lon

a G

óra

, u

l. B

. Ch

rob

rego

2

Wo

jew

ód

zki O

śro

dek

Med

ycyn

y P

racy

, 65

-09

6 Z

ielo

na

Gó

ra, u

l. D

ąbró

wki

15

C

SP Z

OZ

„M

EDK

OL”

, 65

-02

0 Z

ielo

na

Gó

ra, u

l. P

lac

Ko

leja

rza

1

Wo

jew

ód

zki O

śro

dek

Ter

apii

Uza

leżn

ień

i W

spó

łuza

leżn

ien

ia, 6

5-0

44

Zie

lon

a G

óra

, ul.

Waz

ów

36

Szp

ital

Wo

jew

ód

zki S

PZO

Z w

Zie

lon

ej G

órz

e, 6

5-0

46

Zie

lon

a G

óra

, ul.

Zyty

26

SP Z

OZ

Cen

tru

m L

ecze

nia

Dzi

eci i

Mło

dzi

eży

w Z

abo

rze,

66

-00

3 Z

abó

r, u

l. Za

mko

wa

1

Wdrożenie systemu administracyjnego (ERP) do 25 użytk.

X X X X X X

Wdrożenie systemu administracyjnego (ERP) powyżej 25 użytk.

X

VI.2.2.1. Licencjonowanie

Wymagana jest dostawa bezterminowej licencji uprawniającej do eksploatacji oprogramowania

aplikacyjnego ERP przez Uczestnika Projektu jednocześnie dla co najmniej następującej liczby

użytkowników bez ograniczeń w odniesieniu do liczby jednocześnie uruchomionych modułów:


Strona 66 z 208

Uczestnik Projektu Liczba

użytkowników

SPZOZ „Przychodnia Dworcowa” w Gorzowie Wielkopolskim, 66-400 Gorzów Wlkp., ul. Dworcowa 13

10

Samodzielna Publiczna Wojewódzka Stacja Pogotowia Ratunkowego, 66-400 Gorzów Wlkp., ul. Kazimierza Wielkiego 7

11

Samodzielny Publiczny Szpital dla Nerwowo i Psychicznie Chorych, 66-300 Międzyrzecz, ul. Poznańska 109

27

Wojewódzka Stacja Pogotowia Ratunkowego Samodzielny Publiczny Zakład Opieki Zdrowotnej, 65-043 Zielona Góra, ul. B. Chrobrego 2

8

Wojewódzki Ośrodek Medycyny Pracy, 65-096 Zielona Góra, ul. Dąbrówki 15C

8

SP ZOZ „MEDKOL”, 65-020 Zielona Góra, ul. Plac Kolejarza 1

4

Wojewódzki Ośrodek Terapii Uzależnień i Współuzależnienia, 65-044 Zielona Góra, ul. Wazów 36

6

Razem 74

Wykonawca dostarczy także licencję uprawniającą Uczestnika Projektu do eksploatacji

oprogramowania bazodanowego z którym współpracuje system ERP i licencja musi umożliwiać

jednoczesną pracę liczby użytkowników zgodną z dostarczoną licencją na system ERP lub na

instalację na serwerach opisanych w punktach VI.3.2.16 oraz VI.3.2.17. bez ograniczania

użytkowników.

Oprogramowanie, Oprogramowanie Systemowe, Oprogramowanie Narzędziowe oraz sprzęt

teleinformatyczny będą przez cały okres trwałości projektu własnością Zamawiającego (Urząd

Marszałkowski Województwa Lubuskiego) i bezpłatnie użyczone przez niego dla Uczestników

Projektu. Uczestnicy Projektu będą je eksploatować w okresie wdrożenia i trwałości Projektu. Po

zakończeniu okresu trwałości Projektu Oprogramowanie, Oprogramowanie Systemowe,

Oprogramowanie Narzędziowe oraz sprzęt teleinformatyczny zostanie formalnie przekazany do

Uczestników Projektu i stanie się ich własnością.

Wykonawca zobowiązany jest uwzględnić powyższe wymagania przy doborze odpowiedniego

sposobu licencjonowania oferowanego Oprogramowania, Oprogramowania Systemowego oraz

Oprogramowania Narzędziowego a także oprogramowania systemowego sprzętu

teleinformatycznego.

VI.2.2.2. Wymagania

W opisie wymagań przyjęto następującą konwencję:

wymagania, dla których w kolumnie „Typ” wpisano P są to wymagania, które oferowany

system musi posiadać obligatoryjnie na dzień składania ofert,

wymagania dla których w kolumnie „Typ” wpisano D są to wymagania, które oferowany

system może posiadać na dzień składania ofert – Wykonawca deklaruje spełnianie tych

wymagań przez oferowany system na dzień składania ofert w formularzu zgodnym ze wzorem


Strona 67 z 208

określonym w Załączniku nr 13 do SIWZ, wagi punktowe przypisane poszczególnym

wymaganiom zostały określone w Załączniku nr 13 do SIWZ.

Funkcjonalności typu P oraz typu D zostaną zweryfikowane podczas badania ofert w oparciu o

procedurę określoną w Załączniku nr 12 do SIWZ na podstawie deklaracji Wykonawcy złożonej wraz z

ofertą zgodnie ze wzorem określonym w Załączniku nr 13 do SIWZ.

VI.2.2.2.1. Wymagania pozafunkcjonalne

Nr wymagania Wymaganie Typ

ERP.WPF.1 Na stanowiskach użytkowników oprogramowanie powinno pracować w środowisku systemów

operacyjnych z rodziny MS Windows XP / / Vista / Windows 7 i nowszych[systemy 32 i 64 bit].

P

ERP.WPF.2 System musi zapewniać polskojęzyczny interfejs użytkownika oraz polskojęzyczne wartości danych

przechowywanych w systemie (sortowanie, reprezentacja dat, liczb).

P

ERP.WPF.3 System powinien zapewniać kontrolę wprowadzanych danych oraz pomoc kontekstową dla

użytkownika.

P

ERP.WPF.4 Wykonawca musi dostarczyć kompletną polskojęzyczną dokumentację użytkownika i

dokumentację administratora.

P

ERP.WPF.5 Wykonawca musi dostarczyć pełną dokumentację techniczną zawierającą struktury tablic w bazie

danych z opisem zawartości pól oraz relacji pomiędzy tablicami z opisem algorytmów i

parametrów oraz programowych zasad ochrony danych i systemu przetwarzania.

P

ERP.WPF.6 Aktualizacje systemu powinny zawierać szczegółową informację o wprowadzonych zmianach i

nowych funkcjach.

P

ERP.WPF.7 Aktualizacje systemu powinny umożliwiać przesłanie do dostawcy systemu szczegółowych logów z

instalacji w celu ich ewentualnej weryfikacji.

P

ERP.WPF.8 System powinien posiadać możliwość aktualizacji (nowe wersje, patche) w formie pozwalającej na

ich samodzielną instalację przez administratora systemu.

P

ERP.WPF.9 System musi posiadać możliwość realizacji kopii bezpieczeństwa w trakcie działania (na gorąco).

P

ERP.WPF.10 System posiada mechanizmy umożliwiające zapis i przeglądanie danych o logowaniu

użytkowników do systemu pozwalające na uzyskanie informacji o czasie i miejscach ich pracy.

P

ERP.WPF.11 System posiada oprogramowanie narzędziowa dla administratorów systemu pozwalające na

definiowania i generowania dowolnych zestawień i raportów związanych z zawartością

informacyjną bazy danych. Raporty takie musza mieć możliwość wywołania przez użytkownika z

poziomu aplikacji.

P

ERP.WPF.12 System umożliwia podgląd wszystkich dostępnych raportów z jednego miejsca

P

ERP.WPF.13 System posiada możliwość definicji indywidualnych zakresów raportów dla każdego użytkownika

P

ERP.WPF.14 System posiada elastyczny interfejs użytkownika umożliwiający wykorzystanie technologii

opartych na siatce danych min. w zakresie:

a) Rozciąganie i przesuwanie okien,

b) Prezentacja danych w formie tabeli przestawnej,

c) Przesuwanie, zmiana kolejności i rozmiarów kolumn,

d) Zamrażanie, usuwania pozycji kolumn

e) Filtrowanie i sortowania

f) Dowolne sumowanie danych

g) Wyszukiwania na danych lokalnych bez wykonywania zapytania

D


Strona 68 z 208


ERP.WPF.15 System musi posiadać możliwość tworzenia indywidualnego menu użytkownika z zachowaniem

wyszególnionych funkcjonalności:

a) tworzenie menu pozwalającego na szybki dostęp dla wybranych funkcji i raportów

systemu (w tym też bez podziału na moduły),

b) tworzenie w menu użytkownika własnej hierarchii funkcji i raportów (podmenu),

c) tworzenie zestawów menu,

d) modyfikowanie w menu użytkownika nazw funkcji i raportów.

P

ERP.WPF.16 System musi posiadać mechanizmy przesyłania i odbierania komunikatów tekstowych do

poszczególnych użytkowników i ich grup. Alerty generują się automatyczne na podstawie

zdefiniowanych uprzednio warunków takich jak: zmiana wartości pola w bazie danych, zajście

zdarzenia, brak czynności/zdarzenia po upływie określonego czasu.

P



ERP.WO.1 Moduły systemu muszą charakteryzować się wysokim stopniem integracji, wykorzystując zasadę

jednokrotnego wprowadzania danych.

P

ERP.WO.2 Dostęp do wszystkich dostępnych użytkownikowi zasobów systemu ma być zapewniony poprzez

jedną konsolę dostępu – po jednokrotnym wpisaniu hasła i nazwy (identyfikatora) użytkownika.

P

ERP.WO.3 Uprawnienia użytkownika mają być definiowane na poziomie bazy danych i zarządzanie nimi

powinno się odbywać z jednego miejsca przez osobę uprawnioną (administratora).

P

ERP.WO.4 Zarządzanie uprawnieniami powinno dotyczyć dostępu do poszczególnych modułów, pozycji menu

i funkcji systemu.

P

ERP.WO.5 System musi zapewniać możliwość konfiguracji dostępu użytkowników według ich rzeczywistych

kompetencji.

P

ERP.WO.6 System powinien umożliwiać definiowanie grup użytkowników/profili uprawnień dla sprawnego

zarządzania dostępem użytkowników do funkcji systemu.

P

ERP.WO.7 System musi rejestrować daty i godziny utworzenia i modyfikacji każdego rekordu w bazie danych

oraz nazwy użytkownika, który te czynności wykonał.

P

ERP.WO.8 Wszystkie dane wprowadzone do systemu, jak ich modyfikowanie i usuwanie, muszą być

autoryzowane a system musi umożliwić identyfikację osoby, która je wprowadziła wraz z datą tej

operacji.

P

ERP.WO.9 Z poziomu dowolnego formularza system powinien udostępniać informację o dacie i godzinie

utworzenia wskazanego rekordu oraz użytkowniku który rekord utworzył.

P

ERP.WO.10 System musi posiadać mechanizmy szybkiego wyszukiwania danych według dostępnych kryteriów,

w tym według fragmentów nazw i zakresów (dat, numerów).

P

ERP.WO.11 System powinien umożliwiać dowolne sortowanie danych wyświetlanych na formularzach (tzn.

sortowanie po dowolnych polach formularza lub funkcjach obliczonych na podstawie pól

formularza i danych w bazie danych) oraz zapisywanie domyślnych ustawień sortowania.

P

ERP.WO.12 System musi posiadać mechanizm definiowalnych filtrów pozwalających ograniczać zakres danych

wyświetlanych na formularzach.

P

ERP.WO.13 System musi zapewniać możliwość współpracy z oprogramowaniem MS Office. Raporty,

zestawienia, dokumenty, sprawozdania i inne wynikowe dokumenty w ramach tzw.

korespondencji seryjnej mają mieć możliwość zapisania w formacie MS Word.

P

ERP.WO.14 System musi zapewniać wydruk dokumentów i zestawień w trybie graficznym na drukarkach

laserowych oraz atramentowych.

P

ERP.WO.15 Wprowadzanie danych do systemu musi być oparte o listy wartości przypisane poszczególnym

polom formularzy w celu minimalizacji ewentualnych błędów danych.

P

ERP.WO.16 System musi umożliwiać dwustronną wymianę danych z systemami home-banking

funkcjonującymi u Zamawiającego (import wyciągów bankowych, export przelewów własnych).

P


Strona 69 z 208


ERP.WO.17 System powinien posiadać jedną wspólną dla wszystkich modułów bazę podmiotów-

kontrahentów.

P

ERP.WO.18 Systemu powinien umożliwić podgląd numeru wersji kluczowych komponentów systemu

(pakietów, modułów aplikacji, menu, formularzy, raportów).

P

ERP.WO.19 System powinien zawierać mechanizmy umożliwiające definicję zadań systemowych (zadań

bazodanowych), uruchamianych w określonych przez administratora interwałach czasowych.

P

ERP.WO.20 System musi kontrolować, aby pola PESEL, NIP, REGON były zamiennie wymagalne.

P

ERP.WO.21 System musi umożliwiać dołączanie do kartoteki kontrahenta i przechowywanie elektronicznych

załączników w postaci plików dowolnego formatu.

P

ERP.WO.22 System musi pozwalać zdefiniować wspólną dla wszystkich modułów systemu strukturę

organizacyjną.

P

ERP.WO.23 Przy danych dotyczących kontrahenta system musi umożliwić rejestrację adresu e-mail oraz zgody

na otrzymywanie korespondencji drogą poczty elektronicznej.

P

ERP.WO.24 System musi posiadać możliwość zaimportowania jednolitego słownika ulic oraz słownika

miejscowości i kodów pocztowych.

P

ERP.WO.25 System powinien pozwalać na dodawanie dodatkowych pól definiowalnych dla dokumentów i

innych rekordów przechowywanych w bazie, takich jak: kontrahent, indeks magazynowy,

pracownik, element majątku trwałego.

P

ERP.WO.26 System powinien umożliwiać administratorowi definiowane prostych słowników (zawierających

kod i wartość).

P

ERP.WO.27 System musi umożliwiać automatyczną obsługę żądań przekazania danych do Centralnej Aplikacji

BI zgodnie ze specyfikacją interfejsu wymiany danych opracowanego przez Wykonawcę w ramach

Centralnej Aplikacji BI.

P

VI.2.2.2.3. Księgowość


ERP.KS.1 System musi zapewnić obsługę kont bilansowych oraz pozabilansowych.

P

ERP.KS.2 System powinien posiadać możliwość tworzenia nowych kont na podstawie wzorców (szablonów) budowy kont zawierających charakterystykę poszczególnych poziomów analityki konta i słowników kont analitycznych.

P

ERP.KS.3 System musi zapewniać możliwość zdefiniowania dowolnej struktury kont księgowych (budowa segmentu konta znakowa lub numeryczna) o długości do 200 znaków. Wymagana długość segmentu konta to 20 znaków.

P

ERP.KS.4 System musi zapewniać możliwość prowadzenia dekretacji dokumentu na kontach bilansowych oraz pozabilansowych jednocześnie.

P

ERP.KS.5 Dla wskazanych kont powinna istnieć możliwość przypisania dodatkowych atrybutów/parametrów konta, tj. dodatkowych klasyfikatorów ewidencjonowanych dla dekretów księgowanych na wybrane konta.

P

ERP.KS.6 System musi umożliwić definiowanie dostępu użytkowników do kont księgi głównej.

P

ERP.KS.7 System musi umożliwiać tworzenie kont poprzez kopiowanie analityki z innego, wskazanego konta księgowego.

P

ERP.KS.8 System musi umożliwiać łączenie wskazanych kont w grupy, w ramach których dodanie/modyfikacja/usunięcie konta analitycznego na jednym z kont będzie skutkowało wykonaniem analogicznej operacji na pozostałych kontach tej grupy.

P

ERP.KS.9 System musi zapewnić automatyczne kopiowanie planu kont przy otwarciu nowego roku obrotowego

P

ERP.KS.10 System musi zapewnić synchronizację planów kont na potrzeby generowania bilansu otwarcia nowego roku na podstawie bilansu zamknięcia roku poprzedniego tj. mapowanie kont należących do planów kont następujących po sobie lat obrotowych.

P


Strona 70 z 208


ERP.KS.11 System musi zapewniać otrzymywanie salda kont na poziomie syntetycznym zarówno po stronie Winien jak i Ma.

P

ERP.KS.12 System musi zapewniać automatyczne generowanie przeksięgowań związanych z zamykaniem kont bilansowych i pozabilansowych na koniec roku obrotowego.

P

ERP.KS.13 System musi zapewniać możliwość definiowania schematów/szablonów księgowań poszczególnych rodzajów dokumentów, wg których będzie następowało automatyczne generowanie dekretów.

P

ERP.KS.14 System musi zapewniać możliwość generacji storna czarnego i czerwonego (w zależności od potrzeby) poprzez wskazanie dokumentu, który powinien zostać skorygowany.

P

ERP.KS.15 System musi posiadać mechanizmy pozwalające na definicję algorytmów sprawdzających zgodność obrotów/sald wskazanych kont księgowych.

P

ERP.KS.16 System musi kontrolować zgodność zapisów księgi pomocniczej rozrachunków z księgą główną.

P

ERP.KS.17 System musi sprawdzać bilansowanie się wprowadzanego dokumentu (w ramach dekretów na kontach bilansowych).

P

ERP.KS.18 System musi uwzględniać etap merytorycznej weryfikacji wprowadzonych dowodów księgowych przez osobę z odpowiednimi uprawnieniami.

P

ERP.KS.19 System musi umożliwiać przeglądanie dokumentów jeszcze niezaksięgowanych.

P

ERP.KS.20 System musi zapewniać możliwość prowadzenia dzienników i rejestrów w układzie chronologicznym.

P

ERP.KS.21 System musi pozwalać na zarządzanie okresami księgowymi (w tym indywidualnie dla użytkownika), pozwalając na ich tworzenie, otwieranie, blokowanie i zamykanie.

P

ERP.KS.22 System musi zapewniać tworzenie zestawień i raportów w oparciu o zarejestrowane dane.

P

ERP.KS.23 System musi umożliwiać jednoczesną prace w dwóch otwartych latach obrotowych, tj. zapewniać pracę na przełomie lat – ewidencję dowodów księgowych w nowym roku obrotowym przy otwartym poprzednim roku.

P

ERP.KS.24 System musi zapewniać drukowanie całości lub tylko wybranych stron raportów, zestawień, dziennika, sprawozdań itp.

P

ERP.KS.25 System musi zapewniać automatyczne tworzenie bilansu otwarcia jako przeniesienia bilansu zamknięcia poprzedniego roku obrotowego.

P

ERP.KS.26 System musi zapewniać tworzenie wydruków i zestawień na podstawie dokumentów zaksięgowanych i niezaksięgowanych, ale zweryfikowanych (zaksięgowanych próbnie/zaksięgowanych do bufora).

P

ERP.KS.27 System musi zapewniać możliwość wyszukiwania dokumentów poprzez określenie ich wybranych parametrów – co najmniej możliwość wyboru po identyfikatorze, NIP, REGON, PESEL, adresie kontrahenta, numerze własnym, numerze obcym, rodzaju dokumentu, umowie, stanie w którym się znajduje, datach: wystawienia, operacji, zaksięgowania.

P

ERP.KS.28 System musi zapewniać raportowanie danych wynikających z dokumentów w postaci następujących zestawień:

P

a) Dziennika operacji gospodarczych, b) Miesięcznego zestawienia obrotów i sald w ujęciu syntetycznym i analitycznym, c) Kart kontowych, zawierających zaksięgowane operacje na danym koncie (dotyczy

dokumentów zaksięgowanych oraz próbnie zaksięgowanych/zaksięgowanych do bufora),

d) Stanu kont w ujęciu syntetycznym i analitycznym.

ERP.KS.29 System musi zapewniać ręczne definiowanie kursów walut – kupno, sprzedaż, kurs średni - oraz umożliwiać pobór kursów walut NBP w formacie pliku XML dostępnego na stronie internetowej NBP.

P

ERP.KS.30 System powinien być wyposażony w słownik walut oraz w razie potrzeby powinien umożliwiać uzupełnianie tego słownika.

P

ERP.KS.31 System musi zapewniać definiowanie i wykorzystanie wielu tabel kursów walut, z definiowalną walutą bazową.

P

ERP.KS.32 System powinien posiadać wbudowane mechanizmy umożliwiające import kursów walut z pliku tekstowego o odpowiednim formacie.

P

ERP.KS.33 System musi zapewniać obsługę wielowalutową w zakresie:

P

a) Rejestrowania dowodów księgowych (w tym dokumentów należności i zobowiązań) wyrażonych w dowolnej walucie,


Strona 71 z 208


b) Obsługi walutowej kasy (raportów kasowych),

c) Obsługi walutowego rachunku bankowego.

ERP.KS.34 W zakresie obsługi księgowej System musi zapewniać prowadzenie ksiąg rachunkowych.

P

ERP.KS.35 System musi zapewniać możliwość rejestracji i dekretacji dowodów księgowych (w tym dowodów źródłowych) oraz możliwość podglądu i wydruku dowodów księgowych zaewidencjonowanych i zaksięgowanych.

P

ERP.KS.36 System musi posiadać funkcję definicji rejestrów księgowych grupujących rejestrowane dowody z możliwością przydzielania dla nich uprawnień wskazanym użytkownikom. Dodatkową funkcją jest całkowite blokowanie rejestrów.

P

ERP.KS.37 System musi zapewniać generowanie raportów i zestawień: P

a) Plan kont,

b) Dziennik,

c) Bilans otwarcia,

d) Bilans zamknięcia,

e) Obroty i salda.

ERP.KS.38 Systemu musi pozwalać na definiowanie harmonogramów księgowań kosztów i przychodów rozliczanych w czasie (dla wskazanych kont oraz dla wskazanych dowodów księgowych).

P

ERP.KS.39 System musi umożliwiać drukowanie wymaganych druków podatkowych (CIT-8, CIT-8/O) i statystycznych (F-01s) oraz pozwalać na definiowanie źródła danych dla pozycji tych druków.

P

ERP.KS.40 Na potrzeby sprawozdawczości system musi zapewniać możliwość tworzenia definiowalnych zestawień (np. bilans, rachunek zysków i strat) z wykorzystaniem definiowalnych i modyfikowalnych wyrażeń odwołujących się do obrotów/sald wybranych kont księgowych (m. in. obroty WN/MA, saldo WN/MA, suma sald WN/MA, persaldo WN/MA).

P

VI.2.2.2.4. Finanse


ERP.FIN.1 System musi umożliwić rejestrację dokumentów należności i zobowiązań krajowych.

P

ERP.FIN.2 System musi zapewnić możliwość definicji rodzajów dokumentów należności i zobowiązań.

P

ERP.FIN.3 System musi umożliwić rejestrację poleceń księgowania.

P

ERP.FIN.4 System musi umożliwić rejestracje dokumentów zobowiązań importowych i SAD oraz zakupów

WNT i faktur wewnętrznych.

P

ERP.FIN.5 System musi stosownym komunikatem ostrzegać użytkownika przed dwukrotnym

wprowadzeniem tego samego dokumentu zakupowego.

P

ERP.FIN.6 System musi umożliwić rejestrację korekt dokumentów należności i zobowiązań.

P

ERP.FIN.7 System musi umożliwić rejestrację not korygujących dla dokumentów zakupu (zobowiązań).

P

ERP.FIN.8 System musi umożliwić kojarzenie dokumentów zakupowych z dokumentami PZ wystawianymi w

obszarze gospodarka magazynowa, reprezentującymi rzeczową realizację zakupu.

P

ERP.FIN.9 System musi zapewnić możliwość dołączania elektronicznych załączników (np. w postaci skanu

dokumentu) do dowodów księgowych.

P

ERP.FIN.10 System musi umożliwić rejestrację, edycję i pogląd dokumentów w zdefiniowanych rejestrach.

P

ERP.FIN.11 Rejestracja dokumentów w rejestrach musi być możliwa w walucie krajowej PLN i w walutach

obcych.

P

ERP.FIN.12 System musi umożliwić definiowanie rejestrów oraz podrejestrów VAT.

P

ERP.FIN.13 System musi zapewniać możliwość rejestracji i rozliczania podatku od towarów i usług (VAT)

odliczanego całkowicie, procentowo oraz nie podlegającego odliczeniu.

P


Strona 72 z 208


ERP.FIN.14 System musi zapewnić możliwość automatycznego przyporządkowania dokumentu do właściwego

rejestru VAT (na podstawie zdefiniowanego dla dokumentu domyślnego typu obsługi VAT).

P

ERP.FIN.15 System musi umożliwić ręczne przyporządkowanie dokumentu do właściwego rejestru VAT.

P

ERP.FIN.16 System musi umożliwić użytkownikowi ręcznie wprowadzić kwotę VAT dla poszczególnych pozycji

ewidencjonowanego dokumentu, w celu eliminacji problemu zaokrągleń kwot VAT na

dokumentach zakupowych.

P

ERP.FIN.17 System musi zapewnić automatyczną dekretację kwot VAT dokumentu na kontach z jednoczesnym

uwzględnieniem sposobu jego odliczenia.

P

ERP.FIN.18 System musi zapewniać prowadzenie pełnych rozrachunków z kontrahentami i pracownikami

własnymi, w tym przeglądanie, rozliczanie, generowanie i wydruk salda zaległości/nadpłaty,

generowanie i wydruk not odsetkowych, wezwań do zapłaty oraz potwierdzeń sald.

P

ERP.FIN.19 System musi posiadać wspólny słownik banków oraz jednostek banków wykorzystywany przez

wszystkie moduły systemu.

P

ERP.FIN.20 System musi zapewniać tworzenie poleceń przelewów własnych na podstawie

zaewidencjonowanych dokumentów zobowiązań oraz tworzenie przelewów z harmonogramu.

P

ERP.FIN.21 System musi umożliwić wymianę danych z systemami Home-Banking: P a) eksport przelewów własnych, b) import wyciągów bankowych. ERP.FIN.22

System musi umożliwiać obsługę płatności masowych w zakresie importu wyciągów bankowych. P

ERP.FIN.23 System musi zapewniać możliwość wyświetlania bieżącego stanu środków na wybranym rachunku

bankowym.

P

ERP.FIN.24 System musi zapewnić możliwość definiowania szablonów dekretacji (schematów księgowania) dla

dokumentów rozrachunkowych.

P

ERP.FIN.25 System musi zapewnić możliwość tworzenia algorytmów automatycznie kojarzących zapłaty z

rozrachunkami.

P

ERP.FIN.26 System musi zapewnić możliwość ręcznego kojarzenia zapłat z rozrachunkami, przy czym jedna

zapłata może rozliczać wiele rozrachunków, a jeden rozrachunek może być realizowany przez

wiele zapłat.

P

ERP.FIN.27 System musi zapewnić możliwość ręcznego rozbijania rozrachunków oraz przedłużania terminów

ich płatności.

P

ERP.FIN.28 System musi zapewnić możliwość przenoszenia i uzgadniania Bilansu Otwarcia rozrachunków.

P

ERP.FIN.29 System musi zapewnić możliwość przeglądania stanu rozrachunków - należności, zobowiązań, w

walucie rozrachunku oraz w PLN, z kontrahentem lub grupą kontrahentów.

P

ERP.FIN.30 System musi zapewnić możliwość definiowania przedziałów czasowych dla przeglądania struktury

wiekowej rozrachunków.

P

ERP.FIN.31 System musi zapewniać możliwość prowadzania rozliczeń kompensacyjnych w ramach zobowiązań

i należności pochodzących od tego samego kontrahenta.

P

ERP.FIN.32 System musi zapewniać obsługę cesji.

P

ERP.FIN.33 System musi zapewniać możliwość rejestrowania i rozliczania zaliczek zakupowych i

sprzedażowych.

P

ERP.FIN.34 System musi zapewniać generowanie i wydruk potwierdzenia sald dla poszczególnych

kontrahentów, wraz z kopią do podpisania i odesłania przez kontrahenta.

P

ERP.FIN.35 System musi zapewniać generowanie i drukowanie wezwań do zapłaty: wezwanie do zapłaty,

ponowne wezwanie do zapłaty, przedprocesowe / ostateczne wezwane do zapłaty, oraz

definiowanie ich treści.

P

ERP.FIN.36 System musi zapewniać możliwość generowania, przeglądania, dekretacji, księgowania i wydruku

not odsetkowych oraz definiowania ich treści.

P

ERP.FIN.37 System musi udostępniać możliwość ustalenia minimalnej kwoty odsetek, dla których generowana

będzie nota odsetkowa.

P


Strona 73 z 208


ERP.FIN.38 System musi umożliwiać generację noty odsetkowej bez potrzeby jej natychmiastowej dekretacji

na kontach księgi głównej.

P

ERP.FIN.39 System musi umożliwić generację raportów (dokumentów): P a) Rozrachunki i ich rozliczenie, b) Deklaracja podatkowa VAT-7, c) Deklaracja podatkowa VAT-UE, d) Polecenie przelewu, e) Nota odsetkowa, f) Wezwanie do zapłaty, g) Potwierdzenie salda, h) Dokument KP / KW (Kasa przyjmie / Kasa wyda), i) Raport kasowy. ERP.FIN.40

System musi zapewnić obsługę dowolnej ilości kas. P

ERP.FIN.41 System musi zapewnić możliwość prowadzenia kas w PLN i w walutach obcych.

P

ERP.FIN.42 System musi zapewnić możliwość rejestracji dokumentów wpłat/wypłat oraz raportów kasowych.

P

ERP.FIN.43 System musi zapewniać możliwość powiązania dokumentu wpłaty z informacjami dotyczącymi

tytułu dokonywanej wpłaty oraz odpowiadającym mu dekretem na kontach księgi głównej.

P

ERP.FIN.44 System musi zapewniać otwieranie i zamykanie raportu kasowego oraz podział raportów kasowych

na różne rodzaje działalności dochodowej i wydatkowej.

P

ERP.FIN.45 System musi zapewniać możliwość wyświetlania bieżącego stanu gotówki w wybranej kasie.

P

VI.2.2.2.5. Środki trwałe


ERP.ST.1 System musi zapewnić możliwość ewidencji środków trwałych, wyposażenia, wartości niematerialnych i prawnych.

P

ERP.ST.2 System musi zapewnić możliwość ewidencji bilansowej i pozabilansowej elementów majątku trwałego.

P

ERP.ST.3 System musi zapewnić ewidencję środków trwałych z wpisaniem do książki inwentarzowej i wygenerowaniem karty środka.

P

ERP.ST.4 System musi zapewnić możliwość przeglądania danych w kontekście elementów majątku trwałego lub w kontekście dokumentów obrotowych.

P

ERP.ST.5 System musi zapewnić możliwość dołączania elektronicznych załączników (np. w postaci zdjęcia, skanu podpisanego protokołu odbioru czy dokumentacji technicznej) do elementów majątku trwałego.

P

ERP.ST.6 System musi umożliwiać rejestrację dokumentów: P a) Przyjęcia, nieodpłatnego przyjęcia,

b) Likwidacji całkowitej, likwidacji częściowej, nieodpłatnego przekazania,

c) Przeszacowania,

d) Zmniejszenia / zwiększenia wartości,

e) Dokumentu rat amortyzacji oraz zbiorczego dokumentu rat amortyzacji,

f) Dokumentu rat podatku oraz zbiorczego dokumentu rat podatku,

g) Zmiany danych środka (w tym zmiany co najmniej: miejsca użytkowania, danych opisowych, użytkownika, osoby materialnie odpowiedzialnej).

ERP.ST.7 System musi umożliwić definiowanie dodatkowych typów operacji indywidualnych dokumentów obrotowych.

P

ERP.ST.8 System musi zapewnić możliwość naliczania amortyzacji ścieżką podatkową oraz bilansową. P

ERP.ST.9 System musi zapewnić obsługę następujących metod amortyzacji: P a) Liniowa,


Strona 74 z 208


b) Degresywna.

ERP.ST.10 System musi zapewnić możliwość definiowania własnych metod amortyzacji. P

ERP.ST.11 System musi zapewnić możliwość definiowania okresowości (miesięcznie, kwartalnie, rocznie) naliczania amortyzacji i umorzenia elementu majątku trwałego dla poszczególnych ścieżek amortyzacji.

P

ERP.ST.12 System musi umożliwić wyłączenie naliczania amortyzacji i umorzenia elementu majątku trwałego w wybranych miesiącach.

P

ERP.ST.13 System musi zapewnić możliwość naliczania amortyzacji od różnych wartości brutto elementu majątku trwałego w poszczególnych ścieżkach (przy różnych wartościach niepodlegających amortyzacji dla poszczególnych ścieżek).

P

ERP.ST.14 System musi zapewnić możliwość ewidencjonowania źródeł finansowania środka trwałego oraz uwzględniać te dane przy dekretacji rat amortyzacji.

P

ERP.ST.15 System musi zapewnić możliwość ilościowo-wartościowej ewidencji wyposażenia. P

ERP.ST.16 System musi zapewnić możliwość ponownego przeliczania planu amortyzacji oraz wygenerowania dokumentów korekt rat amortyzacji dla przeszłych okresów.

P

ERP.ST.17 System musi zapewnić możliwość definiowania wielu stawek podatku od nieruchomości. P

ERP.ST.18 System musi zapewnić możliwość procentowego przypisania elementu majątku trwałego do kilku stawek podatku.

P

ERP.ST.19 System musi zapewnić możliwość ponownego przeliczania planu podatku oraz wygenerowania dokumentów korekt rat podatku dla przeszłych okresów.

P

ERP.ST.20 System musi zapewniać wykonywanie operacji na czynnych środkach trwałych, w szczególności: P a) zmiany wartości,

b) zmiany miejsca użytkowania,

c) zmiany osób odpowiedzialnych i/lub użytkujących element majątku,

d) korekty wartości i umorzeń,

e) zmiany stawek amortyzacyjnych.

ERP.ST.21 System musi zapewnić możliwość ewidencji składników elementu majątku trwałego (dla elementów złożonych).

P

ERP.ST.22 System musi umożliwiać kompletację oraz dekompletację środka trwałego złożonego, tj. odłączanie oraz dołączanie do niego nowych składników.

P

ERP.ST.23 System musi umożliwić automatyczne nadawanie numeru inwentarzowego dla elementów majątku trwałego na podstawie definiowanego wzorca.

P

ERP.ST.24 Dla zaewidencjonowanych elementów majątku trwałego System musi umożliwić rejestrację danych podstawowych (dostawca, nazwa, numer fabryczny, grupa KŚT, typ, rodzaj, pochodzenie, data nabycia, wartość nabycia, koszty nabycia, pracownik odpowiedzialny, miejsce używania).

P

ERP.ST.25 System powinien umożliwiać rejestrację specyficznych danych dla elementów majątku będących środkami transportu, min.:

P

a) Typ pojazdu,

b) Rok produkcji,

c) Pojemność silnika, moc,

d) Numery nadwozia, podwozia, silnika, rejestracyjny, karty pojazdu,

e) Marka, model, kolor nadwozia,

f) Przebieg,

g) Masa własna, ładowność,

h) Liczba miejsc.

ERP.ST.26 System powinien umożliwiać rejestrację specyficznych danych dla elementów majątku będących nieruchomościami:

P

a) Powierzchnia użytkowa,

b) Powierzchnia mieszkalna,

c) Kubatura.

ERP.ST.27 System powinien umożliwiać rejestrację innych specyficznych danych dla poszczególnych rodzajów majątku w dodatkowych, definiowalnych polach formularza.

P

ERP.ST.28 System musi umożliwić przypisanie elementu majątku do wielu stanowisk kosztów. P

ERP.ST.29 System musi umożliwić przypisywanie dokumentów zakupowych/sprzedażowych do środków trwałych oraz dokumentów obrotowych (np. przypisanie faktury zakupowej do dokumentu OT).

P

ERP.ST.30 System musi umożliwiać dodawanie nowego elementu majątku na bazie innego już istniejącego np. poprzez funkcję kopiowania.

P


Strona 75 z 208


ERP.ST.31 System musi umożliwić grupowanie elementów majątku trwałego. P

ERP.ST.32 System musi zapewnić definiowanie tabel współczynników przeszacowania i wartości współczynników dla poszczególnych grup majątku trwałego.

P

ERP.ST.33 System musi zapewniać automatyczne przeszacowanie wskazanego podzbioru majątku. P

ERP.ST.34 System musi zapewniać ewidencję rozchodu środków trwałych (likwidacje, przekazania, inne tytuły).

P

ERP.ST.35 System musi zapewniać automatyczną dekretację zaewidencjonowanych w postaci dokumentów obrotowych operacji do księgi głównej.

P

ERP.ST.36 System musi zapewniać wyszukiwanie środków trwałych po ich wszystkich atrybutach. P

ERP.ST.37 System musi zapewniać możliwość inwentaryzacji metodą spisu z natury. P

ERP.ST.38 System musi zapewnić możliwość generacji i wydruku arkuszy inwentaryzacyjnych. P

ERP.ST.39 System musi umożliwiać współpracę z drukarkami nalepek kodów kreskowych oraz umożliwiać obsługę inwentaryzacji środków trwałych z wykorzystaniem kolektorów danych z czytnikiem kodów kreskowych.

P

ERP.ST.40 System musi umożliwić wydruk wszystkich dokumentów obrotowych środków trwałych. P

ERP.ST.41 System musi zapewnić możliwość definicji własnych, indywidualnych raportów na temat środków trwałych w oparciu o predefiniowany zestaw elementów (kolumny z danymi, parametry filtrów danych).

P

ERP.ST.42 System powinien trwale przechowywać dane o środkach trwałych, w tym również tych zlikwidowanych i całkowicie umorzonych, oraz zapewnić do nich dostęp za pomocą raportów.

P

ERP.ST.43 System musi zapewnić dostęp do pełnej historii operacji wykonanych na elementach majątku. P

ERP.ST.44 System musi zapewniać możliwość generacji następujących wydruków i raportów: P a) Karta inwentarzowa środka trwałego,

b) Wartość brutto środków trwałych,

c) Pracownicy odpowiedzialni za środki trwałe,

d) Zestawienie majątku całkowicie umorzonego,

e) Stan majątku na dany dzień,

f) Sprawozdanie F-03,

g) Szczegółowe zestawienie zmian na środkach,

h) Amortyzacja środków trwałych.

VI.2.2.2.6. Kadry


ERP.KAD.1 System musi zapewnić prowadzenie pełnej kartoteki osobowej. P

ERP.KAD.2 System musi zapewniać możliwość rejestrowania danych osobowych pracowników, w tym co najmniej: imię, nazwisko, data i miejsce urodzenia, numer dowodu osobistego, PESEL, NIP, Obywatelstwo, Kraj pochodzenia, Czy zamieszkanie na terytorium Polski (konieczne do IFT-1R) , Urząd Skarbowy odpowiedni dla pracownika, wiele jego adresów, dane potrzebne do ZUS-u oraz dane określające stosunek pracownika do służby wojskowej, numer rachunku bankowego pracownika.

P

ERP.KAD.3 System musi umożliwiać przechowywanie historii zmian danych identyfikacyjnych (umożliwiając uzyskanie z systemu ZUS ZIUA).

P

ERP.KAD.4 System musi zapewniać możliwość rejestrowania danych o przebiegu zatrudnienia pracownika. P ERP.KAD.5 System musi zapewniać możliwość wprowadzenie dowolnego etatu – bez słownika P ERP.KAD.6 System musi zapewniać możliwość ewidencjonowania umów o współpracę pod tym samym

numerem co umowy o pracę P

ERP.KAD.7 System powinien mieć możliwość zaliczania okresów poprzedniej pracy do poszczególnych rodzajów staży.

P

ERP.KAD.8 System musi zapewniać możliwość rejestrowania danych o poszczególnych członkach rodziny pracownika.

P

ERP.KAD.9 System musi zapewniać możliwość rejestrowania danych o kwalifikacjach pracownika. P ERP.KAD.10 System musi zapewniać możliwość rejestrowania danych o karach i wyrokach nałożonych na

pracownika. P

ERP.KAD.11 System musi umożliwiać rejestrację uprawnień posiadanych przez pracownika. P ERP.KAD.12 System musi umożliwiać rejestracje danych o odznaczeniach pracownika. P


Strona 76 z 208


ERP.KAD.13 System musi zapewniać możliwość rejestrowania danych o pełnomocnictwach udzielonych pracownikowi, w tym co najmniej: treść pełnomocnictwa, jego numer, datę przyznania i datę jego odwołania.

P

ERP.KAD.14 System musi zapewniać możliwość rejestrowania danych o badaniach lekarskich, w tym: rejestrowanie wykonanych obowiązkowych badań lekarskich oraz terminów następnego badania.

P

ERP.KAD.15 System musi zapewniać możliwość rejestrowania danych dotyczących umowy o pracę. P ERP.KAD.16 System musi zapewniać możliwość rejestrowania danych dotyczących umów cywilnoprawnych

(zlecenia, o dzieło). P

ERP.KAD.17 System musi zapewniać możliwość definiowania nowych rodzajów nieobecności. P ERP.KAD.18 System musi zapewniać możliwość definiowania obowiązujących systemów czasu pracy. P ERP.KAD.19 Możliwość tworzenia harmonogramów pracy dla wszystkich jednostek organizacyjnych w

szczególności zatrudniających personel medyczny. P

ERP.KAD.20 Możliwość nadawania uprawnień tak, aby użytkownik miał prawo wprowadzania grafików czasu pracy tylko dla wyznaczonej grupy pracowników.

P

ERP.KAD.21 Możliwość prowadzenia grafików osobno plan i wykonanie. P ERP.KAD.22 Możliwość zdefiniowania w systemie pory nocnej oraz świątecznej P ERP.KAD.23 Możliwość definiowanie zmian dostępnych w harmonogramie uwzględniających podstawowe

parametry: P

a) Nr zmiany b) Liczba godzin c) Godziny od – do pracy etatowej d) Godziny od - do dyżuru ERP.KAD.24 Możliwość wyświetlenia i filtrowania danych na harmonogramie P

ERP.KAD.25 Możliwość przeglądania harmonogramów w zależności od posiadanych uprawnień P ERP.KAD.26 Możliwość sprawdzenia dla pracownika norm wynikających z rozliczeń czasu pracy: P a) Okresu rozliczeniowego b) Norma dobowa - Ilość godzin do wypracowania wynikające z normy dobowej etatu c) Ilości godzin do przepracowania w danym okresie ERP.KAD.27 Możliwość wykonania po zdefiniowaniu harmonogramu walidacji poprawności pod kątem

zgodności z przepisami Kodeksu Pracy P

ERP.KAD.28 Możliwość przydzielanie harmonogramom statusu „Zatwierdzony” P ERP.KAD.29 System musi posiadać funkcje bilansu czasu pracy, który pozwoli na szczegółową rejestrację,

analizę i modyfikację godzin przepracowanych i absencji. P

ERP.KAD.30 System musi zapewniać możliwość rejestrowania absencji (nieobecności) pracownika, w tym co najmniej: data rozpoczęcia i zakończenia oraz rodzaj absencji, kod ZUS, miesiąc rozliczania tej absencji oraz przez kogo finansowana (ZUS, OFP)

P

ERP.KAD.31 System musi posiadać funkcję rejestracji urlopów planowanych. P ERP.KAD.32 System musi posiadać możliwość rejestracji absencji w sposób grupowy (jednocześnie dla wielu

pracowników). P

ERP.KAD.33 System musi zapewniać możliwość generacji deklaracji zgłoszeniowych do Programu Płatnik. P ERP.KAD.34 System musi umożliwić generację raportów podstawowych: P a) Umowa o pracę, b) Zmiana umowy o pracę, c) Wypowiedzenie umowy o pracę, d) Aneks do umowy o pracę, e) Świadectwo pracy, f) Zaświadczenie o pracy, g) Umowa o dzieło, h) Umowa zlecenie, i) Aneks do umowy o dzieło / zlecenie, j) Rozwiązanie umowy o pracę, k) Zestawienie pracowników, l) Zestawienie liczby pracowników, m) Kartoteka pracownika, n) Premie i dodatki do wynagrodzenia,


Strona 77 z 208


o) Lista umów o dzieło / zlecenia, p) Przebieg zatrudnienia, q) Konta bankowe pracowników. ERP.KAD.35 System musi umożliwiać edycję szablonów generowanych pism kadrowych (edycja może odbywać

się w edytorze tekstu zgodnym z MS Word). P

ERP.KAD.36 System musi umożliwić generacje raportów statystycznych: P a) Stan zatrudnienia wg etatów, b) Przeciętne zatrudnienie, c) Formularze GUS, d) Miesięczny stan zatrudnienia. ERP.KAD.37 System umożliwia elastyczne tworzenie raportów przez użytkowników na podstawie raportów

systemowych. Przed wydrukowaniem użytkownik ma możliwość wyboru danych poprzez filtrowanie, grupowanie danych

P

ERP.KAD.38 System musi zapewniać możliwość rozliczania zwolnień lekarskich dostarczonych po wypłacie wynagrodzenia, a dotyczących okresu za które zostało już wypłacone wynagrodzenie.

P

ERP.KAD.39 System musi posiadać funkcję do obsługi Pracowniczego Programu Emerytalnego tj. Ewidencji świadczeń dla byłych pracowników, którzy przeszli na emeryturę).

P

ERP.KAD.40 System musi umożliwiać obsługę PKZP (pracowniczej kasy zapomogowo – pożyczkowej) oraz pożyczek mieszkaniowych.

P

ERP.KAD.41 System musi umożliwiać wykonywanie operacji grupowych na danych kadrowych (np. grupowe wprowadzenie aneksów zmieniających stawkę zaszeregowania dla wskazanej jednostki organizacyjnej).

P

ERP.KAD.42 System musi umożliwić generację raportów kontrolnych: P a) Grafiki – plany pracy, b) Karta czasu pracy, c) Roczna karta czasu pracy, d) Absencje w podanym okresie, e) Lista obecności, f) Badania lekarskie, g) Zestawienie badań, h) Data ważności badania, i) Skierowanie na badania, j) Szkolenia w podanym okresie, k) Wymiar absencji należnych i pozostałych do wykorzystania, l) Staże wybranego rodzaju w podanym okresie, m) Okresy nie składkowe, n) Zestawienie obecności, o) Zmiany w umowach o pracę, p) Rozliczenia czasu pracy, q) Sposób zwolnienia pracowników, r) Urlopy planowane w podanym okresie, s) Odzież robocza – zamówienia wg rozmiarów, t) Odzież robocza – okres użytkowania.

VI.2.2.2.7. Płace


ERP.PLC.1 System musi zapewniać możliwość definiowania składników płacowych. Uprawniony użytkownik ma mieć możliwość modyfikowania sposobu działania algorytmu naliczającego płace.

P

ERP.PLC.2 System musi umożliwić sporządzanie list płac wg okresu rozliczeniowego w zakresie: P a) głównej listy płac, b) dodatkowej listy płac,


Strona 78 z 208


c) listy płac dla umów o dzieło / umowy zlecenie d) listy korekt w tym korekty składek ZUS.

ERP.PLC.3 System musi umożliwiać obsługą Zakładowego Funduszu Świadczeń Socjalnych. P ERP.PLC.4 System musi umożliwiać ewidencję świadczeń socjalnych oraz ich wypłatę. P ERP.PLC.5 System musi zapewniać możliwość przyznawania pracownikom dodatków do wynagrodzenia i

potrąceń: P

a) jednorazowych, b) czasowych. ERP.PLC.6 System musi zapewniać księgowanie listy płac bezpośrednio w księdze głównej. P ERP.PLC.7 System musi zapewniać możliwość wyrównania wynagrodzenia wstecz (np. gdy wyrównanie

następuje w czerwcu za okres od początku roku) indywidualnie lub grupowo. P

ERP.PLC.8 System musi posiadać funkcjonalność dokonywania korekt list płac do miesięcy zamkniętych (powodujące dopłaty jak też niedopłaty oraz wyrównania wynagrodzeń). Wyrównania na składnikach w listach korekt powinny naliczać się automatycznie.

P

ERP.PLC.9 System musi zapewnić możliwość prawidłowego wyliczenia zajęć komorniczych, obliczenia potrąceń kwotowych oraz procentowych liczonych od podstawy zgodnie z przepisami.

P

ERP.PLC.10 System musi zapewniać możliwość obliczenia średnich chorobowych stanowiących podstawę do wyliczenia wynagrodzenia lub zasiłku za czas niezdolności do pracy (choroby) (uwzględniając wartości składników wchodzących w dopełnieniu i w faktycznie wypłaconej kwocie oraz okresowych nagród, np. 13-ka wchodząca co miesiąc w 1/12 wysokości rocznej)

P

ERP.PLC.11 System musi obliczać podstawę do chorobowego na podstawie umowy o pracę oraz umów zleceń. P ERP.PLC.12 System musi umożliwić ewidencję danych podatkowych miesięcznych i rocznych (określając prawo

do odpowiednich kosztów). P

ERP.PLC.13 System musi posiadać kontrolę obowiązujących progów podatkowych i ZUS-owskich uwzględniającą również wypłaty z funduszu bezosobowego.

P

ERP.PLC.14 System musi umożliwić współpracę z Programem Płatnika w zakresie przesyłania deklaracji rozliczeniowych (DRA, RSA, RCA, RZA).

P

ERP.PLC.15 System musi umożliwić generację raportów związanych z pracownikiem. P ERP.PLC.16 System musi umożliwić generację raportów deklaracji PIT. P ERP.PLC.17 System musi umożliwić generację raportów z grupy zasiłki. P ERP.PLC.18 System musi umożliwić generację raportów związanych z listami płac. P ERP.PLC.19 System musi umożliwiać generację przelewów wypłat pracowników oraz przelewów

potrąceniowych P

VI.2.2.2.8. Sprzedaż


ERP.SPR.1 Możliwość definiowania dowolnej liczby dokumentów sprzedaży przez użytkownika. P

ERP.SPR.2 Wystawianie dokumentów sprzedaży - faktury, paragony, faktury zaliczkowe, faktury pro-forma, faktury korygujące, zbiorcze faktury korygujące, faktury upustowe, inne definiowalne rodzaje przez użytkownika.

P

ERP.SPR.3 Automatyczna numeracja dokumentów sprzedaży z możliwością ręcznej zmiany. P ERP.SPR.4 Definiowanie dokumentów sprzedaży (sposób numeracji, liczony od cen brutto, netto,

fiskalizowany, eksport, rodzaj dokumentu korygującego). P

ERP.SPR.5 Możliwość przyporządkowania do rodzaju dokumentów sprzedaży listy kontrahentów, którzy mogą być płatnikiem

P

ERP.SPR.6 Możliwość kopiowania dokumentów sprzedaży i faktur pro-forma na faktury sprzedaży P ERP.SPR.7 Możliwość zdefiniowania praw ograniczających czynności na fakturach:

a) potwierdzanie faktur b) modyfikację dat wystawienia, sprzedaży, terminu płatności c) modyfikację sposobu płatności d) modyfikację cenników e) modyfikację rabatów

P

ERP.SPR.8 Możliwość rozróżnienia na fakturze zamawiającego, nabywcy oraz odbiorcy P ERP.SPR.9 Możliwość rozróżnienia katalogu kontrahentów i katalogu osób fizycznych P ERP.SPR.10 Wystawianie pozycji faktur na podstawie danych z kartoteki usług P ERP.SPR.11 Możliwość seryjnego wystawiania dokumentów sprzedaży wg zdefiniowanych wcześniej wzorców. P


Strona 79 z 208


ERP.SPR.12 Możliwość wystawienia z systemu faktur tzn. zbiorczych (zamiast 10 faktur na koniec miesiąca wystawienie jednej zbiorczej)

P

ERP.SPR.13 Możliwość naliczania VAT od ceny netto lub brutto w zależności od rodzaju dokumentu P ERP.SPR.14 Możliwość naliczanie VAT jako sumy VAT po pozycjach dokumentu lub od sumy wartości netto P ERP.SPR.15 Możliwość p przygotowanie i wydruk rejestrów sprzedaży VAT. P ERP.SPR.16 Możliwość tworzenia w systemie korekt ilościowo-wartościowych P ERP.SPR.17 Możliwość wystawienia jednej korekty do wielu faktur P ERP.SPR.18 Możliwość automatycznego dekretowania dokumentów sprzedaży według ustalonych szablonów

księgowania. P

ERP.SPR.19 Możliwość dekretacji dokumentów sprzedaży w systemie P ERP.SPR.20 Możliwość automatycznego wystawiania dokumentów KP/KW (w kasie powiązanej z rejestrem

sprzedaży) P

ERP.SPR.21 Możliwość grupowego zatwierdzania dokumentów sprzedaży P ERP.SPR.22 Możliwość grupowego dekretowania dokumentów sprzedaży P ERP.SPR.23 Możliwość współpracy z drukarkami fiskalnymi (co najmniej protokoły zgodne z POSNET Thermal

2.01, 5v lub ELZAB Omega 2, Mera). P

ERP.SPR.24 Możliwość ustawienia sposobu fiskalizacji w zależności od rodzaju dokumentu (automatyczna lub na życzenie użytkownika).

P

ERP.SPR.25 Możliwość ustawienia fiskalizacji automatycznej dla kontrahenta P ERP.SPR.26 Możliwość wydruku dokumentów sprzedaży w walucie krajowej P ERP.SPR.27 Możliwość wydruku dokumentów sprzedaży w walucie obcej P ERP.SPR.28 Możliwość blokowania drukowania faktur niezatwierdzonych P ERP.SPR.29 System umożliwia obsługę transakcji wewnątrzwspólnotowych P ERP.SPR.30 Możliwość anulowania faktur niezatwierdzonych P ERP.SPR.31 Możliwość pobrania informacji do deklaracji rozliczeniowej VAT, PIT, CIT P ERP.SPR.32 Możliwość dowiązywania zaliczek do rejestrowanych dokumentów sprzedaży P

VI.2.2.2.9. Bankowość


ERP.BNK.1 Definiowanie rachunków bankowych prowadzonych w walucie krajowej, walutach obcych i mieszanych.

P

ERP.BNK.2 Możliwość uzyskania informacji o bieżącym saldzie wraz z obrotami konta bankowego na podstawie danych z wyciągów bankowych bez konieczności dekretacji poszczególnych pozycji wyciągu.

P

ERP.BNK.3 Wgląd w stany kont bankowych na dowolnie wybrany dzień. P

ERP.BNK.4 Wgląd w bieżący stan rozrachunków z kontrahentami i pracownikami. P

ERP.BNK.5 Możliwość przydziału różnych poziomów uprawnień: podgląd, ewidencja i dekretacja wyciągów bankowych.

P

ERP.BNK.6 Możliwość wczytywania wyciągów bankowych z systemów Homebanking. P

ERP.BNK.7 Możliwość automatycznego tworzenia raportów bankowych na podstawie zrealizowanych poleceń przelewu.

P

ERP.BNK.8 Możliwość automatycznej dekretacji wyciągów bankowych i pojedynczych operacji bankowych P

ERP.BNK.9 Możliwość uzyskania informacji o bieżącym saldzie wraz z obrotami konta bankowego na podstawie danych z wyciągów bankowych bez konieczności dekretacji poszczególnych pozycji wyciągu.

P

ERP.BNK.10 System powinien posiadać wbudowany słownik banków i ich oddziałów zawierający nazwę banku, dane adresowe oraz numer rozliczeniowy wraz z możliwością jego edycji.

P

ERP.BNK.11 Integracja kartoteki banków i oddziałów z kartoteką kontrahentów oraz kartoteką przelewów. P

ERP.BNK.12 Możliwość automatycznego generowania przelewów do spłaty zobowiązań w momencie wystawienia faktury zakupu

P

ERP.BNK.13 Możliwość ręcznej rejestracji przelewów P

ERP.BNK.14 Możliwość generowania przelewów z automatycznym uwzględnieniem należności i zobowiązań (np. dla kontrahenta posiadającego zobowiązania na kwotę 50zł oraz jednocześnie należności na kwotę 30 zł system powinien wygenerować przelew na kwotę 20zł)

P

ERP.BNK.15 System musi uniemożliwić generowanie przelewów ujemnych. P


Strona 80 z 208


ERP.BNK.16 Możliwość przeglądania w jednym miejscu przelewów które zostały już zapłacone i tych które czekają na zapłatę

P

ERP.BNK.17 Możliwość obsługi planu płatności w zakresie: a) generowanie planu płatności zobowiązań – zatwierdzanie płatności zgodnie z terminem

płatności, możliwość zmiany daty zapłaty na dowolny inny dzień b) rozbijanie płatności na operacje z różnymi terminami realizacji zapłaty c) generowanie przelewów na podstawie zatwierdzonego planu płatności

P

ERP.BNK.18 Możliwość kontroli salda rozrachunku podczas generowania przelewu P

ERP.BNK.19 Wydruk poleceń przelewu w różnych formatach: a) Układ pionowy na papierze wstępnie zadrukowanym (dwa duże oraz dwa małe

blankiety) b) Układ pionowy z wydrukiem szablonu (dwa duże oraz dwa małe blankiety)

P

ERP.BNK.20 Możliwość scalania niezrealizowanych przelewów kontrahenta w ramach jednej paczki przelewów P

ERP.BNK.21 Współpraca z systemami Homebanking (bankowość elektroniczna) P

ERP.BNK.22 Możliwość automatycznego przekazania paczki przelewów do systemu Homebanking (bankowość elektroniczna)

P

ERP.BNK.23 Możliwość automatycznego zadekretowania wcześniej wysłanych przelewów powracających w wyciągu bankowym

P

ERP.BNK.24 Możliwość automatycznego wstępnego rozpoznawania otrzymanych wpłat: według konta wpłacającego, według opisu zawierającego symbole należności, według nieuregulowanych sald

P

VI.2.2.2.10. Kasa


ERP.KAS.1 Możliwość prowadzenia dowolnej liczby kas P

ERP.KAS.2 Możliwość prowadzenia kas walutowych P

ERP.KAS.3 Bieżąca obsługa operacji kasowych, emitowanie dowodów KP, KW. P

ERP.KAS.4 Generowanie raportów kasowych i ich automatyczna dekretacja. P

ERP.KAS.5 Możliwość współpracy z urządzeniami fiskalnymi P

ERP.KAS.6 Możliwość wglądu w bieżący stan rozrachunków z kontrahentami i pracownikami. P

ERP.KAS.7 Możliwość wglądu w stany kas na dowolnie wybrany dzień P

ERP.KAS.8 Przydział uprawnień do poszczególnych kas, z możliwością wyróżnienia uprawnień dla kasjerów. P

ERP.KAS.9 Możliwość definiowania własnych rodzajów dowodów kasowych innych niż KP, KW np. rozliczenia zaliczki wraz z możliwością określenia zasad numeracji

P

ERP.KAS.10 Możliwość wprowadzania dokumentów zakupu bezpośrednio w kasie (zakupy gotówkowe). P

ERP.KAS.11 Możliwość wyszukania kontrahentów po dowolnej informacji wprowadzonej w kartotece kontrahenta np. nazwie, NIP, ulicy, mieście itp.

P

ERP.KAS.12 Wystawianie dokumentów KP podczas rejestracji dokumentów sprzedaży P

ERP.KAS.13 Definiowanie własnych słowników opisów operacji kasowych. P

ERP.KAS.14 Możliwość automatycznego dekretowania operacji kasowych według ustalonych szablonów księgowania.

P


VI.2.2.3.1. Instalacja, konfiguracja i inicjalizacja bazy danych

VI.2.2.3.2. Instalacja systemu ERP na serwerach

VI.2.2.3.3. Konfiguracja systemu ERP zgodnie z ustaleniami z Analizy Przedwdrożeniowej

VI.2.2.3.4. Instalacja oprogramowania klienckiego na stacjach roboczych

VI.2.2.3.5. Testy funkcjonalne

VI.2.2.3.6. Szkolenia użytkowników i administratorów



Strona 81 z 208

VI.2.2.4.1. Organizacja wdrożenia nie może zaburzyć pracy personelu u Uczestników

Projektu.



technicznej w dni robocze w godzinach od 7 do 15 z obsługą telefoniczną i przy

pomocy poczty elektronicznej.


VI.2.2.6.1. Etap I – po uruchomieniu i inicjalizacji systemu,

VI.2.2.6.2. Etap II – po pozytywnym zakończeniu testów funkcjonalnych,

VI.2.2.6.3. Etap III – po zakończeniu szkoleń.


VI.2.2.7.1. Brak.

VI.2.3. Centralna aplikacja BI

VI.2.3.1. Opis ogólny

Centralna aplikacja BI to rozwiązanie umożliwiające gromadzenie, analizę i raportowanie informacji

strategicznych z punktu widzenia zarządzania i nadzoru właścicielskiego nad podległymi podmiotami

leczniczymi.

W ramach okresowo generowanych zadań (miesięczne, kwartalne, półroczne, roczne - zgodnie z

ustalonym harmonogramem) podmiotom leczniczym będą udostępniane do wypełnienia

elektroniczne formularze. Dostęp do formularzy będzie się odbywał poprzez przeglądarkę internetową,

zaś dane wprowadzane w elektronicznych formularza będą gromadzone w warstwie regionalnej.

Użytkownik będzie posiadał możliwość wypełnienia formularza w całości lub jego zasilenia danymi za

pomocą interfejsu wymiany danych. W przypadku Uczestników Projektu, u których będą wdrażane w

ramach zamówienia systemy HIS i ERP zasilanie formularzy oraz Centralnej Aplikacji BI musi odbywać

się automatycznie dla danych, które Uczestnik Projektu posiada w systemie. W pozostałych

przypadkach zasilanie formularzy lub ich częściowe uzupełnianie ma się odbywać ręcznie. Będzie

również posiadał możliwość skorygowania istniejących danych oraz uzupełnienia brakujących danych.

System będzie weryfikował kompletność wprowadzonych danych. Ponieważ w rozwiązaniu nie będzie

zastosowany podpis elektroniczny, to każdy elektroniczny formularz będzie podlegał etapowi

akceptacji. W tym celu użytkownik wypełniający formularz będzie po zakończeniu zadania przekazywał

(za pomocą systemu) formularz do akceptacji. Osoba akceptująca (przełożony/dyrektor/inna

wyznaczona osoba) będzie miała możliwość cofnięcia elektronicznego formularza do poprawy lub

przekazania go do osoby koordynującej zadania sprawozdawczości w danym podmiocie leczniczym.

Osoba koordynująca zadania sprawozdawczości będzie uprawniona do przekazania (za pomocą


Strona 82 z 208

systemu) elektronicznego formularza do Urzędu Marszałkowskiego lub ewentualnie do cofnięcia

formularza w celu wykonania korekty danych. Role wypełniającego, akceptującego i przekazującego

mogą być łączone. Za pomocą powiadomień e-mail system będzie dodatkowo informował

użytkowników o zadaniach do wykonania.

Po przekazaniu do Urzędu Marszałkowskiego elektroniczny formularz będzie wstępnie weryfikowany.

Użytkownik będzie miał możliwość zatwierdzenia formularza lub jego cofnięcia do poprawy przez

podmiot leczniczy. Po zatwierdzeniu dane pochodzące z danego formularza stają się dostępne dla

raportów i analiz.

Rozwiązanie umożliwi również importowanie sprawozdań kwartalnych (w formacie XML)

przygotowywanych przez Narodowy Fundusz Zdrowia zgodnie z Rozporządzeniem MZ z dnia 27 lipca

2005r. w sprawie zakresu niezbędnych informacji gromadzonych w systemie informatycznym

Narodowego Funduszu Zdrowia oraz zakresu i sposobu ich przekazywania ministrowi właściwemu do

spraw zdrowia oraz wojewodom i sejmikom województw (Dz.U. 2005.152.1271 z późn. zm.). Po

zaimportowaniu system umożliwi prezentację tych danych w czytelnej formie.

VI.2.3.2. Wymagania


Nr wymagania Wymaganie

RSR.WO Wymagania ogólne

RSR.WO.1 System musi umożliwiać podmiotom leczniczym sprawozdawanie danych do centrum regionalnego

RSR.WO.2

System musi umożliwiać podmiotom leczniczym sprawozdawanie danych w układach miesięcznym, kwartalnym, półrocznym i rocznym, przy czym układ może być różny w zależności od zakresu sprawozdawanych danych.

RSR.WO.3 Dane są sprawozdawane w portalu WWW poprzez wypełnienie elektronicznych formularzy (w tym celu udostępnianych podmiotom leczniczym), akceptację i przekazanie do centrum regionalnego.

RSR.WO.4 Dane wprowadzane w formularzach są gromadzone w centrum regionalnym

RSR.WO.5 System musi umożliwiać zasilenie elektronicznych formularzy danymi pochodzącymi z lokalnych systemów podmiotów leczniczych

RSR.WO.6 System musi umożliwiać modyfikowanie danych w elektronicznych formularzach oraz ich uzupełnianie

RSR.WO.7 System musi weryfikować kompletność danych przed ich przekazaniem do centrum regionalnego

RSR.WO.8 System musi umożliwiać wykonywanie raportów opartych na danych przekazanych w elektronicznych formularzach

RSR.WO.9 Zestaw definicji elektronicznych formularzy zostanie dostarczony przez Wykonawcę zgodnie z wymaganiami Zamawiającego dotyczącymi zakresu raportów (załącznik do SIWZ)

RSR.WO.10 Zestaw predefiniowanych raportów zostanie dostarczony przez Wykonawcę zgodnie ze specyfikacją raportów przedstawioną w SIWZ

RSR.WO.11 Rozwiązanie musi umożliwiać rozbudowę funkcjonalną o nowe elektroniczne formularze i raporty bez konieczności programowania.

VI.2.3.2.2. Wsparcie sprawozdawczości


RSR.WS Wsparcie sprawozdawczości

RSR.WS.1 Rozwiązanie musi być oparte na silniku procesowym i posiadać możliwość definiowania ścieżek zatwierdzeń elektronicznych formularzy

RSR.WS.2 Rozwiązanie musi umożliwiać przygotowanie definicji elektronicznych formularzy, które będą dystrybuowane do podmiotów leczniczych celem wypełnienia

RSR.WS.3 System musi umożliwiać wersjonowanie definicji elektronicznych formularzy


Strona 83 z 208


RSR.WS.4 Elektroniczne formularze dla poszczególnych podmiotów leczniczych oparte na definicjach formularzy będą dystrybuowane w ramach zadań do wykonania

RSR.WS.5 System musi umożliwiać definiowanie harmonogramu dystrybucji formularzy (tj. dystrybucji zadań wypełnienia wraz z formularzami), w tym również usuwanie pozycji z harmonogramu

RSR.WS.6 Zadania wypełnienia formularzy dystrybuowane są do użytkowników (pracowników poszczególnych podmiotów leczniczych), którzy posiadają uprawnienia do wprowadzania danych na formularzach.

RSR.WS.7 System musi umożliwiać (użytkownikowi posiadającemu uprawnienia do wprowadzania danych) przeglądanie listy zadań do wykonania

RSR.WS.8 System musi umożliwiać pobranie (z listy zadań użytkownika) zadania do wykonania

RSR.WS.9 System musi umożliwiać wprowadzanie danych do elektronicznego formularza

RSR.WS.10 System musi udostępnić mechanizm umożliwiający (na żądanie użytkownika, którego zadaniem jest wypełnienie formularza) zasilenie danego formularza danymi pochodzącymi z lokalnego systemu podmiotu leczniczego

RSR.WS.11 Specyfikacja interfejs wymiany danych, z którego dane mają być zaczytane do danego formularza zostanie przygotowana przez Wykonawcę na etapie analizy przedwdrożeniowej

RSR.WS.12 System musi umożliwiać użytkownikowi uzupełnienie danych formularza, w przypadku gdy nie wszystkie dane zostały wypełnione za pomocą interfejsu wymiany danych

RSR.WS.13 System musi umożliwiać uzupełnianie danych formularza w wielu sesjach

RSR.WS.14 System musi umożliwiać wydruk danych z formularzy w czytelnej postaci, przy czym jeśli dany formularz dotyczy sprawozdań przygotowywanych na potrzeby zewnętrznych instytucji (np. RB-N), to wydruk musi mieć postać zgodną z postacią sprawozdania

RSR.WS.15 System musi sprawdzać kompletność wprowadzonych danych przed ich przekazaniem do akceptacji - system musi uniemożliwić przekazanie danych niekompletnych.

RSR.WS.16 System musi umożliwiać przekazanie wypełnionego formularza do akceptacji

RSR.WS.17 W wyniku przekazania do akceptacji osoba akceptująca otrzymuje zadanie akceptacji formularza wraz z wypełnionym kompletnym elektronicznym formularzem

RSR.WS.18 System musi umożliwiać użytkownikowi posiadającemu uprawnienia do akceptacji przeglądanie listy zadań do wykonania oraz pobranie wybranego zadania z listy celem jego wykonania

RSR.WS.19 System musi umożliwiać akceptującemu podgląd danych wypełnionego elektronicznego formularza

RSR.WS.20 System musi umożliwiać akceptującemu skierowanie elektronicznego formularza do poprawy

RSR.WS.21 System musi umożliwiać akceptującemu zaakceptowanie elektronicznego formularza

RSR.WS.22 System musi umożliwiać (odpowiedzialnemu za koordynację działań w zakresie sprawozdawczości) pracownikowi podmiotu leczniczego przekazywanie zaakceptowanych formularzy do centrum regionalnego.

RSR.WS.23 System musi umożliwiać użytkownikowi posiadającemu uprawnienia do przekazywania formularzy przeglądanie listy zadań do wykonania oraz pobranie wybranego zadania z listy celem jego wykonania

RSR.WS.24 System musi umożliwiać przekazującemu podgląd danych zaakceptowanego formularza

RSR.WS.25 System musi umożliwiać przekazującemu skierowanie formularza do poprawy

RSR.WS.26 System musi umożliwiać przekazującemu przekazanie formularza do centrum regionalnego

RSR.WS.27 Na liście zadań użytkownikowi (wprowadzającemu, akceptującemu, przekazującemu) prezentowane są (co najmniej):

RSR.WS.27.1 - identyfikator zadania

RSR.WS.27.2 - nazwa zadania

RSR.WS.27.3 - status zadania

RSR.WS.27.4 - data utworzenia zadania

RSR.WS.27.5 - przeterminowanie zadania (w formie innej kolorystyki przeterminowanego zadania)

RSR.WS.27.6 - czas dostępny na wykonanie zadania

RSR.WS.28 System musi umożliwiać uprawnionemu użytkownikowi Urzędu Marszałkowskiego:

RSR.WS.28.1 - przeglądanie listy zaakceptowanych formularzy udostępnionych przez podmioty lecznicze

RSR.WS.28.2 - podgląd wybranego formularz

RSR.WS.28.3 - skierowanie (cofnięcie) do poprawy wybranego formularza

RSR.WS.28.4 - zatwierdzenie wybranego formularza wskutek czego dane z formularza staną się widoczne dla raportów i analiz

RSR.WS.28.5 - przeglądanie historii dystrybuowanych formularzy oraz podgląd aktualnego statusu obsługi każdego z tych formularzy

RSR.WS.29 System uniemożliwia skierowanie do poprawy formularzy, które zostały ostatecznie zatwierdzone, zaś ich dane są dostępne dla raportów i analiz

RSR.WS.30 System musi za pomocą powiadomień mailowych informować użytkowników o:

RSR.WS.30.1 - zadaniach zleconych do wykonania

RSR.WS.30.2 - terminach realizacji tych zadań, w szczególności o pracach przeterminowanych


Strona 84 z 208


RSR.WS.30.3 - zadaniach dotyczących poprawy cofniętych formularzy

RSR.WS.31 System musi mieć zdefiniowany słownik oddziałów, poradni oraz pracowni dla poszczególnych sprawozdających podmiotów leczniczych, zaś dane pozycji muszą zawierać nazwę i specjalność komórki organizacyjnej oraz część VII i VIII kodu resortowego (zgodnie z rozporządzeniem w sprawie systemu resortowych kodów identyfikacyjnych i szczegółowych zasad ich nadawania (Dz. U. nr 77 poz. 464 z późn. zm.)

RSR.WS.32 System musi umożliwiać modyfikację i uzupełnianie ww. słownika (oddziałów, poradni oraz pracowni) przez Uczestnika Projektu

RSR.WS.33 System musi umożliwiać prowadzenie rejestru zakupów i likwidacji sprzętu medycznego podmiotów leczniczych

RSR.WS.34 System musi umożliwiać uprawnionemu użytkownikowi danego podmiotu leczniczego prowadzenie rejestru zakupów i likwidacji sprzętu medycznego obejmującego dane tego podmiotu leczniczego, w szczególności umożliwia:

RSR.WS.34.1 - przeglądanie i filtrowanie sprzętu wg kategorii

RSR.WS.34.2 - dodanie nowej pozycji

RSR.WS.34.3 - edycję danych pozycji

RSR.WS.34.4 - odnotowanie likwidacji sprzętu

RSR.WS.35 Zakres danych wprowadzanych dla pozycji:

RSR.WS.35.1 - nazwa

RSR.WS.35.2 - producent

RSR.WS.35.3 - model

RSR.WS.35.4 - numer seryjny

RSR.WS.35.5 - rok produkcji

RSR.WS.35.6 - wartość początkowa

RSR.WS.35.7 - komórka organizacyjna, w której znajduję się sprzęt

RSR.WS.35.8 - data od (zakupu)

RSR.WS.35.9 - data do (data likwidacji)

RSR.WS.35.10 - uwagi

RSR.WS.36 System musi umożliwiać uprawnionemu użytkownikowi Urzędu Marszałkowskiego przeglądanie rejestru zakupów i likwidacji sprzętu medycznego obejmującego dane z wszystkich podmiotów leczniczych, w szczególności umożliwia filtrowanie sprzętu wg kategorii, podmiotu leczniczego, okresu zakupu, okresu likwidacji

RSR.WS.37 Systemu udostępnia funkcjonalności tylko dla zalogowanych użytkowników

RSR.WS.38 Użytkownicy z danego podmiotu leczniczego mają dostęp wyłącznie do formularzy przeznaczonych dla tego podmiotu

RSR.WS.39 System musi umożliwiać zarządzanie użytkownikami oraz ich uprawnieniami

RSR.WS.40 System musi umożliwiać tworzenie użytkowników o uprawnieniach administratora lokalnego, przy czym uprawnienia te są ograniczone wyłącznie do administracji użytkownikami w ramach danego podmiotu leczniczego

VI.2.3.2.3. Analizy i raporty


RSR.AR Analiza i Raportowanie

RSR.AR.1 System musi udostępniać raporty, które muszą być oparte wyłącznie na danych pochodzących z elektronicznych formularzy udostępnianych podmiotom leczniczym w celu wypełnienia

RSR.AR.2 Dostęp do raportów jest możliwy poprzez przeglądarkę internetową po zalogowaniu

RSR.AR.3 Dostęp do raportów mają jedynie uprawnieni użytkownicy zlokalizowani w Urzędzie Marszałkowskim oraz Uczestnicy Projektu

RSR.AR.4 System musi udostępniać (co najmniej) następujące predefiniowane raporty (szczegółowe informacje o raportach znajdują się w załączniku do SIWZ):

RSR.AR.4.1 - realizacja świadczeń zdrowotnych w lecznictwie zamkniętym

RSR.AR.4.2 - realizacja świadczeń zdrowotnych w lecznictwie otwartym

RSR.AR.4.3 - sprawozdanie z wykonania umów NFZ

RSR.AR.4.4 - zestawienie kosztów w układzie kalkulacyjnym

RSR.AR.4.5 - informacja o sytuacji finansowej

RSR.AR.4.6 - informacja o przebiegu wykonania planu finansowego

RSR.AR.4.7 - sprawozdanie o zatrudnieniu

RSR.AR.4.8 - sprawozdanie finansowe – aktywa


Strona 85 z 208


RSR.AR.4.9 - sprawozdanie finansowe – pasywa

RSR.AR.4.10 - sprawozdanie finansowe - bilans skonsolidowany

RSR.AR.4.11 - struktura zobowiązań

RSR.AR.4.12 - analiza wskaźnikowa

RSR.AR.4.13 - sprawozdania RB-N i RB-Z

RSR.AR.4.14 - sprawozdanie o zapleczu diagnostycznym

RSR.AR.4.15 - sprawozdanie o strukturze leczonych

RSR.AR.4.16 - wykres wykonania planów finansowych

RSR.AR.4.17 - wykres kształtowania się poziomu zobowiązań

RSR.AR.4.18 - wykres rentowności netto przychodów oraz nadwyżki/niedoboru finansowego

RSR.AR.4.19 - wykres struktury przychodów

RSR.AR.4.20 - wykres struktury kosztów

RSR.AR.4.21 - wykres przychodów i kosztów ogółem

RSR.AR.4.22 - wykres struktury kosztów rodzajowych

RSR.AR.4.23 - wykres płynności finansowej

RSR.AR.5 Na etapie analizy przedwdrożeniowej Wykonawca i Zamawiający określą maksymalnie 10 dodatkowych predefiniowanych raportów bazujących na danych pochodzących z formularzy elektronicznych udostępnionych podmiotom leczniczym do wypełnienia w ramach Wsparcia sprawozdawczości.

RSR.AR.6 System musi umożliwiać porównywanie danych podmiotu leczniczego pomiędzy poszczególnymi okresami sprawozdawczymi

RSR.AR.7 System musi umożliwiać porównywanie danych za dany okres sprawozdawczy pomiędzy różnymi podmiotami leczniczymi

RSR.AR.8 System musi umożliwiać importowanie nowych raportów oraz nowych wersji istniejących raportów i ich publikację

RSR.AR.9 System musi umożliwiać eksport raportów co najmniej do formatów XLS oraz PDF

RSR.AR.10 System musi umożliwiać drukowanie raportów

RSR.AR.11 System musi umożliwiać udostępnienie raportów maksymalnie 50 użytkownikom, z zastrzeżeniem, że pracownicy UMWL (użytkownicy) muszą mieć dostęp do pełnego zakresu raportów natomiast pracownicy Uczestników Projektu (użytkownicy) muszą mieć dostęp tylko do raportów danego Uczestnika Projektu.

VI.2.3.2.4. Sprawozdawczość z NFZ


RSR.NFZ Sprawozdawczość z NFZ

RSR.NFZ.1 System musi umożliwiać import danych w formacie XML przekazywanych kwartalnie przez NFZ zgodnie z rozporządzeniem MZ z dnia 27 lipca 2005 27 lipca 2005 r. w sprawie zakresu niezbędnych informacji gromadzonych w systemie informatycznym Narodowego Funduszu Zdrowia oraz zakresu i sposobu ich przekazywania ministrowi właściwemu do spraw zdrowia oraz wojewodom i sejmikom województw (Dz.U.2005.152.1271 z późn. zm.)

RSR.NFZ.2 System musi umożliwiać import wsadowy z określonego zasobu dyskowego

RSR.NFZ.3 System musi umożliwiać ponowny import danych dla danego okresu sprawozdawczego

RSR.NFZ.4 System musi weryfikować czy dane przekazane przez NFZ posiadają strukturę danych zgodną z obowiązującym prawem

RSR.NFZ.5 System generuje raportu o ewentualnych błędach importu

RSR.NFZ.6 System musi umożliwiać przegląd danych o wykonanych operacjach importu danych

RSR.NFZ.7 System musi umożliwiać przeglądanie danych oraz ich prezentowanie w czytelnej formie dla użytkownika

VI.2.3.2.5. Obsługa raportów - system musi umożliwiać przynajmniej generowanie

poniższych raportów i zestawień:

VI.2.3.2.5.1. Realizacja świadczeń zdrowotnych lecznictwie otwartym.

a) Zestawienie musi być generowane miesięcznie.


Strona 86 z 208

b) Zestawienie musi zawierać poniższe informacje:

1 Kod resortowy cz. VII, cz. VIII

2 Nazwa poradni/pracowni

3 Jednostka kontraktowa

4 Liczba wykonanych porad

5 Liczba wykonanych świadczeń zdrowotnych (liczba punktów)

6 Wartość wykonanych świadczeń

7 Przychody

8 Przychody z Kontraktu (NFZ)

9 Koszty

10 Wynik finansowy

VI.2.3.2.5.2. Sprawozdanie z wykonania umów NFZ

a) Sprawozdanie musi być generowane miesięcznie.

b) Sprawozdanie musi zawierać rozbicie informacji na poszczególne oddziały NFZ.

c) Sprawozdanie musi zawierać poniższe informacje:

VI.2.3.2.5.3. Zestawienie kosztów w układzie kalkulacyjnym

a) Zestawienie musi zawierać koszty bezpośrednie i pośrednie dla każdej jednostki,

w podziale na poszczególne ośrodki powstawania kosztów rozumiane jako

komórki organizacyjne jednostki. W ramach każdego ośrodka powstawania

kosztów, koszty powinny być przedstawione w układzie rodzajowym.

b) Zestawienie musi być generowane miesięcznie.

c) Zestawienie musi zawierać informacje:

Kod OPK Nazwa OPK Rodzaj kosztów Koszty bezpośrednie Koszty pośrednie

VI.2.3.2.5.4. Informacja o sytuacji finansowej

a) Zestawienie z jednostek musi byś sprawozdawane miesięcznie.

1 Nr umowy

2 Rodzaj świadczeń zdrowotnych

3 Pierwotna wartość rocznego Kontraktu z NFZ

4 Wartość rocznego Kontraktu z NFZ wg stanu na dzień sprawozdawczy

5 Proporcjonalna wartość rocznego Kontraktu na dzień sprawozdawczy

6 Wykonanie narastająco Kontraktu na dzień sprawozdawczy

7 Wykonanie Kontraktu (procentowo)

8 Niewykonania

9 Nadwykonania

10 Wartość zafakturowana narastająco do Kontraktu

11 Wartość niezafakturowana narastająco do Kontraktu


Strona 87 z 208

b) Na poziomie regionalnym musi być możliwość sprawdzania dynamiki zmian dla

poszczególnych pozycji zestawiania pomiędzy wskazanymi okresami z dodatkową

możliwością porównania pomiędzy wskazanymi jednostkami.

c) Zestawienie musi zawierać informacje w podziale na plan i wykonanie :

1 A. Przychody netto ze sprzedaży i zrównane z nimi, w tym:

2 I. Przychody netto ze sprzedaży produktów, z tego

3 usługi działalności medycznej, w tym:

4 sprzedanych NFZ

5 osoby fizyczne

6 pracodawcy

7 pozostałe

8 usługi niemedyczne, w tym:

9 wynajem pomieszczeń

10 czynsze za mieszkania i hotele

11 pozostałe

12 II. Przychody ze sprzedaży towarów i materiałów

13 III. Inne przychody

14 IV. Zmiana stanu produktów

15 V. Koszty wytworzenia produktów na własne potrzeby jednostki

16 VI. Przychody netto ze sprzedaży towarów i materiałów

17 B. Pozostałe przychody operacyjne

18 darowizny i zapisy otrzymane

19 dotacje otrzymane

20 uzyskane kary, grzywny, odszkodowania

21 świadczenia ponadlimitowe uznane przez NFZ

22 pozostałe

23 C. Przychody finansowe

24 odsetki uzyskane z lokat

25 odsetki od należności od odbiorców

26 przychody z udziałów i akcji, dywidendy

27 pozostałe

28 D. Zyski nadzwyczajne

29 E. Razem przychody

30 F. Koszty działalności operacyjnej

31 zużycie materiałów i energii, w tym:

32 leki (w tym krew i preparaty krwiopochodne)

33 materiały opatrunkowe i sprzęt jednorazowego użytku

34 energia (cieplna, elektryczna, gaz)

35 pozostałe

36 usługi obce, w tym:

37 transportowe

38 remontowo-konserwacyjne

39 wyżywienie chorych

40 pocztowo - telekomunikacyjne

41 medyczne obce, w tym:


Strona 88 z 208

42 kontrakty i konsultacje lekarskie

43 kontrakty pielęgniarskie

44 pozostałe kontrakty

45 pozostałe

46 czynsze oraz usługi związane z najmem i dzierżawą.

47 nieruchomości oraz zarządzaniem nieruchomościami

48 usługi utrzymania czystości

49 pozostałe

50 podatki i opłaty, w tym:

51 podatek od nieruchomości

52 opłaty dzierżawne

53 wpłaty na PFRON

54 pozostałe

55 wynagrodzenia, w tym:

56 administracja

57 personel medyczny, w tym:

58 lekarze

59 pielęgniarki

60 pozostałe

61 pozostałe wynagrodzenia

62 ubezpieczenie społeczne i inne świadczenia, w tym:

63 składki na Fundusz Ubezpieczeń Społecznych i Fundusz Pracy

64 składki na Fundusz Gwarantowanych Świadczeń Pracowniczych

65 odpis na ZFSS

66 koszty kursów, szkoleń

67 pozostałe

68 amortyzacja środków trwałych oraz wartości niematerialnych i prawnych

69 pozostałe koszty rodzajowe, w tym:

70 ubezpieczenia OC i majątkowe

71 koszty podróży służbowych

72 pozostałe

73 wartość sprzedanych towarów i materiałów

74 G. Pozostałe koszty operacyjne

75 darowizny i zapisy przekazane

76 zapłacone kary, grzywny, odszkodowania

77 koszty postępowania sądowego i egzekucyjnego

78 odpis aktualizacyjny z należności z NFZ, za świadczenia ponad limit

79 pozostałe

80 H. Koszty finansowe

81 odsetki od zaciągniętych pożyczek

82 odsetki od kredytów

83 odsetki od zobowiązań wobec dostawców

84 pozostałe

85 I. Straty nadzwyczajne

86 J. Razem koszty

87 K. Wynik na sprzedaży (A-F)


Strona 89 z 208

88 L. Wynik na działalności finansowej (C-H)

89 Ł. Wynik brutto na całokształcie działalności

90 M. Wynik finansowy-Zysk/Strata (brutto)

91 N. Podatek dochodowy

92 O. Pozostałe obowiązkowe zmniejszenie zysku (zwiększenie straty)

93 P. Wynik finansowy - Zysk/Strata (netto)

94 R. Wynik finansowy ogółem netto + amortyzacja

VI.2.3.2.5.5. Informacja o przebiegu wykonania planu finansowego

a) Ze strony jednostek muszą być sprawozdawane informacje o planie finansowym

dla jednostki oraz o jego realizacji.

b) Na poziomie warstwy regionalnej informacje te muszą być pozyskiwane w postaci

raportu zawierającego informacje o planie oraz o jego wykonaniu wartościowo

oraz procentowo.

c) Zestawienie musi zawierać poniższe informacje :

1 A. Przychody netto ze sprzedaży i zrównane z nimi, w tym:

2 I. Przychody netto ze sprzedaży produktów

3 w tym: sprzedanych NFZ

4 II. Zmiana stanu produktów

5 III. Koszty wytworzenia produktów na własne potrzeby jednostki

6 IV. Przychody netto ze sprzedaży towarów i materiałów

7 B. Pozostałe przychody operacyjne

8 I. Zysk ze zbycia niefinansowych aktywów trwałych

9 II. Dotacje

10 III. Inne przychody operacyjne

11 C. Przychody finansowe

12 w tym: odsetki

13 D. Zyski nadzwyczajne

14 E. Razem przychody

15 F. Koszty działalności operacyjnej

16 I. Amortyzacja

17 II. Zużycie materiałów i energii

18 III. Usługi obce

19 IV. Podatki i opłaty

20 V. Wynagrodzenia

21 VI. Ubezpieczenia społeczne i inne świadczenia

22 VII. Pozostałe koszty rodzajowe

23 VIII. Wartość sprzedanych towarów i materiałów

24 G. Pozostałe koszty operacyjne

25 I. Strata ze zbycia niefinansowych aktywów trwałych

26 II. Aktualizacja wartości aktywów niefinansowych

27 III. Inne koszty operacyjne

28 H. Koszty finansowe

29 w tym: odsetki

30 I. Straty nadzwyczajne

31 J. Razem koszty

32 K. Wynik finansowy-Zysk/Strata (brutto)

33 L. Podatek dochodowy


Strona 90 z 208

34 Ł. Pozostałe obowiązkowe zmniejszenie zysku (zwiększenie straty)

35 M. Wynik finansowy - Zysk/Strata (netto)

1 Dotacje z budżetu państwa lub budżetów jednostek samorządu terytorialnego

2 Środki na wydatki majątkowe

3 Stan należności na początek roku

4 Stan należności na koniec roku

5 Stan zobowiązań na początek roku

6 Stan zobowiązań na koniec roku

7 Stan środków pieniężnych na początek roku

8 Stan środków pieniężnych na koniec roku

VI.2.3.2.5.6. Sprawozdanie o zatrudnieniu

a) Sprawozdanie musi być generowane kwartalnie.

b) System musi umożliwiać porównanie danych pomiędzy wybranymi okresami oraz

jednostkami.

c) Sprawozdanie musi zawierać informacje o licznie osób, etatów oraz średniego

wynagrodzenia dla poszczególnych oddziałów / poradni jednostki w podziale na

grupy zawodowe :

1 Lekarze

2 Lekarze stomatolodzy

3 Pielęgniarki

4 Położne

5 Farmaceuci

6 Inny z wykształceniem wyższym medycznym

7 Pielęgniarki

8 Położne

9 Technicy medyczni

10 Personel średni medyczny

11 Personel niższy medyczny

12 Personel administracyjny

13 Personel gospodarczy i obsługi

VI.2.3.2.5.7. Sprawozdania finansowe – Aktywa

a) Sprawozdanie powinno być generowane dla danych rocznych oraz półrocznych.

b) Sprawozdanie powinno zawierać poniższe informacje:

1 A. Aktywa trwałe

2 I. Wartości niematerialne i prawne

3 1. Koszty zakończonych prac rozwojowych

4 2. Wartość firmy

5 3. Inne wartości niematerialne i prawne

6 4. Zaliczki na wartości niematerialne i prawne


Strona 91 z 208

7 II. Rzeczowe aktywa trwałe

8 1. Środki trwałe

9 a) grunty (w tym prawo użytkowania wieczystego gruntu)

10 b) budynki, lokale i obiekty inżynierii lądowej i wodnej

11 c) urządzenia techniczne i maszyny

12 d) środki transportu

13 e) inne środki trwałe

14 2. Środki trwałe w budowie

15 3. Zaliczki na środki trwałe w budowie

16 III. Należności długoterminowe

17 1. Od jednostek powiązanych

18 2. Od pozostałych jednostek

19 IV. Inwestycje długoterminowe

20 1. Nieruchomości

21 2. Wartości niematerialne i prawne

22 3. Długoterminowe aktywa finansowe

23 a) w jednostkach powiązanych

24 - udziały lub akcje

25 - inne papiery wartościowe

26 - udzielone pożyczki

27 - inne długoterminowe aktywa finansowe

28 b) w pozostałych jednostkach




32 - inne długoterminowe aktywa finansowe

33 4. Inne inwestycje długoterminowe

34 V. Długoterminowe rozliczenia międzyokresowe

35 1. Aktywa z tytułu odroczonego podatku dochodowego

36 2. Inne rozliczenia międzyokresowe

37 B. Aktywa obrotowe

38 I. Zapasy

39 1. Materiały

40 2. Półprodukty i produkty w toku

41 3. Produkty gotowe

42 4. Towary

43 5. Zaliczki na dostawy

44 II. Należności krótkoterminowe

45 1. Należności od jednostek powiązanych

46 należności z tytułu dostaw i usług, w tym:

47 należności z zakładów opieki zdrowotnej, z tego:

48 wymagalne

49 inne należności, z tego:

50 wymagalne

51 2. Należności od pozostałych jednostek

52 należności z tytułu dostaw i usług, w tym:


Strona 92 z 208

53 NFZ, z tego:

54 wymagalne

55 z tyt. pozostałych dostaw i usług, z tego;

56 wymagalne

57 należności z zakładów opieki zdrowotnej, z tego:

58 wymagalne

59 należności od osób fizycznych, z tego:

60 wymagalne

61 b) z tytułu podatków, dotacji, ceł, ubezpieczeń społecznych i zdrowotnych oraz innych świadczeń

62 inne należności, z tego:

63 wymagalne

64 Należności wymagalne ogółem

65 d) dochodzone na drodze sądowej

66 III. Inwestycje krótkoterminowe

67 1. Krótkoterminowe aktywa finansowe

68 a) w jednostkach powiązanych




72 - inne krótkoterminowe aktywa finansowe

73 b) w pozostałych jednostkach




77 - inne krótkoterminowe aktywa finansowe

78 c) środki pieniężne i inne aktywa pieniężne

79 środki pieniężne w kasie

80 środki na rachunkach bankowych

81 - inne środki pieniężne

82 - inne aktywa pieniężne

83 2. Inne inwestycje krótkoterminowe

84 IV. Krótkoterminowe rozliczenia międzyokresowe

85 Aktywa razem

VI.2.3.2.5.8. Sprawozdania finansowe – Pasywa

a) Sprawozdanie powinno być generowane dla danych rocznych oraz półrocznych.

b) Sprawozdanie powinno zawierać poniższe informacje:

1 A. Kapitał (fundusz) własny

2 I. Kapitał (fundusz) podstawowy

3 II. Należne wpłaty na kapitał podstawowy (wielkość ujemna)

4 III. Udziały (akcje) własne (wielkość ujemna)

5 IV. Kapitał (fundusz) zapasowy

6 V. Kapitał (fundusz) z aktualizacji wyceny


Strona 93 z 208

7 VI. Pozostałe kapitały (fundusze) rezerwowe

8 VII. Zysk (strata) z lat ubiegłych

9 VIII. Zysk (strata) netto

10 IX. Odpisy z zysku netto w ciągu roku obrotowego (wielkość ujemna)

11 B. Zobowiązania i rezerwy na zobowiązania

12 1. Rezerwa z tytułu odroczonego podatku dochodowego

13 2. Rezerwa na świadczenia emerytalne i podobne

14 - długoterminowa

15 - krótkoterminowa

16 3. Pozostałe rezerwy

17 - długoterminowe

18 - krótkoterminowe

19 II. Zobowiązania długoterminowe

20 1. Wobec jednostek powiązanych

21 2. Wobec pozostałych jednostek

22 kredyty, z tego:

23 wymagalne

24 pożyczki, z tego:

25 wymagalne

26 inne zobowiązania długoterminowe, z tego:

27 wymagalne

28 b) z tytułu emisji dłużnych papierów wartościowych

29 wymagalne

30 c) inne zobowiązania finansowe

31 wymagalne

32 inne zobowiązania długoterminowe, z tego:

33 wymagalne

34 III. Zobowiązania krótkoterminowe

35 1. Wobec jednostek powiązanych

36 a) z tytułu dostaw i usług, o okresie wymagalności:

37 - do 12 miesięcy

38 - powyżej 12 miesięcy

39 b) inne

40 2. Wobec pozostałych jednostek

41 kredyty, z tego:

42 wymagalne

43 pożyczki, z tego:

44 wymagalne

45 z tyt. dostaw i usług, w tym:

46 z tytułu leków i materiałów medycznych, z tego:

47 wymagalne

48 z tytułu zakupu sprzętu medycznego, z tego:

49 wymagalne

50 z tytułu pozostałych dostaw i usług, z tego:

51 wymagalne

52 z tyt. podatków, ceł, ubezpieczeń i innych świadczeń, w tym:


Strona 94 z 208

53 ZUS, z tego:

54 wymagalne

55 Urząd Skarbowy, z tego:

56 wymagalne

57 inne, z tego:

58 wymagalne

59 z tytułu wynagrodzeń, z tego:

60 wymagalne

61 inne zobowiązania krótkoterminowe, z tego:

62 wymagalne

63 Zobowiązania ogółem, w tym:

64 wymagalne

65 3. Fundusze specjalne

66 IV. Rozliczenia międzyokresowe

67 1. Ujemna wartość firmy

68 2. Inne rozliczenia międzyokresowe

69 - długoterminowe

70 - krótkoterminowe

71 Pasywa razem

VI.2.3.2.5.9. Sprawozdania finansowe – bilans skonsolidowany

a) Sprawozdanie powinno zawierać zbiorczo informacje dotyczące pasywów i

aktywów.

b) Sprawozdanie powinno być generowane dla danych rocznych.

VI.2.3.2.5.10. Struktura zobowiązań

a) Zestawienie powinno generowane kwartalnie.

b) Zestawienie powinno zawierać poniższe informacje z odrębnym wyróżnieniem

wartości dla zobowiązań wymaganych.

1 Zobowiązania ogółem

2 Zobowiązania wobec Zakładu Ubezpieczeń Społecznych

3 Zobowiązania wobec Urzędu Skarbowego

4 Zobowiązania wobec PFRON

5 Zobowiązania z tytułu pożyczki restrukturyzacyjnej

6 Zobowiązania z tytułu pożyczek udzielonych przez jednostki samorządu terytorialnego

7 Zobowiązania z tytułu pożyczek i kredytów - inne

8 Zobowiązania z tytułu zakupu leków i materiałów medycznych

9 Zobowiązania tytułu zakupu sprzętu i aparatury medycznej

10 Zobowiązania z tytułu zużycia energii, gazu, wody

11 Zobowiązania z tytułu zakupu usług obcych

12 Zobowiązania wobec pracowników

13 Zobowiązania pozostałe zobowiązania publicznoprawne

14 Zobowiązania pozostałe zobowiązania cywilnoprawne


Strona 95 z 208

15 Rezerwy utworzone a zobowiązania z tyt. "ustawy 203"

16 Zobowiązania zakładu, przekazane przez wierzycieli pierwotnych innym podmiotom

VI.2.3.2.5.11. Analiza wskaźnikowa

a) Analiza powinna być generowana miesięcznie, kwartalnie, półrocznie i rocznie.

b) System powinien udostępniać poniższe wskaźniki :

1 Wskaźniki rentowności

2 Rentowność majątku (ROA)

3 Rentowność netto sprzedaży

4 Rentowność netto

5 Rentowność kapitału własnego (ROE)

6 Rentowność zasobów osobowych (ROSE)

7 Rentowność działalności operacyjnej

8 Wskaźniki płynności finansowej

9 Wskaźnik płynności bieżącej (I)

10 Wskaźnik płynności szybkiej (II)

11 Wskaźnik płynności natychmiastowej (III)

12 Wskaźnik handlowej zdolności kredytowej

13 Wskaźniki zadłużenia

14 Wskaźnik ogólnego zadłużenia

15 Wskaźnik zadłużenia długoterminowego

16 Wskaźnik zadłużenia kapitału własnego

17 Wskaźniki rotacji (obrotowość)

18 Wskaźnik rotacji należności w dniach

19 Szybkość obrotu należnościami

20 Stopień spłaty zobowiązań

21 Wskaźnik rotacji zobowiązań w dniach

22 Wskaźnik produktywności aktywów ogółem

23 Wskaźnik obrotowości (rotacji należności)

24 Wskaźniki do analizy poziomej i pionowej bilansu

25 Złota reguła bilansowania

26 Złota reguła bilansowania II

27 Złota reguła finansowania

28 Wskaźniki struktury kosztów

29 Pozostałe wskaźniki

30 Nadwyżka finansowa/niedobór finansowy

31 Wskaźnik EBITDA

32 Wskaźnik zastosowania kapitału własnego (ZKW)

33 Wskaźnik zastosowania kapitału obcego (ZKO)

34 Wskaźnik ogólnej sytuacji finansowej (ZKW x ZKO)

35 Wskaźnik poziomu wynagrodzeń i pochodnych w przychodach z NFZ

36 Wskaźnik poziomu kosztów

37 Wydajność pracy

38 Wskaźnik wykorzystania łóżek

39 Wskaźnik struktury przychodów

VI.2.3.2.5.12. Sprawozdania RB-N i RB-Z


Strona 96 z 208

a) System musi umożliwiać generowanie sprawozdań RB-N i RB-Z zgodnie ze wzorem

opublikowanym przez ustawodawcę.

VI.2.3.2.5.13. Sprawozdanie RB-27S - Miesięczne / roczne sprawozdanie z wykonania

planu dochodów budżetowych:

a) System musi umożliwiać generowanie sprawozdania RB-27S zgodnie ze wzorem

opublikowanym przez ustawodawcę w tym:

a. Klasyfikacja budżetowa: dział – rozdział – paragraf

b. Plan (po zmianach)

c. Dochody wykonane (wpływy minus zwroty)

d. Dochody otrzymane

wypełniać tylko za miesiące: marzec, czerwiec i wrzesień oraz za rok

sprawozdawczy:

e. Należności (salda początkowe plus przypisy minus odpisy)

f. Potrącenia (art.65 i art. 66 §1pkt 2 ustawy z dn. 29 sierpnia 1997r.-

Ordynacja podatkowa)

g. Saldo końcowe:

1. Należności pozostałe do zapłaty ogółem, w tym:

zaległości

2. Nadpłaty

VI.2.3.2.5.14. Sprawozdanie RB-28S - Miesięczne / roczne sprawozdanie z wykonania

planu wydatków budżetowych

a) System musi umożliwiać generowanie sprawozdania RB-28S zgodnie ze wzorem

opublikowanym przez ustawodawcę w tym:

a. Klasyfikacja budżetowa: dział – rozdział – paragraf

b. Plan (po zmianach)

c. Zaangażowanie

d. Wydatki wykonane

e. Zobowiązania wg stanu na koniec okresu sprawozdawczego ogółem:

1. W tym wymagalne:

powstałe w latach ubiegłych

powstałe w roku bieżącym

wypełniać tylko za rok sprawozdawczy:

f. Wydatki zrealizowane w ramach funduszu sołeckiego (o ile dotyczy)

g. Wydatki, które nie wygasły z upływem roku budżetowego (art. 263 ust.1

ustawy o finansach publicznych)

VI.2.3.2.5.15. Sprawdzanie o zapleczu diagnostycznym


Strona 97 z 208

a) Sprawozdanie musi być generowane kwartalnie

b) Sprawozdanie musi zawierać informację o liczbie posiadanej aparatury oraz o

liczbie wykonanych zabiegach w danym okresie.

c) Informacje w liczbowe w sprawozdaniu powinny się odnosić do poniższych

kategorii aparatury :

1 Aparaty EKG

2 Aparaty KTG

3 Aparaty EEG

4 Aparaty EMG

5 Aparaty RTG, w tym:

6 - aparaty RTG z opcją naczyniową i obróbką cyfrową

7 - aparaty RTG z torem wizyjnym

8 - pozostałe

9 Aparaty USG, w tym:

10 - kardiologiczne

11 - pozostałe

12 Gammakamera

13 Mammograf

14 Tomograf komputerowy

15 Rezonans Magnetyczny

16 Urządzenie magnetycznego rezonansu jądrowego

17 Litotrypter

18 Laseroterapia

19 Analizator biochemiczny wieloparametrowy

20 Akcelerator liniowy

21 Respirator, w tym:

22 - dla dorosłych

23 - dla dzieci

24 Aparat do znieczulenia ogólnego

25 Stoły operacyjne

26 Inkubatory

27 Urządzenie angiograficzne, zestaw do badań naczyniowych

28 Aparatura endoskopowa, w tym:

29 - gastroskop

30 - kolonoskop

31 - bronchoskop

32 - laparoskop

33 - pozostałe

VI.2.3.2.6. Wymagania narzędziowe i sprzętowe

VI.2.3.2.6.1. System bazodanowy (SBD):

VI.2.3.2.6.1.1. Możliwość wykorzystania SBD jako silnika relacyjnej bazy danych, analitycznej, wielowymiarowej bazy danych, platformy bazodanowej dla wielu aplikacji. Powinien zawierać serwer raportów i narzędzia do definiowania raportów, wykonywania analiz biznesowych, tworzenia procesów ETL.

VI.2.3.2.6.1.2. Zintegrowane narzędzia graficzne do zarządzania systemem – SBD musi dostarczać zintegrowane narzędzia do zarządzania i konfiguracji


Strona 98 z 208

wszystkich usług wchodzących w skład systemu (baza relacyjna, usługi analityczne, usługi raportowe, usługi transformacji danych). Narzędzia te muszą udostępniać możliwość tworzenia skryptów zarządzających systemem oraz automatyzacji ich wykonywania.

VI.2.3.2.6.1.3. Zarządzanie serwerem za pomocą skryptów - SBD musi udostępniać mechanizm zarządzania systemem za pomocą uruchamianych z linii poleceń skryptów administracyjnych, które pozwolą zautomatyzować rutynowe czynności związane z zarządzaniem serwerem.

VI.2.3.2.6.1.4. Dedykowana sesja administracyjna - SBD musi pozwalać na zdalne połączenie sesji administratora systemu bazy danych w sposób niezależny od normalnych sesji klientów.

VI.2.3.2.6.1.5. Możliwość automatycznej aktualizacji systemu - SBD musi umożliwiać automatyczne ściąganie i instalację wszelkich poprawek producenta oprogramowania (redukowania zagrożeń powodowanych przez znane luki w zabezpieczeniach oprogramowania).

VI.2.3.2.6.1.6. SBD musi umożliwiać tworzenie klastrów niezawodnościowych. VI.2.3.2.6.1.7. Możliwość zastosowania reguł bezpieczeństwa - wsparcie dla

zdefiniowanej polityki bezpieczeństwa (np. automatyczne wymuszanie zmiany haseł użytkowników, zastosowanie mechanizmu weryfikacji dostatecznego poziomu komplikacji haseł wprowadzanych przez użytkowników), możliwość zintegrowania uwierzytelniania użytkowników z Active Directory.

VI.2.3.2.6.1.8. Możliwość definiowania reguł administracyjnych dla serwera lub grupy serwerów - SBD musi mieć możliwość definiowania reguł wymuszanych przez system i zarządzania nimi. Przykładem takiej reguły jest uniemożliwienie użytkownikom tworzenia obiektów baz danych o zdefiniowanych przez administratora szablonach nazw. Dodatkowo wymagana jest możliwość rejestracji i raportowania niezgodności działającego systemu ze wskazanymi regułami, bez wpływu na jego funkcjonalność.

VI.2.3.2.6.1.9. Rejestrowanie zdarzeń silnika bazy danych w czasie rzeczywistym - SBD musi posiadać możliwość rejestracji zdarzeń na poziomie silnika bazy danych w czasie rzeczywistym w celach diagnostycznych, bez ujemnego wpływu na wydajność rozwiązania, pozwalać na selektywne wybieranie rejestrowanych zdarzeń. Wymagana jest rejestracja zdarzeń:

VI.2.3.2.6.1.9.1. odczyt/zapis danych na dysku dla zapytań wykonywanych do baz danych (w celu wychwytywania zapytań znacząco obciążających system),

VI.2.3.2.6.1.9.2. wykonanie zapytania lub procedury trwające dłużej niż zdefiniowany czas (wychwytywanie długo trwających zapytań lub procedur),

VI.2.3.2.6.1.9.3. para zdarzeń zablokowanie/zwolnienie blokady na obiekcie bazy (w celu wychwytywania długotrwałych blokad obiektów bazy).

VI.2.3.2.6.1.10. Zarządzanie pustymi wartościami w bazie danych - SBD musi efektywnie zarządzać pustymi wartościami przechowywanymi w bazie danych (NULL). W szczególności puste wartości wprowadzone do bazy danych powinny zajmować minimalny obszar pamięci.

VI.2.3.2.6.1.11. Definiowanie nowych typów danych - SBD musi umożliwiać definiowanie nowych typów danych wraz z definicją specyficznej dla tych typów danych logiki operacji. Jeśli np. zdefiniujemy typ do przechowywania danych hierarchicznych, to obiekty tego typu powinny udostępnić operacje


Strona 99 z 208

dostępu do „potomków” obiektu, „rodzica” itp. Logika operacji nowego typu danych powinna być implementowana w zaproponowanym przez Dostawcę języku programowania. Nowe typy danych nie mogą być ograniczone wyłącznie do okrojenia typów wbudowanych lub ich kombinacji.

VI.2.3.2.6.1.12. Wsparcie dla technologii XML - SBD musi udostępniać mechanizmy składowania i obróbki danych w postaci struktur XML. W szczególności musi:

VI.2.3.2.6.1.12.1. udostępniać typ danych do przechowywania kompletnych dokumentów XML w jednym polu tabeli,

VI.2.3.2.6.1.12.2. udostępniać mechanizm walidacji struktur XML-owych względem jednego lub wielu szablonów XSD,

VI.2.3.2.6.1.12.3. udostępniać język zapytań do struktur XML, VI.2.3.2.6.1.12.4. udostępniać język modyfikacji danych (DML) w strukturach

XML (dodawanie, usuwanie i modyfikację zawartości struktur XML),

VI.2.3.2.6.1.12.5. udostępniać możliwość indeksowania struktur XML-owych w celu optymalizacji wykonywania zapytań.

VI.2.3.2.6.1.13. Możliwość tworzenia funkcji i procedur w innych językach programowania - SBD musi umożliwiać tworzenie procedur i funkcji z wykorzystaniem innych języków programowania, niż standardowo obsługiwany język zapytań danego SBD. System musi umożliwiać tworzenie w tych językach m.in. agregujących funkcji użytkownika oraz wyzwalaczy. Dodatkowo musi udostępniać środowisko do debuggowania.

VI.2.3.2.6.1.14. Możliwość tworzenia rekursywnych zapytań do bazy danych - SBD musi udostępniać wbudowany mechanizm umożlwiający tworzenie rekursywnych zapytań do bazy danych bez potrzeby pisania specjalnych procedur i wywoływania ich w sposób rekurencyjny.

VI.2.3.2.6.1.15. Obsługa błędów w kodzie zapytań - język zapytań i procedur w SBD musi umożliwiać zastosowanie mechanizmu przechwytywania błędów wykonania procedury (na zasadzie bloku instrukcji TRY/CATCH) – tak jak w klasycznych językach programowania.

VI.2.3.2.6.1.16. Raportowanie zależności między obiektami - SBD musi udostępniać informacje o wzajemnych zależnościach między obiektami bazy danych.

VI.2.3.2.6.1.17. Mechanizm zamrażania planów wykonania zapytań do bazy danych - SBD musi udostępniać mechanizm pozwalający na zamrożenie planu wykonania zapytania przez silnik bazy danych (w wyniku takiej operacji zapytanie jest zawsze wykonywane przez silnik bazy danych w ten sam sposób). Mechanizm ten daje możliwość zapewnienia przewidywalnego czasu odpowiedzi na zapytanie po przeniesieniu systemu na inny serwer (środowisko testowe i produkcyjne), migracji do innych wersji SBD, wprowadzeniu zmian sprzętowych serwera.

VI.2.3.2.6.1.18. System transformacji danych - SBD musi posiadać narzędzie do graficznego projektowania transformacji danych. Narzędzie to powinno pozwalać na przygotowanie definicji transformacji w postaci pliku, które potem mogą być wykonywane automatycznie lub z asystą operatora. Transformacje powinny posiadać możliwość graficznego definiowania zarówno przepływu sterowania (program i warunki logiczne) jak i przepływu strumienia rekordów poddawanych transformacjom. Powinna być także zapewniona możliwość tworzenia własnych transformacji. Środowisko tworzenia transformacji danych powinno udostępniać m.in.:

VI.2.3.2.6.1.18.1. mechanizm debuggowania tworzonego rozwiązania,


Strona 100 z 208

VI.2.3.2.6.1.18.2. mechanizm stawiania „pułapek” (breakpoints), VI.2.3.2.6.1.18.3. mechanizm logowania do pliku wykonywanych przez

transformację operacji, VI.2.3.2.6.1.18.4. możliwość wznowienia wykonania transformacji od punktu,

w którym przerwano jej wykonanie (np. w wyniku pojawienia się błędu),

VI.2.3.2.6.1.18.5. możliwość cofania i ponawiania wprowadzonych przez użytkownika zmian podczas edycji transformacji (funkcja undo/redo)

VI.2.3.2.6.1.18.6. mechanizm analizy przetwarzanych danych (możliwość podglądu rekordów przetwarzanych w strumieniu danych oraz tworzenia statystyk, np. histogram wartości w przetwarzanych kolumnach tabeli),

VI.2.3.2.6.1.18.7. mechanizm automatyzacji publikowania utworzonych transformacji na serwerze bazy danych (w szczególności tworzenia wersji instalacyjnej pozwalającej automatyzować proces publikacji na wielu serwerach),

VI.2.3.2.6.1.18.8. mechanizm tworzenia parametrów zarówno na poziomie poszczególnych pakietów, jak też na poziomie całego projektu, parametry powinny umożliwiać uruchamianie pakietów podrzędnych i przesyłanie do nich wartości parametrów z pakietu nadrzędnego,

VI.2.3.2.6.1.18.9. mechanizm mapowania kolumn wykorzystujący ich nazwę i typ danych do automatycznego przemapowania kolumn w sytuacji podmiany źródła danych.

VI.2.3.2.6.1.19. Wbudowany system analityczny - SBD musi posiadać moduł pozwalający na tworzenie rozwiązań służących do analizy danych wielowymiarowych (kostki OLAP). Powinno być możliwe tworzenie: wymiarów, miar. Wymiary powinny mieć możliwość określania dodatkowych atrybutów będących dodatkowymi poziomami agregacji. Powinna być możliwość definiowania hierarchii w obrębie wymiaru. Przykład: wymiar Lokalizacja Geograficzna. Atrybuty: miasto, gmina, województwo. Hierarchia: Województwo->Gmina.

VI.2.3.2.6.1.20. Wbudowany system analityczny musi mieć możliwość wyliczania agregacji wartości miar dla zmieniających się elementów (członków) wymiarów i ich atrybutów. Agregacje powinny być składowane w jednym z wybranych modeli (MOLAP – wyliczone gotowe agregacje rozłącznie w stosunku do danych źródłowych, ROLAP – agregacje wyliczane w trakcie zapytania z danych źródłowych). Pojedyncza baza analityczna musi mieć możliwość mieszania modeli składowania, np. dane bieżące ROLAP, historyczne – MOLAP w sposób przezroczysty dla wykonywanych zapytań. Dodatkowo powinna być dostępna możliwość drążenia danych z kostki do poziomu rekordów szczegółowych z bazy relacyjnych (drill to detail).

VI.2.3.2.6.1.21. Wbudowany system analityczny musi pozwalać na dodanie akcji przypisanych do elementów kostek wielowymiarowych (np. pozwalających na przejście użytkownika do raportów kontekstowych lub stron www powiązanych z przeglądanym obszarem kostki).

VI.2.3.2.6.1.22. Wbudowany system analityczny musi posiadać narzędzie do rejestracji i śledzenia zapytań wykonywanych do baz analitycznych.

VI.2.3.2.6.1.23. Wbudowany system analityczny musi obsługiwać wielojęzyczność (tworzenie obiektów wielowymiarowych w wielu językach – w zależności od ustawień na komputerze klienta).


Strona 101 z 208

VI.2.3.2.6.1.24. Wbudowany system analityczny musi udostępniać rozwiązania Data Mining, m.in.: algorytmy reguł związków (Association Rules), szeregów czasowych (Time Series), drzew regresji (Regression Trees), sieci neuronowych (Neural Nets oraz Naive Bayes). Dodatkowo system musi udostępniać narzędzia do wizualizacji danych z modelu Data Mining oraz język zapytań do odpytywania tych modeli.

VI.2.3.2.6.1.25. Tworzenie głównych wskaźników wydajności KPI (Key Performance Indicators - kluczowe czynniki sukcesu) - SBD musi udostępniać użytkownikom możliwość tworzenia wskaźników KPI (Key Performance Indicators) na podstawie danych zgromadzonych w strukturach wielowymiarowych. W szczególności powinien pozwalać na zdefiniowanie takich elementów, jak: wartość aktualna, cel, trend, symbol graficzny wskaźnika w zależności od stosunku wartości aktualnej do celu.

VI.2.3.2.6.1.26. System raportowania - SBD musi posiadać możliwość definiowania i generowania raportów. Narzędzie do tworzenia raportów powinno pozwalać na ich graficzną definicję. Raporty powinny być udostępnianie przez system protokołem HTTP (dostęp klienta za pomocą przeglądarki), bez konieczności stosowania dodatkowego oprogramowania po stronie serwera. Dodatkowo system raportowania musi obsługiwać:

VI.2.3.2.6.1.26.1. raporty parametryzowane, VI.2.3.2.6.1.26.2. cache raportów (generacja raportów bez dostępu do źródła

danych), VI.2.3.2.6.1.26.3. cache raportów parametryzowanych (generacja raportów

bez dostępu do źródła danych, z różnymi wartościami parametrów),

VI.2.3.2.6.1.26.4. współdzielenie predefiniowanych zapytań do źródeł danych, VI.2.3.2.6.1.26.5. możliwość opublikowania elementu raportu (wykresu,

tabeli) we współdzielonej bibliotece, z której mogą korzystać inni użytkownicy tworzący nowy raport,

VI.2.3.2.6.1.26.6. możliwość wizualizacji wskaźników KPI, VI.2.3.2.6.1.26.7. możliwość wizualizacji danych w postaci obiektów sparkline.

VI.2.3.2.6.1.27. Środowisko raportowania powinno być osadzone i administrowane z wykorzystaniem mechanizmu Web Serwisów (Web Services).

VI.2.3.2.6.1.28. Wymagane jest generowanie raportów w formatach: XML, PDF, Microsoft Excel, Microsoft Word, HTML, TIFF. Dodatkowo raporty powinny być eksportowane w formacie Atom data feeds, które można będzie wykorzystać jako źródło danych w innych aplikacjach.

VI.2.3.2.6.1.29. SBD musi umożliwiać rozbudowę mechanizmów raportowania m.in. o dodatkowe formaty eksportu danych, obsługę nowych źródeł danych dla raportów, funkcje i algorytmy wykorzystywane podczas generowania raportu (np. nowe funkcje agregujące), mechanizmy zabezpieczeń dostępu do raportów.

VI.2.3.2.6.1.30. SBD musi umożliwiać wysyłkę raportów drogą mailową w wybranym formacie (subskrypcja).

VI.2.3.2.6.1.31. Wbudowany system raportowania musi posiadać rozszerzalną architekturę oraz otwarte interfejsy do osadzania raportów oraz do integrowania rozwiązania z różnorodnymi środowiskami IT.

VI.2.3.2.6.2. Portal: VI.2.3.2.6.2.1. Serwer Portalu, który posiada następujące cechy dostępne bezpośrednio:


Strona 102 z 208

VI.2.3.2.6.2.1.1. Publikację dokumentów, treści i materiałów multimedialnych na witrynach wewnętrznych i zewnętrznych,

VI.2.3.2.6.2.1.2. Tworzenie wspólnej infrastruktury wszystkich stron dla całej organizacji w oparciu o farmę serwerów portalu.

VI.2.3.2.6.2.1.3. Zarządzanie strukturą portalu i treściami WWW, VI.2.3.2.6.2.1.4. Uczestnictwo użytkowników w forach dyskusyjnych, ocenie

materiałów, publikacji własnych treści, VI.2.3.2.6.2.1.5. Udostępnianie spersonalizowanych witryn i przestrzeni

roboczych dla poszczególnych ról w systemie wraz z określaniem praw dostępu na bazie usługi katalogowej,

VI.2.3.2.6.2.1.6. Udostępnienie formularzy elektronicznych, VI.2.3.2.6.2.1.7. Tworzenie repozytoriów dokumentów oraz wzorów

dokumentów, VI.2.3.2.6.2.1.8. Wspólną, bezpieczną pracę nad dokumentami, VI.2.3.2.6.2.1.9. Wersjonowanie dokumentów (dla wersji roboczych (0.1,0.2)

i głównych (1.0,2.0)), VI.2.3.2.6.2.1.10. Organizację pracy grupowej, VI.2.3.2.6.2.1.11. Wyszukiwanie treści, VI.2.3.2.6.2.1.12. Dostęp do danych w relacyjnych bazach danych, VI.2.3.2.6.2.1.13. Analizy danych wraz z graficzną prezentacją danych, (w tym

drążenie danych oraz drzewo dekompozycji dostępne z poziomu przeglądarki)

VI.2.3.2.6.2.1.14. Możliwość wykorzystanie mechanizmów portalu do budowy systemu zarządzania e-szkoleniami (e-learning).

VI.2.3.2.6.2.1.15. Możliwość zaprojektowania struktury portalu tak, by mogła stanowić zbiór wielu niezależnych portali, które w zależności od nadanych uprawnień mogą być zarządzane niezależnie.

VI.2.3.2.6.2.1.16. Możliwość zaimplementowania procesów przepływu dokumentów i spraw oraz zapewnienie dostępu do informacji niezbędnych do realizacji założonych celów i procesów.

VI.2.3.2.6.2.2. Interfejs użytkownika : VI.2.3.2.6.2.2.1. Praca z dokumentami typu XML w oparciu schematy XML

przechowywane w repozytoriach portalu bezpośrednio z aplikacji w specyfikacji pakietu biurowego (otwieranie/zapisywanie dokumentów, podgląd wersji, mechanizmy ewidencjonowania i wyewidencjonowania dokumentów, edycja metryki dokumentu).

VI.2.3.2.6.2.2.2. Wbudowane zasady realizujące wytyczne dotyczące ułatwień w dostępie do publikowanych treści zgodne z WCAG 2.0

VI.2.3.2.6.2.2.3. Praca bezpośrednio z aplikacji pakietu biurowego z portalowymi rejestrami informacji typu kalendarze oraz bazy kontaktów

VI.2.3.2.6.2.2.4. Tworzenie witryn w ramach portalu bezpośrednio z aplikacji pakietu biurowego

VI.2.3.2.6.2.2.5. Możliwość pracy off-line z plikami przechowywanymi w repozytoriach portalu

VI.2.3.2.6.2.2.6. Umożliwienie uruchomienia prezentacji stron w wersji pełnej oraz w wersji dedykowanej i zoptymalizowanej dla użytkowników urządzeń mobilnych.


Strona 103 z 208

VI.2.3.2.6.2.3. Uwierzytelnianie – wbudowane mechanizmy wspierające uwierzytelnianie na bazie:

VI.2.3.2.6.2.3.1. Oświadczeń (claim-based authentication) z wykorzystaniem:

VI.2.3.2.6.2.3.1.1. Open Authorization 2.0 dla uwierzytelniania aplikacji,

VI.2.3.2.6.2.3.1.2. Uwierzytelniania w trybie server-to-server, VI.2.3.2.6.2.3.1.3. SAML VI.2.3.2.6.2.3.1.4. Windows claims

VI.2.3.2.6.2.3.2. Pojedynczego logowania domenowego (single-sign on), VI.2.3.2.6.2.3.3. Na bazie formularzy (Form-based).

VI.2.3.2.6.2.4. Projektowanie stron VI.2.3.2.6.2.4.1. Wbudowane narzędzia projektowania wyglądu stron, VI.2.3.2.6.2.4.2. Wsparcie dla narzędzi typu Adobe Dreamweaver, Microsoft

Expression Web i edytorów HTML, VI.2.3.2.6.2.4.3. Wsparcie dla ASP.NET, Apache, C#, Java i PHP, VI.2.3.2.6.2.4.4. Możliwość osadzania elementów iFrame w polach HTML na

stronie. VI.2.3.2.6.2.5. Integracja z pozostałymi modułami rozwiązania oraz innymi systemami:

VI.2.3.2.6.2.5.1. Wykorzystanie poczty elektronicznej do rozsyłania przez system wiadomości, powiadomień, alertów do użytkowników portalu w postaci maili

VI.2.3.2.6.2.5.2. Dostęp poprzez interfejs portalowy do całości bądź wybranych elementów skrzynek pocztowych użytkowników w komponencie poczty elektronicznej, z zapewnieniem podstawowej funkcjonalności pracy z tym systemem w zakresie czytania, tworzenia, przesyłania elementów

VI.2.3.2.6.2.5.3. Możliwość wykorzystania oferowanego systemu poczty elektronicznej do umieszczania dokumentów w repozytoriach portalu poprzez przesyłanie ich w postaci załączników do maili

VI.2.3.2.6.2.5.4. Integracja z systemem obsługującym serwis WWW w zakresie publikacji treści z repozytoriów wewnętrznych firmy na zewnętrzne strony serwisu WWW (pliki, strony)

VI.2.3.2.6.2.5.5. Integracja z usługą katalogową w zakresie prezentacji informacji o pracownikach. Dane typu: imię, nazwisko, stanowisko, telefon, adres, miejsce w strukturze organizacyjnej mają stanowić źródło dla systemu portalowego

VI.2.3.2.6.2.5.6. Wsparcie dla standardu wymiany danych z innymi systemami w postaci XML, z wykorzystaniem komunikacji poprzez XML Web Services

VI.2.3.2.6.2.5.7. Mechanizm jednokrotnej identyfikacji (single sign-on) pozwalający na autoryzację użytkowników portalu i dostęp do danych w innych systemach biznesowych, niezintegrowanych z systemem LDAP.

VI.2.3.2.6.2.5.8. Przechowywanie całej zawartości portalu (strony, dokumenty, konfiguracja) we wspólnym dla całego serwisu podsystemie bazodanowym z możliwością wydzielenia danych.


Strona 104 z 208

VI.2.3.2.6.2.5.9. Integracja z pakietem biurowym w zakresie wyświetlania oraz edycji metryk dokumentu z poziomu pakietu biurowego.

VI.2.3.2.6.2.5.10. Integracja z pakietem biurowym w zakresie tworzenia i modyfikacji formularzy elektronicznych bez potrzeby znajomości HTML przez użytkownika końcowego.

VI.2.3.2.6.2.5.11. Integracja z mechanizmami relacyjnej bazy danych poprzez dostępność narzędzi wizualizacji analiz biznesowych dostępnych serwerze bazodanowym.

VI.2.3.2.6.2.6. Zarządzanie treścią i wyglądem portalu powinno opierać się o narzędzia umożliwiające prostą i intuicyjną publikację treści w formacie HTML w trybie WYSIWYG, bez konieczności znajomości języka HTML i innej wiedzy technicznej przez autorów treści:

VI.2.3.2.6.2.6.1. Możliwość formatowania tekstu w zakresie zmiany czcionki, rozmiaru, koloru, pogrubienia, wyrównania do prawej oraz lewej strony, wyśrodkowania, wyjustowania.

VI.2.3.2.6.2.6.2. Proste osadzenie i formatowanie plików graficznych, łącz (linków) różnych typów, tabel, paragrafów, wypunktowań itp. w treści artykułów publikowanych w intranecie (stron HTML)

VI.2.3.2.6.2.6.3. Spójne zarządzanie wyglądem stron intranetu, głównie pod kątem formatowania tekstu: możliwość globalnego zdefiniowania krojów tekstu, które mogą być wykorzystywane przez edytorów treści, możliwość wklejania treści przy publikacji stron intranetu z plików tekstowych lub edytorów tekstu (np. MS Word) z zachowaniem lub z usunięciem formatowania oryginalnego

VI.2.3.2.6.2.6.4. Zarządzanie galeriami zasobów elektronicznych (pliki graficzne, filmy video, dokumenty), wykorzystywanymi przy tworzeniu stron intranetu i przechowywanymi w intranetowym repozytorium treści. Możliwość współdzielenia tych zasobów na potrzeby stron umiejscowionych w różnych obszarach portalu intranetowego. Podstawowe funkcjonalności związane z wersjonowaniem i wyszukiwaniem tych zasobów

VI.2.3.2.6.2.6.5. Definiowanie szablonów dla układów stron (tzw. layout’ów), określających ogólny układ stron intranetu oraz elementy wspólne dla stron opartych na tym samym szablonie. Możliwość stworzenia wielu szablonów na potrzeby różnych układów stron w zależności od potrzeb funkcjonalnych w różnych częściach intranetu. Możliwość generalnej zmiany wyglądu utworzonych już stron poprzez modyfikację szablonu, na którym zostały oparte

VI.2.3.2.6.2.6.6. Możliwość wielokrotnego wykorzystania elementów zawartości intranetu (części treści publikowanych na stronach) w różnych częściach portalu, tzn. modyfikacja zawartości w jednym miejscu powoduje jej faktyczną zmianę na wszystkich stronach intranetu, gdzie dana treść została opublikowana

VI.2.3.2.6.2.6.7. Możliwość odwzorowania w systemie CMS przyjętej wizualizacji portalu intranetowego (projekt graficzny i funkcjonalny).


Strona 105 z 208

VI.2.3.2.6.2.6.8. Możliwość osadzania na stronach narzędzia do odtwarzania materiałów audio i wideo,

VI.2.3.2.6.2.7. Organizacja i publikacja treści: VI.2.3.2.6.2.7.1. Wersjonowanie treści stron intranetu, działające

automatycznie przy wprowadzaniu kolejnych modyfikacji przez edytorów treści.

VI.2.3.2.6.2.7.2. Zastosowanie procesów zatwierdzania zawartości przez publikacją, tzn. Udostępnieniem jej dla szerokiego grona pracowników. Możliwość zdefiniowania przynajmniej dwóch poziomów uprawnień edytorów (edytor i recenzent), przy czym treści publikowane przez edytorów muszą uzyskać pozytywną akceptację recenzenta przed Udostępnieniem jej wszystkim użytkownikom intranetu.

VI.2.3.2.6.2.7.3. Możliwość budowania hierarchicznej struktury stron portalu z prostym przenoszeniem stron i sekcji w ramach struktury nawigacji.

VI.2.3.2.6.2.7.4. Automatyczne tworzenie nawigacji na stronach intranetu, odwzorowujące obecną hierarchię.

VI.2.3.2.6.2.7.5. Automatyczne generowanie mapy stron portalu. VI.2.3.2.6.2.7.6. Możliwość definiowania nawigacji w oparciu o centralne

zarządzanie metadanymi. VI.2.3.2.6.2.7.7. Umożliwienie zarządzania poszczególnymi obszarami

portalu osobom nietechnicznym, pełniącym rolę edytorów bądź administratorów merytorycznych. Istotne jest nieangażowanie zespołu IT w proces zarządzania treścią intranetu.

VI.2.3.2.6.2.7.8. Definiowanie uprawnień użytkowników niezależnie do poszczególnych sekcji i stron intranetu, np. do obszarów poszczególnych spółek, dywizji, biur. Dotyczy to zarówno uprawnień do odczytu zawartości, jak i edycji oraz publikacji (różni edytorzy zawartości intranetu w zależności od jego części). Definiowanie uprawnień powinno być dostępne dla administratorów merytorycznych poszczególnych obszarów portalu w sposób niezależny od pracowników działu IT.

VI.2.3.2.6.2.7.9. Automatyczne dołączanie do publikowanych stron informacji o autorze (edytorze) i dacie publikacji.

VI.2.3.2.6.2.7.10. Możliwość personalizacji i filtrowania treści w intranecie w zależności od roli lub innych atrybutów pracownika (np. stanowiska, działu, pionu lub spółki). Funkcjonalność ta ma być niezależna od mechanizmów zarządzania uprawnieniami użytkownika do zawartości, i ma mieć na celu dostarczenie pracownikowi adekwatnych, skierowanych do niego informacji.

VI.2.3.2.6.2.7.11. Wsparcie dla obsługi różnych wersji językowych wybranych zawartości intranetu oraz zapewnienie automatycznego tłumaczenia na wybrane języki.

VI.2.3.2.6.2.8. Repozytoria dokumentów: VI.2.3.2.6.2.8.1. Możliwość prostej publikacji dokumentów w intranecie

przez edytorów portalu. Prosty sposób publikacji dokumentów, funkcjonalny dostęp użytkowników intranetu do opublikowanych dokumentów.


Strona 106 z 208

VI.2.3.2.6.2.8.2. Wykorzystanie do publikacji, edycji i przeglądania dokumentów w repozytorium narzędzi znanych użytkownikom np. pakiety biurowe czy przeglądarka internetowa.

VI.2.3.2.6.2.8.3. Możliwość tworzenia wielu tematycznych repozytoriów dokumentów w różnych częściach intranetu.

VI.2.3.2.6.2.8.4. Możliwość publikacji plików w strukturze katalogów. VI.2.3.2.6.2.8.5. Możliwość publikacji materiałów wideo oraz audio. VI.2.3.2.6.2.8.6. Możliwość definiowania metryki dokumentu, wypełnianej

przez edytora przy publikacji pliku. VI.2.3.2.6.2.8.7. Możliwość nawigacji po repozytorium dokumentów (lub

całym portalu) w oparciu o metadane z metryk dokumentów.

VI.2.3.2.6.2.8.8. Prosty, elastyczny i niezależny od działu IT mechanizm zarządzania uprawnieniami do publikowanych dokumentów w ramach istniejących uprawnień. Możliwość definiowania różnych poziomów uprawnień przez administratorów merytorycznych, np. uprawnienia do odczytu, publikacji, usuwania.

VI.2.3.2.6.2.8.9. Zarządzanie wersjonowaniem dokumentów: obsługa głównych oraz roboczych wersji (np.: 1.0, 1.1, 1.x… 2.0), automatyczna kontrola wersji przy publikacji dokumentów.

VI.2.3.2.6.2.8.10. Możliwość zdefiniowania w systemie procesu zatwierdzania nowych lub modyfikowanych dokumentów. System informuje użytkowników recenzujących materiały o oczekujących na nich elementach do zatwierdzenia i pozwala podjąć decyzję o ich publikacji lub odrzuceniu.

VI.2.3.2.6.2.8.11. Możliwość tworzenia specjalnych repozytoriów lub katalogów przeznaczonych do przechowywania specyficznych rodzajów treści, np. galerie obrazów dla plików graficznych.

VI.2.3.2.6.2.8.12. Możliwość definiowania polityk cyklu życia dokumentu oraz retencji dokumentów.

VI.2.3.2.6.2.8.13. Możliwość tworzenia specjalnych repozytoriów przeznaczonych na raporty osadzone w arkuszach kalkulacyjnych w formacie ISO/IEC 29500:2008. Serwer powinien generować na podstawie tych arkuszy kalkulacyjnych raporty dostępne do oglądania przez przeglądarkę Internetową bez zainstalowanych innych narzędzi klienckich.

VI.2.3.2.6.2.8.14. Możliwość automatyzacji usuwania duplikatów dokumentów.

VI.2.3.2.6.2.8.15. Możliwość prezentacji dostosowanych przez użytkowników końcowych formularzy z poziomu przeglądarki dzięki użyciu serwera formularzy.

VI.2.3.2.6.2.9. Wyszukiwanie treści: VI.2.3.2.6.2.9.1. Pełnotekstowe indeksowanie zawartości intranetu w

zakresie różnych typów treści publikowanych w portalu, tj. stron portalu, dokumentów tekstowych (w szczególności dokumentów XML), innych baz danych oraz danych dostępnych przez webservice.


Strona 107 z 208

VI.2.3.2.6.2.9.2. Centralny mechanizm wyszukiwania treści dostępny dla użytkowników intranetu

VI.2.3.2.6.2.9.3. Opcja wyszukiwania zaawansowanego, np. wyszukiwanie wg typów treści, autorów, oraz zakresów dat publikacji

VI.2.3.2.6.2.9.4. Możliwość budowania wielu wyszukiwarek w różnych częściach portalu, służących do przeszukiwania określonych obszarów intranetu wg zadanych kryteriów, np. wg typów dokumentów

VI.2.3.2.6.2.9.5. Możliwość definiowania słownika słów wykluczonych (często używanych)

VI.2.3.2.6.2.9.6. Podświetlanie w wynikach wyszukiwania odnalezionych słów kluczowych zadanych w zapytaniu.

VI.2.3.2.6.2.9.7. Przedstawianie w wynikach duplikatów plików VI.2.3.2.6.2.9.8. Statystyki wyszukiwanych fraz

VI.2.3.2.6.2.10. Administracja intranetem i inne funkcje: VI.2.3.2.6.2.10.1. Możliwość definiowania ról / grup uprawnień, w ramach

których definiowane będą uprawnienia i funkcje użytkowników. Przypisywanie użytkowników do ról w oparciu o ich konta w LDAP lub poprzez grupy domenowe. Funkcjonalność zarządzania uprawnieniami dostępna dla administratorów merytorycznych intranetu, niewymagająca szczególnych kompetencji technicznych

VI.2.3.2.6.2.10.2. Możliwość określania uprawnień do poszczególnych elementów zawartości intranetu tj. sekcja, pojedyncza strona, repozytorium dokumentów, katalogu dokumentów, pojedynczego dokumentu

VI.2.3.2.6.2.10.3. Generowanie powiadomień pocztą elektroniczną dla użytkowników intranetu z informacją o publikacji najbardziej istotnych treści

VI.2.3.2.6.2.10.4. Definiowanie metryk opisujących dokumenty w poszczególnych repozytoriach portalu oraz centralnie zarządzanego zbioru metadanych z wyznaczonym administratorem merytorycznym.

VI.2.3.2.6.2.10.5. Możliwość definiowania zewnętrznych źródeł danych takich jak bazy danych i webservice oraz wykorzystywania ich do opisywania dokumentów,

VI.2.3.2.6.2.10.6. Konfigurowanie procesów zatwierdzania publikowanych stron i dokumentów. Możliwość odrębnej konfiguracji w poszczególnych częściach portalu tj. definiowanie różnych edytorów i recenzentów w ramach różnych obszarów intranetu

VI.2.3.2.6.2.10.7. Statystyki odwiedzin poszczególnych części i stron intranetu – analiza liczby odsłon w czasie. Opcjonalnie zaawansowane statystyki i analizy

VI.2.3.2.6.2.10.8. Funkcjonalności wspierające pracę grupową - do wykorzystania na najniższym poziomie intranetu do celów pracy działów i zespołów zadaniowych. Funkcjonalności wspierające gromadzenie dokumentów, wsparcie komunikacji, planowanie zadań i wydarzeń

VI.2.3.2.6.2.10.9. Funkcjonalność serwera formularzy - publikowania na portalu formularzy elektronicznych pozwalających tworzyć dokumenty w formacie XML i przetwarzanych na aplikację


Strona 108 z 208

webową dostępną dla użytkowników przez przeglądarkę Internetową. Dane z wypełnionego formularza mają być zapisywane w formacie XML zgodnie z definicją formularza.

VI.2.3.2.6.2.10.10. Mechanizmy wspierające przepływy pracy (workflow) wraz z funkcjonalnością definiowania procesów obiegu dokumentów, integracji przepływów z web-services, wywoływania web-services z poziomu workflow bez konieczności kodowania przy wykorzystaniu prostych w obsłudze narzędzi portalu.

VI.2.3.2.6.3. System operacyjny :

VI.2.3.2.6.3.1. Licencja na serwerowy system operacyjny musi być przypisana do

każdego procesora fizycznego na serwerze. Liczba rdzeni procesorów i

ilość pamięci nie mogą mieć wpływu na liczbę wymaganych licencji.

Licencja musi uprawniać do uruchamiania serwerowego systemu

operacyjnego w środowisku fizycznym i dwóch wirtualnych środowisk

serwerowego systemu operacyjnego za pomocą wbudowanych

mechanizmów wirtualizacji.

VI.2.3.2.6.3.2. Serwerowy system operacyjny musi posiadać następujące, wbudowane

cechy.

VI.2.3.2.6.3.2.1. Możliwość wykorzystania 320 logicznych procesorów oraz co najmniej 4 TB pamięci RAM w środowisku fizycznym.

VI.2.3.2.6.3.2.2. Możliwość wykorzystywania 64 procesorów wirtualnych oraz 1TB pamięci RAM i dysku o pojemności do 64TB przez każdy wirtualny serwerowy system operacyjny.

VI.2.3.2.6.3.2.3. Możliwość budowania klastrów składających się z 64 węzłów, z możliwością uruchamiania 7000 maszyn wirtualnych.

VI.2.3.2.6.3.2.4. Możliwość migracji maszyn wirtualnych bez zatrzymywania ich pracy między fizycznymi serwerami z uruchomionym mechanizmem wirtualizacji (hypervisor) przez sieć Ethernet, bez konieczności stosowania dodatkowych mechanizmów współdzielenia pamięci.

VI.2.3.2.6.3.2.5. Wsparcie (na umożliwiającym to sprzęcie) dodawania i wymiany pamięci RAM bez przerywania pracy.

VI.2.3.2.6.3.2.6. Wsparcie (na umożliwiającym to sprzęcie) dodawania i wymiany procesorów bez przerywania pracy.

VI.2.3.2.6.3.2.7. Automatyczna weryfikacja cyfrowych sygnatur sterowników w celu sprawdzenia, czy sterownik przeszedł testy jakości przeprowadzone przez producenta systemu operacyjnego.

VI.2.3.2.6.3.2.8. Możliwość dynamicznego obniżania poboru energii przez rdzenie procesorów niewykorzystywane w bieżącej pracy. Mechanizm ten musi uwzględniać specyfikę procesorów wyposażonych w mechanizmy Hyper-Threading.

VI.2.3.2.6.3.2.9. Wbudowane wsparcie instalacji i pracy na wolumenach, które: VI.2.3.2.6.3.2.9.1. pozwalają na zmianę rozmiaru w czasie pracy systemu,


Strona 109 z 208

VI.2.3.2.6.3.2.9.2. umożliwiają tworzenie w czasie pracy systemu migawek, dających użytkownikom końcowym (lokalnym i sieciowym) prosty wgląd w poprzednie wersje plików i folderów,

VI.2.3.2.6.3.2.9.3. umożliwiają kompresję "w locie" dla wybranych plików i/lub folderów,

VI.2.3.2.6.3.2.9.4. umożliwiają zdefiniowanie list kontroli dostępu (ACL). VI.2.3.2.6.3.2.10. Wbudowany mechanizm klasyfikowania i indeksowania plików

(dokumentów) w oparciu o ich zawartość. VI.2.3.2.6.3.2.11. Wbudowane szyfrowanie dysków przy pomocy mechanizmów

posiadających certyfikat FIPS 140-2 lub równoważny wydany przez NIST lub inną agendę rządową zajmującą się bezpieczeństwem informacji.

VI.2.3.2.6.3.2.12. Możliwość uruchamianie aplikacji internetowych wykorzystujących technologię ASP.NET

VI.2.3.2.6.3.2.13. Możliwość dystrybucji ruchu sieciowego HTTP pomiędzy kilka serwerów.

VI.2.3.2.6.3.2.14. Wbudowana zapora internetowa (firewall) z obsługą definiowanych reguł dla ochrony połączeń internetowych i intranetowych.

VI.2.3.2.6.3.2.15. Dostępne dwa rodzaje graficznego interfejsu użytkownika: VI.2.3.2.6.3.2.15.1. Klasyczny, umożliwiający obsługę przy pomocy klawiatury i

myszy, VI.2.3.2.6.3.2.15.2. Dotykowy umożliwiający sterowanie dotykiem na monitorach

dotykowych. VI.2.3.2.6.3.2.16. Zlokalizowane w języku polskim, co najmniej następujące

elementy: menu, przeglądarka internetowa, pomoc, komunikaty systemowe,

VI.2.3.2.6.3.2.17. Możliwość zmiany języka interfejsu po zainstalowaniu systemu, dla co najmniej 10 języków poprzez wybór z listy dostępnych lokalizacji.

VI.2.3.2.6.3.2.18. Mechanizmy logowania w oparciu o: VI.2.3.2.6.3.2.18.1. Login i hasło, VI.2.3.2.6.3.2.18.2. Karty z certyfikatami (smartcard), VI.2.3.2.6.3.2.18.3. Wirtualne karty (logowanie w oparciu o certyfikat chroniony

poprzez moduł TPM), VI.2.3.2.6.3.2.19. Możliwość wymuszania wieloelementowej kontroli dostępu dla

określonych grup użytkowników. VI.2.3.2.6.3.2.20. Wsparcie dla większości powszechnie używanych urządzeń

peryferyjnych (drukarek, urządzeń sieciowych, standardów USB, Plug&Play).

VI.2.3.2.6.3.2.21. Możliwość zdalnej konfiguracji, administrowania oraz aktualizowania systemu.

VI.2.3.2.6.3.2.22. Dostępność bezpłatnych narzędzi producenta systemu umożliwiających badanie i wdrażanie zdefiniowanego zestawu polityk bezpieczeństwa.

VI.2.3.2.6.3.2.23. Pochodzący od producenta systemu serwis zarządzania polityką dostępu do informacji w dokumentach (Digital Rights Management).

VI.2.3.2.6.3.2.24. Wsparcie dla środowisk Java i .NET Framework 4.x – możliwość uruchomienia aplikacji działających we wskazanych środowiskach.

VI.2.3.2.6.3.2.25. Możliwość implementacji następujących funkcjonalności bez potrzeby instalowania dodatkowych produktów (oprogramowania) innych producentów wymagających dodatkowych licencji:


Strona 110 z 208

VI.2.3.2.6.3.2.25.1. Podstawowe usługi sieciowe: DHCP oraz DNS wspierający DNSSEC,

VI.2.3.2.6.3.2.25.2. Usługi katalogowe oparte o LDAP i pozwalające na uwierzytelnianie użytkowników stacji roboczych, bez konieczności instalowania dodatkowego oprogramowania na tych stacjach, pozwalające na zarządzanie zasobami w sieci (użytkownicy, komputery, drukarki, udziały sieciowe), z możliwością wykorzystania następujących funkcji:

VI.2.3.2.6.3.2.25.3. Podłączenie do domeny w trybie offline – bez dostępnego połączenia sieciowego z domeną,

VI.2.3.2.6.3.2.25.4. Ustanawianie praw dostępu do zasobów domeny na bazie sposobu logowania użytkownika – na przykład typu certyfikatu użytego do logowania,

VI.2.3.2.6.3.2.25.5. Odzyskiwanie przypadkowo skasowanych obiektów usługi katalogowej z mechanizmu kosza.

VI.2.3.2.6.3.2.25.6. Bezpieczny mechanizm dołączania do domeny uprawnionych użytkowników prywatnych urządzeń mobilnych opartych o iOS i Windows 8.1.

VI.2.3.2.6.3.2.25.7. Zdalna dystrybucja oprogramowania na stacje robocze. VI.2.3.2.6.3.2.25.8. Praca zdalna na serwerze z wykorzystaniem terminala

(cienkiego klienta) lub odpowiednio skonfigurowanej stacji roboczej

VI.2.3.2.6.3.2.25.9. Centrum Certyfikatów (CA), obsługa klucza publicznego i prywatnego) umożliwiające:

VI.2.3.2.6.3.2.25.10. Dystrybucję certyfikatów poprzez http VI.2.3.2.6.3.2.25.11. Konsolidację CA dla wielu lasów domeny, VI.2.3.2.6.3.2.25.12. Automatyczne rejestrowania certyfikatów pomiędzy

różnymi lasami domen, VI.2.3.2.6.3.2.25.13. Automatyczne występowanie i używanie (wystawianie)

certyfikatów PKI X.509. VI.2.3.2.6.3.2.25.14. Szyfrowanie plików i folderów. VI.2.3.2.6.3.2.25.15. Szyfrowanie połączeń sieciowych pomiędzy serwerami oraz

serwerami i stacjami roboczymi (IPSec). VI.2.3.2.6.3.2.25.16. Możliwość tworzenia systemów wysokiej dostępności (klastry

typu fail-over) oraz rozłożenia obciążenia serwerów. VI.2.3.2.6.3.2.25.17. Serwis udostępniania stron WWW. VI.2.3.2.6.3.2.25.18. Wsparcie dla protokołu IP w wersji 6 (IPv6), VI.2.3.2.6.3.2.25.19. Wsparcie dla algorytmów Suite B (RFC 4869), VI.2.3.2.6.3.2.25.20. Wbudowane usługi VPN pozwalające na zestawienie

nielimitowanej liczby równoczesnych połączeń i niewymagające instalacji dodatkowego oprogramowania na komputerach z systemem Windows,

VI.2.3.2.6.3.2.25.21. Wbudowane mechanizmy wirtualizacji (Hypervisor) pozwalające na uruchamianie do 1000 aktywnych środowisk wirtualnych systemów operacyjnych. Wirtualne maszyny w trakcie pracy i bez zauważalnego zmniejszenia ich dostępności mogą być przenoszone pomiędzy serwerami klastra typu failover z jednoczesnym zachowaniem pozostałej funkcjonalności. Mechanizmy wirtualizacji mają zapewnić wsparcie dla:

VI.2.3.2.6.3.2.25.22. Dynamicznego podłączania zasobów dyskowych typu hot-plug do maszyn wirtualnych,


Strona 111 z 208

VI.2.3.2.6.3.2.25.23. Obsługi ramek typu jumbo frames dla maszyn wirtualnych.

VI.2.3.2.6.3.2.25.24. Obsługi 4-KB sektorów dysków VI.2.3.2.6.3.2.25.25. Nielimitowanej liczby jednocześnie przenoszonych

maszyn wirtualnych pomiędzy węzłami klastra VI.2.3.2.6.3.2.25.26. Możliwości wirtualizacji sieci z zastosowaniem

przełącznika, którego funkcjonalność może być rozszerzana jednocześnie poprzez oprogramowanie kilku innych dostawców poprzez otwarty interfejs API.

VI.2.3.2.6.3.2.25.27. Możliwości kierowania ruchu sieciowego z wielu sieci VLAN bezpośrednio do pojedynczej karty sieciowej maszyny wirtualnej (tzw. trunk mode)

VI.2.3.2.6.3.2.26. Możliwość automatycznej aktualizacji w oparciu o poprawki publikowane przez producenta wraz z dostępnością bezpłatnego rozwiązania producenta serwerowego systemu operacyjnego umożliwiającego lokalną dystrybucję poprawek zatwierdzonych przez administratora, bez połączenia z siecią Internet.

VI.2.3.2.6.3.2.27. Wsparcie dostępu do zasobu dyskowego poprzez wiele ścieżek (Multipath).

VI.2.3.2.6.3.2.28. Możliwość instalacji poprawek poprzez wgranie ich do obrazu instalacyjnego.

VI.2.3.2.6.3.2.29. Mechanizmy zdalnej administracji oraz mechanizmy (również działające zdalnie) administracji przez skrypty.

VI.2.3.2.6.3.2.30. Możliwość zarządzania przez wbudowane mechanizmy zgodne ze standardami WBEM oraz WS-Management organizacji DMTF.

VI.2.3.2.6.3.2.31. Zorganizowany system szkoleń i materiały edukacyjne w języku polskim.


VI.2.3.3.1. Montaż i uruchomienie serwerów w serwerowni w miejscu wskazanym przez

Zamawiającego,

VI.2.3.3.2. Instalacja i konfiguracja oprogramowania narzędziowego i systemowego,

VI.2.3.3.3. Instalacja i konfiguracja oprogramowania raportowego,

VI.2.3.3.4. Uruchomienie systemu raportów,

VI.2.3.3.5. Testy funkcjonalne systemu,


VI.2.3.4.1. Brak.


VI.2.3.5.1. System wraz z oprogramowaniem narzędziowym i systemowym oraz serwery

musi być objęty min 3 letnią gwarancją.


VI.2.3.6.1. Etap I – uruchomienie serwerów oraz oprogramowania narzędziowego i

systemowego,


Strona 112 z 208

VI.2.3.6.2. Etap II – Uruchomienie systemu raportowego,

VI.2.3.6.3. Etap III – po pozytywnym zakończeniu testów funkcjonalnych.


VI.2.3.7.1. Do oferty należy dołączyć dokument potwierdzający zgodność oferowanych

serwerów dla systemu raportowego z normami zasadniczymi (deklaracja CE).


Strona 113 z 208

VI.3. Zadanie III: Infrastruktura techniczna niezbędna dla realizacji

projektu

VI.3.1. Adaptacja pomieszczenia na potrzeby serwerowni oraz DataCenter w UMWL


VI.3.1.2. Dostawa i montaż podłogi technicznej

VI.3.1.2.1. Specyfikacja techniczna / funkcjonalna:

VI.3.1.2.1.1. Podłoga podniesiona musi być wykonana w całym pomieszczeniu serwerowni

(wymiary około 3,5m x 4,5m),

VI.3.1.2.1.2. Podłoga musi posiadać antystatyczną warstwę wierzchnią,

VI.3.1.2.1.3. Wysokość prześwitu pomiędzy podłożem a płytami podłogi min. 30cm i maks.50

cm,

VI.3.1.2.1.4. Wymiary płyty podłogi 60cm x 60cm,

VI.3.1.2.1.5. Wsporniki podłogi wykonane ze stali ocynkowanej, wolnostojące mocowane na

stałe do podłoża,

VI.3.1.2.1.6. Obciążenie punktowe – min. 4 kN,

VI.3.1.2.1.7. Obciążenie powierzchniowe – min. 20 kN/m2 na całej powierzchni podłogi,

VI.3.1.2.1.8. Powierzchnia podłogi: wyrób niezapalny – od strony spodniej, trudno-zapalny - od

strony wierzchniej,

VI.3.1.2.1.9. Wytrzymałość ogniowa min. REI 30,

Pozycja

Urząd Marszałkowski

Województwa Lubuskiego

w Zielonej Górze

Dostawa i montaż podłogi technicznej 1 kpl.

Dostawa i montaż drzwi 1 kpl.

Dostawa, montaż i konfiguracja systemu kontroli dostępu 1 kpl.

Zabezpieczenie instalacji grzewczej 1 usł.

Zabezpieczenie okna 1 usł.

Dostawa, montaż i konfiguracja systemu monitorowania

środowiska 1 kpl.

Dostawa i montaż klimatyzacji 1 kpl. (2 szt.)

Dostawa i montaż zasilacza awaryjnego UPS 1 szt.

Dostawa i montaż serwerów kasetowych 2 szt.

Dostawa i montaż serwera kasetowego na potrzeby systemu

raportowego 1 szt.

Dostawa, montaż i konfiguracja urządzeń klasy UTM 2 szt.

Dostawa, montaż i konfiguracja macierzy 1 szt.

Dostawa, montaż i konfiguracja przełącznika szkieletowego 1 szt.

Dostawa, instalacja i konfiguracja oprogramowania do

archiwizacji danych 1 kpl


Strona 114 z 208

VI.3.1.2.1.10. Opór elektryczny upływu podłogi min. 1*105 Ω,

VI.3.1.2.1.11. Opór elektryczny upływu wykładziny min. 1*106 Ω,

VI.3.1.2.2. Ilość - 1 kpl

VI.3.1.2.3. Zakres prac:

VI.3.1.2.3.1. dostawa i montaż podłogi technicznej,

VI.3.1.2.3.2. dostawa i instalacja kablowych koryt siatkowych o szerokości min. 200 mm w

głównych ciągach kablowych zgodnie ze stanem zastanym oraz uwzględniając

montaż urządzeń objętych niniejszym przedmiotem zamówienia,

VI.3.1.2.3.3. uziemienie podłogi,

VI.3.1.2.3.4. wykończenie listwą przyścienną,

VI.3.1.2.3.5. wyczyszczenie i zabezpieczenie podłoża betonowego płynem antypyłowym,

VI.3.1.2.3.6. dostawa uchwytów do demontażu/montażu płyt min. 2 sztuki.

VI.3.1.2.4. Specyficzne warunki dostaw / prac:

VI.3.1.2.4.1. W pomieszczeniu znajduje się działające wyposażenie serwerowe. Należy

uzgodnić z Zamawiającym sposób i termin takiego montażu podłogi, aby nie

zakłócić organizacji pracy Zamawiającego,

VI.3.1.2.4.2. Dostarczany system podłogi musi być fabrycznie nowy (niewyprodukowany

wcześniej niż 6 miesięcy przed datą dostawy). Wykonawca zobowiązany jest

dołączyć do oferty oświadczenie Wykonawcy, że oferowane do przetargu

urządzenia spełniają ten wymóg.

VI.3.1.2.5. Serwis gwarancyjny:

VI.3.1.2.5.1. Podłoga techniczna wraz z montażem musi zostać objęta min. 3-letnią gwarancją.

VI.3.1.2.6. Etapy realizacji dostaw oraz prac podlegające formalnym odbiorom:

VI.3.1.2.6.1. Etap I – prace podlegające zakryciu – przed ułożeniem płyt podłogi powyżej 30%

powierzchni podłogi,

VI.3.1.2.6.2. Etap II – po zakończeniu montażu.

VI.3.1.2.6.3. Formalnemu odbiorowi podlega wykonanie prac związanych z położeniem

podłogi

VI.3.1.2.6.4. Podpisany przez Zamawiającego protokół odbioru wszystkich prac w ramach

zadania stanowi podstawę płatności za dostawę dla zadania.

VI.3.1.2.7. Wymagania odnośnie treści oferty:

VI.3.1.2.7.1. Do oferty należy dołączyć dokument dla oferowanego systemu podłogi

potwierdzający zgodność z normą „PN-EN 12825:2002/Ap1:2005 Podłogi

podniesione z dostępem”.

VI.3.1.2.7.2. Do oferty należy dołączyć opis oferowanego rozwiązania potwierdzający, że

przedmiot dostawy spełnia wymagania określone przez Zamawiającego.

Wykonawca zobowiązany jest do wskazania producenta, marki oraz modelu


Strona 115 z 208

(numerów katalogowych) oferowanych urządzeń/sprzętu – zgodnie z treścią

załącznika nr 10 do SIWZ,

VI.3.1.2.7.3. Do oferty należy dołączyć oświadczenie Wykonawcy, że oferowany system

podłogi technicznej zostanie dostarczony jako fabrycznie nowy (nie

wyprodukowany wcześniej niż 6 miesięcy przed datą dostawy).

VI.3.1.3. Dostawa i montaż drzwi


VI.3.1.3.1.1. Drzwi antywłamaniowe, jednoskrzydłowe pełne,

VI.3.1.3.1.2. Odporność na włamanie min. klasy 5 zgodnie z normą PN-EN 1627:2012,

VI.3.1.3.1.3. Wymiary: szerokość min. 90 cm, wysokość min. 200 cm,

VI.3.1.3.1.4. System zamykania wyposażony w zamek elektromagnetyczny przeznaczony do

podłączenia systemu kontroli dostępu objętego niniejszym zamówieniem,

VI.3.1.3.1.5. Konstrukcja stalowa lub oparta na stalowej ramie,

VI.3.1.3.1.6. Samozamykacz,

VI.3.1.3.1.7. Wytrzymałość ogniowa min. EI 30,



VI.3.1.3.3.1. Osadzenie ościeżnicy i montaż skrzydła drzwiowego tak, aby drzwi były otwierane

na zewnątrz,

VI.3.1.3.3.2. Montaż i regulacja samozamykacza,

VI.3.1.3.3.3. Montaż systemu zamykania i podłączenie go do systemu kontroli dostępu

objętego niniejszym zamówieniem,

VI.3.1.3.3.4. Doprowadzenie ściany wokół ościeżnicy do stanu pierwotnego,

VI.3.1.3.3.5. W przypadku dostawy drzwi z zamkiem mechanicznym dostawa min. 3

kompletów kluczy.



uzgodnić z Zamawiającym sposób i termin takiego montażu drzwi, aby nie zakłócić

organizacji pracy Zamawiającego,

VI.3.1.3.4.2. Dostarczane urządzenia muszą być fabrycznie nowe (niewyprodukowane





VI.3.1.3.5.1. Drzwi wraz z montażem muszą zostać objęta min. 3-letnią gwarancją.


VI.3.1.3.6.1. Po zakończeniu montażu.


Strona 116 z 208

VI.3.1.3.6.2. Formalnemu odbiorowi podlega dostawa i montaż w Urzędzie Marszałkowskim

Województwa Lubuskiego.

VI.3.1.3.6.3. Podpisany przez Zamawiającego protokół odbioru wszystkich dostaw i prac w

ramach zadania stanowi podstawę płatności za dostawę dla zadania.


VI.3.1.3.7.1. Do oferty należy dołączyć dokument potwierdzający, że oferowane drzwi są

zgodne z normą PN-EN 1627:2012 w klasie co najmniej 5.






VI.3.1.3.7.3. Do oferty należy dołączyć oświadczenie Wykonawcy, że oferowane drzwi zostaną

dostarczone jako fabrycznie nowe (nie wyprodukowane wcześniej niż 6 miesięcy

przed datą dostawy).

VI.3.1.4. Dostawa, montaż i konfiguracja systemu kontroli dostępu


VI.3.1.4.1.1. System musi obejmować min. 2 rodzaje zabezpieczeń z możliwością stosowania

jednoczesnego w tym co najmniej czytnik kart kodowych oraz klawiaturę cyfrową,

VI.3.1.4.1.2. System musi zapisywać wszystkie zdarzenia związane z jego działaniem na

zdalnym serwerze wskazanym przez Zamawiającego.



VI.3.1.4.3.1. Montaż kontrolerów systemu na ścianach serwerowni oraz przywrócenie ścian do

stanu pierwotnego,

VI.3.1.4.3.2. Podłączenie sterowania do zamka w drzwiach objętych niniejszym zamówieniem,

VI.3.1.4.3.3. Zaprogramowanie sterownika zgodnie ze wskazaniami Zamawiającego,

VI.3.1.4.3.4. Konfiguracja transmisji oraz rejestracji dziennika zdarzeń na serwerze wskazanym

przez Zamawiającego,

VI.3.1.4.3.5. Dostarczenie min. 10 kart kodowych,

VI.3.1.4.3.6. Zaprogramowanie min. 10 kombinacji kart kodowych oraz ciągów szyfrów

zgodnie ze wskazaniami Zamawiającego.



uzgodnić z Zamawiającym sposób i termin takiego montażu systemu, aby nie





Strona 117 z 208




VI.3.1.4.5.1. System kontroli dostępu musi zostać objęty min. 3-letnią gwarancją.



VI.3.1.4.6.2. Formalnemu odbiorowi podlega dostawa i montaż w Urzędzie Marszałkowskim


VI.3.1.4.6.3. Podpisany przez Zamawiającego protokół odbioru wszystkich dostaw i prac w

ramach zadania stanowi podstawę płatności za dostawę dla zadania.


VI.3.1.4.7.1. Dokument potwierdzający zgodność oferowanego systemu kontroli dostępu z

normą PN-EN 50133.







kontroli dostępu zostanie dostarczony jako fabrycznie nowy (nie wyprodukowane

wcześniej niż 6 miesięcy przed datą dostawy).

VI.3.1.5. Zabezpieczenie instalacji grzewczej

VI.3.1.5.1. Ilość - 1 usł


VI.3.1.5.2.1. Demontaż kaloryfera,

VI.3.1.5.2.2. Zaczopowanie istniejących ciągów wodnych.


VI.3.1.5.3.1. W pomieszczeniu znajduje się działające wyposażenie serwerowe. Instalacja

grzewcza jest podłączona do działającego systemu. Należy uzgodnić z

Zamawiającym sposób i termin prac tak, aby nie zakłócić organizacji pracy

Zamawiającego oraz nie spowodować zalania innych pomieszczeń.


VI.3.1.5.4.1. Brak wymagań.


VI.3.1.5.5.1. Po zakończeniu prac.


Strona 118 z 208



VI.3.1.5.6. Wymagania odnośnie treści oferty

VI.3.1.5.6.1. Brak.

VI.3.1.6. Zabezpieczenie okna

VI.3.1.6.1. Ilość - 1 usł


VI.3.1.6.2.1. Szybę w oknie po wewnętrznej stronie należy pokryć folią utrudniającą włamanie

i rozbicie spełniającą wymogi klasy antywłamaniowej P2A‐ITB „Odporność na

ręczny atak”.

VI.3.1.6.2.2. W celu redukcji nasłonecznienia na zewnętrznej stronie szyby należy nakleić folię,

która posiada metalizowaną lub napylaną warstwę odbijającą energię słoneczną.

VI.3.1.6.2.3. Okno jest obecnie zabezpieczone kratą, którą należy zdemontować i przekazać

Zamawiającemu przed przystąpieniem do odbioru prac.

VI.3.1.6.2.4. Na zewnątrz należy zamontować kratę stalową z prętów o średnicy min. 8mm i

odległości pomiędzy poszczególnymi prętami w obu kierunkach nie większej niż

40 cm.



uzgodnić z Zamawiającym sposób i termin pracy tak, aby nie zakłócić organizacji

pracy Zamawiającego.


VI.3.1.6.4.1. Zabezpieczenie okna musi zostać objęte min. 3-letnią gwarancją.


VI.3.1.6.5.1. Po zakończeniu prac.




VI.3.1.6.6.1. Brak.

VI.3.1.7. Dostawa, montaż i konfiguracja systemu monitorowania środowiska


VI.3.1.7.1.1. Min. 1 interfejs zgodny ze standardem Ethernet,

VI.3.1.7.1.2. Zgodność z protokołem TCP/IP,

VI.3.1.7.1.3. System musi umożliwiać podłączenie min. 4 czujników analogowych oraz min. 8

czujników cyfrowych,


Strona 119 z 208

VI.3.1.7.1.4. Dostarczany system musi po uruchomieniu mierzyć temperaturę w serwerowni w

zakresie min. od 0°C do +55°C z rozdzielczością min. 2°C,

VI.3.1.7.1.5. Dostarczany system musi po uruchomieniu mierzyć wilgotność względną w

serwerowni w zakresie min. od 20% do 95% z rozdzielczością min. 5%,

VI.3.1.7.1.6. Dostarczany system musi po uruchomieniu wykrywać pojawienie się wody w

określonym miejscu,

VI.3.1.7.1.7. Dostarczony system musi po uruchomieniu wykrywać dym w serwerowni,

VI.3.1.7.1.8. Dostarczony system musi po uruchomieniu wykrywać stan otwarcia drzwi,

VI.3.1.7.1.9. System musi umożliwiać przesyłanie w konfigurowalnych interwałach

komunikatów o parametrach środowiskowych oraz komunikatów alarmowych.

VI.3.1.7.1.10. System musi umożliwiać przesyłanie komunikatów o parametrach

środowiskowych przy wykorzystaniu poczty elektronicznej do min. 5

definiowanych dowolnie adresatów.

VI.3.1.7.1.11. System musi posiadać wbudowany moduł GSM umożliwiający przesyłanie

komunikatów o parametrach środowiskowych przy pomocy sieci telefonii

komórkowej,

VI.3.1.7.1.12. System musi posiadać możliwość zapisywania wszystkich rejestrowanych

parametrów na zdalnym serwerze,

VI.3.1.7.1.13. Wraz z systemem musi zostać dostarczona licencja na min. 2 stanowiska pracujące

w środowisku MS Windows dla oprogramowania umożliwiającego odczyt

parametrów środowiskowych, wizualizację tych parametrów w postaci wykresów

oraz generowanie alertów przy przekroczeniu poziomów określonych w

konfiguracji.



VI.3.1.7.3.1. Montaż systemu i czujników w serwerowni, umiejscowienie czujników (w

szczególności czujnika wykrywającego obecność wody) musi być uzgodnione z

Zamawiającym,

VI.3.1.7.3.2. Konfiguracja systemu do pracy,

VI.3.1.7.3.3. Konfiguracja zapisu rejestru na zdalnym serwerze wskazanym przez

Zamawiającego,

VI.3.1.7.3.4. Instalacja oprogramowania monitorującego na 2 stacjach roboczych wskazanych


VI.3.1.7.3.5. Konfiguracja połączenia pomiędzy systemem monitoringu a oprogramowaniem

monitorującym.



uzgodnić z Zamawiającym sposób i termin takiego montażu systemu, aby nie





Strona 120 z 208

dołączyć do oferty oświadczenia Wykonawcy, że oferowane do przetargu



VI.3.1.7.5.1. System monitoringu wraz z montażem muszą zostać objęta min. 3-letnią

gwarancją.


VI.3.1.7.6.1. Po zakończeniu montażu i konfiguracji.










monitorowania środowiska zostanie dostarczony jako fabrycznie nowy (nie

wyprodukowany wcześniej niż 6 miesięcy przed datą dostawy).

VI.3.1.8. Dostawa i montaż klimatyzacji


VI.3.1.8.1.1. Klimatyzacja typu split składająca się co najmniej z dwóch jednostek zewnętrznych

oraz dwóch inwerterów,

VI.3.1.8.1.2. Moc chłodnicza pojedynczego układu jednostka zewnętrzna + inwerter – min. 8

kW (łącznie min. 16 kW),

VI.3.1.8.1.3. Urządzenia przeznaczone do pracy całorocznej przy założeniu utrzymania stałej

temperatury w cyklu całodobowym w czasie pracy ciągłej (moc grzewcza

odpowiednio dobrana),

VI.3.1.8.1.4. Utrzymanie w serwerowni stałej temperatury z zakresu od 18°C do 25°C przy

temperaturze zewnętrznej w zakresie od -20°C do +40°C,

VI.3.1.8.1.5. Praca redundantna z automatycznym przełączaniem w przypadku awarii w

systemie active/active lub fail-over,

VI.3.1.8.1.6. Sygnalizacja awarii alarmem wizualnym i dźwiękowym,

VI.3.1.8.1.7. Jednostka sterująca wyposażona w moduł GSM umożliwiający przesyłanie

komunikatów alarmowych (co najmniej dotyczących przekroczenia parametrów

pracy oraz awarii) poprzez się GSM.

VI.3.1.8.2. Ilość - 1 kpl. (2 szt.)


VI.3.1.8.3.1. Wykonanie niezbędnych przyłączy elektrycznych,


Strona 121 z 208

VI.3.1.8.3.2. Dostawa i montaż klimatyzacji,

VI.3.1.8.3.3. Zabezpieczenie rur oraz instalacji klimatyzacji przy pomocy odpowiednich koryt

kablowych lub otulin mocowanych na stałe do podłoża,

VI.3.1.8.3.4. Przywrócenie miejsca montażu do stanu pierwotnego.



uzgodnić z Zamawiającym sposób i termin takiego montażu systemu klimatyzacji,

aby nie zakłócić organizacji pracy Zamawiającego,






VI.3.1.8.5.1. System klimatyzacji wraz z montażem musi zostać objęty min. 3-letnią gwarancją.


VI.3.1.8.6.1. Etap I – prace podlegające zakryciu – przed zakryciem instalacji oraz

uzupełnieniem otworów technologicznych w ścianach,





VI.3.1.8.7.1. Do oferty należy dołączyć dokument potwierdzający zgodność oferowanego

systemu klimatyzacji z normami zasadniczymi (deklaracja CE).






VI.3.1.8.7.3. Do oferty należy dołączyć oświadczenie Wykonawcy, że oferowane

urządzenie/sprzęt/wyposażenie zostanie dostarczone jako fabrycznie nowe (nie

wyprodukowane wcześniej niż 6 miesięcy przed datą dostawy). Zapis usunięty

przez Zamawiającego.

VI.3.1.9. Dostawa i montaż zasilacza awaryjnego UPS


VI.3.1.9.1.1. Aktualnie u Zamawiającego są eksploatowane 2 UPS po 40kVA połączone w

układzie redundantnym z BYPASSEM serwisowym przygotowanym na

podłączenie 4 szt. UPS. Przedmiotem zamówienia jest dostawa, instalacja i

uruchomienie dodatkowej jednej sztuki UPS o tej samej mocy.


Strona 122 z 208

VI.3.1.9.1.2. System równoległy ma być całkowicie odporny na awarie jego elementów

składowych, włączając w to połączenia logiczne pomiędzy modułami. Układ

połączeń logicznych pomiędzy jednostkami układu równoległego nie może

stanowić pojedynczego punktu awarii, to znaczy przerwanie połączenia

logicznego między urządzeniami pracującymi równolegle nie może spowodować

utraty funkcjonalności systemu zasilania gwarantowanego. Nawet w przypadku

braku komunikacji logicznej, urządzenia zapewnią podtrzymanie zasilania przy

zaniku napięcia z sieci (praca z falownika) z równomiernym obciążeniem

wszystkich jednostek układu.

VI.3.1.9.1.3. System ma być wyposażony w moduł sprzęgający wyjścia 2 zasilaczy UPS, który

będzie umożliwiał bezprzerwowe przełączanie zasilania odbiorów na sieć

zasilającą (bypass serwisowy) w przypadku konieczności odłączenia UPSów.

VI.3.1.9.1.4. Topologia zasilaczy UPS musi być zgodna z PN-EN 62040-3 – (VFI-SS-111)

VI.3.1.9.1.5. Minimalna moc pojedynczego modułu UPS - 40kVA / 36kW

VI.3.1.9.1.6. Czas podtrzymania przy obciążeniu mocą 32kW musi wynosić co najmniej – 12

minut

VI.3.1.9.1.7. Minimalny zakres tolerancji napięcia wejściowego bez korzystania z energii z

baterii, przy 100% obciążeniu każdego UPSa - 340 – 480 V

VI.3.1.9.1.8. Tolerancja częstotliwości wejściowej co najmniej w zakresie 45 – 65 Hz

VI.3.1.9.1.9. Urządzenia powinny posiadać wejście trójfazowe 5-cio przewodowe (TN-S) oraz

wyjście trójfazowe 5-cio przewodowe (TN-S)

VI.3.1.9.1.10. Maksymalny poziom THDi w prądzie wejściowym – 5%

VI.3.1.9.1.11. Minimalny wejściowy współczynnik mocy – 99%

VI.3.1.9.1.12. Zasilacze wyposażone muszą być w komunikacyjne wyświetlacze LCD z odczytem

parametrów elektrycznych wejścia/wyjścia i komunikatów o stanie pracy UPS w

języku polskim

VI.3.1.9.1.13. Maksymalny poziom głośności pojedynczego modułu w normalnym trybie pracy

on-line i w trybie bateryjnym 50 dBA zgodnie z ISO7779,

VI.3.1.9.1.14. Zakres regulacji prądu ładowania baterii co najmniej w zakresie (1 – 25 A)

VI.3.1.9.1.15. Zdolność zwarciowa pojedynczego modułu UPS w czasie 300 ms – 145A

VI.3.1.9.1.16. Stabilizacja napięcia wyjściowego przy dynamicznej zmianie obciążenia od 10% do

90% i odwrotnie w czasie maks. 1 ms - < 5%

VI.3.1.9.1.17. Sprawność UPSa w trybie normalnym on-line w zakresie obciążenia 50 – 100% -

(min 91%)

VI.3.1.9.1.18. Wyposażenie systemu musi zawierać oprogramowanie do monitorowania UPSów

i zamykania co najmniej następujących systemów operacyjnych: Windows: 2000,

XP, 2003 Server, Vista, Server 2008, Linux: Red Hat Enterprise Linux 3, 4 i 5, Fedora

Core 5, 6, 7 i 8, SuSE Linux 8, 9 i 10, SuSE Enterprise Linux Server 8, 9 i 10, VMware

ESX Server 3.5

VI.3.1.9.1.19. Z pomieszczenia, w którym znajduje się zasilacz awaryjny (pokój 008) należy

wykonać nowe połączenie elektryczne 5-przewodowym miedzianym kablem

energetycznym do pomieszczenia serwerowni (pokój 27) przy zachowaniu

następujących wymagań:


Strona 123 z 208

VI.3.1.9.1.19.1. Kabel należy podłączyć do tablicy rozdzielczej znajdującej się w

pomieszczeniu zasilacza (tablica umożliwia podłączenie za zewnętrznym

bypassem zasilaczy awaryjnych),

VI.3.1.9.1.19.2. Przekrój kabla należy dobrać do obciążenia 50 kVA,

VI.3.1.9.1.19.3. Kabel należy przeprowadzić istniejącą trasą kablową w kanałach

technicznych, maksymalna odległość licząc kanałami technicznymi nie

przekracza 50m,

VI.3.1.9.1.19.4. W pomieszczeniu serwerowni należy zaprojektować, zainstalować i

wyposażyć tablicę rozdzielczą umożliwiającą podłączenie 8 linii zasilających

32A dla szaf RACK oraz 4 linii zasilających 16A dla gniazd przypodłogowych,

VI.3.1.9.1.19.5. Z tablicy elektrycznej należy wyprowadzić 8 linii zasilających dla

znajdujących się w pomieszczeniu dwóch szaf RACK (po 4 linie na 1 szafę)

zakończone gniazdami IEC309 w strefie dostarczanej podłogi technicznej

bezpośrednio pod szafami,

VI.3.1.9.1.19.6. Z tablicy elektrycznej należy wyprowadzić 4 linie zasilające zakończone w

strefie przypodłogowej dostarczanej podłogi technicznej (odległość od

podłogi maks. 50 cm) podwójnymi gniazdami DATA 2P+Z,

VI.3.1.9.1.19.7. Instalację gniazd przypodłogowych należy wykonać w kanałach kablowych

dobranych odpowiednio do dostarczanej podłogi technicznej, część

instalacji wykonanej ponad podłogą należy prowadzić w naściennych

kanałach kablowych,

VI.3.1.9.1.19.8. Gniazda przypodłogowe należy dostarczyć w komplecie z kluczami

kodowymi dla gniazd DATA. Zapis usunięty przez Zamawiającego.

VI.3.1.9.2. Ilość - 1 szt


VI.3.1.9.3.1. Podłączenie do funkcjonującego u Zamawiającego zasilacza UPS EATON 9355

model: 9355-40-NHS-0 oraz systemu zasilania,

VI.3.1.9.3.2. Konfiguracja zestawu do pracy,

VI.3.1.9.3.3. Test poprawności połączeń oraz test w symulacji zaniku napięcia zasilania.


VI.3.1.9.4.1. W pomieszczeniu znajduje się działający zasilacz UPS Eaton 9355. Przy

podłączaniu należy uzgodnić z Zamawiającym dopuszczalne okresy przerw w

zasilaniu oraz zabezpieczyć urządzenia serwerowni przed negatywnymi skutkami

zaniku zasilania.


wcześniej niż 6 miesięcy przed datą dostawy) i pochodzić z oficjalnego kanału

dystrybucyjnego producenta. Wykonawca zobowiązany jest dołączyć do oferty

oświadczenie Wykonawcy, że oferowane do przetargu urządzenia spełniają ten

wymóg.


VI.3.1.9.5.1. Zasilacz wraz z montażem musi zostać objęty min. 3-letnią gwarancją.


Strona 124 z 208






VI.3.1.9.7.1. Do oferty należy dołączyć dokument zawierający deklarację producenta

zgodności produktu z normami EN 62040-1-1: 2003 i EN 50091-2: 1995 oraz

spełnienia dyrektyw: 89/336/EEC, 92/31/EEC, 72/23/EEC, 93/68/EEC wraz z

określeniem roku przyznania znaku bezpieczeństwa CE.








wyprodukowane wcześniej niż 6 miesięcy przed datą dostawy) i będzie pochodzić

z oficjalnego kanału dystrybucyjnego producenta.

VI.3.1.10. Dostawa i montaż serwerów kasetowych


VI.3.1.10.1.1. Obudowa

VI.3.1.10.1.1.1. zgodna z obudową blade Fujitsu PRIMERGY BX900;

VI.3.1.10.1.1.2. możliwość instalacji minimum 2 dysków SSD w obudowie serwera;

VI.3.1.10.1.1.3. dioda pozwalająca na wizualną identyfikację serwera w obudowie;

VI.3.1.10.1.1.4. diodowa sygnalizacja: pracy, usterki, aktywności połączeń LAN;

VI.3.1.10.1.2. Procesory

VI.3.1.10.1.2.1. zainstalowane co najmniej dwa procesory wielordzeniowe 64-bitowe w

architekturze x86;

VI.3.1.10.1.2.2. procesory osiągające w zaoferowanym modelu serwera wynik minimum

500 punktów w teście SPECint_rate2006 w kolumnie Results Base

(Zamawiający wskazuje adres publikacji testów

http://www.spec.org/cpu2006/results/rint2006.html, który został

wykorzystany przez Zamawiającego do określenia wymogów

minimalnych dla procesora. W przypadku zmiany adresu publikacji

testów Zamawiający akceptuje wynik testu SPECint_rate2006

oferowanego procesora znajdującego się pod innym adresem w ramach

strony www.spec.org).

VI.3.1.10.1.2.3. Zamawiający wymaga zaproponowania procesora, dla którego istnieje

wynik w ramach testu SPECint_rate2006 na stronie www.spec.org.

VI.3.1.10.1.3. Płyta główna:

VI.3.1.10.1.3.1. obsługa minimum dwóch procesorów wielordzeniowych;

http://www.spec.org/cpu2006/results/rint2006.html

http://www.spec.org/



Strona 125 z 208

VI.3.1.10.1.3.2. obsługa minimum 192 GB pamięci operacyjnej z korekcją błędów ECC ;

VI.3.1.10.1.3.3. zainstalowany układ szyfrowania zgodny z TPM 1.2;

VI.3.1.10.1.4. Pamięć RAM

VI.3.1.10.1.4.1. wyposażony w minimum 128GB pamięci RAM obsadzonych w trybie

pełnej wydajności, registered, ECC.

VI.3.1.10.1.5. Kontrolery i dyski

VI.3.1.10.1.5.1. zintegrowany z płytą główna kontroler RAID 0,1 pozwalający na obsługę

minimum dwóch dysków typu SSD.

VI.3.1.10.1.5.2. zainstalowane co najmniej dwa dyski SSD o pojemności minimum 100GB

każdy,

VI.3.1.10.1.6. Interfejsy I/O, złącza

VI.3.1.10.1.6.1. minimum 2 interfejsy LAN typu 10 Gbit/s podłączone poprzez backplane

do switchy zainstalowanych w obudowie blade, minimum 2 interfejsy FC

o prędkości min. 8 Gb/sek. do komunikacji poprzez backplane,

VI.3.1.10.1.6.2. oraz wymaga możliwości zainstalowania minimum 2 interfejsów LAN typu

10 GBIT/s podłączonych poprzez backplane do switchy zainstalowanych

w obudowie blade lub 2 interfejsów FC o prędkości min. 8 Gb/sek. do

komunikacji poprzez backplane.

VI.3.1.10.1.7. Oprogramowanie

VI.3.1.10.1.7.1. oprogramowanie zarządzające i diagnostyczne umożliwiające

konfigurację kontrolera RAID, instalację systemów operacyjnych, zdalne

zarządzanie, diagnostykę i przewidywanie awarii w oparciu o informacje

dostarczane w ramach zintegrowanego w serwerze Systemu

umożliwiającego monitoring Systemu i środowiska (temperatura, dyski,

zasilacze, płyta główna, procesory, pamięć operacyjna itd.).

VI.3.1.10.1.8. Dostarczona wraz z serwerem licencja na System operacyjny:

VI.3.1.10.1.8.1. System operacyjny musi umożliwiać podłączenie serwerów do

istniejącego kontrolera domeny Active Directory w Urzędzie;

VI.3.1.10.1.8.2. Licencja na oprogramowanie musi być przypisana do każdego procesora

fizycznego na serwerze. Liczba rdzeni procesorów i ilość pamięci nie mogą

mieć wpływu na liczbę wymaganych licencji. Licencja musi uprawniać do

uruchamiania serwerowego systemu operacyjnego (SSO) w środowisku

fizycznym i dwóch wirtualnych środowisk serwerowego systemu

operacyjnego za pomocą wbudowanych mechanizmów wirtualizacji.

VI.3.1.10.1.8.3. Serwerowy system operacyjny (SSO) musi posiadać następujące,

wbudowane cechy.

VI.3.1.10.1.8.3.1. Możliwość wykorzystania, co najmniej 320 logicznych procesorów

oraz co najmniej 4 TB pamięci RAM w środowisku fizycznym

VI.3.1.10.1.8.3.2. Możliwość wykorzystywania 64 procesorów wirtualnych oraz 1TB

pamięci RAM i dysku o pojemności min. 64TB przez każdy wirtualny

serwerowy system operacyjny.

VI.3.1.10.1.8.3.3. Możliwość budowania klastrów składających się z 64 węzłów, z

możliwością uruchamiania do 8000 maszyn wirtualnych.

VI.3.1.10.1.8.3.4. Możliwość migracji maszyn wirtualnych bez zatrzymywania ich

pracy między fizycznymi serwerami z uruchomionym


Strona 126 z 208

mechanizmem wirtualizacji (hypervisor) przez sieć Ethernet, bez

konieczności stosowania dodatkowych mechanizmów

współdzielenia pamięci.

VI.3.1.10.1.8.3.5. Wsparcie (na umożliwiającym to sprzęcie) dodawania i wymiany

pamięci RAM bez przerywania pracy.

VI.3.1.10.1.8.3.6. Wsparcie (na umożliwiającym to sprzęcie) dodawania i wymiany

procesorów bez przerywania pracy.

VI.3.1.10.1.8.3.7. Automatyczna weryfikacja cyfrowych sygnatur sterowników w celu

sprawdzenia, czy sterownik przeszedł testy jakości

przeprowadzone przez producenta systemu operacyjnego.

VI.3.1.10.1.8.3.8. Możliwość dynamicznego obniżania poboru energii przez rdzenie

procesorów niewykorzystywane w bieżącej pracy. Mechanizm ten

musi uwzględniać specyfikę procesorów wyposażonych w

mechanizmy Hyper-Threading.

VI.3.1.10.1.8.3.9. Wbudowane wsparcie instalacji i pracy na wolumenach, które:

a. pozwalają na zmianę rozmiaru w czasie pracy systemu,

b. umożliwiają tworzenie w czasie pracy systemu migawek,

dających użytkownikom końcowym (lokalnym i

sieciowym) prosty wgląd w poprzednie wersje plików i

folderów,

c. umożliwiają kompresję "w locie" dla wybranych plików

i/lub folderów,

d. umożliwiają zdefiniowanie list kontroli dostępu (ACL).

VI.3.1.10.1.8.3.10. Wbudowany mechanizm klasyfikowania i indeksowania plików

(dokumentów) w oparciu o ich zawartość.

VI.3.1.10.1.8.3.11. Wbudowane szyfrowanie dysków przy pomocy mechanizmów

posiadających certyfikat FIPS 140-2 lub równoważny wydany przez

NIST lub inną agendę rządową zajmującą się bezpieczeństwem

informacji.

VI.3.1.10.1.8.3.12. Możliwość uruchamianie aplikacji internetowych wykorzystujących

technologię ASP.NET

VI.3.1.10.1.8.3.13. Możliwość dystrybucji ruchu sieciowego HTTP pomiędzy kilka

serwerów.

VI.3.1.10.1.8.3.14. Wbudowana zapora internetowa (firewall) z obsługą

definiowanych reguł dla ochrony połączeń internetowych i

intranetowych.

VI.3.1.10.1.8.3.15. Graficzny interfejs użytkownika.

VI.3.1.10.1.8.3.16. Zlokalizowane w języku polskim, co najmniej następujące

elementy: menu, przeglądarka internetowa, pomoc, komunikaty

systemowe,

VI.3.1.10.1.8.3.17. Wsparcie dla większości powszechnie używanych urządzeń

peryferyjnych (drukarek, urządzeń sieciowych, standardów USB,

Plug&Play).

VI.3.1.10.1.8.3.18. Możliwość zdalnej konfiguracji, administrowania oraz

aktualizowania systemu.


Strona 127 z 208

VI.3.1.10.1.8.3.19. Dostępność bezpłatnych narzędzi producenta systemu

umożliwiających badanie i wdrażanie zdefiniowanego zestawu

polityk bezpieczeństwa.

VI.3.1.10.1.8.3.20. Pochodzący od producenta systemu serwis zarządzania polityką

konsumpcji informacji w dokumentach (Digital Rights

Management).

VI.3.1.10.1.8.3.21. Możliwość implementacji następujących funkcjonalności bez

potrzeby instalowania dodatkowych produktów (oprogramowania)

innych producentów wymagających dodatkowych licencji:

a. Podstawowe usługi sieciowe: DHCP oraz DNS wspierający

DNSSEC,

b. Usługi katalogowe oparte o LDAP i pozwalające na

uwierzytelnianie użytkowników stacji roboczych, bez

konieczności instalowania dodatkowego

oprogramowania na tych stacjach, pozwalające na

zarządzanie zasobami w sieci (użytkownicy, komputery,

drukarki, udziały sieciowe), z możliwością wykorzystania

następujących funkcji:

- Podłączenie SSO do domeny w trybie offline – bez

dostępnego połączenia sieciowego z domeną,

- Ustanawianie praw dostępu do zasobów domeny

na bazie sposobu logowania użytkownika – na

przykład typu certyfikatu użytego do logowania,

VI.3.1.10.1.8.4. Odzyskiwanie przypadkowo skasowanych obiektów usługi katalogowej z

mechanizmu kosza.

a. Zdalna dystrybucja oprogramowania na stacje robocze.

b. Praca zdalna na serwerze z wykorzystaniem terminala

(cienkiego klienta) lub odpowiednio skonfigurowanej

stacji roboczej

c. Centrum Certyfikatów (CA), obsługa klucza publicznego i

prywatnego) umożliwiające:

- Dystrybucję certyfikatów poprzez http

- Konsolidację CA dla wielu lasów domeny,

- Automatyczne rejestrowania certyfikatów

pomiędzy różnymi lasami domen.

VI.3.1.10.1.8.5. Szyfrowanie plików i folderów.

VI.3.1.10.1.8.6. Szyfrowanie połączeń sieciowych pomiędzy serwerami oraz serwerami i

stacjami roboczymi (IPSec).

VI.3.1.10.1.8.7. Możliwość tworzenia systemów wysokiej dostępności (klastry typu fail-

over) oraz rozłożenia obciążenia serwerów.

VI.3.1.10.1.8.8. Serwis udostępniania stron WWW.

VI.3.1.10.1.8.9. Wsparcie dla protokołu IP w wersji 6 (IPv6),

VI.3.1.10.1.8.10. Wbudowane usługi VPN pozwalające na zestawienie nielimitowanej liczby

równoczesnych połączeń i niewymagające instalacji dodatkowego

oprogramowania na komputerach z systemem Windows,


Strona 128 z 208

VI.3.1.10.1.8.11. Wbudowane mechanizmy wirtualizacji (Hypervisor) pozwalające na

uruchamianie min. 1000 aktywnych środowisk wirtualnych systemów

operacyjnych. Wirtualne maszyny w trakcie pracy i bez zauważalnego

zmniejszenia ich dostępności mogą być przenoszone pomiędzy serwerami

klastra typu failover z jednoczesnym zachowaniem pozostałej

funkcjonalności. Mechanizmy wirtualizacji mają zapewnić wsparcie dla:

a. Dynamicznego podłączania zasobów dyskowych typu hot-

plug do maszyn wirtualnych,

b. Obsługi ramek typu jumbo frames dla maszyn

wirtualnych.

c. Obsługi 4-KB sektorów dysków

d. Nielimitowanej liczby jednocześnie przenoszonych

maszyn wirtualnych pomiędzy węzłami klastra

e. Możliwości wirtualizacji sieci z zastosowaniem

przełącznika, którego funkcjonalność może być

rozszerzana jednocześnie poprzez oprogramowanie kilku

innych dostawców poprzez otwarty interfejs API.

f. Możliwości kierowania ruchu sieciowego z wielu sieci

VLAN bezpośrednio do pojedynczej karty sieciowej

maszyny wirtualnej (tzw. trunk model)

VI.3.1.10.1.8.12. Możliwość automatycznej aktualizacji w oparciu o poprawki publikowane

przez producenta wraz z dostępnością bezpłatnego rozwiązania

producenta SSO umożliwiającego lokalną dystrybucję poprawek

zatwierdzonych przez administratora, bez połączenia z siecią Internet.

VI.3.1.10.1.8.13. Wsparcie dostępu do zasobu dyskowego SSO poprzez wiele ścieżek

(Multipath).

VI.3.1.10.1.8.14. Możliwość instalacji poprawek poprzez wgranie ich do obrazu

instalacyjnego.

VI.3.1.10.1.8.15. Mechanizmy zdalnej administracji oraz mechanizmy (również działające

zdalnie) administracji przez skrypty.

VI.3.1.10.1.8.16. Możliwość zarządzania przez wbudowane mechanizmy zgodne ze

standardami WBEM oraz WS-Management organizacji DMTF.

VI.3.1.10.1.9. Zarządzanie

VI.3.1.10.1.9.1. zintegrowany z płytą główną kontroler zdalnego zarządzania zgodny ze

standardem IPMI 2.0 zapewniający zdalny restart serwera i pełne

zarządzanie włącznie z przejęciem zdalnym konsoli tekstowej, konsoli

graficznej oraz zdalnego podłączenia napędów na poziomie sprzętowym;

VI.3.1.10.1.10. Inne

VI.3.1.10.1.11. elementy, z których zbudowane są serwery muszą być produktami producenta

tych serwerów lub być przez niego certyfikowane oraz muszą być objęte

gwarancją producenta, potwierdzoną przez oryginalne karty gwarancyjne.

Wykonawca zobowiązany jest dołączyć do oferty oświadczenie producenta lub

Wykonawcy o spełnieniu wskazanego wymagania..

VI.3.1.10.2. Ilość – 2 szt


Strona 129 z 208


VI.3.1.10.3.1. Zamontowanie serwerów w obudowie blade,

VI.3.1.10.3.2. Instalacja systemów operacyjnych oraz oprogramowania do zarządzania,

VI.3.1.10.3.3. Podłączenie interfejsów sieciowych i interfejsów FC do przełączników w obudowie

blade,

VI.3.1.10.3.4. Konfiguracja portów sieciowych zgodnie z metodyką przyjętą w sieci

Zamawiającego i w sposób wskazany przez Zamawiającego,

VI.3.1.10.3.5. Konfiguracja portów FC zgodnie z metodyką przyjętą przez Zamawiającego i w

sposób wskazany przez Zamawiającego,

VI.3.1.10.3.6. Wykonanie dokumentacji powykonawczej obejmującej co najmniej: topologię

połączeń serwerów, adresację wszystkich interfejsów Ethernet oraz FC,

przydzielenie wolumenów dyskowych oraz ich przeznaczenie, uruchomione usługi

oraz ich konfigurację, dane kont użytkowników (w tym administratora) wraz z

hasłami.


VI.3.1.10.4.1. W komplecie należy dołączyć zestaw akcesoriów montażowych dla przyjętego

typu montażu oraz komplet kabli zasilających, wraz z niezbędnymi licencjami

umożliwiającymi prawidłowe podłączenie serwerów do klatki serwerowej blade.


uzgodnić z Zamawiającym sposób i termin takiego montażu systemu serwerów

kasetowych, aby nie zakłócić organizacji pracy Zamawiającego,





wymóg.


VI.3.1.10.5.1. Gwarancja min. 3 lata realizowana w miejscu dostawy w następnym dniu

roboczym po przyjęciu zgłoszenia,

VI.3.1.10.5.2. Serwis urządzeń musi być realizowany przez producenta lub autoryzowanego

partnera serwisowego producenta.


VI.3.1.10.6.1. Po zakończeniu montażu, konfiguracji i uruchomienia serwerów.




VI.3.1.10.7.1. Do oferty należy dołączyć dokument potwierdzający zgodność oferowanych

serwerów z normami zasadniczymi (deklaracja CE),


Strona 130 z 208

VI.3.1.10.7.2. Do oferty należy dołączyć wydruk ze strony SPEC potwierdzający wynik osiągany

przez oferowane wraz z serwerem procesory w oferowanej konfiguracji

sprzętowej,

VI.3.1.10.7.3. Do oferty należy dołączyć dokument potwierdzający, że oferowany serwer jest

fabrycznie nowy i nieregenerowany.

VI.3.1.10.7.4. Do oferty należy załączyć dokumenty potwierdzające, że oferowany sprzęt jest

produkowany zgodnie z normami ISO 9001 oraz ISO 14001.








wyprodukowane wcześniej niż 6 miesięcy przed datą dostawy) i będzie

pochodzić z oficjalnego kanału dystrybucyjnego producenta.

VI.3.1.11. Dostawa i montaż serwera kasetowego na potrzeby systemu raportowego



VI.3.1.11.1.1.1. zgodna z obudową blade Fujitsu PRIMERGY BX900. Zamawiający posiada

8 wolnych gniazd w obudowie blade);

VI.3.1.11.1.1.2. możliwość instalacji minimum 2 dysków SSD w obudowie serwera;

VI.3.1.11.1.1.3. dioda pozwalająca na wizualną identyfikację serwera w obudowie;

VI.3.1.11.1.1.4. diodowa sygnalizacja: pracy, usterki, aktywności połączeń LAN;


VI.3.1.11.1.2.1. zainstalowane co najmniej dwa procesory wielordzeniowe 64-bitowe w

architekturze x86;

VI.3.1.11.1.2.2. procesory osiągające w zaoferowanym modelu serwera wynik minimum

500 punktów w teście SPECint_rate2006 w kolumnie Results Base



wykorzystany przez Zamawiającego do określenia wymogów

minimalnych dla procesora. W przypadku zmiany adresu publikacji

testów Zamawiający akceptuje wynik testu SPECint_rate2006

oferowanego procesora znajdującego się pod innym adresem w ramach

strony www.spec.org).



VI.3.1.11.1.3. Płyta główna:

VI.3.1.11.1.3.1. obsługa minimum dwóch procesorów wielordzeniowych;

VI.3.1.11.1.3.2. obsługa minimum 192 GB pamięci operacyjnej z korekcją błędów ECC ;

VI.3.1.11.1.3.3. zainstalowany układ szyfrowania zgodny z TPM 1.2;





Strona 131 z 208


VI.3.1.11.1.4.1. wyposażony w minimum 64GB pamięci RAM (osiem modułów po 8GB)

obsadzonych w trybie pełnej wydajności, registered, ECC. Wymaga się

aby pozostało wolnych min 10 gniazd pamięci

VI.3.1.11.1.5. Kontrolery i dyski

VI.3.1.11.1.5.1. zintegrowany z płytą główna kontroler RAID 0,1 pozwalający na obsługę

minimum dwóch dysków typu SSD,

VI.3.1.11.1.5.2. zainstalowane co najmniej dwa dyski SSD o pojemności minimum 100GB

każdy,

VI.3.1.11.1.6. Interfejsy I/O, złącza

VI.3.1.11.1.6.1. minimum 2 interfejsy LAN typu 10 Gbit/s podłączone poprzez backplane

do switchy zainstalowanych w obudowie blade, minimum 2 interfejsy FC

o prędkości min. 8 Gb/sek. do komunikacji poprzez backplane,

VI.3.1.11.1.6.2. oraz wymaga możliwości zainstalowania minimum 2 interfejsów LAN typu

10 GBIT/s podłączonych poprzez backplane do switchy zainstalowanych

w obudowie blade lub 2 interfejsów FC o prędkości min. 8 Gb/sek. do

komunikacji poprzez backplane.


VI.3.1.11.1.7.1. Oprogramowanie zarządzające i diagnostyczne umożliwiające

konfigurację kontrolera RAID, instalację systemów operacyjnych, zdalne

zarządzanie, diagnostykę i przewidywanie awarii w oparciu o informacje

dostarczane w ramach zintegrowanego w serwerze Systemu

umożliwiającego monitoring Systemu i środowiska (temperatura, dyski,

zasilacze, płyta główna, procesory, pamięć operacyjna itd.).

VI.3.1.11.1.7.2. Komplet licencji na system operacyjny dla serwera w warstwie

regionalnej, zgodny z analizą przedwdrożeniową w zakresie architektury

dla oprogramowania systemowego, który pozwoli na uruchomienie

wszystkich funkcjonalności systemu raportowego,

VI.3.1.11.1.7.3. Komplet licencji na oprogramowanie bazy danych dla serwera w warstwie

regionalnej, zgodny z analizą przedwdrożeniową w zakresie architektury

dla oprogramowania systemowego, który pozwoli na uruchomienie

wszystkich funkcjonalności systemu raportowego,

VI.3.1.11.1.7.4. Komplet licencji na oprogramowanie serwera raportowego dla serwera w

warstwie regionalnej, zgodny z analizą przedwdrożeniową w zakresie

architektury dla oprogramowania systemowego, który pozwoli na

uruchomienie wszystkich funkcjonalności systemu raportowego,

VI.3.1.11.1.7.5. Serwer raportowy musi mieć wbudowaną funkcjonalność serwera WWW,

VI.3.1.11.1.8. Zarządzanie

VI.3.1.11.1.8.1. zintegrowany z płytą główną kontroler zdalnego zarządzania zgodny ze

standardem IPMI 2.0 zapewniający zdalny restart serwera i pełne

zarządzanie włącznie z przejęciem zdalnym konsoli tekstowej, konsoli

graficznej oraz zdalnego podłączenia napędów na poziomie sprzętowym;

VI.3.1.11.1.9. Elementy, z których zbudowane są serwery muszą być produktami producenta

tych serwerów lub być przez niego certyfikowane oraz muszą być objęte

gwarancją producenta, potwierdzoną przez oryginalne karty gwarancyjne.


Strona 132 z 208

Wykonawca zobowiązany jest dołączyć do oferty oświadczenie producenta lub

Wykonawcy o spełnieniu wskazanego wymagania..

VI.3.1.11.2. Ilość – 1 szt


VI.3.1.11.3.1. Zamontowanie serwera w obudowie blade,

VI.3.1.11.3.2. Instalacja systemu operacyjnego oraz oprogramowania do zarządzania,

VI.3.1.11.3.3. Instalacja i konfiguracja systemu raportowego,

VI.3.1.11.3.4. Podłączenie interfejsów sieciowych i interfejsów FC do przełączników w obudowie

blade,

VI.3.1.11.3.5. Konfiguracja portów sieciowych zgodnie z metodyką przyjętą w sieci

Zamawiającego i w sposób wskazany przez Zamawiającego,

VI.3.1.11.3.6. Konfiguracja portów FC zgodnie z metodyką przyjętą przez Zamawiającego i w

sposób wskazany przez Zamawiającego,

VI.3.1.11.3.7. Wykonanie dokumentacji powykonawczej obejmującej co najmniej: topologię

połączeń serwerów, adresację wszystkich interfejsów Ethernet oraz FC,

przydzielenie wolumenów dyskowych oraz ich przeznaczenie, uruchomione usługi

oraz ich konfigurację, dane kont użytkowników (w tym administratora) wraz z

hasłami.



typu montażu oraz komplet kabli zasilających, wraz z niezbędnymi licencjami

umożliwiającymi prawidłowe podłączenie serwerów do klatki serwerowej blade.


uzgodnić z Zamawiającym sposób i termin takiego montażu serwerów

kasetowych, aby nie zakłócić organizacji pracy Zamawiającego,





wymóg.


VI.3.1.11.5.1. Gwarancja min. 3 lata realizowana w miejscu dostawy w następnym dniu

roboczym po przyjęciu zgłoszenia,

VI.3.1.11.5.2. Serwis urządzeń musi być realizowany przez producenta lub autoryzowanego

partnera serwisowego producenta.


VI.3.1.11.6.1. Po zakończeniu montażu, konfiguracji i uruchomieniu serwera.




Strona 133 z 208



serwerów z normami zasadniczymi (deklaracja CE),



sprzętowej,

VI.3.1.11.7.3. Do oferty należy dołączyć dokument potwierdzający, że oferowany serwer jest

fabrycznie nowy i nieregenerowany.












VI.3.1.12. Dostawa, montaż i konfiguracja urządzeń klasy UTM


VI.3.1.12.1.1. urządzenie modularne pozwalające na uzyskanie funkcji firewall, VPN (sprzętowe

wsparcie szyfrowania), sondy IPS, kontroli ruchu

VI.3.1.12.1.2. wyposażone w co najmniej cztery interfejsy Ethernet 10/100/1000 Mb/s

VI.3.1.12.1.3. wyposażone w co najmniej jeden interfejs dla zarządzania pozapasmowego (OOB)

VI.3.1.12.1.4. wyposażone w moduł sprzętowego wsparcia szyfrowania DES i AES 256

VI.3.1.12.1.5. porty dedykowane dla zarządzania: port konsoli

VI.3.1.12.1.6. co najmniej jeden port USB (tokeny, certyfikaty etc.)

VI.3.1.12.1.7. co najmniej 4GB pamięci Flash

VI.3.1.12.1.8. co najmniej 2GB pamięci DRAM

VI.3.1.12.1.9. możliwość rozbudowy o co najmniej:

VI.3.1.12.1.9.1. funkcjonalności Systemu IPS (Intrusion Prevention System)

VI.3.1.12.1.9.1.1. obsługa IPv4 i IPv6

VI.3.1.12.1.9.1.2. wydajność min. 350Mb/s

VI.3.1.12.1.9.1.3. praca w trybie online

VI.3.1.12.1.10. zasilacz umożliwiający zasilanie prądem przemiennym 230V

VI.3.1.12.1.11. wydajność:

VI.3.1.12.1.11.1. co najmniej 1,2 Gb/s ruchu poddawanego inspekcji przez mechanizmy

ściany ogniowej

VI.3.1.12.1.11.2. co najmniej 250 Mb/s ruchu szyfrowanego

VI.3.1.12.1.11.3. terminowanie co najmniej 250 jednoczesnych sesji IPSec VPN


Strona 134 z 208

VI.3.1.12.1.11.4. możliwość terminowania jednocześnie 250 sesji WebVPN (min. 2 w

oferowanej konfiguracji)

VI.3.1.12.1.11.5. nielimitowana liczba użytkowników

VI.3.1.12.1.11.6. bezterminowa licencja na firewall i VPN

VI.3.1.12.1.11.7. obsługa co najmniej 250 000 jednoczesnych sesji/połączeń z

prędkością 15 000 połączeń na sekundę

VI.3.1.12.1.11.8. obsługa min. 2 wirtualnych instancji firewall z możliwością rozbudowy

do min. 20-stu

VI.3.1.12.1.11.9. obsługa min. 100 sieci logicznych VLAN

VI.3.1.12.1.12. Oprogramowanie – funkcjonalność:

VI.3.1.12.1.12.1. ściana ogniowa śledząca stan połączeń z funkcją weryfikacji informacji

charakterystycznych dla warstwy aplikacji

VI.3.1.12.1.12.2. bez ograniczenia na ilość jednocześnie pracujących użytkowników w

sieci chronionej

VI.3.1.12.1.12.3. dostarczone wraz z dedykowanym Oprogramowaniem klienta VPN.

Oprogramowanie musi mieć możliwość instalacji na stacjach roboczych

pracujących pod kontrolą Systemów operacyjnych Windows, Solaris i

Linux, a także komputerach Mac. Oprogramowanie musi umożliwiać

zestawienie do urządzenia stanowiącego przedmiot postępowania

połączeń VPN z komputerów osobistych PC. Oprogramowanie to

powinno pochodzić od tego samego producenta, co oferowane

urządzenie i powinno być objęte jego jednolitym wsparciem

technicznym.

VI.3.1.12.1.12.4. możliwość operowania jako transparentna ściana ogniowa warstwy

drugiej ISO OSI (dla IPv4 i IPv6)

VI.3.1.12.1.12.5. możliwość routingu pakietów zgodnie z protokołami RIP, OSPF

VI.3.1.12.1.12.6. mechanizmy związane z obsługą ruchu multicast (IGMP, PIM-SM)

VI.3.1.12.1.12.7. protokół NTP

VI.3.1.12.1.12.8. obsługa IKE, IKE Extended Authentication (Xauth) oraz IKE Aggressive

Mode

VI.3.1.12.1.12.9. współpraca z serwerami PKI CA

VI.3.1.12.1.12.10. funkcjonalność Network Address Translation (NAT)

VI.3.1.12.1.12.11. mechanizmy inspekcji aplikacyjnej i kontroli następujących usług:

VI.3.1.12.1.12.11.1. Hypertext Transfer Protocol (HTTP),

VI.3.1.12.1.12.11.2. File Transfer Protocol (FTP),

VI.3.1.12.1.12.11.3. Extended Simple Mail Transfer Protocol (ESMTP), Zapis usunięty

przez Zamawiającego

VI.3.1.12.1.12.11.4. Domain Name System (DNS),

VI.3.1.12.1.12.11.5. Simple Network Management Protocol (SNMP),

VI.3.1.12.1.12.11.6. Internet Control Message Protocol (ICMP),

VI.3.1.12.1.12.11.7. SQL*Net,

VI.3.1.12.1.12.11.8. Network File System (NFS),

VI.3.1.12.1.12.11.9. H.323 (wersje 1-4),

VI.3.1.12.1.12.11.10. H.239

VI.3.1.12.1.12.11.11. Session Initiation Protocol (SIP),


Strona 135 z 208

VI.3.1.12.1.12.11.12. Real-Time Streaming Protocol (RTSP),

VI.3.1.12.1.12.11.13. Lightweight Directory Access Protocol (LDAP), Internet Locator

Service (ILS),

VI.3.1.12.1.12.11.14. Sun Remote Procedure Call (RPC)

VI.3.1.12.1.12.12. inspekcja ruchu głosowego i wideo w zakresie protokołów H.323,

H.239, SIP

VI.3.1.12.1.12.13. możliwość blokowania aplikacji tunelowanych z użyciem portu 80 w

tym:

VI.3.1.12.1.12.13.1. blokowanie komunikatorów internetowych w tym AOL Instant

Messenger, Microsoft Messenger, Yahoo Messenger

VI.3.1.12.1.12.13.2. blokowanie aplikacji typu peer-to-peer w tym KaZaA i Gnutella

VI.3.1.12.1.12.13.3. wykrywanie ruchu typu botnet, spyware. Malware, aktywności

użytkowników na portalach społecznościowych typu MySpace,

Facebook, Zapis usunięty przez Zamawiającego

VI.3.1.12.1.12.13.4. zapobieganie stosowaniu aplikacji typu GoToMyPC

VI.3.1.12.1.12.14. obsługa protokołu ESMTP w zakresie wykrywania anomalii, śledzenia

stanu protokołu oraz obsługi komend wprowadzonych wraz z

protokołem ESMTP

VI.3.1.12.1.12.15. możliwość inspekcji protokołów HTTP oraz FTP na niestandardowych

portach

VI.3.1.12.1.12.16. wsparcie stosu protokołów IPv6 w tym:

VI.3.1.12.1.12.16.1. dla list kontroli dostępu dla IPv6

VI.3.1.12.1.12.16.2. inspekcji aplikacyjnej co najmniej dla protokołów HTTP, FTP, SMTP,

ICMP,

VI.3.1.12.1.12.17. współpraca z serwerami autoryzacji (RADIUS, TACACS+ lub

równoważny) w zakresie przesyłania list kontroli dostępu z serwera do

urządzenia z dokładnością per użytkownik

VI.3.1.12.1.12.18. mechanizmy redundancji w tym możliwość konfiguracji urządzeń w

układ zapasowy (failover) działający w modelu active/standby oraz

active/active

VI.3.1.12.1.12.19. funkcjonalność stateful Failover dla ruchu VPN

VI.3.1.12.1.13. zarządzanie i konfiguracja

VI.3.1.12.1.13.1. możliwość eksportu informacji przez syslog

VI.3.1.12.1.13.2. możliwość eksportu informacji o przekazywanym ruchu w oparciu o

sFlow lub równoważny protokół (NetFlow, jFlow itp.),

VI.3.1.12.1.13.3. możliwość komunikacji z serwerami uwierzytelnienia i autoryzacji za

pośrednictwem protokołu RADIUS, TACACS+ lub równoważnego, LDAP

VI.3.1.12.1.13.4. konfigurowalne przez CLI oraz interfejs graficzny (oczekiwane są

narzędzia dodatkowe w postaci kreatorów połączeń, etc.)

VI.3.1.12.1.13.5. dostęp do urządzenia przez SSHv1 i SSHv2

VI.3.1.12.1.13.6. obsługa SNMPv3

VI.3.1.12.1.13.7. plik konfiguracyjny urządzenia musi być możliwy do edycji w trybie off-

line, tzn. konieczna jest możliwość przeglądania i zmian konfiguracji w

pliku tekstowym na dowolnym urządzeniu PC. Po zapisaniu konfiguracji


Strona 136 z 208

w pamięci nieulotnej powinno być możliwe uruchomienie urządzenia z

nowa konfiguracją

VI.3.1.12.1.13.8. urządzenie musi umożliwiać jednoczesne przechowywanie w pamięci

nieulotnej co najmniej 2 niezależnych konfiguracji urządzenia

VI.3.1.12.1.14. obudowa wykonana z metalu, nie dopuszcza się stosowania urządzeń w obudowie

plastikowej

VI.3.1.12.1.15. obudowa przeznaczona do instalacji w szafie RACK 19”

VI.3.1.12.1.16. do urządzenia musi być dołączony komplet licencji dla zapewnienia wymaganej

funkcjonalności przez okres min. 3 lat.

VI.3.1.12.2. Ilość - 2 szt


VI.3.1.12.3.1. Montaż urządzeń w szafach rack,

VI.3.1.12.3.2. Podłączenie do funkcjonującej u Zamawiającego sieci szkieletowej,

VI.3.1.12.3.3. Konfiguracja do pracy zgodnie ze wskazówkami Zamawiającego (w szczególności

adresacja, routing, polityki bezpieczeństwa, filtry, QoS),

VI.3.1.12.3.4. Test poprawności działania.



typu montażu oraz komplet kabli zasilających,

VI.3.1.12.4.2. Należy uzgodnić z Zamawiającym sposób i termin takiego montażu urządzeń, aby

nie zakłócić pracy sieci w sposób utrudniający funkcjonowanie organizacji

Zamawiającego,





wymóg.


VI.3.1.12.5.1. Urządzenia muszą zostać objęte min. 3-letnią gwarancją realizowaną w miejscu

instalacji z czasem reakcji w następnym dniu roboczym po przyjęciu zgłoszenia.







urządzeń z normami zasadniczymi (deklaracja CE)


Strona 137 z 208












VI.3.1.13. Dostawa, montaż i konfiguracja macierzy



VI.3.1.13.1.1.1. rozwiązanie musi być dostarczone ze wszystkimi komponentami do

instalacji w standardowej szafie RACK 19” z zajętością maks. 6U w tej szafie;

VI.3.1.13.1.1.2. obudowa musi zawierać układ nadmiarowy dla modułów zasilania i

chłodzenia umożliwiający wymianę tych elementów w razie awarii bez

konieczności wyłączania macierzy;

VI.3.1.13.1.1.3. obudowa powinna posiadać widoczne elementy sygnalizacyjne do

informowania o stanie poprawnej pracy lub awarii/macierzy;

VI.3.1.13.1.1.4. moduły dla rozbudowy o dodatkowe dyski i przestrzeń dyskową muszą

mieć obudowy o zajętości nie większej niż 6U, przy montażu w szafach

przemysłowych standardu 19”;

VI.3.1.13.1.1.5. moduły dla rozbudowy muszą być wyposażone w nadmiarowy układ

zasilania i chłodzenia.

VI.3.1.13.1.2. Pojemność

VI.3.1.13.1.2.1. rozwiązanie musi umożliwiać instalację min 12 dysków formatu 3,5”

wykonanych jako dyski NearLine-SAS/SATA II, musi także umożliwiać

instalację dysków SolidStateDrive;

VI.3.1.13.1.2.2. rozwiązanie musi posiadać możliwość dołączania półek rozszerzeń

umożliwiających rozbudowę do min 120 dysków, macierz powinna

posiadać możliwość późniejszej rozbudowy wyłącznie poprzez zakup

elementów sprzętowych.

VI.3.1.13.1.3. Kontrolery

VI.3.1.13.1.3.1. rozwiązanie musi posiadać 2 kontrolery pracujące w układzie

nadmiarowym typu active-active, z minimum 8GB pamięci podręcznej

każdy;

VI.3.1.13.1.3.2. w przypadku awarii zasilania dane nie zapisane na dyski, przechowywane w

pamięci CACHE muszą być zabezpieczone metodą trwałego zapisu na dysk

lub pamięć nieulotną niewymagającą podtrzymania bateryjnego bądź


Strona 138 z 208

zabezpieczone poprzez podtrzymanie bateryjne pamięci CACHE przez

minimum 120 godzin

VI.3.1.13.1.3.3. kontrolery muszą posiadać możliwość ich wymiany bez konieczności

wyłączania zasilania całego urządzenia;

VI.3.1.13.1.3.4. w układzie z zainstalowanymi dwoma kontrolerami RAID zawartości

pamięci podręcznej obydwu kontrolerów musi być identyczna tzw. Write

cache mirror;

VI.3.1.13.1.3.5. każdy z kontrolerów RAID powinien posiadać dedykowany interfejs RJ-45

dla potrzeb serwisowych

VI.3.1.13.1.4. Interfejsy FC

VI.3.1.13.1.4.1. oferowana macierz musi mieć minimum po 4 porty FC dla bezpośredniego

podłączenia serwerów lub dla dołączenia do sieci SAN, wyprowadzone na

każdy kontroler RAID.

VI.3.1.13.1.4.2. porty powinny pracować z prędkością min. 8 Gb/s oraz umożliwiać

poprawną pracę także z prędkością 4Gb/s.

VI.3.1.13.1.4.3. interfejsy FC nie mogą być wykorzystywane do innych transmisji

(zarządzanie lub konfiguracja macierzy) niż dane do zapisu / odczytu danych

na zdefiniowane woluminy

VI.3.1.13.1.5. Poziomy RAID

VI.3.1.13.1.5.1. macierz musi zapewniać poziom zabezpieczenia danych na dyskach

definiowany poziomami RAID: 0, 1, 5, 6 (lub inna z podwójną parzystością)

VI.3.1.13.1.6. Oferowana macierz musi wspierać dyski:

VI.3.1.13.1.6.1. NL-SAS (NearLine SAS) i SATA wykonane w technologii hot-plug o

pojemnościach min. 750GB i prędkości obrotowej min. 7200 obrotów na

minutę;

VI.3.1.13.1.6.2. elektroniczne SolidStateDrive wykonane w technologii hot-plug o

pojemnościach min. 100GB – liczba dysków SSD obsługiwanych w macierzy

musi wynosić min 9 szt.;

VI.3.1.13.1.6.3. interfejsy obsługiwanych dysków muszą być wyposażone w min. 2 porty

pracujące w reżimie full-duplex (jednoczesną transmisję danych przez dwa

porty).

VI.3.1.13.1.7. Oferowana macierz musi być dostarczona z zainstalowanymi dyskami o łącznej

pojemności min. 48 TB w trybie surowym (RAW) o czasie wyszukiwania poniżej

10ms;

VI.3.1.13.1.8. Inne

VI.3.1.13.1.8.1. macierz musi wspierać mieszaną konfigurację dysków NearLine-SAS/SATA

i SSD, w obrębie pojedynczego modułu obudowy;

VI.3.1.13.1.8.2. macierz musi wspierać dla min jednej z obsługiwanych technologii

dyskowych mechanizm automatycznej przedawaryjnej migracji zapisów i

składowanych danych na dysk zapasowy;

VI.3.1.13.1.8.3. macierz musi wspierać technologię energooszczędne typu Drive Spin Down

lub wyłączanie dysków nieaktywnych w trybie ręcznym i automatycznym z

wykorzystaniem mechanizmu typu ‘time scheduler’ czyli w zadanym i/lub

powtarzalnym oknie czasowym;


Strona 139 z 208

VI.3.1.13.1.8.4. macierz musi umożliwiać definiowanie i obsługę dysków zapasowych tzw.

hot-spare w trybach:

VI.3.1.13.1.8.5. hot-spare dedykowany dla zabezpieczenia grupy dyskowej RAID;

VI.3.1.13.1.8.6. hot-spare dla zabezpieczania dowolnej grupy dyskowej RAID.


VI.3.1.13.1.9.1. macierz musi być wyposażona w system kopii migawkowych (snapshot) z

licencją na min 8 kopii migawkowych z możliwością rozszerzenia licencji do

min. 1024 kopii migawkowych;

VI.3.1.13.1.9.2. macierz musi wspierać Microsoft Volume ShadowCopy Services (VSS),

licencja wliczona w koszt macierzy;

VI.3.1.13.1.9.3. macierz musi wspierać Microsoft Virtual Disk Services (VDS), licencja

wliczona w koszt macierzy;

VI.3.1.13.1.9.4. macierz musi umożliwiać zdefiniowanie min. 1024 woluminów (LUN),

licencja wliczona w koszt macierzy;

VI.3.1.13.1.9.5. macierz powinna umożliwiać podłączenie logiczne z serwerami poprzez

kilka redundatnych ścieżek logicznych FC;

VI.3.1.13.1.9.6. macierz musi umożliwiać aktualizację oprogramowania wewnętrznego i

kontrolerów RAID bez konieczności wyłączania macierzy i bez konieczności

wyłączania podłączonych serwerów;

VI.3.1.13.1.10. Macierz musi umożliwiać dokonywanie w trybie on-line (tj. bez wyłączania

zasilania i bez przerywania przetwarzania danych w macierzy) operacji:

VI.3.1.13.1.10.1. zmiana rozmiaru woluminu;

VI.3.1.13.1.10.2. zmiana poziomu RAID;

VI.3.1.13.1.10.3. dodawanie nowych dysków do istniejącej grupy dyskowej;

VI.3.1.13.1.11. Macierz musi posiadać wsparcie dla systemów operacyjnych: MS Windows Server

2003/2008, 2008R2/2012, SuSE Linux, RedHat Linux, SUN Solaris, VMWare

5.0/5.1, Citrix XEN Server;

VI.3.1.13.1.12. W cenie macierzy musi być zawarty koszt licencji na oprogramowanie obsługujące

technologię typu multipath (obsługa nadmiarowości dla ścieżek transmisji danych

pomiędzy macierzą i serwerem) dla połączeń FC. Wymagane wsparcie

oprogramowania dla systemów operacyjnych klasy: MS Windows, Linux, VMware.

Cena musi uwzględniać użytkowanie oprogramowania w okresie gwarancji bez

żadnych dodatkowych kosztów;

VI.3.1.13.1.13. Macierz musi umożliwiać wystawienie woluminu logicznego o maksymalnej

pojemności min. 16TB;

VI.3.1.13.1.14. Aktywacja mechanizmu replikacji powinna odbyć się wyłącznie na drodze

uruchomienia właściwej licencji, bez konieczności późniejszego zakupu

elementów sprzętowych (dopuszcza się aby zarządzanie replikacją było

realizowane za pomocą stacji zewnętrznej, nie dopuszcza się jednak replikacji

typu „host-based”).

VI.3.1.13.1.15. Macierz musi być wyposażona w mechanizm umożliwiający szyfrowanie (kluczem

o długości min. 128 bitów) na poziomie LUN’ów, wraz z macierzą powinny zostać

dostarczone ewentualne niezbędne licencje umożliwiające szyfrowanie bez

ograniczeń co do ilości danych oraz ilości serwerów

VI.3.1.13.1.16. Konfiguracja, zarządzanie


Strona 140 z 208

VI.3.1.13.1.16.1. oprogramowanie do zarządzania musi być zintegrowane z systemem

operacyjnym systemu pamięci masowej bez konieczności dedykowania

oddzielnego serwera do obsługi tego oprogramowania;

VI.3.1.13.1.16.2. komunikacja z wbudowanym oprogramowaniem zarządzającym macierzą

musi być możliwa w trybie graficznym np. poprzez przeglądarkę WWW oraz

w trybie tekstowym;

VI.3.1.13.1.16.3. pełne zdalne zarządzanie macierzą powinno być możliwe bez konieczności

instalacji żadnych dodatkowych aplikacji na stacji administratora, przez

dodatkowe aplikacje Zamawiający nie rozumie środowiska

uruchomieniowego typu Java zainstalowanego na stacjach administratora;

VI.3.1.13.1.17. Inne

VI.3.1.13.1.17.1. system musi zapewniać możliwość samodzielnego i automatycznego

powiadamiania producenta i administratorów Zamawiającego o usterkach

za pomocą wiadomości wysyłanych poprzez protokół SNMP lub SMTP.

VI.3.1.13.2. Ilość - 1 szt


VI.3.1.13.3.1. Montaż macierzy w szafie rack,

VI.3.1.13.3.2. Podłączenie do funkcjonującego u Zamawiającego systemu pamięci masowych,

VI.3.1.13.3.3. Konfiguracja ścieżek połączeń FC z wykorzystaniem przełączników FC w obudowie

blade Fujitsu PRIMERGY BX900 posiadanej przez Zamawiającego,

VI.3.1.13.3.4. Konfiguracja wolumenów dyskowych zgodnie ze wskazówkami Zamawiającego,



VI.3.1.13.4.1. W komplecie należy dołączyć wszystkie akcesoria, przewody i licencje

umożliwiające w pełni funkcjonalne użytkowanie macierzy dyskowej po jej

podłączeniu do istniejącej klatki Fujitsu PRIMERGY BX 900 S1 a w szczególności:

VI.3.1.13.4.1.1. zestaw akcesoriów montażowych dla przyjętego typu montażu,

VI.3.1.13.4.1.2. komplet okablowania zasilającego i sygnałowego,

VI.3.1.13.4.1.3. moduły transmisyjne FC i Ethernet,

VI.3.1.13.4.2. Należy uzgodnić z Zamawiającym sposób i termin takiego montażu macierzy, aby

nie zakłócić pracy systemu pamięci masowych w sposób utrudniający

funkcjonowanie organizacji Zamawiającego,





wymóg.


VI.3.1.13.5.1. Urządzenia muszą zostać objęte min. 3-letnią gwarancją realizowaną w miejscu



Strona 141 z 208






VI.3.1.13.7.1. Do oferty należy dołączyć dokument potwierdzający zgodność oferowanej

macierzy z normami zasadniczymi (deklaracja CE)

VI.3.1.13.7.2. do oferty należy załączyć dokumenty potwierdzające, że oferowany sprzęt jest











VI.3.1.14. Dostawa, montaż i konfiguracja przełącznika szkieletowego


VI.3.1.14.1.1. Przełącznik stakowalny wyposażony w min. 24 porty Gigabit Ethernet SFP

VI.3.1.14.1.2. Min. 8 portów Ethernet musi być wyposażone we wkładki optyczne SFP w

standardzie 1000Base-SX LC,

VI.3.1.14.1.3. Przełącznik musi posiadać minimum jeden dodatkowy slot na moduł rozszerzeń z

możliwością jego wymiany „na gorąco” (ang. hot swap). Wśród dostępnych

modułów rozszerzeń muszą być dostępne co najmniej następujące moduły:

Minimum 4-portowy moduł Gigabit Ethernet z gniazdami interfejsów

do obsadzenia optycznymi modułami SFP

Minimum 2-portowy moduł 10GBaseT (porty muszą umożliwiać pracę

zarówno jako 10GE jak i GE)

Minimum 2-portowy moduł 10Gigabit Ethernet SFP+ , przy czym

wymagane jest, aby w przypadku wykorzystanie pojedynczego łącza

10GE istniała możliwość instalacji dodatkowych 2 portów Gigabit

Ethernet SFP

VI.3.1.14.1.4. Porty SFP muszą umożliwiać ich obsadzenie modułami 100Base-FX, 1000Base-T,

1000Base-SX, 1000Base-LX/LH oraz CWDM i DWDM zależnie od potrzeb

Zamawiającego. Porty SFP+ muszą umożliwiać ich obsadzenie modułami

10GBase-SR, 10GBase-LR, 10GBase-LRM


Strona 142 z 208

VI.3.1.14.1.5. Przełącznik musi zapewniać możliwość stakowania z zapewnieniem

następujących parametrów:

Przepustowość w ramach stosu min. 64Gb/s

Min. 4 urządzenia w stosie

Zarządzanie poprzez jeden adres IP

Możliwość tworzenia połączeń cross-stack EtherChannel (czyli dla

portów należących do różnych jednostek w stosie) zgodnie z IEEE

802.3ad

VI.3.1.14.1.6. Urządzenie musi być wyposażone w redundantne i wymienne moduły

wentylatorów

VI.3.1.14.1.7. Urządzenie musi być wyposażone w redundantne zasilacze. Zamawiający nie

dopuszcza stosowania zewnętrznych systemów zasilania redundantnego w celu

realizacji tego zadania. Zasilacze muszą być wymienne.

VI.3.1.14.1.8. Wsparcie sprzętowe i obsługa standardu IEEE 802.1ae szyfrowania ruchu na

portach dostępowych

VI.3.1.14.1.9. Szybkość przełączania minimum 65,5 Mpps dla pakietów 64-bajtowych

VI.3.1.14.1.10. Minimum 512MB pamięci DRAM

VI.3.1.14.1.11. Minimum 64 MB pamięci flash

VI.3.1.14.1.12. Jednoczesna obsługa min. 6.000 adresów MAC, 8.000 tras w tablicy routingu i

1.000 sieci VLAN

VI.3.1.14.1.13. Obsługa protokołu NTP

VI.3.1.14.1.14. Obsługa IGMPv3 i MLDv1/2 Snooping

VI.3.1.14.1.15. Przełącznik musi wspierać następujące mechanizmy związane z zapewnieniem

ciągłości pracy sieci:

IEEE 802.1w Rapid Spanning Tree

IEEE 802.1s Multi-Instance Spanning Tree

Obsługa protokołu LLDP i LLDP-MED.

Funkcjonalność Layer 2 traceroute umożliwiająca śledzenie fizycznej

trasy pakietu o zadanym źródłowym i docelowym adresie MAC

Obsługa funkcji Voice VLAN umożliwiającej odseparowanie ruchu

danych i ruchu głosowego

Przełącznik musi posiadać możliwość uruchomienia funkcji serwera

DHCP

VI.3.1.14.1.16. Urządzenie musi wspierać następujące mechanizmy związane z zapewnieniem

bezpieczeństwa sieci:

Wiele poziomów dostępu administracyjnego poprzez konsolę.

Przełącznik musi umożliwiać zalogowanie się administratora z

konkretnym poziomem dostępu zgodnie z odpowiedzą serwera

autoryzacji

Autoryzacja użytkowników w oparciu o IEEE 802.1x z możliwością

dynamicznego przypisania użytkownika do określonej sieci VLAN

Autoryzacja użytkowników w oparciu o IEEE 802.1x z możliwością

dynamicznego przypisania listy ACL

Obsługa funkcji Guest VLAN umożliwiająca uzyskanie gościnnego

dostępu do sieci dla użytkowników bez suplikanta 802.1X


Strona 143 z 208

Możliwość uwierzytelniania urządzeń na porcie w oparciu o adres MAC

Możliwość uwierzytelniania użytkowników w oparciu o portal www dla

klientów bez suplikanta 802.1X (bez konieczności stosowania

zewnętrznego serwera www)

Wymagane jest wsparcie dla możliwości uwierzytelniania wielu

użytkowników na jednym porcie oraz możliwości jednoczesnego

uwierzytelniania na porcie telefonu IP i komputera PC podłączonego za

telefonem

Funkcjonalność elastycznego uwierzytelniania (możliwość wyboru

kolejności uwierzytelniania – 802.1X/uwierzytelnianie w oparciu o MAC

adres/uwierzytelnianie oparciu o portal www)

Możliwość wdrożenia uwierzytelniania w oparciu o 802.1x w trybie

monitor (niezależnie od tego czy uwierzytelnianie się powiedzie, czy nie

użytkownik ma prawo dostępu do sieci) – jako element sprawdzenia

gotowości instalacji na pełne wdrożenie 802.1x

Przełącznik musi posiadać funkcję supplicanta 802.1X (możliwość

podłączenia przełącznika do innego switcha z uruchomionym

mechanizmem uwierzytelniania 802.1X)

Obsługa funkcji: Port Security, DHCP Snooping, Dynamic ARP Inspection

i IP Source Guard

Możliwość autoryzacji prób logowania do urządzenia (dostęp

administracyjny) do serwerów RADIUS lub TACACS+

Obsługa list kontroli dostępu (ACL)na poziomie portów (PACL), VLAN-

ów (VACL), interfejsów routera L3 (RACL), możliwość konfiguracji tzw.

czasowych list ACL (aktywnych w określonych godzinach i dniach

tygodnia)

VI.3.1.14.1.17. Przełącznik musi wspierać następujące mechanizmy związane z zapewnieniem

jakości usług w sieci:

Implementacja co najmniej czterech kolejek sprzętowych dla ruchu

wyjściowego na każdym porcie dla obsługi ruchu o różnej klasie obsługi.

Implementacja algorytmu Shaped Round Robin lub podobnego dla

obsługi tych kolejek

Możliwość obsługi jednej z powyżej wspomnianych kolejek z

bezwzględnym priorytetem w stosunku do innych (StrictPriority)

Klasyfikacja ruchu do klas różnej jakości obsługi (QoS) poprzez

wykorzystanie następujących parametrów: źródłowy/docelowy adres

MAC, źródłowy/docelowy adres IP, źródłowy/docelowy port TCP

Możliwość ograniczania pasma dostępnego na danym porcie dla ruchu

o danej klasie obsługi z dokładnością do 8 Kbps (policing, rate limiting).

Wymagana jest możliwość skonfigurowania minimum 64 różnych

ograniczeń per port, każde odpowiednio dla różnej klasy obsługi ruchu

Implementacja mechanizmu Weighted Tail Drop lub równoważnego w

celu unikania zatorów

Kontrola sztormów dla ruchu broadcast/multicast/unicast


Strona 144 z 208

Możliwość zmiany przez urządzenie kodu wartości QoS zawartego w

ramce Ethernet lub pakiecie IP – poprzez zmianę pola 802.1p (CoS) oraz

IP ToS/DSCP

VI.3.1.14.1.18. Wsparcie dla DHCP Option 82

VI.3.1.14.1.19. Obsługa protokołu VRRP lub mechanizmu równoważnego dla usług redundancji

bramy dla IPv4 i IPv6

VI.3.1.14.1.20. Urządzenie musi zapewniać możliwość routingu statycznego i dynamicznego

(minimum w oparciu o protokół RIP) dla protokołów IPv4 i IPv6

VI.3.1.14.1.21. Możliwość obsługi tras routingu o jednakowym koszcie (ECMP - Equal-costmulti-

path routing)

VI.3.1.14.1.22. Obsługa funkcji DHCP Relay

VI.3.1.14.1.23. Możliwość konfiguracji list ACL i usług QoS dla IPv6

VI.3.1.14.1.24. Funkcjonalność prywatnego VLAN-u, czyli możliwość blokowania ruchu pomiędzy

portami w obrębie jednego VLANu (tzw. porty izolowane) z pozostawieniem

możliwości komunikacji z portem nadrzędnym

VI.3.1.14.1.25. Urządzenie musi mieć możliwość rozszerzenia funkcjonalności o:

obsługę zaawansowanych protokołów routingu dynamicznego dla IPv4

(w tym OSPF, BGP4, IS-IS) i IPv6 (co najmniej OSPFv3)

Funkcjonalność Policy-based routingu

Obsługa protokołów routingu multicastów – PIM-SM, PIM-DM, PIM-

SSM

monitorowanie parametrów usług dla ruchu IP (IP SLA), w tym również

dla usług wiedo (wbudowany symulator ruchu). Wymagana jest

możliwość monitorowania parametrów takich jak opóźnienie, jitter,

utrata pakietów

VI.3.1.14.1.26. Przełącznik musi umożliwiać zdalną obserwację ruchu na określonym porcie,

polegającą na kopiowaniu pojawiających się na nim ramek i przesyłaniu ich do

zdalnego urządzenia monitorującego, poprzez dedykowaną sieć VLAN (RSPAN)

VI.3.1.14.1.27. Przełącznik musi posiadać makra lub wzorce konfiguracji portów zawierające

prekonfigurowane ustawienie rekomendowane przez producenta sprzętu

zależnie od typu urządzenia dołączonego do portu (np. telefon IP, kamera itp.)

VI.3.1.14.1.28. Dedykowany port Ethernet do zarządzania out-of-band

VI.3.1.14.1.29. Minimum jeden port USB umożliwiający podłączenie zewnętrznego nośnika

danych. Urządzenie musi mieć możliwość uruchomienia z nośnika danych

umieszczonego w porcie USB.

VI.3.1.14.1.30. Urządzenie musi być wyposażone w port konsoli USB

VI.3.1.14.1.31. Plik konfiguracyjny urządzenia musi być możliwy do edycji w trybie off-line (tzn.

konieczna jest możliwość przeglądania i zmian konfiguracji w pliku tekstowym na

dowolnym urządzeniu PC). Po zapisaniu konfiguracji w pamięci nieulotnej musi

być możliwe uruchomienie urządzenia z nową konfiguracją. W pamięci nieulotnej

musi być możliwość przechowywania przynajmniej 5 plików konfiguracyjnych

VI.3.1.14.1.32. Obsługa protokołów SNMPv3, SSHv2, SCP, https, syslog – z wykorzystaniem

protokołów IPv4 i IPv6

VI.3.1.14.1.33. Urządzenie musi umożliwiać tworzenie skryptów celem obsługi zdarzeń, które

mogą pojawić się w systemie


Strona 145 z 208

VI.3.1.14.1.34. Możliwość montażu w szafie rack 19”. Wysokość urządzenia nie może przekraczać

1 U

VI.3.1.14.2. Ilość - 1 szt


VI.3.1.14.3.1. Montaż przełącznika w szafie rack,

VI.3.1.14.3.2. Podłączenie do funkcjonującej u Zamawiającego sieci szkieletowej,

VI.3.1.14.3.3. Wykonanie połączeń zgodnie ze wskazówkami zamawiającego,

VI.3.1.14.3.4. Konfiguracja urządzenia zgodnie ze wskazówkami Zamawiającego,





VI.3.1.14.4.2. Należy uzgodnić z Zamawiającym sposób i termin takiego montażu przełącznika,

aby nie zakłócić pracy sieci w sposób utrudniający funkcjonowanie organizacji

Zamawiającego.





wymóg.


VI.3.1.14.5.1. Przełącznik musi zostać objęty min. 3-letnią gwarancją realizowaną w miejscu








przełącznika z normami zasadniczymi (deklaracja CE).









Strona 146 z 208



VI.3.1.15. Dostawa, instalacja i konfiguracja oprogramowania do archiwizacji danych


VI.3.1.15.1.1. Oprogramowanie musi zapewniać pełną archiwizację dostarczanych do centrum

regionalnego systemów w ramach niniejszego zamówienia,

VI.3.1.15.1.2. Oprogramowanie zarządzające archiwizacją musi współpracować z oferowaną

macierzą dyskową,

VI.3.1.15.1.3. Musi umożliwiać archiwizację wykorzystując sieć SAN FC 8Gb/s oraz sieć

ETHERNET 10Gb/s,

VI.3.1.15.1.4. Musi posiadać licencję na archiwizację co najmniej 20 klientów przyłączonych do

sieci SAN i co najmniej 20 klientów przyłączonych do sieci ETHERNET,

VI.3.1.15.1.5. Musi obsługiwać klientów pracujących pod kontrolą systemów operacyjnych z

rodziny Microsoft Windows Server oraz Linux,

VI.3.1.15.1.6. Musi umożliwiać wykonywania kopii pełnych i przyrostowych,

VI.3.1.15.1.7. Musi posiadać licencje na archiwizację on-line dostarczonych w zamówieniu

pracujących baz danych w liczbie niezbędnej do archiwizacji wdrożonego systemu

oraz licencje na archiwizację on-line dostarczonych środowisk wirtualnych w

liczbie niezbędnej do archiwizacji wszystkich maszyn wirtualnych wdrożonego

systemu,

VI.3.1.15.1.8. Musi umożliwiać dołączenie własnych poleceń przed i po wykonaniu kopii,

VI.3.1.15.1.9. Musi umożliwiać archiwizację danych na dyski twarde zaoferowanej macierzy

dyskowej wykorzystując technologię deduplikacji danych. Licencja na tę

funkcjonalność musi umożliwiać archiwizację co najmniej 10TB danych,

VI.3.1.15.1.10. Licencja na wymagane funkcjonalności musi obejmować min. okres 5 lat.

VI.3.1.15.2. Ilość - 1 kpl


VI.3.1.15.3.1. Instalacja oprogramowania na wskazanej maszynie,

VI.3.1.15.3.2. Konfiguracja harmonogramu archiwizacji zgodnie ze wskazaniami

Zamawiającego,



VI.3.1.15.4.1. Należy uzgodnić z Zamawiającym sposób i termin instalacji i konfiguracji

oprogramowania, aby nie zakłócić pracy systemu przetwarzania danych w sposób

utrudniający funkcjonowanie organizacji Zamawiającego


VI.3.1.15.5.1. Brak.


Strona 147 z 208


VI.3.1.15.6.1. Po zakończeniu instalacji i konfiguracji.

VI.3.1.15.6.2. Formalnemu odbiorowi podlega dostawa do Urzędu Marszałkowskiego


VI.3.1.15.6.3. Podpisany przez Zamawiającego protokół odbioru wszystkich dostaw w ramach





Wykonawca zobowiązany jest do wskazania producenta, rodzaju/wersji

oprogramowania, zakresu dostarczanych licencji, zakres czasowy obowiązywania

wymaganych licencji.

VI.3.2. Modernizacja i doposażenie serwerowni u Uczestników Projektu



Strona 148 z 208

Pozycja

SPZO

Z „P

rzyc

ho

dn

ia D

wo

rco

wa”

w G

orz

ow

ie W

ielk

op

ols

kim

, 66

-40

0 G

orz

ów

Wlk

p.,

ul.

Dw

orc

ow

a 1

3

Wo

jew

ód

zki O

śro

dek

Med

ycyn

y P

racy

, 66

-40

0 G

orz

ów

Wlk

p.,

ul.

Fab

rycz

na

71

Sam

od

ziel

na

Pu

blic

zna

Wo

jew

ód

zka

Stac

ja P

ogo

tow

ia R

atu

nko

weg

o, 6

6-4

00

Go

rzó

w W

lkp

., u

l. K

azim

ierz

a

Wie

lkie

go 7

Wie

losp

ecja

listy

czn

y Sz

pit

al W

oje

wó

dzk

i w G

orz

ow

ie W

lkp

. Sp

. z o

.o.,

66

-40

0 G

orz

ów

Wlk

p.,

ul.

Wal

czak

a 4

2

Sam

od

ziel

ny

Pu

blic

zny

Szp

ital

dla

Ner

wo

wo

i P

sych

iczn

ie C

ho

rych

, 66

-30

0 M

ięd

zyrz

ecz,

ul.

Po

znań

ska

10

9

Lub

usk

i Szp

ital

Sp

ecja

listy

czn

y P

ulm

on

olo

gicz

no

-Kar

dio

logi

czn

y w

To

rzym

iu S

pó

łka

z o

.o.,

66

-23

5 T

orz

ym, u

l.

Wo

jska

Po

lski

ego

52

W

oje

wó

dzk

i Szp

ital

Sp

ecja

listy

czn

y d

la N

erw

ow

o i

Psy

chic

znie

Ch

ory

ch S

amo

dzi

eln

y P

ub

liczn

y Za

kład

Op

ieki

Zdro

wo

tnej

, 66

-21

3 C

ibó

rz 5

O

śro

dek

dla

Osó

b U

zale

żnio

nyc

h S

amo

dzi

eln

y P

ub

liczn

y Za

kład

Op

ieki

Zd

row

otn

ej „

No

wy

Dw

ore

k”, 6

6-2

00

No

wy

Dw

ore

k 4

6;

Lub

usk

i Ośr

od

ek R

ehab

ilita

cyjn

o -

Ort

op

edyc

zny

im. d

r Le

cha

Wie

rusz

a SP

ZOZ,

66

-20

0 Ś

wie

bo

dzi

n, u

l.

Zam

kow

a 1

Wo

jew

ód

zka

Stac

ja P

ogo

tow

ia R

atu

nko

weg

o S

amo

dzi

eln

y P

ub

liczn

y Za

kład

Op

ieki

Zd

row

otn

ej, 6

5-0

43

Zi

elo

na

Gó

ra, u

l. B

. Ch

rob

rego

2

Wo

jew

ód

zki O

śro

dek

Med

ycyn

y P

racy

, 65

-09

6 Z

ielo

na

Gó

ra, u

l. D

ąbró

wki

15

C

SP Z

OZ

„M

EDK

OL”

, 65

-02

0 Z

ielo

na

Gó

ra, u

l. P

lac

Ko

leja

rza

1

Wo

jew

ód

zki O

śro

dek

Ter

apii

Uza

leżn

ień

i W

spó

łuza

leżn

ien

ia, 6

5-0

44

Zie

lon

a G

óra

, ul.

Waz

ów

36

Szp

ital

Wo

jew

ód

zki S

PZO

Z w

Zie

lon

ej G

órz

e, 6

5-0

46

Zie

lon

a G

óra

, ul.

Zyty

26

SP Z

OZ

Cen

tru

m L

ecze

nia

Dzi

eci i

Mło

dzi

eży

w Z

abo

rze

, 66

-00

3 Z

abó

r, u

l. Za

mko

wa

1

Razem

Dostawa i montaż klimatyzacji Typ A 1 1 1 1 1 1 1 1 8

Dostawa i montaż klimatyzacji Typ B 1 1 1 1 4

Dostawa i montaż klimatyzacji Typ C 2 2

Dostawa, montaż i konfiguracja systemu monitorowania środowiska 1 1 1 1 1 1 1 1 1 1 1 1 1 1 14

Dostawa i montaż drzwi antywłamaniowych 1 1 1 2 1 1 1 1 1 10

Dostawa, montaż i konfiguracja systemu kontroli dostępu 1 1 2

Dostawa i montaż zasilacza UPS 8kVA 1 1 1 1 1 5

Dostawa i montaż zasilacza UPS 5kVA 1 1 1 2 5

Dostawa i montaż zasilacza UPS 3kVA 1 1 1 3

Dostawa, montaż i konfiguracja systemu alarmowego i sygnalizacji pożarowej 1 1

Dostawa i montaż szafy RACK 42U 1 1 1 1 1 1 1 1 1 9

Dostawa i montaż szafy RACK 36U 1 1 1 1 4

Dostawa, montaż i konfiguracja serwera 3 1 4

Dostawa, montaż i konfiguracja serwera (HIS) 1 1 1 1 1 5

Dostawa, montaż i konfiguracja serwera (ERP) - Typ A 1 1 1 1 1 1 6

Dostawa, montaż i konfiguracja serwera (ERP)- Typ B 1 1

Dostawa, montaż i konfiguracja macierzy dyskowej 1 1


Strona 149 z 208

Dostawa, montaż i konfiguracja biblioteki taśmowej 1 1

VI.3.2.2. Dostawa i montaż klimatyzacji Typ A


VI.3.2.2.1.1. Klimatyzacja typu split składająca się co najmniej z dwóch jednostek zewnętrznych

oraz dwóch inwerterów,

VI.3.2.2.1.2. Moc chłodnicza pojedynczego układu jednostka zewnętrzna + inwerter – min. 8

kW (łącznie min. 16 kW),




VI.3.2.2.1.4. Utrzymanie w serwerowni stałej temperatury wybieranej z zakresu od 18°C do

25°C przy temperaturze zewnętrznej w zakresie od -20°C do +40°C,

VI.3.2.2.1.5. Praca redundantna z automatycznym przełączaniem w przypadku awarii w

systemie active/active lub fail-over,

VI.3.2.2.1.6. Sygnalizacja awarii alarmem wizualnym i dźwiękowym,

VI.3.2.2.2. Ilość – zgodnie z tabelą w punkcie VI.3.2.1.









uzgodnić z Zamawiającym i Uczestnikiem Projektu sposób i termin takiego

montażu systemu klimatyzacji, aby nie zakłócić organizacji pracy.












Strona 150 z 208

VI.3.2.2.6.3. Formalnemu odbiorowi podlega dostawa i montaż.













wyprodukowane wcześniej niż 6 miesięcy przed datą dostawy).

VI.3.2.3. Dostawa i montaż klimatyzacji Typ B


VI.3.2.3.1.1. Klimatyzacja typu split składająca się co najmniej jednej jednostki zewnętrznej

oraz jednego inwertera,

VI.3.2.3.1.2. Moc chłodnicza zestawu – min. 8 kW,






VI.3.2.3.1.5. Możliwość pracy redundantnej z automatycznym przełączaniem w przypadku

awarii w systemie active/active lub fail-over po zamontowaniu drugiego zestawu,

VI.3.2.3.1.6. Sygnalizacja awarii alarmem wizualnym i dźwiękowym.










Strona 151 z 208



montażu systemu klimatyzacji, aby nie zakłócić organizacji pracy

























VI.3.2.4. Dostawa i montaż klimatyzacji Typ C


VI.3.2.4.1.1. Klimatyzator przeznaczony do montażu w oknie (ze względu na ochronę

konserwatorską),

VI.3.2.4.1.2. Moc chłodnicza zestawu – min. 3 kW,







Strona 152 z 208


zakresie min. od 0°C do +55°C z rozdzielczością min. 1°C

VI.3.2.4.1.6. Sygnalizacja awarii alarmem wizualnym i dźwiękowym.











montażu systemu klimatyzacji, aby nie zakłócić organizacji pracy

VI.3.2.4.4.2. Dostarczane urządzenia muszą być fabrycznie nowe. Wykonawca zobowiązany

jest dołączyć do oferty oświadczenie Wykonawcy, że oferowane do przetargu




















urządzenie/sprzęt/wyposażenie zostanie dostarczone jako fabrycznie nowe.

VI.3.2.5. Dostawa i montaż systemu monitorowania środowiska


Strona 153 z 208


VI.3.2.5.1.1. Min. 1 interfejs zgodny ze standardem Ethernet,

VI.3.2.5.1.2. Zgodność z protokołem TCP/IP,

VI.3.2.5.1.3. System musi umożliwiać podłączenie min. 4 czujników analogowych oraz min. 8

czujników cyfrowych,


zakresie min. od -0°C do +55°C z rozdzielczością min. 2°C,

VI.3.2.5.1.5. Dostarczany system musi po uruchomieniu mierzyć wilgotność względną w

serwerowni w zakresie min. od 20% do 95% z rozdzielczością min. 5%,

VI.3.2.5.1.6. Dostarczany system musi po uruchomieniu wykrywać pojawienie się wody w

określonym miejscu,

VI.3.2.5.1.7. System musi posiadać możliwość zapisywania wszystkich rejestrowanych

parametrów na zdalnym serwerze,

VI.3.2.5.1.8. System musi posiadać wbudowany moduł GSM umożliwiający przesyłanie

komunikatów o parametrach środowiskowych przy pomocy sieci telefonii

komórkowej,

VI.3.2.5.1.9. Wraz z systemem musi zostać dostarczona licencja na min. 1 stanowisko

pracujące w środowisku MS Windows dla oprogramowania umożliwiającego

odczyt parametrów środowiskowych, wizualizację tych parametrów w postaci

wykresów oraz generowanie alertów przy przekroczeniu poziomów określonych

w konfiguracji.



VI.3.2.5.3.1. Montaż systemu i czujników w serwerowni, umiejscowienie czujników (w

szczególności czujnika wykrywającego obecność wody) musi być uzgodnione z

Zamawiającym,

VI.3.2.5.3.2. Konfiguracja systemu do pracy,

VI.3.2.5.3.3. Konfiguracja zapisu rejestru na zdalnym serwerze wskazanym przez

Zamawiającego,

VI.3.2.5.3.4. Instalacja oprogramowania monitorującego na stacji roboczej wskazanej przez

Zamawiającego,

VI.3.2.5.3.5. Konfiguracja połączenia pomiędzy systemem monitoringu a oprogramowaniem

monitorującym.




montażu systemu, aby nie zakłócić organizacji pracy Zamawiającego.






Strona 154 z 208


VI.3.2.5.5.1. System monitoringu wraz z montażem muszą zostać objęta min. 3-letnią

gwarancją.















VI.3.2.6. Dostawa i montaż drzwi antywłamaniowych


VI.3.2.6.1.1. Drzwi antywłamaniowe, jednoskrzydłowe pełne,

VI.3.2.6.1.2. Odporność na włamanie min. klasy 5 zgodnie z normą PN-EN 1627:2012,

VI.3.2.6.1.3. Wymiary: szerokość min. 90 cm, wysokość min. 200 cm,

VI.3.2.6.1.4. System zamykania wyposażony w zamek elektromagnetyczny przeznaczony do

podłączenia systemu kontroli dostępu objętego niniejszym zamówieniem,

VI.3.2.6.1.5. W lokalizacjach, w których nie będzie dostarczany System Kontroli Dostępu, drzwi

będą wyposażone wyłącznie w zamek fizyczny sklasyfikowany w co najmniej 6

klasie wg normy PN-EN 12209.

VI.3.2.6.1.6. Konstrukcja stalowa lub oparta na stalowej ramie,

VI.3.2.6.1.7. Samozamykacz,

VI.3.2.6.1.8. Wytrzymałość ogniowa min. EI 30,



VI.3.2.6.3.1. Osadzenie ościeżnicy i montaż skrzydła drzwiowego tak, aby drzwi były otwierane

na zewnątrz,

VI.3.2.6.3.2. Montaż i regulacja samozamykacza,

VI.3.2.6.3.3. Montaż systemu zamykania i podłączenie go do systemu kontroli dostępu

objętego niniejszym zamówieniem,


Strona 155 z 208

VI.3.2.6.3.4. Doprowadzenie ściany wokół ościeżnicy do stanu pierwotnego,

VI.3.2.6.3.5. W przypadku dostawy drzwi z zamkiem mechanicznym dostawa min. 3

kompletów kluczy.




montażu drzwi, aby nie zakłócić organizacji pracy Zamawiającego






VI.3.2.6.5.1. Drzwi wraz z montażem muszą zostać objęta min. 3-letnią gwarancją.







VI.3.2.6.7.1. Do oferty należy dołączyć dokument potwierdzający, że oferowane drzwi są

zgodne z normą PN-EN 1627:2012 w klasie co najmniej 5.









VI.3.2.7. Dostawa, montaż i konfiguracja systemu kontroli dostępu


VI.3.2.7.1.1. System musi obejmować min. 2 rodzaje zabezpieczeń z możliwością stosowania

jednoczesnego w tym co najmniej czytnik kart kodowych oraz klawiaturę cyfrową,

VI.3.2.7.1.2. System musi zapisywać wszystkie zdarzenia związane z jego działaniem na

zdalnym serwerze wskazanym przez Zamawiającego.




Strona 156 z 208

VI.3.2.7.3.1. Montaż kontrolerów systemu na ścianach serwerowni oraz przywrócenie ścian do

stanu pierwotnego,

VI.3.2.7.3.2. Podłączenie sterowania do zamka w drzwiach objętych niniejszym zamówieniem,

VI.3.2.7.3.3. Zaprogramowanie sterownika zgodnie ze wskazaniami Zamawiającego,

VI.3.2.7.3.4. Konfiguracja transmisji oraz rejestracji dziennika zdarzeń na serwerze wskazanym


VI.3.2.7.3.5. Dostarczenie min. 5 kart kodowych,

VI.3.2.7.3.6. Zaprogramowanie min. 5 kombinacji kart kodowych oraz ciągów szyfrów zgodnie

ze wskazaniami Zamawiającego.






wcześniej niż 6 miesięcy przed datą dostawy. Wykonawca zobowiązany jest


















wyprodukowane wcześniej niż 6 miesięcy przed datą dostawy). Zapis usunięty

przez Zamawiającego.

VI.3.2.8. Dostawa i montaż zasilacza UPS 8kVA



Strona 157 z 208

VI.3.2.8.1.1. Obudowa typu tower lub do montażu w szafie rack (w przypadku montażu w

szafie rack wysokość zasilacza nie może przekroczyć 6U),



VI.3.2.8.1.3. Moc min. 8kVA,

VI.3.2.8.1.4. Wymagany minimalny czas pracy na baterii nie może być krótszy niż 4 minut przy

100% obciążeniu oraz 12 minut przy obciążeniu równym 50%,

VI.3.2.8.1.5. Musi istnieć możliwość wydłużenia czasu pracy na baterii poprzez zastosowanie

dodatkowych modułów bateryjnych,

VI.3.2.8.1.6. Zasilacz powinien być wyposażony w minimum 8 gniazd z utrzymaniem zasilania

w standardzie IEC320 C13 (10A) oraz minimum 4 gniazda z utrzymaniem zasilania

w standardzie IEC320 C19 (16A) lub w przypadku podłączenia poprzez stałe styki

należy dostarczyć listwy dystrybucyjne zawierające minimum 8 gniazd z

utrzymaniem zasilania w standardzie IEC320 C13 (10A) oraz minimum 4 gniazda z

utrzymaniem zasilania w standardzie IEC320 C19 (16A),

VI.3.2.8.1.7. Zasilacz musi umożliwiać podłączenie go do sieci ETHERNET oraz umożliwiać

monitorowanie za pomocą protokołów SNMP oraz Telnet.



VI.3.2.8.3.1. Montaż zasilacza zgodnie z przyjętym typem montażu w miejscu wskazanym przez

Zamawiającego,

VI.3.2.8.3.2. Podłączenie zasilacza do instalacji elektrycznej,







montażu zasilacza, aby nie zakłócić organizacji pracy Zamawiającego.





wymóg.


VI.3.2.8.5.1. Zasilacz musi zostać objęty min. 3-letnią gwarancją.



VI.3.2.8.6.2. Formalnemu odbiorowi podlega dostawa montaż.


Strona 158 z 208





zasilacza z normami zasadniczymi (deklaracja CE).












VI.3.2.9.1.1. Obudowa typu tower lub do montażu w szafie rack (w przypadku montażu w

szafie rack wysokość zasilacza nie może przekroczyć 4U),



VI.3.2.9.1.3. Moc min. 5kVA,





VI.3.2.9.1.6. Zasilacz powinien być wyposażony w minimum 6 gniazd z utrzymaniem zasilania


w standardzie IEC320 C19 (16A) lub w przypadku podłączenia poprzez stałe styki

należy dostarczyć listwy dystrybucyjne zawierające minimum 6 gniazd z

utrzymaniem zasilania w standardzie IEC320 C13 (10A) oraz minimum 2 gniazda z

utrzymaniem zasilania w standardzie IEC320 C19 (16A),





VI.3.2.9.3.1. Montaż zasilacza zgodnie z przyjętym typem montażu w miejscu wskazanym przez

Zamawiającego,




Strona 159 z 208











wymóg.






















VI.3.2.10.1.1. Obudowa do montażu w szafie rack (wysokość zasilacza nie może przekroczyć 2U),

VI.3.2.10.1.2. W komplecie należy dołączyć zestaw akcesoriów montażowych oraz komplet kabli

zasilających,

VI.3.2.10.1.3. Moc min. 3kVA,


Strona 160 z 208





VI.3.2.10.1.6. Zasilacz powinien być wyposażony w minimum 4 gniazda z utrzymaniem zasilania


w standardzie IEC320 C19 (16A),





VI.3.2.10.3.1. Montaż zasilacza w szafie rack w miejscu wskazanym przez Zamawiającego,













wymóg.















Strona 161 z 208







VI.3.2.11. Dostawa, montaż i konfiguracja systemu alarmowego i sygnalizacji pożarowej


VI.3.2.11.1.1. System powinien składać się co najmniej z następujących elementów:

Centrali alarmowej z niezależnym zasilaniem akumulatorowym

(obejmującym również czujniki),

Panelu sterującego z klawiaturą i wyświetlaczem,

Zestawu czujników,

Kompletu syren alarmowych z własnym zasilaniem,

Modułu GSM.

VI.3.2.11.1.2. Centrala alarmowa powinna zostać umieszczona wewnątrz serwerowni

VI.3.2.11.1.3. Panel sterujący powinien być umieszczony na zewnątrz serwerowni w pobliżu

drzwi wejściowych na wysokości umożliwiającej swobodny dostęp,

VI.3.2.11.1.4. Zestaw czujników musi obejmować co najmniej:

Czujniki ruchu,

Czujniki otwarcia drzwi i okien,

Czujniki temperatury,

VI.3.2.11.1.5. Przy projektowaniu rozmieszczenia czujników należy uwzględnić :

Powierzchnię pomieszczenia – do 25m2,

Maksymalnie 4 okna (każde musi zostać objęte czujnikami),

1 drzwi przeciwpożarowe (muszą zostać objęte czujnikami),

VI.3.2.11.1.6. Syreny alarmowe muszą zostać umieszczone co najmniej jedna wewnątrz

serwerowni oraz jedna na zewnątrz serwerowni,

VI.3.2.11.1.7. Syreny alarmowe muszą samodzielnie uruchomić sygnalizację alarmu w

następujących przypadkach: przy zaniku sygnału z centrali alarmowej, przy

oderwaniu od podłoża, przy próbie otwarcia obudowy,

VI.3.2.11.1.8. Elementy alarmu muszą być zabezpieczone przed ich zneutralizowaniem bez

użycia dedykowanych narzędzi,

VI.3.2.11.1.9. Dostęp do centrali alarmowej musi być zabezpieczonym mechanizmem

wymagającym posiadania elementu zabezpieczającego np. karty kodowej, klucza

itp.,


Strona 162 z 208

VI.3.2.11.1.10. Wszystkie tory transmisyjne czujników muszą być monitorowane przez centralę i

wykryte uszkodzenia muszą być sygnalizowane w czasie nie przekraczającym 30s.



VI.3.2.11.3.1. Montaż systemu w serwerowni,

VI.3.2.11.3.2. Konfiguracja systemu do pracy zgodnie ze wskazaniem Zamawiającego,










wymóg.





VI.3.2.11.6.2. Formalnemu odbiorowi podlega dostawa, montaż i konfiguracja.





systemu z normami zasadniczymi (deklaracja CE).









z oficjalnego kanału dystrybucyjnego producenta. Zapis usunięty przez

Zamawiającego.

VI.3.2.12. Dostawa i montaż szafy RACK 42U


Strona 163 z 208


VI.3.2.12.1.1. Szafa RACK o wysokości 42U zgodna ze specyfikacją co najmniej EIA-310-D,

VI.3.2.12.1.2. Nośność min. 600kg,

VI.3.2.12.1.3. Głębokość dostosowana do rozmiaru oferowanego i dostarczanego sprzętu,

VI.3.2.12.1.4. Szafa musi być wyposażona w cokół o wysokości min. 120mm z możliwością

wprowadzenia okablowania z każdej strony,

VI.3.2.12.1.5. Przednie i tylnie drzwi szafy muszą umożliwić wymianę powietrza,

VI.3.2.12.1.6. Przednie i tylne drzwi wyposażone w zamek mechaniczny (wymagane jest

dostarczenie min. 2 kompletów kluczy w zestawie),

VI.3.2.12.1.7. Przednie drzwi metalowe zaopatrzone w system otworów wentylacyjnych,

VI.3.2.12.1.8. Boki szafy pełne z możliwością demontażu,

VI.3.2.12.1.9. Możliwość adaptacji drzwi przednich na prawą lub lewą stronę,

VI.3.2.12.1.10. Szafa musi być dostarczona w komplecie co najmniej z następującymi

akcesoriami:

Uchwyty kablowe do montażu na profilach pionowych (min. 10 szt.),

Organizery kabli 1U (min. 5 szt.),

Panel wentylacyjny (4 wentylatory) z termostatem (min. 1 szt.),

Panel krosowniczy 24 porty kat. 6e (min. 1 szt.) – wszystkie porty muszą

być obsadzone wkładkami,

Komplet śrub i uchwytów dla profili przednich i tylnych do montażu

urządzeń w szafie przy założeniu, że szafa jest w pełni obsadzona

urządzeniami o wysokości 1U każde,

Patchcordy kat. 6e dł. 0,5m (min. 10 szt.),


Patchcordy kat. 6e dł. 1,5m (min. 30 szt.)

VI.3.2.12.1.11. Szafa musi być wyposażona w system dystrybucji zasilania składający się co

najmniej z dwóch linii zasilających o maksymalnym prądzie dopuszczalnym 16A

zakończonych jednofazowymi wtykami z uziemieniem standardu C/E/F oraz

paneli dystrybucyjnych montowanych wewnątrz szafy zawierających min. 16

gniazd C13.



VI.3.2.12.3.1. Montaż szafy w serwerowni (ustawienie na cokole, poziomowanie, podłączenie

uziemienia),

VI.3.2.12.3.2. Montaż w szafie wszystkich dostarczonych akcesoriów,

VI.3.2.12.3.3. Podłączenie systemu zasilania i wentylacji,

VI.3.2.12.3.4. Podłączenie okablowania sieciowego do paneli krosowniczych,

VI.3.2.12.3.5. Montaż dostarczonych urządzeń zgodnie ze wskazaniami Zamawiającego,

VI.3.2.12.3.6. Zaplanowanie organizacji okablowania i ułożenie okablowania w organizerach.



Strona 164 z 208



montażu szafy, aby nie zakłócić organizacji pracy Zamawiającego.





wymóg.


VI.3.2.12.5.1. Szafa musi zostać objęta min. 3-letnią gwarancją.
















VI.3.2.13. Dostawa i montaż szafy RACK 36U


VI.3.2.13.1.1. Szafa RACK o wysokości 36U zgodna ze specyfikacją co najmniej EIA-310-D,

VI.3.2.13.1.2. Nośność min. 400kg,

VI.3.2.13.1.3. Głębokość dostosowana do rozmiaru oferowanego i dostarczanego sprzętu,

VI.3.2.13.1.4. Szafa musi być wyposażona w cokół o wysokości min. 120mm z możliwością

wprowadzenia okablowania z każdej strony,

VI.3.2.13.1.5. Przednie i tylnie drzwi szafy muszą umożliwić wymianę powietrza,

VI.3.2.13.1.6. Przednie i tylne drzwi wyposażone w zamek mechaniczny (wymagane jest

dostarczenie min. 2 kompletów kluczy w zestawie),

VI.3.2.13.1.7. Przednie drzwi metalowe zaopatrzone w system otworów wentylacyjnych,

VI.3.2.13.1.8. Boki szafy pełne z możliwością demontażu,

VI.3.2.13.1.9. Możliwość adaptacji drzwi przednich na prawą lub lewą stronę,


Strona 165 z 208

VI.3.2.13.1.10. Szafa musi być dostarczona w komplecie co najmniej z następującymi

akcesoriami:

Uchwyty kablowe do montażu na profilach pionowych (min. 8 szt.),

Organizery kabli 1U (min. 4 szt.),

Panel wentylacyjny (4 wentylatory) z termostatem (min. 1 szt.),

Panel krosowniczy 24 porty kat. 6e (min. 1 szt.) – wszystkie porty muszą

być obsadzone wkładkami,

Komplet śrub i uchwytów dla profili przednich i tylnych do montażu

urządzeń w szafie przy założeniu, że szafa jest w pełni obsadzona

urządzeniami o wysokości 1U każde,



Patchcordy kat. 6e dł. 1,5m (min. 20 szt.)

VI.3.2.13.1.11. Szafa musi być wyposażona w system dystrybucji zasilania składający się co

najmniej z dwóch linii zasilających o maksymalnym prądzie dopuszczalnym 16A

zakończonych jednofazowymi wtykami z uziemieniem standardu C/E/F oraz

paneli dystrybucyjnych montowanych wewnątrz szafy zawierających min. 8

gniazd C13.



VI.3.2.13.3.1. Montaż szafy w serwerowni (ustawienie na cokole, poziomowanie, podłączenie

uziemienia),

VI.3.2.13.3.2. Montaż w szafie wszystkich dostarczonych akcesoriów,

VI.3.2.13.3.3. Podłączenie systemu zasilania i wentylacji,

VI.3.2.13.3.4. Podłączenie okablowania sieciowego do paneli krosowniczych,

VI.3.2.13.3.5. Montaż dostarczonych urządzeń zgodnie ze wskazaniami Zamawiającego,

VI.3.2.13.3.6. Zaplanowanie organizacji okablowania i ułożenie okablowania w organizerach.




montażu szafy, aby nie zakłócić organizacji pracy Zamawiającego.





wymóg.


VI.3.2.13.5.1. Szafa musi zostać objęta min. 3-letnią gwarancją.



Strona 166 z 208















VI.3.2.14. Dostawa, montaż i konfiguracja serwera



VI.3.2.14.1.1.1. do instalacji w serwerowej szafie RACK 19”;

VI.3.2.14.1.1.2. wysokość nie więcej niż 2U po zamontowaniu w szafie RACK;

VI.3.2.14.1.1.3. możliwość instalacji minimum 6 dysków twardych 3,5” SATA, SAS, NL-SAS

hot-plug i hot-swap w dostarczonej konfiguracji bez konieczności

rozbudowy lub wymiany jakichkolwiek komponentów;

VI.3.2.14.1.1.4. obudowa zaprojektowana na potrzeby oferowanego modelu serwera.

VI.3.2.14.1.2. Płyta główna

VI.3.2.14.1.2.1. dedykowana płyta serwerowa;

VI.3.2.14.1.2.2. min. dwa gniazda procesora, wsparcie dla procesorów wielordzeniowych;

VI.3.2.14.1.2.3. minimum 12 banków pamięci obsługujące minimum 384 GB pamięci typu

registered

VI.3.2.14.1.2.4. minimum 2 złącza PCI Express Generacji 3 o prędkości minimum x4;

VI.3.2.14.1.2.5. zainstalowany układ szyfrowania zgodny z TPM 1.2 (konfigurowalny z

pozycji BIOS).

VI.3.2.14.1.3. BIOS

VI.3.2.14.1.3.1. możliwość zabezpieczenia hasłem dostępu do Systemu operacyjnego i

dostępu do BIOS serwera- zabezpieczenia te muszą działać niezależnie od

siebie;

VI.3.2.14.1.3.2. możliwość odczytania z BIOS serwera informacji o numerze seryjnym,

numerze inwentaryzacyjnym (asset tag), możliwość odczytania z BIOS

dokładnych informacji o procesorach (model, typ, częstotliwości FSB,

prędkości rzeczywista, ilość pamięci cache);

VI.3.2.14.1.3.3. możliwość wyłączenia pracy wielordzeniowej procesora z pozycji BIOS.


Strona 167 z 208


VI.3.2.14.1.4.1. zainstalowane min. dwa 64-bitowe wielordzeniowe procesory serwerowe

w architekturze x86,

VI.3.2.14.1.4.2. Procesor osiągający w zaoferowanym modelu serwera wynik minimum 480

punktów w teście SPECint_rate2006 w kolumnie Results Base



wykorzystany przez Zamawiającego do określenia wymogów minimalnych

dla procesora. W przypadku zmiany adresu publikacji testów Zamawiający

akceptuje wynik testu SPECint_rate2006 oferowanego procesora

znajdującego się pod innym adresem w ramach strony www.spec.org);


wynik w ramach testu SPECint_rate2006 na stronie www.spec.org


VI.3.2.14.1.5.1. Min. 32 GB RAM, min. 8 slotów wolnych

VI.3.2.14.1.5.2. wsparcie dla technologii korekcji błędów ECC;

VI.3.2.14.1.5.3. wsparcie sprzętowe kontrolera pamięci dla zapisu lustrzanego pamięci.

VI.3.2.14.1.6. Kontroler macierzowy

VI.3.2.14.1.6.1. kontroler dysków zapewniający obsługę wszystkich dostarczonych dysków,

minimum 8 portów z obsługą RAID 0,1,10,5,50,6,60 z pamięcią cache

minimum 512MB oraz podtrzymaniem bateryjnym pamięci cache.

VI.3.2.14.1.7. Dyski twarde

VI.3.2.14.1.7.1. Min. 2 dyski SAS o pojemności min. 300 GB każdy, czas wyszukiwania

poniżej 5ms, hot-plug, hot-swap

VI.3.2.14.1.7.2. Min. 2 dyski SATA o pojemności min. 1TB, czas wyszukiwania poniżej 10ms,

hot-plug, hot-swap

VI.3.2.14.1.8. Napędy zintegrowane

VI.3.2.14.1.8.1. zintegrowana nagrywarka DVD +/- RW (obsługa DVD+R, DVD-R, DVD DL)

wraz z oprogramowaniem do nagrywania płyt DVD dla zaoferowanego

Systemu operacyjnego;

VI.3.2.14.1.8.2. zintegrowany napęd LTO5, SAS 160GB pojemności natywnej, transfer min.

120MB/s wraz z odpowiednim kontrolerem wraz z oprogramowaniem do

wykonywania kopii bezpieczeństwa;

VI.3.2.14.1.8.3. min. 1 kartridż czyszczący do napędu LTO, min. 7 kartridży typu LTO5

(możliwość zapisania min. 160GB skompresowanych danych).

VI.3.2.14.1.9. Interfejsy sieciowe

VI.3.2.14.1.9.1. Min. 4 porty Ethernet 1Gbit/s dla komunikacji Systemowej (RJ-45);

VI.3.2.14.1.9.2. zintegrowana trwale karta sieciowa 10/100Mbit, RJ-45 dedykowana dla

kontrolera zdalnego zarządzania, z możliwością przekierowania

komunikacji kontrolera zarządzania na kartę 1Gbit.

VI.3.2.14.1.10. Interfejsy zintegrowane

VI.3.2.14.1.10.1. 1 x RS-232-C (9 pin);

VI.3.2.14.1.10.2. min. 5 portów USB 2.0 (w tym min. 2 na panelu przednim);

VI.3.2.14.1.10.3. możliwość zainstalowania wewnętrznego klucza USB (pamięci flash).

VI.3.2.14.1.11. Zarządzanie zdalne





Strona 168 z 208

VI.3.2.14.1.11.1. zintegrowany trwale z płytą główną kontroler zdalnego zarządzania zgodny

ze standardem IPMI 2.0 umożliwiający zdalne uruchomienie, wyłączenie i

restart serwera;

VI.3.2.14.1.11.2. pełne zarządzanie sprzętowe: monitorowanie pracy kluczowych układów,

wentylatorów, zasilaczy, napędów, temperatur, itp., logowanie błędów w

zakresie ustalonym przez administratora;

VI.3.2.14.1.11.3. dostęp do interfejsu karty zarządzającej za pomocą przeglądarki MS

Internet Explorer lub Mozilla Firefox bez konieczności instalowania

jakiegokolwiek software specyficznego dla producenta sprzętu;

VI.3.2.14.1.11.4. funkcja przekierowania konsoli graficznej (minimum 2 niezależne

połączenia) i mapowania napędów zdalnych, bądź ich obrazów (CD, DVD,

FDD, klucz USB);

VI.3.2.14.1.11.5. połączenie z kartą zarządzającą musi być szyfrowane minimum 128-

bitowym kluczem SSL;

VI.3.2.14.1.11.6. monitorowanie zużycia energii serwera w trybie dziennym, miesięcznym,

rocznym oraz wizualizacja raportów w postaci wykresów graficznych,

kontrola zużycia energii w trybie rzeczywistym;

VI.3.2.14.1.11.7. funkcja konfiguracji i ograniczania zużycia energii elektrycznej przez serwer

bezpośrednio z pozycji konsoli graficznej karty sprzętowej (tryby

minimalnego zużycia energii, pełnej wydajności);

VI.3.2.14.1.11.8. funkcja umożliwiająca konfigurację i automatyczne przełączanie się

pomiędzy trybami zużycia energii w czasie, w ciągu tygodnia z dokładnością

do godzin (wymagane z uwagi na różne obciążenie maszyny w czasie);

VI.3.2.14.1.11.9. wsparcie dla integracji z Active Directory i LDAP;

VI.3.2.14.1.11.10. wsparcie dla aktualizacji firmware karty zarządzającej online, bez

konieczności restartu serwera;

VI.3.2.14.1.11.11. dostarczone wraz z serwerem Oprogramowanie zarządzające i

diagnostyczne wyprodukowane i wspierane przez producenta serwera

umożliwiające m.in.:

VI.3.2.14.1.11.12. konfigurację kontrolera RAID bez konieczności konfiguracji

bezpośrednio w BIOS kontrolera;

VI.3.2.14.1.11.13. instalację Systemów operacyjnych wspieranych przez producenta

serwera (z nośników fizycznych lub zdalnie przez sieć LAN) wraz ze

sterownikami;

VI.3.2.14.1.11.14. wykrywanie usterek z wyprzedzeniem

VI.3.2.14.1.11.15. monitorowanie i zarządzanie kontrolerami RAID i zainstalowanymi

dyskami twardymi

VI.3.2.14.1.12. Karta graficzna

VI.3.2.14.1.12.1. zintegrowana karta graficzna;

VI.3.2.14.1.12.2. złącze VGA dostępne z tyłu obudowy;

VI.3.2.14.1.12.3. obsługa rozdzielczości minimum 1280x1024.

VI.3.2.14.1.13. Bezpieczeństwo

VI.3.2.14.1.13.1. zintegrowany w obudowie slot do zabezpieczenia linką lub kłódką Zapis

usunięty przez Zamawiającego;

VI.3.2.14.1.14. Zasilanie i chłodzenie


Strona 169 z 208

VI.3.2.14.1.14.1. dwa, redundantne zasilacze o mocy dobranej do maksymalnego obciążenia

przy pełnej konfiguracji serwera, typu hot-plug o sprawności minimalnej

90% przy typowym obciążeniu 50%;

VI.3.2.14.1.14.2. redundantne wentylatory chłodzące wnętrze obudowy. Wymienne w

trybie hot-plug;

VI.3.2.14.1.14.3. dostarczone dwa przewody zasilające z wtyczką używaną w Polsce, długości

min. 1,8m.

VI.3.2.14.1.15. Inne

VI.3.2.14.1.15.1. dostarczona w zestawie mysz optyczna z rolką i klawiatura Qwerty w

układzie US

VI.3.2.14.1.16. Do serwera musi być dołączona licencja systemu operacyjnego o następujących

parametrach minimalnych :

System operacyjny musi umożliwiać podłączenie serwerów do istniejącego

kontrolera domeny Active Directory u Uczestnika Projektu,

Liczba rdzeni procesorów i ilość pamięci nie mogą mieć wpływu na liczbę

wymaganych licencji. Licencja musi uprawniać do uruchamiania serwerowego

systemu operacyjnego (SSO) w środowisku fizycznym i dwóch wirtualnych

środowisk serwerowego systemu operacyjnego za pomocą wbudowanych

mechanizmów wirtualizacji. SSO musi posiadać następujące, wbudowane

cechy:

o Możliwość wykorzystania co najmniej 320 logicznych procesorów

oraz co najmniej 4 TB pamięci RAM w środowisku fizycznym,

o Możliwość wykorzystywania 64 procesorów wirtualnych oraz 1TB

pamięci RAM i dysku o pojemności min. 64TB przez każdy wirtualny

serwerowy system operacyjny,

o Możliwość budowania klastrów składających się z 64 węzłów, z

możliwością uruchamiania do 8000 maszyn wirtualnych,

o Możliwość migracji maszyn wirtualnych bez zatrzymywania ich pracy

między fizycznymi serwerami z uruchomionym mechanizmem

wirtualizacji (hypervisor) przez sieć Ethernet, bez konieczności

stosowania dodatkowych mechanizmów współdzielenia pamięci,

o Wsparcie (na umożliwiającym to sprzęcie) dodawania i wymiany

pamięci RAM bez przerywania pracy,

o Wsparcie dodawania i wymiany procesorów bez przerywania pracy,

o Automatyczna weryfikacja cyfrowych sygnatur sterowników w celu

sprawdzenia, czy sterownik przeszedł testy jakości przeprowadzone

przez producenta systemu operacyjnego,

o Możliwość dynamicznego obniżania poboru energii przez rdzenie

procesorów niewykorzystywane w bieżącej pracy. Mechanizm ten

musi uwzględniać specyfikę procesorów wyposażonych w

mechanizmy Hyper-Threading,

o Wbudowane wsparcie instalacji i pracy na wolumenach, które:

pozwalają na zmianę rozmiaru w czasie pracy systemu,


Strona 170 z 208

umożliwiają tworzenie w czasie pracy systemu migawek,

dających użytkownikom końcowym (lokalnym i sieciowym)

prosty wgląd w poprzednie wersje plików i folderów,

umożliwiają kompresję w trakcie pracy dla wybranych plików

i/lub folderów,

umożliwiają zdefiniowanie list kontroli dostępu (ACL),

Wbudowany mechanizm klasyfikowania i indeksowania plików

(dokumentów) w oparciu o ich zawartość,

Wbudowane szyfrowanie dysków przy pomocy mechanizmów posiadających

certyfikat FIPS 140-2 lub równoważny wydany przez NIST lub inną agendę

rządową zajmującą się bezpieczeństwem informacji,

Możliwość uruchamianie aplikacji internetowych wykorzystujących

technologię ASP.NET,

Możliwość dystrybucji ruchu sieciowego HTTP pomiędzy kilka serwerów,

Wbudowana zapora internetowa (firewall) z obsługą definiowanych reguł dla

ochrony połączeń internetowych i intranetowych,

Graficzny interfejs użytkownika,

Zlokalizowane w języku polskim, co najmniej następujące elementy: menu,

przeglądarka internetowa, pomoc, komunikaty systemowe,

Możliwość zdalnej konfiguracji, administrowania oraz aktualizowania

systemu,

Możliwość implementacji następujących funkcjonalności bez potrzeby

instalowania dodatkowych produktów (oprogramowania) innych

producentów wymagających dodatkowych licencji:

o Podstawowe usługi sieciowe: DHCP oraz DNS wspierający DNSSEC,

o Usługi katalogowe oparte o LDAP i pozwalające na uwierzytelnianie

użytkowników stacji roboczych, bez konieczności instalowania

dodatkowego oprogramowania na tych stacjach, pozwalające na

zarządzanie zasobami w sieci (użytkownicy, komputery, drukarki,

udziały sieciowe), z możliwością wykorzystania następujących funkcji:

Podłączenie SSO do domeny w trybie offline - bez dostępnego

połączenia sieciowego z domeną,

Ustanawianie praw dostępu do zasobów domeny na bazie

sposobu logowania użytkownika - na przykład typu

certyfikatu użytego do logowania,

Odzyskiwanie przypadkowo skasowanych obiektów usługi

katalogowej z mechanizmu kosza,

o Zdalna dystrybucja oprogramowania na stacje robocze,

o Praca zdalna na serwerze z wykorzystaniem terminala (cienkiego

klienta) lub odpowiednio skonfigurowanej stacji roboczej,

o Centrum Certyfikatów (CA), obsługa klucza publicznego i prywatnego)

umożliwiające:

Dystrybucję certyfikatów poprzez http,

Konsolidację CA dla wielu lasów domeny,


Strona 171 z 208

Automatyczne rejestrowania certyfikatów pomiędzy różnymi

lasami domen,

o Szyfrowanie połączeń sieciowych pomiędzy serwerami oraz

serwerami i stacjami roboczymi (IPSec),

o Możliwość tworzenia systemów wysokiej dostępności (klastry typu

fail-over) oraz rozłożenia obciążenia serwerów,

o Serwis udostępniania stron WWW,

o Wsparcie dla protokołu IP w wersji 6 (IPv6),

o Wbudowane usługi VPN pozwalające na zestawienie nielimitowanej

liczby równoczesnych połączeń i niewymagające instalacji

dodatkowego oprogramowania na komputerach z systemem

Windows,

o Wbudowane mechanizmy wirtualizacji (Hypervisor) pozwalające na

uruchamianie min. 1000 aktywnych środowisk wirtualnych systemów

operacyjnych. Wirtualne maszyny w trakcie pracy i bez zauważalnego

zmniejszenia ich dostępności mogą być przenoszone pomiędzy

serwerami klastra typu failover z jednoczesnym zachowaniem

pozostałej funkcjonalności. Mechanizmy wirtualizacji mają zapewnić

wsparcie dla:

Dynamicznego podłączania zasobów dyskowych typu hot-

plug do maszyn wirtualnych,

Obsługi ramek typu jumbo frames dla maszyn wirtualnych,

Obsługi 4-KB sektorów dysków,

Nielimitowanej liczby jednocześnie przenoszonych maszyn

wirtualnych pomiędzy węzłami klastra,

Możliwości wirtualizacji sieci z zastosowaniem przełącznika,

którego funkcjonalność może być rozszerzana jednocześnie

poprzez oprogramowanie kilku innych dostawców poprzez

otwarty interfejs API,

Możliwości kierowania ruchu sieciowego z wielu sieci VLAN

bezpośrednio do pojedynczej karty sieciowej maszyny

wirtualnej (tzw. trunk model),

Możliwość automatycznej aktualizacji w oparciu o poprawki publikowane

przez producenta wraz z dostępnością bezpłatnego rozwiązania producenta

SSO umożliwiającego lokalną dystrybucję poprawek zatwierdzonych przez

administratora, bez połączenia z siecią Internet,

Wsparcie dostępu do zasobu dyskowego SSO poprzez wiele ścieżek

(Multipath),

Możliwość instalacji poprawek poprzez wgranie ich do obrazu instalacyjnego,

Mechanizmy zdalnej administracji oraz mechanizmy (również działające

zdalnie) administracji przez skrypty,

VI.3.2.14.1.17. Możliwość zarządzania przez wbudowane mechanizmy zgodne ze standardami

WBEM oraz WS-Management organizacji DMTF.



Strona 172 z 208


VI.3.2.14.3.1. Montaż serwera szafie rack w miejscu wskazanym przez Uczestnika Projektu,

VI.3.2.14.3.2. Podłączenie serwera do zasilania i sieci lokalnej,

VI.3.2.14.3.3. Instalacja i konfiguracja systemu operacyjnego

VI.3.2.14.3.4. Test prawidłowości działania,






montażu serwera, aby nie zakłócić organizacji pracy Zamawiającego.





wymóg.


VI.3.2.14.5.1. Serwer musi zostać objęty min. 3-letnią gwarancją z naprawą w miejscu instalacji

z czasem reakcji w następnym dniu roboczym od zgłoszenia.


VI.3.2.14.6.1. Po zakończeniu testu prawidłowości działania.

VI.3.2.14.6.2. Formalnemu odbiorowi podlega dostawa do Uczestnika Projektu.





serwera z normami zasadniczymi (deklaracja CE).












sprzętowej


Strona 173 z 208


produkowany zgodnie z normami ISO 9001 oraz ISO 14001

VI.3.2.15. Dostawa, montaż i konfiguracja serwera (HIS)





VI.3.2.15.1.1.3. możliwość instalacji minimum 6 dysków twardych 3,5” SATA, SAS lub NL-

SAS hot-plug i hot-swap w dostarczonej konfiguracji bez konieczności






VI.3.2.15.1.2.3. min. 12 banków pamięci obsługujące minimum 384GB pamięci typu

registered


VI.3.2.15.1.2.5. minimum 1 złącze PCI 32bit Zapis usunięty przez Zamawiającego;


pozycji BIOS).

VI.3.2.15.1.3. BIOS



siebie;




















Strona 174 z 208




VI.3.2.15.1.5.1. Min. 32 GB RAM



VI.3.2.15.1.6.1. kontroler dysków typu SAS 2.0, minimum 8 portów z obsługą RAID

0,1,10,5,50,6,60 z pamięcią cache minimum 512MB oraz podtrzymaniem

bateryjnym pamięci cache.



poniżej 5ms, hot-plug, hot-swap.

Min. 2 dyski SATA o pojemności min. 1TB, czas wyszukiwania poniżej

10ms, hot-plug, hot-swap
















VI.3.2.15.1.10.1. 1 x RS-232-C (9 pin);





restart serwera;









FDD, klucz USB);



Strona 175 z 208



















sterownikami;



dyskami twardymi










trybie hot-plug;


min. 1,8m.

VI.3.2.15.1.14. Inne


układzie US

VI.3.2.15.1.15. Do serwera muszą być dołączone licencje systemu operacyjnego, bazy danych

oraz niezbędnego oprogramowania narzędziowego pozwalająca na pełne

uruchomienie dostarczanego systemu HIS,



VI.3.2.15.3.1. Montaż serwera szafie rack w miejscu wskazanym przez Zamawiającego,



Strona 176 z 208

VI.3.2.15.3.3. Instalacja i konfiguracja oprogramowania systemowego, bazodanowego i

narzędziowego,

VI.3.2.15.3.4. Test prawidłowości działania.






montażu serwera, aby nie zakłócić organizacji pracy Uczestnika Projektu.





wymóg.











serwera z normami zasadniczymi (deklaracja CE)

VI.3.2.15.7.2. Do oferty należy dołączyć wydruk wyniku testu SPEC CINT2006 Base dla

oferowanej konfiguracji serwera.













Strona 177 z 208

VI.3.2.16. Dostawa, montaż i konfiguracja serwera (ERP) – Typ A





VI.3.2.16.1.1.3. możliwość instalacji minimum 6 dysków twardych 3,5” SATA, SAS, NL-SAS

hot-plug i hot-swap w dostarczonej konfiguracji bez konieczności






VI.3.2.16.1.2.3. min. 12 banków pamięci obsługujące minimum 384GB pamięci typu

registered



pozycji BIOS).

VI.3.2.16.1.3. BIOS



siebie;




















VI.3.2.16.1.5.1. Min. 32 GB RAM

VI.3.2.16.1.5.2. wsparcie dla technologii korekcji błędów ECC;







Strona 178 z 208
























VI.3.2.16.1.10.1. 1 x RS-232-C (9 pin);






restart serwera;









FDD, klucz USB);







Strona 179 z 208

















sterownikami;



dyskami twardymi













trybie hot-plug;


min. 1,8m.

VI.3.2.16.1.15. Inne


układzie US



uruchomienie dostarczanego systemu ERP,




Strona 180 z 208

VI.3.2.16.3.1. Montaż serwera szafie rack w miejscu wskazanym przez Zamawiającego i

Uczestnika Projektu,



narzędziowego,












wymóg.













oferowanej konfiguracji serwera,











Strona 181 z 208



VI.3.2.17. Dostawa, montaż i konfiguracja serwera (ERP) – Typ B





VI.3.2.17.1.1.3. możliwość instalacji minimum 6 dysków twardych hot-plug i hot-swap w

dostarczonej konfiguracji bez konieczności rozbudowy lub wymiany

jakichkolwiek komponentów;




VI.3.2.17.1.2.2. dwa gniazda procesora, wsparcie dla procesorów wielordzeniowych;

VI.3.2.17.1.2.3. minimum 12 banków pamięci obsługujące minimum 96GB pamięci typu

registered

VI.3.2.17.1.2.4. minimum 2 złącza PCI Express Generacji 3 w tym minimum jeden slot o

prędkości minimum x8 oraz drugi o prędkości x16;


pozycji BIOS).

VI.3.2.17.1.3. BIOS



siebie;




















Strona 182 z 208




VI.3.2.17.1.5.1. Min. 24 GB RAM


























VI.3.2.17.1.10.1. 1 x RS-232-C (9 pin);






restart serwera;




VI.3.2.17.1.11.3. dostęp do interfejsu karty zarządzającej za pomocą przeglądarki (co

najmniej MS Internet Explorer, Mozilla Firefox, Opera, Google Chrome w

wersjach aktualnych na dzień składania ofert bez konieczności instalowania

jakiegokolwiek oprogramowania specyficznego dla producenta sprzętu;



Strona 183 z 208



FDD, klucz USB);






















sterownikami;



dyskami twardymi













trybie hot-plug;


min. 1,8m.

VI.3.2.17.1.15. Inne


Strona 184 z 208


układzie US



uruchomienie dostarczanego systemu ERP,



VI.3.2.17.3.1. Montaż serwera szafie rack w miejscu wskazanym przez Zamawiającego i




narzędziowego,












wymóg.













oferowanej konfiguracji serwera,


Strona 185 z 208












VI.3.2.18. Dostawa, montaż i konfiguracja macierzy dyskowej


VI.3.2.18.1.1. Macierz przeznaczona do montażu w szafie rack 19” o wysokości nie

przekraczającej 6U,

VI.3.2.18.1.2. W komplecie z macierzą należy dostarczyć szyny i akcesoria mocujące do montażu

w szafie rack,

VI.3.2.18.1.3. Macierz musi być wyposażona w min. 1 kontroler z pamięcią buforową o

pojemności min. 16 GB z korekcją błędów ECC,

VI.3.2.18.1.4. Macierz musi posiadać min. 12 zatok dyskowych umożliwiających osiągnięcie

pojemności minimum 48TB oraz instalację w każdej z nich dysków SATA, SAS lub

SSD z możliwością wymiany dysków na gorąco (Hot swap) bez przerywania pracy

urządzenia,

VI.3.2.18.1.5. Urządzenie powinno mieć możliwość rozbudowy o kolejne 48 dysków twardych

za pomocą dedykowanych półek dyskowych łączonych z urządzeniem głównym za

pomocą dedykowanego portu,

VI.3.2.18.1.6. Dostarczana macierz musi być wyposażona w dyski o łącznej pojemności

min. 36 TB w trybie surowym (RAW) o czasie wyszukiwania nie większym niż

10ms,

VI.3.2.18.1.7. Urządzenie powinno zapewnić możliwość zmiany sposobu wykorzystywania przez

macierz konkretnego dysku np. dysk SSD pracujący tylko jako bufor odczytu lub

zapisu oraz przypisania dysku do różnych grup RAID

VI.3.2.18.1.8. Dla rozwiązania wykorzystującego półki dyskowe wszystkie dyski powinny być

widoczne z poziomu jednego systemu zarządzającego oraz półki dyskowe

powinny umożliwić stworzenie jednej grupy RAID,

VI.3.2.18.1.9. Macierz musi być wyposażona w min. dwa porty Ethernet 10/100/1000 Mb/s z

wyrównywaniem obciążenia i systemem failover,

VI.3.2.18.1.10. Macierz musi posiadać min. 2 porty umożliwiające instalację modułów SFP+,

VI.3.2.18.1.11. Porty sieciowe powinny zapewnić możliwość stworzenia wirtualnych adresów IP,

VI.3.2.18.1.12. Macierz musi posiadać min. 2 porty USB,


Strona 186 z 208

VI.3.2.18.1.13. Macierz musi posiadać min. 2 zasilacze redundantne o mocy adekwatnej do

pełnego wyposażenia macierzy,

VI.3.2.18.1.14. Urządzenie musi być wyposażone w preinstalowany system operacyjny

pozwalający na realizację integracji z Domeną oraz Active Directory.

Niedopuszczalne są płatne licencje wymagane dla użytkowania systemu

operacyjnego.

VI.3.2.18.1.15. Urządzenie powinno obsługiwać następujące standardy oraz funkcje RAID:

RAID 0, 1, 10, 5, 6,

Wymiana dysku nie może wiązać się z wyłączeniem urządzenia lub

restartem,

Stworzenie grupy RAID do stanu produkcyjnego nie może zająć więcej

niż 60s,

VI.3.2.18.1.16. Urządzenie powinno wspierać następujące protokoły sieciowe:

IPv6

SNMP

NFS v2/v3 dla Linux i UNIX

CIFS/SMB dla Windows

HTTP/S

FTP/S

Zarządzanie

VI.3.2.18.1.17. Urządzeniem powinno dać się zarządzać z poziomu przeglądarki internetowej,

VI.3.2.18.1.18. Urządzenie powinno mieć możliwość definiowania wirtualnych interfejsów

sieciowych z opcją wykorzystania komunikacji przez kilka interfejsów fizycznych w

celu zapewnienia redundancji połączeń,

VI.3.2.18.1.19. Urządzenie powinno być wyposażone w mechanizm umożliwiający wykonywanie

kopii w czasie rzeczywistym na inne takie same urządzenie. Replikacja pomiędzy

urządzeniami powinna odbywać się w sposób stały czyli nie na podstawie

harmonogramu. Dodatkowo wszystkie elementy konfiguracyjne związane z

tworzeniem kopii powinny być dostępne z poziomu chmury tzn. nie powinny

wymagać konfiguracji każdego urządzenia z osobna.

VI.3.2.18.1.20. Urządzenie powinno umożliwić stworzenie tzw. obrazu/migawki danych

przechowywanych da macierzy

VI.3.2.18.1.21. Urządzenie powinno posiadać możliwość pełnej integracji z posiadanym przez

Uczestnika oprogramowaniem VMware ESX 4.0 potwierdzone certyfikatem

VMWare,

VI.3.2.18.1.22. Urządzenie powinno umożliwiać współpracę z posiadanym przez Uczestnika

oprogramowaniem Citrix XenServer™ oraz Hyper-V firmy Microsoft,

VI.3.2.18.1.23. Urządzenie powinno umożliwiać współpracę z posiadanym przez Uczestnika

oprogramowaniem Symantec Backup Exec bez konieczności zakupu i instalowania

dodatkowego klienta tego oprogramowania.



VI.3.2.18.3.1. Montaż macierzy w szafie rack w miejscu wskazanym przez Uczestnika Projektu,



Strona 187 z 208

VI.3.2.18.3.3. Konfiguracja wolumenów dyskowych zgodnie ze wskazaniami Zamawiającego i








montażu macierzy, aby nie zakłócić organizacji pracy Uczestnika Projektu.





wymóg.


VI.3.2.18.5.1. Macierz wraz z dyskami musi zostać objęta min. 3-letnią gwarancją z naprawą w

miejscu instalacji z czasem reakcji do 3 dni roboczych.








macierzy z normami zasadniczymi (deklaracja CE).










VI.3.2.19. Dostawa, montaż i konfiguracja biblioteki taśmowej



Strona 188 z 208

VI.3.2.19.1.1. Typ napędu

VI.3.2.19.1.1.1. LTO-5

VI.3.2.19.1.2. Liczba napędów

VI.3.2.19.1.2.1. Min 2 szt.

VI.3.2.19.1.3. Liczba slotów

VI.3.2.19.1.3.1. Min. 24 szt.


VI.3.2.19.1.4.1. Rack 19” maks. 2U

VI.3.2.19.1.5. Interfejs

VI.3.2.19.1.5.1. FC 8 Gb/s

VI.3.2.19.1.6. Oferowane urządzenie musi spełniać minimalne parametry:

VI.3.2.19.1.6.1. pojemność bez kompresji: do 36 TB;

VI.3.2.19.1.6.2. pojemność z kompresją: do 72 TB;

VI.3.2.19.1.7. Oferowane urządzenie musi być wyposażone w:

VI.3.2.19.1.7.1. wbudowany skaner kodów paskowych na nośnikach LTO;

VI.3.2.19.1.7.2. złącze Ethernet 10/100Mb/s RJ-45 do zdalnego zarządzania.

VI.3.2.19.1.8. Oferowane urządzenie musi umożliwiać:

VI.3.2.19.1.8.1. zdalne zarządzanie oraz lokalne zarządzanie za pomocą

panelu/pulpitu operatora;

VI.3.2.19.1.8.2. zabezpieczenie dostępu panelu/pulpitu operatora hasłem lub kodem;

VI.3.2.19.1.8.3. zabezpieczenie hasłem lub kodem interfejsu zdalnego zarządzania;

VI.3.2.19.1.8.4. obsługę protokołu SNMP przez moduł zarządzania;

VI.3.2.19.1.8.5. obsługę szyfrowania danych na nośniku LTO-5;

VI.3.2.19.1.9. Wraz z urządzeniem należy dostarczyć:

VI.3.2.19.1.9.1. szyny do montażu w szafie rack 19”

VI.3.2.19.1.9.2. kabel UTP kat. 5 min. 3 m

VI.3.2.19.1.9.3. dwa zewnętrzne kable FC MMF 8Gb/s min. 3m

VI.3.2.19.1.9.4. 1 kabel zasilający

VI.3.2.19.1.9.5. Min. 25 kaset LTO 5 z kodem kreskowym na dane

VI.3.2.19.1.9.6. Min. 1 kaseta czyszcząca,



VI.3.2.19.3.1. Montaż biblioteki w szafie rack w miejscu wskazanym przez Uczestnika Projektu,

VI.3.2.19.3.2. Podłączenie biblioteki do zasilania i systemu pamięci masowej,

VI.3.2.19.3.3. Konfiguracja zgodnie ze wskazaniami Uczestnika Projektu,







montażu biblioteki, aby nie zakłócić organizacji pracy Uczestnika Projektu.


Strona 189 z 208





wymóg.


VI.3.2.19.5.1. Biblioteka musi zostać objęta min. 3-letnią gwarancją z naprawą w miejscu

instalacji z czasem reakcji do 3 dni roboczych.








biblioteki z normami zasadniczymi (deklaracja CE)

VI.3.2.19.7.2. do oferty należy załączyć dokumenty potwierdzające, że oferowany sprzęt jest











VI.3.3. Rozbudowa infrastruktury na potrzeby projektu



Strona 190 z 208

Pozycja

SPZO

Z „P

rzyc

ho

dn

ia D

wo

rco

wa”

w G

orz

ow

ie W

ielk

op

ols

kim

, 66

-40

0 G

orz

ów

Wlk

p.,

ul.

Dw

orc

ow

a 1

3

Wo

jew

ód

zki O

śro

dek

Med

ycyn

y P

racy

, 66

-40

0 G

orz

ów

Wlk

p.,

ul.

Fab

rycz

na

71

Sam

od

ziel

na

Pu

blic

zna

Wo

jew

ód

zka

Stac

ja P

ogo

tow

ia R

atu

nko

weg

o, 6

6-4

00

Go

rzó

w W

lkp

., u

l. K

azim

ierz

a

Wie

lkie

go 7

Wie

losp

ecja

listy

czn

y Sz

pit

al W

oje

wó

dzk

i w G

orz

ow

ie W

lkp

. Sp

. z

o.o

., 6

6-4

00

Go

rzó

w W

lkp

., u

l. W

alcz

aka

42

Sam

od

ziel

ny

Pu

blic

zny

Szp

ital

dla

Ner

wo

wo

i P

sych

iczn

ie C

ho

rych

, 66

-30

0 M

ięd

zyrz

ecz,

ul.

Po

znań

ska

10

9

Lub

usk

i Szp

ital

Sp

ecja

listy

czn

y P

ulm

on

olo

gicz

no

-Kar

dio

logi

czn

y w

To

rzym

iu S

pó

łka

z o

.o.,

66

-23

5 T

orz

ym, u

l.

Wo

jska

Po

lski

ego

52

Wo

jew

ód

zki S

zpit

al S

pec

jalis

tycz

ny

dla

Ner

wo

wo

i P

sych

iczn

ie C

ho

rych

Sam

od

ziel

ny

Pu

blic

zny

Zakł

ad O

pie

ki

Zdro

wo

tnej

, 66

-21

3 C

ibó

rz 5

Ośr

od

ek d

la O

sób

Uza

leżn

ion

ych

Sam

od

ziel

ny

Pu

blic

zny

Zakł

ad O

pie

ki Z

dro

wo

tnej

„N

ow

y D

wo

rek”

, 66

-20

0

No

wy

Dw

ore

k 4

6;

Lub

usk

i Ośr

od

ek R

ehab

ilita

cyjn

o -

Ort

op

edyc

zny

im. d

r Le

cha

Wie

rusz

a SP

ZOZ

66

-20

0 Ś

wie

bo

dzi

n, u

l. Za

mko

wa

1

Wo

jew

ód

zka

Stac

ja P

ogo

tow

ia R

atu

nko

weg

o S

amo

dzi

eln

y P

ub

liczn

y Za

kład

Op

ieki

Zd

row

otn

ej, 6

5-0

43

Ziel

on

a G

óra

, ul.

B. C

hro

bre

go 2

Wo

jew

ód

zki O

śro

dek

Med

ycyn

y P

racy

, 65

-09

6 Z

ielo

na

Gó

ra, u

l. D

ąbró

wki

15

C

SP Z

OZ

„M

EDK

OL”

, 65

-02

0 Z

ielo

na

Gó

ra, u

l. P

lac

Ko

leja

rza

1

Wo

jew

ód

zki O

śro

dek

Ter

apii

Uza

leżn

ień

i W

spó

łuza

leżn

ien

ia, 6

5-0

44

Zie

lon

a G

óra

, ul.

Waz

ów

36

Szp

ital

Wo

jew

ód

zki S

PZO

Z w

Zie

lon

ej G

órz

e, 6

5-0

46

Zie

lon

a G

óra

, ul.

Zyty

26

SP Z

OZ

Cen

tru

m L

ecze

nia

Dzi

eci i

Mło

dzi

eży

w Z

abo

rze

, 66

-00

3 Z

abó

r, u

l. Za

mko

wa

1

Razem

Dostawa i montaż punktu dostępowego WiFi 4 4

Dostawa, montaż i konfiguracja urządzenia klasy UTM 1 1 1 1 1 1 6

Dostawa i montaż przełącznika 2 2 1 3 8

Dostawa i montaż przełącznika z PoE 2 3 5

Dostawa stacji roboczej 5 7 10 24 19 10 19 10 15 10 7 10 5 24 14 189

Dostawa drukarki 2 5 10 10 5 5 5 3 3 15 10 73

Dostawa zasilacza UPS 650VA 18 18

VI.3.3.2. Dostawa i montaż punktu dostępowego WiFi


VI.3.3.2.1.1. Min 1 port 10/100/1000BASE-T IEEE 802.3af,

VI.3.3.2.1.2. Obsługa PoE,

VI.3.3.2.1.3. Min. 1 port konsoli RJ45 ,

VI.3.3.2.1.4. Min. 2 złącza RP SMA


Strona 191 z 208

VI.3.3.2.1.5. Min. 2 anteny w komplecie,

VI.3.3.2.1.6. Wymagane standardy sieci bezprzewodowej

VI.3.3.2.1.6.1. IEEE 802.11a 5GHz,

VI.3.3.2.1.6.2. IEEE 802.11g, IEEE 802.11b, 2.4GHz,

VI.3.3.2.1.6.3. IEEE 802.11n standard, 2.4GHz and 5GHz,

VI.3.3.2.1.6.4. WMM,

VI.3.3.2.1.6.5. WDS- Wireless Distribution System,

VI.3.3.2.1.6.6. IEEE 802.3af,

VI.3.3.2.1.7. Wymagane funkcje oraz protokoły

VI.3.3.2.1.7.1. Obsługa WPA, WPA2, WEP 64-bit, 128-bit, 152-bit,

VI.3.3.2.1.7.2. Autentykacja IEEE802.1x RADIUS EAP TLS, TTLS, PEAP,

VI.3.3.2.1.7.3. Autentykacja na podstawie MAC,

VI.3.3.2.1.7.4. Wsparcie VPN pass-through,

VI.3.3.2.1.7.5. Obsługa Secure SSH, Security Socket Layer (SSL),

VI.3.3.2.1.7.6. Zarządzanie poprzez przeglądarkę, SNMP lub Telnet wraz z CLI,

VI.3.3.2.1.7.7. SNMP MIB I, MIB II, 802.11 MIB,

VI.3.3.2.1.7.8. Wireless Distribution System (WDS),

VI.3.3.2.1.7.9. Tryb Point-to-point

VI.3.3.2.1.7.10. Tryb Point-to-multipoint,

VI.3.3.2.1.7.11. Tryb repeater,

VI.3.3.2.1.7.12. Możliwość rozgłaszania min. 8 sieci (SSID) na częstotliwość,

VI.3.3.2.1.7.13. Wykrywanie obcych AP,

VI.3.3.2.1.7.14. Izolacja klientów radiowych,

VI.3.3.2.1.8. Montaż do sufitu lub do ściany



VI.3.3.2.3.1. Montaż punktów dostępowych w miejscach wskazanych przez Uczestnika

Projektu (Uczestnik Projektu zapewnia niezbędne przyłącza),

VI.3.3.2.3.2. Podłączenie do funkcjonującej u Uczestnika Projektu sieci szkieletowej,

VI.3.3.2.3.3. Konfiguracja do pracy zgodnie ze wskazówkami Uczestnika Projektu,



VI.3.3.2.4.1. Należy uzgodnić z Zamawiającym i Uczestnikiem Projektu sposób i termin takiego

montażu urządzenia, aby nie zakłócić pracy sieci w sposób utrudniający

funkcjonowanie organizacji Uczestnika Projektu.





wymóg.



Strona 192 z 208

VI.3.3.2.5.1. Urządzenie musi zostać objęte min. 3-letnią gwarancją z czasem naprawy w ciągu

3 dni roboczych od przyjęcia zgłoszenia.








urządzenia z normami zasadniczymi (deklaracja CE).










VI.3.3.3. Dostawa, montaż i konfiguracja urządzeń klasy UTM


VI.3.3.3.1.1. Urządzenie pełniące rolę ściany ogniowej śledzącej stan połączeń z funkcją

weryfikacji informacji charakterystycznych dla warstwy aplikacji

VI.3.3.3.1.2. Musi być oparte o dedykowany system operacyjny – nie dopuszcza się rozwiązań

gdzie platformą systemową jest otwarty system operacyjny np. UNIX (Linux,

FreeBSD etc.) lub jego modyfikacja

VI.3.3.3.1.3. Urządzenie nie powinno posiadać ograniczenia na ilość jednocześnie pracujących

użytkowników w sieci chronionej

VI.3.3.3.1.4. Urządzenie musi posiadać co najmniej cztery porty 10/100/1000 GigabitEthernet

VI.3.3.3.1.5. Musi posiadać dedykowane dwa porty dla podłączenia konsoli oraz dla uzyskania

zdalnego dostępu przez modem asynchroniczny

VI.3.3.3.1.6. Musi posiadać co najmniej jeden port USB dla przyszłych zastosowań (tokeny,

etc.)

VI.3.3.3.1.7. Musi posiadać co najmniej 1GB DRAM oraz 256MB Flash

VI.3.3.3.1.8. Urządzenie musi posiadać możliwość rozbudowania o funkcjonalność IPS poprzez

licencję lub moduł

VI.3.3.3.1.9. Urządzenie musi posiadać zaimplementowaną pełną funkcjonalność ochrony

antywirusowej, antyspyware, blokowania transferu plików, antyspamowa,

filtrowania i blokowania odwołań do niepożądanych adresów URL. Wymaga się,


Strona 193 z 208

aby moduł obsługiwał dla tej funkcjonalności minimum 200 użytkowników –

możliwość większej liczby po zastosowaniu dodatkowej licencji

VI.3.3.3.1.10. Urządzenie musi wspierać Active Directory oraz RADIUS’a do autentykacji

użytkowników

VI.3.3.3.1.11. Urządzenie musi posiadać zintegrowane sprzętowe wsparcie dla szyfrowania

VI.3.3.3.1.12. Urządzenie musi mieć możliwość operowania jako transparentna ściana ogniowa

warstwy drugiej ISO OSI

VI.3.3.3.1.13. Urządzenie musi umożliwiać terminowanie co najmniej 100 jednoczesnych sesji

VPN opartych o protokół IPSEC

VI.3.3.3.1.14. Na urządzeniu musi istnieć możliwość terminowania jednocześnie 2 sesji WebVPN

z możliwością rozbudowy do 10 sesji po zastosowaniu dodatkowej licencji

VI.3.3.3.1.15. Urządzenie musi obsługiwać co najmniej 20 000 jednoczesnych sesji/połączeń z

prędkością 5000 połączeń na sekundę

VI.3.3.3.1.16. Przepustowość obsługiwana przez urządzenie nie powinna być mniejsza niż 100

Mbps i jednocześnie 50 Mbps dla ruchu szyfrowanego symetrycznymi

algorytmami 3DES/AES

VI.3.3.3.1.17. Wraz z urządzeniem powinno być dostarczane oprogramowanie klienta VPN,

umożliwiające instalację go i zestawienie do urządzenia połączeń VPN z

komputerów osobistych PC pracujących pod kontrolą systemów operacyjnych

Windows, i Linux, a także komputerów Mac. Oprogramowanie to powinno

pochodzić od tego samego producenta, co oferowane urządzenie i powinno być

objęte jego jednolitym wsparciem technicznym

VI.3.3.3.1.18. Urządzenie musi umożliwiać obsługę co najmniej 20 interfejsów VLAN w

standardzie 802.1q

VI.3.3.3.1.19. Urządzenie musi w celu redundancji umożliwiać implementację funkcji

niezawodności pary takich urządzeń, czyli tzw. failover działającego w trybie

active/standby lub active/active po zastosowaniu dodatkowej licencji

(dostarczenie licencji w ramach tego postępowania nie jest wymagane).

VI.3.3.3.1.20. Urządzenie musi umożliwiać obsługę minimum 5 wirtualnych instancji firewall po

zastosowaniu dodatkowej licencji (dostarczenie licencji w ramach tego

postępowania nie jest wymagane)

VI.3.3.3.1.21. Urządzenie musi dokonywać inspekcji ruchu voice w zakresie protokołów H.323,

SIP, SCCP, MGCP, TAPI, JTAPI

VI.3.3.3.1.22. Urządzenie powinno mieć możliwość blokowania aplikacji typu „internetowy

komunikator” wykorzystujących port 80 (np.: Skype, MSN)

VI.3.3.3.1.23. Urządzenie powinno mieć możliwość blokowania aplikacji typu peer-to-peer (np:

Kaaza, eDonkoey)

VI.3.3.3.1.24. Urządzenie powinno mieć możliwość inspekcji protokołów HTTP oraz FTP na nie

standardowych portach

VI.3.3.3.1.25. Urządzenie musi zapewniać wsparcie dla list kontroli dostępu dla IPv6

VI.3.3.3.1.26. Urządzenie musi być zarządzalne przy wykorzystaniu dedykowanej aplikacji

umożliwiającej płynną (z użyciem kreatorów) konfigurację poszczególnych funkcji

urządzenia

VI.3.3.3.1.27. Urządzenie musi być przystosowane do montażu w 19” szafie rack i nie zajmować

więcej miejsca niż 1U


Strona 194 z 208

VI.3.3.3.1.28. Do urządzenia musi być dołączony komplet licencji dla zapewnienia pełnej

funkcjonalności ochrony antywirusowej, antyspyware, blokowania transferu

plików, antyspamowa, filtrowania i blokowania odwołań do niepożądanych

adresów URL przez okres min. 3 lat.



VI.3.3.3.3.1. Montaż urządzenia w szafie rack,

VI.3.3.3.3.2. Podłączenie do funkcjonującej u Uczestnika Projektu sieci szkieletowej,

VI.3.3.3.3.3. Konfiguracja do pracy zgodnie ze wskazówkami Uczestnika Projektu(w

szczególności adresacja, routing, polityki bezpieczeństwa, filtry, QoS),





VI.3.3.3.4.2. Należy uzgodnić z Zamawiającym i Uczestnikiem Projektu sposób i termin takiego

montażu urządzenia, aby nie zakłócić pracy sieci w sposób utrudniający

funkcjonowanie organizacji Uczestnika Projektu.





wymóg.


VI.3.3.3.5.1. Urządzenie musi zostać objęte min. 3-letnią gwarancją realizowaną w miejscu









urządzenia z normami zasadniczymi (deklaracja CE).







Strona 195 z 208





VI.3.3.4. Dostawa i montaż przełącznika


VI.3.3.4.1.1. Przeznaczony do montażu w szafie rack 19”, wysokości maks. 2U,

VI.3.3.4.1.2. Typ i liczba portów - min. 24 porty Gigabit Ethernet 10/100/1000BaseT oraz

minimum 4 porty Gigabit Ethernet MiniGBIC (SFP). Wykorzystanie portów SFP nie

może powodować wyłączenia żadnego z portów 10/100/1000BaseT

VI.3.3.4.1.3. Przełącznik musi umożliwiać rozbudowę (np. poprzez instalację dodatkowego

modułu) o możliwość łączenia w stosy z zachowaniem następującej

funkcjonalności:

Zarządzanie stosem poprzez jeden adres IP

min. 4 przełączników w stosie

Magistrala stakująca o wydajności minimum 20Gb/s

Możliwość tworzenia połączeń link aggregation zgodnie z 802.3ad dla

portów należących do różnych jednostek w stosie (Cross-stack link

aggregation)

VI.3.3.4.1.4. Minimalne parametry wydajnościowe:

matryca przełączająca o przepustowości min. 130Gb/s

szybkość przełączania min. 41,7 Mp/s (dla pakietów 64-bajtowych)

obsługa min. 8.000 adresów MAC

obsługa min. 255 sieci VLAN

obsługa ramek jumbo o wielkości min. 9216 bajtów

VI.3.3.4.1.5. Wsparcie dla protokołów:



wymagane wsparcie dla min. 64 instancji protokołu STP

VI.3.3.4.1.6. Obsługa min. 16 statycznych tras dla routingu IP

VI.3.3.4.1.7. Obsługa protokołów LLDP i LLDP-MED.

VI.3.3.4.1.8. Obsługa ruchu multicast - IGMPv3 i MLDv1/2 Snooping

VI.3.3.4.1.9. Przełącznik musi posiadać możliwość uruchomienia funkcjonalności serwera

DHCP

VI.3.3.4.1.10. Wymagane mechanizmy związane z zapewnieniem bezpieczeństwa sieci:

min. 4 poziomy dostępu administracyjnego poprzez konsolę

autoryzacja użytkowników w oparciu o IEEE 802.1x z możliwością

przydziału VLANu oraz dynamicznego przypisania listy ACL

obsługa VLANu dla gości

możliwość uwierzytelniania urządzeń na porcie w oparciu o adres MAC


Strona 196 z 208

uwierzytelnianie użytkowników w oparciu o portal www dla klientów

bez suplikanta 802.1X

dostęp do urządzenia poprzez HTTPS, SNMPv3 i SSHv2

możliwość filtrowania ruchu w oparciu o adresy MAC, IP, porty TCP/UDP

obsługa mechanizmów Port Security, DHCP Snooping, Dynamic ARP

Inspection, IP Source Guard

obsługa funkcji voice VLAN

VI.3.3.4.1.11. Wymagane mechanizmy QoS:

implementacja co najmniej czterech kolejek sprzętowych QoS na

każdym porcie wyjściowym dla obsługi ruchu o różnej klasie obsługi

klasyfikacja ruchu do klas różnej jakości obsługi (QoS) poprzez



obsługa jednej z powyżej wspomnianych kolejek z bezwzględnym

priorytetem w stosunku do innych (Strict Priority)

VI.3.3.4.1.12. Wymagane opcje zarządzania:

możliwość lokalnej i zdalnej obserwacji ruchu na określonym porcie,

polegająca na kopiowaniu pojawiających się na nim ramek i przesyłaniu

ich do urządzenia monitorującego przyłączonego do innego portu lub

poprzez określony VLAN (SPAN/RSPAN)

plik konfiguracyjny urządzenia musi być możliwy do edycji w trybie off-

line (tzn. konieczna jest możliwość przeglądania i zmian konfiguracji w

pliku tekstowym na dowolnym urządzeniu PC). W pamięci nieulotnej

musi być możliwość przechowywania przynajmniej 5 plików

konfiguracyjnych

dedykowany port konsoli

dedykowany port Ethernet do zarządzania

min. jeden port USB umożliwiający dołączenie zewnętrznych pamięci

flash

możliwość synchronizacji czasu zgodnie z protokołem NTP

VI.3.3.4.1.13. Możliwość zastosowania redundantnego zasilacza.




VI.3.3.4.3.2. Podłączenie zasilania,





VI.3.3.4.4.2. Należy podłączyć okablowanie sieciowe zgodnie ze wskazaniami Zamawiającego i

Uczestnika Projektu.


Strona 197 z 208





wymóg.


VI.3.3.4.5.1. Przełącznik musi być objęty min. 3-letnią gwarancją.


VI.3.3.4.6.1. Po zakończeniu testu poprawności działania.
















VI.3.3.5. Dostawa i montaż przełącznika z PoE


VI.3.3.5.1.1. Przeznaczony do montażu w szafie rack 19”, wysokości maks. 2U,

VI.3.3.5.1.2. Typ i liczba portów - min. 24 porty Gigabit Ethernet 10/100/1000BaseT w

standardzie PoE oraz minimum 4 porty Gigabit Ethernet MiniGBIC (SFP).

Wykorzystanie portów SFP nie może powodować wyłączenia żadnego z portów

10/100/1000BaseT

VI.3.3.5.1.3. Przełącznik musi umożliwiać rozbudowę (np. poprzez instalację dodatkowego

modułu) o możliwość łączenia w stosy z zachowaniem następującej

funkcjonalności:

Zarządzanie stosem poprzez jeden adres IP

min. 4 przełączników w stosie

Magistrala stakująca o wydajności minimum 20Gb/s


Strona 198 z 208

Możliwość tworzenia połączeń link aggregation zgodnie z 802.3ad dla

portów należących do różnych jednostek w stosie (Cross-stack link

aggregation)

VI.3.3.5.1.4. Minimalne parametry wydajnościowe:

matryca przełączająca o przepustowości min. 130Gb/s

szybkość przełączania min. 41,7 Mp/s (dla pakietów 64-bajtowych)

obsługa min. 8.000 adresów MAC

obsługa min. 255 sieci VLAN

obsługa ramek jumbo o wielkości min. 9216 bajtów

VI.3.3.5.1.5. Wsparcie dla protokołów:



wymagane wsparcie dla min. 64 instancji protokołu STP

VI.3.3.5.1.6. Obsługa min. 16 statycznych tras dla routingu IP

VI.3.3.5.1.7. Obsługa protokołów LLDP i LLDP-MED.

VI.3.3.5.1.8. Obsługa ruchu multicast - IGMPv3 i MLDv1/2 Snooping

VI.3.3.5.1.9. Przełącznik musi posiadać możliwość uruchomienia funkcjonalności serwera

DHCP

VI.3.3.5.1.10. Wymagane mechanizmy związane z zapewnieniem bezpieczeństwa sieci:

min. 4 poziomy dostępu administracyjnego poprzez konsolę

autoryzacja użytkowników w oparciu o IEEE 802.1x z możliwością

przydziału VLANu oraz dynamicznego przypisania listy ACL

obsługa VLANu dla gości

możliwość uwierzytelniania urządzeń na porcie w oparciu o adres MAC

uwierzytelnianie użytkowników w oparciu o portal www dla klientów

bez suplikanta 802.1X

dostęp do urządzenia poprzez HTTPS, SNMPv3 i SSHv2

możliwość filtrowania ruchu w oparciu o adresy MAC, IP, porty TCP/UDP

obsługa mechanizmów Port Security, DHCP Snooping, Dynamic ARP

Inspection, IP Source Guard

obsługa funkcji voice VLAN

VI.3.3.5.1.11. Wymagane mechanizmy QoS:

implementacja co najmniej czterech kolejek sprzętowych QoS na

każdym porcie wyjściowym dla obsługi ruchu o różnej klasie obsługi

klasyfikacja ruchu do klas różnej jakości obsługi (QoS) poprzez



obsługa jednej z powyżej wspomnianych kolejek z bezwzględnym

priorytetem w stosunku do innych (Strict Priority)

VI.3.3.5.1.12. Wymagane opcje zarządzania:

możliwość lokalnej i zdalnej obserwacji ruchu na określonym porcie,

polegająca na kopiowaniu pojawiających się na nim ramek i przesyłaniu

ich do urządzenia monitorującego przyłączonego do innego portu lub

poprzez określony VLAN (SPAN/RSPAN)


Strona 199 z 208

plik konfiguracyjny urządzenia musi być możliwy do edycji w trybie off-

line (tzn. konieczna jest możliwość przeglądania i zmian konfiguracji w

pliku tekstowym na dowolnym urządzeniu PC). W pamięci nieulotnej

musi być możliwość przechowywania przynajmniej 5 plików

konfiguracyjnych

dedykowany port konsoli

dedykowany port Ethernet do zarządzania

min. jeden port USB umożliwiający dołączenie zewnętrznych pamięci

flash

możliwość synchronizacji czasu zgodnie z protokołem NTP

VI.3.3.5.1.13. Możliwość zastosowania redundantnego zasilacza.




VI.3.3.5.3.2. Podłączenie zasilania,





VI.3.3.5.4.2. Należy podłączyć okablowanie sieciowe zgodnie ze wskazaniami Uczestnika

Projektu.





wymóg.


VI.3.3.5.5.1. Przełącznik musi być objęty min. 3-letnią gwarancją.


VI.3.3.5.6.1. Po zakończeniu testu poprawności działania.










Strona 200 z 208








VI.3.3.6. Dostawa stacji roboczej

VI.3.3.6.1. Specyfikacja techniczna / funkcjonalna jednostki centralnej:

VI.3.3.6.1.1. Procesor

VI.3.3.6.1.1.1. Procesor osiągający w zaoferowanym modelu komputera wynik minimum

4300 punktów w teście PassMark CPU Benchmarks w kolumnie Passmark CPU

Mark (Zamawiający wskazuje adres publikacji testów

http://www.cpubenchmark.net/cpu_list.php, który został wykorzystany przez

Zamawiającego do określenia wymogów minimalnych dla procesora. W

przypadku zmiany adresu publikacji testów Zamawiający akceptuje wynik

testu PassMark CPU Benchmarks zaproponowanego procesora znajdującego

się pod innym adresem w ramach strony http://www.passmark.com/).

Zamawiający wymaga zaoferowania procesora, dla którego istnieje wynik w

ramach testu PassMark CPU Benchmarks na stronie

http://www.passmark.com).


VI.3.3.6.1.2.1. co najmniej 4GB, minimum 2 banki pamięci, w tym jeden wolny

VI.3.3.6.1.2.2. możliwość rozbudowy do min. 16 GB ,

VI.3.3.6.1.3. Dysk twardy

VI.3.3.6.1.3.1. co najmniej 500 GB; czas wyszukiwania maksymalnie 10ms; min. 1 x wolna

kieszeń 3,5 (wewnętrzna);


VI.3.3.6.1.4.1. zintegrowany kontroler 3 x SATA;

VI.3.3.6.1.4.2. min 1x PCI Express 3.0 o szybkości x16;

VI.3.3.6.1.4.3. min 2x PCI Express o szybkości x1;

VI.3.3.6.1.4.4. możliwość zabezpieczenia hasłem dostępu do BIOS’ u komputera;

VI.3.3.6.1.5. Karta dźwiękowa

VI.3.3.6.1.5.1. zintegrowana w standardzie High Definition

VI.3.3.6.1.6. Karta sieciowa

VI.3.3.6.1.6.1. 10/100/1000 Mbp/s ,


VI.3.3.6.1.7.1. zintegrowana, dopuszcza się współdzielenie pamięci z pamięcią operacyjną

VI.3.3.6.1.7.2. obsługa rozdzielczości obrazu minimum 1280 x 1024 pikseli,

VI.3.3.6.1.7.3. obsługa DirectX 11, OpenGL® 2.1,

VI.3.3.6.1.8. Porty I/O

http://www.passmark.com/


Strona 201 z 208

VI.3.3.6.1.8.1. min. 6 portów USB w tym min 2 na panelu przednim.

VI.3.3.6.1.8.2. 1 x DVI lub 1 x Display Port w zależności od oferowanego monitora;

VI.3.3.6.1.8.3. 1 x D-SUB;

VI.3.3.6.1.8.4. co najmniej 1x wyjście audio oraz 1x wejście mikrofonowe umieszczone z

przodu i z tyłu obudowy;

VI.3.3.6.1.9. Obudowa typu Tower lub Minitower,

VI.3.3.6.1.10. Zasilacz o mocy dobranej do maksymalnej konfiguracji komputera z aktywnym

filtrem PFC;

VI.3.3.6.1.11. Klawiatura standardowa w układzie QWERTY,

VI.3.3.6.1.12. DVD-RW (z oprogramowaniem do odtwarzania i nagrywania płyt DVD), Napęd

optyczny

VI.3.3.6.1.13. Mysz optyczna z rolką, podkładka pod mysz zapewniająca jej prawidłowe

funkcjonowanie.

VI.3.3.6.1.14. Do stacji roboczej musi być dołączone oprogramowanie wspierane przez

producenta służące do diagnozy stanu technicznego komputera.

VI.3.3.6.1.15. Jednostka centralna musi być wyposażona w BIOS posiadający możliwość:

VI.3.3.6.1.15.1. skonfigurowania hasła „Power On” oraz ustawienia hasła dostępu do

BIOSu (Administratora) w sposób gwarantujący utrzymanie

zapisanego hasła nawet w przypadku odłączenia wszystkich źródeł

zasilania i podtrzymania BIOS,

VI.3.3.6.1.15.2. możliwość ustawienia hasła na dysku (drive lock),

VI.3.3.6.1.15.3. blokady/wyłączenia portów USB, COM, karty sieciowej, karty audio,

VI.3.3.6.1.15.4. blokady/wyłączenia kart rozszerzeń/slotów PCI, Zapis usunięty przez

Zamawiającego,

VI.3.3.6.1.15.5. kontroli sekwencji startowej,

VI.3.3.6.1.15.6. startu systemu z urządzenia USB,

VI.3.3.6.1.15.7. funkcja blokowania startu stacji roboczej z zewnętrznych urządzeń,

VI.3.3.6.1.16. Oferowany sprzęt musi być produkowany zgodnie z normami ISO 9001 oraz ISO

14001 lub równoważnymi,

VI.3.3.6.1.17. Oferowany komputer musi być zgodny z zaoferowaną wersją systemu

operacyjnego (wymagane potwierdzenie kompatybilności komputera na stronie

producenta lub jego oświadczenie),

VI.3.3.6.1.18. Komputer musi posiadać deklarację zgodności CE,

VI.3.3.6.1.19. Komputer musi posiadać ważny certyfikat zgodny z normą Energy Star 5.0,

VI.3.3.6.1.20. W jednostce centralnej musi być preinstalowany system operacyjny klasy PC

posiadający następujące cechy:

VI.3.3.6.1.20.1. Musi umożliwiać podłączenie zestawów komputerowych do

kontrolera domeny Active Directory użytkowanego w Urzędzie;

VI.3.3.6.1.20.2. Dostępne dwa rodzaje graficznego interfejsu użytkownika:

Klasyczny, umożliwiający obsługę przy pomocy klawiatury i myszy,

Dotykowy umożliwiający sterowanie dotykiem na urządzeniach

typu tablet lub monitorach dotykowych,

VI.3.3.6.1.20.3. Interfejsy użytkownika dostępne w wielu językach do wyboru – w tym

Polskim i Angielskim,


Strona 202 z 208

VI.3.3.6.1.20.4. Możliwość dokonywania bezpłatnych aktualizacji i poprawek w

ramach wersji systemu operacyjnego poprzez Internet, mechanizmem

udostępnianym przez producenta systemu z możliwością wyboru

instalowanych poprawek oraz mechanizmem sprawdzającym, które z

poprawek są potrzebne,

VI.3.3.6.1.20.5. Możliwość dokonywania aktualizacji i poprawek systemu poprzez

mechanizm zarządzany przez Administratora systemu Zamawiającego,

VI.3.3.6.1.20.6. Dostępność bezpłatnych biuletynów bezpieczeństwa związanych z

działaniem systemu operacyjnego,

VI.3.3.6.1.20.7. Wbudowana zapora internetowa (firewall) dla ochrony połączeń

internetowych; zintegrowana z systemem konsola do zarządzania

ustawieniami zapory i regułami IP v4 i v6;

VI.3.3.6.1.20.8. Wbudowane mechanizmy ochrony antywirusowej i przeciw

złośliwemu oprogramowaniu z zapewnionymi bezpłatnymi

aktualizacjami,

VI.3.3.6.1.20.9. Zlokalizowane w języku polskim, co najmniej następujące elementy:

menu, odtwarzacz multimediów, pomoc, komunikaty systemowe,

VI.3.3.6.1.20.10. Graficzne środowisko instalacji i konfiguracji dostępne w języku

polskim,

VI.3.3.6.1.20.11. Funkcjonalność automatycznej zmiany domyślnej drukarki w

zależności od sieci, do której podłączony jest komputer,

VI.3.3.6.1.20.12. Możliwość zarządzania stacją roboczą poprzez polityki grupowe –

przez politykę rozumiemy zestaw reguł definiujących lub

ograniczających funkcjonalność systemu lub aplikacji,

VI.3.3.6.1.20.13. Rozbudowane, definiowalne polityki bezpieczeństwa – polityki dla

systemu operacyjnego i dla wskazanych aplikacji,

VI.3.3.6.1.20.14. Możliwość zdalnej automatycznej instalacji, konfiguracji,

administrowania oraz aktualizowania systemu, zgodnie z określonymi

uprawnieniami poprzez polityki grupowe,

VI.3.3.6.1.20.15. Zabezpieczony hasłem hierarchiczny dostęp do systemu, konta i profile

użytkowników zarządzane zdalnie; praca systemu w trybie ochrony

kont użytkowników.

VI.3.3.6.1.20.16. Zintegrowany z systemem moduł wyszukiwania informacji (plików

różnego typu, tekstów, metadanych) dostępny z kilku poziomów:

poziom menu, poziom otwartego okna systemu operacyjnego; system

wyszukiwania oparty na konfigurowalnym przez użytkownika module

indeksacji zasobów lokalnych,

VI.3.3.6.1.20.17. Zintegrowany z systemem operacyjnym moduł synchronizacji

komputera z urządzeniami zewnętrznymi.

VI.3.3.6.1.20.18. Wbudowany system pomocy w języku polskim;

VI.3.3.6.1.20.19. Możliwość przystosowania stanowiska dla osób niepełnosprawnych

(np. słabo widzących);

VI.3.3.6.1.20.20. Wsparcie dla IPSEC oparte na politykach – wdrażanie IPSEC oparte na

zestawach reguł definiujących ustawienia zarządzanych w sposób

centralny;


Strona 203 z 208

VI.3.3.6.1.20.21. Automatyczne występowanie i używanie (wystawianie) certyfikatów

PKI X.509;

VI.3.3.6.1.20.22. Mechanizmy logowania w oparciu o:

Login i hasło,

Karty z certyfikatami (smartcard),

Wirtualne karty (logowanie w oparciu o certyfikat chroniony

poprzez moduł TPM),

VI.3.3.6.1.20.23. Wsparcie dla uwierzytelniania na bazie Kerberos v. 5,

VI.3.3.6.1.20.24. Wsparcie do uwierzytelnienia urządzenia na bazie certyfikatu,

VI.3.3.6.1.20.25. Wsparcie dla algorytmów Suite B (RFC 4869),

VI.3.3.6.1.20.26. Wsparcie wbudowanej zapory ogniowej dla Internet Key Exchange v.

2 (IKEv2) dla warstwy transportowej IPsec,

VI.3.3.6.1.20.27. Wbudowane narzędzia służące do administracji, do wykonywania kopii

zapasowych polityk i ich odtwarzania oraz generowania raportów z

ustawień polityk;

VI.3.3.6.1.20.28. Wsparcie dla środowisk Java i .NET Framework 1.1 i 2.x, 3.x i 4.x –

możliwość uruchomienia aplikacji działających we wskazanych

środowiskach,

VI.3.3.6.1.20.29. Wsparcie dla JScript i VBScript – możliwość uruchamiania interpretera

poleceń,

VI.3.3.6.1.20.30. Zdalna pomoc i współdzielenie aplikacji – możliwość zdalnego

przejęcia sesji zalogowanego użytkownika celem rozwiązania

problemu z komputerem,

VI.3.3.6.1.20.31. Rozwiązanie służące do automatycznego zbudowania obrazu systemu

wraz z aplikacjami. Obraz systemu służyć ma do automatycznego

upowszechnienia systemu operacyjnego inicjowanego i

wykonywanego w całości poprzez sieć komputerową,

VI.3.3.6.1.20.32. Rozwiązanie ma umożliwiające wdrożenie nowego obrazu poprzez

zdalną instalację,

VI.3.3.6.1.20.33. Transakcyjny system plików pozwalający na stosowanie przydziałów

(ang. quota) na dysku dla użytkowników oraz zapewniający większą

niezawodność i pozwalający tworzyć kopie zapasowe,

VI.3.3.6.1.20.34. Zarządzanie kontami użytkowników sieci oraz urządzeniami

sieciowymi tj. drukarki, modemy, woluminy dyskowe, usługi

katalogowe

VI.3.3.6.1.20.35. Oprogramowanie dla tworzenia kopii zapasowych (Backup);

automatyczne wykonywanie kopii plików z możliwością

automatycznego przywrócenia wersji wcześniejszej,

VI.3.3.6.1.20.36. Możliwość przywracania obrazu plików systemowych do uprzednio

zapisanej postaci,

VI.3.3.6.1.20.37. Identyfikacja sieci komputerowych, do których jest podłączony system

operacyjny, zapamiętywanie ustawień i przypisywanie do min. 3

kategorii bezpieczeństwa (z predefiniowanymi odpowiednio do

kategorii ustawieniami zapory sieciowej, udostępniania plików itp.),


Strona 204 z 208

VI.3.3.6.1.20.38. Możliwość blokowania lub dopuszczania dowolnych urządzeń

peryferyjnych za pomocą polityk grupowych (np. przy użyciu numerów

identyfikacyjnych sprzętu),

VI.3.3.6.1.20.39. Wbudowany mechanizm wirtualizacji typu hypervisor, umożliwiający,

zgodnie z uprawnieniami licencyjnymi, uruchomienie do 4 maszyn

wirtualnych,

VI.3.3.6.1.20.40. Mechanizm szyfrowania dysków wewnętrznych i zewnętrznych z

możliwością szyfrowania ograniczonego do danych użytkownika,

VI.3.3.6.1.20.41. Wbudowane w system narzędzie do szyfrowania partycji systemowych

komputera, z możliwością przechowywania certyfikatów „w

mikrochipie TPM (Trusted Platform Module) w wersji minimum 1.2 lub

na kluczach pamięci przenośnej USB.

VI.3.3.6.1.20.42. Wbudowane w system narzędzie do szyfrowania dysków przenośnych,

z możliwością centralnego zarządzania poprzez polityki grupowe,

pozwalające na wymuszenie szyfrowania dysków przenośnych

VI.3.3.6.1.20.43. Możliwość tworzenia i przechowywania kopii zapasowych kluczy

odzyskiwania do szyfrowania partycji w usługach katalogowych.

VI.3.3.6.1.20.44. Możliwość nieodpłatnego instalowania dodatkowych języków

interfejsu systemu operacyjnego oraz możliwość zmiany języka bez

konieczności reinstalacji systemu.

VI.3.3.6.2. Specyfikacja techniczna / funkcjonalna monitora:

VI.3.3.6.2.1. Przekątna ekranu, rozdzielczość

VI.3.3.6.2.1.1. Przekątna ekranu co najmniej 18,9 cala o rozdzielczości natywnej minimum

1280 x 1024 pikseli,

VI.3.3.6.2.1.2. Parametry obrazu

VI.3.3.6.2.1.3. monitor podświetlany w technologii LED,

VI.3.3.6.2.1.4. kąty widzenia: pion minimum 160 stopni, poziom minimum 170 stopni

VI.3.3.6.2.1.5. monitor musi posiadać możliwość regulacji w pionie i w poziomie

VI.3.3.6.2.2. Wejścia wideo

VI.3.3.6.2.2.1. złącze wideo zgodne z zaoferowaną kartą graficzną

VI.3.3.6.2.3. Obudowa i regulacja monitora

VI.3.3.6.2.3.1. zintegrowany zasilacz,

VI.3.3.6.2.3.2. zintegrowane głośniki lub dedykowana zasilana z monitora listwa

głośnikowa stereo lub głośniki wolnostojące o mocy minimum 1W na każdy

głośnik

VI.3.3.6.2.4. Kable

VI.3.3.6.2.4.1. fabrycznie dostarczone w zestawie:

VI.3.3.6.2.4.2. kabel zgodny z zaoferowaną kartą graficzną o długości minimum 1,8 m,

VI.3.3.6.2.4.3. kabel umożliwiający przesyłanie dźwięku stereo z komputera do monitora

min. 1,8 m,

VI.3.3.6.2.4.4. zasilania energii elektrycznej.



Strona 205 z 208


VI.3.3.6.4.1. Dostawa stacji roboczych w terminie i do miejsca uzgodnionego z Zamawiającym

i Uczestnikiem Projektu.






wymóg.


VI.3.3.6.6.1. Stacje robocze (jednostka centralna i monitor) muszą być objęte min. 3-letnią

gwarancją.


VI.3.3.6.7.1. Po dostawie.






jednostki centralnej i monitora z normami zasadniczymi (deklaracja CE),

VI.3.3.6.8.2. Zamawiający wymaga dostarczenia do oferty wydruku rezultatu testu PassMark

CPU Benchmarks oferowanego procesora potwierdzającego spełnienie

powyższego warunku.



VI.3.3.6.8.4. Do oferty należy załączyć dokument potwierdzający, że oferowany komputer

jest zgodny z zaoferowaną wersją systemu operacyjnego,










VI.3.3.7. Dostawa drukarki


Strona 206 z 208

VI.3.3.7.1. Specyfikacja techniczna / funkcjonalna jednostki centralnej:

VI.3.3.7.1.1. Typ urządzenia – urządzenie wielofunkcyjne: drukarka, skaner, kopiarka,

VI.3.3.7.1.2. Monochromatyczny druk laserowy

VI.3.3.7.1.3. Obsługiwane języki min. PCL 6, PCL 5, emulacja Postscript poziom 3,

VI.3.3.7.1.4. Normatywne obciążenie min. 8 000 stron miesięcznie,

VI.3.3.7.1.5. Rozdzielczość druku min. 600x600 dpi

VI.3.3.7.1.6. Wyświetlacz tekstowy LCD lub dotykowy,

VI.3.3.7.1.7. Bufor druku min. 64 MB,

VI.3.3.7.1.8. Prędkość druku min. 25 str. A4/min.

VI.3.3.7.1.9. Wbudowany skaner stolikowy z podajnikiem dokumentów na minimum 35

arkuszy,

VI.3.3.7.1.10. Format skanowania min. JPEG, TIF, PDF wielostronicowy,

VI.3.3.7.1.11. Rozdzielczość skanowania min. 600 dpi,

VI.3.3.7.1.12. Skalowanie obrazu przy kopiowaniu w zakresie min. 25 - 400%.

VI.3.3.7.1.13. Wbudowane złącza min. 1 x USB 2.0, RJ-45,

VI.3.3.7.1.14. Format wydruku min. A4,

VI.3.3.7.1.15. Automatyczny podajnik papieru min. na 250 ark.,

VI.3.3.7.1.16. Dostępny podajnik ręczny,

VI.3.3.7.1.17. Taca odbiorcza na min. 100 arkuszy,

VI.3.3.7.1.18. Bezpośrednie drukowanie dokumentów z USB (Pendrive),

VI.3.3.7.1.19. Dostępne sterowniki dla systemów operacyjnych z rodziny MS Windows, Linux i

Mac OS.



VI.3.3.7.3.1. Dostawa drukarek w terminie i do miejsca uzgodnionego z Uczestnikiem Projektu.






wymóg.


VI.3.3.7.5.1. Drukarka musi być objęta min. 3-letnią gwarancją z czasem reakcji w ciągu 3 dni

roboczych.







Strona 207 z 208



drukarki z normami zasadniczymi (deklaracja CE).










VI.3.3.8. Dostawa zasilacza UPS 650VA


VI.3.3.8.1.1. Obudowa wolnostojąca,

VI.3.3.8.1.2. W komplecie należy dołączyć komplet kabli zasilających,

VI.3.3.8.1.3. Moc min. 650 VA,



VI.3.3.8.1.5. Zasilacz powinien być wyposażony w minimum 2 gniazda z utrzymaniem zasilania

w standardzie IEC320 C13 (10A),

VI.3.3.8.1.6. Zasilacz musi posiadać złącze do podłączenia do standardowego komputera PC w

celu monitorowania pracy.



VI.3.3.8.3.1. Dostawa zasilaczy w terminie i do miejsca uzgodnionego z Zamawiającym.






wymóg.






Strona 208 z 208
















Lubuskie...Projekt współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju...

Documents

Transcript of Lubuskie...Projekt współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju...