Zintegrowany System Dowodzenia Dokument wizji

Transkrypt

1 Gliwice Zintegrowany System Dowodzenia Dokument wizji Laboratorium Analizy i Projektowania Systemów Informatycznych Wersja 1.0

2 Spis treści 1. Wprowadzenie Cele dokumentu wizji Zakres Definicje, akronimy Założenia projektu Cele biznesowe Sformułowanie problemu Opis zamawiającego i użytkowników systemu Opis zamawiającego Użytkownicy systemu Środowisko użytkowania Profile użytkowników Kluczowe potrzeby zamawiającego oraz użytkowników Opis produktu Niezależnośd produktu Podsumowanie możliwości Koszty Licencjonowanie Możliwości produktu Funkcjonalności dostępne dla operatora Funkcjonalności dostępne dla dyspozytora Funkcjonalności dostępne dla kierownika zespołu Funkcjonalności dostępne dla administratora Ograniczenia Ramy jakościowe Priorytety systemu Inne wymagania Wymagania systemowe Wymagania wydajnościowe Wymagana dokumentacja Instalacja... 8

3 1. Wprowadzenie 1.1 Cele dokumentu wizji Celem dokumentu jest zebranie, analiza i definicja cech zintegrowanego systemu dowodzenia. 1.2 Zakres Dokument ten przedstawia założenia systemu dowodzenia dla jednostek Pogotowia Ratunkowego. Zawarto w nim postawione przed projektem wymagania, zidentyfikowano problemy oraz zaproponowano sposób ich rozwiązania 1.3 Definicje, akronimy ZRM zespół ratownictwa medycznego NFZ Narodowy Fundusz Zdrowia 2. Założenia projektu 2.1. Cele biznesowe System ma za zadanie ułatwid komunikację dyspozytora z zespołem ratownictwa medycznego, poprzez automatyzację i unifikację tego procesu. Zakłada się również archiwizację każdych danych związanych z obsługą zgłoszeo i zdarzeo oraz możliwośd sprawozdawczości dla organu zarządzającego jednostką pogotowia ratunkowego. 2.2 Sformułowanie problemu Brak ustandaryzowanego modelu obsługi działao ratunkowych, negatywnie wpływa na pracę jednostek pogotowia ratunkowego. Powoduje to chaotycznośd działao oraz niedokładnośd zebranych informacji. W obecnej chwili dane przechowywane w formie papierowej nie pozwalają na łatwe przeszukiwanie oraz ich składowanie. Udanym rozwiązaniem przedstawionego problemu będzie system wymuszający odpowiednią kolejnośd podejmowanych działao, zbierając i dostarczając użytkownikom wszelkich niezbędnych informacji. Dane o zrealizowanych zgłoszeniach będą łatwo dostępne z poziomu systemu, co usprawni sprawozdawczośd oraz zaoszczędzi zasobów magazynowych do ich przechowywania w formie papierowej. 3. Opis zamawiającego i użytkowników systemu 3.1. Opis zamawiającego Typ: Jednostka Pogotowia Ratunkowego Reprezentuje: Bielskie Pogotowie Ratunkowe Rola: Określenie wymagao funkcjonalnych i niefunkcjonalnych 3.2 Użytkownicy systemu

4 Operator osoba przyjmująca zgłoszenie, przeprowadzająca wywiad ze zgłaszającym oraz podejmująca decyzję o przekazaniu do realizacji. Dyspozytor przydziela zespoły do realizacji zdarzenia. Kierownik ZRM wypełnia kartę wyjazdową, która jest podstawą do rozliczenia z NFZ. Administrator zarządza użytkownikami, wprowadza wartości słownikowe ora zajmuje się utrzymaniem systemu 3.3 Środowisko użytkowania System będzie się składał ze stanowisk: Operatorskiego stanowisko z telefonem, na którym operator będzie przyjmował zgłoszenia od potencjalnych pacjentów Dyspozytorskiego służącego do przydzielania zespołów i śledzenia podejmowanych przez nie działao Stanowiska ZRM do tworzenia zespołów, potwierdzania przyjęcia dyspozycji wyjazdu, wypisywania kart wyjazdowych oraz potwierdzania zakooczenia obsługi. Do obsługi zgłoszenia w zależności od decyzji operatora o podjęciu działao, zaangażowanych jest od jednej do 2+n osób, gdzie n to liczba wyjazdów ZRM. System powinien byd odporny na możliwe braki dostępu do sieci. Tworzony produkt powinien integrowad się z istniejącym systemem informatycznym wojewódzkich centrów powiadamiania ratunkowego. 3.4 Profile użytkowników Użytkownik Typ Obowiązki Kryteria sukcesu Operator Dyspozytor Kierownik ZRM Osoba oswojona z komputerem Osoba oswojona z komputerem Osoba oswojona z komputerem Przyjmowanie zgłoszeo, przekazywanie ich do realizacji Wybór zespołów do obsługi zdarzenia Wypełnianie kart wyjazdowych, tworzenie własnego zespołu Uproszczenie procesu przyjmowania zgłoszeo Ciągły dostęp do informacji o gotowości zespołów i działaniach przez nich podejmowanych Szybkie i wygodne wprowadzanie danych na temat przebiegu wyjazdu Zaangażowanie Określa, które czynności przysparzają mu najwięcej problemów Określa, które czynności przysparzają mu najwięcej problemów Określa, które czynności zajmują mu najwięcej czasu Administrator Osoba Wprowadzenia Niezawodnośd Wskazuje

5 posiadająca rozległą wiedzę informatyczną użytkowników do systemu, zarządzanie danymi słownikowymi, opieka nad systemem systemu konfigurowalne elementy systemu 3.5 Kluczowe potrzeby zamawiającego oraz użytkowników Potrzeba Priorytet Aktualne rozwiązanie Proponowane rozwiązanie danych o zgłoszeniach informacji o wyjazdach Informacja o stanie i gotowości zespołów do podjęcia działao Wysoki Wysoki Wysoki Dane o odebranych telefonach nie są przechowywane. Dane są przechowywane w księdze dyspozytora. Informacje o czasie przyjęcia do realizacji, wydania decyzji są wypisywane ręcznie Zespoły poprzez system radiowy informują o swojej gotowości dyspozytora danych Wysoki Dane są przechowywane w formie papierowej Sprawozdawczośd Wysoki Rozliczenia z NFZ na podstawie papierowych kart. informacji o pracownikach Magazyn sprzętów jednostki Średni Średni Dane przechowywane w papierowych dokumentach albo w dziale kadr danej placówki Brak jednoznacznego miejsca w którym można uzyskad informacje o System automatycznie będzie tworzyd zgłoszenie po odebraniu telefonu. Operator będzie mógł takie zgłoszenie odrzucid jednakże informacja o nim będzie zapisana w systemie System za użytkownika zbierze odpowiednie czasy i zapisze je do zgłoszenia. Odpowiednio oznaczy pola, które należy wypełnid Dyspozytor z poziomu systemu będzie miał dostępne informacje o statusach zespołów oraz ich gotowości do podjęcia działao. Cała procedura przekazania zdarzenia odbywad się będzie bez wykonywania połączeo głosowych Dane przechowywane w bazie danych Wprowadzone dane do systemu pozwolą na automatyczne tworzenie rozliczeo z NFZ System przechowuje informacje o wszystkich pracownikach pogotowia informacji o dostępnym sprzęcie w bazie danych

6 dostępnym sprzęcie jednostki 4. Opis produktu 4.1 Niezależnośd produktu Tworzony produkt będzie systemem pozwalającym na niezależne działanie. Jego architektura będzie przygotowana na dodanie nowych, nieokreślonych na chwilę obecną interfejsów służących do integracji z systemami, które powstaną w przyszłości. Na chwilę obecną system zakłada integrację z SIWCPR zgodnie z wymaganiami opisanymi przez ten system, co nie jest częścią tworzonego produktu. 4.2 Podsumowanie możliwości Główną zaletą zintegrowanego systemu dowodzenia jest automatyzacja i przyspieszenie procesu obsługi wyjazdów ratunkowych. Każda czynnośd jest archiwizowana co pozwala na odtworzenie podjętych kroków od momentu odebrania zgłoszenia do jego zakooczenia. Zebrane w systemie informacje o pracownikach pogotowia pozwalają na łatwe tworzenie zespołów wyjazdowych, bez obawy, że w zespole zabraknie odpowiedniego specjalisty. Wirtualny magazyn sprzętu usprawni zarządzanie zasobami pogotowia, sprawiając je bardziej efektywnym. Automatycznie generowane raporty dla NFZ, pozwolą zaoszczędzid czas, a walidacja danych uchroni klienta przed odrzuceniem jego sprawozdania, co pozwoli zachowad płynnośd finansową. 4.3 Koszty Sprzęt zostanie w odpowiedni sposób skonfigurowany i dostarczony przez wykonawcę projektu. Koszt przygotowania jednego stanowiska to złotych. Cena zwiera koszty stworzenia odpowiedniej infrastruktury sieciowej. 4.4 Licencjonowanie Licencja na produkt jest dostarczana na ograniczoną liczbę komputerów. Cena licencji obejmującej dwanaście stacji to złotych. 5 Możliwości produktu 5.1 Funkcjonalności dostępne dla operatora Przyjmowanie zgłoszenia z automatycznym wypełnianiem wymaganych przez organ nadzorujący czasów oraz zaznaczaniem wymaganych pól Możliwośd odrzucenia zgłoszenia, jeśli takowe jest złośliwe Możliwośd przekazania zgłoszenia do realizacji Przeglądanie zgłoszeo Odsłuchiwanie archiwalnych rozmów

7 5.2 Funkcjonalności dostępne dla dyspozytora Przeglądanie dostępnych zespołów i danych na ich temat Przydzielanie zespołów do realizacji zdarzenia Podgląd stanu realizacji wyjazdu Dodawanie kolejnych wyjazdów do zdarzenia Podgląd statusów zespołów Przeglądanie zdarzeo Dodawanie zdarzeo zaplanowanych Tworzenie wyjazdów komercyjnych Tworzenie wyjazdów transportowych 5.3 Funkcjonalności dostępne dla kierownika zespołu Wypełnianie elektronicznej karty wyjazdowej Zaznaczenie pól wymaganych przez organ nadzorujący do zakooczenia realizacji wyjazdu Przeglądanie wypełnionych kart Potwierdzenie zakooczenia wyjazdu Tworzenie zespołu 5.4 Funkcjonalności dostępne dla administratora Dodawanie, modyfikacja i usuwanie użytkowników Zarządzanie danymi słownikowymi Nadawanie uprawnieo Przegląd danych raportowych Generowanie raportów Zarządzanie dostępnym sprzętem pogotowia 6. Ograniczenia Dostęp do danych objętych ochroną prawną powinien byd monitorowany oraz wprowadzane zmiany powinny byd rejestrowane. NFZ nakłada na pogotowie ratunkowe wiele ograniczeo prawnych. Zespół może się składad z maksymalnie 4 osób. Każdy zespół musi posiadad kierownika oraz osobę kierującą pojazdem. Karty wyjazdowe muszą byd zgodne ze wzorem dostarczonym z Ministerstwa Zdrowia. Każdy wyjazd powinien mied odnotowany czas przyjęcia zgłoszenia, wyjazdu, dotarcia na miejsce oraz zakooczenia realizacji. 7. Ramy jakościowe Interfejs użytkownika powinien byd łatwy i intuicyjny. Wymaga się aby system nie stwarzał trudności w obsłudze przeciętnemu użytkownikowi komputera.

8 Ze względu na sztywne ramy czasowe wykonywania obsługi zgłoszeo system powinien działad nieprzerwanie z maksymalną wydajnością uwzględniając maksymalne obciążenie. Maksymalny czas przerwy w działaniu systemu to 0,5% w skali miesiąca. Zakłada się wykonywanie okresowych kopii zapasowych bazy danych. 8. Priorytety systemu Realizację projektu należy rozpocząć od implementacji funkcjonalności związanych z przyjęciem zgłoszenia. Kolejnym etapem będzie jego obsługa. Następne działania będą obejmować możliwość stworzenia zespołu oraz zadysponowania go do obsługi zdarzenia z przyjętego zgłoszenia. Funkcjonalności związane z administracją mają najmniejszy priorytet. 9. Inne wymagania 9.1 Wymagania systemowe System operacyjny: Microsoft Windows 7 Enterprise Edition Dostęp do sieci intranet 4 GB pamięci RAM Dysk 250 GB Procesor: Intel Core i7 Trzy monitory 22 UPS Adobe Reader, Java 1.6, Skype 9.3 Wymagania wydajnościowe Sied intranet 100 mb Średni czas odpowiedzi hosta z serwerem aplikacji: 5ms 10. Wymagana dokumentacja Model klas Model przypadków użycia Scenariusze przypadków użycia Diagram aktywności Diagram sekwencji 10.3 Instalacja Wykonawca zobowiązuje się dostarczyć skonfigurowane stacje robocze