Błąd w systemie rozliczeniowym szpitala, którego nikt nie zauważył przez trzy tygodnie

Wprowadzenie

Wiosną ubiegłego roku regionalny system szpitalny na Środkowym Zachodzie wdrożył poprawkę dotyczącą harmonogramów w ramach standardowego procesu wprowadzania zmian. Nie było to nic nadzwyczajnego — rutynowa aktualizacja synchronizacji godzin wypisów ze szpitala z modułem rozliczeniowym. Trzy tygodnie później pracownik działu należności zauważył grupę odrzuconych wniosków o zwrot kosztów z powodu niezgodności znaczników czasu. Zanim dział IT zidentyfikował przyczynę, poprawka wpłynęła na wnioski ubezpieczeniowe dotyczące ponad czterystu pacjentów. Nikt nie popełnił żadnego błędu. Aktualizacja przeszła pomyślnie wszystkie testy z listy kontrolnej. Po prostu nie była to właściwa lista kontrolna.

Ta historia utkwiła mi w pamięci, ponieważ tak naprawdę nie dotyczy szpitali. Chodzi o to, co się dzieje, gdy systemy działające po cichu w tle organizacji są traktowane jak gotowe produkty, a nie jako żywa infrastruktura wymagająca regularnej kontroli.

Automatyzacja, którą wdrożyłeś dwa lata temu, nie jest tą automatyzacją, za jaką ją uważasz

Większość firm tworzy swoje pierwsze automatyzacje przepływu pracy, aby rozwiązać konkretny, widoczny problem. Zespół HR ma dość ręcznego przekazywania wniosków o urlop. Pracownik działu operacyjnego sprzedaży automatyzuje przydzielanie potencjalnych klientów, aby przedstawiciele handlowi przestali wybierać tylko najlepsze zlecenia. Są one tworzone za pomocą narzędzi do automatyzacji podobnych do Power Automate — szybkich w konfiguracji, łatwych do przekazania każdemu, kto zechce się nimi zająć, i w dużej mierze niewidocznych, gdy już działają.

Problem polega na tym, że „gdy już zaczną działać”, stają się trwałe. Nikt nie planuje ich przeglądu. Osoba, która je stworzyła, zmienia zespół lub odchodzi. Tymczasem otoczenie biznesowe ulega zmianom – pojawiają się nowe pola w systemie CRM, zmienia się hierarchia zatwierdzania, dochodzi do fuzji, która podwaja przepływ danych w systemie zaprojektowanym na połowę obciążenia. Automatyzacja nadal działa dokładnie tak, jak została zaprojektowana, i właśnie w tym tkwi problem. Została zaprojektowana dla firmy, która już nie istnieje w tej samej postaci.

Widziałem, jak firma logistyczna odkryła, że zautomatyzowany przepływ obsługi wyjątków działał nieprawidłowo przez jedenaście miesięcy, ponieważ dostawca zmienił nazwę pola w API. Jakie było obejście? Ktoś ręcznie ponownie wprowadzał nieudane przypadki, nie informując o tym nikogo, zakładając, że to jednorazowa sytuacja. To nie jest awaria narzędzia. To organizacyjna porażka polegająca na braku ponownego sprawdzenia czegoś, co wszyscy uważali za stabilne.

Szpitale ponoszą to samo ryzyko, ale stawka jest znacznie wyższa

Weźmy ten sam schemat i umieśćmy go w środowisku klinicznym i administracyjnym szpitala, a margines błędu drastycznie się zmniejszy. W tworzeniu oprogramowania szpitalnego zazwyczaj priorytetem jest zgodność z przepisami i ciągłość działania, a nie elastyczność — co jest zrozumiałe, biorąc pod uwagę, że nieudane wdrożenie może oznaczać, że pielęgniarka nie będzie mogła wyświetlić historii leczenia o 2 w nocy. Jednak ta sama ostrożność sprawia, że starsze systemy często pozostają w użyciu znacznie dłużej, niż powinny, i są raczej łatanie, a nie przebudowywane, ponieważ nikt nie chce być tym, który zepsuje coś, co ma kluczowe znaczenie.

W rezultacie powstaje architektura, w której gromadzą się decyzje, o których nikt już nie pamięta. Moduł planowania komunikuje się z modułem rozliczeniowym poprzez integrację stworzoną w 2016 roku dla dostawcy, z którego usług szpital zrezygnował w 2019 roku. W większości przypadków nadal działa. Jednak „w większości” to nie jest słowo, którego chcesz używać w kontekście danych pacjentów.

Powoli zmienia się jednak świadomość, że odporność w informatyce medycznej nie polega na unikaniu zmian — chodzi o budowanie systemów na tyle elastycznych, by mogły one dostosowywać się do zmian bez konieczności cudu za każdym razem, gdy zmieniają się przepisy lub dodawany jest nowy moduł elektronicznej dokumentacji medycznej.

Dlaczego podejście „jeśli coś nie jest zepsute” jest błędne

Oto sedno obu scenariuszy: systemy nie były zepsute. Działały dokładnie tak, jak zostały skonfigurowane. Właśnie dlatego nikt się nimi nie interesował.

Zepsute systemy z definicji przyciągają uwagę – ktoś zgłasza skargę, coś się zatrzymuje, zgłaszane jest zgłoszenie serwisowe. Niebezpieczne są te systemy, które na pozór działają bez zarzutu, a jednocześnie po cichu tracą synchronizację z rzeczywistymi potrzebami organizacji. Automatyzacja przepływu pracy, która nadal działa, ale kieruje zadania do niewłaściwego działu. Interfejs szpitalny, który nadal przesyła dane, ale usuwa pole, od którego zależy teraz system znajdujący się dalej w łańcuchu.

Audyt nie jest efektowny, ale alternatywa też nie jest

Rozwiązanie nie jest skomplikowane w teorii, choć w praktyce bywa żmudne: zaplanuj okresowe przeglądy wszystkiego, co działa bez nadzoru, niezależnie od tego, jak dobrze funkcjonowało w przeszłości. Zapytaj, kto jest za to obecnie odpowiedzialny. Zapytaj, co zmieniło się na wyższych i niższych szczeblach od czasu jego stworzenia. Zapytaj, czy ktokolwiek zauważyłby, gdyby jutro po cichu przestało działać.

Większość organizacji pomija ten etap, ponieważ wydaje się to raczej konserwacją niż postępem, a konserwacja rzadko otrzymuje budżet lub pochwały. Jednak koszt pominięcia tego etapu nie znika — po prostu czeka w ciszy na moment, w którym ktoś z działu księgowości zauważy, że liczby się nie zgadzają.