Specyfikacja Techniczna 1. Założenia 2

Transkrypt

Załącznik 2 do SIWZ 11/ZP/2012
Specyfikacja Techniczna
1. Założenia
Projekt obejmuje rozbudowę funkcjonującego systemu informatycznego w SPZOZ RPR Sosnowiec ,
dalej: Pogotowie Ratunkowe, oraz wdrożenie i zintegrowanie systemu radiokomunikacyjnego. Projekt obejmuje
zakup niezbędnego sprzętu i oprogramowania oraz usługi rozbudowy oprogramowania. W ramach projektu :
a) rozbudowa oprogramowania będzie składać się z :
 Rozbudowy oprogramowania dyspozytorskiego MedDispatch
 Zakupu i konfiguracji stanowisk komputerowych dla Stacji Pogotowia Ratunkowego
 Stworzenia modułu rozliczeniowego dla Stacji Pogotowia Ratunkowego
 Rozbudowy oprogramowania Mapowego;
b) wdrożenie systemu radiokomunikacyjnego obejmuje :
 zakup paneli dla dyspozytorni
 zakup i wdrożenie oprogramowania do obsługi radiotelekomunikacji
 zakup oraz konfiguracje modułów radiowych dla Stacji Pogotowia Ratunkowego
 zintegrowanie systemu radiotelekomunikacyjnego z istniejącym oprogramowaniem
dyspozytorskim medDispatch
c) wykonanie przeszkolenia osób obsługi systemu.
2. Wymagania Szczegółowe
2.1. Rozbudowa oprogramowania
2.1.1. Rozbudowa oprogramowania dyspozytorskiego medDispatch
 Modyfikacja Karty zgłoszenia
o Dodać pole „Klatka” obok pól informacyjnych nr lokalu /posesji piętro.
o Ukryć pola : POI, GPS-długość, GPS-szerokość, Miejsce , wiek pacjenta, dane zgłaszającego.
o Po wybraniu z listy rozwianej „Rodzaj-POI” powinno się ukazać pole POI umożliwiające dodanie
opisu
o Pola GPS-Długość, GPS-szerokość, Miejsce, wiek pacjenta, dane zgłaszającego powinny się
pojawić po naciśnięciu przycisku „więcej
o W części „Decyzja „ po wybraniu z listy rozwijanej „decyzja” : ”Akceptacja wyjazdu” powinno się
pojawić pole umożliwiające zadysponowanie zespołu bezpośrednio z karty zgłoszenia.
o W razie zaznaczenia pola „odwołanie ZRM” w części „II-Podjęcie decyzji” na Karcie zgłoszenia
zostanie wyświetlone pole umożliwiające wpisanie powodów odmowy (pole jest obligatoryjne)
o Zlecenie powinno być wysłane do terminala karetki oraz na Stację Pogotowia Ratunkowego do
zaimplementowanego modułu rozliczeniowego.
o Wiadomość z Karty zgłoszenia, wysyłana do terminali w karetce, powinna zawierać minimalnie
dane z wypełnionych pól :
 Miasto
 Ulica
 Nr posesji/nr lokalu
 Klatka
 Piętro
 Opis zdarzenia
Strona 1 z 14
 Opis miejsca zdarzenia
 Dane pacjenta (imię i nazwisko)
 Telefon kontaktowy




Uprawniony pracownik Pogotowia Ratunkowego powinien mieć możliwość dodania lub
usunięcia pól z wiadomości wysyłanych do terminali .
o Po zapisaniu zgłoszenia automatycznie powinno zostać wywołane połączenie z
zadysponowanym zespołem na panelu dyspozytorskim do radiokomunikacji, ewentualna
trwająca rozmowa powinna zostać zawieszona. Funkcja powinna mieć możliwość włączania i
wyłączania przez administratora.
W oknie głównym na zakładce Zdarzenia : Lista za kolumną „Miejsce” dodać kolumny „powód
wezwania” oraz „zespół”, które będą pobierać dane z Karty zgłoszenia.
Dodanie na końcu kolumny „potwierdzenie przyjęcia” do tabeli „zdarzenia” w oknie „Aktualne
wyjazdy”
 Komórka będzie miała przypisany jeden ze stanów „potwierdzono” lub „nie
potwierdzono”
o Stan „potwierdzono” będzie mógł być ustawiony przy spełnieniu jednego z warunków:
 Potwierdzenie zostanie dokonane w module rozliczeniowym Stacji Pogotowia
Ratunkowego za pomocą karty RFID
 Potwierdzenie zostanie włączone przez dyspozytora po odbyciu rozmowy telefonicznej,
jeśli zespół był poza Stacją Pogotowia Ratunkowego i nie mógł potwierdzić przyjęcia
kartą.
o Niepotwierdzenie przez zespół lub dyspozytora w czasie 5 minut przyjęcia wyjazdu spowoduje
włączenie lekkiego alarmu: zlecenie zapali się na czerwono oraz włączy się trzykrotny sygnał
dźwiękowy na panelu dyspozytorskim. Po upływie kolejnych 10 minut uaktywni się twardy
alarm: ciągły 3s sygnał alarmowy oraz zostanie wysłany mail do Kierownika Dyspozytorni.
Moduł Administracyjny medDispatch
o Powinien być stworzony w tej samej technologii opierający się o jedną bazę danych,
wykorzystujący istniejący już system uprawnień
o zostanie wyposażony w funkcję zarządzania kartami RFID
o Dodawanie, usuwanie kart
o Dodawanie, usuwanie kart do istniejących użytkowników systemu
o Powinien umożliwić przeglądanie zdarzeń historycznych wraz z przypisanymi do zdarzenia
wyjazdami.
 Po wybraniu zakładki „Monitoring Zdarzeń” otrzymujemy tabelę z listą zdarzeń
 „Monitoring Zdarzeń” będzie udostępniał dane :
a) Uprawnieni użytkownicy będą mogli wybrać zdarzenie i zobaczyć szczegółowe
dane w nim zawarte (wszystkie dane wpisane przez dyspozytora podczas
przyjmowania zlecenia, uzupełnione czasy karetki wraz z danymi dotyczącymi
realizacji zlecenia, oraz mapą przejazdu karetki).
b) Dział techniczny karetek na liście będzie widział wszystkie wyjazdy karetek bez
danych z kart zlecenia wyjazdu, na mapie będzie widoczna trasa przejazdu karetki
z możliwością wyświetlenia takich informacji jak: prędkość w danym położeniu na
mapie, czas wyjazdu, czas powrotu, długość trasy, spalanie.
Logowanie do systemu medDispatch odbywać się będzie za pomocą karty RFID oraz
indywidualnego Hasła.
Strona 2 z 14
o Karta RFID będzie użytkowana w pierwszym etapie logowania do identyfikacji logującej się
osoby (automatycznego wyboru nazwy użytkownika).
o Hasło będzie wymagane do uwierzytelnienia osoby posiadającej kartę.
o Po zbliżeniu karty do czytnika system powinien ją odczytać i wyświetlić okno logowania
umożliwiające wpisanie hasła użytkownika przypisanego do karty, nazwa Użytkownika powinna
być wyświetlona nad polem do wpisywania hasła.
o Po prawidłowym zalogowaniu karta nie będzie musiała znajdować się w czytniku.
o Logowanie powinno następować raz do całego systemu MedDispatch (po zalogowaniu
powinna być dostępna część dyspozytorska oraz mapowa)
o W sytuacji awaryjnej (uszkodzenia, zgubienia karty) Kierownik dyspozytorni będzie posiadał
specjalną kartę (oznaczoną na czerwono) umożliwiającą ręczne wpisanie nazwy użytkownika i
hasła.
o Logowanie za pomocą specjalnej karty (oznaczonej na czerwono) powinno zostać odnotowane
w systemie, o tym fakcie powinien mailowo zostać powiadomiony Administrator (informatyk
RPR Sosnowiec)
o W razie braku czytnika w systemie (tj. gdy czytnik nie jest wykrywany przez medDispatch)
system automatycznie bez użycia karty umożliwi ręczne wpisanie nazwy użytkownika i hasła, o
tym fakcie powinien mailowo zostać powiadomiony Administrator (informatyk Pogotowia
Ratunkowego) z adnotacją „brak czytnika na stanowisku”.
o Po 12 godzinach pracy dyspozytora i braku aktywnego okna karty zgłoszenia (dyspozytor nie
przyjmuje w tym czasie zgłoszenia) powinno pojawić się okno z pytaniem, czy wylogować
użytkownika; w przypadku odpowiedzi negatywnej użytkownika, okno powinno się zamknąć, w
przypadku odpowiedzi pozytywnej - użytkownik powinien zostać wylogowany.
 Zmiana organizacji uprawnień w systemie względem Stacji Pogotowia Ratunkowego.
o Dyspozytorzy będą posiadali dostęp i możliwość przyjmowania zgłoszeń ze wszystkich i dla
wszystkich Stacji Pogotowia Ratunkowego.
o Dyspozytor nie będzie przypisywany do jednej z dyspozytorni (np. Sosnowiec, Zawiercie …),
ale jako dyspozytor będzie miał dostęp do przyjmowania zgłoszeń dla wszystkich Stacji
Pogotowia Ratunkowego.
 W systemie zostanie stworzona „Elektroniczna książka zgłoszeń”
o „Elektroniczna książka zgłoszeń” będzie zawierać tabelę z następującymi nagłówkami kolumn :
 Data (aktualna data w formacie dd-mm-rrrr, wpisywana automatycznie przez system
medDispatch)
 Nr bieżący (aktualny numer zdarzenia, jednoznacznie je identyfikujący, wpisywany
automatycznie przez system medDispatch)
 Godzina wezwania rozumiana jako czas zakończenia rozmowy (wpisywana automatycznie
przez system medDispatch, pobrana z panelu dyspozytorskiego)
 Godzina przekazania rozumiana jako czas zadysponowanie karetki (wpisywana
automatycznie przez system medDispatch, przesłana do terminala informacja o wizycie)
 Godzina wyjazdu (wpisywana automatycznie przez system medDispatch, pobrana z terminala
karetki po zmianie statutu karetki na „w drodze do pacjenta” )
 Godzina powrotu (wpisywana automatycznie przez system medDispatch, pobrana z terminala
karetki po zmianie statusu na „wolny w bazie” lub „wolny w trasie”)
 Miejsce wypadku (wpisywane automatycznie przez system medDispatch, pobrane z
odpowiedniego pola karty zgłoszenia wypełnianej przez dyspozytora)
Strona 3 z 14
 Przyczyny wezwania/objawy (wpisywane automatycznie przez system medDispatch, pobrane
z odpowiedniego pola karty zgłoszenia wypełnianej przez dyspozytora)
 Oznaczenie wzywającego (wpisywane automatycznie przez system medDispatch, pobrane z
odpowiedniego pola karty zgłoszenia wypełnianej przez dyspozytora)
 Oznaczenie pacjenta (wpisywane automatycznie przez system medDispatch, pobrane z
odpowiedniego pola „Karty Medycznych Czynności Ratunkowych”)
 Nr telefonu (wpisywane automatycznie przez system medDispatch, z panelu dyspozytorskiego
do radiokomunikacji)
 Rozpoznanie/ przyczyny wypadku (wpisywane automatycznie przez system medDispatch,
pobrane z pól części III-Rozpoznanie „Karta Medycznych Czynności Ratunkowych”)
 Dalsze postępowanie z chorym (wpisywane automatycznie przez system medDispatch,
pobrane z pól części II-Podjęcie Decyzji „Karta Zlecenia Wyjazdu Zespołu Ratownictwa
Medycznego”)
 Imię i nazwisko przyjmującego oraz podpis (pole do wypełnienia w górnej części tylko
imieniem, nazwiskiem i identyfikatorem dyspozytora, po wydrukowaniu w tym miejscu
dyspozytor wbija pieczątkę i składa podpis)
 Zadysponowany ZRM (wpisywane automatycznie przez system medDispatch, pobrany skład
zespołu, który został zadysponowany do wezwania, na pierwszym miejscu kierownik zespołu,
na ostatnim kierowca oraz typ karetki P lub S i jej numer np. S1)
 Uwagi (wpisywane automatycznie przez system medDispatch, pobrane z pól części IVPostępowanie z Pacjentem „Karta Medycznych Czynności Ratunkowych” : Zastosowane Leki
 Zostanie utworzony grafik dyspozytorów
o Powinien być stworzony w tej samej technologii oraz powinien opierać się na jednej bazie
danych i wykorzystywać istniejący już system uprawnień
o Powinien posiadać funkcjonalność co najmniej taką, jak używany grafik zespołów ratunkowych
 Zmianie ulegnie numeracja zgłoszeń/zdarzeń/wyjazdów – wspólna dla całego systemu niezależnie
od Stacji Pogotowia Ratunkowego i dyspozytorni
 Rozbudowany zostanie system odsłuchiwania rozmów tak, aby panel do odsłuchiwania wszystkich
rozmów był integralną częścią systemu.
2.1.2. Zakup i konfiguracje stanowisk komputerowych dla Stacji Pogotowia Ratunkowego
 Jedno stanowisko dla Stacji Pogotowia Ratunkowego składa się z :
o Jednostki centralnej (komputer)
o Jednego monitora
o Czytnika kart RFID
o Klawiatury i myszki
o Modułu radiowego
 Wymagania techniczne dla jednostki centralnej
 Komputer klasy PC
 Zainstalowany system Linux lub równoważny
Procesor
Pamięć RAM
Min 2 rdzenie, min 3,10 GHz , min 3 MB cache
Min 4096 MB (DIMM DDR3, 1333 MHz) z możliwością
Strona 4 z 14
rozszerzenia do min 16 GB
Ilość gniazd pamięci
Karta graficzna
Dysk twardy
Wbudowane napędy
Dodatkowe chłodzenie
Zasilacz
Min 4
Min 512 MB, umożliwiająca podłączenie 2 monitorów, obsługującą
min DirectX 11, OpenGL 3.1, min częstotliwość podstawowa
układu graficznego 600MHz
Min 250 GB SATA 7200 obr.
DVD+/-RW DualLayer
Wentylator wewnętrzny min 92mm
min 350 W, PFC: aktywne, poziom hałasu max 40 dB
Karta muzyczna
Zintegrowana karta dźwiękowa zgodna / lub zewnętrzna
Karta sieciowa
10/100/1000 Mbps
Wi-Fi 802.11 b/g/n
Rodzaje wejść/wyjść - panel
przedni
Rodzaje wejść/wyjść - panel tylni
Porty wewnętrzne
min 1x wejście mikrofonowe
min 1x wyjście słuchawkowe/głośnikowe
min 2x USB 2.0
min 2x USB 3.0
min 1x HDMI
min 1x RJ45 (LAN)
min 1x VGA (D-sub)
min 1x wyjście słuchawkowe/głośnikowe (S/PDIF)
min 2x USB 3.0
min 4x USB 2.0
min 1x PCI-E x16
min 1x SATA II
min 2x kieszeń wewnętrzne 3,5"
min 2x kieszeń zewnętrzna 5,25"
min 2x miniPCI
min 3x PCI-E x1
min 3x SATA III
Dodatkowe informacje
Gwarancja 36 miesięcy oraz wymiana sprzętu następnego dnia
roboczego
Akcesoria
Kabel zasilający, Klawiatura, Mysz optyczna, głośniki min 1 W z
wbudowanym zasilaczem
 Wymagania techniczne Monitorów
Typ matrycy
Przekątna ekranu
Format obrazu
TFT IPS (In-Plane Switching)
Min 21”
Panoramiczny 16:9
Strona 5 z 14
Nominalna
rozdzielczość
Min 1920 x 1080 FULLHD
Wielkość plamki
Min 0.265 mm
Jasność
Min 300 cd/m2
Czas reakcji
Min 8ms (GTG)
Kąt widzenia w
poziomie
Min 178 st
Kąt widzenia w
pionie
Min 178 st
Liczba
wyświetlanych
kolorów
Min 16.7 milionów
Rodzaje wyjść /
wejść
Min 1x D-Sub
min 1x DisplayPort (DP)
min 1x DVI-D (z HDCP)
min 1x VGA
Obrotowy ekran typu
Tak
pivot
Regulacja podstawy Tak
Regulacja wysokości Tak
Wbudowany hub
USB
Tak
 Wymagania kart RFID i
o Karty Clamshel l UNIQUE
o Częstotliwość pracy 125kHz
o kompatybilne z systemami Roger EMC-2, Satel KT-STD-2
o Modulacja ASK
o Kodowanie Manchester
 Czytniki kart
o Kompatybilne z wyżej wymienionymi kartami.
 Konfiguracja obejmuje również konfigurację wszystkich urządzeń peryferyjnych na potrzeby
systemu takich jak :
o Czytniki kart RFID
o Drukarki
Stworzenie
modułu rozliczeniowego dla Stacji Pogotowia Ratunkowego
2.1.3.
 Moduł rozliczeniowy musi być integralną częścią systemu medDispatch, stworzony w tej samej
technologii oraz oparty na jednej bazie danych, wykorzystujący istniejący już system uprawnień
Strona 6 z 14
 Moduł rozliczeniowy musi działać w całości w oparciu o przeglądarkę internetową niezależnie od
systemu operacyjnego zainstalowanego na komputerze; musi działać na systemach z rodziny
Windows, Linux oraz MAC
 Moduł rozliczeniowy musi być zintegrowany z czytnikami kart RFID dostarczonymi na potrzeby
rozbudowy systemu.
 Moduł rozliczeniowy będzie posiadał w oknie dwie tabele, tabela „Wyjazdy Oczekujące” oraz tabelę
„Rozliczenie wyjazdów”.
o W tabeli „Wyjazdy Oczekujące” znajdować się będą w wierszu: zlecenia wyjazdów następujące informacje :
 Nazwa zespołu
 Priorytet (K1,K2, W, T …)
 Karetka (P1, S1, …)
 Numer ID zlecenia
o W tabeli „Rozliczenie Wyjazdów” znajdować się będą w wierszu: nierozliczone zlecenia
wyjazdów – następujące informacje:
 Nazwa zespołu
 Priorytet (K1,K2, W, T …)
 Karetka (P1, S1, …)
 Numer ID zlecenia
o Nierozliczone zlecenie będzie się wyświetlać dopiero po potwierdzeniu przyjęcia zlecenia przez
dyspozytora w panelu dyspozytorskim lub przez osobę z zespołu karetki za pomocą karty w
module rozliczeniowym.
o Aby potwierdzić zlecenie program rozliczeniowy
 Będzie oczekiwał na zbliżenie karty RFID osoby z zespołu, który otrzymał zlecenie.
 Po odczytaniu karty wyszuka, czy dany zespół ma zlecenie wyjazdu; jeśli tak - wyświetli
informacje na zielono „Potwierdzono” na 3s wraz z 1 sekundowym dźwiękiem i zamknie
okno informacyjne; jeśli zespół nie ma wyjazdów - wyświetli informacje na czerwono
„Brak aktualnych wyjazdów” z podwójnym sygnałem dźwiękowym 2 sekundowym .
o Niepotwierdzenie przez zespół lub dyspozytora w czasie 5 minut przyjęcia wyjazdu spowo duje
włączenie lekkiego alarmu: w tabeli „Wyjazdy Oczekujące” zlecenie zapali się na czerwono
oraz włączy się trzykrotny 0,5s sygnał dźwiękowy z głośników komputera . Po upływie kolejnych
10 minut uaktywni się twardy alarm: ciągły 5s sygnał alarmowy
 Zostanie utworzona elektroniczna Karta Medycznych Czynności Ratunkowych; karta powinna
zawierać minimalnie wszystkie pola zawarte w aktualnie obowiązującym rozporządzeniu
(Dz.U.2011.125.712 załącznik nr 4) „KARTA MEDYCZNYCH CZYNNOŚCI RATUNKOWYCH” z
włączeniem części:
 III-REALIZACJA ZLECENIA
 IV-ZGON
 V-PODSUMOWANIE
z „KARTY ZLECENIA WYJAZDU ZESPOŁU RATOWNICTWA MEDYCZNEGO”
o System powinien umożliwić wypełnienie karty wymaganymi danymi oraz jej wydruk
o Każde z pól II-części „Karty Medycznych Czynności Ratunkowych” powinno zawierać dwa
dodatkowe pola
Strona 7 z 14
 „nie badano” z możliwością zaznaczenia (po zaznaczeniu tego pola uaktywni się wiersz z
możliwością wpisania przyczyn braku badania, resztę komórek pola będzie wyszarzała i
zablokowana, bez możliwości wypełnienia)
o Pole „czynności” z IV-części „Karty Medycznych Czynności Ratunkowych” powinno zawierać
dwa dodatkowe pola
 „nie wykonano” z możliwością zaznaczenia (po zaznaczeniu tego pola uaktywni się wiersz z
możliwością wpisania przyczyn braku czynności, resztę komórek pola będzie wyszarzała i
zablokowana, bez możliwości wypełnienia)
o Pole „Dane Pacjenta” z V-części „Karty Medycznych Czynności Ratunkowych” powinno
zawierać dodatkowe pola
 „Brak Danych” z możliwością zaznaczenia
 Pacjent NN
 INNE
o Elektroniczna „Karta Medycznych Czynności Ratunkowych” powinna być stworzona w tej
samej technologii i opierać się na jednej bazie danych, oraz wykorzystywać istniejący już
system uprawnień.
2.1.4. Rozbudowa oprogramowania Mapowego
 Zmiana map Desktopowych na mapy Webowe przy wykorzystaniu posiadanej przez Pogotowie
Ratunkowe licencji.
 Moduł Mapowy musi działać w całości w oparciu o przeglądarkę internetową niezależnie od
systemu operacyjnego zainstalowanego na komputerze; musi działać na systemach z rodziny
Windows, Linux oraz MAC
 Moduł Mapowy musi być integralną częścią systemu medDispatch, stworzony w tej samej
technologii i opierać się na jednej bazie danych, oraz wykorzystywać istniejący już system
uprawnień
 Zalogowanie się do systemu medDispatch powinno powodować jednoczesne zalogowanie się do
Modułu Mapowego.
 Funkcje Modułu Mapowego
o Prezentacja warstwowego podkładu mapowego
o Zarządzanie warstwami (włączanie, wyłączanie, dodawanie nowych warstw)
o Skalowanie mapy, w tym przybliżanie, centrowanie do obiektów widocznych na mapie, w
szczególności pojazdów oraz zdarzeń. Możliwość powiększenia konkretnego obszaru mapy
przez zaznaczenie tego obszaru.
o Prezentacja współrzędnych geograficznych elementów wskazanych kursorem myszy.
o Prezentacja listy pojazdów z graficznym oraz opisowym rozróżnieniem ich statusów, oraz
możliwością prezentacji szczegółowych informacji na temat ich bieżącego stanu (zarówno na
liście, jak i w postaci „dymku” przy konkretnym pojeździe). Możliwość zarządzania, które
pojazdy są widoczne na mapie, a które nie.
o Prezentacja aktualnego położenia pojazdów na mapie wraz z możliwością śledzenia wybranego
pojazdu (mapa podąża za oznaczonym pojazdem)
o Definiowanie okresu czasu, z jakim na mapie odświeżane są dane. Odświeżane mają być tylko
te warstwy, które ulegają zmianie.
o Prezentacja aktualnego położenia zdarzeń na mapie z graficznym oraz opisowym
rozróżnieniem ich stanów (przyjęte, zadysponowane, zakończone, odwołane), oraz z
możliwością prezentacji szczegółowych informacje na temat ich bieżącego stanu.
Strona 8 z 14
o Pełna integracja z częścią dyspozytorską systemu, a w szczególności z listą zdarzeń oraz
aktualnych zdarzeń, umożliwiająca wskazanie danego zdarzenia na mapie.
o Możliwość wyszukiwania na mapie zdarzeń, oraz obiektów mapowych wraz z możliwością ich
identyfikacji na mapie czyli prezentacja informacji opisowych.
2.2. Wdrożenie systemu radiokomunikacyjnego
2.2.1. Zakup 7 (siedem) paneli dyspozytorskich, w których skład wchodzą:
• zintegrowane konsole dyspozytorskie - monitor dotykowy od 22” do 27” i komputer w jednej
obudowie - łatwe w instalacji i obsłudze
• Mikrofon biurkowy o parametrach: przycisk nadawania PTT, podłączony do komputera przez port
RS-232 lub USB, zasilanie dodatkowe, regulacja wzmocnienia na obudowie
• Słuchawki z mikrofonem (jednogłośnikowe), kablowe, dedykowane do systemów dyspozytorskich o
podniesionej wytrzymałości (np. metalowa obejma na głowę),
• Z systemem Linux lub równoważnym
2.2.2. Wymagania dotyczące oprogramowania do obsługi radiotelekomunikacji zainstalowanego na
konsolach dyspozytorskich












Komunikacja pomiędzy modułem zdalnego sterowania łącznością radiową a pulpitem
dyspozytorskim w technologii IP.
Możliwość jednoczesnego prowadzenia rozmowy z wykorzystaniem łącza radiowego,
telefonicznego interkomu oraz prowadzenia podsłuchu radiowego.
Funkcje umożliwiające obsługę połączeń radiowych i monitoringu środków radiowych:
o
obserwowanie stanu sygnałów PTT i SQUELCH w danym kanale radiowym,
o
rejestracja rozmów,
o
wybór kanału pracy radiostacji,
o
wybór trybu pracy (nasłuch, nadawanie-odbiór),
o
wybór grup w radiotelefonie.
Zestaw rejestrujący lokalną korespondencję.
Rejestracja rozmów radiowych zawiera co najmniej:
o
ID radiotelefonu,
o
nr kanału, na którym prowadzona jest rozmowa,
o
godzinę rozpoczęcia i zakończenia rozmowy,
o
czas rozmowy,
o
identyfikator nagrania.
Integracja środków łączności radiowej różnych standardów i typów (analogowe, cyfrowe).
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.
Podczas zmiany kanału radiowego przez dyspozytora jest dostępna sygnalizacja (z podaniem
nazwy stanowiska dyspozytorskiego, które dokonało zmiany) na pozostałych konsolach
dyspozytorskich posiadających dostęp do ww. radiotelefonu.
Konsola umożliwia dyspozytorowi dynamiczne tworzenie grupy radiotelefonów,
Konsola zapewnia regulację głośności sygnalizacji dźwiękowej.
Wszystkie komunikaty, ostrzeżenia i opisy wyświetlane na konsoli są w języku polskim.
Administrator systemu ma możliwość nadawania odpowiednich uprawnień poszczególnym
konsolom, grupom dyspozytorów i użytkownikom uprzywilejowanym.
Strona 9 z 14



Obsługa interkomu do szybkiej łączności pomiędzy operatorami.
Obsługa lokalnej i globalnej książki telefonicznej.
Obsługa pozwalająca na realizacje połączeń crossconect (połączenie radiostacji z telefonem) i
crossband (połączenie dwóch radiostacji).

Obsługa historii zdarzeń telefonicznych, radiowych, SMS, statusów i alarmów.

Obsługa alarmów urządzeń oddalonych

Zmiana konfiguracji aplikacji nie może powodować jej restartu i nie ma być odczuwalna z
punktu widzenia użytkownika.

Oprogramowanie konsoli musi umożliwiać wykonanie wszystkich czynności telefonicznych i
radiowych wprost z ekranu dotykowego.

W zakresie obsługi konwencjonalnych radiotelefonów bazowych (analogowych) konsola ma
zapewnić:
o wizualizację stanu nadawania (PTT) i odbioru;
o sterowanie zmianą kanałów;
o otwarcie blokady szumów, wyłączenie kodowej blokady szumów (ctcss,dcs);
o wyświetlanie nazwy kanału – 12 znakowy opis kanału;
o wyświetlanie nazwy grupy przypisanej odebranemu kodowi ctcss;
o uruchomienie skaningu, skaningu z priorytetem;
o odbiór wywołań Select V – wyświetlanie ANI rozmówcy;
o generacja wywołań SELECT V - z listy kontaktów lub klawiatury numerycznej;
o wybór grup w radiotelefonie;
o realizacja funkcji odbioru zbiorczego na podstawie poziomu RSSI mierzonego w stacji
bazowej;
 W zakresie obsługi radiotelefonów cyfrowych systemu FDMA konsola ma zapewnić co najmniej:
o ustawienie (zmiana) kanału pracy;
o wywołania indywidualne i grupowe, identyfikacja rozmówcy;
o wysyłanie/ odbiór informacji tekstowych do stacji mobilnych systemu FDMA;
o odbiór informacji telemetrycznych od stacji ruchomych systemu FDMA;
o odbiór pozycji GPS od stacji ruchomych systemu FDMA i ich wizualizacja na mapie cyfrowej;
o zapewnienie obsługi pełnej sygnalizacji cyfrowej wbudowanej w system FDMA w relacji ze
stacjami ruchomymi : sprawdzenie obecności abonenta w sieci, obsługa wywołań alarmowych,
o blokada/odblokowanie stacji ruchomej
 interfejs użytkownika dostosowywany do wymagań użytkownika oraz konsola wyposażona w
edytor umożliwiający samodzielną konfiguracje GUI
 centralna i lokalna książka telefoniczna
 zintegrowany system rejestracji rozmów radiotelefonów oraz telefonów stacjonarnych i GSM, z
możliwością oparcia tej funkcjonalności wyłącznie o komputer konsoli dyspozytora.
 możliwość realizacji przez moduł radiokomunikacyjny funkcji „przemiennika radiowego”
wyposażonego w dwa radiotelefony,
 wersje mobilne konsoli dyspozytorskiej instalowane na tabletach
 dostępny interfejs API dla integracji z aplikacjami zewnętrznymi ( np. WCPR)
• Możliwość zdalnej obsługi radiotelefonu i realizowania wywołań głosowych
• Musi posiadać interfejs i dokumentację w języku polskim
• Musi wyświetlać historię wywołań oraz umożliwiać szybkie odsłuchanie dowolnej ich części. Pliki
dźwiękowe z zapisem rozmów powinny być rejestrowane na komputerze dyspozytora. Powinna być
możliwość eksportu treści rozmowy do formatu WAV lub MP3
Strona 10 z 14
• Musi obsługiwać wysyłanie i odbiór wiadomości tekstowych w trybie cyfrowym
• Musi udostępniać funkcje zarządzania siecią radiotelefonów:
o blokowanie wybranego radiotelefonu
o sprawdzanie dostępności wybranego radiotelefonu (możliwość utworzenia zobrazowania
graficznego statusów dla radiotelefonów bazowych i przewoźnych w oprogramowaniu
dyspozytora – status radiotelefon dostępny, status radiotelefon niedostępny w sieci; możliwość
utworzenia mapy lub listy z graficznym zobrazowaniem statusów radiotelefonów bazowych w
sieci, w tym dane odnośnie braku zasilania i otwarcia szafy teletechnicznej)
o zdalne włączenie nadawania wybranego radiotelefonu
o przerywanie trwających wywołań z pozostałych radiotelefonów w sieci
• Musi mieć możliwość konfigurowania dedykowanych przycisków PTT. Po naciśnięciu takiego
przycisku radiotelefon będzie nadawał na określonym kanale, w określonej strefie oraz w
określonym typie wywołania (prywatny, grupowy). Po zakończeniu wywołania za pomocą takiego
przycisku radiotelefon ma się znajdować na kanale, na którym był przed wywołaniem
• Musi mieć możliwość dynamicznego połączenia wybranych radiotelefonów przez obsługującego
aplikację dyspozytora. Połączone radiotelefony mają przekazywać wywołania głosowe pomiędzy
sobą
• Musi mieć możliwość ustanowienia grupy radiotelefonów bazowych pracujących w trybie
analogowym (bez skaningu), z wykorzystaniem techniki porównania siły sygnału przychodzącego i
przekazania audio wyłącznie z radiotelefonu o najwyższej sile sygnału przychodzącego oraz
odpowiedzi dyspozytora automatycznie przez ten sam radiotelefon
• Musi mieć możliwość pracy kilku użytkowników w odległych lokalizacjach na pojedynczym
radiotelefonie z możliwością bezpośredniej komunikacji głosowej pomiędzy nimi (interkom) oraz
przesyłania wiadomości tekstowych pomiędzy nimi (tzw. „czat” pomiędzy dyspozytorami). Każdy z
nich ma słyszeć pełną korespondencję głosową prowadzoną przez radiotelefon (łączenie z
wywołaniami innych użytkowników obsługujących ten radiotelefon)
• Musi mieć możliwość integracji z centralą telefoniczną (sygnalizacja SIP), w tym skonfigurowania
dowolnej ilości połączeń linii telefonicznych VOIP centrali telefonicznej z radiotelefonami.
• Z uwagi na niezawodność systemu, na komputerze konsoli dyspozytorskiej powinien być
zintegrowany serwer usług głosowych umożliwiający realizację minimum 20 równoległych połączeń
VOIP (SIP). Całość komunikacji VOIP pomiędzy wszystkimi dostarczanymi elementami systemu
dyspozytorskiego powinna być oparta o w/w aplikację serwerową zainstalowaną na konsoli. Oprócz
konsoli dyspozytorskiej oraz modułów radiowych nie powinno być wymagane żadne dodatkowe
urządzenie (np. radioserwer)
• Musi mieć wizualny konfigurator wyglądu okna konsoli, pozwalający na określenie wymiarów i
położenia elementów konsoli. Możliwość wizualnej konfiguracji powinna być dostępna dla
administratora Pogotowia Ratunkowego po odpowiednim przeszkoleniu
• Musi mieć możliwość uruchamiania w konfiguracji nie wyświetlającej systemowych ramek okien
oraz uniemożliwiającej użytkownikowi przesuwanie lub zamykanie okien konsoli
• Musi mieć możliwość wizualizowania i alarmowania o stanie otoczenia radiotelefonu wyniesionego,
sygnalizacja otwarcia szafki z radiotelefonem wyniesionym, sygnalizacja pracy radiotelefonu z
akumulatora (brak zasilania sieciowego)
• Musi mieć możliwość niezależnej od systemu operacyjnego regulacji poziomu dźwięku dla każdego
z radiotelefonów wyniesionych
• Musi mieć możliwość pracy w środowisku Windows i Linux z wykorzystaniem typowego sprzętu
informatycznego
Strona 11 z 14
• Radiotelefony muszą mieć możliwość zdalnego programowania parametrów w ramach
dostarczonego systemu
• Klawiatura do wyboru połączeń SIP
• Ustawienia dla zdarzeń wiadomości tekstowych – zdarzenia typu wiadomość tekstowa można
skonfigurować według wszystkich dostępnych opcji dla zdarzeń
• System umożliwia zapisywanie danych w typowych silnikach bazodanowych
• System musi umożliwiać zdalne programowanie radiotelefonów
2.2.3. Zakup oraz konfiguracje modułów radiowych dla Stacji Pogotowia Ratunkowego
 system radiowy cyfrowo analogowy
 moduły radiowe integrujące w jednej obudowie 2U: radiotelefon, sterownik, mikrokomputerowy,
zasilanie,
 moduły radiowe obsługują analogowo cyfrowe systemy radiowe w technologii FDMA i TDMA,
 moduły radiowe obsługują radiotelefony analogowe, analogowo cyfrowe oraz cyfrowe TETRA
 obsługiwane radiotelefony takich producentów jak: Motorola (MotoTRBO), ICOM (IDAS),
Kenwood (NXDN), Sepura,
 W obudowie interfejsu radiowego ma być zamontowany : radiotelefon, zasilacz oraz interfejs bramy
radiowej. Całość ma umożliwić montaż w szafie 19”;
 Zakres temperatury pracy od -20°C do + 60°C;
 Zakres temperatury składowania od -40°C do +65°C;
 Spełnianie normy ETSI EN 300 086 oraz norm w zakresie drgań, wstrząsów, zapylenia, wilgotności,
deszczu i promieniowania słonecznego;
 Zasilanie 12 V lub 24 V (minus na masie); gdy urządzenie jest zasilane sieciowo 230 V /50 Hz, musi
posiadać system automatycznego bezzwłocznego przełączenia z zasilania sieciowego na
rezerwowe 12 V lub 24 V zapewniające ciągłą pracę radiotelefonu. Czas pracy na zasilaniu
rezerwowym min. 8 godzin przy stosunku Stdby/Rx/Tx: 80%/10%/10%. Zabezpieczenie
przepięciowe i przed odwrotnym podłączeniem biegunów zasilania podstawowego i rezerwowego;
 Radiotelefony mają mieć zagwarantowane zabezpieczenie zasilania przy braku sieci 230 V
 Parametry ogólne radiotelefonów
o Pasmo pracy 136 do 174 MHz;
o Ilość kanałów : minimum 250;
o Odstęp międzykanałowy minimum 12,5 kHz i 6,25 kHz w trybie cyfrowym
o Impedancja antenowa 50 Ω (dla WFS < 2:1);
o Wyświetlacz LCD;
o Protokół cyfrowy ETSI: EN 300 086, EN 300 113, EN 300 219, EN 301 489, EN 301 166;
 Parametry techniczne nadajnika
o Moc wyjściowa nadajnika w.cz. programowana w zakresie od 1 w do 45W;
o Możliwość ustawienia poziomu mocy (w trybie serwisowym)
o Dewiacja sygnału CTCSS 250 ± 50 Hz (dla odstępu 12,5 kHz)
o Charakterystyka pasma akustycznego (+1, -3 dB)
o Łączne zniekształcenia modulacji < 5%
o Całkowity przydźwięk i szumy własne < -40 dB
o Stabilność częstotliwościowa <=2,3 ppm
 Parametry techniczne odbiornika
o Współczynnik zawartości harmonicznych < 3 %
Strona 12 z 14
o Charakterystyka pasma akustycznego (+1, -3 dB)
 Dostarczenie jednego zestawu do programowania oraz strojenia radiotelefonów, obejmującego
wszystkie niezbędne elementy umożliwiające zaprogramowanie dostarczonych radiotelefonów, np.
dedykowane oprogramowanie producenta wraz z licencją, przewody, interfejs; przeszkolenie
wskazanych pracowników Pogotowia Ratunkowego z podstaw programowania dostarczonych
radiostacji, umożliwiających pracownikowi między innymi dołączenie radiostacji do działającego
systemu.
systemu
radiotelekomunikacyjnego
z
istniejącym
oprogramowaniem
2.2.4. Zintegrowanie
dyspozytorskim MedDispach
2.2.5. Wymagania w zakresie wdrożenia
 Wykonawca dokona dostawy sprzętu oraz uruchomienia systemu składającego się z elementów
wymienionych wyżej
według ustalonego między Pogotowiem Ratunkowym a Wykonawcą
harmonogramu oraz sposobu wdrożenia.
 Wykonawca musi dostarczyć wszystkie składniki niezbędne do poprawnego funkcjonowania
opisanego systemu, które zapewnią kompletność rozwiązania. Jeśli Pogotowie Ratunkowe w
niniejszej specyfikacji nie zawarło wystarczająco dokładnego opisu danego rozwiązania, a
Wykonawca nie zwróci się na piśmie o jego wyjaśnienie przed złożeniem oferty, ewentualne
wątpliwości będą interpretowane na korzyść Pogotowia Ratunkowego.
 Wszystkie składniki systemu muszą prawidłowo współpracować tworząc wysoko niezawodną
strukturę techniczno – organizacyjną, służącą do obsługi systemu łączności radiowej Pogotowia
Ratunkowego.
 Wykonawca zapewni należyte wykonanie zamówienia i prawidłowe funkcjonowanie dostarczonego
sprzętu i oprogramowania, stanowiącego element wyposażenia dyspozytorni Pogotowia
Ratunkowego.
 Oferowane urządzenia muszą:
o pochodzić z bieżącej linii produktowej, tzn. nie mogą się znajdować na liście produktów, które w
ciągu 2 lat od wykonania zamówienia przestaną być wspierane przez producenta,
o być „fabrycznie nowe” przez co rozumie się, że nie będą starsze niż 6 miesięcy od daty
produkcji,
o nie mogą być wcześniej używane w innych projektach.
 Wraz ze sprzętem Wykonawca zobowiązany jest dostarczyć:
o instrukcje obsługi, oprogramowania i konfiguracje w języku polskim sterowników oraz
oprogramowania do konfiguracji i oprogramowania, wraz z niezbędnymi kablami i interfejsami,
o karty gwarancyjne Wykonawcy lub producentów sprzętu,
o niezbędne certyfikaty, atesty i homologacje.
 Urządzenia nie mogą być zabezpieczone plombami gwarancyjnymi („stickerami”) lub w inny sposób,
których zerwanie przez użytkownika powoduje utratę gwarancji.
 Wykonawca przeszkoli dwóch przedstawicieli Pogotowia Ratunkowego z podstawowych czynności
serwisowych sprzętu.
 Najpóźniej w dacie protokolarnego odbioru wykonania zamówienia Wykonawca przekaże Pogotowiu
Ratunkowemu wykaz wszystkich loginów i haseł administracyjnych, użytych do zabezpieczenia
dostarczonych systemów i urządzeń.
 Wykonawca zobowiązuje się do przejęcia obowiązków gwarancyjnych po poprzednim twórcy
systemu w zakresie gwarancji na sprzęt, jak i gwarancji na oprogramowanie.
Strona 13 z 14
2.2.6. Wykonawca zobowiązany jest przeszkolić dyspozytorów, administratorów i członków zespołów
ratownictwa medycznego z wprowadzonych zmian w systemie.
2.2.7. System wdrażany będzie etapami do końca roku 2013
2.2.8. Zakup sprzętu obejmie 12 (dwanaście) stanowisk komputerowych w Stacjach Pogotowia
Ratunkowego oraz 7 (siedem) stanowisk dyspozytorskich w 2 dyspozytorniach :
 5 Stanowisk w Dyspozytorni Głównej
 2 Stanowiska w Dyspozytorni Zapasowej
 300 kart RFID
2.2.9. System musi posiadać możliwość wymiany danych z SIWCPR poprzez interfejs opisany w " OPIS I
SPECYFIKACJA INTERFEJSU DO SYSTEMÓW DZIEDZINOWYCH W WERSJI 5.9” którego
aktualną wersję można znaleźć http://sipr.eu.
 Kompatybilność z aktualną SPECYFIKACJĄ INTERFEJSU DO SYSTEMÓW DZIEDZINOWYCH,
system musi posiadać w każdym etapie wdrożenia począwszy od wdrożenia w Dyspozytorni
głównej).
i
nie dopuszczamy możliwości kart pracujących w innych częstotliwościach oraz nie kompatybilnych z systemami Roger
EMC-2, Satel KT-STD-2 z powodu posiadanego w wynajmowanym budynku systemu elektronicznego dostępu który bazuje
na kartach pracujących w tych standardach
Strona 14 z 14

Specyfikacja Techniczna 1. Założenia 2

Transkrypt

Podobne dokumenty

Wymagane dokumenty potwierdzające spełnianie

Kwota pobrania z przeniesienia do przeniesie

Załącznik nr 1 do SIWZ - Opis Przedmiotu