opis przedmiotu zamówienia (opz)

Transkrypt

System Wspomagania Dowodzenia Państwowego Ratownictwa Medycznego
Załącznik nr 1
OPIS PRZEDMIOTU ZAMÓWIENIA (OPZ)
na budowę i wdrożenie ogólnokrajowego Systemu Wspomagania
Strona 1
Dowodzenia Państwowego Ratownictwa Medycznego (SWD PRM)
1. Wstęp
Przedsięwzięcie stanowi element projektu pn.: „System Informatyczny Powiadamiania
Ratunkowego (SI PR)” którego realizacja podyktowana jest koniecznością wdrożenia jednolitych
w skali kraju narzędzi informatycznych wspierających współdziałanie i realizację zadań służb
ustawowo powołanych do przyjęcia i obsługi wywołań alarmowych. System ten będzie stanowił
główny element wyposażenia Państwowego Ratownictwa Medycznego funkcjonującego w ramach
systemu powiadamiania ratunkowego (SPR), o których mowa w rozporządzeniu Ministra Spraw
Wewnętrznych i Administracji z dnia 31 lipca 2009 r. w sprawie organizacji i funkcjonowania
centrów powiadamiania ratunkowego i wojewódzkich centrów powiadamiania ratunkowego (Dz. U.
z 2009 r. Nr 130, poz. 1073), oraz komórek organizacyjnych Policji.
Przedmiotowe zamówienie dotyczy realizacji Systemu Wspomagania Dowodzenia
Państwowego
Ratownictwa
Medycznego
(SWD
PRM)
stanowiącego
moduł
Systemu
Informatycznego Powiadamiania Ratunkowego, którego głównym zadaniem jest zapewnienie
sprawnej obsługi zdarzeń przekazanych przez Centra Powiadamiania Ratunkowego i Wojewódzkie
Centra
Powiadamiania
Ratunkowego,
wsparcie
procesu
dysponowania
siłami
i
środkami
wykorzystywanymi w celach obsługi zdarzeń oraz rozliczeń dokonywanych z Narodowym
Funduszem Zdrowia (NFZ).
Głównym użytkownikiem SWD PRM będą Dysponenci (dyspozytorzy medyczni) zespołów
ratownictwa medycznego oraz SP ZOZ Lotnicze Pogotowie Ratunkowe. W ramach zamówienia
zapewniony zostanie uniwersalny interfejs, umożliwiający integrację m.in. z systemami WCPR/ CPR
oraz innymi systemami wspomagania dowodzenia PRM i systemami zewnętrznymi służby zdrowia.
Zamówienie jest finansowane w ramach przedsięwzięcia pn. ”Budowa i wyposażenie Centrów
Powiadamiania Ratunkowego” realizowanego w Programie Operacyjnym Innowacyjna Gospodarka
(POIG) Oś priorytetowa VII oraz ”Budowa i wyposażenie Wojewódzkich Centrów Powiadamiania
Ratunkowego”
realizowanego
w
Programie
Operacyjnym
Infrastruktura
i
Środowisko
(POIŚ)
Oś priorytetowa XII.
2. Pojęcia i skróty
Dla potrzeb niniejszego opracowania przyjmuję się następujące definicje skrótów i pojęć:
Skrót/pojęcie
Definicja
Analiza
Dokumentacja sporządzona przez Wykonawcę na podstawie szczegółowej
analizy potrzeb Zamawiającego w zakresie wymagań stawianych Systemowi;
APL
Automatic Person Location – Automatyczna Lokalizacja Osoby;
APN
(ang. Access Point Name) Sieć pakietowa (np. Internet, intranet operatora)
i (opcjonalnie) usługę (np. MMS, WAP, GPRS) dzięki której w sieciach
komórkowych GSM i UMTS użytkownik terminala może korzystać z transmisji
danych przesyłanych z zewnętrznych sieci (kanał transmisyjny GRE over IP
sec);
Aplikacja SI WCPR
Aplikacja
użytkownika
Systemu
Informatycznego
Wojewódzkich
Centrów
Powiadamiania Ratunkowego;
AVL
Automatic Vehicle Location – Automatyczna Lokalizacja Pojazdu;
Awaria Krytyczna
brak działania środowiska produkcyjnego Systemu, praca nie może być
kontynuowana, operacja krytyczna dla procesu biznesowego jest niemożliwa.
Awarie Krytyczne mają jedną lub więcej z poniższych cech:
Skrót/pojęcie
Definicja
a) Dane biznesowe zostały uszkodzone;
b) Funkcjonalność krytyczna („Funkcjonalność Krytyczna”) udokumentowana
w Projekcie Technicznym nie działa;
c) System w zakresie Funkcjonalności Krytycznych przerywa działania i nie daje
się uruchomić pomimo prób;
Awaria Niekrytyczna
Utrudnia
działanie
Systemu
w
środowisku
produkcyjnym
w
zakresie
Funkcjonalności Krytycznej i uniemożliwia działanie Systemu w zakresie
pozostałych funkcjonalności. W tym kontekście „utrudnia” oznacza istnienie
sposobu jego obejścia (co może mieć wpływ na wygodę w użyciu Systemu lub
wymagać
procedur
ręcznych).
„Uniemożliwia”
oznacza
brak
możliwości
znalezienia sposobu na jego obejście;
Awaria Zwykła
Wszelka awaria nie będąca Awarią Krytyczną lub Awarią Niekrytyczną;
CPR
Centrum Powiadamiania Ratunkowego;
Dokumentacja medyczna
Książka pracy Pogotowia Ratunkowego, karta zlecenia wyjazdu zespołu
PRM
ratownictwa medycznego, karta medycznych czynności ratunkowych, karta
drogowa, karta medyczna dla potrzeb LPR. Dokumentacja będzie zgodna
z rozporządzeniem MZ, gdzie zawarte są jej wzory;
Dokumentacja
Oznacza
dokumentację
wykonaną
przez
Wykonawcę
i
dostarczoną
projektowa
Zamawiającemu w ramach realizacji Umowy, podlegająca zatwierdzeniu przez
Zamawiającego, materiały w formie papierowej, jak również informacje
zapisane
na
innych
nośnikach,
w
tym
nośnikach
elektronicznych,
w
szczególności PZP
Dysponent
Zakład opieki zdrowotnej, w którego skład wchodzą jednostki systemu
Państwowe Ratownictwo Medyczno, podmiot odpowiedzialny za dysponowanie
zespołów ratownictwa medycznego. Rolę Dysponenta pełni również SP ZOZ
Lotnicze
Pogotowie
Ratunkowe
(Samodzielny
Publiczny
Zakład
Opieki
Zdrowotnej Lotnicze Pogotowie Ratunkowe);
Dyspozytor
Użytkownik
realizujący
obsługę
zgłoszeń
przyjętych
od
Operatora,
wykorzystujący system SWD PRM. Rola i zakres działania Dyspozytora jest
zdefiniowany
w
ustawie
o
Państwowym
Ratownictwie
Medycznym
oraz
Rozporządzeniu Ministra Zdrowia w sprawie ramowych procedur przyjmowania
wezwań przez dyspozytora medycznego i dysponowania zespołami ratownictwa
medycznego;
Funkcjonalność Krytyczna
Cechy funkcjonalne systemu uniemożliwiające realizację operacji krytycznych
z punktu widzenia przyjęcia i obsługi zgłoszeń alarmowych;
GPS
(ang. Global Positioning System) system nawigacji satelitarnej;
Koordynator PRM
Użytkownik Końcowy z ramienia PRM realizujący funkcję nadzoru na poziomie
WCPR;
Lokalizacja
Oznacza wskazane i przygotowane przez Zamawiającego miejsce (w tym
karetki ZRM, miejsca stacjonowania ZRM, 50 dyspozytorni medycznych), do
którego Wykonawca dostarczy wymagane przez Zamawiającego w ramach
dostaw elementy Systemu, w wyłączeniem elementów Systemu zapewnianych
przez Zamawiającego;
Modyfikacja
Oznacza wyższe wersje (update/upgrade), patche i programy korekcji błędów
Oprogramowania Aplikacyjnego oraz Oprogramowania Standardowego, do
których dostarczenia na rzecz Zamawiającego, wraz z odnosząca się do tego
Dokumentacją, zobowiązany jest Wykonawca;
MS ZRM
Miejsce Stacjonowania Zespołów RM zdefiniowane jako miejsce wyczekiwania
PRM-u i obszarami działania;
MSWiA
Ministerstwo
Spraw
Wewnętrznych
i
Administracji
wraz
z
organami
i jednostkami organizacyjnymi podległymi lub nadzorowanymi przez Ministra
Strona 3
ZRM-u w ramach struktury Dysponenta zgodne z Rejonami Operacyjnymi
Skrót/pojęcie
Definicja
Spraw Wewnętrznych i Administracji;
Oprogramowanie
Oprogramowanie Standardowe i Oprogramowanie Aplikacyjne;
Oprogramowanie
Oprogramowanie
Standardowe
pomocnicze), będące przedmiotem Dostaw w ramach realizacji przedmiotu
powszechnie
dostępne
(systemowe,
bazodanowe,
zamówienia, na które producent udziela Zamawiającemu licencji na warunkach
i zasadach określonych w Umowie oraz umowach licencyjnych Oprogramowania
Standardowego pozwalających na korzystanie z Systemu Użytkownikowi
końcowemu, dostarczane przez Wykonawcę wraz licencją producenta oraz z
dokumentacją i Modyfikacjami;
Oprogramowanie
Oprogramowanie i skrypty wraz z kompletnymi kodami źródłowymi wytworzone
Aplikacyjne
i dostarczone przez Wykonawcę w ramach przedmiotu zamówienia, wraz
z dokumentacją i Modyfikacjami, do których Wykonawca przeniesie autorskie
prawa majątkowe na Zamawiającego i MSWiA na warunkach i zasadach
określonych w Umowie (Zamawiający za Oprogramowanie Aplikacyjne uznaje
również oprogramowanie otrzymane na bazie modyfikacji kodów źródłowych
Oprogramowania Standardowego);
Ośrodek Krajowy
Centrum serwerowe w oparciu, o które będzie zbudowana architektura systemu
SI PR na poziomie centralnym;
Ośrodki Regionalne
Element architektury systemu SI WCPR stanowiący pośredniczącą warstwę
serwerów
lokalnych
zapewniający
przyjmowania
zgłoszeń
oraz
zintegrowanej
łączności
w
ich
krytyczną
obsługi,
obiektach
w
funkcjonalność
na
których
potrzeby
w
zakresie
podsystemów
umiejscowieni
zostaną
Użytkownicy końcowi
Operator
Użytkownik Końcowy realizujący funkcję przyjęcia zgłoszenia w ramach
CPR/WCPR;
PRM
Państwowe Ratownictwo Medyczne;
PSP
Państwowa Straż Pożarna;
SWD
System Wspomagania Dowodzenia klasy dyspozytorskiej „czasu rzeczywistego”
wspomagającego w zakresie przyjęcia i obsługi wywołań alarmowych/zdarzeń;
Podmiot ratowniczy
Podmiot, o którym mowa w Rozporządzeniu Ministra Spraw Wewnętrznych
i Administracji z dnia 31 lipca 2009 r. w sprawie organizacji i funkcjonowania
centrów
powiadamiania
ratunkowego
oraz
wojewódzkich
centrów
powiadamiania ratunkowego;
LPR
Samodzielny
Publiczny
Zakład
Opieki
Zdrowotnej
Lotnicze
Pogotowie
Ratunkowe, pełniący w Systemie rolę Dysponenta.
System/SWD PRM
wraz z infrastrukturą sprzętową oraz zainstalowanym Oprogramowaniem
Standardowym;
SIM
System Informacji Medycznej;
SI PR
System Informatyczny Powiadamiania Ratunkowego;
SPR
System Powiadamiania Ratunkowego;
TM
Terminal
mobilny
-
przenośny
komputer
osobisty
stanowiący
element
wyposażenia karetek;
Utwór
Oprogramowanie Aplikacyjne oraz jego Modyfikacje, rozwiązania techniczne
przyjęte dla realizacji Systemu wraz z odnoszącą się dokumentacją, z
wyłączeniem
Oprogramowania
Standardowego
i
jego
Modyfikacji,
oraz
dokumentacja powykonawcza, stanowiące utwór w rozumieniu ustawy z dnia 4
lutego 1994 r. o prawie autorskim i prawach pokrewnych (Dz.U. z 2000 r. Nr
Oznacza podmiot korzystający z Systemu;
WCPR
Wojewódzkie Centrum Powiadamiania Ratunkowego;
Zamawiający
Centrum Projektów Informatycznych MSWiA;
Strona 4
80 poz. 904 ze zm.);
Użytkownik końcowy
Skrót/pojęcie
Definicja
Zgłoszenie
Wywołanie alarmowe przyjmowane przez Operatora w WCPR/CPR;
Zdarzenie
Zgłoszenie przekazane przez Operatora do Dyspozytora celem obsługi;
ZRM
Zespół Ratownictwa Medycznego.
Pozostałe pojęcia użyte w dokumencie należy rozumieć zgodnie z ich ogólnie przyjętym
znaczeniem.
3. Przedmiot zamówienia
Przedmiotem zamówienia jest
Wspomagania
Dowodzenia
budowa i wdrożenie ogólnokrajowego Systemu
Państwowego
Ratownictwa
Medycznego
(SWD
PRM).
Przedmiot zamówienia obejmuje:
1) opracowanie i dostarczenie Analizy i Projektu technicznego, w tym przeniesienie na
Zamawiającego autorskich praw majątkowych do Projektu technicznego,
2) Dostawę, Instalację i Konfigurację
Elementów Systemu niezbędnych do prawidłowego
funkcjonowania Systemu, w tym Instalację i
Konfigurację w
Lokalizacjach dostarczanego
przez Wykonawcę Oprogramowania na zapewnianych przez Zamawiającego 240 szt.
stanowiskach dostępowych oraz 240 szt. konsol dyspozytorskich zintegrowanej łączności, o
których mowa w rozdz. 5.8 i 5.9,
3) Dostawę i Instalację w Lokalizacjach dostarczanych w ramach Dostaw 32 szt. terminali
mobilnych (komputerów typu tablet) wraz ze stacjami dokującymi oraz drukarkami oraz 32
szt. urządzeń do pozycjonowania GPS i monitoringu karetek ZRM (urządzeń GPS), w tym
Instalację i Konfigurację dostarczanego przez Wykonawcę Oprogramowania,
4) udzielenie Zamawiającemu i MSWiA licencji na Oprogramowanie Standardowe, którego
producentem
jest
Standardowego
Wykonawca
oraz
oraz
zapewnienie
licencji
na
udzielenia
Modyfikacje
Zamawiającemu
tego
i
Oprogramowania
MSWiA
licencji
na
Oprogramowanie Standardowe, którego producentem nie jest Wykonawca oraz licencji na
Modyfikacje tego Oprogramowania Standardowego,
5) przeniesienie na Zamawiającego i MSWiA autorskich praw majątkowych do Oprogramowania
Aplikacyjnego oraz jego Modyfikacji, rozwiązania technicznego przyjętego dla realizacji
Systemu
wraz
z
odnoszącą
się
Dokumentacją,
z
wyłączeniem
Oprogramowania
Standardowego i jego Modyfikacji,
6) budowa oraz wdrożenie Systemu w Lokalizacjach wskazanych przez Zamawiającego wraz z
przeprowadzeniem testów Systemu,
7) opracowanie i dostarczenie Dokumentacji powykonawczej Systemu,
8) przeniesienie na Zamawiającego i MSWiA autorskich praw majątkowych do Dokumentacji,
9) przeprowadzenie Szkoleń,
10) świadczenie Serwisu gwarancyjnego na zasadach i w okresie określonym w § 11 Umowy,
GPS dostarczonych w ramach Dostaw,
Strona 5
11) zapewnienie usług APN na rzecz transmisji dla potrzeb 32 szt. terminali mobilnych i urządzeń
12) świadczenie w okresie Serwisu gwarancyjnego usług Nadzoru Autorskiego w wymiarze 5000
(pięć
tysięcy) roboczogodzin, w ramach którego Wykonawca wykonywał będzie prace
związane
z
modyfikacjami
Systemu
w
zakresie
funkcjonalno-użytkowym,
zgodnie
z
oczekiwaniami Zmawiającego oraz Użytkowników końcowych.
4.
Wymagania wobec przedmiotu zamówienia
W celu zapewnienia pożądanej jakości produktów i ich zgodności z oczekiwaniami Użytkownika
końcowego, wymagane jest wykonanie zamówienia z uwzględnieniem podziału na etapy, przy czym
termin realizacji przedmiotu zamówienia wynosi 10-mc od daty zawarcia umowy.
4.1.
Ogólne założenia SWD PRM
SWD PRM ma stanowić jeden z elementów systemu informatycznego działającego na
rzecz służb ratowniczych na terenie całego, z uwzględnieniem organizacji i podległości właściwej
dla PRM (architektura systemu informatycznego będzie wynikała z projektu technicznego
zaproponowanego przez Wykonawcę w trakcie realizacji umowy z uwzględnieniem wymaganego
poziomu
SLA
oraz
możliwości
wykorzystania
jednego
ośrodka
krajowego
oraz
do
16 ośrodków regionalnych). System zoptymalizuje proces zarządzania siłami i środkami
ratowniczym na terenie obsługiwanym przez Dyspozytorów. Zapewni sprawną koordynację
zdarzeń odbywających się na styku rejonów, obejmujących swoim zasięgiem więcej niż jeden
rejon lub też wymagają zaangażowania jednostek z sąsiednich rejonów (zdarzenie mnogie lub
masowe).
Ponadto będzie
umożliwiał bezgłosowe
przekazywanie informacji o zdarzeniach
bezpośrednio do zespołów wyjazdowych (ZRM) oraz prowadzenie korespondencji głosowej
zespołów
z
dyspozytornią
(Dysponentem).
Komunikacja
mobilna
pomiędzy
stanowiskami
dyspozytorskimi a terminalami mobilnymi, oraz urządzeniami GPS zainstalowanymi w karetkach
zostanie zrealizowana z wykorzystaniem APN zapewnianym przez Wykonawcę (za pośrednictwem
centralnego
z
punktu
wykorzystaniem
głosowa).
styku
konsol
OST112
wskazanego
dyspozytorskich
i
przez
serwerów
Zamawiającego),
komunikacyjnych
jak
również
(korespondencja
Wsparciem w zakresie obsługi zdarzeń będzie wizualizacja danych na mapach
cyfrowych udostępnionych z Centralnego Sytemu Mapowego GIS (moduł zapewniany przez
Zamawiającego, wykorzystujący mechanizmy WebService). Oprogramowanie będzie prezentować
na mapie numerycznej m.in. lokalizację pracujących zespołów, ich statusów, lokalizacje osób
wywołujących numery alarmowe, obszary działań podmiotów ratunkowych. Jednocześnie system
informatyczny będzie wspierał tworzenie grafików czasu pracy osób wchodzących w skład
zespołów wyjazdowych oraz tworzenie elektronicznych list obecności.
W celu usprawnienia procesu tworzenia dokumentacji medycznej, system informatyczny
umożliwi wypełnianie kart wyjazdowych na urządzeniach mobilnych w formie elektronicznej oraz
prowadzenie dokumentacji istotnej z punktu widzenia rozliczeń z NFZ. Komunikacja przewodowa
zostanie zrealizowana w oparciu o sieć OST112 zapewnianą przez Zamawiającego
ogólnokrajowa
w
technologii
IP/MPLS),
a
dostęp
do
systemu
realizowany
(sieć
będzie
z wykorzystaniem protokołów XML.
W
skład
Systemu
należy
zaliczyć
głównie
następującą
infrastrukturę
sprzętowo-
1. Aplikację SWD PRM, składającą się z co najmniej nw. modułów:
a. Moduł aplikacji dla potrzeb Dyspozytorów ZRM,
b. Moduł aplikacji dla potrzeb ZRM (TM oraz stanowisk dostępowych w MS ZRM),
Strona 6
programową:
c.
Moduł pomocniczy, składający się z:
Moduł szpitalny sił i środków,
Moduł analityczno-raportowy,
Moduł do rozliczeń z NFZ.
2. Oprogramowanie standardowe, w tym system operacyjny i oprogramowanie antywirusowe,
3. Zapewniane przez Zamawiającego, wojewódzkie serwery komunikacyjne (centra regionalne)
- 16 szt. (wraz centralą telefoniczna i systemem rejestracji korespondencji), stanowiska
dostępowe, konsole dyspozytorskie zintegrowanej łączności, radiotelefony.
4. Terminale mobilne wraz ze stacjami dokującymi, drukarki mobilne oraz urządzenia GPS .
5. Serwery systemowe (wraz z szafami) w tym: bazodanowe, aplikacyjne, kopii zapasowych,
DNS, terminali mobilnych, serwer do synchronizacji czasu urządzeń i systemów.
6. Sprzęt sieciowy dla potrzeb wdrożenia dostarczanych centrów przetwarzania danych.
Każde stanowisko dyspozytorskie będzie składało się z stanowiska dostępowego, jedno
lub dwumonitorowego, oraz konsoli dyspozytorskiej zintegrowanej łączności, komunikującej się
po protokole IP z jednym z 16 wojewódzkich serwerów komunikacyjnych.
W ramach wdrożenia SWD PRM zostanie wykorzystany jednolity w ramach SI PR
centralny system mapowy wraz z podsystemami AVL/APL, zapewniany przez Zamawiającego.
Po stronie SWD PRM zostanie zapewniony interfejs gwarantujący współpracę z tym systemem jak
również innymi systemami zewnętrznymi. Wymagane jest wdrożenie kompletnego rozwiązania
obsługującego niekwalifikowany podpis elektroniczny zgodny z PKI oraz standardem X.509
zapewniający uwierzytelnianie użytkowników końcowych za pomocą kart inteligentnych. Ponadto
System
zostanie
wyposażony
w
możliwość tworzenia
kopii
zapasowych
pozwalający
na
gromadzenie danych na dyskach taśmowych. W przypadku wystąpienia sytuacji awaryjnej,
konieczne jest umożliwienie przejęcia zadań do wyznaczonej jednostki PRM, również z możliwością
wskazania jednostki z innego województwa.
W ramach zamówienia Wykonawca dla potrzeb testowania ogólnokrajowego systemu
komunikacji mobilnej PRM dostarczy, zainstaluje i uruchomi w 32 karetkach ZRM TM wraz ze
stacjami dokującymi, drukarkami i urządzeniami GPS , jak również zapewni na czas trwania
gwarancji
wymaganą
usługę
APN
u
operatora
telekomunikacyjnego
sieci
komórkowej
(zamawiający w trakcie wykonania umowy wskaże format ramki w oparciu o który funkcjonować
będzie zapewniany przez jego podsystem AVL/AVP).
Poniżej przedstawiono diagram czynności dyspozytora SWD PRM oraz jego umiejscowienie
w ramach systemu informatycznego powiadamiania ratunkowego.
Dla potrzeb budowy i wdrożenia aplikacji informatycznych funkcjonujących w lokalizacji
CPR/WCPR oraz komórek organizacyjnych PSP, PRM, PSP oraz Policji, zakłada się następującą
Strona 7
strukturę organizacyjną SI PR:
uc struktura SI CPR i SI WCPR oraz SWD
SI CPR i SI WCPR
SWD
dane
Operator CPR
Dyspozytor
Koordynator
Operator WCPR
Rys. 1 – Struktura SI CPR i SI WCPR oraz SWD
Na diagramie poniżej przedstawiono główne role dla CPR/WCPR.
uc SI CPR i SI WCPR - głów ne role
SI CPR i SI WCPR
Decyzj e i w ytyczne
Wizualizacj a sytuacj i
Koordynator WCPR
Łączność i
komunikaty
Analizy i raporty
Operator
Obsługa zgłoszeń
Zgłaszaj ący
Zgłoszenie alarmow e
telefoniczne
Rys. 2 – Główne role w CPR /WCPR
Koordynatora zapewniająca w szczególności: przegląd bieżącej sytuacji w zakresie przyjęcia
zgłoszeń i statusów obsługi zdarzeń, monitorowanie ilości i typów zgłoszeń na obszarze
województwa oraz wymiany informacji i dyspozycji z innymi CPR.
Strona 8
Oprócz roli Operatora w ramach WCPR/CPR zaimplementowana zostanie funkcjonalność
Na diagramie poniżej przedstawiono zadania Dyspozytora realizującego obsługę zdarzeń
w ramach systemu SWD.
uc SWD
SWD
koordynacj a działań
«extend»
w ymiana danych
obsługa zgłoszeń i
zdarzeń
zarządzanie siłami
iśrodkami
GIS - w izualizacj a
sytuacj i
Dyspozytor
monitorow anie
zdarzeń, sił i
środków
zgłoszenie z
CPR/WCPR
analizy i raporty
Rys. 3 – Zakres roli Dyspozytora w ramach systemów klasy SWD
Na poziomie SWD PRM dodatkowo oprócz roli Dyspozytora w ramach niniejszego
zamówienia wymagane jest zaimplementowanie funkcjonalność Koordynatora (lekarz
koordynator/krajowy dyspozytor lotniczego pogotowania ratunkowego) zapewniającej
terenie całego kraju, dostęp do danych o siłach i środkach i stanie aktualnie
realizowanych zdarzeń, mechanizmy koordynacji i wymiany informacji.
Strona 9
w szczególności: monitorowanie działalności jednostek pogotowania ratunkowego na
Strona 10
Poniżej przedstawiono poglądowe powiązania systemowe oraz otoczenie SI PR.
5.
Wymagania szczegółowe
5.1
Wymagania funkcjonalne systemu SWD PRM
5.1.1
Moduł aplikacji dla potrzeb Dyspozytorów ZRM
Kod
Opis funkcjonalności
wymagania
F.SWDPRM.1
Umieszczanie
zdarzeń
na
liście
zdarzeń
oczekujących,
z
uwzględnieniem
identyfikatorów przydzielonych w SI CPR / SI WCPR (wyświetlany czas
oczekiwania zdarzenia na podjęcie interwencji z sygnalizacja przekroczenia
zadanej wartości czasu oczekiwania).
F.SWDPRM.2
Porządkowanie wyświetlania zdarzeń według zadanych parametrów (np. czas
przyjęcia, Dyspozytor, kategoria zdarzenia).
F.SWDPRM.3
Wspomaganie obsługi zdarzenia poprzez:

różne kolory zdarzeń w zależności od aktualnego statusu (jednakowe
w skali kraju, bez możliwości zmiany przez użytkowników),

przekazanie do ZRM oraz LPR dyspozycji obsługi zdarzenia,

możliwość przyporządkowania i odwołania do obsługi zdarzenia więcej niż
jedną karetkę,

wyświetlanie w postaci listy aktualnych zasobów (z bieżącymi statusami
np. wolny, zajęty, w drodze),

manualne aktualizowanie bieżących statusów zasobów, obsługiwanych
zdarzeń,

manualne przypisanie zasobów do obsługi zdarzenia,

wskazanie potencjalnych zasobów do obsługi zdarzenia według wyboru
kryteriów „filtrowania” (np. status, typ
i wyposażenie karetki, rodzaj
jednostki PRM – możliwość wyboru kilku kryteriów),

kategoryzowanie zdarzeń.
F.SWDPRM.4
Możliwość przeglądu historii obsługi zdarzeń zakończonych.
F.SWDPRM.5
Dostęp do danych archiwalnych z okresu 20 lat w trybie on-line, z Systemu oraz
zewnętrznych systemów informatycznych SIM w oparciu o uniwersalny interfejs
w technologii web service, w zakresie Dokumentacji medycznej PRM (w ramach
niniejszego
Zamówienia
Wykonawca
dostarczy
infrastrukturę
serwerową
umożliwiającą gromadzenie Dokumentacji medycznej PRM przez okres 5 lat).
Parametr wyszukiwania danych archiwalnych stanowią istotne parametry możliwe
do zarejestrowania w zgłoszeniu i zdarzeniu, między innymi data, miejsce, dane
poszkodowanego, dane zgłaszającego, typ zdarzenia oraz dodatkowo każdy
parametr możliwy do zarejestrowania w dokumentacji medycznej.
F.SWDPRM.6
Dostęp do danych archiwalnych w zakresie nagrań i pozostałych informacji
gromadzonych w Systemie z okresu 1 roku w systemie on-line oraz z okresu 20
lat w systemie backupu.
do zarejestrowania w zgłoszeniu i zdarzeniu, między innymi data, miejsce, dane
poszkodowanego, dane zgłaszającego, typ zdarzenia.
F.SWDPRM.7
Informowanie
Dyspozytora
o
zmianach
w
już
obsługiwanych
zdarzeniach
Strona 11
Parametr wyszukiwania danych archiwalnych stanowią istotne parametry możliwe
Kod
wymagania
wynikających z dodatkowych informacji zebranych przez operatorów.
F.SWDPRM.8
Możliwość przekazywania obsługi zdarzeń innemu Dyspozytorowi, dyspozytorowi
LPR (w dowolnym momencie procesu obsługi zdarzenia), również do innego
województwa.
F.SWDPRM.9
Dostępna na bieżąco informacja o pozostających w dyspozycji zasobach siłach
i środkach, ich statusie oraz lokalizacji, również siłach i środkach pozostałych
Dysponentów w ramach Systemu.
F.SWDPRM.10
Wizualizacja
na
mapie
wszystkich
ZRM
z
możliwością
konfiguracji,
w szczególności: pokazuj tylko własne ZRM dyspozytora, pokazuj własne ZRM
dysponenta, pokazuj własne i obce ZRM znajdujące się w makroregionie, pokazuj
własne i sąsiednie ZRM.
F.SWDPRM.11
Obsługa różnych typów wyjazdów.
F.SWDPRM.12
Rozsyłanie komunikatów wraz z załącznikami (np. pliki pdf, jpg) pomiędzy
Dyspozytorami (komunikaty okólnikowe).
F.SWDPRM.13
Możliwość zakończenia obsługi zdarzenia na dowolnym etapie (momencie)
obsługi pomimo braku pełnych danych i jego modyfikacji (uzupełnienia) po
zakończeniu.
F.SWDPRM.14
Możliwość kontroli czasu pracy Dyspozytora, ilość prowadzonych zdarzeń, czasu
obsługi zdarzenia.
F.SWDPRM.15
Analizy czasu obsługi zdarzeń.
F.SWDPRM.16
Historia
jednostki
z
chronologiczną
listą
realizowanych
zdarzeń
własnych
i zleconych (z czasem trwania) – Książka Pracy Dyspozytora, wraz z możliwością
jej wydruku
F.SWDPRM.17
Rejestracja danych o zasobach ratowniczych.
F.SWDPRM.18
Możliwość
a
wymiany
informacji
Operatorami/Koordynatorami
PRM
w
pomiędzy
czasie
Dyspozytorami
rzeczywistym,
z
użyciem
komunikatów aplikacyjnych.
F.SWDPRM.19
Automatyczne generowanie propozycji dyspozycji sił i środków dla obsługi
określonej kategorii zdarzeń (mechanizmu optymalizacji wsparcia dysponowania
sił i środków oparty w co najmniej następujące czynniki: odległość, kategoria
urazu, czas dotarcia, jednostkowych kosztów transportu, wyposażenie techniczne
i skład załogi).
F.SWDPRM.20
Modyfikacja
przez
Dyspozytora
automatycznie
generowanych
propozycji
dyspozycji sił i środków.
F.SWDPRM.21
Prezentacja na mapie cyfrowej lokalizacji dostępnych i biorących udział w akcji sił
i środków, statusów, lokalizacji osoby wywołującej zgłoszenie.
F.SWDPRM.22
Możliwość elektronicznego wprowadzania danych w oparciu do predefiniowane
formularze zgodne ze wzorami określonymi dla Dokumentacji medycznej PRM.
F.SWDPRM.23
Możliwość zmiany z poziomu aplikacji statusu dostępnych i biorących udział
F.SWDPRM.24
Możliwość nawiązania połączenia telefonicznego z poziomu aplikacji.
F.SWDPRM.25
Prowadzenie rozliczeń apteki zespołu wyjazdowego, w zakresie:

zarządzanie stanem apteki,

informowanie o stanie ważności leków,
Strona 12
w akcji sił i środków.
Kod
wymagania

rozliczenie apteki po zakończeniu dyżuru,

integracja ze szpitalnym systemem apteki.
F.SWDPRM.26
Administrowanie uprawnieniami użytkowników.
F.SWDPRM.27
Dodawanie/usuwanie stanowisk dostępowych.
F.SWDPRM.28
Utrzymywanie danych słownikowych/bibliotek.
F.SWDPRM.29
Automatyczna rejestracja działań realizowanych przez użytkowników (kto, kiedy,
co).
F.SWDPRM.30
Zapewnienie współpracy z centralnym systemem mapowym (usługi WebService).
F.SWDPRM.31
Identyfikacja numeru telefonu dzwoniącego zintegrowana z bazą teleadresową.
F.SWDPRM.32
Dostęp do książki telefonicznej, możliwość wywoływania połączeń bezpośrednio
z książki telefonicznej.
F.SWDPRM.33
Usprawnienie
telefonów,
komunikacji
zestawianie
poprzez
połączeń
zautomatyzowanie
konferencyjnych,
wybierania
wsparcie
numerów
przekazywania
połączeń.
F.SWDPRM.34
Dostęp do zasobów systemu za pomocą specjalizowanych konsol dyspozytorskich
zainstalowanych
na
stanowiskach
pracy
(zasobów
telefonii
przewodowej
i radiowej).
F.SWDPRM.35
Zapamiętywanie dla każdej zarejestrowanej korespondencji zestawu metadanych
obejmujących co najmniej: czas rozpoczęcia i czas zakończenia, numery
telefonów uczestniczących w korespondencji, identyfikatorów stacji bazowych
uczestniczących
w
korespondencji,
kanałów
na
których
była
prowadzona
korespondencja.
F.SWDPRM.36
Odsłuch rozmów z funkcją: przewijania, pauza, stop.
F.SWDPRM.37
Przeszukiwanie rozmów w oparciu zadany: okres czasu, identyfikator, „znacznik”.
F.SWDPRM.38
Automatyczne powiązanie zarejestrowanych rozmów ze zdarzeniami.
F.SWDPRM.39
Pełna dokumentacja obsługi zdarzeń w zakresie rejestracji wszystkich kanałów
komunikacji.
F.SWDPRM.40
Przekazanie identyfikatora zdarzenia jako znacznika do modułu rejestracji
korespondencji, jeśli zgłoszenie przyjmowane jest telefonicznie.
F.SWDPRM.41
Przekazanie identyfikatora zdarzenia jako znacznika do modułu rejestracji
korespondencji, jeśli prowadzona rozmowa dotyczy danego (zarejestrowanego
wcześniej) zgłoszenia.
F.SWDPRM.42
Możliwość odsłuchania treści rozmów telefonicznych i korespondencji radiowej
związanych z danym zdarzeniem.
F.SWDPRM.43
Dwustronna komunikacja z terminalami mobilnymi zapewniająca:

przekazywanie statusów oraz potwierdzeń,

przesyłanie i odbieranie wiadomości tekstowych (komunikator tekstowy),

przekazywanie danych o zleceniach wyjazdów oraz niezbędnych dla
tworzenia i archiwizacji Dokumentacji medycznej PRM.
F.SWDPRM.44
Dostęp do biblioteki regulaminów, instrukcji i przepisów. W ramach realizacji
przedmiotu zamówienia należy dostarczyć przestrzeń dyskową dla potrzeb
F.SWDPRM.45
Gromadzenie informacji o trasie przejazdu danego pojazdu, łącznie z prędkością,
postojami, statusami i stanem czujników pojazdu.
F.SWDPRM.46
Możliwość odtwarzania tras wybranych pojazdów, łącznie z prędkościami,
Strona 13
biblioteki w wielkości co najmniej 1TB.
Kod
wymagania
postojami,
statusami
i
stanem
czujników
pojazdu
(dla
wybranego
pojazdu/kierowcy w zadanym czasie).
F.SWDPRM.47
Definiowanie wyposażenia pojazdów i grup pojazdów.
F.SWDPRM.48
Proces przydzielania i zarządzania ID pojazdów.
F.SWDPRM.49
Elektroniczna karta zlecenia wyjazdu zespołu ratownictwa medycznego, zgodna z
Dokumentacją medyczną PRM, wraz z możliwością jej przekazania do ZRM.
F.SWDPRM.50
W przypadku zgłoszeń alarmowych kierowanych bezpośrednio do Dysponenta
ZRM, System musi zapewnić rejestrację zgłoszenia alarmowego za pomocą
standardowego
przyjęcia
arkusza
zgłoszenia,
przyjęcia
zgłoszenia
wykorzystywanym
w
(arkusz
zgodny
CPR/WCPR),
w
z
arkuszem
szczególności
w zakresie:

Numer telefonu (dane pozyskane z PLI CBD),

Imię,

Nazwisko,

Lokalizacja zgłaszającego,

Lokalizacja miejsca zdarzenia,

Opis zdarzenia,

Kategoria zdarzenia.

Dane poszkodowanego.

Uszczegółowienie lokalizacji miejsca zdarzenia poprzez wskazanie punktu
na mapie.
F.SWDPRM.51
Uniwersalny interfejs umożliwiający wymianę danych z systemami zewnętrznymi
względem SWD PRM, w szczególności systemami SI CPR, SI WCPR, systemami
wytwarzanymi przez Centrum Systemów Informacyjnych Ochrony Zdrowia,
systemami informatycznymi LPR, w oparciu o komunikaty w formacie XML.
F.SWDPRM.52
Możliwość
wymiany
informacji
pomiędzy
Dyspozytorami
a
Operatorami
CPR/WCPR w czasie rzeczywistym z użyciem komunikatów aplikacyjnych.
F.SWDPRM.53
Przekazanie
przez
Dyspozytora
do
Operatora
CPR/WCPR
potwierdzenia
o przyjęciu informacji o zdarzeniu oraz statusu obsługi zdarzenia w szczególności
w zakresie: przyjęcie, odmowa, w realizacji, ZRM na miejscu.
F.SWDPRM.54
Wspieranie działań związanych z tworzeniem grafików czasu pracy osób
pracujących w zespołach wyjazdowych oraz tworzenie elektronicznych list
obecności.
F.SWDPRM.55
Możliwość rejestrowania i modyfikowania grafików Dyspozytorów oraz składów
ZRM na podstawie jednego wspólnego szablonu. Grafiki będą wykorzystywane do
automatycznego uzupełniania Dokumentacji medycznej PRM.
F.SWDPRM.56
Interfejs umożliwiający współpracę z systemami informatycznymi dysponenta w
szczególności z systemem kadrowo-płacowym i finansowo-księgowym.
F.SWDPRM.57
Przekazywanie do Koordynatora PRM informacji o siłach i środkach dostępnych na
obszarze działania danego Dysponenta, ich rozmieszczeniu oraz o stanie
aktualnie realizowanych zadań.
Automatyczne otwieranie formatki zgłoszenia skojarzonej z przełączaną rozmową
telefoniczną do dyspozytora medycznego.
Strona 14
F.SWDPRM.58
5.1.2
Moduł aplikacji dla potrzeb ZRM
Kod
wymagania
F.SWDPRM.59
Zapewnienie
interfejsu
umożliwiającego
wymianę
informacji
pomiędzy
Dysponentem a ZRM, w szczególności w zakresie elektronicznej karty zlecenia
wyjazdu
zespołu
ratownictwa
medycznego,
karty
medycznych
czynności
ratunkowych oraz karty drogowej.
F.SWDPRM.60
Uzupełnienie
dokumentacji
otrzymanej
od
Dysponenta,
w
szczególności
elektronicznej karty zlecenia wyjazdu zespołu ratownictwa medycznego, karty
medycznych czynności ratunkowych i karty drogowej (karty drogowe tworzą
członkowie ZRM, a kontroluje i rozlicza je Dysponent) z funkcją walidacji pól
wymaganych.
F.SWDPRM.61
Automatyczna
wizualizacja
na
mapie
własnej
pozycji
pojazdu
i
pozycji
przyjętego zgłoszenia, oraz wyznaczenia trasy przejazdu z wykorzystaniem
ogólnie
dostępnego,
standardowego
oprogramowania
do
nawigacji
samochodowej.
F.SWDPRM.62
Administrowanie uprawnieniami użytkowników.
F.SWDPRM.63
Dodawanie/usuwanie stanowisk dostępowych.
F.SWDPRM.64
Automatyczna rejestracja działań realizowanych przez użytkowników (kto,
kiedy, co?).
F.SWDPRM.65
Zdalny dostęp z poziomu karetki (terminala mobilnego) do bazy wiedzy, np.
katalog leków wraz z ich dawkowaniem, procedury postępowania. W ramach
realizacji przedmiotu zamówienia należy dostarczyć przestrzeń dyskową dla
potrzeb biblioteki w wielkości co najmniej 1TB.
F.SWDPRM.66
Wypełnianie
kart
zlecenia
wyjazdu
zespołu
ratownictwa
medycznego
wyjazdowych, kart medycznych czynności ratunkowych oraz kart drogowych na
urządzeniach mobilnych w formie elektronicznej (dane zebrane na urządzeniach
mobilnych będą stanowić podstawę do rozliczenia z NFZ czy tworzenia statystyk
realizowanych przez służbę pogotowia ratunkowego), wraz z możliwością
wydruku.
F.SWDPRM.67
Potwierdzanie
obecności
na
elektronicznej
liście
obecności,
określającej
jednocześnie skład ZRM.
F.SWDPRM.68
Przesyłanie statusów ZRM do Dyspozytora.
F.SWDPRM.69
Aplikacja musi być przystosowana w wersji do pracy na terminalu mobilnym
(bez konieczności używania rysika) oraz w wersji do pracy stanowisku
dostępowym w MS ZRM.
Możliwość pracy lokalnej w trybie Off Line, w szczególności w zakresie tworzenia
Dokumentacji medycznej PRM.
Strona 15
F.SWDPRM.70
5.1.3
Moduł pomocniczy
5.1.3.1 Moduł szpitalny sił i środków
Kod
wymagania
F.SWDPRM.71
Możliwość rejestrowania danych na poziomie szpitali, istotnych z punktu widzenia
działania Dyspozytora.
F.SWDPRM.72
Prowadzenie ewidencji dla potrzeby SWD PRM w zakresie wolnych miejsc
szpitalnych ze wskazaniem co najmniej: nazwa szpitala, oddział, ilość wolnych
miejsc.
F.SWDPRM.73
Mechanizmy rozliczalności użytkownika wprowadzającego dane (logi systemowe).
F.SWDPRM.74
Automatyczne
generowanie
propozycji
szpitala
z
wolnymi
miejscami
umożliwiającymi przyjęcia pacjenta o określonej kategorii urazu oraz wizualizacja
na mapie danego szpitala wraz wyznaczeniem trasy przejazdu (współpraca ze
standardowym oprogramowaniem do nawigacji samochodowej zainstalowanym
na terminalu mobilnym).
F.SWDPRM.75
Możliwość aktualizacji danych przez uprawnionego użytkownika Systemu.
F.SWDPRM.76
Zapewnienie interfejsu umożliwiającego automatyczne pobieranie danych.
5.1.3.2Moduł analityczno-raportowy
Kod
wymagania
F.SWDPRM.77
Dostęp do danych wykorzystywanych w pozostałych modułach Systemu.
F.SWDPRM.78
Definiowanie typów źródeł danych za pomocą graficznego edytora zapytań
(możliwość określanie frazy WHERE, ORDER BY, wyrażeń).
F.SWDPRM.79
Typy źródeł danych dostarczają zdefiniowane przez użytkownika dane.
F.SWDPRM.80
Określenie dla źródeł: filtrów (typu filtru, wykorzystanie operatorów logicznych)
oraz parametrów źródła (parametry wejściowe dla raportu).
F.SWDPRM.81
Dane zwracane przez zdefiniowane źródło prezentowanie w formie tabeli lub
wykresu.
F.SWDPRM.82
Możliwość przedstawienia danych z wykorzystaniem edytora graficznego wraz
z funkcją wydruku.
F.SWDPRM.83
Eksportowanie zdefiniowanych szablonów i dokumentów. Możliwe formaty: doc,
PDF, html, XLS (z wyjątkiem szablonu wykresu) i CSV (z wyjątkiem szablonu
wykresu).
F.SWDPRM.84
Możliwość eksportowania danych do XLS całościowo – bez podziału na strony lub
tabele i innego formatowania.
F.SWDPRM.85
Raportowanie administracyjne
w ramach zdefiniowanej
puli raportów
(20
szablonów raportów uzgodnionych z Zamawiającym).
Możliwość generowania raportów dotyczących eksploatacji pojazdów (ilość
przejechanych kilometrów, ilość zużytego paliwa itd.).
Strona 16
F.SWDPRM.86
5.1.3.3Moduł do rozliczeń z NFZ
Kod
wymagania
F.SWDPRM.87
Import danych z pozostałych modułów Systemu.
F.SWDPRM.88
Zapewnienie rozliczalności z NFZ wg wytycznych NFZ
przez cały okres
serwisowy.
F.SWDPRM.89
Zapewnienie funkcjonalności realizującej weryfikację importowanych danych
i zapis tylko tych poprawnych. Dla każdego niezweryfikowanego świadczenia
musi być wyświetlana informacja o błędzie z możliwością zapisania do pliku
formatu *xls.
F.SWDPRM.90
Dostęp do modułu przydzielany administracyjnie.
F.SWDPRM.91
Moduł musi realizować wysyłanie komunikatów statystycznych i rozliczeniowych
do NFZ w aktualnie obowiązującym formacie XML.
F.SWDPRM.92
Wczytywanie raportów zwrotnych oraz przegląd błędów wskazanych przez z NFZ.
W przypadku błędów wskazanych przez NFZ, zapewnienie ponownego importu
zmienionych danych.
F.SWDPRM.93
Wystawianie faktur i korekt zgodnych z szablonami przysłanymi w odpowiedzi do
raportów rozliczeniowych oraz drukowanie sprawozdania finansowego.
5.2
Wymagania niefunkcjonalne SWD PRM
5.2.1
Wymagania ogólne
Kod
wymagania
NF.SWDPRM.1
Podsystem Zintegrowanej Łączności systemu SWD PRM zostanie zrealizowany
poprzez rozbudowę Podsystemu Zintegrowanej Łączności systemu SI WCPR
metodą prototypowania i testowania poprawek w co najmniej 3 lokalizacjach
wskazanych przez Zamawiającego, w tym Dysponent, MS ZRM oraz ZRM
NF.SWDPRM.2
Podsystem Zintegrowanej
Łączności
systemu
SWD PRM ma
obejmować
połączenia telefoniczne oraz łączność radiową w oparciu o lokalne i zdalne
stacje bazowe.
NF.SWDPRM.3
Stanowiska użytkowników końcowych systemu SWD PRM będą zlokalizowane
w siedzibach CPR/WCPR, w siedzibie Dysponenta oraz wskazanych karetkach.
NF.SWDPRM.4
Podsystem Zintegrowanej Łączności systemu SI WCPR obsługuje połączenia
telefoniczne oraz łączność radiową w oparciu o lokalne i zdalne stacje bazowe.
NF.SWDPRM.5
Wizualizacja danych na stanowisku dowodzenia w oparciu o dwa monitory
w ramach stanowiska dostępowego oraz dodatkowy (trzeci) monitor w ramach
konsoli dyspozytorskiej zintegrowanej łączności.
NF.SWDPRM.6
Modułowa budowa aplikacji (dostęp do modułów uzależniony od posiadanych
Moduł kopii zapasowych zrealizowany z użyciem dedykowanych serwerów
fizycznych i podłączonych do nich bibliotek taśmowych zapewnianych przez
Zamawiającego)
–
z
wykorzystaniem
oprogramowania
klasy
Enterprise
Strona 17
przez użytkownika końcowego poziomu uprawnień).
NF.SWDPRM.7
Kod
wymagania
z nielimitowanym skalowaniem i partycjonowaniem
NF.SWDPRM.8
Każdy
z
serwer
kopii
zapasowych
wyposażony
min.
w
1
procesor
czterordzeniowy, 8GB RAM oraz 2TB przestrzeni dyskowej z możliwością
rozbudowy.
NF.SWDPRM.9
Serwery pracujące w kastrze niezawodnościowo - wydajnościowym
NF.SWDPRM10
Sterowanie funkcjami za pomocą skrótów klawiszowych.
NF.SWDPRM11
W
przypadku
awarii
stacji
roboczej
obsługa
powinna
zostać
przejęta
automatycznie przez uprzednio określone stanowisko innego Dyspozytora.
NF.SWDPRM12
Wymagania niefunkcjonalne dotyczące rozmieszczenia infrastruktury sprzętowej
będą wynikały z zaproponowanej przez wykonawcę aplikacji w ramach projektu
technicznego architektury Systemu, uwzględniającej mechanizmy replikacji
danych oraz trójwarstwową architekturę klient-serwer.
NF.SWDPRM13
Komunikacja (synchroniczna) pomiędzy WCPR a systemami dziedzinowymi
służb (systemy klasy SWD) zrealizowana w oparciu o technologię Web-Service
i komunikację w formacie XML.
NF.SWDPRM14
Ergonomia
GUI
dostosowana
do
maksymalnego
skrócenia
procesu
wprowadzania danych.
NF.SWDPRM15
Część kliencka rozwiązania w technologii grubego klienta.
NF.SWDPRM16
System posiadać będzie wydzielone środowisko produkcyjne, developerskie
oraz
szkoleniowo-testowe.
sprzętowo-programowej
(4
Wymagane
stanowiska
jest
dostarczenie
developerskie
oraz
infrastruktury
50
stanowisk
szkoleniowych) oraz licencji niezbędnych do prawidłowego funkcjonowania
każdego ze środowisk.
NF.SWDPRM17
Interfejs użytkownika w języku polskim.
NF.SWDPRM18
Zapewnienie architektury rozwiązania zapewniającej niezawodność systemu na
wymaganym poziomie SLA.
NF.SWDPRM19
Zapewnienie do końca roku 2013 usług APN na rzecz transmisji dla potrzeb 32
szt. terminali mobilnych i dostarczanych urządzeń GPS
NF.SWDPRM20
Przyjęte rozwiązanie musi pozwalać na wdrożenie logiki biznesowej aplikacji
w oparciu o zewnętrzną szynę komunikacyjną (wymiany informacji).
NF.SWDPRM21
Zaproponowane
przez
Wykonawcę
rozwiązanie
musi
być
kompatybilne
z zapewnianymi przez Zamawiającego stanowiskami dostępowymi (stanowiska
dostępowe
wyposażone
w
karty
mikroprocesorowe
oraz
czytniki
kart
mikroprocesorowych) oraz konsolami dyspozytorskimi zintegrowanej łączności
o minimalnych wymaganiach przedstawionych w pkt 5.5 i 5.6.
NF.SWDPRM22
Mechanizmy zapewniające możliwość zdalnego upgrade-u oprogramowania oraz
automatyczna dystrybucja powiadomień o nowych wersjach systemu
Wykonawca zobowiązany jest do umieszczenia na dostarczonej infrastrukturze
sprzętowej
oznaczeń
zgodnych
z
„Zasadami
promocji
projektów
dla
beneficjentów Programu Operacyjnego Infrastruktura i Środowisko 2007-2013”
oraz „Przewodnikiem w zakresie promocji projektów finansowanych w ramach
Programu
Operacyjnego
Innowacyjna
Gospodarka,
2007-2013
dla
beneficjentów i instytucji zaangażowanych we wdrażanie programu”, jak
również wytycznymi „Strategii komunikacji Funduszy Europejskich w Polsce w
ramach Narodowej Strategii Spójności na lata 2007-2013” rozdział 8.2, tzn.
Strona 18
NF.SWDPRM23
Kod
wymagania
wszelka dostarczona w ramach realizacji przedmiotu Zamówienia dokumentacja
musi
być
opatrzona
logotypami:
Narodowa
Strategia
Spójności,
Unia
Europejska z odniesieniem słownym do Europejskiego Funduszu Rozwoju
Regionalnego, logo Beneficjenta. Szablony oznaczeń zostaną przekazane
Wykonawcy przez Zamawiającego.
5.2.2
Bezpieczeństwo
Pojęcia Poufność, Integralność, Rozliczalność i Niezaprzeczalność są rozumiane zgodnie z normą
PN-I-02000:2002 Technika Informatyczna – zabezpieczenia w systemach informatycznych.
5.2.3
Poufność
Kod
wymagania
NFP.1
Zaimplementowanie funkcjonalności umożliwiającej przetwarzanie w Systemie
informacji wrażliwych zgodnie z wymaganiami określonymi w odpowiednich aktach
prawnych, w szczególności ustawie z dnia 29 sierpnia 1997 r. o ochronie danych
osobowych (Dz. U. z 2002 r. Nr 101, poz. 926) oraz rozporządzenia Rady
Ministrów z dnia 28 października 2005 r. o minimalnych wymaganiach dla
systemów teleinformatycznych (Dz. U. z 2005 r. Nr 212, poz. 1766).
NFP.2
Zaimplementowanie mechanizmów umożliwiających dostęp do Systemu wyłącznie
po jednoznacznym zidentyfikowaniu użytkownika końcowego przeprowadzonym
w ramach procesu uwierzytelnienia.
NFP.3
Zaimplementowanie mechanizmów zapewniających przechowywanie i przesyłanie
haseł użytkowników wyłącznie w postaci zaszyfrowanej.
NFP.4
Zaimplementowanie
mechanizmu
kontroli
uprawnień
opartego
na
rolach,
umożliwiającego kontrolę poziomu dostępu do Systemu każdego użytkownika
zarówno
i
w
zakresie
korzystania
z
jego
dostępu
do
danych
funkcjonalności.
przetwarzanych
System
uprawnień
w
Systemie
musi
jak
umożliwić
ograniczenie dostępu wyłącznie do takich danych oraz takiego zakresu funkcji, jaki
jest mu niezbędny do wykonania zadań wynikających z zakresu obowiązków.
NFP.5
W przypadku szyfrowania wymagane jest zaimplementowanie mechanizmów
kryptograficznych
opartych
na
uznanych
standardach
otwartych.
Moc
wykorzystanych mechanizmów nie może być mniejsza od mocy zapewniana przez
3DES, AES-128, RSA-1024, SHA-1.
NFP.6
Zabezpieczenie
a
serwerami
transmisji
danych
umieszczonymi
w
wrażliwych
węzłach
pomiędzy
stacją
technologicznych
użytkownika
oraz
pomiędzy
współpracującymi systemami. Poziom zabezpieczenia transmisji nie może być
bitów.
NFP.7
Opracowanie polityki bezpieczeństwa, zgodnej przepisami prawa wskazanymi w
pkt. 5.12, oraz stosownych instrukcji bezpieczeństwa.
Strona 19
mniejszy od poziomu zapewnianego przez protokół TLS z kluczem o długości 128
5.2.4
Integralność
Kod
wymagania
NFI.1
Zaimplementowanie
mechanizmów
zapewniających
integralność
danych
wykorzystywanych przy obsłudze zdarzeń w trakcie ich przesyłania pomiędzy SWD
PRM a innymi systemami współpracującymi z nim w ramach SI PR oraz SPR.
Poziom
zapewnienia
integralności
nie
może
być
mniejszy
od
poziomu
integralność
danych
zapewnianego przy użyciu protokołu TLS z kluczem 128 bit.
NFI.2
Zaimplementowanie
mechanizmów
zapewniających
wykorzystywanych przy obsłudze zdarzeń i zgłoszeń w trakcie ich przesyłania
pomiędzy węzłem technicznym systemu a stacją roboczą użytkownika. Poziom
zapewnienia integralności nie może być mniejszy od poziomu zapewnianego przy
użyciu protokołu TLS z kluczem 128 bit.
5.2.5
Rozliczalność
Kod
wymagania
NFR.1
Zaimplementowanie
mechanizmów
umożliwiających
rozliczalność
działań
użytkowników końcowych, które są bezpośrednio związane z obsługą zdarzeń.
Wymagane jest rejestrowanie, co najmniej następujących informacji:
NFI.2

data i czas przyjęcia zdarzenia do obsługi,

rodzaj zdarzenia,

data i czas zadysponowania sił i środków,

identyfikator użytkownika,

identyfikator stacji użytkownika.
Zaimplementowanie
mechanizmów
umożliwiających
rozliczalność
działań
administracyjnych związanych z nadawaniem i odbieraniem uprawnień do tych
usług realizowanych przez system, które są bezpośrednio związane z obsługą
zgłoszeń i zdarzeń.
5.2.6
Niezaprzeczalność
Kod
wymagania
NFN.1
Zaimplementowanie mechanizmów umożliwiających niezaprzeczalność działań
związanych z przyjmowaniem i obsługą zdarzeń w ramach SWD PRM.
5.2.7
Ciągłość działania
Kod
NFC.1
Zaimplementowanie
mechanizmów
umożliwiających
uruchomienie
Systemu
zgodnie z zaakceptowanym przez Zamawiającego projektem technicznym.
Strona 20
wymagania
NFC.2
Optymalizacja architektury Systemu pod kątem maksymalnego wyniesienia
infrastruktury sprzętowo-programowej do Ośrodka Krajowego, z zachowaniem
wymaganych poziomów dostępności Systemu.
5.2.8
Dostępność
Kod
wymagania
NFD.1
Zaimplementowanie
usług
Systemu
mechanizmów
umożliwiających
wykorzystywanych
do
obsługi
zapewnienie
zgłoszeń
i
dostępności
zdarzeń
liczonej
w okresach miesięcznych indywidualnie dla każdego ośrodka:
a) dla
Ośrodka
Krajowego
SLA
na
poziomie
99,99%
(niedostępność
miesięczna 4,38 min. / ośrodek),
b) dla każdego Dysponenta na poziomie 99% (niedostępność miesięczna 7,3h
/ Dysponent)
SLA Dysponenta liczone jest jako suma czasu trwania niedostępności Systemu
spowodowanej Awariami Krytycznymi, przy czym okna serwisowe związane
z konserwacją/rekonfiguracją Systemu nie podlegają uwzględnianiu w obliczeniu
SLA (termin i zakres prac realizowanych w ramach okna serwisowego wymaga
uzyskania przez Wykonawcę uprzedniej akceptacji Zamawiającego).
NFD.2
Zaimplementowanie
mechanizmów
umożliwiających
użytkownikom
kontynuację
w
awarii
z
pracy
przypadku
jednego
węzłów
Systemu
technicznych
z wykorzystaniem usług świadczonych przez inny węzeł.
NFD.3
Zaimplementowanie mechanizmów umożliwiających przejęcie obsługi zgłoszeń
alarmowych przez innego Dysponenta.
5.2.9
Pojemność i Wydajność
Kod
wymagania
NFPW.1
System
przystosowany
do
przyjęcia
i
obsługi
do
1 mln
zdarzeń
rocznie
z możliwością późniejszej rozbudowy do co najmniej 3 mln rocznie (mechanizmy
skalowalności rozwiązania).
NFPW.2
Zaimplementowanie mechanizmów umożliwiających obsługę zwiększonej liczby
zgłoszeń w okresach szczytów, przy założeniu, iż liczba ta nie przekroczy 10-cio
krotności średniej liczby zgłoszeń wyliczonej na podstawie ww. wymagania.
NFPW.3
Zaimplementowanie mechanizmów umożliwiających obsługę do co najmniej 800
równoczesnych użytkowników.
5.3
Minimalne wymagania na terminale mobilne
W ramach zamówienia wymagane jest wyposażenia karetek w zestaw urządzeń pozwalających na
Zestaw musi zawierać co najmniej: terminal mobilny, drukarkę, urządzenie GPS o minimalnych
parametrach określonych w kolejnych rozdziałach.
Strona 21
realizowanie wymaganej funkcjonalności.
Wymagania ogólne dla zestawu urządzeń wchodzących w wyposażenie karetki (w tym: terminala
mobilnego, drukarki, urządzeń GPS).
Lp.
Parametr
Wymagana wartość parametru
1.
Napięcie zasilania każdego z
urządzeń
12 V DC
2.
Sumaryczna maksymalna moc
pobierana przez zestaw wszystkich
urządzeń
max. 200 W
3.
Łączność bezprzewodowa
Wifi 802.11 b/g/n, Bluetooth 2.0 EDR, moduł 3G GPRS
EDGE, slot na kartę SIM operatora komórkowego
4.
Minimalny zakres temperatury
pracy każdego z urządzeń
5.
od -20 do +60 stopni Celsjusza
Montaż urządzeń w sposób zapewniający utrudniony
dostęp osobom postronnym oraz nieutrudniający
swobodnej pracy zespołu karetki
Funkcje montażu
6.
Dane przesyłane przez zestaw
urządzeń
7.
Normy i certyfikaty





Współrzędne geograficzne obiektu.
Wysokość obiektu nad poziomem morza.
Prędkość chwilową obiektu.
Data i godzina pomiaru.
Stan odbiornika status włączenia/wyłączenia
stacyjki (silnika).
 Poziom paliwa w zbiorniku.
 Status włączenia/wyłączenia sygnalizacji.
Zgodność z dyrektywą 104/2004/WE lub równoważną
(zgodności elektromagnetycznej)
Wymagania dla terminalu mobilnego (wymagania minimalne)
Lp.
Parametr
1.
Procesor
Co najmniej 1.06 GHz
2.
Pamięć operacyjna
Min. 2 GB
3.
Dysk twardy
pojemność min 32 GB
4.
Dźwięk
Wbudowany mikrofon z redukcją szumów, wbudowany głośnik
5.
Ekran
Przekątna 10,4’’, technologia TFT z powłoką dotykową,
rozdzielczość natywna 1024x768,
6.
Technologia dotykowa
Technologia umożliwiająca obsługę piórkiem magnetycznym
lub dotykiem palca
7.
Porty
Złącze dokujące, 2x USB, RS232, , Ethernet, wejście
mikrofonowe, wyjście słuchawkowe
8.
Inne wymagania
9.
Zestaw do montażu w
Bateria umożliwiająca pracę poza stacją dokującą
przynajmniej do 3,5h bez konieczności wymiany lub
ładowania.
 Norma szczelności nie mniejsza niż IP65 lub równoważną
 Instalacja urządzenia zgodnie z normą PN-S-76020 lub
równoważną.
 Zgodność ze znakiem CE lub równoważnym.
Tablet należy wyposażyć w stację dokującą montowaną w
samochodzie
Strona 22

Lp.
Parametr
pojeździe
10.
Zasilanie zewnętrzne
Zasilacz sieciowy oraz zasilacz samochodowy
11.
System operacyjny
Co najmniej Windows XP Tablet PC lub wyższy np. Windows 7
Professional
Parametry stacji dokującej
Co najmniej 2 porty USB, wejście mikrofonowe, wyjście
słuchawkowe, port zasilania,. Stacja dokująca z możliwością
instalacji w karetce musi zapewniać ochronę fizyczną sprzętu
przez zabezpieczenie zamkiem otwieranym kluczem. Stacja
musi mieć zasilanie z akumulatora samochodu aby
doładowywać tablet medyczny
16.
5.4
Minimalne wymagania na drukarki do karetek ZRM
Lp.
Parametr
1.
Typ drukarki
monochromatyczna
2.
Format wydruku
A4
3.
Prędkość drukowania (A4, tryb
draft)
Min. 10 str./min.
4.
Normatywny cykl pracy
(miesięcznie, format A4)
Do 400 str./miesiąc
5.
Wbudowana pamięć
Min. 32 MB
6.
Standardowy podajnik papieru
Podajnik na 30 arkuszy
5.5
Minimalne wymagania dot. urządzeń GPS (do pozycjonowania GPS i monitoringu
Lp.
Parametr
1.
Odbiornik GSM
Tak – wewnętrzny
2.
Antena GSM
Tak – zewnętrzna
3.
Czułość odbiornika GPS
-158 dBm (w trybie Tracking)
-148 dBm Reacquisition
-142 dBm Cold
4.
Dokładność lokalizacji obiektu
2,5 m CEP
5 m SEP
5.
Odbiornik GPS
16 kanałowy
6.
Interwał transmisji danych do
serwera systemu
Od 5 s do 10000 s - programowalny
Strona 23
w karetkach)
5.6
Serwer komunikacyjny zintegrowanej łączności – minimalne parametry
W ramach realizacji zamówienia wymagane jest wdrożenie rozwiązania zapewniającego
dyspozytorom medycznym komunikację radiową z karetkami. Niniejsza komunikacja musi być
realizowana w oparciu o zapewniane przez Zamawiającego serwery komunikacyjne konsole
dyspozytorskie oraz sieć OST112 w technologii IP/MPLS, z wykorzystaniem komunikacji protokołem
IP. Poprzez konsolę dyspozytorską dyspozytor będzie wywoływał oraz odbierał połączenia radiowe
i telefoniczne. Ponadto dyspozytor musi mieć możliwość odsłuchiwania rozmów z systemu
rejestracji korespondencji zlokalizowanego w WCPR (dostawa serwerów komunikacyjnych
zintegrowanej
zapewnienie
łączności,
łączy
radiotelefonów
telekomunikacyjnych
konsol
nie
dyspozytorskich
wchodzi
w
zakres
jak
również
przedmiotowego
zamówienia).
Zamawiający wymaga aby wykonawca wdrożył rozwiązanie oparte o serwery zlokalizowane
w WCPR charakteryzujące się poniżej wskazanymi parametrami.
Kod
Opis
wymagania
SK.1
Rozumiany
jako
zapewniająca
oprogramowanie
integrację
środków
dedykowane
korespondencji
oraz
platforma
radiowej,
sprzętowa
telefonicznej
oraz
systemów informatycznych złożone z:
a. modułu Rejestracji,
b. modułu Telefoniczny,
c. serwera Zarządzania.
SK.2
Możliwość dołączenia do 255 konsol dyspozytorskich
SK.3
Możliwość
dołączenia
do
255
obsługiwanych
stacji
bazowych
(radiostacji,
radiotelefonów).
SK.4
110 kanałów radiowych dostępnych w jednym czasie na konsoli dyspozytorskiej
z następującym podziałem:
a. 60 kanałów do pracy w trybie Rx/Tx,
b. 50 kanałów do pracy w trybie Rx.
SK.5
Współużytkowanie 1 kanału radiowego w trybie nadawczo-odbiorczym przez 32
operatorów z uwzględnieniem priorytetów. Możliwość definiowania parametru liczby
operatorów.
SK.6
Zapewnienie pracy ciągłej, co oznacza, iż zmiany konfiguracji, nie mogą powodować
restartu sterowników i resynchronizacji połączeń.
SK.7
Obsługa
następujących
typów
radiotelefonów/systemów
radiowych
(przystosowanych do zdalnego sterowania):
a. Konwencjonalne VHF,
b. TETRA,
c. EDACS,
SK.8
Funkcja systemowej rejestracji korespondencji:
a. telefonicznej
i. Numer abonenta A (abonent inicjujący połączenie),
Strona 24
d. Obsługa sygnalizacji SELECT5 oraz CTCSS.
Kod
Opis
wymagania
ii. Numer abonenta B (abonent wywoływany przez abonenta A),
iii. Numer abonenta C (abonent osiągnięty przez abonenta A w przypadku
przekierowania przez abonenta B),
iv. Godzina rozpoczęcia nagrania,
v. Czas trwania nagrania,
vi. Identyfikator nagrania w systemie rejestracji serwera komunikacyjnego,
b. radiowej
i. Identyfikator radiotelefonu,
ii. Numer kanału ustawionego w radiotelefonie i/lub częstotliwość,
iii. Godzina rozpoczęcia nagrania,
iv. Czas trwania nagrania,
v. Identyfikator nagrania w systemie rejestracji serwera komunikacyjnego.
SK.9
Możliwość zdefiniowania tylko jednego serwera zarządzania dla kilku serwerów
komunikacyjnych.
SK.10
W
pełni
cyfrowe
przenoszenie
akustyki
pomiędzy
konsolą
dyspozytorską
zintegrowanej łączności a modułem kontrolnym radiotelefonów.
SK.11
Możliwość pracy wszystkich elementów serwera komunikacyjnego bez dostępu do
systemu nadzoru.
SK.12
W przypadku realizacji systemu w oparciu o łącza TDM E1 opóźnienie sygnału PTT
(push-to-talk) wnoszone przez system mniejsze niż 20ms.
SK.13
Możliwość
dostępu
sieciowania
do
serwerów
zasobów
komunikacyjnych
radiowych
innego
serwera
rozumiana
jako
możliwość
komunikacyjnego
zarówno
z wykorzystaniem IP jak i E1.
SK.14
Serwer komunikacyjny ma możliwość współpracy z zewnętrznymi centralkami PABX
używanymi, jak również możliwość zastąpienia istniejących centralek PABX.
SK.15
Obsługa następujących protokołów telekomunikacyjnych:
a. DSS1 (2B+D, 30B+D),
b. Qsig,
c. SS7,
d. H.323,
e. SIP.
Serwer
komunikacyjny
wyposażony
w
następujące
standardowe
interfejsy
telekomunikacyjne:
a. styk A - przeznaczony do współpracy z traktem cyfrowym–PCM30,
b. styk
C11
-
przeznaczony
do
współpracy
z
dwutorowymi,
końcowymi
wyposażeniami telefonii nośnej, –styki C21 i C22 - przeznaczone do współpracy z
centralami elektromechanicznymi po jednotorowych (niewzmacnianych) łączach
analogowych,
c. styk Z - przeznaczony do współpracy z jednotorowym analogowym łączem
abonenckim,
d. styk
V1
-
przeznaczony
do
współpracy
z
łączem
cyfrowym
dostępu
podstawowego–(2B+D),
e. styk V3 - przeznaczony do współpracy z traktem dostępu pierwotnego (–0B+D),
f. styk Stg - przeznaczony do współpracy z siecią taktyczną pracującą według
zaleceń Eurocom D1, STANAG 4206-4210, STANAG 4578 ED.2.
Strona 25
SK.16
Kod
Opis
wymagania
SK.17
Dla
kart
portów
cyfrowych
łączy
miejskich
zapewniona
możliwość
zmiany
sygnalizacji (DSS1 / QSIG) tylko w sposób programowy bez konieczności wymiany
pakietu.
SK.18
wysoka
niezawodności
sprzętu
poprzez
zdublowanie
krytycznych
elementów
systemu. Elementy redundantne muszą pracować w trybie gorącej rezerwy.
Awaryjne przełączenie na system rezerwowy nie może powodować przerw w
komunikacji.
SK.19
Interfejsy 2Mbit/s do współpracy z publiczną siecią telekomunikacyjną muszą
spełniać parametry teletransmisyjne zgodne z zaleceniem ITU-T G.703.
SK.20
Serwer komunikacyjny musi udostępniać interfejs do współpracy z zewnętrznymi
aplikacjami typu CTI wymagana jest obsługa protokołu, co najmniej typu TAPI.
SK.21
Serwer
komunikacyjny
musi
gwarantować
możliwość
wprowadzania
zmian
wynikających z rozwoju technologicznego oraz zapewniać możliwość rozbudowy,
zwiększenia pojemności i funkcjonalności w zależności od potrzeb Zamawiającego
zarówno części dotyczącej oprogramowania jak i sprzętu.
SK.22
Konstrukcja serwera komunikacyjnego oraz jego oprogramowania powinna zakładać
możliwość dostosowywania go do indywidualnych potrzeb Zamawiającego.
SK.23
Całość dokumentacji zarówno do serwera komunikacyjnego, jego interfejsów,
wspieranych protokołów i oprogramowania musi być dostarczona w języku polskim.
SK.24
W
ramach
zsieciowanego
systemu
serwerów
komunikacyjnych
musi
zostać
zapewniony wspólny plan numeracji.
SK.25
Serwer
komunikacyjny
musi
zapewniać
możliwość
tworzenia
wielu
planów
numeracji, tj. tworzenie wirtualnej centrali PBX. Liczba wirtualnych grup nie mniej
niż 10.
SK.26
Serwer
komunikacyjny
zintegrowanej
łączności
musi
gwarantować
możliwość
tworzenia planu numeracji wewnętrznej i zewnętrznej zawierającej:

numery wewnętrzne i zewnętrzne użytkowników wewnętrznych,

numery wewnętrzne i zewnętrzne aparatów systemowych,

SK.27
Serwer
kody dostępu do publicznych sieci telekomunikacyjnych.
komunikacyjny
musi
charakteryzować
się
strukturą
umożliwiającą
wynoszenie modułów funkcjonalnych w inne lokalizacje z wykorzystaniem sieci TDM
oraz sieci IP.
SK.28
Serwer komunikacyjny musi wybierać drogi obejściowe w przypadku uszkodzenia
bądź przepełnienia drogi podstawowej. Wymagany jest dostęp do minimum 4 dróg
obejściowych.
SK.29
Serwer komunikacyjny musi przekazywać do centralnego stanowiska zarządzania,
na bieżąco, informację o wszystkich alarmach w systemie, raporty i inne dane
o charakterze statystycznym.
W ramach serwera komunikacyjnego wymagane zapewnienie centralki telefonicznej
PABX (100 numerów).
Strona 26
SK.30
5.7
System rejestracji rozmów jako funkcjonalność systemu zintegrowanej łączności
(serwera komunikacyjnego zintegrowanej łączności) – minimalne parametry
Zaproponowane przez Wykonawcę rozwiązanie musi być oparte o zapewniany przez
Zamawiającego system zintegrowanej łączności (serwer komunikacyjnego zintegrowanej łączności
wraz z systemem rejestracji rozmów).
Zamawiający wymaga aby w ramach przedmiotowego zamówienia wykonawca dostarczył
rozwiązanie oparte o system rejestracji rozmów zlokalizowany w WCPR, charakteryzujący się
poniżej wskazanymi parametrami.
Kod
Opis
wymagania
SRR.1
System
rejestracji
rozmów
musi
umożliwiać
rejestrację
treści
rozmów
telefonicznych w postaci zapisu cyfrowego.
SRR.2
System rejestracji rozmów powinien umożliwiać rejestrację wszystkich rozmów
obsługiwanych przez serwer komunikacyjny oraz rejestrację rozmów wybranej
grupy abonentów.
SRR.3
System rejestracji rozmów powinien umożliwiać rejestrację rozmowy dowolnego
abonenta oraz zdalny wybór abonenta nagrywanego ze stanowiska nadzoru, bez
konieczności fizycznego krosowania na przełącznicy.
SRR.4
System rejestracji rozmów musi umożliwiać rejestrację rozmowy z portów nie
przechodzących przez centralę (analogowe łącza miejskie i ISDN BRA).
SRR.5
System rejestracji rozmów musi zapewniać ochronę danych oraz kontrolę dostępu
do zapisanych informacji na podstawie systemu haseł i klas uprawnień.
SRR.6
System rejestracji rozmów powinien umożliwiać kontrolny odczyt danych (przez
autoryzowanych użytkowników) w celu sprawdzenia stanu rejestracji.
SRR.7
Łączny czas nagrań na wewnętrznym dysku rejestratora bez „nadpisywania” nie
powinien być krótszy niż 48 godzin.
SRR.8
System rejestracji rozmów musi umożliwić automatyczną i ręczną archiwizację
nagrań na zewnętrznym serwerze nagrań. Dostęp do serwera poprzez sieć
Ethernet.
SRR.9
System rejestracji rozmów musi umożliwiać wykonanie kopii wybranych przez
uprawnionego operatora fragmentów zapisu w postaci pliku audio w formacie .wav
i .pcm.
SRR.10
System
rejestracji rozmów musi zapewniać archiwizację i odsłuch zapisanych
danych, na co najmniej 3 wskazanych komputerach PC pracującym w sieci LAN,
WAN.
SRR.11
System
rejestracji rozmów musi umożliwiać archiwizację nagrań pochodzących
z różnych lokalizacji w jednym miejscu z wykorzystaniem sieci LAN/WAN.
SRR.12
System rejestracji rozmów powinien umożliwiać odsłuch rozmów poprzez sieć LAN
z użyciem dedykowanej aplikacji.
SRR.13
System
rejestracji rozmów musi umożliwiać administrowanie oraz zdalny nadzór
SRR.14
System rejestracji rozmów powinien opatrywać nagrania głosowe dodatkowymi
informacjami tj.:
1. numer abonenta dzwoniącego (w ruchu przychodzącym),
Strona 27
poprzez sieć LAN/WAN.
Kod
Opis
wymagania
2. numer wewnętrzny,
3. numer wybrany,
4. data i godzina połączenia,
5. czas trwania połączenia,
6. kierunek rozmowy,
7. numer linii (kanał),
SRR.15
System
rejestracji rozmów musi umożliwić wyszukiwanie nagrań co najmniej
według następujących kryteriów:
1. data i czas nagrania,
2. numer linii (kanał),
3. numer dzwoniący,
4. numer wewnętrzny,
5. kierunek połączenia.
SRR.16
Brak bezpośredniego dostępu do sytemu plików dla systemu rejestracji rozmów
(rejestratora).
SRR.17
odsłuch rozmowy niezależnie od jej rejestracji w danym momencie.
SRR.18
System
rejestracji rozmów musi uniemożliwiać kasowanie plików również
z poziomu uprawnień administratora.
SRR.19
System
rejestracji rozmów musi umożliwiać elastyczną rozbudowę, zwiększenie
liczby rejestrowanych kanałów.
SRR.20
System
rejestracji
rozmów
musi
zapewniać
możliwość
natychmiastowego
raportowania o błędach lub awariach urządzeń wchodzących w skład systemu.
SRR.21
W przypadku przerwy w zasilaniu system
rejestracji rozmów po odzyskaniu
zasilania musi samodzielnie powrócić do normalnej bezobsługowej pracy.
SRR.22
System rejestracji rozmów powinien zostać dostarczony w obudowie umożliwiającej
montaż w szafie przemysłowej 19”.
SRR.23
System rejestracji rozmów powinien być zasilany ze źródła gwarantowanego przez
zasilacze (siłownię) centrali.
5.8
Stanowiska dostępowe
Zaproponowane
przez
Wykonawcę
rozwiązanie
musi
oparte
o
zapewniane
przez
Zamawiającego stanowiska dostępowe (stanowiska wyposażone w karty mikroprocesorowe oraz
czytniki kart mikroprocesorowych) o przedstawionych poniżej minimalnych wymaganiach (dostawa
stanowisk dostępowych nie wchodzi w zakres zamówienia).
5.8.1
Kod
Stanowiska dostępowe– minimalne parametry
Element
Opis
procesor
minimum dwurdzeniowy zgodny z architekturą x86, który umożliwi
SD.1
uzyskanie przez oferowany komputer wydajności w teście BAPCO
SYSMARK 2007 Preview wyników nie gorszych niż: 150 punktów
Strona 28
wymagania
Kod
Element
Opis
wymagania
(SYSmark 2007 Preview Rating) na podstawie tabeli opublikowanej:
http://www.bapco.com/support/fdrs/SYSmark2007web.html
Uwaga!
Jeżeli
konfiguracją
zaoferowany
procesor
sprzętowo-programową
wymienionej
tabeli,
przeprowadzenia
nie
Wykonawca
testów
na
wraz
z
jest
proponowaną
ujęty
zobowiązany
własny
koszt
i
w
wyżej
będzie
do
udokumentowania
Zamawiającemu, że oferowany procesor osiąga wymagany wynik
punktowy w wymienionych testach.
SD.2
SD.3
pamięć
DDR2 lub DDR3
operacyjna
rozbudowy do 4 GB).
karta
minimum
grafiki
umożliwiające jednoczesną obsługę dwu monitorów LCD.
256
Zamawiający
SDRAM, min. 2GB, 800MHz (z możliwością
MB
nie
DDR3,
wyposażona
dopuszcza
rozwiązań
w
dwa
opartych
porty
na
DVI
kartach
graficznych zintegrowanych z płytą główną. Karty graficzne muszą
posiadać pełne wsparcie dla DirectX 10.
SD.4
SD.5
SD.6
karta
co najmniej dwukanałowa. Zamawiający dopuszcza zastosowanie
dźwiękowa
karty dźwiękowej zintegrowanej z płytą główną.
karta
LAN
sieciowa
zastosowanie karty sieciowej zintegrowanej z płytą główną.
dysk
SATA, min. 320 GB, 7200rpm, min 8MB cache.
10/100/1000
-
złącze
RJ-45.
Zamawiający
dopuszcza
twardy
SD.7
napęd
DVD Dual Layer +/- RW wraz z zainstalowanym oprogramowaniem
w języku polskim.
SD.8
mysz
optyczna PS/2 lub USB - 2 przyciski + rolka przewijania, podkładka.
SD.9
klawiatura
USB, w układzie QWERTY.
SD.10
obudowa
Midi lub Mini Tower, ATX. Wolne złącza: 4xUSB 2.0, wejście/wyjście
audio, przednie złącza: 2x USB 2.0.
SD.11
monitor
2 szt. – LCD 19”:
o
rozdzielczość - 1440x900
o
minimalny kontrast – 8000:1
o
monitor musi umożliwiać regulację wysokości, kąta pochylenia
i obrotu
o
minimalny kąt widzenia w poziomie: 160
o
minimalny kat widzenia w pionie: 160
o
złącze DVI
o
monitor musi spełniać normy:
TCO’03,
ISO 13406-2, EPA
ENERGY STAR, TUV/GS
o
dostarczony monitor musi być wyposażony w komplet kabli:
zasilający o długości min. 1,8 m oraz kabel sygnałowy o długości
min. 1,8 m.
oprogramo
Dostarczone
stanowiska
dostępowe
muszą
mieć
zainstalowany
wanie
system operacyjny, pakiet oprogramowania antywirusowego, a także
czytniki o których mowa w pkt. 5.5.3.:
o
64 bitowy system operacyjny w polskiej wersji językowej, jeden
z wymienionych:
Strona 29
SD.12
Kod
Element
Opis
wymagania
o

MS Windows 7 Ultimate* lub

MS Windows 7 Professional* lub

MS Windows Vista Business plus Service Pack 2*
program antywirusowy z modułem aktualizacji bazy sygnatur
wirusów przez Internet przez okres co najmniej 2 lat w polskiej
wersji językowej,
o
SD.13
oprogramowanie biurowe – OpenOfficePl
Listwa
napięcie 230V, częstotliwość 50 Hz,
zasilająca
o
obciążenie dla jednego gniazda nie mniejsza niż 460 W,
o
liczba gniazd w listwie 5
o
wyłącznik dwubiegunowy – podświetlony
o
zabezpieczenie prądowe – bezpiecznik 10A – 250V
o
zabezpieczenie przepięciowe – impuls 1x130J<10/1000us.
*lub równoważne
5.8.2
Kod
Karty mikroprocesorowe– minimalne parametry
Opis
wymagania
KM.1
zgodne ze standardem ISO w następujących częściach: 7816-1, 7816-2, 7816-3,
7816-4, 7816-5, 7816-6, 7816-8.
KM.2
wyposażone w procesor o pojemności min 72 kB.
KM.3
dostarczony sprzęt musi być fabrycznie nowy/nieużywany. Ponadto Wykonawca
dostarczy, zainstaluje i uruchomi sprzęt na wskazanym stanowisku pracy.
KM.4
zgodne ze Standardem Java Card 2.2.1.
KM.5
napięcie zasilania karty musi mieścić się w zakresie 1,62 – 5,5 V.
KM.6
gwarantowana ilość cykli zapisu/kasowania dostarczonej karty nie może być
mniejsza niż 500,000.
KM.7
karty wspierane przez algorytmy kryptograficzne i szyfrujące:
o 3DES (ECB, CBC),
o AES (128, 192, 256),
o RSA up to 2048bit ,
o SHA-1.
KM.8
Długość generowanych kluczy kryptograficznych Cryptographic algorithms: 3DES
(ECB, CBC), AES (128, 192, 256), RSA up to 2048bit ,SHA-1.
KM.9
wsparcie dla MS terminal Services, Wsparcie dla logowania w domenie, Wsparcie
dla pracy wieloaplikacyjnej.
KM.10
zapewniające wsparcie dla polityki haseł (PINÓW).
KM.11
zapewniające wsparcie dla szyfrowania komunikacji między kartą a komponentami
zapewniające wsparcie dla różnych kodów PIN, PUK.
KM.13
zapewniające wsparcie dla historii PIN’ów.
KM.14
zapewniające wsparcie dla konfigurowalnej polityki PIN i PUK.
KM.15
zapewniające wsparcie dla PKCS #11 dla:
o Windows:
Windows w wersji językowej polskiej lub angielskiej 2000SP6 / XP Proffesional SP2
Strona 30
systemu.
KM.12
Kod
Opis
wymagania
lub SP3 / 2003 Server / Vista (Home, Business, Ultimate) –wersje 32b i 64b /
Windows 7 (Starter, Home, Premium, Professional, Ultimate) – wersje 32b i 64b
o Linux z jądrem 2.6:
 Ubuntu 7.X, 8.10, 9.10,
 openSUSE 11.X,
 Red Hat Enterprise Linux 5,
 Debian Etch 4.0, 5.0.X.
KM.16
zapewniające wsparcie dla CSP dla systemu operacyjnego Windows:
Windows w wersji językowej polskiej lub angielskiej 2000SP6 / XP Proffesional SP2
lub SP3 / 2003 Server / Vista (Home, Business, Ultimate) –wersje 32b lub 64b /
Windows 7 (Starter, Home, Premium, Professional, Ultimate) – wersje 32b i 64b
5.8.3
Kod
Czytniki kart mikroprocesorowych– minimalne parametry
Opis
wymagania
CKM.1
czytnik kart mikroprocesorowych jako urządzenie wewnętrzne (wbudowane)
komputera podłączony przez wewnętrzny port USB 2.0.
CKM.2
zgodność z PC/SC.
CKM.3
zgodność z ISO 7816-1, 7816-2, 7816-3, 7816-4, 7816-8 – interfejs stykowy.
CKM.4
sterowniki dla Windows XP, Vista, Windows 7.
CKM.5
sterowniki dla systemu Linux.
CKM.6
czytnik musi gwarantować poprawną pracę dla min. 100 000 cykli włożenia/wyjęcia
karty.
CKM.7
czytnik musi posiadać sygnalizację optyczną (np. dioda) akceptacji karty oraz pracy
z kartą.
CKM.8
5.9
Czytnik musi współpracować z oferowanymi kartami mikroprocesorowymi.
Konsole dyspozytorskie zintegrowanej łączności – minimalne parametry
Zaproponowane przez Wykonawcę rozwiązanie musi być kompatybilne z zapewnianymi przez
Zamawiającego konsolami dyspozytorskimi zintegrowanej łączności o przedstawionych poniżej
minimalnych wymaganiach. Dostawa konsol dyspozytorskich zintegrowanej łączności nie wchodzi
w zakres zamówienia.
Kod
Opis
KD.1
Ekran dotykowy, o przekątnej min. 19” z regulacją położenia (podnoszenie/
opuszczanie i uchylanie).
KD.2
Łączność z serwerem komunikacyjnym zintegrowanej łączności za pomocą interfejsu
Strona 31
wymagania
Kod
Opis
wymagania
SHDSL, E1/G.703 lub IP.
KD.3
Możliwość współpracy z bezprzewodowym zestawem mikrofonowo-słuchawkowym.
KD.4
Możliwość jednoczesnego prowadzenia rozmowy z wykorzystaniem łącza radiowego,
telefonicznego interkomu oraz prowadzenia podsłuchu radiowego.
KD.5
Funkcje
umożliwiające
obsługę
połączeń
radiowych
i
monitoringu
środków
radiowych:
-obserwowanie stanu sygnałów PTT i SQUELCH w danym kanale radiowym,
-rejestracja rozmów,
-wybór kanału pracy radiostacji,
-wybór trybu pracy (nasłuch, nadawanie-odbiór),
-wybór grup w radiotelefonie.
KD.6
Funkcje umożliwiające obsługę środków łączności telefonicznej:
-kolejkowanie zgłoszeń,
-szybkie wybieranie połączenia konferencyjnego,
-szybki dostęp do książki telefonicznej,
-zestawianie połączeń pomiędzy abonentami,
-rejestracja rozmów.
KD.7
Funkcje umożliwiające obsługę Interkomu.
KD.8
Zestaw rejestrujący lokalną korespondencję.
KD.9
Rejestracja rozmów radiowych powinna zawierać co najmniej:
-ID radiotelefonu,
-nr kanału na którym prowadzona jest rozmowa,
-godzinę rozpoczęcia i zakończenia,
-czas rozmowy,
-identyfikator nagrania.
KD.10
Rejestracja rozmów telefonicznych powinna zawierać co najmniej:
-numer abonenta inicjującego,
-numer abonenta wywołanego,
-numer abonenta docelowego (przypadek przekserowania),
-godzinę rozpoczęcia i zakończenia,
-czas rozmowy,
-identyfikator nagrania.
KD.11
Integracja środków łączności radiowej różnych standardów i typów (analogowe,
cyfrowe).
KD.12
Możliwość
podsłuchu
korespondencji
pomiędzy
dyspozytorem
innej
konsoli
prowadzącej nasłuch na tym samym radiotelefonie lub grupie a użytkownikami sieci
radiowej.
KD.13
Podczas zmiany kanału radiowego przez dyspozytora konieczna jest sygnalizacja
(z podaniem nazwy stanowiska dyspozytorskiego, które dokonało zmiany) na
pozostałych konsolach dyspozytorskich posiadających dostęp do ww. radiotelefonu.
Konsola musi umożliwić dyspozytorowi dynamiczne tworzenie grupy radiotelefonów,
przypisanie
im
jednego
przycisku,
który
załączy
nadawanie
na
wszystkich
radiotelefonach w grupie. Utworzenie grupy powinno być sygnalizowane na
pozostałych konsolach mających uprawnienia do korzystania z dowolnego telefonu
w zestawionej grupie.
Strona 32
KD.14
Kod
Opis
wymagania
KD.15
Konsola musi zapewniać regulację głośności sygnalizacji dźwiękowej.
KD.16
Wszystkie komunikaty, ostrzeżenia i opisy wyświetlane na konsoli muszą być
w języku polskim.
KD.17
Administrator systemu musi mieć możliwość nadawania odpowiednich uprawnień
poszczególnym konsolom, grupom dyspozytorów i użytkownikom uprzywilejowanym.
KD.18
Możliwość
odsłuchu
zarejestrowanej
korespondencji
prowadzonej
przez
daną
konsole.
KD.19
Po konsultacjach z zamawiającym wykonawca zaproponuje organizację i wygląd
interfejsu graficznego konsoli, z zastrzeżeniem modyfikacji wyglądu i funkcjonalności
przez zamawiającego w okresie do 6 miesięcy od uruchomienia WCPR.
KD.20
Zamawiający wymaga, aby całość wymaganej funkcjonalności była realizowana
przez zintegrowaną aplikację działającą na konsoli dyspozytorskiej. Zamawiający nie
dopuszcza rozwiązania, w którym dla realizacji wymagań opisanych w tej tabeli
użytkownik będzie musiał uruchamiać niezależne aplikacje.
KD.21
Obsługa co najmniej 4 kolejek z funkcją ACD (Automatic Call Distribution), obsługa
gorących linii pozwalająca na obserwację stanu łącza abonenta.
KD.22
Obsługa interkomu do szybkiej łączności pomiędzy operatorami.
KD.23
Obsługa lokalnej i globalnej książki telefonicznej.
KD.24
Obsługa konferencji zwykłej i selektorowej również w modelu sieciowym. Łączna
minimalna liczba uczestników konferencji to 48.
KD.25
Obsługa pozwalająca na realizacje połączeń crossconect (połączenie radiostacji
z telefonem) i crossband (połączenie dwóch radiostacji).
KD.26
Obsługa fax-ów, polegającą na zobrazowaniu i archiwizowaniu zgłoszeń.
KD.27
Obsługa historii zdarzeń telefonicznych, radiowych, SMS, statusów i alarmów.
Pozwalająca na przeglądanie zdarzeń z co najmniej 7 ostatnich dni oraz ich
archiwizację.
KD.28
Obsługa alarmów urządzeń oddalonych, polegająca na zgłaszaniu zdarzeń typu
otwarcie obudowy, brak napięcia zasilania, brak zasilania czujek ruchu PIR, wzrost
lub zmniejszenie się temperatury w pomieszczeniu powyżej lub poniżej ustalonej
wartości, zadziałanie czujki PPOŻ.
KD.29
Zmiana konfiguracji aplikacji nie może powodować jej restartu, nie jest odczuwalna
z punktu widzenia użytkownika.
KD.30
Obsługa
profili
operatorskich.
Profile
operatorskie
systemu
określają
zakres
odpowiedzialności i przywileje jakie posiada operator posługujący się danym
profilem. Profil musi zawierać informacje na temat:
a. kanałów radiowych, dostępnych na stanowisku operatorskim,
b. praw dostępu do kanałów (tryby pracy operatora na danym kanale i priorytety),
c. praw do zmiany częstotliwości i mocy nadawania określonych kanałów,
d. dostępnych zasobów telefonicznych (kolejki, gorące linie),
e. wyglądu interfejsu (rozmieszczenie przycisków, napisy na przyciskach).
KD.31
Obsługa zestawu funkcji umożliwiających powiadamianie telefoniczne zdefiniowanej
Obsługa następujących funkcji dyspozytorskich:
a. Kierowanie wywołań do 4 kolejek
b. Możliwość podjęcia z kolejki dowolnego abonenta
Strona 33
grupy osób.
KD.32
Kod
Opis
wymagania
c. Możliwość zawieszenia do 3 wywołań (HOLD)
d. Możliwość szybkiego przekazania połączenia
e. Możliwość grupowania klawiszy gorących linii w zakładki
f. Możliwość przypisywania klawiszom gorących linii kolorów
g. Możliwość definiowania kolorów dla różnych stanów wskazywanych przez klawisze
gorących linii
h. Możliwość przypisania typu dzwonka do klawisza
i. Możliwość przypisania dzwonka do kolejki.
KD.33
Możliwość zaprogramowania grup poszukiwania – tworzenie numeru grupowego po
wybraniu, którego wywoływane będą kolejne terminale wg określonego szyku:
liniowo, cyklicznie, grupowo (równoległa sygnalizacja wywołania na kilku stacjach).
KD.34
Możliwość zdefiniowania grup przechwytujących – w przypadku wywołania na
jednym z terminali abonenckich z grupy możliwość przejęcia tego wywołania na
dowolnym innym terminalu.
KD.35
„Oddzwanianie” przy zajętości – w przypadku zajętości wywoływanego terminala
abonent może zażądać zasygnalizowania faktu, że terminal wywoływany przeszedł
w stan spoczynku, tzn. zakończyła dotychczasowe połączenie.
KD.36
„Oddzwanianie” przy braku odpowiedzi – w przypadku braku odpowiedzi ze strony
wywoływanego terminala abonent może zażądać zasygnalizowania faktu, że pojawiła
się jakakolwiek aktywność ze strony wywoływanego terminala (np. zrealizował
połączenie i przeszedł w stan spoczynku).
KD.37
Zróżnicowany
sygnał
dzwonienia
dla
rozmów
wewnętrznych,
zewnętrznych,
specjalnych (połączenia pilne itp.)
KD.38
„Wejście na trzeciego” dla uprzywilejowanego abonenta (pulpitu dyspozytorska, itp.)
możliwość włączenia się w trwającą rozmowę.
KD.39
Ochrona przed „wejściem na trzeciego” - możliwość aktywowania dla wewnętrznego
wybranego abonenta usługi uniemożliwiającej włączenie w prowadzone przez niego
rozmowy.
5.10 Wymagania w zakresie szkoleń
Kod
wymagania
EDU.1
W ramach wdrożenia Systemu Wykonawca przeprowadzi szkolenia w języku polskim
dla
40
użytkowników-instruktorów
oraz
20
administratorów-instruktorów
(wytypowanych przez Zamawiającego) obejmujących wykłady teoretyczne oraz
warsztaty wdrożeniowe w zakresie użytkowania i administrowania wdrożonej wersji
Systemu.
EDU.2
Szkolenie dla trenerów oraz administratorów obejmować ma minimum 14h. Czas
trwania szkolenia - min. 2 dni (po maks. 8 godzin/dziennie), w dni robocze,
EDU.3
Wykonawca opracuje harmonogram szkoleń zawierający:

cel i projektowany zakres szkoleń,

informacje o zakresie tematycznym szkoleń,
Strona 34
w godzinach pracy Zamawiającego.
Kod
wymagania

metodzie i formie szkoleń,

czasie trwania szkoleń,

pożądanych
kwalifikacjach
osób
skierowanych
na
szkolenia,
ich
koszcie
jednostkowym oraz miejscu przeprowadzenia poszczególnych szkoleń.
EDU.4
Wykonawca zapewni zakwaterowanie oraz wyżywienie dla uczestników szkoleń oraz
zapewnieni zaplecze techniczno-dydaktyczne, w tym infrastrukturę sprzętową
niezbędną do przeprowadzenia szkolenia.
EDU.5
Harmonogram, o którym mowa w EDU 3, wykonawca
przedstawi do akceptacji
zamawiającego.
EDU.6
Wykonawca zobowiązany jest do przeprowadzenia szkoleń zgodnie z zatwierdzonym
harmonogramem szkoleń.
EDU.7
Wszystkie szkolenia Wykonawca przeprowadzi w języku polskim, zapewniając
materiały szkoleniowe (w języku polskim) dla uczestników szkoleń oraz przeniesie
prawa autorskie do opracowanych materiałów szkoleniowych.
EDU.8
Wykonawca
dostarczy
Zamawiającemu
multimedialne
materiały
szkoleniowe
w postaci zapisu na płycie CD-ROM (lub innym równoważnym nośniku).
EDU.9
Wykonawca zapewni prowadzenie szkoleń przez wykwalifikowaną kadrę posiadającą
wiedzę teoretyczną i praktyczną z zakresu przedmiotu zamówienia.
EDU.10
Przeszkoleni administratorzy i instruktorzy otrzymają potwierdzenie ukończenia
szkolenia
stwierdzające,
że
osiągnęli
oni
wiedzę
niezbędną
do
pełnienia
powierzonych zadań oraz inne dokumenty potwierdzające nabycie określonych
umiejętności (certyfikat).
EDU.11
Przeprowadzenie szkoleń zostanie potwierdzone protokołem sporządzonym w dwóch
jednobrzmiących egzemplarzach, po jednym dla Zamawiającego i Wykonawcy,
zawierającym:
EDU.12

nazwę i tematykę i czas trwania szkolenia,

datę i miejsce szkolenia,

imienną listę osób uczestniczących w szkoleniu,

imię i nazwisko oraz specjalizację osób prowadzących szkolenie,
Protokół
z
przeprowadzenia
szkoleń
podlegać
będzie
zatwierdzeniu
przez
Zamawiającego.
5.11 Wymagania w zakresie dokumentacji
Kod
wymagania
DOC.1
Zamawiający
wymaga,
aby
Wykonawca
przygotował,
zgodnie
z
ogólnie
akceptowalnymi standardami w dziedzinie dokumentowania, następujące rodzaje
dokumentacji bezpośrednio związanej z przedmiotem zamówienia:
DOC.1.1
Szczegółowa analiza potrzeb Zamawiającego w zakresie wymagań stawianych
Systemowi.
Projekt techniczny zawierający, co najmniej następujące informacje:

Szczegółową specyfikację wymagań dla Systemu zgodnie z przekazanym
przez Zamawiającego szablonem,

Diagram kontekstowy realizacji przedmiotu zamówienia,
Strona 35
DOC.1.2
Kod
wymagania

Procesy kierujące realizacją przedmiotu zamówienia

Struktura i zawartość planów realizacji przedmiotu zamówienia,

Techniki zarządzania realizacją przedmiotu zamówienia,

Zestaw elementów sterujących zarządzaniem i jakością, w tym tworzona
dokumentacja
obejmująca
również
działania
zarządcze,
tj.
planowanie,
monitorowanie i raportowanie prac w ramach realizacjiprzedmiotu Zamówienia,
w sytuacjach normalnych i wyjątkowych, a także działania specjalistyczne
determinowane przez zakres i cele umowy/przedmiotu Zamówienia, opisujące
prace niezbędne do wytworzenia produktów, które mają powstać w ramach
realizacji przedmiotu zamówienia.
DOC.1.3
Dokumentację powykonawczą, zawierającą co najmniej następujące informacje:

Wprowadzenie opisujące cele i zakres przedmiotu zamówienia,

Diagram kontekstowy zaproponowanego rozwiązania i model zachowania,

Ograniczenia rozwiązania, założenia i zależności,

Ogólna charakterystyka użytkowników,

Opis wymagań funkcjonalnych i niefunkcjonalnych Systemu,

Specyfikację wymagań funkcjonalnych,

Specyfikację wymagań niefunkcjonalnych,

Opis wymagań sprzętowych i programowych,

Specyfikację wymagań sprzętowych,

Specyfikację wymagań programowych,

Opis i specyfikację interfejsów,

Opis sposobu realizacji przedmiotu zamówienia zależny od zastosowanych
metod, tj. metod obiektowych lub strukturalnych,

Program przebiegu testów akceptacyjnych i sposób oszacowania niezawodności
zaproponowanego rozwiązania, w tym raportów z testów,
DOC.2

Kody źródłowe.

Plany ciągłości działania.
Zamawiający wymaga, aby wszystkie dokumenty tworzone w ramach realizacji
przedsięwzięcia charakteryzowały się wysoką jakością, na którą będą miały wpływ,
takie czynniki jak:

Struktura dokumentu, rozumiana jako podział danego dokumentu na rozdziały,
podrozdziały i sekcje, w czytelny i zrozumiały sposób.

Zachowanie
standardów,
w
tym
notacji
UML,
a
także
sposób
pisania,
rozumianych jako zachowanie spójnej struktury, formy i sposobu pisania dla
poszczególnych dokumentów oraz fragmentów tego samego dokumentu

Kompletność dokumentu, rozumiana jako pełne, bez wyraźnych, ewidentnych
braków przedstawienie omawianego problemu obejmujące całość z danego
zakresu rozpatrywanego zagadnienia.

Spójność
i
niesprzeczność
dokumentu,
rozumianych
jako
zapewnienie
wzajemnej zgodności pomiędzy wszystkimi rodzajami informacji umieszczonymi
w dokumencie, jak i brak logicznych sprzeczności pomiędzy informacjami
samego dokumentu.
DOC.3
Zamawiający wymaga, aby cała dokumentacja, o której mowa powyżej, podlegała
Strona 36
zawartymi we wszystkich przekazanych dokumentach oraz we fragmentach tego
Kod
wymagania
jego akceptacji, a także, aby została dostarczona w języku polskim, w wersji
elektronicznej w niezabezpieczonym/edytowalnym formacie Word i PDF (na płycie
CD-ROM lub innym równoważnym nośniku danych) i ewentualnie drukowanej, co
najmniej w 3 egzemplarzach (dopuszcza się inne formaty zapisu dokumentacji np.
diagramy UML lub formaty wektorowe jak DWG,. DXF, należy jednak dołączyć
przeglądarkę obsługującą wykorzystane formaty). Diagramy UML sporządzone za
pomocą narzędzi CASE powinny być dostarczone w formacie EAP. Dostarczone
wykresy Gantta powinny być dostarczone w formacie MPP lub w formacie XLS
umożliwiającym import do MS Project.
DOC.4
Wszelka Dokumentacja wytworzona w ramach realizacji przedmiotu Zamówienia
musi być zgodna z „Zasadami promocji projektów dla beneficjentów Programu
Operacyjnego Infrastruktura i Środowisko 2007-2013” oraz „Przewodnikiem w
zakresie promocji projektów finansowanych w ramach Programu Operacyjnego
Innowacyjna Gospodarka, 2007-2013 dla beneficjentów i instytucji zaangażowanych
we wdrażanie programu”, jak również wytycznymi „Strategii komunikacji Funduszy
Europejskich w Polsce w ramach Narodowej Strategii Spójności na lata 2007-2013”
rozdział 8.2, tzn. wszelka dostarczona w ramach realizacji przedmiotu Zamówienia
dokumentacja musi być opatrzona logotypami: Narodowa Strategia Spójności, Unia
Europejska
z
odniesieniem
słownym
do
Europejskiego
Funduszu
Rozwoju
Regionalnego, logo Beneficjenta. Wytworzona dokumentacja nie będzie opatrzona
logo Wykonawcy.
Szablony Dokumentacji zostaną przekazane Wykonawcy przez Zamawiającego.
5.12 Wymagania w zakresie zgodności Systemu z przepisami prawa
Kod
Opis wymagania
wymagania

System musi być zgodny z niżej wymienionymi aktami prawnym:

Rozporządzenie Rady Ministrów z dnia 11.10.2005 roku w sprawie
minimalnych wymagań dla systemów teleinformatycznych.

Ustawa z dnia 29.08.1997 roku o ochronie danych osobowych.

Ustawa z dnia 17.02.2005 roku o informatyzacji działalności podmiotów
realizujących zadania publiczne.

Ustawa z dnia 24 sierpnia 1991 r. o ochronie przeciwpożarowej (Dz. U.
z 2009 r. Nr 178, poz. 1380);

Ustawa z dnia 18 kwietnia 2002 r. o stanie klęski żywiołowej (Dz. U. z 2002
r. Nr 62, poz. 558, z późn. zm.);

Ustawa z dnia 16 lipca 2004 r. - Prawo telekomunikacyjne (Dz. U. z 2004 r.
Nr 171, poz. 1800, z późn. zm.);

Ustawa z dnia 8 września 2006 r. o Państwowym Ratownictwie Medycznym
(Dz. U. z 2006 r. Nr 191, poz. 1410, z późn. zm.);

Ustawa z dnia 26 kwietnia 2007 r. o zarządzaniu kryzysowym (Dz. U.
Strona 37
PR.1
Kod
Opis wymagania
wymagania
z 2007 r. Nr 89, poz. 590 z późn. zm.);

Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 31
lipca
2009
r.
powiadamiania
w
sprawie
ratunkowego
organizacji
i
i
funkcjonowania
wojewódzkich
centrów
centrów
powiadamiania
ratunkowego (Dz. U. z 2009 r. Nr 130, poz. 1073);

Dyrektywa 2002/22/WE Parlamentu Europejskiego i Rady z dnia 7 marca
2002 r. w sprawie usługi powszechnej i związanych z sieciami i usługami
łączności elektronicznej praw użytkowych;

Ustawa z dnia 30 sierpnia 1991 r. o zakładach opieki zdrowotnej (Dz. U. z
2007 r. Nr 14, poz. 89);

Ustawa 6 listopada 2008 r. o prawach pacjenta i Rzeczniku Praw Pacjenta
(Dz. U. z 2007 r. Nr 52, poz. 417);

Ustawa z dnia 27 sierpnia 2004 r. o świadczeniach opieki zdrowotnej
finansowanych ze środków publicznych (Dz. U. z 2004 r. Nr 210, poz.
2135);

Wykonawcze akty prawne do ww. ustaw w tym również Zarządzenia
Prezesa NFZ.
5.13 Wymagania w zakresie gwarancji
Kod
Opis wymagania
wymagania
WG.1
Gwarancja na dostarczone elementy infrastruktury sprzętowej i oprogramowanie
biegnie osobno dla każdej dostawy od daty podpisania przez Zamawiającego
protokołu
jakościowego
gwarancyjne
polegać
oprogramowania
na
danej
będzie
wolne
od
dostawy.
na
W
przypadku
wymianie
wad,
okres
jeżeli
wadliwego
gwarancji
dla
świadczenie
elementu
tego
lub
elementu
(oprogramowania) biegł będzie na nowo od daty protokołu stwierdzającego tą
wymianę.
WG.2
Wymagany tryb zgłaszania awarii w trybie 24/7. Zgłoszenie następuje w drodze
pisemnej faksem lub mailem na adres podany przez Wykonawcę:
fax pod numer ..........................................
mail na adres
WG.3
..........................................
Wykonawca dokona usunięcia Awarii Niekrytycznej Systemu w terminie nie
dłuższym niż 24 godzin od momentu zgłoszenia Awarii Niekrytycznej ( usunięcie
Awarii Niekrytycznej rozumiane jest jako przywrócenie funkcjonalności Systemu
sprzed Awarii Niekrytycznej).
WG.4
Wykonawca dokona usunięcia Awarii Zwykłej Systemu w terminie nie dłuższym niż
72 godzin od momentu zgłoszenia Awarii Zwykłej (usunięcie Awarii Zwykłej
jest
jako
przywrócenie
funkcjonalności
Systemu
sprzed
Awarii
Zwykłej).
WG.5
Przez
usunięcie
każdej
Awarii
rozumie
się
rozwiązanie
problemu
lub
zaproponowanie procedury obejścia pozwalającej na funkcjonowanie Systemu bez
Strona 38
rozumiane
Kod
Opis wymagania
wymagania
rozwiązania problemu.
WG.6
Wykonawca dokona naprawy (lub wymiany elementu) w lokalizacji wskazanej
przez Zamawiającego; w przypadku konieczności dokonania naprawy poza
lokalizacją Zamawiającego, Wykonawca pokryje koszty transportu i ewentualnego
ubezpieczenia przedmiotu zamówienia do miejsca naprawy oraz jego zwrotu do
lokalizacji wskazanej przez Zamawiającego.
WG.8
Zamawiający dopuszcza realizację świadczenia gwarancyjnego w ten sposób, że
na podstawie informacji diagnostycznych przekazanych przez Zamawiającego
Wykonawcy podczas zgłoszenia awarii, Wykonawca prześle na swój koszt
zamiennik uszkodzonego elementu, natomiast fizycznej wymiany uszkodzonego
elementu
dokona
odpowiednio
przeszkolony
przez
Wykonawcę
pracownik
Zamawiającego, czyniąc to na ryzyko Wykonawcy. Jednakże taki tryb realizacji
naprawy
nie
zwalnia
Wykonawcy
z
obowiązku
zapewnienia
przywrócenia
pierwotnego stanu pracy systemu. Jeżeli dla dotrzymania założonego terminu
naprawy systemu konieczne jest dokonanie naprawy w siedzibie Zamawiającego,
Wykonawca jest zobowiązany do samodzielnego dokonania naprawy urządzenia
w siedzibie Zamawiającego.
WG.9
Gwarancja obejmuje również wykonanie przez Wykonawcę wszelkich czynności
związanych
oraz
z przywróceniem pierwotnego stanu pracy Systemu (sprzed Awarii)
pokrycie
przez
Wykonawcę
kosztów
części
zamiennych
użytych
do
przywrócenia Systemu do stanu pierwotnego (sprzed awarii).
WG.10
W
okresie
udostępni
gwarancji
Wykonawca
Zamawiającemu
dostarczonego
w
możliwość
oprogramowania
oferowanych przez producenta
ramach
otrzymanego
wielokrotnego
standardowego
do
wynagrodzenia
uaktualniania
całego
najnowszych
wersji
oprogramowania (włączając tzw. firmware),
a także dostęp do usług wsparcia technicznego właściwych dla danego produktu.
W przypadku, gdy dostęp taki wymaga podania nazwy użytkownika, hasła lub
numeru seryjnego Wykonawca dostarczy Zamawiającemu ww. przed podpisaniem
protokołu zdawczo-odbiorczego.
Zamawiający
dowolnych
zastrzega
sobie
producentów
prawo
oraz
do
dodawania
wymiany
nowych
zainstalowanych
komponentów
komponentów
samodzielnie lub z pomocą Wykonawcy bez utraty gwarancji na zakupiony sprzęt.
Zamawiający
będzie
dokonywał
wymiany
podzespołów
samodzielnie
po
wcześniejszym uzgodnieniu z Wykonawcą. Jeżeli Wykonawca nie udzieli zgody na
samodzielną wymianę lub dodanie podzespołów przez Zamawiającego, wówczas
jest obowiązany sam dokonać takiej wymiany lub dodania komponentów
w terminie 3 dni od zgłoszenia żądania przez Zamawiającego w ramach
wynagrodzenia otrzymanego za dostarczone elementy w ramach danej dostawy.
Strona 39
WG.11
5.14
Wymagania w zakresie zarządzanie projektem
Kod
Opis wymagania
wymagania
MGM.1
Wymaga się od Wykonawcy aby:

organizacja przedsięwzięcia związanego z przedmiotem zamówienia,

procesy kierujące przedsięwzięciem,

struktura i zawartość planów projektu,

techniki zarządzania projektem,

zestaw elementów sterujących zarządzaniem i jakością, w tym cała
tworzona dokumentacja,
zostały oparte o ogólnie znaną metodykę projektową lub własną uwzględniającą
konkretne
techniki,
narzędzia
i
notacje,
a także
zapewniającą
osiągnięcie
zamierzonych celów jakościowych przy jednoczesnej minimalizacji możliwości
niepowodzenia przedsięwzięcia.
W przypadku wykorzystywania przez Wykonawcę własnej metodyki zarządzania
przedsięwzięciem, wymaga się, aby uwzględniała ona co najmniej następujące
elementy:

sposób zarządzania projektem, w tym proces kontroli postępu prac
w zakresie kosztów, pracochłonności i zgodności z harmonogramem,
a także częstotliwości punktów kontrolnych, raportowanie o postępach
w realizacji projektu oraz sposób zarządzania problemami w realizacji
projektu,

proces przygotowania planu realizacji
przedsięwzięcia w tym planu
zapewnienia jakości przedsięwzięcia

analizę ryzyka przed rozpoczęciem projektu i zarządzanie ryzykiem
w trakcie jego realizacji,

sposób
zarządzania
konfiguracją,
w
tym
identyfikacja
elementów
konfiguracji, kontrola wersji, informowanie o zmianach,

sposób zarządzania zmianami, w tym rodzaje modyfikacji (poprawki,
aktualizacje, rozbudowa, udoskonalenia) oraz procedury kontroli zmian.
Strona 40
MGM.2

opis przedmiotu zamówienia (opz)

Transkrypt

Podobne dokumenty

Drukuj do PDF - Ministerstwo Zdrowia

Pogotowie_Zielona Góra

WYPOŻYCZALNIA SPRZĘTU MEDYCZNEGO Fundacja Piotra

opis przedmiotu zamówienia (opz)

Generuj PDF

Odpowiedzialność medyczna w Polsce i we Francji (polsko