Podsumowanie Prac Zespołu ds. Rozwoju SWD PRM

Transkrypt

Zespołu do spraw rozwoju SWD PRM
SYSTEMU WSPOMAGANIA DOWODZENIA Prace
PAŃSTWOWEGO
XI 2015 r. – VI 2016 r.
PODSUMOWANIE PRAC
ZESPOŁU DO SPRAW ROZWOJU
RATOWNICTWA MEDYCZNEGO (SWD PRM)
W OKRESIE:
LISTOPAD 2015 r. – MARZEC 2016 r.
Opracował
Zespół ds. rozwoju SWD PRM
Zatwierdził
Podsekretarz Stanu w Ministerstwie Zdrowia
Pan Marek Tombarkiewicz
Przewodniczący Zespołu
…………………………………..
…………………………………..
………………………………….
………………………………….
(data)
(data)
(podpis i pieczęć)
(podpis i pieczęć)
str. 1 z 82
Prace Zespołu do spraw rozwoju SWD PRM
XI 2015 r. – VI 2016 r.
Spis treści
Powołanie Zespołu ds. rozwoju SWD PRM ............................................................................... 4
Członkowie Zespołu ds. rozwoju SWD PRM ............................................................................. 4
Zadania Zespołu ds. rozwoju SWD PRM ................................................................................... 5
Opisy funkcjonalności dla potrzeb projektu SWD PRM 2.0 ...................................................... 12
Specyfikacja zmiany nr: 1 (1) ............................................................................................... 12
Specyfikacja zmiany nr: 5 (10) ............................................................................................. 18
Specyfikacja zmiany nr: 10 (93) ........................................................................................... 31
Specyfikacja zmiany nr: 13.0 (99-0) ..................................................................................... 35
Specyfikacja zmiany nr: 17 (2 .............................................................................................. 42
str. 2 z 82
XI 2015 r. – VI 2016 r.
Specyfikacja zmiany nr: 28 (100) ......................................................................................... 58
Specyfikacja zmiany nr: 41 (230) ....................................... Błąd! Nie zdefiniowano zakładki.
Specyfikacja zmiany nr: 43 (237) ....................................... Błąd! Nie zdefiniowano zakładki.
Załączniki do niniejszego opracowania:
ZAŁĄCZNIK NR 1 – dotyczy specyfikacji zmiany nr 1
ZAŁĄCZNIK NR 2 – dotyczy specyfikacji zmiany nr 23
str. 3 z 82
XI 2015 r. – VI 2016 r.
Niniejsze opracowanie stanowi podsumowanie prac Zespołu ds. rozwoju SWD PRM
zrealizowanych w okresie od momentu powołania Zespołu – 11 listopada 2015 r.
do końca marca 2016 r.
Powołanie Zespołu ds. rozwoju SWD PRM
SWD PRM w wersji 1.0 został wytworzony – dzięki wsparciu z Programu Operacyjnego Innowacyjna
Gospodarka – w ramach projektu pn. System Informatyczny Powiadamiania Ratunkowego (SIPR), który
był realizowany przez Centrum Cyfrowej Administracji (CCA) i zakończył się w dniu 31 grudnia 2015 r.
Z uwagi na uwarunkowania, w jakich był realizowany projekt budowy SWD PRM 1.0 – w szczególności
ograniczenia czasowe i finansowe – zbudowany w latach 2014-2015 system nie zaspokaja wszystkich
potrzeb i oczekiwań przyszłych beneficjentów i użytkowników.
Konieczność podjęcia prac w zakresie rozwoju SWD PRM (budowy SWD PRM w wersji 2.0) była
wynikiem licznych wniosków i doświadczeń zebranych w trakcie realizacji projektu w wersji 1.0.
Zespół ds. rozwoju SWD PRM został powołany Zarządzeniem Ministra Zdrowia z dnia 10 listopada
2015 r. w sprawie powołania Zespołu do spraw rozwoju Systemu Wspomagania Dowodzenia
Państwowego Ratownictwa Medycznego (Dz. Urz. MZ. Nr 77).
Przewodniczącym Zespołu jest Pan Mateusz Komza – Dyrektor Departamentu Spraw Obronnych,
Zarządzania
Kryzysowego,
Ratownictwa
Medycznego
i Ochrony
Informacji
Niejawnych
Ministerstwa Zdrowia, natomiast na Zastępcę Przewodniczącego Zespołu wybrano Pana Marcina
Podgórskiego – Zastępcę Dyrektora ds. Ratownictwa Medycznego, Organizacji i Planowania SP
ZOZ Lotniczego Pogotowia Ratunkowego.
Członkowie Zespołu ds. rozwoju SWD PRM
Członkowie Zespołu do spraw rozwoju Systemu Wspomagania Dowodzenia Państwowego
Ratownictwa Medycznego (SWD PRM 2.0)
Urząd / podmiot leczniczy
Imię i nazwisko
Stanowisko
Przewodniczący Zespołu – Dyrektor Departamentu
Spraw Obronnych, Zarządzania Kryzysowego,
Ratownictwa Medycznego i Ochrony Informacji
Niejawnych Ministerstwa Zdrowia
Mateusz Komza
Dyrektor Departamentu
dwóch przedstawicieli Departamentu Spraw
Obronnych, Zarządzania Kryzysowego,
Ratownictwa Medycznego i Ochrony Informacji
Niejawnych Ministerstwa Zdrowia
Mirosława StockaMirońska
Naczelnik Wydziału Ratownictwa
Medycznego
Katarzyna
Jankowska
Główny Specjalista
Marcin Podgórski
Z-ca Dyrektora ds. Ratownictwa
Medycznego, Organizacji
i Planowania
Przemysław
Mrowiec
Specjalista w Zespole
Programistycznym
przedstawiciel Świętokrzyskiego Centrum
Ratownictwa Medycznego i Transportu Sanitarnego
Dariusz Dziedzic
Starszy Specjalista ds. informatyki
przedstawiciel Wojewódzkiego Pogotowia
Ratunkowego w Katowicach
Klaudiusz Nadolny
Ratownik Med. Koordynujący
Ośrodka Koordynacji
przedstawiciel Krakowskiego Pogotowia
Ratunkowego
Marek Maślerz
Zastępca Dyrektora
przedstawiciel Wojewódzkiej Stacji Pogotowia
Ratunkowego w Szczecinie
Łukasz
Sochanowski
Ratunkowego i Transportu Sanitarnego
w Warszawie MEDITRANS
Łukasz Kalinowski
Główny Specjalista ds. Informatyki
Paweł Wnuk
Kierownik Centrum
Dyspozytorskiego
przedstawiciel Bielskiego Pogotowia Ratunkowego
Wojciech Waligóra
Dyrektor Bielskiego Pogotowia
Ratunkowego
dwóch przedstawicieli SP ZOZ Lotnicze Pogotowie
Ratunkowe w Warszawie
str. 4 z 82
XI 2015 r. – VI 2016 r.
Członkowie Zespołu do spraw rozwoju Systemu Wspomagania Dowodzenia Państwowego
Ratownictwa Medycznego (SWD PRM 2.0)
Urząd / podmiot leczniczy
Ratunkowego w Olsztynie
Imię i nazwisko
Grzegorz Rzońca
Stanowisko
Zastępca Kierownika Centralnej
Dyspozytorni Medycznej
Ratunkowego w Gorzowie Wielkopolskim
Robert Kozłowski
Dyspozytor medyczny
przedstawiciel Wojewody Mazowieckiego
Zbigniew Urbański
Starszy Inspektor Wojewódzki
przedstawiciel Wojewody Małopolskiego
Małgorzata
Lechowicz
Dyrektor Wydziału Polityki
Społecznej
przedstawiciel Wojewody Pomorskiego
Michał StypRekowski
Starszy Informatyk Wojewódzki
przedstawiciel Wojewody Podlaskiego
Daniel Szutko
Zastępca Dyrektora WBiZK
przedstawiciel Wojewody Wielkopolskiego
Jakub Czarski
Specjalista ds. kontrolnoorganizacyjnych systemu PRM,
WBiZK, Oddział RM
Rafał Gawryszak
Starszy Serwisant Urządzeń
Elektronicznych
Merytoryczne wsparcie dla prac Zespołu
Arkadiusz
Kosowski
Narodowy Fundusz Zdrowia
Wojciech Zawalski
Centrum Projektów Informatycznych/
Centrum Cyfrowej Administracji
Tomasz
Woźniakowski
Eugeniusz
Koral
Dyrektor Departamentu ds. służb
Mundurowych
Dyrektor Departamentu Świadczeń
Opieki Zdrowotnej
Główny Specjalista
Kierownik Umowy
Zadania Zespołu ds. rozwoju SWD PRM
Zgodnie z Zarządzeniem Ministra Zdrowia do zadań Zespołu należy:
1. opracowanie katalogu podstawowych i dodatkowych funkcjonalności SWD PRM w wersji 2.0;
2. opracowanie zmian obecnych funkcjonalności SWD PRM w oparciu o wiedzę, doświadczenia oraz
zgłoszenia użytkowników;
3. opracowanie koncepcji i opisu nowych funkcjonalności SWD PRM w wersji 2.0 w oparciu o wiedzę,
doświadczenia oraz zgłoszenia użytkowników;
4. wskazywanie priorytetów i kolejności realizacji zmian dotyczących funkcjonalności SWD PRM;
5. udział w procesie wytwórczym oprogramowania SWD PRM na etapie tworzenia wymagań
i prototypów rozwiązań;
6. konsultowanie propozycji rozwiązań przedstawionych przez podmiot, który będzie wykonawcą
oprogramowania do obsługi SWD PRM w wersji 2.0;
7. opiniowanie projektów realizacji zmian funkcjonalności SWD PRM;
8. udział w testach akceptacyjnych oprogramowania SWD PRM;
9. weryfikacja wdrożonych zmian w środowisku produkcyjnym SWD PRM;
10. wskazywanie zagrożeń w przygotowanych przez Zespół lub zaprezentowanych przez wykonawcę
rozwiązaniach;
11. dbanie o spójność poszczególnych funkcjonalności i zgodność z wymaganiami jednostek
współpracujących z SWD PRM;
12. określanie innych potrzeb użytkowników SWD PRM w zakresie szkoleń, zmian lub modernizacji
sprzętu.
W ramach prac Zespołu zrealizowanych w okresie od listopada 2015 r. do marca 2016 r. wykonano
zadania wskazane w punktach 1-4.
Opisy specyfikacji dla poszczególnych funkcjonalności przygotowane przez Członków Zespołu będą
niezbędne przy sporządzeniu Opisu Przedmiotu Zamówienia w ramach SIWZ, przy postępowaniu
str. 5 z 82
XI 2015 r. – VI 2016 r.
o udzielenie zamówienia publicznego. Tworząc poszczególne opisy kierowano się koniecznością
sformułowania ich w sposób jednoznaczny, wyczerpujący i ściśle uwzględniający wszystkie wymagania
– na poziomie biznesowym – w celu zagwarantowania prawidłowej realizacji zamówienia.
Dotychczasowe posiedzenia Zespołu odbyły się w poniższych terminach:
• I POSIEDZENIE – 25 listopada 2015 r. (wideokonferencja)
• II POSIEDZENIE – 19-20 stycznia 2015 r.
• III POSIEDZENIE – 1 lutego 2016 r.
• IV POSIEDZENIE – 10 lutego 2016 r.
W poniższej tabeli przedstawiono:
• katalog funkcjonalności SWD PRM dla wersji 2.0 zaproponowany i opracowany w oparciu
o wiedzę, doświadczenia oraz zgłoszenia użytkowników, w szczególności Członków Zespołu;
katalog obejmuje propozycje zmiany obecnych funkcjonalności oraz wprowadzenie nowych
funkcjonalności,
• priorytet realizacji proponowanych zmian wskazany przez Członków Zespołu,
• decyzję Członków Zespołu w zakresie rekomendacji realizacji zmiany w SWD PRM 2.0 lub
rezygnacji z jej realizacji.
Roboczy
Numer
numer
Funkcjonalność SWD PRM 2.0
specyfikacji
specyfikacji
Decyzja Członków Zespołu
dot. realizacji funkcjonalności
Priorytet
realizacji
1
OPZ
Budowa i wdrożenie Modułu Sprawozdawczości do NFZ
dla ogólnokrajowego SWD PRM
opis przygotowany i niewykorzystany
w ramach prac nad SWD PRM 1.0;
zaakceptowany przez Członków
1
Zespołu do wprowadzenia w SWD
PRM 2.0
2
2
Opcja zapamiętania ustawienia filtrów danego
użytkownika (dyspozytora medycznego) z momentu
wylogowania.
opis przygotowany i zaakceptowany
1
przez Członków Zespołu
3
Integracja z systemem łączności telefoniczno-radiowej
z wykorzystaniem dowolnej technologii (łączność
analogowa, cyfrowa). Konsole dyspozytorskie integrujące
1
różne platformy łączności zarówno telefonicznej jak
i radiowej.
5
Możliwość obsługi otwartego interfejsu komunikacyjnego
służącego do powiadamiania systemów dysponenta
o przyjęciu nowego zgłoszenia w systemie SWD PRM
wraz z możliwością pobrania przez niego wybranych
danych dotyczących zlecenia z SWD PRM i użycia ich
w celu powiadomienia zespołu.
1
5
10
Umożliwienie zadysponowania lotniczych ZRM przez
dyspozytora medycznego z poziomu SWD PRM.
Dołączenie lotniczych ZRM do algorytmu dysponowania
ZRM przez dyspozytora medycznego.
1
6
41
Moduł Planisty (w tym grafiki pracy)
1
7
89
Optymalizowane widoki na bazie danych dla zwiększenia
możliwości i szybkości modułu raportowego.
1
8
91
Automatyzacje w wypełnianiu KMCR - np. powiązanie
ICD9 z zaznaczeniem czynności na KMCR.
1
9
92
Dodanie statusu POMOCY – cichego powiadomienia
dyspozytora na wypadek zagrożenia bezpieczeństwa.
1
10
93
mechanizm efektywnego wyszukiwania zgłoszeń
pozwalający stworzenie dowolnego zapytania
wyszukującego (np. po numerze KZW).
1
11
97
Dodatkowe komunikaty dla ZRM w przypadku zmian
danych w zgłoszeniach.
1
12
98
Kopiowanie danych z ekranu zdarzenia do KZW
w przypadku wielu poszkodowanych.
1
3
4
str. 6 z 82
XI 2015 r. – VI 2016 r.
Roboczy
Numer
numer
specyfikacji
specyfikacji
Priorytet
realizacji
1
13
99
Dodatkowe raporty predefiniowane.
34
94
opis przygotowany przez GUGiK
Dostosowanie aplikacji do wyświetlania etykiet na ikonach
i zaakceptowany przez Członków
w UMM w postaci DYMKA.
Zespołu
1
36
26
Monitoring czasu, który upłynął od momentu
zadysponowania ZRM do przesłania statusu WYJAZD
1
PRM 2.0
14
4
Utworzenie SZYNY do komunikacji umożliwiającej
generowanie informacji, które zostaną wysłane poprzez
np. SMS, pager, e-mail.
2
8
Tworzenie, w trakcie pracy systemu SWD PRM, bazy
danych zgłoszeń, którą możemy wykorzystać do
przyspieszenia procesu przyjęcia zgłoszeń w systemie.
2
Automatyczne przypisanie danych abonenta w zależności przez Członków Zespołu
od wcześniej udzielanych świadczeń opieki zdrowotnej
przez ZRM.
13
Możliwość otwarcia drugiego ekranu do przeglądu
zgłoszeń i zdarzeń na potrzeby rozdzielenia procesu
dysponowania od procesu przeglądania zleceń
archiwalnych. Podział obecnego okna SWD PRM i UMM
z 2 monitorów na 3 monitory.
17
20
Możliwość nawiązania połączenia telefonicznego
z poziomu aplikacji – funkcjonalność umożliwiająca
przyporządkowanie wszystkich prowadzonych rozmów
2
związanych z obsługą danego zdarzenia w aplikacji SWD
PRM.
18
27
Moduł Apteka
2
19
49
Umieszczenie w SWD PRM innej dokumentacji tj. karta
chorób zakaźnych, "niebieska karta", karta przymusu
bezpośredniego, , karta odstąpienia od medycznych
czynności ratunkowych
2
20
51
Informacja zarządcza dla kierownictwa jednostki PRM
2
21
54
Możliwości teletransmisji bieżących parametrów
fizjologicznych pacjenta (np. EKG) do miejsca docelowego
2
transportu chorego.
22
55
Dostęp do bazy wiedzy, biblioteki regulaminów, instrukcji
przepisów i procedur
2
23
62
Segregacja rannych w wypadkach masowych - zgodnie
z "Procedurą postępowania na wypadek wystąpienia
zdarzenia mnogiego/masowego"
2
24
80
Po przekroczeniu określonego czasu realizacji zlecenia
odrębna wizualizacja danego ZRM na mapie.
2
25
96
Zmiana niektórych ikon statusów.
2
33
87
Zadysponowanie jednostki współpracującej z systemem
PRM do zdarzenia
opis przygotowany przez Członków
Zespołu
2
35
90
Hipotermia - wydruk dodatkowej karty kwalifikacji
w przypadku wpisania przez ratownika do KMCR
wybranych rozpoznań
opis przygotowany, odstąpiono od
realizacji w SWD PRM 2.0
z powodu rezygnacji w MUW
2
26
7
Możliwość obsługi wyjazdów ZRM na ćwiczenia.
3
27
43
Kontrola przeglądów i data ważności pojazdów i sprzętu
medycznego
3
15
16
2
str. 7 z 82
XI 2015 r. – VI 2016 r.
Roboczy
Numer
numer
specyfikacji
specyfikacji
Priorytet
realizacji
28
100
Wprowadzenie do SWD PRM statusów ZRM oraz
możliwość generowania historii użytych podczas akcji
ratunkowej statusów - dla każdego wyjazdu
2
29
102
Utworzenie bazy raportów z możliwością udostępniania
nowoutworzonych raportów innym użytkownikom
2
30
103
Wdrożenie rozwiązania dla archiwizacji i udostępniania
dokumentacji medycznej na żądanie uprawnionej osoby
w lokalizacji poza siecią OST112.
1
31
104
Lekarz koordynator ratownictwa medycznego rozszerzenie zadań, jakie może wykonywać
z wykorzystaniem SWD PRM, celem realizacji zadań
ustawy o PRM
1
32
105
KZW, KMCR – dostosowanie dokumentacji medycznej do opis przygotowany i zaakceptowany
1
nowej wersji dokumentu oraz nowego standardu
204
Optymalizacja wyświetlanych notyfikacji
1
PRM 2.0
206
Wymuszanie zatwierdzenia dokumentacji medycznej
1
PRM 2.0
213
Usprawnienia w interfejsie aplikacji mobilnej widoczny
numer KZW
1
PRM 2.0
220
Powiązanie kodu pilności ze znacznikiem sygnałów
świetlnych
1
PRM 2.0
230
Zmiana algorytmu podpowiadania Zdarzeń podobnych
1
PRM 2.0
236
Narzędzie monitorujące pracę dyspozytorów medycznych
1
na zmianie
PRM 2.0
237
Automatyczne uzupełnianie znacznika Dorosły-Dziecko na
1
podstawie wprowadzonego wieku
PRM 2.0
250
Zmiana sposobu obsługi pola Zalecenia Zastosowane leki w ramach prac nad SWD PRM 1.0;
w zakresie działania słowników i sposobu generowania
1
wydruku KMCR
PRM 2.0
252
1
PRM 2.0
37
38
39
40
41
42
43
44
45
Baza szpitali
str. 8 z 82
XI 2015 r. – VI 2016 r.
Roboczy
Numer
numer
specyfikacji
specyfikacji
Priorytet
realizacji
255
Automatyzacja wypełniania KZW pacjent nie wyraża zgody
1
na udzielenie pomocy
PRM 2.0
261
Implementacja ograniczenia dostępu do nagrań
w zdarzeniu dla nieuprawnionych użytkowników
1
PRM 2.0
265
Historia aktywności stanowiska dyspozytorskiego
dodatkowy raport
2
PRM 2.0
49
53
zaproponowano wykorzystanie
modułu Analityka UMM
Tworzenie modeli najbardziej efektywnego rozmieszczenia dostarczanego przez GUGiK –
ZRM na podstawie zadanych założeń.
istnieje konieczność weryfikacji
spełniania wymagań oczekiwanych
od niniejszej funkcjonalności
2
50
9
Możliwość odbioru wezwania za pomocą sms np. od os.
niepełnosprawnej lub w podeszłym wieku.
funkcjonalność będzie realizowana
w CPR (112)
1
51
76
Możliwość podpinania obiektów tzn. wpisywania w adresie
skrzyżowań, nazw przystanków komunikacji miejskiej,
stacji PKP, parków, skwerów, centrów handlowych, kin,
w UMM
teatrów, szkół (lista słownikowana)
1
52
78
Lokalizacja miejsc stacjonowania zespołów ratownictwa
medycznego na mapie.
w UMM
1
53
79
Możliwość zidentyfikowania numeru drogi i kilometrów
poprzez wpisanie tych informacji w opisie miejsca
zdarzenia.
w UMM
1
54
6
Powiadomienie dyspozytora w przypadku braku
potwierdzenia odbioru zgłoszenia przez ZRM
odstąpiono od realizacji
funkcjonalności w SWD PRM 2.0
(uznano za wystarczającą
specyfikację zmiany nr 36)
-
55
82
Współpraca SWD PRM z systemami wykorzystywanymi
przez GDDKiA – na drogach krajowych, ekspresowych
i autostradach.
-
56
14
INTERFEJS. Komunikacja SWD PRM ze Szpitalnymi
Oddziałami Ratunkowymi (SOR) w celu przepływu
informacji w zakresie określenia stanu obłożenia oddziału
i przewidywanego czasu przyjęcia pacjenta z ZRM
w związku z opóźnieniami
w realizacji SIM
-
15
Możliwość monitorowania rozmieszczenia ZRM przez
dyspozytorów med. i czasowego przesunięcia w celu
zapewnienia odpowiedniego czasu dojazdu do miejsca
zdarzenia.
(brak możliwości realizacji bez
wcześniejszych zmian rozwiązań
prawnych)
-
58
24
Komunikator tekstowy – przesyłanie i odbieranie
wiadomości tekstowych pomiędzy karetkami a
Dyspozytorami. Aplikacja dostosowana do wymiany
danych z modułem aplikacji Dyspozytorów – współpraca
z F.SWDPRM.11.
-
59
25
Komunikator głosowy – komunikacja głosowa
z dyspozytorem przy zastosowaniu technologii VoIP.
funkcjonalności w SWD PRM
(funkcjonalność uznana za zbędną)
-
46
47
48
57
str. 9 z 82
XI 2015 r. – VI 2016 r.
Roboczy
Numer
numer
specyfikacji
specyfikacji
Priorytet
realizacji
60
56
Uniwersalny interfejs umożliwiający wymianę danych
z systemami zewnętrznymi względem SWD PRM, tj.:
systemami wytwarzanymi przez Centrum Systemów
Informacyjnych Ochrony Zdrowia, systemami
informatycznymi LPR, w oparciu o komunikaty w formacie
XML.
61
57
rezygnacja z przygotowania opisu –
Interfejs umożliwiający współpracę z systemami
funkcjonalność będzie zawierała się
informatycznymi Dysponenta w szczególności z systemem
w opisach specyfikacji zmian nr 6
kadrowo-płacowym i finansowo-księgowym.
i 18
62
75
Współpraca z bazą danych o lokalizacji AED po stronie
SWD PRM i UMM.
-
63
12
Przetwarzanie nagrania głosowego w słowo pisane
(przekształcanie słowa w gotowe dokumenty, tj. opis
poszczególnych pól w dokumentacji medycznej).
-
64
18
Rozsyłanie komunikatów wraz z załącznikami (np. pliki
PDF, JPG) pomiędzy Dyspozytorami (komunikaty
okólnikowe).
-
65
19
Możliwość wymiany informacji pomiędzy Dyspozytorami
a Operatorami CPR/WCPR w czasie rzeczywistym
z użyciem komunikatów aplikacyjnych.
-
66
21
Dwustronna komunikacja z terminalami mobilnymi
zapewniająca przesyłanie i odbieranie wiadomości
tekstowych (komunikator tekstowy)
-
67
50
Wizualizacja i obsługa procesu wsparcia dyspozytora, gdy
zachodzi konieczność przewiezienia pacjenta do
najbliższej jednostki szpitalnej poprzez: 1. wizualizację na
mapie za pomocą odpowiedniej warstwy informacji
o wolnych zasobach oddziałów szpitalnych; 2. zestawienie
danych dotyczących aktualnych możliwości przyjęcia
przewożonego pacjenta, oraz całkowitej liczby
przewiezionych pacjentów na dany SOR lub oddział
w ostatnich 12h, 3. zasugerowanie przez system placówki,
która może przyjąć pacjenta po obliczeniu najszybszej
trasy dojazdu, oraz aktualnego obciążenia jednostki
szpitalnej.
w realizacji SIM
-
68
52
Integracja z systemem sygnalizacji świetlnej w taki
sposób, aby możliwe było udrażnianie zakorkowanych
skrzyżowań i przejazdów zespołów ratunkowych w jak
najkrótszym czasie.
-
58
Wizualizacja wielkoformatowa – moduł aplikacyjny
pozwalający na wizualizację na wielkoformatowej ścianie
wizyjnej obrazów związanych z obsługą zgłoszeń
w ramach Systemu oraz z innych źródeł obrazu.
Wymagane jest dostarczanie aplikacji realizującej
niniejszą funkcjonalność i określenie w projekcie
technicznym wymagań na sprzęt konieczny do jej realizacji
(dostawa sprzętu nie wychodzi w zakres przedmiotu
zamówienia (dla co najmniej 100 równoczesnych
użytkowników).
-
70
63
Możliwość rejestrowania danych na poziomie szpitali,
istotnych z punktu widzenia działania Dyspozytora. Dane
te powinny być również wizualizowane w module
mapowym jako część sił i środków.
-
71
64
Prowadzenie ewidencji dla potrzeby SWD PRM w zakresie
wolnych miejsc szpitalnych ze wskazaniem co najmniej:
nazwa szpitala, oddział, ilość wolnych miejsc.
w realizacji SIM
-
72
65
Mechanizmy rozliczalności użytkownika wprowadzającego odstąpiono od realizacji
dane (logi systemowe).
-
69
-
str. 10 z 82
XI 2015 r. – VI 2016 r.
Roboczy
Numer
numer
specyfikacji
specyfikacji
Priorytet
realizacji
w realizacji SIM
-
73
66
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).
74
68
Zapewnienie interfejsu umożliwiającego automatyczne
pobieranie danych.
-
75
86
Możliwość powiadomienia osób, które odbyły np. kurs
pierwszej pomocy, KPP będących najbliżej miejsca
zdarzenia
-
76
101
Możliwość dowolnej zmiany podkładów mapowych
(wybranych przez dysponentów) – z pozostawieniem
wspólnej bazy adresowej.
-
str. 11 z 82
XI 2015 r. – VI 2016 r.
Opisy funkcjonalności dla potrzeb projektu SWD PRM 2.0
Specyfikacja zmiany nr: 1 (1)
1. Identyfikator
zlecenia:
2. Opis
przedmiotu
zadania:
Budowa i wdrożenie Modułu Sprawozdawczości do NFZ dla ogólnokrajowego SWD
PRM:
OPIS PRZEDMIOTU ZAMÓWNIENA przygotowany w ramach prac nad
SWD PRM 1.0: ZAŁĄCZNIK NR 1
3. Wyniki
realizacji
zadania:
4. Kryteria
akceptacji
zadania:
str. 12 z 82
XI 2015 r. – VI 2016 r.
5. Identyfikator
zlecenia:
Możliwość ustawień z pozycji administratora, aby po wylogowaniu danego użytkownika
(dyspozytora medycznego) były zapamiętane w systemie SWD PRM ustawienia filtrów
danego użytkownika z momentu wylogowania.
6. Opis
przedmiotu
zadania:
1. Ustawienia użytkownika, które zostaną zapamiętane z momentu ostatniego
wylogowania, w tym również w przypadku awarii połączenia z serwerem lub
samoczynnego wylogowania:
1.1 Tryb pracy dyspozytora:
a) przyjmujący zgłoszenia
b) dysponujący zespoły
1.2 Ustawienie obszaru dysponowania zarówno w trybie pracy dyspozytora
przyjmującego zgłoszenia jak również dysponującego zespoły.
1.3 Ustawienia konfiguracji filtrowania zdarzeń w oparciu o:
a) statusy zdarzeń: nowe, przyjęte, obsługiwane, odmowa, duplikaty,
pozostałe, anulowane, obsłużone;
b) czas przyjęcia zdarzenia w SWD PRM
c) lokalizację miejsca zdarzenia
1.4 Ustawienia filtra Lista ZRM
1.5 Ustawienia filtra Statusy ZRM poprzez kryteria:
a) Gotowość,
b) obsługa zdarzenia,
c) Inne
LUB
d) Zdefiniowane grupy czerwonej i zielonej.
1.6 Ustawienia dotyczące lokalizowania danego ZRM poprzez wyłonienie ikony
(znacznik) przy nazwie zespołu, który wizualizuje dany ZRM na mapie.
2. Zostaje utrzymana możliwość powrotu w całości systemu, jak również przy
poszczególnych ustawieniach, do trybu odpowiednio: podstawowego lub
domyślnego.
7. Wyniki
realizacji
zadania:
8. Kryteria
akceptacji
zadania:
str. 13 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
2. Opis
przedmiotu
zadania:
Przedmiotem zadania jest integracja Serwerów Komunikacyjnych z funkcjonującymi
systemami łączności radiowej, pozwalająca na wykorzystanie systemów w różnej
technologii (analogowej i cyfrowej) z zachowaniem możliwości płynnej migracji do
docelowego systemu komunikacji radiowej. Powstanie jednolita platforma komunikacji
telefonicznej i radiowej, pozwalająca na udostępnianie środków radiowych pomiędzy
Dyspozytorniami,
zapewniająca
ciągłość
działania
w przypadku
awarii
(zastępowalność Dyspozytorni, praca ośrodka w trybie „offline”). Integracja umożliwi
monitorowanie działania sieci radiowej z Centrum Technicznego oraz w ramach
poszczególnych Dyspozytorni. Pozwoli to na zarządzanie dostępem do sieci radiowej
wraz z możliwością rekonfiguracji w przypadkach awarii. Udostępnienie środków
łączności radiowej na Konsolach Dyspozytorskich Podsystemu Zintegrowanej
Łączności (PZŁ), zapewni dostęp do środków łączności telefonicznej oraz radiowej na
jednym stanowisku (Konsola Dyspozytorska wraz z powiązaną z nią Stacja Dostępową
SWD PRM). Obsługa środków łączności radiowej z zachowaniem jednolitego interfejsu
użytkownika niezależnie od dołączonego systemu radiowego (łatwość obsługi
w przypadku zastępowalności, jednolity system szkoleń). Zachowanie spójnego
systemu rejestracji i archiwizacji korespondencji radiowej i telefonicznej oraz systemu
monitorowania zdarzeń zapewniającego rozliczalność oraz niezaprzeczalność
powstałych zapisów. Możliwość niezwłocznego i prostego dostępu do zarejestrowanej
korespondencji radiowej z poziomu Konsoli Dyspozytorskiej.
Zadanie zostanie zrealizowane poprzez doposażenie Serwerów Komunikacyjnych
CPR. Istniejące Serwery Radiowe zostaną doposażone w sterowniki radiotelefonów
oraz radiotelefony bazowe lub zostaną wykorzystane obecne środki łączności radiowej
(jeżeli umożliwiają dołączenie do sterowników radiowych). Ze względu na spójność,
możliwości rozwoju, utrzymania i bezpieczeństwo systemu, integracji będą podlegały
jedynie środki łączności radiowej tzn. nie będzie kanału komunikacji pomiędzy
istniejącym w województwie systemem integrującym łączność radiową (innym niż PZŁ)
a ogólnokrajowym systemem PZŁ.
Metody integracji w zależności od istniejącej infrastruktury sieci radiowej:
I. Cyfrowe systemy radiowe typu DMR – sieć przemienników połączonych
poprzez transmisję IP, obejmujących zasięgiem obszar województwa, lub jego
część:
1. Integracja na poziomie protokołu będzie możliwa w przypadku udostępniania
wykonawcy PZŁ, przez producenta systemu DMR, protokołu oraz niezbędnych
licencji do integracji (nie wszyscy producenci oferują możliwość komunikacji
z przemiennikami poprzez IP).
a. Dostęp poprzez protokół IP do przemienników wiąże się z koniecznością
połączenia sieci radiowej IP z OST 112.
b. By w pełni możliwa była zastępowalność Dyspozytorni, konieczny jest dostęp
do sieci IP przemienników z sieci OST 112
i. Zapewnienie spójnej adresacji IP
ii. Zapewnienie bezpieczeństwa połączenia
iii. Zapewnienie routingu pomiędzy siecią radiową IP a siecią OST112
2. Integracja poprzez sterowniki radiowe oraz radiotelefony bazowe realizowana
będzie w przypadku, gdy producent nie udostępnia protokołu do współpracy
z przemiennikami po IP lub w przypadku gdy działa inny system integrujący
korzystający z protokołu producenta systemu radiowego
a. Zakłada się, że każdy z Dyspozytorów będzie miał do dyspozycji własny
radiotelefon bazowy (możliwe też współdzielenie zasobów radiowych
pomiędzy Dyspozytorami),
b. Rozmieszczenie radiotelefonów będzie zależne od struktury sieci radiowej,
c. Sterowniki radiowe oraz radiotelefony bazowe powinny być rozmieszczone
w lokalizacjach, w których jest dostępna sieć OST112 (obiekty PSP, Policji,
urzędy),
str. 14 z 82
XI 2015 r. – VI 2016 r.
d. Dołączenie sterowników bezpośrednio poprzez sieć OST112 eliminuje
problemy związane z dołączeniem sieci radiowej IP z siecią OST112
(konieczność zachowania spójnej adresacji, routing, bezpieczeństwo).
Zastępowalność
Dyspozytorni,
udostępnianie
środków
radiowych
i zarządzanie środkami łączności radiowej będzie możliwe bez konieczności
rekonfiguracji istniejącej sieci radiowej,
e. Dołączenie sterowników bezpośrednio poprzez sieć OST112 eliminuje
nakłady
związane
z zapewnieniem
urządzeń
pośredniczących
zapewniających bezpieczeństwo połączenia,
3. Oba sposoby integracji (poprzez protokół producenta oraz sterowniki radiowe) są
równoważne w zakresie dostępnych funkcjonalności radiowych
II.
Cyfrowe systemy radiowe typu TETRA – integracja zgodnie z opisem punktu I
odpowiednio dla infrastruktury Tetra
III.
Brak integratora (innego niż PZŁ) obejmującego zasięgiem obszar
województwa lub obszar działania SDM
Możliwości integracji sieci radiowej:
1. Doposażenie istniejącego w ośrodku CPR Serwera Radiowego w sterowniki
radiowe. Sterowniki radiowe zostaną zainstalowane w lokalizacjach radiowych
stacji bazowych z zapewnionym dostępem poprzez siec IP (preferowany dostęp
poprzez sieć OST112). Do systemu dołączone zostaną istniejące radiotelefony
bazowe (jeśli ich konstrukcja umożliwia zdalne sterowanie) lub nowe
radiotelefony analogowo cyfrowe.
2. Wdrożenie docelowego systemu łączności radiowej cyfrowej (DMR, TETRA)
i integracja zgodnie z opisem punktu I
3. Wyniki
realizacji
zadania:
IV. Systemy radiowe wykorzystujące integrator producenta systemu PZŁ
Możliwości integracji sieci radiowej:
1. Rekonfiguracja istniejącego systemu integratora i udostępnienie zasobów
radiowych Konsolom Dyspozytorskim systemu PZŁ
1. Pełna zastępowalność Dyspozytorni Medycznych, każda Dyspozytornia będzie
miała dostęp do środków radiowych i telefonicznych całego systemu PZŁ
2. Jednolity system archiwizacji korespondencji radiowej i telefonicznej Dyspozytorów,
jednolity odsłuch i udostępnianie zarejestrowanych nagrań.
3. Zabezpieczenie zarejestrowanych nagrań w archiwum (zapis na zasobach
niemodyfikowalnych).
4. Zapewnienie ciągłości działania systemu poprzez możliwość odmiejscowienia
obsługi zdarzenia.
5. Możliwość monitorowania dostępności środków łączności radiowej w skali kraju.
6. Zawsze dostępna łączność telefoniczna i radiowa niezależnie od miejsca obsługi
zdarzenia.
7. Zapewnienie jednolitego interfejsu użytkownika dla obsługi środków łączności
telefonicznej, radiowej oraz odsłuchu korespondencji – ujednolicenie procesu
szkoleń
8. System telefoniczny i radiowy powiązane ze sobą (połączenie telefoniczne trafi do
Dyspozytora, który ma dostęp do środków radiowych by zadysponować zespół. Nie
będzie sytuacji, w której działa System radiowy a telefoniczny jest w awarii
i połącznia trafiają do Dyspozytora bez dostępu do radia.
9. Możliwość tworzenia redundancji serwerów radiowych, w przypadku awarii CPR,
sterowniki wyniesione mogą automatycznie logować się do innego (zastępczego)
ośrodka CPR. Do ośrodka tego zalogują się również konsole, które mogą
prowadzić łączność radiową.
10. Zapewnienie działania systemu w trybie „offline”.
11. Wykorzystanie działającego
produkcyjnie
i zweryfikowanego
Podsystemu
Zintegrowanej Łączności
12. Zasady Zastępowalności Dyspozytorni w zakresie dostępu do środków
str. 15 z 82
XI 2015 r. – VI 2016 r.
telefonicznych i radiowych
a. Zastępowalność w zakresie przekierowania połączeń telefonicznych – jest
realizowana
automatycznie
przez
system
PZŁ,
zgodnie
z tabelą
zastępowalności.
b. Zastępowalność w zakresie dostępu do środków łączności radiowej:
i. W przypadku awarii jednej dyspozytorni medycznej obszar jej dysponowania
przejmuje
inna,
wyznaczona
dyspozytornia
(zgodnie
z tabelą
zastępowalności).
ii. Konfiguracja systemu PZŁ i Konsol Dyspozytorskich w SDM zastępczych
będzie pozwalała na załączenie obsługi środków radiowych innej
Dyspozytorni. Konsole Dyspozytorskie będą posiadały w konfiguracji ekrany
(zakładki) ze zdefiniowanymi środkami radiowymi Dyspozytorni, którą mogą
zastępować.
1. W trakcie normalnej pracy Dyspozytor będzie mógł obserwować na
Konsoli Dyspozytorskiej stan (dostępność) środków radiowych
Dyspozytorni, którą może zastępować, natomiast nie będzie korzystał
z tych zasobów radiowych.
2. W przypadku awarii i konieczności przejęcia obszaru dysponowania,
Dyspozytorzy będą aktywowali komunikację głosową ze środkami
łączności radiowej (radiotelefony), z których będą korzystali na przejętym
obszarze dysponowania. Będą mogli aktywować automatycznie
komunikację ze wszystkimi radiotelefonami lub też wybrać określone
radiotelefony bazowe (w zależności od potrzeb).
3. Zapewniony będzie jednoczesny dostęp do środków łączności radiowej
na danym obszarze z wielu Konsol Dyspozytorskich różnych SDM.
Umożliwi to płynne przejęcie obszaru działania w przypadku prac
planowych oraz powrót do dysponowania środkami we własnym
obszarze po awarii.
4. Będzie możliwość definiowania dla danego Dyspozytora wielu ekranów
(zakładek), co da możliwość przejęcia przez niego wielu obszarów
dysponowania, jeżeli zajdzie taka konieczność
5. Ekrany (zakładki) będą definiowane przez administratora PZŁ.
6. Dokonanie stosownych zmian po stronie PZŁ.
7. Wizualizacja zasięgu łączności radiowej „poszczególnych sieci
radiowych”.
4. Kryteria
akceptacji
zadania:
str. 16 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
SWD PRM musi obsługiwać otwarty interfejs komunikacyjny służący do powiadamiania
systemów dysponenta o przyjęciu nowego zgłoszenia w systemie SWD PRM wraz
z możliwością pobrania przez niego wybranych danych dotyczących zlecenia z SWD
PRM i użycia ich w celu powiadomienia zespołu.
Dzięki takiemu rozwiązaniu dysponenci będą mogli zachować dotychczasowe systemy
powiadamiania, jak i będą mogli je dowolnie rozwijać i modyfikować wedle potrzeb
w celu minimalizacji czasu wyjazdu zespołu.
2. Opis
przedmiotu
zadania:
3. Wyniki
realizacji
zadania:
4. Kryteria
akceptacji
zadania:
Kluczowe techniczne aspekty otwartego protokołu komunikacyjnego znajdują się
poniżej:
• Komunikacja do API będzie odbywać się z zastosowaniem szyfrowanej warstwy
transportowej WebSockets over SSL/TLS wystawianej przez serwer SWD PRM.
• Wewnątrz warstwy transportowej, wiadomości będą wymieniane z użyciem
protokołu JSON w formacie zgodnym z dokumentacja.
• Autoryzacja odbędzie się na warstwie protokołu z użyciem hasła dysponenta
przekazanego przez SWD PRM i certyfikatu usługi WebSockets.
• Po pozytywnym zakończeniu autoryzacji SWD PRM wyśle do klienta informacje
o każdym nowym zleceniu w systemie SWD PRM przekazując dla każdego
zlecenia informacje o jego numerze i haśle.
• Dodatkowo po zakończeniu autoryzacji serwer SWD PRM wyśle do klienta
informacje o numerach zleceń i hasłach dla zleceń z przed ostatnich 10 minut.
• Przy użyciu dostarczonego numeru karty i hasła, klient będzie mógł odpytać
o dodatkowe informacje dotyczące karty w zależności od wymaganego zakresu
informacji.
• W przypadku, gdy w ciągu 1s nie odbędzie się żadna komunikacja na warstwie
protokołu, serwer SWD PRM wyśle do klienta wiadomość Heartbeat, której format
zgodny jest z dokumentacja, pozwalającą klientowi odróżnić stan awarii
komunikacji miedzy systemami od stanu, w którym SWD PRM nie przyjął żadnych
nowych zgłoszeń.
• Administrator centralny ma możliwość konfiguracji bazowego katalogu danych
a administrator wojewódzki konfiguruje zakres danych z KZW udostępnianych
poszczególnym dysponentom.
• Minimalny zakres danych:
1. Kod ZRM,
2. Dysponent ZRM,
3. Status ZRM w chwili dysponowania,
4. Plik ZRM zawierający dane udostępnione przez administratora centralnego dla
dysponenta.
Zaimplementowanie otwartego interfejsu komunikacyjnego zgodnie z dokumentacją
i przyznanie dostępu do niego dysponentom.
str. 17 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
Umożliwienie zadysponowania Lotniczych ZRM (LZRM) przez dyspozytora
medycznego z poziomu SWD PRM. Dołączenie LZRM do algorytmu dysponowania
ZRM przez dyspozytora medycznego.
2. Opis
przedmiotu
zadania:
I. Dysponowanie LZRM:
1. Każdy LZRM może posiadać jeden z następujących statusów:
a) W GOTOWOŚCI (1)
b) LOT PO PACJENTA (2)
c) NA MIEJSCU (3)
d) Z PACJENTEM (4)
e) W SZPITALU (5)
f) POWRÓT NA RADIU (6)
g) ZAWIESZENIE DYŻURU (7)
h) OBSŁUGA TECHNICZNA (8)
i) INNE ZADANIA (9)
j) DYŻUR ZAKOŃCZONY (10)
k) EMERGENCY (11)
2. Każdy LZRM może posiadać jeden ze statusów pogody:
a) ZIELONA
b) ŻÓŁTA
c) CZERWONA
3. Statusy 1,2,3,4,5,6 umożliwiają przydzielenie/zmianę zlecenia.
4. Statusy pogody ZIELONY, ŻÓŁTY, CZERWONY potencjalnie umożliwiają
przekazanie zlecenia.
5. W zakładce „Przydziel ZRM” zawsze pojawia się co najmniej jeden LZRM, który
w najkrótszym czasie dotrze do miejsca zdarzenia. (Najkrótszy czas dotarcia
LZRM obliczany jest wg algorytmu: status 1,2 lub 6 + ostatnie zarejestrowane
współrzędne śmigłowca x ... km/h = ... orientacyjny czas dotarcia) oraz zawsze na
ostatnim miejscu kolejny LZRM.
6. Dyspozytor ma możliwość uwidocznienia większej liczby LZRM, poprzez przycisk
(np. „pokaż dostępne HEMS”), uwzględniając wizualizację czasu dotarcia.
7. Po przydzieleniu zlecenia LZRM, dyspozytor otrzymuje w czasie krótszym niż 50
sekund zwrotne potwierdzenie przyjęcia lub nieprzyjęcia zlecenie.
8. W przypadku przydzielenia zlecenia LZRM, dyspozytor oznacza powód
zadysponowania (wielokrotnego wyboru):
a) LZRM dotrze w najkrótszym czasie do miejsca zdarzenia,
b) LZRM w najkrótszym czasie przetransportuje pacjenta do ośrodka
docelowego,
c) ZRM potrzebuje wsparcia,
d) Zdarzenie z potencjalnie dużą liczbą poszkodowanych.
9. W przypadku nieprzyjęcia zlecenia – dyspozytor otrzymuje informację o powodzie
nieprzyjęcia zlecenia: brak pogody, usterka, brak możliwości operacyjnych.
10. W przypadku braku otrzymania potwierdzenia w ciągu 50 sekund, dyspozytor
kontaktuje się z zadysponowanym LZRM telefonicznie/radiotelefonicznie.
II. Dysponowanie LZRM w nocy.
1. Dyspozytor ma możliwość zadysponowania LZRM:
a) Do miejsca gminnego
b) Na drogę dwujezdniową
c) Do miejsca zdarzenia.
2. W przypadku kiedy realizacja wezwania przez LZRM będzie wiązał się
z lądowaniem w miejscu zdarzenia w nocy, Dyspozytor otrzyma informację – LOT
HEMS w NOCY. (Dyspozytorowi wyświetli się okno z informacją o treści:
Lądowanie zespołu HEMS we wskazanej lokalizacji będzie miało miejsce w nocy.
W celu uzgodnieniu szczegółów skontaktuj się z Centrum Operacyjnym LPR lub
str. 18 z 82
XI 2015 r. – VI 2016 r.
podobnej, która zostanie wysłana z serwera LPR kiedy dane wysłane
w zgłoszeniu wskazują na lądowanie w nocy – obliczane po stronie LPR
automatycznie na podstawie czasu i miejsca wezwania.)
3. W przypadku dysponowania LZRM do miejsca gminnego/lądowiska
przyszpitalnego, Dyspozytor poprzez przycisk „5 najbliższych lądowisk nocnych”
wygeneruje 5 najbliższych miejsc gminnych/lądowisk przyszpitalnych (Dyspozytor
powinien zobaczyć na mapie lokalizację (znaczniki z numerami) 5 najbliższych
miejsc gminnych w celu oceny, które z nich będzie optymalne do przekazania
pacjenta.
5 najbliższych miejsc gminnych powinno być ponumerowanych od 1 do 5
w zależności od odległości do miejsca wezwania/zdarzenia, gdzie numer 1
otrzyma miejsce najbliższe a 5 oddalone najbardziej.
Obliczanie odległości od miejsca wezwania do najbliższych lądowisk:
– wyszukiwane są najbliższe miejsca gminne dla śmigłowca – w linii prostej od
miejsca zdarzenia – dla każdego ze znalezionych miejsc wyliczany jest czas
dojazdu przez karetkę z miejsca zdarzenia do miejsca gminnego.
– otrzymane wyniki prezentowane są w jednym oknie (najlepiej z możliwością
sortowania po czasie dotarcia śmigłowca i czasie dotarcia karetki lub czasy te są
odpowiednio oznaczone np. kolorami, od zielonego – najbliższe poprzez żółty do
czerwonego – najdalsze).
– dyspozytor ocenia, które z zaproponowanych miejsc jest optymalne dla obu
zespołów gdzie priorytetem jest najkrótszy czas transportu pacjenta do szpitala.
Wybór miejsca gminnego bezpośrednio z mapy klikając w znacznik z numerkiem
(jeśli to możliwe) lub z listy wyświetlonej w oknie, w którym numeracja miejsc jest
zgodna z tą wyświetloną na mapie).
4. Po ustaleniu miejsca lądowania LZRM na jednym z miejsc o których mowa
w pkt 1, system wskazuje Dyspozytorowi LZRM, który w najkrótszym czasie
dotrze do miejsca zdarzenia (najkrótszy czas dotarcia LZRM obliczany jest wg
algorytmu: status 1,2 lub 6 + ostatnie zarejestrowane współrzędne śmigłowca
x … km/h = ... orientacyjny czas dotarcia. Czas dolotu na miejsce gminne należy
obliczyć dla każdego zespołu i wyświetlić w oknie posortowaną według czasu
dolotu listę X najszybszych, dostępnych zespołów) łączy się drogą telefoniczną
lub radiotelefoniczną i po ustaleniu szczegółów przekazuje wezwanie według
zasad obowiązujących w dzień.
(W nocy wzywający zawsze otrzyma status ContacUs, co oznacza, że wezwanie
może zostać obsłużone i przyjęte tylko werbalnie przez radio lub telefon.)
III.
Na każdym etapie zlecenia Dyspozytor ma możliwość przekazania formatki
zlecenia do Dyspozytora Centrum Operacyjnego LPR oraz bezpośredniego
telefonicznego kontaktu.
3. Kryteria
akceptacji
zadania:
str. 19 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
Rozbudowa Modułu Planisty
Moduł Systemu: Moduł Planisty, Aplikacja Administratora, Aplikacja Analityka,
aplikacje serwerowe komunikacja-interfejsy, system bazodanowy
2. Opis
przedmiotu
zadania:
3. Wyniki
realizacji
zadania:
Opis wymagania: Wymaganie dotyczy bardzo dużej modyfikacji Modułu Planisty
w celu dostosowania jej do realnych potrzeb w PRM, wyposażenia w funkcje
wspomagające planowanie zgodnie z wszystkimi regułami wynikającymi z prawa pracy
oraz funkcję integracji z rejestrami centralnymi oraz systemami kadrowymi
Dysponentów. Ze względu na olbrzymią złożoność zagadnień związanych
z planowaniem pracy w realiach PRM, funkcjonalność wymaga stworzenia przez
wykonawcę szczegółowego projektu technicznego precyzującego opisane poniżej
zagadnienia i funkcjonalności.
1. Interfejs
1.1 Pojedynczy Grafik będzie dotyczył jednego stanowiska pracy. Lista grafików
powinna zawierać: nazwę grafiku, Imię Nazwisko Planisty, Typ Grafiku, Status
Grafiku. np.
K01-21 Kierowca – Jan Kowalski – Plan Grafiku zatwierdzony przez Zarząd
K01-21 Ratownik – Jan Kowalski – Plan Grafiku zatwierdzony przez Zarząd
Dyspozytor stanowisko 1 – Adam Nowak – Plan Grafiku zatwierdzony przez
Zarząd
Lista Grafików może tworzyć użytkownik posiadający rolę Planista-Administrator.
Zdefiniowane grafiki można oznaczyć jako aktywne lub nieaktywne.
1.2 Pojedyncze Grafiki są grafikami na okres jednego miesiąca, ale są podpięte pod
dowolnie zdefiniowany okres rozliczeniowy. Miesięczny, Kwartalny, itp. Nowe
okresy może definiować użytkownik posiadający rolę Planista-Administrator.
Definiując okres rozliczeniowy dłuższy niż jeden miesiąc, należy od razu
definiować każdy miesięczny przedział tego okresu poprzez określenie „na
kalendarzu”: Dni Pracujących (domyślnie poniedziałek-piątek), Dni Wolnych
(domyślnie soboty), Niedzieli (domyślnie niedziela), Świąt, Dni świątecznych
dodawanych do czasu nominalnego, Dni świątecznych niewliczanych do czasu
nominalnego, Święto + Wolne. Po oznaczeniu tych dni system automatycznie
pokazuje wyliczoną liczbę dni wliczaną do nominalnego czasu pracy.
1.3 Zdefiniowany nominalny czas pracy jest później wykorzystywany do obliczeń
liczby godzin do zaplanowania w grafiku poszczególnym pracownikom Etatowym
w zależności o liczby już zaplanowanych godzin, wymiaru etatu.
2. Symbole czasu pracy
2.1 Domyślnym widokiem w grafiku, powinien być widok, w którym wizualizacja
czasu pracy w poszczególnych dniach miesiąca jest zrealizowana przy pomocy
symboli. Symbolem może być dowolna mała lub duża litera alfabetu.
2.2 Każdy symbol może odpowiadać dowolnemu przedziałowi czasu zdefiniowanego
z dokładnością co do jednej minuty. Np. symbol N 7:00 – 19:00.
2.3 Konfigurację i zarządzanie symbolami może wykonać użytkownik z rolą PlanistaAdministrator.
2.4 Symbole oznaczone dużymi literami będą definiowane na poziomie
administratora centralnego. Zakłada się również, że każdy dysponent
niezależnie od innego dysponenta może poszerzyć listę symboli w systemie
o własne symbole oznaczone małymi literami. Do dodawania symboli własnych
dysponenta, uprawniony będzie jedynie użytkownik posiadający rolę „planistaadministrator”. Zdefiniowane symbole można oznaczać jako aktywny
i nieaktywny. Symbole nieaktywne nie można użyć w nowo tworzonym grafiku.
2.5 Symbole można wprowadzać w „kratki” grafiku za pomocą klawiatury. Po
kliknięciu prawym klawiszem myszy w menu kontekstowym widnieje pełna lista
dostępnych danemu dysponentowi aktywnych symboli, będąca sumą symboli
centralnych i dysponenta. Na liście widnieje symbol i obok symbolu widać
str. 20 z 82
XI 2015 r. – VI 2016 r.
przedział godzinowy, któremu on odpowiada.
2.6 Po najechaniu kursorem na symbol pojawia się okienko z przedziałem
czasowym, któremu odpowiada symbol złożonym z daty i godziny rozpoczęcia
dyżuru oraz zakończenia dyżuru.
2.7 Niezależnie od symboli zdefiniowanych, po wpisaniu z klawiatury symbolu
specjalnego @ lub wybrania z menu kontekstowego opcji „ustaw czas ręcznie”,
pojawia się możliwość wprowadzenia dowolnej daty i godziny rozpoczęcia
dyżuru. Data i godzina rozpoczęcia jest wstępnie ustawiona na godzinę 00:00
i datę odpowiadającą dacie w „kratce” grafiku w którym rozpoczęto ręczne
ustawianie czasu. Data i godzina zakończenia jest wstępnie ustawiona na
godzinę 23:59 i datę odpowiadającą dacie w „kratce” grafiku, w którym
rozpoczęto ręczne ustawianie czasu. Okienko posiada informację o dacie dnia,
którego dotyczy zmiana w formie Ustawiasz czas ręcznie dla dnia rrrr-mm-dd. Po
ustawieniu zakresu ręcznie w „kratce” pozostaje symbol @.
2.8 Grafik ma możliwość przełączenia do widoku godzin, który wyświetla zamiast
symboli godziny pracy w każdej „kratce”. Przy widoku symboli, kratki są
odpowiednio wąskie i dopasowane do jednej litery w celu zapewnienia
czytelności i zmieszczenia na całym ekranie minimum 2 tygodni z miesiąca.
3. Baza pracowników
3.1 Na karcie Użytkownika/Pracownika, osoba uprawniona powinna mieć możliwość
zdefiniowania następujących parametrów:
– Wymiar zatrudniania (8, 7:35, 5) [godz:min] – słownik edytowalny z poziomu
bazy danych;
– Rodzaj Umowy (Etat, Kontrakt, Kontrakt Zewnętrzny, Umowa Zlecenia –
słownik jw.;
– Wymiar Etatu (1, 1/2,1/4, 3/5 itp.) – słownik edytowalny z poziomu bazy
danych;
– Ilość godzin kontraktu do wypracowania (np. 180 – wartość wpisywana
ręcznie;
- Określenie maksymalnej, możliwej do wypracowania liczby godzin –Kontrakt,
Umowa zlecenie
– Identyfikator pracownika w systemie kadrowym;
– mail pracownika.
3.2 System powinien udostępniać interfejs do integracji z systemem kadrowym
w zakresie wstępnego dodawania pracownika do systemu SWD PRM po
dodaniu go najpierw do systemu kadrowego dysponenta. Dodany automatycznie
nowy pracownik posiada status „nowy” i jego pełna aktywacja w systemie SWD
następuje po zdefiniowaniu pozostałych wymaganych parametrów, przez
wszystkim uprawnień, które nie są dostarczane przez system kadrowy.
3.3 Obecne rozwiązanie dodawania użytkownika/pracownika do systemu, powinno
być rozbudowane w taki sposób, aby była możliwość powiązania z więcej niż
jednym rodzajem zatrudnienia danego pracownika np. Etat i Kontrakt. Dla
każdego z rodzaju zatrudnienia użytkownik może mieć różne parametry opisane
w pkt 5.3.1 oraz różne role w systemie. Np. Na etacie pracuje jako dyspozytor,
a na kontrakcie jako Ratownik. Dla obu tych ról wskazanym aby miał ten sam
login i hasło z opcją autoryzacji w kontekście rodzaju zatrudnienia z jakiego
w danym momencie świadczy pracę.
3.4 Po rozwiązaniu umowy w systemie kadrowym pracownik jest automatycznie
blokowany w systemie SWD PRM.
4. Rejestry centralne Ratowników Medycznych, Lekarzy, Pielęgniarek
4.1 System powinien być zintegrowany z centralnymi rejestrami Ratowników
Medycznych, Lekarzy, Pielęgniarek wytwarzanymi przez MZ. System powinien
okresowo aktualizować swoją bazę w oparciu o rejestr centralny.
UWAGA: Na dzień dzisiejszy takie rejestru centralnego nie ma. Jest on
planowany w najbliższej nowelizacji ustawy o PRM. Do czasu jego stworzenia
str. 21 z 82
XI 2015 r. – VI 2016 r.
będzie konieczność wprowadzania danych pracowników przez poszczególnych
dysponentów.
4.2 Przed aktywacją użytkownika/pracownika w systemie, dysponent będzie musiał
podpiąć go pod rejestr centralny. Wyszukiwanie w rejestrze centralnym będzie
automatyczne i realizowane po numerze PESEL dla Ratowników Medycznych
oraz numerze prawa wykonywania zawodu dla Lekarzy i Pielęgniarek. Jeżeli
pozostałe dane będą się zgadzać, system pozwoli aktywować użytkownika
(dotyczy tylko pracowników medycznych). Dzięki temu powiązaniu system
będzie wykrywał, że dany pracownik zatrudniony u jednego dysponenta zarówno
„na Etat” jak i „na Kontrakt” to jedna i ta sama osoba. Będzie to wykorzystane do
wykrywania nakładania czasu pracy lub powstawania niedozwolonych ciągów
czasu pracy w różnych grafikach na etapie planowaniu grafików z poziomu
dysponenta. Dodatkowo w poziomu Administratora Wojewody lub Administratora
Centralnego da możliwość raportowania u ilu dysponentów dany pracownik jest
zatrudniony, pozwoli na wykrywanie niedozwolonych ciągów czasu pracy u wielu
dysponentów.
4.3 System powinien być przygotowany na wprowadzenie autoryzacji indywidualną
kartą autoryzacyjną (podpis elektroniczny) wydawaną przez MZ każdemu,
ratownikowi pielęgniarce, lekarzowi w powiązaniu z centralnymi rejestrami
prowadzonymi przez MZ. W takim przypadku, powinna być możliwość
przełączenia autoryzacji indywidualnym loginem i hasłem, (który jest różny dla
danego pracownika w przypadku zatrudnienia u więcej niż jednego dysponenta)
na autoryzację jedną kartą autoryzacyjną danego pracownika, używaną
w kontekście tego dysponenta u którego w danym momencie świadczy on pracę.
5. Udostępnianie Grafików Pracownikom
5.1 System umożliwi Drukowanie Grafików w każdym etapie planu i wykonania.
Przykładowy wzór wydruku przedstawia RYSUNEK 1
5.2 System dwa razy w miesiącu automatycznie po zatwierdzeniu planu oraz po
zatwierdzeniu wykonania wyśle godziny pracy danego pracownika na jego maila
jeżeli jest on wpisany w karcie pracownika. Mail będzie zawierał godziny pracy
danego pracownika ułożone chronologicznie ze wszystkich grafików u danego
dysponenta. Przykładowy wzór maila przedstawia RYSUNEK 2.
6. Lista Obecności
6.1 System powinien umożliwiać generowanie listy obecności i jej wydruk.
6.2 Lista obecności powinna być generowana dla jednego lub kilku stanowisk pracy.
6.3 Lista obecności powinna być generowana dla jednego dnia lub zakresu kilku dni.
6.4 Lista obecności powinna zawierać: Imię i Nazwisko Pracownika, nazwę grafiku,
rodzaj umowy, rolę/stanowisko na dyżurze, kolumnę z godzinami pracy ma
podstawie wykonania grafiku, kolumnę z godzinami pracy na podstawie
potwierdzeń rozpoczęcia i zakończenia dyżurów, kolumnę z uwagami, kolumnę
z loginem użytkownika, który dokonał potwierdzenia rozpoczęcia i zakończenia
dyżuru.
7. Interfejs Grafiku
7.1 Interfejs grafiku powinien być w układzie tabeli reprezentującej jeden miesiąc,
dla jednego stanowiska pracy.
7.2 Wiersz nagłówkowy powinien zawierać kolejne dni miesiąca
7.3 Pierwsza kolumna powinna zawierać Imiona i Nazwiska Pracowników dodanych
do grafiku.
7.4 Druga kolumna powinna zawierać rodzaj umowy pracownika.
7.5 Kolejne kolumny to kolejne dni miesiąca.
7.6 Na końcu kolumny zawierające podsumowania dla każdego wiersza (czyli
pracownika): Suma godzin wszystkich godzin zaplanowanych w danym grafiku,
Suma godzin oznaczonych jako „Zwolnienie L4”, Suma godzin oznaczona jako
„Urlop Wypoczynkowy”, Suma godzin pracy oznaczonych jako „Nieobecność
str. 22 z 82
XI 2015 r. – VI 2016 r.
usprawiedliwiona”,
Suma
godzin
oznaczona
jako
„Nieobecność
nieusprawiedliwiona”, Suma godzin pracy.
7.7 Wszystkie wartości w kolumnach podsumowania mają się zmieniać dynamicznie
za każdym razem, gdy wprowadzane są zmiany w poszczególnych „kratkach”
grafiku.
7.8 Grafik powinien posiadać analogiczne jak wyżej opisane podsumowanie
poziome dla każdego dnia miesiąca. Celem tego podsumowania jest pokazanie
planiście ile godzin jeszcze brakuje, aby dyżur był zabezpieczony 24h/dobę.
7.9 W przypadku gdy okres rozliczeniowy jest większy niż jeden miesiąc, w/w
podsumowania podają dodatkowo w nawiasie wartości w kontekście całego
okresu rozliczeniowego.
8. W grafiku powinna być możliwość oznaczenia nieobecności dla pojedynczych dni
oraz dla większego zakresu czasowego następujących typów: Zwolnienie L4,
Urlop
Wypoczynkowy,
Nieobecność
Usprawiedliwiona,
Nieobecność
Nieusprawiedliwiona.
9. W grafiku powinna być możliwość wyznaczenia dla każdej osoby niezależnie,
indywidualnego kalendarza pracy z możliwością oznaczenia w dowolnym dniu:
Wolnego za sobotę, wolnego za niedzielę, wolnego za święto, dnia pracy,
10. System daje możliwości planiście automatycznego wypełniania serią dyżurów na
cały miesiąc dla danego pracownika np. w układzie Dzień, Noc, Wolne, Wolne,
Dzień, Noc, Wolne, Wolne, lub Dzień, Dzień, Dzień, Dzień, Dzień, Wolne, Wolne.
Możliwość generowania serii dostosowanej do potrzeb danego dysponenta.
11. Wykrywanie konfliktów i ciągłości
11.1 Przy próbie zatwierdzania grafików system wykrywa i pokazuje nakładanie się
dyżurów jednej osoby w ramach dysponenta i niezależnie w ramach całego
systemu.
11.2 System wykrywa i pokazuje ciągłości pracy jednej osoby w ramach dysponenta
i niezależnie w ramach całego systemu. Reguły tych ciągłości wymagać będą
doprecyzowania, wstępnie można powiedzieć o wykrywaniu dyżurów pracy
ciągłej powyżej 24 godzin na dowolnym stanowisku, pracy powyżej 12 godzin
na stanowisku kierowcy,
11.3 Wykrycie poszczególnych konfliktów i ciągłości uruchamia funkcję blokowania
zatwierdzenia grafiku lub ostrzegania planisty.
11.4 Funkcja wykrywania konfliktów pokazuje w układzie graficznym miesięcznym
zestawienie wszystkich dyżurów danego pracownika na wszystkich grafikach
w ramach jednego dysponenta z zaznaczeniem graficznym konfliktów,
ciągłości, przekroczeń wymiaru etatu/ maksymalną liczbę godzin
kontraktowych.
12. Statusy Grafików – Plan, Wykonanie Etapy Tworzenia i Zatwierdzania
12.1 W systemie powinny istnieć następujące statusy grafików: Przygotowanie
Planu – Planista, zakończenie Planu-Planista, Zatwierdzanie Planu-Kadry,
Odrzucanie Planu-Kadry, Zatwierdzenie Planu-Zarząd(ostateczne wszystkich
planów w danym okresie jednocześnie). Od tego momentu Plan zostaje
zamrożony i przepisany do Wykonania, dalsze zmiany są dokonywane jedynie
na wykonaniu. Kolejnymi statusami są: Zatwierdzenie Wykonania-Planista,
zatwierdzenie Wykonania-Kadry, Odrzucenie wykonania-Kadry, Zatwierdzenie
Wykonania-Zarząd (ostateczne dla wszystkich wykonań w danym okresie
jednocześnie).
12.2 W grafiku powinien istnieć: Widok Planu, Widok Wykonania i widok
zestawionego Plan i Wykonania, Podsumowania godzin.
13. Planista tworząc nowy grafik na kolejny miesiąc powinien mieć możliwość pobrania
str. 23 z 82
XI 2015 r. – VI 2016 r.
listy osób z grafiku na to samo stanowisko z poprzedniego miesiąca oraz jej
dalszej edycji.
14. W systemie muszą istnieć następujące role dla użytkowników związane
z grafikami:
Planista,
Planista
Zatwierdzający(Kadry),
Planista
Zatwierdzający(Zarząd), Planista Administrator.
15. System umożliwia
etatowego.
wydruk
Indywidualnej
Karty
Czasu
Pracy
pracownika
16. Mechanizm rozpoczęcia i zakończenia dyżuru zapisuje trwale w systemie godzinę
rzeczywistego rozpoczęcia i zakończenia pracy. Jeżeli użytkownik dokonuje
potwierdzenia zakończenia lub rozpoczęcia dyżuru do 15 minut przed lub po
godzinie wynikającej z wykonania grafiku, to system dokonuje dodatkowo
automatycznej zmiany w tym grafiku w wykonaniu i oznacza symbol gwiazdką np.
D* oraz prosi pracownika o podanie przyczyny. Po odczytaniu przyczyny Planista
może uznać wytłumaczenie (np. awaria komputera) i dokonać ręcznie korekty do
godziny pierwotnej wynikającej z grafiku lub pozostawić jako spóźnienie,
nadgodziny itp.
17. System powinien mieć możliwość integracji z systemami kadrowymi w zakresie
exportu planu i wykonania każdego pracownika wraz ze wszystkimi oznaczeniami
niezbędnymi do wyliczenia wszystkich składników wynagrodzenia poprzez
uniwersalny interfejs.
18. Dodatkowo system powinien mieć możliwość integracji (odpowiedni interfejs)
z systemami kadrowymi również w takim wariancie, że grafiki są układane
i zatwierdzane w systemie zewnętrznym dysponenta, a do SWD ładowane są
jedynie dane wynikowe zatwierdzonych grafików do realizacji. W takim przypadku
system będzie używał tych danych do realizacji dalszych procesów w analogiczny
sposób jak by były wytworzone w wewnętrznym module planisty.
19. System powinien być zgodny z polskim Prawem Pracy.
4. Kryteria
akceptacji
zadania:
str. 24 z 82
XI 2015 r. – VI 2016 r.
RYSUNEK 1 DO SPECYFIKACJI NR 6
str. 25 z 82
XI 2015 r. – VI 2016 r.
RYSUNEK 2 DO SPECYFIKACJI NR 6
Grafik na miesiąc maj – plan zatwierdzony
Rodzaj umowy
Nazwa grafiku
Typ grafiku
Data pocz.
Data końcowa
Etat
Jas_Ratownik
K01-042
2015-06-01 07:00:00
2015-06-01 19:00:00
Kontrakt
Jas_Kierowca
K01-042
2015-06-01 19:00:00
2015-06-02 07:00:00
Etat
Jas_Ratownik
K01-042
2015-06-02 19:00:00
2015-06-03 07:00:00
Kontrakt
Jas_Kierowca
K01-040
2015-06-03 19:00:00
2015-06-04 07:20:00
Etat
Jas_Ratownik
K01-042
2015-06-04 07:20:00
2015-06-04 19:00:00
Kontrakt
Jas_Kierowca
K01-042
2015-06-05 19:00:00
2015-06-06 07:00:00
Etat
Jas_Ratownik
K01-042
2015-06-06 19:00:00
2015-06-07 07:00:00
Kontrakt
Jas_Kierowca
K01-042
2015-06-07 07:00:00
2015-06-07 19:00:00
Kontrakt
Jas_Kierowca
K01-042
2015-06-08 07:00:00
2015-06-08 19:00:00
Kontrakt
Jas_Kierowca
K01-038
2015-06-08 19:00:00
2015-06-08 19:30:00
Etat
Jas_Ratownik
K01-042
2015-06-09 07:00:00
2015-06-09 19:00:00
Etat
Jas_Ratownik
K01-042
2015-06-10 19:00:00
2015-06-11 07:30:00
Kontrakt
Jas_Kierowca
K01-042
2015-06-11 07:30:00
2015-06-11 19:00:00
Etat
Jas_Ratownik
K01-042
2015-06-13 19:00:00
2015-06-14 07:00:00
Kontrakt
Jas_Kierowca
K01-040
2015-06-14 07:00:00
2015-06-14 07:30:00
Kontrakt
Jas_Kierowca
K01-042
2015-06-15 19:00:00
2015-06-16 07:00:00
Kontrakt
Masl_Kierowca
K01-004
2015-06-16 19:00:00
2015-06-17 06:30:00
Etat
Jas_Ratownik
K01-042
2015-06-17 07:00:00
2015-06-17 19:00:00
Etat
Jas_Ratownik
K01-042
2015-06-18 19:00:00
2015-06-19 07:00:00
Kontrakt
Jas_Kierowca
K01-042
2015-06-19 07:00:00
2015-06-19 19:25:00
Kontrakt
Jas_Kierowca
K01-038
2015-06-20 19:00:00
2015-06-21 07:00:00
Etat
Jas_Ratownik
K01-042
2015-06-21 07:00:00
2015-06-21 19:00:00
Etat
Jas_Ratownik
K01-042
2015-06-23 07:00:00
2015-06-23 19:00:00
Kontrakt
Masl_Kierowca
RT-5
2015-06-24 09:00:00
2015-06-24 15:00:00
Kontrakt
Jas_Kierowca
K01-042
2015-06-24 19:00:00
2015-06-25 07:00:00
Etat
Jas_Ratownik
K01-042
2015-06-25 07:00:00
2015-06-25 10:15:00
Kontrakt
Jas_Kierowca
K01-042
2015-06-26 07:00:00
2015-06-26 19:00:00
Etat
Jas_Ratownik
K01-042
2015-06-26 19:00:00
2015-06-27 07:00:00
Kontrakt
Masl_Kierowca
RT-5
2015-06-29 09:00:00
2015-06-29 15:00:00
Kontrakt
Jas_Kierowca
K01-042
2015-06-29 19:00:00
2015-06-30 07:00:00
Etat
Jas_Ratownik
K01-042
2015-06-30 19:00:00
2015-07-01 07:00:00
str. 26 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
2. Opis
przedmiotu
zadania:
3. Wyniki
realizacji
zadania:
Wdrożenie warstwy bazy danych do raportowania na poziomach dysponenta,
dyspozytorni, województwa, centralnym z uwzględnieniem ograniczenia uprawnień do
danych osobowych i wrażliwych na poziomach nadrzędnych oraz ograniczeniem
widoczności danych operacyjnych pomiędzy różnymi jednostkami/obszarami na tym
samym poziomie.
1. Zaprojektowanie i wdrożenie architektury raportowej składającej się z trzech warstw
oraz procesów obsługujących ich zasilanie. Częstość zasilania do ustalenia
w ramach analizy – wstępnie zakładane zasilanie dobowe w dwóch pierwszych
warstwach i zasilanie miesięczne na poziomie warstwy raportowej. Okres
przechowywania danych do ustalenia w ramach analizy. Charakterystyka
oczekiwanych warstw bazy danych:
a. Warstwa przechowywania danych bazowych – przechowuje dane z systemów
źródłowych (SWD PRM) w postaci pierwotnej.
b. Warstwa integracji danych źródłowych – odpowiedzialna za przechowywanie
detalicznych danych w postaci jednorodnej, W przypadku zmian w zawartości
dokumentacji medycznej, w tej warstwie następuje jej uspójnienie do ogólnie
stosowanego standardu wymaganego w sprawozdawczości.
c. Warstwa raportowa/Mart – udostępnia dane w postaci oczekiwanej przez
odbiorców raportów z uwzględnieniem potrzeb informacyjnych i uprawnień do
danych. Dane podzielone na miary i charakteryzujące je wymiary. Pozwala na
szybkie zestawienie raportów w różnych konfiguracjach miar.
2. Wdrożona warstwa bazy danych na poziomie raportowym zawierająca kompletną
informację o zgłoszonych zdarzeniach i wyjazdach ZRM, w tym kompletną
informację zawartą w Dokumentacji Medycznej, dane pacjentów i personelu
obsługującego Zlecenia.
3. W warstwie raportowej należy udostępnić wstępnie wyliczone parametry
statystyczne z możliwością przejścia do danych detalicznych (drill down) służących
do ich wyznaczenia.
4. W zależności od poziomu dostępu do danych, należy wyznaczyć wartości miar
w wymiarach:
a. Dla dysponenta: rejon operacyjny, wyjazd w rejonie/poza rejon, MS ZRM,
ZRM, pacjent, miejsce Zdarzenia – rodzaj, miejsce Zdarzenia – ulica, miejsce
Zdarzenia – miejscowość, miejsce Zdarzenia – w mieście pow.10tys./poza
miastem, powód wezwania, czy masowe, odmowa/odrzucenie (powody
odmowy), kod pilności, stan zagrożenia życia (KMCR), rodzaj obrażeń,
zastosowane procedury (ICD-9), zastosowane leki, pracownik/członek ZRM,
dyspozytor, postępowanie z pacjentem (pacjent pozostał, przewieziony do,
oświadczenia pacjenta), zgon, choroba zakaźna, ICD-10, zdarzenia z 1
pacjentem (wartością <> 1), z 1/ 2-5/ >5 KZW.
b. Dla dyspozytorni (dysponenta, do którego przynależy dyspozytornia):jak dla
dysponenta + wymiary dysponent, dyspozytor przyjmujący, dyspozytor
wysyłający, stanowisko dyspozytorskie aktywne w zgłoszeniu, użycie ZRM
nieprzypisanego do danej dyspozytorni,
c. Dla województwa: rejon operacyjny, wyjazd w rejonie/poza rejon,
dyspozytornia, dysponent, MS ZRM, ZRM, pacjent – płeć, pacjent – wiek,
pacjent – obywatelstwo, pacjent – miejsce zamieszkania (województwo, gmina,
miejscowość), pacjent – kod NFZ, miejsce Zdarzenia – rodzaj, miejsce
Zdarzenia – ulica, miejsce Zdarzenia – miejscowość, miejsce Zdarzenia –
w mieście pow.10tys./poza miastem, powód wezwania, czy masowe,
odmowa/odrzucenie (powody odmowy), kod pilności, stan zagrożenia życia
(KMCR), rodzaj obrażeń, zastosowane procedury (ICD-9), zastosowane leki,
postępowanie z pacjentem (pacjent pozostał, przewieziony do, oświadczenia
pacjenta), odmowa przyjęcia do SOR, pacjenta przekazano innemu Zespołowi,
brak pacjenta w miejscu zdarzenia, zgon, choroba zakaźna, ICD-10, zdarzenia
z 1 pacjentem (wartością <> 1), z 1/ 2-5/ >5 KZW, użycie ZRM
str. 27 z 82
XI 2015 r. – VI 2016 r.
nieprzypisanego do danej dyspozytorni/województwa,
d. Centralnie: rejon operacyjny, wyjazd w rejonie/poza rejon, dyspozytornia,
dysponent, pacjent – płeć, pacjent – wiek, pacjent – obywatelstwo, pacjent –
miejsce zamieszkania (województwo, gmina, miejscowość), pacjent – kod NFZ,
miejsce Zdarzenia – rodzaj, miejsce Zdarzenia – miejscowość, miejsce
Zdarzenia – w mieście pow.10tys./poza miastem, powód wezwania, czy
masowe, odmowa/odrzucenie (powody odmowy), kod pilności, stan zagrożenia
życia (KMCR), rodzaj obrażeń, zastosowane procedury (ICD-9), zastosowane
leki, postępowanie z pacjentem (pacjent pozostał, przewieziony do,
oświadczenia pacjenta), odmowa przyjęcia do SOR, pacjenta przekazano
innemu Zespołowi, brak pacjenta w miejscu zdarzenia, zgon, choroba zakaźna,
ICD-10, zdarzenia z 1 pacjentem (wartością <> 1), z 1/ 2-5/ >5 KZW, użycie
ZRM nieprzypisanego do danej dyspozytorni/województwa,
5. Dane w warstwie raportowej powinny zostać pogrupowane logicznie zgodnie
z charakterem danych (miary, wymiary) i uprawnieniami użytkownika (poziom
dostępu do danych). Wstępnie proponowane grupy danych:
a. Miary: średnie czasy (całkowite i czasy przekroczeń), mediany czasów reakcji
(całkowite i czasy przekroczeń), dojazdu do miejsca zdarzenia, obsługi
zdarzenia, przebywania w statusie gotowości/w akcji (statusy związane
z obsługą Zdarzenia), czasów oczekiwania na przekazanie pacjenta
i procedury przekazania w SOR, powrotu do MS, przebywania w statusach
technicznych: awaria, tankowanie, mycie, dezynfekcja, liczby wyjazdów
w poszczególnych wymiarach, liczba pacjentów, liczba ponagleń,
b. Wymiar pacjent szczegółowo (dla Dysponenta): dane osobowe, adresowe,
płeć, wiek, obywatelstwo, przypisanie do nfz, stan zagrożenia życia (KMCR),
rodzaj obrażeń, zastosowane procedury (ICD-9), zastosowane leki,
postępowanie z pacjentem (pacjent pozostał, przewieziony do, oświadczenia
pacjenta), zgon, choroba zakaźna, ICD-10,
c. Wymiar pacjent ogólny (dla statystyk): dane osobowe bez imienia i nazwiska,
adresowe (tylko do poziomu miejscowości), płeć, wiek, obywatelstwo,
przypisanie do nfz, stan zagrożenia życia (KMCR), rodzaj obrażeń,
zastosowane procedury (ICD-9), zastosowane leki, postępowanie z pacjentem
(pacjent pozostał, przewieziony do, oświadczenia pacjenta), zgon, choroba
zakaźna, ICD-10,
d. Wymiar Zdarzenie szczegółowo (dla Dysponenta i Dyspozytorni): wszystkie
informacje określające miejsce Zdarzenia, powód wezwania, czy masowe,
odmowa/odrzucenie (powody odmowy), kod pilności, odmowa przyjęcia do
SOR, pacjenta przekazano innemu Zespołowi, brak pacjenta w miejscu
zdarzenia, zdarzenia z 1 pacjentem (wartością <> 1), z 1/ 2-5/ >5 KZW, użycie
ZRM nieprzypisanego do danej dyspozytorni/województwa,
e. Wymiar Zdarzenie statystycznie: rejon operacyjny, adres z dokładnością do
nazwy miejscowości i ulicy, nr drogi + kilometr, w mieście/poza miastem, opis,
rodzaj miejsca zdarzenia, powód wezwania, czy masowe, odmowa/odrzucenie
(powody odmowy), kod pilności, odmowa przyjęcia do SOR, pacjenta
przekazano innemu Zespołowi, brak pacjenta w miejscu zdarzenia, zdarzenia
z 1 pacjentem (wartością <> 1), z 1/ 2-5/ >5 KZW, użycie ZRM
nieprzypisanego do danej dyspozytorni/województwa,
f. ZRM obsługujący (dla dysponenta): wszystkie informacje włącznie z danymi
pojazdu i danymi osobowymi członków ZRM.
g. ZRM obsługujący (dla statystyk): typ, liczba osób w składzie, przynależność do
dysponenta, miejsce stacjonowania (nazwa, adres)
4. Kryteria
akceptacji
zadania:
str. 28 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
2. Opis
Automatyzacje w wypełnianiu KZW – powiązanie ICD 9 na KZW z wypełnionymi
przedmiotu
medycznymi czynności na KMCR.
zadania:
1. Zaimplementowanie do SWD PRM aktualnej międzynarodowej klasyfikacji procedur
medycznych ICD-9-CM (w wersji polskiej).
2. W Aplikacji mobilnej ZRM w Karcie Zlecenia Wyjazdu w zakładce V Procedury
Medyczne udzielone przez ZRM (ICD9) znajdują się kody ICD 9 (zgodne z aktualną
3. Wyniki
międzynarodową klasyfikacją procedur medycznych ICD-9-CM w polskiej wersji)
realizacji
zaimportowane z danych zaznaczonych w Karcie Medycznych Czynności
zadania:
Ratunkowych
Dodatkowa możliwość ręcznego generowania przez kierownika
ZRM kodów ICD 9 w KZW w polu Podsumowanie.
3. Rozwijana słownikowana lista kodów ICD 9 przy ręcznym wpisywaniu kodów po
określeniu ciągu 3 (słownie: trzech) znaków, w tym liter lub cyfr.
1. W Aplikacji mobilnej ZRM automatyczne uwidocznienie kodów ICD 9 po
uzupełnieniu przez kierownika ZRM Karcie Medycznych Czynności Ratunkowych
Możliwość wstawienia dodatkowych, niż wymienione w KMCR czynności za
pomocą ręcznego wpisywania wykonanych procedur w polu INNE zawartych
w zamkniętym katalogu (międzynarodowa klasyfikacja procedur medycznych ICD9-CM). Katalog ICD-9-CM jest słownikiem dynamicznym. Wyszukiwanie
i automatyczne podpowiadanie wyrazów następuje na podstawie słów kluczowych.
Po dokonaniu wyboru danej czynności, odpowiadające tej procedurze kody ICD 9
automatycznie uwidocznione są w KZW w części V. Podsumowanie w polu
Procedury medyczne.
2. Kody ICD 9 zapisane w formacie zgodnym ze słownikiem międzynarodowej
klasyfikacji procedur medycznych (ICD-9-CM)- wersja pl (rozszerzona).
3. W przypadku zmiany/aktualizacji międzynarodowej klasyfikacji procedur…
4. Kryteria
Administrator Centralny aktualizuje katalog ICD 9.
akceptacji
4. Możliwość wprowadzenia dodatkowych słów kluczy przez Administratora
zadania:
Centralnego.
5. Warunki dodatkowe (mogą być zapisane w umowie ogólnej):
a. Należy
wprowadzić
właściwe
zapisy
w dokumentacji
użytkownika
i dokumentacji technicznej systemu oraz zaktualizować scenariusze testowe.
b. Zmiana powinna zostać zainstalowana i przetestowana na środowisku
szkoleniowym z wynikiem pozytywnym. Wykonawca zobowiązany jest do
wcześniejszego
wykonania
testów
wewnętrznych
na
środowisku
deweloperskim. Warunkiem dopuszczenia systemu do zainstalowania
w środowisku szkoleniowym jest zakończenie testów wewnętrznych wynikiem
pozytywnym, potwierdzone raportem z testów.
c. Zmiana, po przetestowaniu na środowisku szkoleniowym, powinna zostać
przekazana w postaci kompletnej paczki instalacyjnej wraz z opisem sposobu
instalacji Administratorowi Systemu.
str. 29 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
Dodanie statusu ZRM POMOC – na potrzebę cichego powiadomienia dyspozytora
2. Opis
przedmiotu wysyłającego/ dyspozytora głównego na wypadek zagrożenia bezpieczeństwa
członków ZRM.
zadania:
1. W Aplikacji ZRM dodatkowe okno informujące o POMOCY.
2. Okno ze statusem POMOC zawiera informację o kryptonimie ZRM, czasie, jaki
upłynął od momentu zmiany statusu ZRM na status POMOC w formacie gg:mm:ss
(godziny:minuty:sekundy).
3. Okno zostaje wyłączone indywidualnie przez dyspozytora medycznego na danym
stanowisku dyspozytorskim, który dysponował ZRM do ostatniego wezwania.
3. Wyniki
4. W przypadku uruchomienia statusu ZRM POMOC dodatkowo system SWD PRM
realizacji
w module dyspozytora generuje dźwięk.
zadania:
5. Sygnalizowanie ZRM POMOC widoczne dla stanowiska dyspozytora medycznego
dysponującego ZRM oraz dyspozytora głównego i jego zastępcy.
6. Sygnalizowanie POMOC jest realizowane także poprzez podświetlenie wiersza
ZRM w sekcji Lista ZRM oraz wiersza Zdarzenia w liście Zdarzeń (sugerowany
kolor brązowy).
7. Ikona ZRM ze statusem POMOC ma symbolem.
1. W Aplikacji Dyspozytora SWD PRM dodatkowe okno wyłącznie po przejściu ZRM
w status POMOC.
2. Status POMOC może zostać określony przez ZRM niezależnie od aktualnego
statusu ZRM.
3. Status POMOC wyłączany jest automatycznie po ręcznej zmianie przez kierownika
ZRM statusu na inny lub zmianie ręcznej dokonanej przez zgłaszającego lub przez
DM Głównego po uprzednim kontakcie z ZRM inną metodą niż SWD PRM.
4. W sekcji Lista ZRM dodana kolumna z informacją o czasie od momentu określenia
dla ZRM statusu POMOC w formacie gg:mm:ss (godziny:minuty:sekundy).
5. Wartość w kolumnie z czasem zerowana automatycznie przy zmianie przez ZRM
statusu lub poprzez zmianę statusu przez dyspozytora głównego po konsultacji
z ZRM.
6. Zachowana widoczność wszystkich dotychczas dostępnych informacji w ekranie
(zarówno w sekcji Lista ZRM, jak w pozostałych sekcjach).
7. Sygnalizowanie o statusie ZRM POMOC jest widoczne na wszystkich stacjach
4. Kryteria
roboczych dyspozytorów medycznych oraz na stanowisku dyspozytora głównego.
akceptacji
8. Sygnalizowanie statusie ZRM POMOC w sposób zgodny z opisem w pkt. 2 i 5
zadania:
Wynik realizacji zlecenia.
9. Po ustawieniu przez ZRM statusu POMOC centralizacja na mapie UMM
z lokalizacją ZRM.
a. Należy
wprowadzić
właściwe
zapisy
w dokumentacji
użytkownika
wcześniejszego
wykonania
testów
wewnętrznych
na
środowisku
str. 30 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
2. Opis
przedmiotu
zadania:
3. Wyniki
realizacji
zadania:
4. Kryteria
akceptacji
zadania:
W systemie musi być wdrożony mechanizm efektywnego wyszukiwania zgłoszeń
pozwalający na stworzenie dowolnego zapytania wyszukującego.
Opisane możliwości filtrowania będą miały zastosowanie w dodatkowym oknie do
przeglądania danych historycznych opisanych w funkcjonalności nr 13.
W systemie powinna być możliwość wyszukiwania po wszystkich polach jednocześnie
bez zastosowania wielkości znaków (A=a).
Wyszukiwanie takie powinno działać w taki sposób, że wyszukuje wszystkie karty,
które posiadają w dowolnym polu cześć wyszukiwanego ciągu znaków
z uwzględnieniem opisanej wyżej zasady porównywania.
Możliwość precyzyjnego wykonania zapytania do bazy z użyciem dowolnej ilości pół.
Takie zapytanie wyszukujące powinno składać się z dowolnej ilości wyrażeń i aby
uznać zlecenie za dopasowanie do zapytania to wszystkie wyrażenia zapytania musza
być spełnione. Każde wyrażenie dotyczy konkretnego pola na karcie wyjazdowej.
2 typy wyrażeń:
• Znalezienie idealnego dopasowania w polu (np. dla „Kowal” znajduje tylko „Kowal”)
• Znalezienie podciągu znaków w polu bez uwzględnienia wielkości znaków (np. dla
„owal” znajduje „Kowalski”, „KOwalska”)
Wdrożenie opisanego mechanizmu do systemu.
str. 31 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
Na terminalu mobilnym oraz w miejscu stacjonowania dodatkowe komunikaty dla ZRM
2. Opis
dokonania
przez
dyspozytora
medycznego
zmian danych
przedmiotu w przypadku
w zgłoszeniach.
zadania:
1. W aplikacji mobilnej i miejsca stacjonowania SWD PRM dodatkowe okno
informujące o zmianie przez dyspozytora medycznego danych w zgłoszeniu, tj.: kod
pilności, adres miejsca zgłoszenia, powód wezwania, itd..
2. Dodatkowa kolumna w formatce zgłoszenia zawiera informację o zmianie danych
dotyczących miejsca zdarzenia, powodu wezwania, kodu pilności.
3. Przycisk w formatce zgłoszenia do wysyłania dodatkowych zmian w zgłoszeniu dla
zadysponowanego ZRM.
4. Możliwość wyboru przez dyspozytora czy wprowadzone zmiany w przyjętym
zgłoszeniu należy wysłać do zadysponowanego ZRM.
5. W aplikacji dyspozytora w formatce przyjęcia zdarzenia wprowadzenie
3. Wyniki
dodatkowego pola do umieszczania informacji związanych ze zmianą danych
realizacji
zawartych w formatce.
zadania:
6. Możliwość przesłania zaktualizowanych danych do ZRM za pomocą dedykowanego
przycisku. Informacje wprowadzone w polu, o którym mowa w pkt 5 są
odwzorowane w księdze dysponenta w Kolumnie UWAGI.
7. Okno powiadomienia odebrania zmian w zleceniu pozostaje wyłączone
indywidualnie przez kierownika ZRM na terminalu mobilnym.
8. Sygnalizowanie o zmianie danych przez dyspozytora medycznego w zgłoszeniu
jest widoczne na terminalu mobilnym ZRM oraz w miejscu stacjonowania, którego
dotyczą zmiany w zgłoszeniu.
9. Sygnalizowanie o zmianach widoczne w dodatkowym oknie w następujących
statusach ZRM: zadysponowany, wyjazd, na miejscu.
1. W Aplikacji mobilnej i miejsca stacjonowania dodatkowe okno informujące
o zmianie przez dyspozytora medycznego adresu miejsca zdarzenia, powodu
wezwania, kodu pilności.
2. Zmiany sygnalizowane są na terminalu mobilnym i w stacji wyczekiwania
dodatkowo sygnalizowane dźwiękowo o zmianach.
3. Dodatkowe okno informujące o zmianach na terminalu mobilnym wymaga
potwierdzenia przez kierownika ZRM.
4. Dodatkowe okno informujące o zmianach w miejscu stacjonowania ZRM wymaga
potwierdzenia przez członka ZRM.
5. Dodatkowe okno sygnalizowane sygnałem dźwiękowym na terminalu mobilnym
i miejscu stacjonowania wyłączane jest poprzez potwierdzenie Kierownika ZRM
terminala mobilnego.
4. Kryteria
7. Sygnalizowanie statusu ZRM POMOC w sposób zgodny z opisem w pkt. 2 Wynik
akceptacji
realizacji zlecenia.
zadania:
a. Należy
wprowadzić
właściwe
zapisy
w dokumentacji
użytkownika
wcześniejszego
wykonania
testów
wewnętrznych
na
środowisku
str. 32 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
2. Opis
przedmiotu Kopiowanie danych z ekranu zdarzenia do KZW w przypadku wielu poszkodowanych
zadania:
1. Pole „Wywiad – opis” obsługiwane analogicznie, jak pozostałe dane ZDARZENIA
(nie dane pacjenta), tzn.:
2. Wywiad – opis powinien być kopiowany DO WSZYSTKICH KZW w Zdarzeniu,
niezależnie od liczby pacjentów, ZAWSZE. Pozostawić możliwość modyfikacji
wartości pola w KZW, jak dotychczas.
3. Dane pacjenta w Zdarzeniu są dostępne do edycji wyłącznie, gdy jest określone, że
jest 1 pacjent/poszkodowany. Wprowadzone dane pacjenta (Imię, Nazwisko, Płeć,
Wiek, Lata, Miesiące, Dni życia) mają się kopiować do wszystkich KZW (gdy jest
jeden pacjent) – również ich modyfikacje. Można zmodyfikować dane pacjenta
w KZW i taka zmiana nie powinna być przeniesiona do danych zdarzenia
(kopiowanie danych w jedną stronę). W przypadku, gdy w KZW są wprowadzone
dane pacjenta, kopiowanie nowych danych do KZW wymaga potwierdzenia.
4. W przypadku, gdy liczba pacjentów jest określona na wartość inną od „1” (po
3. Wyniki
obcięciu spacji z obu stron), dane pacjenta w Zdarzeniu są NIEDOSTĘPNE do
realizacji
edycji. Kolejne KZW są wystawiane na NN. Dane pacjenta można zmodyfikować
zadania:
w KZW.
5. W przypadku więcej niż 1 pacjenta zaznaczonego w formatce podczas
przyjmowania zdarzenia a następnie zmiany tej informacji, np. z 3 pacjentów na 1,
należy odblokować dane pacjenta w danych Zdarzenia i wyświetlić okno dialogowe
z pytaniem o przeniesienie danych z KZW zespołu ratownictwa medycznego, który
został zadysponowany jako pierwszy.
6. Dyspozytor medyczny powinien mieć, niezależnie od wprowadzonej liczby
pacjentów, możliwość edycji danych pacjenta w konkretnej KZW – dotyczyć to
będzie sytuacji, w której jest więcej KZW.
7. Należy wprowadzić mechanizmy sterujące dostępnością do edycji pól objętych
zmianą oraz zaimplementować funkcjonalność kopiowania danych z pola Wywiad
do KZW i pomiędzy polami opisującymi pacjenta/ów w ekranie Zgłoszenia i w KZW,
zgodnie z opisem.
1. Wywiad – opis kopiowany DO WSZYSTKICH KZW w Zdarzeniu, niezależnie od
liczby pacjentów, ZAWSZE. Pozostawić możliwość modyfikacji wartości pola
w KZW, jak dotychczas.
2. W przypadku kopiowania kolejnej wersji Wywiadu medycznego, wyświetla się
dodatkowy komunikat informujący o automatycznym zaktualizowaniu wywiadu
medycznego we wszystkich KZW. Wyjście z okna komunikatu wyłącznie przez OK.
3. Nowe KZW w Zdarzeniu (przy tworzeniu nowego zlecenia wyjazdu) zawsze
pobiera aktualną wartość pola Wywiad – opis.
4. Dane pacjenta w Zdarzeniu są dostępne do edycji wyłącznie, gdy jest określone,
że jest 1 pacjent/poszkodowany. – wartość w polu z liczbą pacjenta po obcięciu
początkowych i końcowych spacji = „1”. Wartości wprowadzone w innym formacie
4. Kryteria
(tekstem, cyfrą rzymską, zakończenie kropką itd.) będą interpretowane, jako
akceptacji
wartość niepozwalająca na wprowadzanie danych pacjenta z poziomu Zdarzenia.
zadania:
5. Jeżeli liczba pacjentów w zdarzeniu = 1 i w KZW nie było wprowadzonych danych
pacjenta (NN), wprowadzone dane pacjenta (Imię, Nazwisko, Płeć, Wiek, Lata,
Miesiące, Dni życia) mają się kopiować automatycznie do wszystkich KZW (gdy
jest jeden pacjent).
6. Jeżeli liczba pacjentów w zdarzeniu = 1 i w Zdarzeniu wprowadzono dane pacjenta
(Imię, Nazwisko, Płeć, Wiek, Lata, Miesiące, Dni życia), przy wystawieniu
kolejnego KZW w Zdarzeniu, dane pacjenta mają się kopiować automatycznie do
tego KZW.
7. W przypadku modyfikacji danych pacjenta, jeżeli liczba pacjentów w zdarzeniu = 1,
wyświetla się dodatkowy komunikat informujący o automatycznym zaktualizowaniu
str. 33 z 82
XI 2015 r. – VI 2016 r.
danych pacjenta we wszystkich KZW. Wyjście z okna komunikatu wyłącznie przez
OK. bądź Anuluj (dane nie są kopiowane do KZW).
8. Można zmodyfikować dane pacjenta w KZW i taka zmiana nie przenosi się do
danych zdarzenia (kopiowanie danych w jedną stronę).
9. W przypadku, gdy liczba pacjentów jest określona na wartość inną od „1” (po
obcięciu spacji z obu stron), dane pacjenta w Zdarzeniu są NIEDOSTĘPNE do
edycji. Kolejne KZW są wystawiane na NN. Dane pacjenta można zmodyfikować
w KZW.
10. W
przypadku
więcej
niż
1
pacjenta
zaznaczonego
w formatce
zdarzenia,a następnie zmiany tej informacji, np. z 3 pacjentów na 1, następuje
odblokowanie do edycji danych pacjenta w danych Zdarzenia. Wyświetla się okno
dialogowe z pytaniem o przeniesienie danych z pierwszego KZW dla Zdarzenia,
o ile istnieje. W przypadku potwierdzenia (OK.), dane są kopiowane z pierwszego
KZW do Zdarzenia, w przypadku anulowania operacji kopiowania, wyświetlą się
niewypełnione pola w trybie edycji – bez kopiowania. W przypadku braku
wystawionych
nieanulowanych
KZW
w Zdarzeniu,
brak
dodatkowych
działań/komunikatów – następuje wyłącznie odblokowanie do edycji danych
pacjenta w danych Zdarzenia.
11. Dyspozytor medyczny ma, niezależnie od wprowadzonej liczby pacjentów,
możliwość edycji danych pacjenta w konkretnej KZW – dane po zmianie nie są
kopiowane do Zdarzenia ani do innych KZW.
str. 34 z 82
XI 2015 r. – VI 2016 r.
Specyfikacja zmiany nr: 13.0 (99-0)
1. Identyfikator
zlecenia:
2. Opis
przedmiotu
zadania:
3. Wyniki
realizacji
zadania:
Raport przedstawia pełne, szczegółowe statystyki dotyczące wyjazdów ZRM,
posiadających określony czas dojazdu na miejsce zdarzenia, niezbędne do
monitorowania działania systemu PRM. Zapewnia dogłębną analizę systemu
i umożliwia pełny obraz województwa pod względem czasów dotarcia na miejsce
zdarzenia.
Wymagane jest stworzenie następujących pól raportu:
1. Rejon/Dyspozytornia/Powiat/Gmina/Miejscowość/ZRM (w zależności od wyboru
oczekiwanego kryterium)
2. Liczba interwencji ogółem (od przyjęcia zgłoszenia do dotarcia na miejsce
zdarzenia)
3. Liczba interwencji w granicach maksymalnych czasów ustawowych (dla miast
powyżej 10 tys. mieszkańców do 15 min., poza miastami powyżej 10 tys.
mieszkańców do 20 minut)
4. Liczba wyjazdów przekraczających ustawowy czas maksymalny dotarcia na
miejsce zdarzenia (ogółem)
5. Liczba wyjazdów przekraczających ustawowy czas maksymalny dotarcia na
miejsce zdarzenia w podziale na minutowe przedziały obrazujące liczbę minut
powyżej czasu ustawowego:
5.1 (+1 minuta) – liczba wyjazdów mieszczących się w czasie 0-1 minuta ponad
maksymalny czas ustawowy
5.2 (+2 minuty) – liczba wyjazdów mieszczących się w czasie 1-2 minut ponad
5.5 (+5 minut) – liczba wyjazdów mieszczących się w czasie 4-5 minut ponad
5.10 (+10 minut) – liczba wyjazdów mieszczących się w czasie 9-powyżej 10 minut
ponad maksymalny czas ustawowy
6. Wskaźnik w formacie procentowym obrazujący stosunek ogólnej liczby wyjazdów
przekraczających czas ustawowy (pkt 4) do ogólnej liczby interwencji zakończonych
dotarciem na miejsce zdarzenia (pkt 2)
7. Wskaźnik w formacie procentowym obrazujący stosunek łącznego czasu
przekroczeń mierzonego w formacie [gg:mm:ss] do łącznego czasu wszystkich
interwencji zakończonych dojazdem do miejsca zdarzenia mierzonego w formacie
[gg:mm:ss].
8. Średni czas przekroczeń maksymalnego czasu ustawowego w formacie [gg:mm:ss]
9. Średni czas interwencji ZRM (od przyjęcia zgłoszenia do dotarcia zespołu na
miejsce zdarzenia)
Raport powinien mieć możliwość wyboru wszystkich powyższych danych w układzie
dla:
– wszystkich i każdego z osobna rejonu operacyjnego
– wszystkich i każdej z osobna dyspozytorni
– wszystkich i każdego z osobna powiatu
– wszystkich i każdej z osobna gminy
str. 35 z 82
XI 2015 r. – VI 2016 r.
– wszystkich i każdej z osobna miejscowości
– wszystkich i każdego z osobna dysponenta ZRM
– wszystkich i każdego z osobna Zespołu Ratownictwa Medycznego.
Raport powinien przedstawiać powyższe dane dla zadanego okresu czasowego [Data
od, Data do] i być generowany w postaci rankingu sortowanego wg zadanego
kryterium [przykładowo: rankingu gmin wg wskaźnika opisanego w punkcie 6 –
malejąco] jak również mieć możliwość „kaskadowego” przedstawienia powyższych
danych (podobnie do Excelowych tabel przestawnych).
Przykład 1
Wygeneruj wszystkie gminy powiatu krakowskiego wraz ze wszystkimi ZRM, które
dotarły na teren każdej gminy przedstawiając i dla powiatu i dla gminy i dla
poszczególnych ZRM dane opisane w pkt 1-9
w układzie :
1. Powiat
1.1 Gmina
1.1.1 ZRM
Przykład 2:
Wygeneruj raport obrazujący, do jakich gmin jeżdżą ZRM, których dysponentem jest
Krakowskie Pogotowie Ratunkowe i dla każdego ZRM przedstaw dane z punktów 1-9
w odniesieniu do każdej obsługiwanej gminy w układzie:
1. Dysponent
1.1 ZRM
1.1.1 Gmina
4. Kryteria
akceptacji
zadania:
Stworzenie raportów jak wyżej, moduł raportowy.
1. Identyfikator
zlecenia:
Celem raportu jest określenie natężenia wyjazdów ZRM, posiadających określony czas
2. Opis
przedmiotu dojazdu na miejsce zdarzenia, w poszczególnych godzinach doby dla poszczególnych
ZRM.
zadania:
Wymagane pola:
1. Nazwa ZRM
2. Liczba interwencji ogółem (liczona od przyjęcia wezwania do przybycia na miejsce
3. Wyniki
zdarzenia)
realizacji
3. Liczba interwencji ogółem w podziale na przedziały godzinowe
zadania:
Raport generowany dla poszczególnych ZRM, filtry: dysponent, typ ZRM, Data od,
Data do.
4. Kryteria
akceptacji
zadania:
1. Identyfikator
zlecenia:
Celem raportu jest określenie natężenia przekroczeń maksymalnego czasu
2. Opis
przedmiotu ustawowego wyjazdów ZRM, posiadających określony czas dojazdu na miejsce
zdarzenia, w poszczególnych godzinach doby dla poszczególnych ZRM.
zadania:
Wymagane pola:
3. Wyniki
str. 36 z 82
XI 2015 r. – VI 2016 r.
realizacji
zadania:
4. Kryteria
akceptacji
zadania:
1. Nazwa ZRM
2. Liczba przekroczeń maksymalnego czasu ustawowego ogółem
3. Liczba przekroczeń maksymalnego czasu ustawowego w podziale na przedziały
godzinowe
Raport generowany dla poszczególnych ZRM, filtry: dysponent, typ ZRM, Data od,
Data do, dla miast powyżej 10 tys. mieszkańców do 15 minut, poza miastami powyżej
10 tys. mieszkańców do 20 minut.
1. Identyfikator
zlecenia:
Celem raportu jest określenie natężenia przekroczeń maksymalnego czasu
2. Opis
przedmiotu ustawowego wyjazdów ZRM, posiadających określony czas dojazdu na miejsce
zdarzenia w poszczególnych godzinach doby w poszczególnych powiatach/gminach.
zadania:
Wymagane pola:
1. Powiat/Gmina
2. Liczba przekroczeń maksymalnego czasu ustawowego ogółem na terenie
powiatu/gminy
3. Wyniki
3. Liczba przekroczeń maksymalnego czasu ustawowego w podziale na przedziały
realizacji
godzinowe
zadania:
Raport generowany dla poszczególnych gmin/powiatów. Filtr: Data od, Data do, dla
miast powyżej 10 tys. mieszkańców do 15 minut, poza miastami powyżej 10 tys.
mieszkańców do 20 minut.
4. Kryteria
akceptacji
zadania:
1. Identyfikator
zlecenia:
Celem raportu jest określenie natężenia wyjazdów ZRM, posiadających określony czas
2. Opis
przedmiotu dojazdu na miejsce zdarzenia w poszczególnych godzinach doby w poszczególnych
powiatach/gminach.
zadania:
Wymagane pola:
1. Powiat/Gmina
2. Liczba interwencji ogółem (liczona od przyjęcia wezwania do przybycia na miejsce
3. Wyniki
zdarzenia) na terenie danego powiatu/gminy
realizacji
3. Liczba interwencji ogółem w podziale na przedziały godzinowe
zadania:
Raport generowany dla poszczególnych powiatów/gmin, filtry: Data od, Data do, dla
miast powyżej 10 tys. mieszkańców do 15 minut, poza miastami powyżej 10 tys.
mieszkańców do 20 minut.
4. Kryteria
akceptacji
zadania:
str. 37 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
Utworzenie SZYNY do komunikacji umożliwiającej generowanie informacji, które
zostaną wysłane poprzez np. SMS, pager, e-mail.
2. Opis
przedmiotu
zadania:
Zaimplementowanie mechanizmów powiadamiania (sygnalizacji wezwania) zespołu
ZRM poprzez SMS lub inny rodzaj komunikacji dwustronnej wykorzystującej transmisję
danych. Rozszerzenie zakresu funkcjonalności komunikacji Dyspozytorni z ZRM
poprzez zastosowanie w pojazdach ZRM systemów integrujących kanały
komunikacyjne i zapewniających niezawodność łączności oraz zapewniających rozwój
i możliwość korzystania z usług dostępnych wraz z rozwojem technologii.
Sposób realizacji rozszerzenia kanałów komunikacji z ZRM:
1. Wystawienie danych z SWD PRM do SZYNY danych do komunikacji
z zewnętrznymi systemami dysponenta ZRM (SMS, pager, e-mail, itp.), które
umożliwi konfiguracje danych w systemie tj. tworzenie, przypisywanie grup
powiadamianych użytkowników przypisywanych do wysyłanych ZRM i osób
funkcyjnych na poziome administratora dysponenta.
2. Minimalny zakres danych:
Usługa musi posiadać możliwość konfigurowania procedur alarmowych, według
których są wysyłane powiadomienia:
• wybór typu procedury: informacyjna, która nie wymaga od adresata żadnej
odpowiedzi, alarmowa, która wymaga od adresata udzielenia odpowiedzi
(potwierdzenia lub rezygnacji), służy zebraniu określonej grupy uczestników
zdarzenia.
• wybór rodzaju powiadomień (sms, email lub VoIP),
• planowanie odstępu między wiadomością e-mail, wysłaniem wiadomości SMS,
wykonaniem połączenia VoIP,
• konfigurowanie ilości powtórzeń wysyłki email, SMS i wykonywania połączenia
VoIP,
• konfigurowanie ilości powtórzeń całej procedury,
• ustalanie zapotrzebowania na zasoby oraz celu wysyłki.
Opcjonalnie ustalanie ram czasowych zdarzenie i rezerwacji zasobów w zadanym
okresie. Każda procedura musi posiadać również przyznane przez system unikalny
identyfikator. Raz przygotowana procedura służy następnie jako szablon przy
wysyłaniu kolejnych powiadomień.
Powiadamianie:
• system posiada opcje potwierdzenia lub odrzucenia uczestnictwa w zdarzeniu
przez użytkownika końcowego. Potwierdzenie wymagane jest zarówno
w wiadomości e-mail, SMS jak i VoIP.
• system umożliwia wysyłanie powiadomień różnego typu w zależności od potrzeb:
SMS lub e-mail lub VoIP,
• wysyłający alert daje możliwość wstrzymania lub wznowienia alertu z poziomu
pulpitu.
• wysyłający alert ma możliwość odwołania wcześniej wysłanego alertu z poziomu
pulpitu.
• z poziomu detalu alertu istnieje możliwość wysłania prostej wysyłki informacyjnej
(e-mail + SMS) do uczestników trwającego alertu.
Raportowanie i archiwizacja
• usługa umożliwia odbiór i analizę odpowiedzi (SMS lub email lub VoIP)
udzielonych na wysłane powiadomienia
• usługa pozwala na monitoring wykonywania kilku trwających procedur
• usługa zapewnia pobieranie raportów z przebiegu procedury i wysyłki
powiadomień, raporty dostępne w otwartym formacie CSV
• usługa musi pozwalać na przeszukiwanie archiwalnych alertów, po dacie wysyłki
lub identyfikatorze
• usługa musi posiadać możliwość szczegółowych raportów (uczestnictwo, brak
str. 38 z 82
XI 2015 r. – VI 2016 r.
uczestnictwa, odebranie wiadomości e-mail, SMS, dotyczących konkretnego
uczestnika,
posiada
możliwość
generowania
raportów
zbiorczych
dla
• usługa
przeprowadzonych w danym okresie alertów.
Baza kontaktów i Grupy:
• usługa posiada możliwość grupowania użytkowników (kontaktów); jeden kontakt
może zostać przypisany do wielu grup.
• usługa musi posiada funkcję importowania z pliku (w formacie CSV, o rożnej
konstrukcji) własnej bazy użytkowników (kontaktów). Przy importowaniu jest opcja
wyboru grupy, do której przypisani zostają wszyscy użytkownicy w pliku.
Instancje i uprawnienia:
• usługa zapewnia rozdzielenie uprawnień na Administratora, który zajmuje się
zarządzaniem bazą kontaktów oraz konfigurowaniem procedur oraz Dysponenta,
który zajmuje się wyłącznie wysyłką alertów oraz ich monitorowaniem.
• usługa umożliwia uruchomienie kilku instancji systemu w taki sposób, że jedna
z instancji nie ma wglądu w procedury, grupy, użytkowników, archiwum.
• jeden administrator może zarządzać wieloma instancjami
• jeden dysponent przypisany jest do jednej instancji
• jeden kontakt (adres e-mail lub numer telefonu) może otrzymywać powiadomienia
z dowolnej liczby instancji.
Dostępność usługi:
• usługa jest możliwa z telefonu z dostępem do Internetu, z zainstalowanym
popularnym, mobilnym systemem operacyjnym. Usługa posiada wygodny panel
zarządzania dostosowany do mniejszej rozdzielczości telefonu.
• usługa jest dostępna z tabletu z dostępem do Internetu, z zainstalowanym
popularnym, mobilnym systemem operacyjnym. Usługa musi posiadać wygodny
panel zarządzania dostosowany do mniejszej rozdzielczości tabletu.
• usługa jest możliwa z komputera z dostępem do Internetu, z zainstalowanym na
nim popularnym systemem operacyjnym.
• usługa nie może wymagać instalacji specjalnego oprogramowania, poza
przeglądarką internetową – przeglądarka internetowa powinna widnieć
w pierwszej 10 rankingu najczęściej używanych przeglądarek, tworzonego na
podstawie badań Gemius Traffic
• wykonawca zapewnia dostępność usługi (SLA)
Zabezpieczenia:
System zapewnia wysoką politykę bezpieczeństwa, z uwagi na przechowywane dane
osobowe:
• system jest zabezpieczony protokołem SSL
3. Wyniki
realizacji
zadania:
3. Wizualizacja w systemie SWD PRM w module dyspozytora: wysłania
komunikatu SMS, pager. mail. oraz potwierdzenie jego dostarczenia.
Zaimplementowanie mechanizmów powiadamiania wybranych osób, grupa osób
wybierana z listy lub przyporządkowana automatycznie w zależności od kategorii
zdarzenia. System powiadamiania wykorzystuje wszystkie dostępne kanały
komunikacji (SMS, e-mail, połączenia głosowe telefoniczne i radiowe). Istnieje
możliwość uruchomienia powiadamiania w sposób ręczy lub automatyczny (na
podstawie zdefiniowanych kryteriów/scenariuszy), system umożliwia zdefiniowanie
interakcji powiadamianego użytkownika (definiowanie sposobu potwierdzania
otrzymania komunikatu, zgody/odmowy przyjęcia zadania).
4. Kryteria
akceptacji
zadania:
str. 39 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
Tworzenie, w trakcie pracy systemu SWD PRM, bazy danych zgłoszeń, którą można
wykorzystać do przyspieszenia procesu przyjęcia zgłoszeń w systemie.
2. Opis
przedmiotu
zadania:
1. System przyjmuje zlecenia z różnych źródeł w tym, z takich, z których jest duże
prawdopodobieństwo, iż zgłoszenie będzie posiadało tego samego abonenta co
umożliwia wypełnienie ich w karcie.
W przypadku, gdy w systemie dla danego numeru telefonu istnieją co najmniej
2 zgłoszenia i 2 ostatnie posiadają pokrywające się dane abonenta, można założyć,
że nowe zgłoszenie dotyczy tego samego abonenta i zgodnie z tym uzupełnić kartę.
Przyjęte rozwiązanie przyspiesza prace dyspozytorów poprzez automatyczne
uzupełnienie formatki dla zgłoszeń z numerów, w których abonenci się różnią (numery
alarmowe innych służb, szkoły, etc)
3. Wyniki
realizacji
zadania:
4. Kryteria
akceptacji
zadania:
Wdrożenie opisanego mechanizmu do systemu.
str. 40 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
Możliwość otwarcia drugiego ekranu do przeglądu zgłoszeń i zdarzeń na potrzeby
2. Opis
przedmiotu rozdzielenia procesu dysponowania i procesu przeglądania zleceń archiwalnych.
Podział obecnego okna SWD PRM i UMM z 2 monitorów na 3 monitory.
zadania:
1. Rozdzielenie procesu dysponowania od procesu przeglądania zleceń
archiwalnych.
3. Wyniki
2. Podział obecnego okna SWD PRM i UMM z 2 monitorów na 3 monitory.
realizacji
3. Zakup dodatkowego sprzętu komputerowego o parametrach odpowiadających
zadania:
wymaganiom aplikacji SWD PRM i UMM. (monitory, karty graficzne)
4. Montaż oraz konfiguracja systemu dla stanowiska 3 monitorowego.
1. Aplikacja SWD PRM umożliwia podział na odpowiednie sekcje formatek na osobne
okna mobilne pod względem funkcjonalności. (formatka przyjęcia wezwania,
formatka zgłoszeń, formatka zasobów).
2. Wszystkie okna aplikacji powinny być mobilne dla uniwersalnego dostosowania
dla: użytkownika lub dyspozytorni.
3. Możliwość przeglądania zleceń archiwalnych w osobnym oknie.
4. Okno z archiwalnymi wezwaniami powinno dawać możliwość określenia przez
użytkownika parametrów czasowych.
5. Okno archiwalne dostępne zgodnie z nadanymi przez administratora
uprawnieniami.
6. Możliwość wyszukiwania zgłoszeń archiwalnych na podstawie następujących
parametrów:
– czasu
– nr zgłoszenia
4. Kryteria
– adresu, ulicy zgłoszenia
akceptacji
– imię lub nazwisko chorego
zadania:
7. Możliwość zdefiniowania na poziomie aplikacji rozmieszczenie okienek dla
konkretnej dyspozytorni.
a. Należy
wprowadzić
właściwe
zapisy
w dokumentacji
użytkownika
wcześniejszego
wykonania
testów
wewnętrznych
na
środowisku
UWAGA: Do rozważenia funkcjonalność umożliwiająca zapisanie układu okien dla
użytkownika oraz przywrócenie ustawień domyślnych.
str. 41 z 82
XI 2015 r. – VI 2016 r.
Specyfikacja zmiany nr: 17 (2
1. Identyfikator
zlecenia:
2. Opis
przedmiotu
zadania:
Rozszerzenie funkcjonalności w module Dyspozytora w zakresie możliwości
nawiązania
połączenia
telefonicznego
z poziomu
aplikacji
ze wszystkimi
prowadzonymi rozmowami związanymi z obsługą danego zdarzenia przez dyspozytora
medycznego.
Funkcjonalność po otwarciu formatki zdarzenia i wykonaniu połączenia telefonicznego
umożliwia przyporządkowanie określonej rozmowy do danego zdarzenia oraz po
uruchomieniu funkcji połącz ponownie po otwarciu okna modalnego wybór połączenia,
które ma zostać ponownie wykonane.
Funkcjonalność dotyczy sytuacji, w której dyspozytor medyczny:
- ustala dodatkowe dane związane z miejscem zdarzenia i kilkukrotnie wykonuje
połączenia do osoby lub osób zgłaszających pod inne numery niż wprowadzone
pierwotnie przez operatora numerów alarmowych lub dyspozytora medycznego,
- prowadzi kilka rozmów związanych np. z problemem z przyjęciem pacjenta, rozmów
z lekarzem koordynatorem ratownictwa medycznego, itp.
Umieszczenie wszystkich rozmów pod danym zdarzeniem umożliwia szybkie
oddzwonienie do danej osoby/podmiotu bez konieczności wielokrotnego wyszukiwania
i wprowadzania numeru.
W kwestiach wymagających weryfikacji umożliwiony jest szybki dostęp do całej
korespondencji związanej ze zdarzeniem.
UWAGA: Konieczne zmiany po stronie PZŁ.
3. Wyniki
realizacji
zadania:
4. Kryteria
akceptacji
zadania:
str. 42 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
Moduł Apteczny
zlecenia:
Funkcjonalność modułu apteki z poziomu tabletu ZRM:
1. Prowadzenie rozliczeń apteki zespołu wyjazdowego, w zakresie zarządzania
stanem apteki.
2. Prowadzenie rozliczeń apteki zespołu wyjazdowego, w zakresie informowania
o stanie ważności leków.
3. Prowadzenie rozliczeń apteki zespołu wyjazdowego, w zakresie rozliczenia apteki
po zakończeniu dyżuru.
4. Prowadzenie rozliczeń apteki zespołu wyjazdowego, w zakresie integracji
systemem apteki dysponenta zespołów ratownictwa medycznego.
5. Elektroniczna apteka: Prowadzenie ewidencji stanu leków w poszczególnych
ambulansach.
6. Elektroniczna apteka: Tworzenie zamówień na leki oraz przekazywanie
zamówionych leków do apteki.
2. Opis
apteka: Przechowywanie
informacji o stanie leków na
przedmiotu 7. Elektroniczna
poszczególnych ośrodkach kosztów.
zadania:
8. Elektroniczna apteka: Rozdzielanie leków z apteki do ośrodków kosztu.
9. Elektroniczna apteka: Automatyczna aktualizacja stanu magazynowego leków na
ośrodku kosztu po tym, jak lek zostanie zużyty w trakcie wizyty realizowanej przez
ten ośrodek kosztu.
10. Elektroniczna apteka: Dodatkowy dostęp do zestawień, które pozwolą prześledzić
drogę przekazywania leków, miejsce zużycia (ze szczególnym uwzględnieniem
narkotyków), osobę podającą lek oraz możliwość podsumowania ilościowego stanu
leków.
11. Elektroniczna apteka: Sygnalizowanie przekroczenia terminów ważności
poszczególnych leków oraz braków w wyposażeniu.
12. Elektroniczna apteka: Aplikacja dostosowana do wymiany danych z modułem
aplikacji mobilnej
Moduł systemu: Aplikacja mobilna ZRM
Opis wymagania:
Opis w całości funkcjonalności modułu aptecznego z poziomu mobilnego tabletu
zespołu ratownictwa medycznego. Funkcjonalność jest opisana, jako jedna główna,
składająca się z kilku mniejszych.
Zespół Ratownictwa Medycznego wypełniając dokumentację medyczną na urządzeniu
mobilnym, uzupełnia wpis o zużyciu sprzętu tj. opatrunki, leki, inny sprzęt medyczny
znajdujący się na wyposażeniu ambulansu.
System automatycznie ściąga ze stanu leki, środki medyczne i sprzęt, po
3. Wyniki
wprowadzeniu z listy (wybrany z listy) w KMCR. Leki, środki medyczne, i sprzęt
realizacji
wpisywany bezpośrednio do KMCR daje możliwość stworzenia odpowiednich
zadania:
zestawień w rozliczeniu na konkretnego pacjenta, zespół: np. jakim pacjentom podano
lek „morfina” w badanym okresie.
Każdy dysponent ratownictwa medycznego ma jedną główną aptekę, jako magazyn.
Każda nowa faktura zakupowa leków, sprzętu jest wprowadzona do systemu, co
zwiększa stan danego sprzętu medycznego. Natomiast ośrodkami kosztów nie są
ambulanse a zespoły ratownictwa medycznego.
W określonym przedziale czasowym powinna nastąpić inwentaryzacja sprzętu
w module aptecznym. Występuje podział na sprzęt policzalny i niepoliczalny.
Magazyn apteki:
• możliwość przeglądania bieżącego stanu magazynowego wg kategorii (leki,
narkotyki, leki psychotropowe i sedujące, środki dezynfekcyjne, sprzęt medyczny,
4. Kryteria
opatrunki)
akceptacji
• bieżąca aktualizacja bazy leków i sprzętu medycznego po każdym użyciu leku lub
zadania:
sprzętu
• możliwość wyświetlania szczegółów informacji o leku
• możliwość wprowadzenia zakupionego sprzętu poprzez wybranie danej pozycji ze
str. 43 z 82
XI 2015 r. – VI 2016 r.
słownika dostarczonego przez administratora centralnego) i uzupełnienie
odpowiednich pól:
a) dawka leku
b) numer serii
c) data ważności
d) ilość dostarczanego sprzętu (ampułki, sztuki, opakowania itd.)
e) podział magazynu na poszczególne ośrodki kosztów (dany zespół ratownictwa
medycznego)
f) możliwość kontroli zużycia wybranego sprzętu oraz leku za wybrany czas i dla
konkretnego ośrodka kosztów
g) możliwość automatycznej inwentaryzacji w chwili naliczania obrotu za wybrany
czas
h) filtrowanie wyświetlanych informacji po wybranym ośrodku kosztów
i) filtrowanie względem wybranej kategorii leku (leki, środki dezynfekcyjne, sprzęt
medyczny, opatrunki)
j) możliwość tworzenia własnych słowników i grup leków
k) możliwość definiowania własnych dokumentów (np. rozchodu darów, przyjęcie
bezpłatnych próbek itd.)
l) możliwość sporządzenia zamówienia doraźnego środków farmaceutycznych
i materiałów opatrunkowych. Zamówienia mogą być przygotowane
automatycznie, na podstawie aktualnych stanów magazynowych, stanów
minimalnych i maksymalnych
m) odnotowanie wstrzymania lub wycofania leku z obrotu
n) możliwość automatycznego zdejmowania ze stanów magazynowych leków
przeterminowanych
o) możliwość przekazywania środków medycznych z jednego ośrodka kosztów do
drugiego.
Dysponent w oparciu o katalog leków i produktów leczniczych ma możliwość
utworzenia własnego lokalnego katalogu.
UWAGA: Problem, jaki się pojawia to wpisywanie leków z numerem serii i datą
ważności do modułu aptecznego. Bardzo często leki są wymieszane z sobą,
pacjentowi podaje się kilka ampułek czy fiolek z różną serią i data ważności. Trudno
sobie wyobrazić, aby zespół podczas reanimacji oglądał czy spisywał, jaką serię leku
podał i do kiedy była data ważności.
Numer serii oraz datę ważności członek ZRM nie będzie wpisywał w moduł apteczny.
Pozycje w module będą tak ustawione, że pierwsza pozycja to będzie najkrótsza data
ważności.
Numer serii oraz data ważności jest kontrolowana do momentu przełożenia
asortymentu do ambulansu.
Naliczanie obrotu za okres obrachunkowy:
• możliwość przeliczenia zużytych leków w okresie obrachunkowym i na jego
podstawie generowanie listy zamówień
• zamówienie generowane w chwili osiągnięcia wcześniej określonego minimalnego
stanu na danym ośrodku
Zamówienia:
• prezentacja listy dokumentów zakupu na dzień bieżący
• możliwość generowania zamówień wg określonego przez administratora kategorii
dla poszczególnych ośrodków kosztów
• możliwość tworzenia zamówienia przez członków konkretnego Zespołu
Ratownictwa Medycznego z poziomu miejsca stacjonowania, jego późniejszego
zatwierdzenia przez uprawnioną osobę i realizacji.
• zakres prezentowanych informacji dotyczących zamówienia:
a) nazwa ośrodka (numer), dla którego jest zamówienie
b) data i czas zamówienia
c) ilość pozycji na liście
d) dane zamówienia (numer zamówienia, nazwa, symbol leku, ilość
str. 44 z 82
XI 2015 r. – VI 2016 r.
zamówienia, ilość otrzymana, cena jednostkowa, wartość)
• modyfikacja wygenerowanego zamówienia
• możliwość usuwania zamówień wygenerowanych wcześniej i niezatwierdzonych
• możliwość definiowania listy leków dostarczanych przez wybranego dostawcę
w celu automatycznego generowania odrębnych zamówień dla poszczególnych
dostawców
• generowanie zamówień na podstawie zużycia przez określony ośrodek kosztów
• możliwość drukowania zamówień na papierze formatu A4
• możliwość filtrowania listy zamówień względem:
a) ośrodka kosztów
b) kategorii sprzętu
c) wzorca nazwy
Zakupy:
• lista zakupów zawierająca następujące informacje:
a) data i czas zakupu
b) dostawca
c) sygnatura zakupu
d) wartość zakupu
• możliwość sortowania po wybranej kolumnie
• archiwalna lista zakupów zawierająca następujące informacje:
a) data i czas zakupu
b) dostawca
• sygnatura zakupu
• możliwość filtrowania archiwalnej listy zakupów dla określonego przedziału czasu
Bilans zużycia leków:
• prezentacja listy wybranych leków za wybrany czas
• zakres prezentowanych informacji:
a) ilość pozycji na liście
b) miesiąc
c) rok
d) dane o leku, sprzęcie (nazwa, zakupiona ilość, zużyta ilość, różnica pomiędzy
ilością zakupioną a zużytą, inwentaryzacja, bilans)
• możliwość filtrowania listy dla:
a) wybranego przedziału czasowego
b) określonej kategorii leków
c) wybranego wzorca nazwy
Narkotyki:
• prezentacja listy narkotyków zużytych w wybranym czasie
• prezentacja szczegółowych informacji o narkotyku:
a) czas, dla którego prezentowana jest lista
b) numer zlecenia
c) data zlecenia
d) ilość podana
e) rozpoznanie
f) nazwisko osoby podającej
g) nazwisko i imię pacjenta
• możliwość filtrowania listy dla:
a) wybranego przedziału czasowego
b) wybranego wzorca nazwy
Słownik leków oraz sprzętu medycznego:
• możliwość wprowadzenia do słownika leków i sprzętu wg kategorii
• zakres danych wprowadzanych do słownika:
a) nazwa leku, sprzętu itp.
b) dawka
c) postać (ampułki, tabletki, fiolki itp.)
d) jednostka miary
str. 45 z 82
XI 2015 r. – VI 2016 r.
Integracja z innymi modułami realizującymi funkcjonalność w zakresie (poprzez
interfejs?/czy poprzez możliwość wygenerowania danych tekstowych?):
• dostępność funkcji wartościowego, syntetycznego zapisu obrotu materiałowego na
kontach księgi głównej FK
• możliwość zapisu dokumentów rozchodowych (koszty) na poziomie wydania
z magazynu apteki
• możliwość zapisu dokumentów rozchodowych (koszty) na poziomie wydania
z magazynu apteczki ośrodka kosztów
• możliwość elastycznego tworzenia wzorców eksportu do FK
• możliwość wykorzystania słowników FK: kontrahentów, rodzaju kosztów, ośrodków
powstania kosztów
Rachunek kosztów leczenia:
• w zakresie udostępnienia indeksu leków i danych o aktualnych cenach leków do
określenia normatywnych materiałowych świadczeń (w zakresie leków)
Czynności analityczno-sprawozdawcze:
Generowanie raportów i zestawień:
• na podstawie rozchodów
• na podstawie przychodów
• na podstawie obrotów
• przegląd stanów magazynowych na wybrany dzień
• kontrola leków o zbliżających się terminie ważności
• druki standardowe z ewidencji narkotyków i leków psychotropowych
• wydruk raportów i zestawień do XLS
RYSUNEK DO SPECYFIAKCJI NR 18
str. 46 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
2. Opis
Umieszczenie w SWD PRM modułu mobilnego dodatkowej dokumentacji medycznej –
przedmiotu
karty chorób zakaźnych, „niebieskiej karty", karty przymusu bezpośredniego etc.
zadania:
SWD PRM zawiera dokumentację, inną niż KZW i KMCR określoną obowiązującymi
przepisami prawa, w szczególności kartę chorób zakaźnych, „niebieską kartę", kartę
przymusu bezpośredniego oraz kartę zgonu. W razie konieczności kierownik ZRM ma
3. Wyniki
możliwość wybrania z pliku dokumentów konkretnej dokumentacji (jednej lub kilka)
realizacji
z możliwością ręcznego uzupełniania. Po wypełnieniu przez kierownika ZRM KMCR
zadania:
tożsame pola z innej, wybranej przez kierownika ZRM, dokumentacji przypisanej do tej
KMCR są automatycznie wypełnione przez system (np. Imię i Nazwisko, wiek, płeć,
PESEL, itp.).
1. SWD PRM zawiera dodatkową dokumentację tj. kartę chorób zakaźnych,
„niebieską kartę", kartę przymusu bezpośredniego oraz kartę zgonu.
2. Powyższa dokumentacja zgodna jest z obowiązującymi przepisami prawa.
3. Dostęp członków ZRM do dokumentacji, o której mowa w pkt 1, jest tożsamy
z KZW i KMCR.
4. Po wybraniu przez Kierownika ZRM innej, niż KMCR dokumentacji, automatycznie
uzupełnione są tam pola tożsame z KMCR (np. Imię i Nazwisko, płeć, wiek, itd.).
5. Dokumentacja inna niż KMCR przypisana jest do konkretnej KZW i KMCR.
4. Kryteria
a. Należy
wprowadzić
właściwe
zapisy
w dokumentacji
użytkownika
akceptacji
zadania:
wcześniejszego
wykonania
testów
wewnętrznych
na
środowisku
str. 47 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
2. Opis
przedmiotu
zadania:
3. Wyniki
realizacji
zadania:
4. Kryteria
akceptacji
zadania:
Informacja zarządcza dla kierownictwa jednostki ZRM (wyświetlana np. u dyrektora
jednostki ZRM na monitorze) dotycząca:
1. obecnego
stanu
i ilości
zgłoszeń
(oczekujących,
zadysponowanych,
zakończonych...),
2. ilości zarejestrowanych zleceń i ich kompletności w systemie (w celu dalszego
przekazania do NFZ),
3. wyliczanie oraz prezentacja mediany czasu dojazdu dla zespołów realizujących
świadczenia w mieście i poza miastem,
4. prezentacji informacji dotyczącej długości kolejki i czasu oczekiwania na
podniesienie słuchawki przez dyspozytora.
1. Strona internetowa dla kierownictwa jednostki lub osobna aplikacja.
2. Zalogowanie się do systemu po podaniu loginu i hasła.
3. Statystyki na głównej stronie z możliwością określenie zakresu czasowego
(aktualny dyżur, poprzedni dyżur, ostatnie 24h, ostatnie 7 dni, aktualny miesiąc,
poprzedni miesiąc).
4. Dostępne raporty:
• Średni czas obsługi zdarzeń dla dyspozytorni bez podziału na konkretnego
dyspozytora
• Średni czas dojazdu do pacjenta od momentu zadysponowania zespołu do
czasu dojazdu
• Średni czas dojazdu do pacjenta od momentu przyjęcia wezwania zespołu do
czasu dojazdu
• Średni czas realizacji zdarzenia
• Ilość odebranych połączeń. Ilość przyjętych zgłoszeń do realizacji. Ilość odmów
• Mediana czasu dojazdu
5. W przypadku korzystania z usług podwykonawców dostęp do w/w danych również
podwykonawców przez dyrektora, którego zakład posiada umowę z NFZ
6. Zdefiniowanie w systemie moduły do prezentacji w zależności od preferencji
kierownictwa jednostki
1. W module konfiguracji możliwość zaznaczenia opcji dostępu do omawianego
modułu.
2. Wyniki prezentowane dla każdego dysponenta. W przypadku, gdy dysponent
posiada umowę z NFZ i posiada dysponentów podwykonawców powinien mieć
możliwość podglądu dla swoich jednostek jak i dla podwykonawców.
a. Należy
wprowadzić
właściwe
zapisy
w dokumentacji
użytkownika
wcześniejszego
wykonania
testów
wewnętrznych
na
środowisku
str. 48 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
2. Opis
przedmiotu
zadania:
3. Wyniki
realizacji
zadania:
4. Kryteria
akceptacji
zadania:
Integracja SWD PRM z aparaturą medyczną wykorzystywaną w ZRM z możliwością
przesyłania bieżących parametrów fizjologicznych pacjenta do wybranego miejsca Np.
możliwość korzystania z teletransmisji EKG lub przesyłania innych jednostkowych
danych medycznych.
UWAGI:
(jednostkowych danych
• określić katalog parametrów fizjologicznych
medycznych), jakie mogłyby być przesyłane,
• przygotować tzw. „cienkiego klienta” dla podmiotów leczniczych,
• utworzyć serwer HL7 przy serwerze SWD PRM
1. Możliwość przekazania jednostkowych danych medycznych w tym m. in. zapisu
EKG za pośrednictwem aplikacji zainstalowanej na tablecie stanowiącym
wyposażenie ambulansu do wybranej lokalizacji w tym do podmiotu leczniczego.
2. Przekazanie jednostkowych danych medycznych za pośrednictwem wybranego
łącza/systemu łączności do centralnego serwera, z którego jednostkowe dane
medyczne zostaną przekazane do wybranej lokalizacji w tym do podmiotu
leczniczego.
3. Zainstalowana w wybranej lokalizacji w tym m.in. w podmiocie leczniczym aplikacja
umożliwia odbieranie i jednoczesne drukowanie badania lub przekazanie danych
do wykorzystywanego przez dany podmiot leczniczy systemu szpitalnego –
interfejs.
4. Przyjście jednostkowych danych medycznych do wybranej lokalizacji
sygnalizowane jest dźwiękiem z głośników oraz wizualnie na monitorze.
5. Dyżurujący w wybranej lokalizacji, w tym w podmiocie leczniczym personel
medyczny ocenia jednostkowe dane medyczne.
1. ZRM ma możliwość wykonania pomiaru parametrów funkcji życiowych i wykonania
badania EKG za pomocą defibrylatora i wybrania lokalizacji , do której chce
przesłać jednostkowe dane medyczne, w aplikacji SWD PRM ZRM.
2. Przekazanie informacji zawierającej zapis jednostkowych danych medycznych w
tym badania EKG za pośrednictwem łącza/ systemu łączności do centralnego
serwera, z którego za pomocą łącza internetowego wynik badania zostaje
przekazany do wybranej lokalizacji w tym podmiotu leczniczego, w aplikacji SWD
PRM ZRM.
3. Zapewnienie przesłania danych do wybranej lokalizacji za pomocą zainstalowanej
aplikacji, która umożliwia odebranie jednostkowych danych medycznych w tym
EKG i jednoczesne drukowanie.
4. Otrzymanie nowych jednostkowych danych medycznych w tym badania EKG przez
wybrane jednostki w tym podmiot leczniczy sygnalizowane jest dźwiękiem
z głośników oraz wizualnie na monitorze.
5. Dyżurujący w wybranej lokalizacji lub podmiocie leczniczym personel medyczny
ocenia jednostkowe dane medyczne, przekazany słownie stan pacjenta
i podejmuje decyzję o tym, gdzie powinien on trafić.
str. 49 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
2. Opis
przedmiotu
zadania:
3. Wyniki
realizacji
zadania:
Dostęp do bazy wiedzy: procedur postępowania ZRM w wybranych stanach
zagrożenia zdrowotnego, aktualnych wytycznych resuscytacji opublikowanych przez
Polską Radę Resuscytacji, biblioteki regulaminów, instrukcji i przepisów. W ramach
realizacji przedmiotu zamówienia należy dostarczyć przestrzeń dyskową dla potrzeb
bazy wiedzy (biblioteki) w wielkości co najmniej 1TB.
1. W module aplikacji dla potrzeb: dyspozytorów, ZRM-ów znajduje się formatka
pozwalająca na dostęp do bazy wiedzy podzielonej na trzy grupy:
1.1. „CENTRALA” – administrator centralny z kategoriami np.:
– organizacyjne (regulaminy, instrukcje)
– medyczne (przepisy, procedury, wytyczne).
1.2. „WOJEWODA” – administrator wojewody z kategoriami np.:
1.3. „DYSPONENT” – administrator dysponenta z kategoriami np.:
– komunikaty
– ogłoszenia.
1.1. administrator centralny zarządzający bazą wiedzy może tworzyć w swojej
grupie:
– kategorie
– dodawać elementy/pliki w odpowiednim formacie i rozmiarze do
wybranej kategorii
– definiować słowa klucze/kluczowe dla dodawanych elementów.
1.2. administrator wojewody zarządzający bazą wiedzy może tworzyć w swojej
grupie:
– kategorie
wybranej kategorii
1.3. administrator dysponenta zarządzający bazą wiedzy może tworzyć
w swojej grupie:
– kategorie
wybranej kategorii
2. Dostęp do bazy wiedzy użytkownika odbywa się poprzez przeszukiwanie wybranej
kategorii i/lub przez słowo kluczowe.
3. Po wybraniu odpowiedniej kategorii/ słowa kluczowego wyświetlona zostaje lista
elementów z wybranej kategorii/zawierających słowo kluczowe.
4. Wybranie elementu z listy powoduje przesłanie pliku skojarzonego z wybranym
elementem.
5. W module aplikacji powinna istnieć możliwość rozsyłania komunikatów wraz
z załącznikami między użytkownikami systemu:
– administrator dysponenta/lokalny,
– dyspozytorzy dysponenta,
– ZRM-y dysponenta.
5.1. Administrator lokalny/dysponenta powinien mieć możliwość tworzenia listy
komunikatów, ogłoszeń i:
– dodawanie, usuwanie elementów z listy
– dodawanie, usuwanie załączników/plików w odpowiednim formacie i rozmiarze
przeznaczonych dla dyspozytorów, ZRM-ów dysponenta.
str. 50 z 82
XI 2015 r. – VI 2016 r.
6. W aplikacji ukazuje się informacja o nowym/liczbie nowych komunikatów.
7. Dostęp do komunikatów odbywa się poprzez przeszukiwanie listy komunikatów.
8. Wybranie elementu z listy spowoduje przesłanie pliku skojarzonego z wybranym
elementem.
9. funkcja blokowania możliwości wydruku informacji z bazy wiedzy, komunikatów
z tabletu na drukarce w ambulansie (znamy pojemność 11 i 7 ml pojemników
z tuszem w przekazanych drukarkach)
10. Na stanowiskach w miejscu stacjonowania zespołu dostęp do bazy wiedzy,
komunikatów jest nieograniczony.
11. Na stanowiskach w miejscu stacjonowania zespołu powinna być możliwość
wydrukowania pobranych informacji – bez limitu.
12. Baza wiedzy zawiera aktualne procedury postępowania ZRM w wybranych
stanach zagrożenia zdrowotnego oraz aktualnych wytycznych dotyczących
resuscytacji krążeniowo-oddechowej opublikowanych przez Polską Radę
Resuscytacji.
a. Należy
wprowadzić
właściwe
zapisy
w dokumentacji
użytkownika
wcześniejszego
wykonania
testów
wewnętrznych
na
środowisku
4. Kryteria
akceptacji
zadania:
str. 51 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
Zdarzenia mnogie/masowe
Przedmiotem zadania jest opracowanie funkcjonalności wykorzystywanej przez
użytkowników systemu:
• dyspozytorów medycznych,
• lekarzy koordynatorów ratownictwa medycznego,
• kierowników zespołów ratownictwa medycznego.
Funkcjonalność będzie dostępna w następujących modułach:
• dyspozytora,
• mobilnym ZRM,
• miejscu stacjonowania.
Opis funkcjonalności zrealizowany w oparciu o zalecenie Konsultanta Krajowego
w dziedzinie medycyny ratunkowej dotyczące procedur postępowania na wypadek
wystąpienia zdarzenia mnogiego/masowego Pana prof. dr hab. n. med. Jerzego
Roberta Ładnego, zatwierdzone i wprowadzone do stosowania przez Ministra Zdrowia
w dniu 11 czerwca 2015 r. – ZAŁĄCZNIK NR 2
Funkcjonalność stanowi odwzorowanie
sposobu postępowania
opisanego
w procedurze.
2. Opis
przedmiotu
zadania:
Celem realizacji funkcjonalności jest wsparcie osób uczestniczących w zdarzeniu
mnogim/masowym poprzez zapewnienie prawidłowego postępowania w obszarze
zadań dyspozytorów medycznych, zespołów ratownictwa medycznego, lekarzy
koordynatorów ratownictwa medycznego, szpitalnych oddziałów ratunkowych, centrów
urazowych, izb przyjęć, jednostek organizacyjnych szpitali wyspecjalizowanych
w zakresie udzielania świadczeń zdrowotnych niezbędnych dla ratownictwa
medycznego, w przypadku powiadomienia o zdarzeniu dyspozytora medycznego
i zakwalifikowania tego zdarzenia jako zdarzenia o potencjalnym charakterze
mnogim/masowym.
Funkcjonalność uruchamiana w momencie przyjmowania przez dyspozytora
powiadomienia o zdarzeniu, które w formatce przyjęcia zdarzenia oznaczy jako
zdarzenie masowe.
Funkcjonalność umożliwia dyspozytorom medycznym, kierownikom zespołów
ratownictwa medycznego, lekarzom koordynatorom ratownictwa medycznego
realizację dedykowanych im kart działań opisanych w procedurze, o której mowa
powyżej.
Funkcjonalność zapewnia automatyczne wprowadzanie danych w poszczególnych
kartach działań w szczególności w zakresie:
• powiadomienia o zdarzeniu,
• liczbie zadysponowanych ZRM wraz z ich kryptonimami w tym lotniczych ZRM,
• czasie powiadomienia innych służb,
• dane o dostępności lotniczych ZRM wraz z przewidywanym czasem dotarcia do
miejsca zdarzenia,
• zmiany trybu pracy dyspozytorni medycznej, w tym wyznaczenie dyspozytorów
medycznych współpracujących,
• wyznaczenie zadań dla dyspozytorów medycznych współpracujących,
• powiadomienie LKRM,
• wymiana informacji pomiędzy dyspozytorem medycznym, LKRM, kierującym akcją
medyczną,
• tabeli dyslokacji poszkodowanych,
• tabeli szpitali.
Funkcjonalność umożliwia przygotowanie:
• raportu z przebiegu zdarzenia,
• karty ocen,
str. 52 z 82
XI 2015 r. – VI 2016 r.
• karty zestawienia uwag, spostrzeżeń i propozycji dla MZ.
Funkcjonalność dla każdego z użytkowników posiada spójne ze sobą i wzajemnie się
uzupełniające Karty realizacji zadań:
• KARTA działań dyspozytora medycznego kierującego,
• KARTA działań dyspozytora medycznego współpracującego,
• KARTA działań dyspozytora medycznego z ościennej dyspozytorni medycznej,
• KARTA działań dyspozytora krajowego SP ZOZ Lotnicze Pogotowie Ratunkowe,
• KARTA działań kierującego akcją medycznych czynności ratunkowych,
• KARTA działań zespołu ratownictwa medycznego,
• KARTA działań lekarza koordynatora ratownictwa medycznego,
• KARTA działań lekarza koordynatora ratownictwa medycznego z ościennego
województwa,
• KARTA działań szpitalnego oddziału ratunkowego/izby przyjęć,
• KARTA działań jednostki organizacyjnej szpitala wyspecjalizowanej w zakresie
udzielania świadczeń zdrowotnych niezbędnych dla ratownictwa medycznego.
Realizacja funkcjonalności ma zapewnić maksymalne ograniczenie czynności, jakie
należy wykonać celem prowadzenia dokumentacji zdarzenia mnogiego/masowego, jak
również konieczne do wykonania czynności mają być realizowane w sposób prosty
i intuicyjny dla użytkownika końcowego. Funkcjonalność jest elementem wspierającym
użytkownika końcowego i nie może go w nadmierny sposób absorbować.
3. Wyniki
realizacji
zadania:
4. Kryteria
akceptacji
zadania:
str. 53 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
2. Opis
Po przekroczeniu określonego czasu realizacji zlecenia (ZRM na miejscu zdarzenia,
przedmiotu
w szpitalu) odrębna wizualizacja danego ZRM na mapie.
zadania:
1. Komunikat świetlny, migające podświetlenie, sygnał dźwiękowy, oznaczenie ZRM
w liście ZRM widocznych w module Dyspozytora, po przekroczeniu czasu
pozostawania ZRM w określonym statusie tj. w miejscu wezwania, u pacjenta,
w szpitalu.
2. Przesunięcie w Module Dyspozytora, u dyspozytora głównego i jego zastępcy, na
liście wszystkich zespołów dostępnych w danym rejonie operacyjnym na początek
listy wraz z komunikatem, o którym mowa powyżej.
3. Możliwość ustawienia czasu dla poszczególnych statusów przez Administratora
Dysponenta oraz Dyspozytora Głównego
4. Tablet powinien sygnalizować komunikatem dźwiękowym/świetlnym przekroczenie
zadanego czasu.
3. Wyniki
5. Możliwość skasowania alarmu przekroczenia czasu przez Dyspozytora Głównego
realizacji
lub jego zastępcę (w momencie jego wystąpienia)
zadania:
6. W module Analityk powinna być możliwość wygenerowania raportu z określonego
czasu, dla każdego ZRM z osobna bądź dla grupy ZRM biorąc pod uwagę ich
rodzaj, rejon operacyjny.
7. Przekroczenia czasów pozostawania w określonych statusach są na bieżąco
monitorowane i okresowo analizowane w pierwszej kolejności przez dysponenta
posiadającego w swojej strukturze dyspozytornię medyczną, następnie przez
dysponenta, które, „problem” przekroczeń dotyczy. Możliwość występowania
przekroczeń nie „z winy” ZRM, lecz np. z powodu organizacji pracy SOR lub IP
bądź ich obciążenia. Informacja umożliwia weryfikację i analizę statystyczną
zagadnienia „przetrzymywania ZRM” w podmiotach leczniczych.
8. Zastosowanie alarmów powinno skutkować analizą przyczyn ich występowania.
4. Kryteria
akceptacji
zadania:
jw.
str. 54 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
2. Opis
przedmiotu Zmiana niektórych ikon statusów
zadania:
GOTOWY W BAZIE
3. Wyniki
realizacji
zadania:
Bez zmian
Strzałka powinna być w kolorze niebieskim – to dopiero
zadysponowanie, ZRM po wciśnięciu statusu „wyjazd do
ZADYSPONOWANY
zdarzenia” powinien zmienić się kolor na czerwony i zmienia
się ikona.
ikona karetki powinna być skierowana w prawo – ZRM udaje
WYJAZD DO
się na miejsce wezwania, po przyjeździe na miejsce wciskając
„na miejscu” ikona karetki widoczna powinna być przodem do
ZDARZENIA
nas
NA MIEJSCU
Jw. – karetka skierowana przodem do nas.
ZDARZENIA
PRZEWÓZ DO
Bez zmian
SZPITALA
W SZPITALU
Bez zmian
POWRÓT DO BAZY Ikona karetki skierowana w lewo – kolor bez zmian
AWARIA
Bez zmian
Podczas tankowania – teoretycznie ZRM nie jest gotowy do
TANKOWANIE
natychmiastowego zadysponowania, więc sugerowane jest
tankowanie w kolorze niebieskim. Ikona bez zmian
Również podczas dezynfekcji ZRM nie jest gotowy do
DEZYNFEKCJA
natychmiastowego wyjazdu do zdarzenia – sugerowany jest
kolor niebieski ze zmianą ikony na „skażenie biologiczne”
MYCIE –
Zamiast mycie – „Czyszczenie Karetki” – kolor niebieski ze
CZYSZCZENIE
względu na ewentualny charakter czyszczenia ambulansu.
KARETKI
NIEGOTOWY
Bez zmian.
4. Kryteria
akceptacji
zadania:
str. 55 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
2. Opis
przedmiotu Możliwość obsługi wyjazdów ZRM na ćwiczenia.
zadania:
1. W aplikacji SWD PRM ćwiczenia obsługuje wskazany/wyznaczony dyspozytor
– dyspozytor główny,
– zastępca dyspozytora głównego
– lub nowa rola
2. W formatce WYWIAD aplikacji SWD PRM dodany checkbox „ĆWICZENIA”
3. Zgłoszenia tworzone na potrzeby ćwiczeń znajdują się na liście wszystkich
zgłoszeń i:
– zlecenia posiadają numerację poprzedzoną znacznikiem/prefiksem,
– lub posiadają własną numerację
– pasek zlecenia na wspólnej liście jest wyróżniony kolorem,
– tło otworzonego zlecenia wyróżnia się kolorem lub na przekątnej ekranu
pojawia się znak wodny „ĆWICZENIA”
4. W filtrach dodatkowych dodany FILTR „ĆWICZENIA”
5. Do ćwiczeń dyspozytor może przydzielić ZRM-y:
– nieujęte w wojewódzkim Planie Działania Systemu PRM, utworzone na
potrzeby ćwiczeń,
– dodatkowe zespoły ratownictwa medycznego ujęte w wojewódzkim Planie
Działania Systemu PRM,
– zespoły ratownictwa medycznego włączone do systemu Państwowe
Ratownictwo Medyczne.
3. Wyniki
6. ZRM przydziela się do ćwiczeń z listy zespołów w zakładce „SZCZEGÓŁY”
realizacji
– powoduje dodanie znacznika/prefiksu do nazwy zespołu,
zadania:
– i/lub zmiana koloru tła paska na liście zespołów,
– na mapie zmiana kształtu ikony ZRM z zachowaniem kolorów i symboli
statusów
– ZRM przydzielony do ćwiczeń powinien być włączony do algorytmu
podpowiadania ZRM oraz listy „ZRM w obszarze xxx km” – z zaznaczeniem
„ĆWICZENIA”.
7. Dyspozytor
powinien mieć możliwość wycofania zespołu z ćwiczeń
i zadysponowania go do zdarzenia w rejonie ćwiczeń, jako zespół o najkrótszym
czasie dotarcia do zdarzenia.
8. Tablet ZRM w czasie ćwiczeń powinien pracować w trybie „on-line/ĆWICZENIA”
przy zmienionej kolorystyce tła lub znakiem wodnym „ĆWICZENIA” na przekątnej
ekranu. Interfejs mocno różniący się od pracy w normalnym trybie.
9. Każda dokumentacja papierowa wytworzona w czasie pracy w trybie
„ĆWICZENIA” powinna posiadać znak wodny a numeracja znacznik/prefiks.
10. Obsługa zleceń realizowanych w ramach ćwiczeń powinna przebiegać w ten sam
sposób jak obsługa zdarzeń w normalnym trybie środowiska produkcyjnego.
11. Zlecenia z prefiksem nie powinny podlegać sprawozdawczości, raportowaniu.
12. Komunikacja głosowa zarejestrowana dla zdarzeń w trybie „ĆWICZENIA” może
być oznaczona (do dyskusji czy jest taka potrzeba).
str. 56 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
Kontrola przeglądów i data ważności pojazdów, kontrola ważności paszportów
2. Opis
przedmiotu technicznych sprzętu medycznego
Moduł Systemu: Aplikacja Administratora/Moduł techniczny
zadania:
Funkcjonalność obejmuje powiadamianie administratora/działu technicznego o końcu
ważności przeglądu pojazdu i „końcu ważności pojazdu” oraz o końcu ważności
paszportu sprzętu medycznego.
3. Wyniki
realizacji
zadania:
1. W Aplikacji Administratora – zakładka Administrator dysponenta – w tablicy Pojazd
nowa kolumna „Data ważności” w przypadku przekroczenia daty ważności minus
14 dni do końca terminu ważności – informacja rekord na żółto, w przypadku
przekroczenia daty ważności minus 7 dni do końca terminu ważności – informacja
rekord na czerwono. Anulowanie informacji poprzez edycję i zmianę dat.
2. W Aplikacji Administrator biznesowy – zakładka Administrator dysponenta – dodać
klawisz „Wyposażenie” po naciśnięciu klawisza pokazuje się tabela
„Wyposażenie”. W tabeli możliwość dopisania, usunięcia, modyfikacji i edycji pól.
Wstępnie pola wymagane: „Typ” – z tabeli słowniki nowy „słownik wyposażenia”:
defibrylator, pompa itd.
W rekordzie pola – „Nazwa”, „Data wprowadzenia”, „Nr inwentarzowy” „Data
usunięcia”, „Usunięte – przyczyna”, „Data końca ważności” w przypadku
przekroczenia daty ważności minus 30 dni do końca terminu ważności – informacja
rekord na żółto, w przypadku przekroczenia daty ważności minus 14 dni do końca
terminu ważności – informacja rekord na czerwono. Anulowanie informacji poprzez
edycję zmianę dat lub usunięcie.
„Przypisany do pojazdu (numer pojazdu, pole nieedytowalne z poziomu zakładki –
nr pojazdu przypisany z formatki „Modyfikacja Pojazdu”)”, „Nr paszportu”, „Opis”.
3. W Aplikacji Administrator biznesowy – zakładka Administrator dysponenta po
wybraniu pojazdu na formatce „Modyfikacja pojazdu” dodać klawisz
„Wyposażenie”. Po naciśnięciu klawisza „Wyposażenie” pokazuje się tabela
„Wyposażenie” z klawiszem „Dodaj” i klawiszem „Usuń” w przypadku dodania
wyposażenia z tabeli „Wyposażenie” rekord zmienia kolor na szary i brak
możliwości ponownego wyboru z informacją „Wyposażenie przypisane do pojazdu
____”.
Wszystkie tabele możliwość sortowania tabeli po nazwie pola.
4. Kryteria
akceptacji
zadania:
str. 57 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
2. Opis
przedmiotu
zadania:
3. Wyniki
realizacji
zadania:
4. Kryteria
akceptacji
zadania:
Wprowadzenie do SWD PRM statusów ZRM z pacjentem, przekazanie pacjenta,
gotowy w trasie, gotowy w bazie, pomocy, uszkodzony terminal, katastrofa, przerwa,
dezynfekcja i mycie ambulansu) oraz możliwość generowania historii użytych podczas
akcji ratunkowej statusów – dla każdego wyjazdu.
UWAGA: W związku z faktem, że poszczególne podmioty mają własne wewnętrzne
procedury dotyczące dezynfekcji i mycia ambulansów należy uzgodnić czy rozdzielać
status na dwie kategorie: mycie oraz dezynfekcja czy pozostawić jeden mycie
i dezynfekcja. W przypadku rozdzielenia na dwie kategorie należy ustalić jedną
definicję dla całego kraju.
Wprowadzenie funkcjonalności rejestrującej czas nadania statusu ZRM (wyjazd, na
miejscu, z pacjentem, w szpitalu, przekazanie pacjenta, gotowy w trasie, gotowy
w bazie, pomocy, awaria, tankowanie, uszkodzony terminal, katastrofa, przerwa)
powinien być zapisywany w SWD PRM i dostępny do pobrania za pomocą raportu,
podobnie jak dostępne są czasy interwencji ZRM określone w KZW.
Wprowadzenie funkcjonalności rejestrującej czas nadania statusu ZRM, jako warunek
konieczny do pełnej analizy funkcjonowania ZRM. Dzięki nim będą możliwe do
dokładnego określenia dodatkowe parametry działania ZRM takie jak np.: czas
przebywania ZRM w SOR czy ilość interwencji rozpoczynających się w trasie nie
w miejscu stacjonowania ZRM, aplikacja Dyspozytora SWD PRM i ZRM.
str. 58 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
2. Opis
Raporty stworzone przez jednego dysponenta powinny posiadać możliwość
przedmiotu
udostępnienia innym osobom – utworzenie bazy raportów
zadania:
1. Stworzenie raportu przez jednego dysponenta i udostępnienie go dla innego
3. Wyniki
użytkownika systemu dla wartości z jego obszaru. np. Dysponent stworzy raport dla
realizacji
sprawozdawczości NFZ i umożliwi udostępnienie zapytania dla innych
zadania:
dysponentów
1. Po zalogowaniu się do systemu raportowego użytkownik tworzy swój raport.
2. Opcja udostępnij w systemie tworzenia raportów indywidualnych.
3. Wskazanie, dla jakiego innego dysponenta (wskazanie osób u innego dysponenta
posiadające dostęp do raportów), będzie dostępny raport lub umożliwienie
udostępnienia wszystkim.
4. U drugiego dysponenta raport widoczny w folderze Udostępnione od innych
dysponentów.
5. W zawiązku, iż struktura bazy danych jest identyczna dla wszystkich dysponentów,
4. Kryteria
jeżeli zapytanie działa u jednego dysponenta musi działać u drugiego. Osoba
akceptacji
tworząca raport powinna mieć możliwość wpisania komentarzy, co dane pole bazy
zadania:
danych oznacza w celu ewentualnej dalszej weryfikacji przez pozostałych
dysponentów.
6. Osoba, która otrzyma raport, ma możliwość zapisania go w swoim systemie jako
własny.
7. W przypadku wykrycia błędu w raporcie przez innego dysponenta należy wycofać
poprzednią wersję raportu przez osobę która udostępniła ten raport. Spowoduje to
brak problemu ze zbyt dużą ilością raportów w systemie.
str. 59 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
2. Opis
Wdrożenie rozwiązania dla archiwizacji i udostępniania dokumentacji medycznej na
przedmiotu
żądanie uprawnionej osoby w lokalizacji poza siecią OST112.
zadania:
1. Należy zaprojektować i wdrożyć bazę danych dla archiwum dokumentacji
medycznej Zdarzeń z interfejsem użytkownika dostępnym z poziomu roli Analityka.
2. Archiwum dokumentacji medycznej będzie przechowywało i udostępniało
dokumenty w wersji ostatecznej (zamknięte) w standardzie HL7.
3. Archiwum dokumentacji medycznej będzie udostępniało interfejs dla systemu SIM
(P1), pozwalający na przyjęcie z SIM żądania udostępnienia konkretnej (określonej
identyfikatorem) dokumentacji medycznej wskazanej osobie z użyciem wskazanego
w parametrach nośnika (wydruk wysłany pod adres pocztowy/płyta lub inny nośnik
elektroniczny – plik/plik wystawiony pod automatycznie generowanym linkiem
tymczasowym z autoryzowanym dostępem, dane do pobrania pliku przesyłane pod
wskazany mail/hasło sms pod wskazany nr).
4. Z poziomu GUI Analityka Dysponenta dostępny mechanizm przeszukiwania
archiwum dokumentacji medycznej w oparciu o kryteria numeru zdarzenia i KZW,
danych osobowych pacjenta, przedział dat udzielenia pomocy, miejsce zdarzenia,
powód wezwania, pełno tekstowe przeszukiwanie wywiadu medycznego, miejsce
przekazania pacjenta, znacznik zgonu, znacznik zdarzenia masowego, znacznik
choroby zakaźnej.
5. Z poziomu GUI Analityka Dysponenta dostępne operacje drukowania, zapisania do
pliku, przesłania na serwer komunikacyjny połączonego z wygenerowaniem
tymczasowego linku do pliku na serwerze i wysłaniem danych do pobrania pliku na
wskazany mail i numer telefonu.
6. Możliwość konfiguracji z poziomu centralnego modułu archiwizacji w taki sposób,
aby dokumentacja medyczna była wystawiana automatycznie w lokalizacji poza
OST112 z automatycznym powiadomieniem o sposobie jej pozyskania (przesłanie
tymczasowego linku i hasła) po przekazaniu z pomocą interfejsu P1 żądania
3. Wyniki
udostępnienia takiej informacji w sieci. Analityk Dysponenta powinien bezpośrednio
realizacji
po zalogowaniu się w systemie otrzymać komunikat informujący o wykonaniu takich
zadania:
automatycznych działań w czasie jego braku aktywności. W przypadku wystąpienia
żądania udostępnienia dokumentacji medycznej w sieci w trakcie pracy Analityka
Dysponenta w systemie, powinien on być na bieżąco informowany o fakcie
udostępnienia dokumentacji medycznej.
7. W przypadku wysłania z SIM (P1) żądania udostępnienia dokumentacji medycznej
wyjazdu w sposób inny, niż w lokalizacji sieciowej, takie żądania są gromadzone po
stronie SWD PRM i komunikowane Analitykowi Dysponenta przy pierwszym
zalogowaniu użytkownika w roli Analityka danego dysponenta. Lista żądań
udostępnienia dokumentacji jest dostępna dla Analityka Dysponenta w postaci listy
zadań do wykonania z informacją o osobie uprawnionej do otrzymania
dokumentacji medycznej (wcześniej zautoryzowanej przez SIM) i sposobie
przekazania informacji. W module analityka SWD PRM będzie istniała możliwość
automatycznego przejścia do właściwego dokumentu z dostępem do funkcji
wymaganych dla realizacji żądania (drukowanie, zapis do pliku), a w przypadku
braku możliwości zlokalizowania bezpośrednio właściwego dokumentu,
z interfejsem do przeszukiwania archiwum. Zarejestrowane żądania będą miały
możliwość zaznaczenia faktu ich obsłużenia z oznaczeniem czasu realizacji
i przekazaniem do SIM informacji o realizacji.
8. Analityk Dysponenta posiada funkcjonalność pozwalającą na przeglądanie listy
oraz danych szczegółowych dotyczących realizacji wszystkich zarejestrowanych
żądań udostępnienia dokumentacji medycznej, wraz z informacją o czasach
charakterystycznych realizacji takiego żądania i zarejestrowanymi w systemie
znacznikami związanymi z jego wykonaniem (np. numer nadania listu poleconego).
9. W ramach rozszerzenia e-usług SWD PRM zostanie rozszerzone o dodatkowy
serwer plików wystawiony poza bezpieczną infrastrukturę OST112, do którego
str. 60 z 82
XI 2015 r. – VI 2016 r.
dostęp będzie realizowany przez Ośrodek Krajowy za pośrednictwem Centralnego
Punktu Styku. Serwer plików będzie udostępniał przestrzeń dyskową wystawioną
w sieci Internet, dostępną z zewnątrz za pośrednictwem tymczasowych ścieżek
dostępu generowanych na potrzebę wystawienia konkretnej dokumentacji
medycznej po dodatkowej autoryzacji hasłem dostępu generowanym na potrzeby
pobrania danego pliku. Plik dokumentacji medycznej jest dostępny pod
wygenerowanym adresem nie dłużej, niż przez czas określony parametrem
centralnie określonym dla SWD PRM. Użytkownik po pobraniu pliku z serwera
plików może zażądać jego usunięcia z tej lokalizacji bądź zachowania do ew.
powtórnego pobrania (na czas nie dłuższy, niż wymieniony wyżej). W przypadku
przekroczenia czasu wystawienia dokumentacji medycznej w tymczasowej
lokalizacji na serwerze plików, wystawiona dokumentacja jest z tej lokalizacji
usuwana, a jej powtórne udostępnienie wymaga uruchomienia procedury przez
system SIM.
10. Wszystkie operacje wykonywane w zakresie udostępnienia, zapisania na dysku,
wygenerowania lokalizacji tymczasowych, pobrań i usunięć będą rejestrowane
i archiwizowane w systemie z możliwością odczytania z poziomu aplikacji Analityka
Dysponenta, Administratora Dysponenta, Wojewody oraz Centralnego.
4. Kryteria
akceptacji
zadania:
KOMENTARZ DYREKTORA CSIOZ:
Opisane w załączonym dokumencie rozwiązanie wygląda na repozytorium dokumentów medycznych, więc co do
zasady jest ok. Aby rozwiązanie takie mogło współpracować z SIM musi po każdym zleceniu przekazać do P1
zdarzenie medyczne (w nomenklaturze P1), czyli przekazać indeks dokumentów w standardzie IHE XDS. Tylko ta
operacja doda w sposób poprawny powstałą dokumentację do indeksu dokumentacji pacjenta a w przyszłości
umożliwi udostępnienie dokumentu pacjentowi bądź lekarzowi (po obsłużeniu wniosku o udostępnienie). SWD PRM
musi też obsługiwać wniosek o udostępnienie definiowany przez SIM, tzn. nie można przyjąć, że SIM
zaimplementuje wniosek definiowany przez SWD PRM na potrzeby komunikacji z tym systemem.
Udostępnienie w trybie innym niż przez wniosek z P1 jest oczywiście możliwe, jednak w P1 nie może być po tym
śladu, tzn. nie należy zapisywać w P1 informacji o takim udostępnieniu. Inaczej – P1 obsługuje jeden proces
udostępniania i nie wspiera procesów zewnętrznych, których istnienie i funkcjonowanie jest obojętne z punktu
widzenia SIM/P1.
Doszczegółowienia wymaga standard zapisu dokumentu medycznego. Standardem przyjętym w P1 jest HL7 CDA
i rekomenduję użycie tego właśnie standardu. PDF wizualnie wygląda dobrze, możliwe jest przedstawienie
dokumentu jak we wzorze karty papierowej, w tym takiego wydruku jeżeli jest to konieczne. Traci jednak zalety
automatycznego przetwarzania, tzn. jest to elektroniczne odwzorowania dokumentu papierowego, niczym nie różni
się od skanu z OCR.
HL7 CDA ma tę zaletę, że z dokumentu automatycznie można pobrać dane w dowolnym innym medycznym
systemie informatycznym w kraju i zapisać je np. w rekordzie medycznym pacjenta. Można też prowadzić statystyki
dla danych z wielu dokumentów wielu pacjentów, tzn. HL7 CDA daje się automatycznie przetwarzać otwierając
nowe możliwości, również w nieznanej teraz przyszłości. Podobnie można automatycznie wytworzyć indeks IHE
XDS takiego dokumentu. Wadą jest standard wyświetlania danych, tzn. bez dedykowanej transformaty, a takich się
raczej nie robi, niemożliwe będzie przedstawienie Karty Medycznych Czynności Ratunkowych w układzie graficznym
jak we wzorze z rozporządzenia. HL7 CDA jest sposobem zapisu danych medycznych w XML bez kontekstu ich
wyświetlania, a transformata służy prezentacji, w tym wydruku tych danych w sposób możliwie standardowy dla
wszystkich rodzajów dokumentów, czy to recepty, czy KMCR, nie ma znaczenia.
Istotnym aspektem utworzenia nowych wzorów dokumentów HL7 CDA jest to, że opracowanie (w tym KMCR)
powinno być realizowane wyłącznie przez certyfikowaną osobę z instytucji będącej członkiem HL7 (tego wymaga
licencja i zdrowy rozsądek), konsultowane w normalnym trybie. W związku z powyższym rekomenduję aby
opracowanie nowych wzorów dokumentów (w tym KMCR) zostało przeprowadzone przez CSIOZ (jesteśmy
członkiem organizacji HL7) a nowe wzory dokumentów zostały włączone do Polskiej Implementacji Krajowej HL7
CDA właścicielem której jest CSIOZ.
Jeżeli jest taka możliwość to sugeruję aby środki finansowe przewidziane w projekcie na utworzenie nowych
dokumentów zostały przesunięte do CSIOZ.
CCA (T. WOŹNIAKOWSKI):
Obecna specyfikacja na chwilę obecną wydaje się wystarczająca, z dokładnością do uzupełnienia skrótów nazwy
standardu, ew. wskazania przypadków używania plików PDF, zgodnie z rekomendacją Pana Dyrektora
Węgrzyniaka.
str. 61 z 82
XI 2015 r. – VI 2016 r.
str. 62 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
2. Opis
przedmiotu
zadania:
Lekarz koordynator ratownictwa medycznego
Rozszerzenie zadań jakie może wykonywać LKRM z wykorzystaniem SWD PRM
celem realizacji zadań o których mowa w art. 29 ustawy z dnia 8 września 2006 r. (Dz.
U. z 2013 r., poz. 757 z późn. zm.) w szczególności w zakresie:
• koordynowania użycia ZRM pomiędzy rejonami operacyjnymi,
• odsłuchiwania nagrań,
• przekazywania obsługi zdarzeń pomiędzy dyspozytorniami medycznymi.
3. Wyniki
realizacji
zadania:
4. Kryteria
akceptacji
zadania:
1. Identyfikator
zlecenia:
2. Opis
przedmiotu
zadania:
Dostosowanie obecnie występującej w SWD PRM KZW i KMCR do nowej wersji
zgodnie ze zmianami, które zostaną wprowadzone w rozporządzeniu Ministra Zdrowia
w sprawie w sprawie rodzajów i zakresu dokumentacji medycznej oraz sposobu jej
przetwarzania.
Przy zmianie rozporządzenia zmiany zostaną wprowadzone w:
• Karcie Zlecenia Wyjazdu,
• Karcie Medycznych Czynności Ratunkowych.
Zakładane jest również przy nowelizacji rozporządzenia wprowadzenie karty
odstąpienia od medycznych czynności ratunkowych, która powinna znaleźć się
również w SWD PRM.
W zakresie standardu nowej wersji dokumentacji medycznej przewiduje się jej
przygotowanie w standardzie HL7 CDA oraz przygotowanej dedykowanej transformaty
tak aby można było zwizualizować graficznie dokumentację medyczną (na obecny
wzór).
3. Wyniki
realizacji
zadania:
4. Kryteria
akceptacji
zadania:
str. 63 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
2. Opis
przedmiotu
zadania:
3. Wyniki
realizacji
zadania:
Zadysponowanie jednostki współpracującej z systemem PRM do zdarzenia –
konieczność zobrazowania tego w SWD PRM.
UWAGA: konieczność jednoznacznego określenia jednostki współpracującej
z systemem PRM i ewentualnej zmiany zakresu funkcjonalności
1. W dodawaniu służb pomocniczych w module dyspozytora powinien pośredniczyć
system informatyczny Centrum Powiadamiania Ratunkowego (wspólna numeracja
zdarzeń).
2. Po dodaniu służby pomocniczej w formatce zdarzenia aplikacji dyspozytorskiej na
liście zleceń przy zleceniu pomiędzy „nazwa ZRM” a „lokalizacja” powinna ukazać
się ikona informująca o podłączeniu odpowiednich służb do zlecenia.
3. Po otrzymaniu z Centrum Powiadamiania Ratunkowego potwierdzenia
zadysponowania zespołu przez dołączoną do zlecenia służbę pomocniczą powinna
być możliwość wizualizacji tego zespołu na oddzielnej warstwie UMM.
4. Po uruchomieniu z listy zdarzeń „pokaż środki zadysponowane do zdarzenia”
powinno nastąpić uruchomienie nowej warstwy, wycentrowanie mapy do punktu
/miejsca zdarzenia oraz wizualizacja wszystkich zespołów przydzielonych do
obsługi zlecenia
– odmienne symbole graficzne dla służb
– ZRM-y z odpowiednim statusem
– zespoły służb pomocniczych bez statusu ale z odległością od miejsca zdarzenia
i przybliżonym czasem dotarcia na miejsce.
4. Kryteria
akceptacji
zadania:
str. 64 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
2. Opis
przedmiotu Dostosowanie aplikacji do wyświetlania etykiet na ikonach w UMM w postaci DYMKA.
zadania:
Temat sprowadza się do aktualizacji DLLek w aplikacji IISowej IGUMM oraz
aktualizacji konfiguracji biznesowej w XMLach.
Jeżeli chodzi o ‘etykietę’ w postaci dodatkowej ikony, to po stronie UMM do reguły
stylu dodano pod-regułę (regułę wewnętrzną), która umożliwia wyświetlenie
dodatkowej ikony.
Plik konfiguracyjny z regułami styli (Style.xml), gdzie można to zobaczyć ‘od środka’
(zaznaczony element, który został dodany w celu rozszerzenia funkcjonalności):
<Style>
<ObjectTypeName>Taksi</ObjectTypeName>
<Definition xsi:type="ThematicStyleDefinition">
<ThematicItems>
<ThematicItemDefinition>
<Name>Osobowy</Name>
<PictogramUrl>img/examples/osobowy.gif</PictogramUrl>
</ThematicItemDefinition>
<ThematicItemDefinition>
<Name>Ciężarowy</Name>
<PictogramUrl>img/examples/ciezarowy.gif</PictogramUrl>
</ThematicItemDefinition>
</ThematicItems>
<ThematicStyles>
<StyleElement>
<PrimaryStyleRule>
<Rule>'[Typ]'=='o'</Rule>
<Definition xsi:type="PictureStyleDefinition">
3. Wyniki
<PictureUrl>img/examples/osobowy.gif</PictureUrl>
realizacji
<Width>47</Width>
zadania:
<Height>18</Height>
</Definition>
</PrimaryStyleRule>
<StyleRules>
<StyleRule>
<Rule>'[Marka]'=='fiat'</Rule>
<Definition>
<PictureUrl>img/examples/car.png</PictureUrl>
<Width>94</Width>
<Height>36</Height>
</Definition>
<InnerStyleRule>
<Rule>'[Status]'=='zajeta'</Rule>
<Definition>
<PictureUrl>img/examples/busy.png</PictureUrl>
<Width>24</Width>
<Height>24</Height>
</Definition>
</InnerStyleRule>
</StyleRule>
</StyleRules>
</StyleElement>
<StyleElement>
<PrimaryStyleRule>
<Rule>'[Typ]'=='c'</Rule>
str. 65 z 82
XI 2015 r. – VI 2016 r.
<Definition xsi:type="PictureStyleDefinition">
<PictureUrl>img/examples/ciezarowy.gif</PictureUrl>
<Width>52</Width>
<Height>21</Height>
</Definition>
</PrimaryStyleRule>
<StyleRules>
<StyleRule>
<Rule>'[Id]'==1</Rule>
<Definition>
<PictureUrl>img/examples/warning.png</PictureUrl>
<Width>52</Width>
<Height>21</Height>
</Definition>
</StyleRule>
</StyleRules>
</StyleElement>
</ThematicStyles>
</Definition>
</Style>
4. Kryteria
akceptacji
zadania:
str. 66 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
2. Opis
przedmiotu
zadania:
3. Wyniki
realizacji
zadania:
4. Kryteria
akceptacji
zadania:
Monitoring czasu, który upłynął od momentu zadysponowania ZRM do przesłania
statusu WYJAZD wraz z wyświetleniem odpowiedniego alertu po przekroczeniu
wartości zadanej oraz przesłaniu do ZRM ponaglenia, wizualizacja na liście ZRM
czasów zmiany statusów.
1. W Aplikacji Dyspozytora SWDPRM w sekcji Lista ZRM dodana kolumna
z informacją o czasie, jaki upłynął od momentu określenia dla ZRM aktualnego
statusu w formacie gg:mm:ss (godziny:minuty:sekundy).
2. W Systemie dodana obsługa parametru mówiącego o tym, po jakim czasie należy
wygenerować ostrzeżenie dla dyspozytorów wysyłających o zbyt długim czasie
pomiędzy
zadysponowaniem
ZRM
przez
Dyspozytora
(status
ZRM
„Zadysponowany”), a wyjazdem (ustawienie statusu „Wyjazd”). Parametr ustawiany
lokalnie dla stacji roboczej.
3. Sygnalizowanie o przekroczonym czasie od zadysponowania do wyjazdu ZRM jest
widoczne na wszystkich stacjach roboczych dyspozytorów wysyłających, którzy
widzą w liście Zdarzeń bądź liście ZRM wiersze związane z sygnałem.
realizowane poprzez podświetlenie wiersza ZRM w liście ZRM oraz wiersza
Zdarzenia w liście Zdarzeń (w przypadku wielu KZW dla Zdarzenia, po rozwinięciu
widoczne na wierszu właściwym dla opóźnionego KZW), dla którego przynajmniej
jeden wyjazd jest opóźniony, jaskrawym tłem w kolorze dedykowanym dla tego
sygnału (sugerowany kolor niebieski).
5. Sygnał o przekroczeniu czasu do wyjazdu ma niższy priorytet od sygnału
o przekroczeniu czasu dla potwierdzenia przyjęcia Zlecenia przez ZRM. Jeśli ZRM
nie przyjął Zlecenia w określonym czasie i został oznaczony w liście, nie nakłada
się na ten sygnał informacji o przekroczeniu czasu do wyjazdu.
6. W liście ZRM w menu pod prawym przyciskiem myszy oraz w sekcji KZW w ekranie
Zdarzenia dostępny przycisk ponaglenia, aktywny wyłącznie w przypadku, gdy ZRM
potwierdził przyjęcie Zlecenia i ZRM jeszcze nie dotarł na miejsce Zdarzenia
(dot. listy ZRM).
7. Użycie przycisku ponaglenia w przypadku, gdy wiersz ZRM jest oznaczony
sygnałem opóźnionego wyjazdu do Zdarzenia powoduje wygaszenie tego sygnału
na wszystkich stanowiskach, na których jest widoczny i rozpoczęcie na nowo
odliczania czasu dla podświetlenia tak, jakby ZRM został zadysponowany
w momencie ponaglenia.
W Aplikacjach ZRM (w miejscu stacjonowania i na tablecie) wyświetlane jest okno
modalne z komunikatem: „Dyspozytor <kod dyspozytora> przekazał ponaglenie dla
zlecenia nr <nr KZW dla aktualnego Zdarzenia>” (KZW właściwe dla sekcji
w ekranie Zdarzenia albo pierwsze dla danego ZRM w ramach aktywnego
Zdarzenia) oraz generuje sygnał, jak w przypadku przekazania Zlecenia dla ZRM.
8. Komunikat o ponagleniu w aplikacjach ZRM może być wyłączony przez
potwierdzenie przyciskiem „OK.”, jak przy potwierdzeniu przyjęcia Zlecenia
(potwierdzenie hasłem na komputerze stacjonarnym, potwierdzenie na jednym
stanowisku wyłącza wszystkie okna związane z komunikatem o ponagleniu), albo
poprzez anulowanie KZW z poziomu Aplikacji Dyspozytora.
9. Jeżeli ZRM do czasu upłynięcia czasu dla wyjazdu od momentu ponaglenia nie
przyjął statusu „Wyjazd”, ZRM jest oznaczany ponownie, jak w przypadku
upłynięcia czasu od momentu zadysponowania.
10. Sygnał o przekroczeniu czasu do wyjazdu (zarówno dla zadysponowania, jak dla
ponaglenia) jest wyłączany w przypadku zmiany statusu przez ZRM na dowolny
status związany z obsługą wyjazdu („Wyjazd”, „Na miejscu”, „Transport do szpitala”,
„W szpitalu”, „Powrót do bazy”).
1. W Aplikacji Dyspozytora SWDPRM w sekcji Lista ZRM dodana kolumna
z informacją o czasie od momentu określenia dla ZRM aktualnego statusu
w formacie gg:mm:ss (godziny:minuty:sekundy).
Dopuszcza
się format
str. 67 z 82
XI 2015 r. – VI 2016 r.
minuty:sekundy, który przechodzi w godziny:minuty po przekroczeniu 59 minut, pod
warunkiem wyraźnego i jednoznacznego oznaczenia, że została przekroczona
godzina od ustawienia obecnego statusu.
2. Wartość w kolumnie z czasem zerowana automatycznie przy zmianie statusu przez
ZRM. Od tego momentu automatycznie aktualizowana i wyświetlana.
(zarówno w sekcji Lista ZRM, jak w pozostałych sekcjach).
4. Parametr określający długość czasu, po którym należy włączyć sygnalizację
przekroczenia czasu do wyjazdu wyrażony w sekundach, ustawiany na poziomie
każdej stacji roboczej. Dopuszcza się ustawianie jego wartości na poziomie pliku
konfiguracyjnego albo z poziomu interfejsu użytkownika Aplikacji Dyspozytora.
widoczne na wszystkich stacjach roboczych dyspozytorów wysyłających, na których
stacjach są widoczne wiersze ZRM lub Zdarzenia, którego dotyczy sygnalizacja.
realizowane w sposób zgodny z opisem w pkt. Wynik realizacji zlecenia.
7. Podświetlenie wiersza Zdarzenia mówiące o opóźnionym czasie wyjazdu ZRM
w przypadku Zdarzenia z wieloma KZW jest widoczne w przypadku, gdy opóźnienie
dotyczy jednego lub więcej KZW zarówno przy Zdarzeniu rozwiniętym do poziomu
poszczególnych KZW, jak przy wierszu scalonym (nierozwiniętym). W przypadku
rozwinięcia listy do poziomu KZW dodatkowo podświetlony jest wiersz opóźnionego
KZW.
8. Sygnał o przekroczeniu czasu przyjęcia Zlecenia przez ZRM nie może zostać
nadpisany sygnałem o opóźnieniu wyjazdu ZRM.
9. W liście ZRM w menu pod prawym przyciskiem myszy oraz w sekcji KZW w ekranie
Zdarzenia dostępny przycisk ponaglenia, aktywny wyłącznie w przypadku, gdy ZRM
potwierdził przyjęcie Zlecenia i ZRM jeszcze nie dotarł na miejsce Zdarzenia (dot.
listy ZRM). Przycisk niewidoczny albo nieaktywny w statusach „Na miejscu”,
„Transport do szpitala”, „W szpitalu”, „Powrót do bazy”, „Gotowy w bazie” i
w statusach „technicznych”.
10. Użycie przycisku ponaglenia w przypadku, gdy wiersz ZRM jest oznaczony
sygnałem opóźnionego wyjazdu do Zdarzenia albo zmiana statusu ZRM na
dowolny związany z obsługa Zdarzenia, zgodnie z opisem w pkt. „Wynik realizacji
zlecenia”, powoduje wygaszenie tego sygnału na wszystkich stanowiskach, na
których jest widoczny i rozpoczęcie na nowo odliczania czasu dla podświetlenia tak,
jakby ZRM został zadysponowany w momencie ponaglenia.
11. Uruchomienie ponaglenia dla ZRM powoduje wyświetlenie komunikatu modalnego
z sygnałem dźwiękowym dla ZRM zgodnie z opisem w pkt. „Wyniki realizacji
zlecenia”.
12. Komunikat o ponagleniu w aplikacjach ZRM może być wyłączony wyłącznie przez
potwierdzenie przyciskiem „OK.”, jak przy potwierdzeniu przyjęcia Zlecenia
(potwierdzenie hasłem na komputerze stacjonarnym, potwierdzenie na jednym
stanowisku wyłącza wszystkie okna związane z komunikatem o ponagleniu), albo
poprzez anulowanie KZW z poziomu Aplikacji Dyspozytora.
13. Jeżeli ZRM do czasu upłynięcia czasu dla wyjazdu od momentu ponaglenia nie
przyjął statusu „Wyjazd”, ZRM jest oznaczany ponownie, jak w przypadku
upłynięcia czasu od momentu zadysponowania.
a) Należy
wprowadzić
właściwe
zapisy
w dokumentacji
użytkownika
b) Zmiana powinna zostać zainstalowana i przetestowana na środowisku
wcześniejszego
wykonania
testów
wewnętrznych
na
środowisku
c) Zmiana, po przetestowaniu na środowisku szkoleniowym, powinna zostać
str. 68 z 82
XI 2015 r. – VI 2016 r.
str. 69 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
2. Opis
Nazwa wymagania: Optymalizacja wyświetlanych notyfikacji.
przedmiotu
Moduł Systemu: Aplikacja dyspozytora
zadania:
1. Uporządkowanie zakresu prezentowanych notyfikacji w Aplikacji dyspozytor.
Po wprowadzeniu funkcjonalności, notyfikacje mają być wyświetlane wyłącznie na
wskazanych w specyfikacji stanowiskach dyspozytorskich w konkretnej dyspozytorni
medycznej – zgodnie z pełnioną przez dyspozytora medycznego rolą na zmianie albo
przypisaniem do Zdarzenia,
Uporządkowanie zakresu prezentowanych notyfikacji ma skutkować wyświetlanie
w Aplikacji dyspozytora jedynie następujących notyfikacji:
1.1 Awaria dyspozytorni medycznej zastępowanej i wymaganie przejęcia obsługi
zgłoszeń i zdarzeń (notyfikacja na stanowisku Dyspozytorów Głównego
i Zastępcy w dyspozytorni medycznej zastępującej);
1.2 Przekazanie zgłoszenia do innej dyspozytorni medycznej (notyfikacja na
stanowisku Dyspozytorów Głównego i Zastępcy w dyspozytorniach
medycznych przekazującej i docelowej);
1.3 Brak przypisanego obszaru dysponowania dla zdarzenia w ramach
dyspozytorni medycznej (notyfikacja na stanowisku Dyspozytorów Głównego
i Zastępcy);
1.4 Awaria stanowiska dyspozytorskiego albo konsoli (notyfikacja na stanowisku
Dyspozytorów Głównego i Zastępcy oraz na właściwym stanowisku którego
dotyczy awaria konsoli);
1.5 Przydzielenie Zdarzenia do zadysponowania – notyfikacja wyróżniona
sygnałem dźwiękowym (właściwy dyspozytor medyczny wysyłający) –
w przypadku braku dyspozytorów medycznych wysyłających w ramach
dyspozytorni medycznej (tryb każdy dyspozytor medyczny dysponuje przyjęte
przez siebie zdarzenia) – brak tej notyfikacji;
1.6 Zgłoszenie przez ZRM statusu „AWARIA” (notyfikacja na wszystkich
3. Wyniki
stanowiskach dyspozytorów medycznych dysponujących, którzy mają
realizacji
ustawiony obszar dysponowania przecinający się z obszarem działania ZRM
zadania:
oraz na stanowisku Dyspozytora Głównego i jego Zastępcy w dyspozytorni
medycznej, z którą jest powiązany ZRM – na obszarze której stacjonuje);
1.7 Zgłoszenie ZRM w nowym składzie – specjalne oznaczenie graficzne
w przypadku składu niepełnego (notyfikacja u Dyspozytora Głównego lub
Zastępcy);
1.8 Zdarzenie niepodjęte (czyli nieotwarte) przez dyspozytora medycznego
dysponującego właściwego dla zdarzenia po określonym czasie od przyjęcia,
(notyfikacja u wszystkich dyspozytorów medycznych wysyłających –
w przypadku braku dyspozytorów medycznych wysyłających w ramach
dyspozytorni medycznej (tryb pracy – każdy dyspozytor medyczny dysponuje
przyjęte przez siebie zdarzenia) – brak tej notyfikacji;
1.9 Zmiana kodu pilności przez dyspozytora medycznego (notyfikacja na
stanowisku Dyspozytora Głównego i Zastępcy oraz dyspozytora wysyłającego
dla tego Zdarzenia bądź na jego stanowisku, pod warunkiem, że przynajmniej
jeden ZRM z przypisanych do obsługi Zdarzenia jeszcze nie był w statusie
„ZRM na miejscu” dla tego Zdarzenia;
1.10 Zmiana danych dotyczących miejsca zdarzenia (notyfikacja na stanowisku
Dyspozytora Głównego i Zastępcy oraz dyspozytora wysyłającego dla tego
Zdarzenia bądź na jego stanowisku, pod warunkiem, że przynajmniej jeden
ZRM z przypisanych do obsługi Zdarzenia jeszcze nie był w statusie „ZRM na
miejscu” dla tego Zdarzenia);
1.11 Zmiany informacji dotyczących stanu pacjenta (notyfikacja na stanowisku
Dyspozytora Głównego i Zastępcy oraz dyspozytora wysyłającego dla tego
Zdarzenia bądź na jego stanowisku, pod warunkiem, że przynajmniej jeden
str. 70 z 82
XI 2015 r. – VI 2016 r.
ZRM z przypisanych do obsługi Zdarzenia jeszcze nie był w statusie „ZRM na
miejscu” dla tego Zdarzenia);
2. Wszystkie Notyfikacje pojawiające się na stanowiskach, z wyjątkiem notyfikacji
typu „Nowe zdarzenie do zadysponowania” (pkt 1.5.), nie powinny znikać same.
Użytkownik każdą notyfikację będzie mógł wyłączyć wywołując dla niej funkcję
„Usuń z listy” lub otwierając zdarzenie, na które wskazuje notyfikacja poprzez
kliknięcie w nią lewym przyciskiem. Notyfikacja typu „Nowe zdarzenie do
zadysponowania” powinna znikać automatycznie po zadysponowaniu zespołu
ratownictwa medycznego do zdarzenia.
4. Kryteria
akceptacji
zadania:
str. 71 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
2. Opis
Nazwa wymagania: Wymuszanie zatwierdzenia dokumentacji medycznej
przedmiotu
Moduł Systemu: Aplikacja mobilna ZRM/Aplikacja MS ZRM/Moduł raportowy
zadania:
Funkcjonalność wymusza na personelu zespołu ratownictwa medycznego
zatwierdzenie wytworzonej przez nich dokumentacji medycznej. Kierownik ZRM nie
będzie mógł prawidłowo zakończyć dyżuru jeżeli będzie posiadał niezamknięte
KZW/KMCR. Przy próbie zakończenia dyżuru przez kierownika ZRM, w sytuacji gdy
istnieją niezamknięte przypisane do niego KZW/KMCR, niezależnie od czasu w jakim
powstały, wyświetlany zostanie komunikat, pokazujący wszystkie niezakończone
KZW/KMCR, a czynność zakończenia dyżuru nie zostanie wykonana w sposób
standardowy – nie zostanie wprowadzona data zakończenia. Będzie możliwe
rozpoczęcie kolejnego dyżuru przez tego użytkownika, który nie ma wprowadzonego
czasu zakończenia poprzedniego dyżuru. Jego poprzedni dyżur zakończy się
automatycznie z zakończeniem na czas rozpoczęcia kolejnego dyżuru i zaznaczeniem
niespełnionego warunku zakończenia. W raporcie „Lista Obecności” będzie to
oznaczone * (modyfikacja raportu).
1. Przy próbnie wykonywania akcji „zakończ dyżur” przez kierownika ZRM, gdy
system wykryje istniejące przypisane do niego, niezakończone KZW/KMCR, system
będzie wyświetlał okno modalne zawierające komunikat:
„Następujące dokumenty nie są zamknięte:
Numer (adres) dokumentu 1
Numer (adres) dokumentu 2
3. Wyniki
…
realizacji
Aby zakończyć poprawnie dyżur, należy najpierw zakończyć wszystkie dokumenty.
zadania:
Dostępne operacje: OK (Dokończenie operacji przy niespełnionym warunku
zamknięcia dokumentacji medycznej, bez wprowadzenia daty zakończenia dyżuru),
Anuluj (kontynuacja dyżuru w celu zamknięcia dokumentacji medycznej).
1.1 W przypadku gdy użytkownik zignoruje komunikat i nie zakończy poprawnie
dyżuru, próba rozpoczęcia następnego dyżuru zakończy poprzedni dyżur
automatycznie. Fakt zakończenia dyżuru w sposób automatyczny, a nie
prawidłowy tj. ręcznie i osobiście przez kierownika ZRM, powinien być oznaczony
w bazie w taki sposób, aby było możliwe stworzenie raportu wykazującego takie
przypadki.
1.1.1 W ramach realizacji zlecenia, w predefiniowanym raporcie „Lista obecności”
wykonawca powinien dokonać zmiany polegającej na tym, że w kolumnie nr 8
– „Czas zakończenia dyżuru” poszczególne wpisy powinny zostać oznaczone
„*” na końcu w przypadku, gdy zakończenie dyżuru nastąpiło w sposób
automatyczny. Przykładowo:
09-03-2015 17:01*
Pod całą tabelą raportu powinien pojawić się opis:
(* – zakończenie nastąpiło automatycznie w wyniku rozpoczęcia nowego
dyżuru bez wcześniejszego prawidłowego zakończenia poprzedniego dyżuru)
4. Kryteria
akceptacji
zadania:
str. 72 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
Nazwa wymagania: Usprawnienia w interfejsie aplikacji mobilnej – widoczny numer
2. Opis
przedmiotu KZW.
Moduł Systemu: Aplikacja mobilna ZRM
zadania:
Wprowadzona w aplikacji mobilnej ZRM funkcjonalność wyświetlająca numer aktualnej
Karty Zlecenia Wyjazdu obok napisu ZDARZENIE znajdującego się na pasku
z zakładkami. Przedmiotowy numer powinien być aktywnym linkiem, po którego
kliknięciu otworzy się dokument dotyczący tej Karty Zlecenia Wyjazdu. Wielkość
obszaru aktywnego powinna umożliwić swobodne otwarcie dokumentu za pomocą
3. Wyniki
dotyku palcem.
realizacji
1. W aplikacji mobilnej ZRM wyświetlany jest w sekcji górnego paska numer aktualnej
zadania:
KZW.
2. W przypadku, gdy na tablecie nie ma żadnej aktywnej KZW, aktywny link nie jest
wyświetlany.
3. Kliknięcie w napis powoduje otwarcie aktualnej KZW.
4. Kryteria
akceptacji
zadania:
str. 73 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
Nazwa wymagania: Powiązanie kodu pilności ze znacznikiem sygnałów świetlnych
2. Opis
przedmiotu i dźwiękowych w ekranie Zdarzenia.
zadania:
Funkcjonalność dotyczy powiązania kodu pilności wezwania z automatycznym
zaznaczeniem pola „wyjazd na sygnale” na poziomie Zdarzenia. Powyższe dotyczy
także zmian w tym zakresie w KZW przekazanych już do zespołu ratownictwa
medycznego.
1. Wybranie kodu pilności '1' automatycznie ustawia wyjazd na sygnale we wszystkich
KZW dla Zdarzenia.
1.1 Wybranie kodu pilności '2' automatycznie ustawia wyjazd bez sygnałów.
3. Wyniki
1.1.1 Zmiana kodu pilności i automatyczne powiązanie lub nie z wyjazdem na sygnale
realizacji
na poziomie zdarzenia dotyczy zmian w tym zakresie w kartach zlecenia
zadania:
wyjazdu przekazanych już do zespołu ratownictwa medycznego.
1.1.1.1 Oznaczenie 'wyjazd na sygnale' ma nadal być dostępne do edycji – jego
zmiana nie będzie zmieniać wartości kodu pilności. Znacznik ma być również
dostępny do edycji na poziomie każdego KZW z osobna – nadpisywany na
żądanie (po potwierdzeniu przez użytkownika) przy zmianie z poziomu
Zdarzenia.
4. Kryteria
akceptacji
zadania:
1. Identyfikator
zlecenia:
2. Opis
Nazwa wymagania: Zmiana algorytmu podpowiadania Zdarzeń podobnych.
przedmiotu
zadania:
Obecnie działający algorytm podpowiadania Zdarzeń podobnych (wyszukiwania
w Systemie SWD PRM), podłączony do GUI Dyspozytora, należy zastąpić nowym
mechanizmem w zakresie kryterium podobnej lokalizacji z uzupełnieniem o kryterium
czasu.
1. Jako zdarzenie podobne powinny być podpowiadane, oprócz uwzględnianych
obecnie, zdarzenia, których miejsce jest w niewielkiej, określonej parametrem
określanym na poziomie Administratora Centralnego, odległości od bieżącego
3. Wyniki
zdarzenia (np. 300 metrów) – dopuszcza się uproszczenie polegające na
realizacji
uwzględnieniu obszaru o kształcie kwadratu o boku dł. określonej parametrem na
zadania:
poziomie Administratora Centralnego, w którego środku znajduje się bieżące
Zdarzenie.
2. Podpowiadana lista zdarzeń powinna zawierać zdarzenia w dowolnym statusie
(otwarte, obsłużone, odmowy itd.) zdarzenia z ostatnich np. 12 godzin (parametr
liczby godzin, jakie upłynęły od zarejestrowania zgłoszenia w SWD PRM/odebrania
połączenia przez dyspozytora medycznego, który będzie ustawiany z poziomu
Administratora Centralnego).
4. Kryteria
akceptacji
zadania:
str. 74 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
Nazwa wymagania: Narzędzie monitorujące pracę dyspozytorów medycznych na
2. Opis
przedmiotu zmianie.
zadania:
Narzędzie monitorujące pracę dyspozytorów medycznych na zmianie w dyspozytorni
medycznej ma za zadanie zobrazowanie realizowanych przez nich czynności przez
cały okres liczony od rozpoczęcia do zakończenia pracy na danym stanowisku
dyspozytorskim.
3. Wyniki
realizacji
zadania:
1.1 Narzędzie monitorujące pracę dyspozytorów medycznych na zmianie ma stanowić
odrębne okno Aplikacji dyspozytora włączane i wyłączane poprzez obsługę
przycisku dodanego do: „Paska parametrów modułu dyspozytora”.
1.2 Narzędzie monitorujące pracę dyspozytorów medycznych na zmianie dostępne
jest na wszystkich stanowiskach dyspozytorów medycznych bez względu na
pełnioną rolę (Dyspozytor, Główny Dyspozytor, Zastępca Głównego Dyspozytora)
oraz aktualne ustawienia stacji roboczej (przyjmujący, dysponujący, przyjmujący
i dysponujący, wyłączone obie opcje) oraz status (aktywny/przerwa).
1.3 Narzędzie monitorujące pracę dyspozytorów medycznych na zmianie jest oknem
niemodalnym (pozwala na pracę w innych oknach aplikacji) wyświetlanym w trybie
„zawsze na wierzchu” i składa się z okna głównego oraz obszaru dodatkowego
otwieranego z pomocą przycisku „+”.
1.4 Narzędzie monitorujące pracę dyspozytorów medycznych na zmianie w oknie
głównym obrazuje następujące elementy:
1.4.1 Stanowiska zalogowane i niezalogowane w tym odrębne oznaczenie dla
stanowisk podstawowych i zapasowych.
1.4.2 Stanowiska wylogowane automatycznie przez system SWD PRM.
1.4.3 Włączenie/Wyłączenie przyjmowania zgłoszeń.
1.4.4 Włączenie/Wyłączenie dysponowania zgłoszeń.
1.4.5 Tryb pracy: obsługa zgłoszeń, przerwa.
1.5 Narzędzie dodatkowe monitorujące pracę dyspozytorów medycznych na zmianie
w/pod przyciskiem „+” obrazuje następujące elementy:
1.5.1
Czas pracy w trybie obsługa zgłoszeń, przerwa, gotowość do obsługi
zgłoszenia oraz czas od automatycznego wylogowania przez system SWD
PRM – pokazywane są wartości sumaryczne dla stanowiska
dyspozytorskiego liczone od momentu rozpoczęcia dyżuru przez
Dyspozytora.
1.5.1.1 Czas pracy w trybie obsługa zgłoszeń jest liczony od momentu
rozpoczęcia obsługi zgłoszenia (odebrania połączenia na konsoli albo
otworzenia formatki nowego Zdarzenia dla zgłoszeń bezgłosowych)
i liczony jest do czasu zakończenia jego obsługi (wyjścia z formatki
szczegółów Zdarzenia do listy Zdarzeń).
1.5.1.2 Czas pracy w trybie przerwa liczony jest od momentu rozpoczęcia
przerwy do jej zakończenia (wprowadzane przyciskiem „słuchawek”).
1.5.1.3 Czas pracy w trybie gotowości do obsługi zgłoszenia liczony jest od
momentu pozostawania w gotowości (wyświetlona lista Zdarzeń albo
ekran szczegółów Zdarzenia w trybie tylko do odczytu, Dyspozytor
zalogowany w Systemie nie prowadzi rozmowy z konsoli, ma ustawioną
dostępność, „zielone słuchawki” w pasku statusu) do czasu do czasu
przejścia w inny tryb pracy.
1.5.1.4 Czas od automatycznego wylogowania przez system SWD PRM liczony
jest od momentu automatycznego wylogowania przez system do czasu
pracy ponownego zalogowania do Systemu.
1.6 Włączenie przez dyspozytora medycznego Przerwy lub wyłączenie przyjmowania
zgłoszeń i dysponowania zgłoszeń lub automatyczne wylogowanie stanowiska
str. 75 z 82
XI 2015 r. – VI 2016 r.
przez system SWD PRM jest sygnalizowane przez dźwięk i „migające” pole
obrazujące stanowisko dyspozytora medycznego, którego dotyczy ta sytuacja.
1.6.1 Dźwięk, o którym mowa w pkt 1.6 jest generowany jedynie na stanowisku
Głównego Dyspozytora oraz Zastępcy Głównego Dyspozytora.
1.6.2 „Migające” pole obrazujące stanowisko dyspozytora medycznego, którego
dotyczy sytuacja opisana w pkt 1.6 trwa przez okres 10 sekund.
4. Kryteria
akceptacji
zadania:
1. Identyfikator
zlecenia:
Nazwa wymagania: Automatyczne uzupełnianie znacznika Dorosły/Dziecko na
2. Opis
przedmiotu podstawie wieku
Moduł Systemu: Aplikacja Dyspozytora
zadania:
1. W przypadku wprowadzenia w polu „Lata” wartości z przedziału <0; 17>, należy
ustawić znacznik na wartość „Dziecko”. W przypadku wprowadzenia wartości 18 lub
większej, należy ustawić znacznik na wartość „Dorosły”.
2. Funkcjonalność uruchamiana wyłącznie w przypadku wprowadzania zmian wartości
w polu „Lata”. W przypadku, gdy przy wejściu do pola wartość jest ustawiona na 17,
a znacznik na „Dorosły” i pomiędzy wejściem i opuszczeniem pola „Lata” nie
edytowano danych, funkcja nie będzie uruchamiana – znacznik pozostanie
ustawiony na „Dorosły”.
3. Wartość nieokreślona w polu „Lata” nie wpływa na zmianę wartości znacznika.
4. Wartość „Wiek” będzie analizowana każdorazowo po opuszczeniu pola „Lata”
3. Wyniki
(niezależnie, czy nawigacja tabulatorem, czy myszą). Nawigacja tabulatorem
realizacji
w obrębie sekcji „Dane pacjenta” kolejno:
zadania:
1. Imię
2. Nazwisko
3. Płeć – Mężczyzna
4. Płeć – Kobieta
5. Lata
6. Miesiące
7. Dni
8. Wiek – Dorosły
9. Wiek – Dziecko.
4. Kryteria
akceptacji
zadania:
str. 76 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
Nazwa wymagania: Zmiana sposobu obsługi pola „Zalecenia/Zastosowane leki”
2. Opis
przedmiotu w zakresie działania słowników i sposobu generowania wydruku KMCR.
Moduł Systemu: Aplikacja mobilna ZRM, Aplikacja MZ ZRM.
zadania:
Zastąpienie interfejsu słownika: Postępowanie z pacjentem Karty Medycznych
Czynności Ratunkowych: Zalecenia/Zastosowane leki rozwiązaniem opartym o 5
pól: „Nazwa leku”, „Dawka leku”, „Jednostka miary”, „Droga podania”, „Godzina
podania”.
W wersji drukowanej KMCR kolejne wybrane pozycje mają być prezentowane,
jako wpisy składające się z kompletu wartości wprowadzonych w ww. polach
oddzielonych znakiem ‘,’, wartości puste mają być pomijane w złączeniu (brak
„podwójnych przecinków”), kolejne zastosowane leki mają być oddzielane znakiem
‘;’.
1.1 „Nazwa leku” – pole słownikowe korzystające z dostarczonego do SWD PRM
słownika leków – bez możliwości wprowadzania dodatkowych nazw leków przez
użytkownika końcowego – członka zespołu ratownictwa medycznego. Możliwość
wyszukiwania właściwej nazwy po dowolnych ciągach znaków dłuższych od 3
różnych od spacji (spacja jest separatorem rozdzielającym kolejne wyszukiwane
ciągi,
należy
wybierać
wszystkie
nazwy
zawierające
którykolwiek
z wprowadzonych ciągów).
1.2 „Dawka leku” – pole numeryczne, uzupełniane poprzez wpisanie na
klawiaturze ekranowej aplikacji SWD PRM przez użytkownika wartości – ilości
3. Wyniki
podanego leku np.: 1, 2, 10, 500, 1000, itp.
realizacji
1.3 „Jednostka miary” – pole słownikowe, inicjalnie zawierające wartości: mg, g,
zadania:
ml. Słownik będzie mógł być modyfikowany z interfejsu Administratora
Centralnego (dodatkowy słownik powiązany ze słownikiem leków). Wartości
nie będą zależne od wybranego leku ani weryfikowane przez System –
Użytkownik zawsze może wybrać dowolną z pozycji w polu jednostki miary.
1.4 „Droga podania” – pole słownikowe, do którego będą wprowadzane kody
(użytkownik powinien mieć możliwość zweryfikowania opisu dla kodu
w słowniku utrzymywanym przez Administratora Centralnego (słownik
dostępny z GUI Administratora). Początkowa lista wartości dla pola: „p. o.”, „s.
l.”, „p. r.”, „i. v.”, „i. m.”, „s. c.”, „droga wziewna”.
1.5 „Godzina podania” – pole złożone pozwalające na wpisanie dwóch wartości
numerycznych z klawiatury dla czasu w formacie: GG:MM lub poprzez
automatyczne wprowadzenie godziny przez użytkownika poprzez kliknięcie
przycisku, którego zadaniem będzie automatyczne pobranie godziny z aplikacji
SWD PRM.
W ramach wymagania należy zmodyfikować struktury danych przechowujące
informacje o KMCR (baza operacyjna serwerowa i lokalne, raportowa, archiwum),
GUI do wprowadzania danych, generowanie dokumentów drukowanych oraz ew.
raporty.
4. Kryteria
akceptacji
zadania:
str. 77 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
2. Opis
Nazwa wymagania: Baza szpitali
przedmiotu
Moduł Systemu: Aplikacja mobilna ZRM/Aplikacja MS ZRM
zadania:
Wprowadzenie w aplikacji mobilnej ZRM oraz aplikacji MS ZRM w KZW w części
dotyczącej realizacji zlecenia po wprowadzeniu przez użytkownika: „Udzielono pomocy
i przewieziono do”, po wyświetleniu ekranu wprowadzenia wymaganych dodatkowych
informacji, należy obecne pole tekstowe zamienić na pole słownikowane umożliwiające
użytkownikowi wybór ze słownika nazwy podmiotu leczniczego do jakiego został
przewieziony pacjent przez zespół ratownictwa medycznego.
3. Wyniki
realizacji
zadania:
1.1 W zależności od wybranego przez kierownika ZRM pola: IP/SOR, centrum
urazowe, jednostki wyspecjalizowane szpitala dla każdego z tych pól dostępny jest
oddzielny słownik. Oczekuje się rozwiązania z przypisaniem pozycji słownika do
poszczególnych pól KZW, poprzez dodanie do pozycji w słowniku wartości
logicznych wskazujących na zastosowanie przy właściwej pozycji w KZW, tj.
pozycja słownikowa, oprócz typowych dla słownika pól, powinna posiadać pola
odpowiadające IP/SOR, centrum urazowemu, jednostkom wyspecjalizowanym
szpitali, innym jednostkom oraz wskazanie na województwo, w którym znajduje się
dana jednostka.
1.2 Słownik podmiotów leczniczych powinien zawierać informacje o nazwie podmiotu
leczniczego, przypisaniu do właściwego rodzaju podmiotu leczniczego, zgodnie
z klasyfikacją w KZW oraz określenie województwa, w którym się znajduje.
1.3 W skład nazwy podmiotu leczniczego wchodzi nazwa świadczeniodawcy, ulica,
numer budynku, kod pocztowy, miejscowość. Wielkość pola przechowującego
nazwę podmiotu leczniczego powinna zostać dobrana tak, żeby nazwa pozwalała
na ujęcie tych informacji i mieściła się w formularzu KZW przy wydruku (jak
największa długość napisu możliwa do wydrukowania).
1.4 Wprowadzenie w aplikacji funkcjonalności realizującej wyszukiwanie pozycji
w słowniku nazw podmiotów leczniczych, zawierającej w opisie lub kodzie
którykolwiek z wyrazów o długości co najmniej 3 znaków (jako cały wyraz bądź
fragment wyrazu), wprowadzonych w polu edycyjnym do wprowadzenia
szukanego ciągu znaków z możliwością wyszukiwania w całym słowniku albo
wyłącznie w zakresie jednostek w województwie, do którego jest przypisany dany
ZRM (domyślnie wyszukiwanie w zakresie województwa).
1.4.1 Mechanizm wyszukiwania podmiotu leczniczego uruchamiany przyciskiem
lupy.
1.4.2 Algorytm wyszukiwania będzie identyfikował w polu szukanego ciągu znaków
wyrazy złożone z co najmniej 3 znaków (liter, cyfr bądź znaków specjalnych,
z wyjątkiem spacji). Poszczególne wyrazy będą oddzielone jedną bądź więcej
spacją.
1.5 Słownik nazw podmiotów leczniczych umożliwia jego aktualizację przez
administratora centralnego poprzez import z pliku CSV, wprowadzenie nowej albo
zmodyfikowanie istniejącej pozycji (w tym oznaczenie usunięcia/nieaktywności
pozycji) w słowniku z poziomu GUI Administratora Centralnego.
1.6 Import danych CSV podczas zmiany słownika nazw podmiotów leczniczych
skutkuje utworzeniem nowego słownika podmiotów leczniczych z zachowaniem
dotychczas wykorzystywanych nazw podmiotów leczniczych (z oznaczeniem, jako
nieaktywne) – dotyczy zgłoszeń obsłużonych.
1.7 Należy przewidzieć mechanizm automatycznej aktualizacji słownika w aplikacjach
ZRM przy uruchomieniu aplikacji. W przypadku, gdy w aplikacji ZRM pozostaje
zarejestrowana KZW z wpisem z nieaktualnej wersji słownika (pozycja oznaczona,
jako nieaktywna), należy zapewnić możliwość zapisania dokumentu
z nieaktualnym wpisem.
1.8 W przypadku próby zmiany wartości w zamkniętym dokumencie KZW, należy
zapewnić dostęp do aktualnego słownika, z możliwością wprowadzenia również
str. 78 z 82
XI 2015 r. – VI 2016 r.
wartości z listy nieaktywnych (historycznych) słowników podmiotów leczniczych.
1.9 W przypadku wyboru przez kierownika ZRM pola: „inne” należy uniemożliwić
użytkownikowi z poziomu aplikacji wprowadzanie nazw podmiotów leczniczych
spoza słownika (tekst niesformatowany, walidacja wyłącznie długości tekstu pod
kątem zamieszczenia w wydruku). W przypadku pozostałych rodzajów podmiotów
leczniczych, nie będzie możliwe wprowadzenie nazwy spoza słownika.
4. Kryteria
akceptacji
zadania:
str. 79 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
Nazwa wymagania: Automatyzacja wypełniania KZW – pacjent nie wyraża zgody na
2. Opis
przedmiotu udzielenie pomocy
Moduł Systemu: Aplikacja mobilna ZRM/Aplikacja MS ZRM
zadania:
Wprowadzenie usprawnienia w zakresie wypełniania Karty Zlecenia Wyjazdu przez
Kierownika zespołu ratownictwa medycznego.
3. Wyniki
realizacji
zadania:
1.1 W KZW w części: „III realizacja zlecenia” słownikowanie pola: „pacjent nie wyraża
zgody na udzielenie pomocy”.
1.2 W przypadku wyboru pola: „pacjent nie wyraża zgody na udzielenie pomocy”
rozwija się lista z następującymi polami do wyboru:
1.2.1 Pozostawiono w miejscu zdarzenia
1.2.2 Przekazano Policji
1.2.3 Przekazano Straży Miejskiej
1.2.4 Przekazano rodzinie
1.2.5 Przekazano opiekunowi prawnemu
1.2.6 Przekazano ochronie obiektu
1.2.7 Pacjent oddalił się z miejsca zdarzenia
1.2.8 Inne
1.3 Po wybraniu: „Inne” należy umożliwić wprowadzenie opisu z wykorzystaniem
klawiatury aplikacji w dodatkowym polu.
1.4 Wprowadzony opis o którym mowa w pkt. 5.3 w systemie widoczny jako: „Inne –
(opis wprowadzony przez użytkownika)”. Opis ten pozostaje tylko w wersji
elektronicznej KZW, nie ma odzwierciedlenia w drukowanej wersji KZW.
1.5 Pozycje do wyboru z listy wyświetlanej dla wskazanej pozycji braku zgody
pacjenta mają być przechowywane w tabeli słownikowej. Słownik umożliwia
aktualizację przez administratora centralnego poprzez import z pliku CSV,
wprowadzenie nowej albo zmodyfikowanie istniejącej pozycji w słowniku
z poziomu GUI Administratora Centralnego.
1.6 Import danych CSV podczas zmiany słownika skutkuje utworzeniem nowej wersji
całego słownika (oznaczenie dotychczasowych pozycji słownika, jako nieaktywne
– nie jest wymagane wersjonowanie z określeniem przedziału czasu ważności)z
zachowaniem dotychczas wykorzystywanych nazw – dotyczy obsłużonych
zdarzeń.
1.7 Należy przewidzieć mechanizm automatycznej aktualizacji słownika w aplikacji
ZRM przy uruchomieniu aplikacji. W przypadku, gdy w aplikacji ZRM pozostaje
zarejestrowana KZW z wpisem z nieaktualnej wersji słownika, należy zapewnić
możliwość zapisania dokumentu z nieaktualnym wpisem.
1.8 W przypadku prób zmiany wartości w zamkniętym dokumencie KZW z poziomu
interfejsu użytkownika o roli Analityk dysponenta, należy zapewnić dostęp do
aktualnego słownika, z możliwością wprowadzenia również wartości z listy
nieaktywnych (historycznych) słowników.
4. Kryteria
akceptacji
zadania:
str. 80 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
Nazwa wymagania: Implementacja ograniczenia dostępu do nagrań w zdarzeniu dla
2. Opis
przedmiotu nieuprawnionych użytkowników
zadania:
Wprowadzenie bezpośredniego interfejsu z Podsystemem Zintegrowanej Łączności
(PZŁ) w zakresie rejestrowania powiązania pomiędzy rozmową realizowaną poprzez
funkcję oddzwonienia do Wzywającego, pobierania nagrań powiązanych ze
Zdarzeniem oraz funkcjonalności ograniczenia dostępu do nagrań w zdarzeniu
wyłącznie do uprawnionych użytkowników Systemu. Usprawnienie procesu odsłuchu
nagrania podczas obsługi zdarzenia przez dyspozytora medycznego poprzez
rozdzielenie części nagrania zgłaszającego z operatorem numerów alarmowych oraz
nagrania zgłaszającego z dyspozytorem medycznym.
3. Wyniki
realizacji
zadania:
1.1 Rozszerzenie działania przycisku „Oddzwoń do Wzywającego” o żądanie nagrania
rozmowy i przekazanie PZŁ parametrów mówiących o powiązaniu realizowanego
połączenia z konkretnym Zdarzeniem (tym, z którego ekranu realizowane jest
oddzwonienie).
1.2 Modyfikacja działania funkcji pobrania nagrania Wzywającego z Dyspozytorem
w PRM dla Zdarzenia poprzez wprowadzenie dodatkowej bezpośredniej
komunikacji z systemem PZŁ w tym zakresie, z wykorzystaniem metod obecnie
wykorzystywanych w systemie dla CPR, jako dopełnienie pobierania nagrań
z Operatorem 112 za pośrednictwem systemu SI WCPR (w formatce).
1.3 W formatce zdarzenia modyfikacja działania obecnego przycisku: „Otwórz
oryginalną treść zgłoszenia” w następujący sposób:
1.3.1 Po kliknięciu w przycisk: „Otwórz oryginalną treść zgłoszenia” dyspozytor
medyczny ma możliwość odsłuchania wszystkich nagrań Z PRM i 112,
powiązanych z bieżącym zdarzeniem po stronie PZŁ, tj. nagrań rozmów
Wzywającego z Operatorem, Wzywającego z Dyspozytorami, Operatora
z Dyspozytorami, rozmów pomiędzy Dyspozytorami (do czasu zakończenia
pierwszego połączenia), nagrań Wzywającego w tle (podczas oczekiwania na
przełączenie) oraz rozmowy oddzwanianej.
1.3.2 W prezentowanej liście nagrań zostanie ujęta informacja o służbie
prowadzącej
rozmowę
(112
albo
PRM),
inicjującym
rozmowę
(Wzywający/PRM/112) oraz czasie rozpoczęcia połączenia.
1.3.3 Dyspozytor w PRM nie będzie miał dostępu do nagrań rozmów
prowadzonych przez pozostałe służby (Policja, PSP) w ramach obsługi
Zdarzenia
1.4 Odsłuch nagrań prowadzonych pomiędzy osobą zgłaszającą zarówno
z operatorem jak i dyspozytorem medycznym ogranicza się wyłącznie do
dyspozytorni medycznej, która na jakimkolwiek etapie obsługi Zdarzenia została
przypisana do niego w SWD PRM. W konsekwencji, w przypadku potrzeby
odsłuchania nagrania dla danego Zdarzenia, dyspozytor chcący odsłuchać takie
nagranie musi być przypisany do dyspozytorni, do której aktualnie bądź
w przeszłości było to zdarzenie przypisane, ew. musi przypisać zdarzenie do
swojej dyspozytorni, aby otrzymać dostęp do nagrań. Zmiana dyspozytorni wiąże
się z zapisaniem wersji Zdarzenia w Systemie wraz z autorem zmiany. Dla
użytkowników nieuprawnionych do odsłuchu nagrań (przypisanych do innych
dyspozytorni) przycisk dostępu do nagrań jest wyszarzony w ekranie szczegółów
Zdarzenia.
4. Kryteria
akceptacji
zadania:
str. 81 z 82
XI 2015 r. – VI 2016 r.
1. Identyfikator
zlecenia:
Nazwa wymagania: Historia aktywności stanowiska dyspozytorskiego (dodatkowy
2. Opis
przedmiotu raport)
Moduł Systemu: Moduł raportowy
zadania:
Raport obrazuje historię aktywności stanowiska dyspozytorskiego. Stworzony
predefiniowany raport w module raportowym uwzględnia następujące wartości:
1. województwo,
2. kod dyspozytorni medycznej,
3. okres sprawozdawczy (data od … – data do …, godzina od… – godzina do …),
4. liczba wszystkich stanowisk dyspozytorskich,
5. liczba
stanowisk
dyspozytorskich
przyjmujących
i liczba
stanowisk
wysyłających (jeśli jest),
6. średni czas obsługi zdarzenia w dyspozytorni medycznej (czas liczony od
przyjęcia zdarzenia przez dyspozytora medycznego do chwili zadysponowania
ZRM),
7. łączny czas przebywania na przerwie,
8. liczba automatycznych wylogowań z SWD PRM,
9. łączny czas niezalogowań w SWD PRM
3. Wyniki
1. Dane w SWD PRM powinny umożliwiać pozyskanie informacji dotyczącej historii
realizacji
aktywności stanowiska dyspozytorskiego w różnych konfiguracjach.
zadania:
2. Raport umożliwia monitorowanie aktywności pracy wszystkich dyspozytorów
medycznych zatrudnionych u dysponenta zespołów ratownictwa medycznego (w
tym średni czas obsługi zgłoszenia dyspozytora medycznego, łączny czas
przebywania na przewie – dodatkowy przycisk „+”, który zawiera informacje
o liczbie pobytów na przerwie oraz o wszystkich czasach rozpoczęcia i zakończenia
przerwy, liczba automatycznych wylogowani z SWD PRM – dodatkowy przycisk „+”,
który zawiera informacje o wszystkich czasach wylogowań oraz ponownych
zalogować do SWD PRM, łączny czas niezalogowania w SWD PRM).
3. Możliwość generowania raportu poprzez następujące filtry:
1. imię i nazwisko dyspozytora medycznego,
2. kod dyspozytora medycznego,
3. data od … – data do …,
4. godzina od … – godzina do …
4. Kryteria
akceptacji
zadania:
str. 82 z 82

Podsumowanie Prac Zespołu ds. Rozwoju SWD PRM

Transkrypt

Podobne dokumenty

b) maksymalny czas osiągnięcia pełnej gotowości do współpracy z

Drukuj do PDF - Ministerstwo Zdrowia

65 000 PLN brutto

CENTRUM SZKOLENIA POLICJI STRZELANIE

Yokogawa wprowadza Plant Resource Manager (PRM®) R3.30

ROLA DYSPOZYTORA POGOTOWIA RATUNKOWEGO PRZY

PM-17/RM 1. Celem Procedury jest: 1.1. Ujednolicenie zasad

pobierz - Radiotechnika Marketing

PRM-1 - PSSE Grodzisk Mazowiecki