Jak uporządkować codzienną pracę pogotowia bez papierowego obiegu? – WSPR Zielona Góra case study
Codzienna praca stacji pogotowia ratunkowego to nie tylko wyjazdy do pacjentów. To również harmonogramy, obowiązkowe czynności wykonywane na dyżurze, dokumentacja pojazdów i stan sprzętu, którym dysponują zespoły ratownictwa medycznego.
Przez lata duża część tych czynności wykonywana była manualnie. Na karteczkach. Każda z nich z osobna wydaje się drobiazgiem. Razem tworzą obieg informacji, w którym łatwo o niedociągnięcie. Ktoś komuś czegoś nie powiedział, ktoś czegoś nie przekazał dalej i informacja, która była potrzebna od razu, dociera z opóźnieniem albo wcale.
Wojewódzka Stacja Pogotowia Ratunkowego SP ZOZ w Zielonej Górze potrzebowała rozwiązania, które zbierze te czynności w jednym miejscu i przeniesie je do systemu. Odpowiedzią była dedykowana aplikacja stworzona przez GAMP.
Zobacz, jak o systemie mówi zespół WSPR w Zielonej Górze.
Spis treści
1. Wyzwanie
Celem stworzenia aplikacji było przede wszystkim uporządkowanie codziennej pracy pogotowia. Wiele czynności wykonywanych było manualnie, na karteczkach. Głównym założeniem stało się więc zebranie wszystkich tych operacji w jednym miejscu i umożliwienie pracy przy wykorzystaniu systemu.
Drugim istotnym elementem była dostępność wielu narzędzi w jednej aplikacji. Nie chodziło o zdigitalizowanie pojedynczego dokumentu, tylko o to, żeby wszystko, z czego zespół korzysta na dyżurze, znajdowało się w tym samym miejscu. Harmonogram to jedno z tych narzędzi. Obok niego karty obowiązkowych czynności oraz karty drogowe.
Trzecim wyzwaniem był przepływ informacji między ludźmi. W papierowym obiegu wiedza o tym, że jakiś sprzęt uległ awarii albo wymaga poprawy, przekazywana jest ustnie — a więc zależy od tego, czy ktoś zdążył, pamiętał i trafił na właściwą osobę. W pracy pogotowia taka luka ma realne znaczenie.
Czwartym elementem była specyfika samej organizacji. Procesy pracy pogotowia są dosyć specyficzne. Gotowe rozwiązania dostępne na rynku wymagałyby dostosowania do nich istniejących procesów, czyli kompromisu po stronie stacji. Dlatego wybór padł na system dedykowany.
2. Rozwiązanie
Tak powstał ControlER, czyli aplikacja, która zbiera w jednym miejscu narzędzia używane w codziennej pracy zespołów ratownictwa medycznego.
W systemie dostępne są między innymi:
- harmonogram,
- karty obowiązkowych czynności.
- karty drogowe,
- informacje o sprzęcie i pojazdach,
- zgłoszenia usterek.
Karty drogowe wypełniają ratownicy, którzy mają uprawnienia do kierowania pojazdami uprzywilejowanymi. Wcześniej był to kolejny dokument w papierowym obiegu, dziś powstaje w tym samym systemie, co reszta. Ważna jest nie tylko zawartość aplikacji, ale też sposób, w jaki można z niej korzystać. Zalogować się można z komputera stacjonarnego, z komputera w każdej dyżurce zespołu ratownictwa, a także przez telefon, za pomocą smartfona. Ratownik nie musi więc wracać do konkretnego pomieszczenia ani czekać na dostęp do jednego stanowiska.
Osobnym elementem systemu jest obsługa usterek. W każdym momencie dyżuru ratownicy mogą wejść w program i odklikać, co jest uszkodzone. Nie wymaga to znalezienia właściwej osoby ani odkładania sprawy na koniec zmiany. Zgłoszenie nie zostaje w systemie bezczynnie. Aplikacja automatycznie powiadamia o nim mailem, z informacją, że na danym zespole i na konkretnym pojeździe jest coś do naprawienia bądź do poprawienia. To właśnie ten mechanizm zamyka lukę opisaną w sekcji Wyzwanie. Informacja nie przechodzi już z rąk do rąk. Trafia dalej sama, razem z kontekstem: kogo i czego dotyczy.
ControlER pracuje w Data Center GAMP. Stacja nie musiała więc przygotowywać własnej infrastruktury pod nowy system ani dzielić odpowiedzialności między dostawcę oprogramowania a dostawcę środowiska, w którym to oprogramowanie działa.
Skończyła się era papierkowej roboty. Mamy teraz wszystko dostępne w jednym miejscu i tak naprawdę możemy zalogować się w komputerze stacjonarnym, w komputerze, w każdej dyżurce zespołu ratownictwa, bądź też przez telefon za pomocą smartfona.
3. Współpraca
Wybór GAMP wynikał z historii, która zaczęła się na długo przed tym projektem. Obie strony współpracują ze sobą od wielu lat i ta współpraca zawsze układała się dobrze, z możliwością liczenia na wsparcie w każdym momencie.
Po stronie GAMP projekt prowadził zespół w składzie: project manager, scrum master, developerzy i UX designer. Prace zaczęły się od analizy. Na jej podstawie powstały makiety aplikacji, dzięki nim układ ekranów i sposób pracy w systemie można było zobaczyć i omówić, zanim powstała pierwsza linia kodu.
Kolejne etapy to wdrożenie, testy i uruchomienie systemu. Po uruchomieniu projekt przeszedł w tryb utrzymania i pozostaje pod opieką tego samego zespołu, który go zbudował. Sam proces powstawania programu wymagał jednak czegoś więcej niż harmonogramu etapów. Wymagał elastyczności po obu stronach: ustalania, na co można się zgodzić, i wyjścia trochę poza własną strefę komfortu, żeby dopiąć wszystko na ostatni guzik.
To dość typowe dla projektów dedykowanych. System, który ma odwzorować realne procesy organizacji, powstaje w rozmowie, a rozmowa oznacza, że obie strony czasem zmieniają zdanie.
Dlaczego GAMP? Dlatego, że współpracujemy od wielu, wielu lat. Ta współpraca zawsze układa nam się bardzo dobrze. Możemy liczyć na wsparcie w każdym momencie. Nawet proces tworzenia samego programu pokazał, jak mocno potrafimy być w stosunku do siebie elastyczni, na co możemy się zgodzić, na co firma nam pozwoliła. Jakby wyjść troszeczkę ze swojej strefy komfortu, żeby dopiąć wszystko na ostatni guzik.
4. Korzyści
Wdrożenie aplikacji zmieniło sposób, w jaki w stacji krąży informacja o codziennej pracy zespołów.
Koniec papierkowej roboty
Czynności, które wcześniej wykonywano manualnie i notowano na karteczkach, wykonywane są dziś w systemie. Wszystko jest dostępne w jednym miejscu, a nie rozproszone po dokumentach, które trzeba najpierw znaleźć.
Dostęp z komputera i ze smartfona
Do aplikacji można zalogować się z komputera stacjonarnego, z komputera w każdej dyżurce zespołu ratownictwa oraz przez telefon. Dzięki temu korzystanie z systemu nie wymaga zmiany rytmu pracy. Ratownik używa go tam, gdzie akurat jest, i w momencie, w którym potrzebuje.
Informacja, która nie zależy od przekazania jej dalej
Wcześniej wiedza o awarii sprzętu przechodziła ustnie. Wystarczyło, że ktoś komuś nie powiedział albo nie przekazał, i sprawa czekała. Dziś ratownicy w każdym momencie dyżuru mogą wejść w program i odklikać, co jest uszkodzone. Zgłoszenie zostaje zapisane niezależnie od tego, kto akurat jest na zmianie.
Automatyczne powiadomienie o usterce
System powiadamia mailem, że na danym zespole i na konkretnym pojeździe jest coś do naprawienia bądź do poprawienia. Powiadomienie zawiera więc od razu to, co jest potrzebne do reakcji: którego zespołu dotyczy, którego pojazdu i czego konkretnie. Nie trzeba dopytywać ani szukać kontekstu.
Rozwiązanie dopasowane do procesów
Rozwiązania dedykowane pozwalają w pełni odpowiedzieć na potrzeby klienta i nie wymagają pójścia na kompromisy ani dostosowywania aktualnych procesów do tego, co jest dostępne na rynku. W przypadku pracy pogotowia, gdzie procesy są dosyć specyficzne, ma to szczególne znaczenie. Gotowy produkt trzeba by najpierw naciągnąć na organizację, albo organizację na produkt.
