Silnik ostrzegania przed sepsą firmy Epic oblał walidację przeprowadzoną w 2021 roku w Michigan Medicine, nie wykrywając dwóch trzecich pacjentów, u których później rozwinęła się sepsa, podczas gdy alarm uruchamiał w 18% wszystkich przyjęć. Ten błąd wynika z klasycznego problemu wycieku danych (data leakage): model uznał zlecenie antybiotyku przez lekarza — będące już sygnałem podejrzenia infekcji — za czynnik predykcyjny, w zasadzie powielając decyzję, którą klinicysta już podjął.

Dlaczego model zawiódł

Zespół z Michigan przeanalizował 38 455 pobytów w szpitalu, co odpowiada skali typowego, wieloletniego projektu doskonalenia jakości. Wewnętrzne punkty odniesienia (benchmarks) firmy Epic obiecywały wysoką dokładność, ale niezależny test wykazał coś przeciwnego. Alerty „wysokiego ryzyka” generowane przez model pojawiały się u niemal jednej piątej pacjentów, podczas gdy dwie trzecie rzeczywistych przypadków sepsy przeszły niezauważone. W praktyce system zbyt często krzyczał „uwaga”, jednocześnie pomijając zdarzenia, które miał wykrywać.

Przyczyną nie była wada samego algorytmu uczenia maszynowego, lecz dane, które do niego wprowadzono. Wykorzystując obecność zlecenia antybiotyku jako dane wejściowe, model nauczył się przewidywać decyzję, którą klinicysta już podjął. Gdy algorytm flagował pacjenta, często działo się to dlatego, że lekarz już zlecił antybiotyk, a nie dlatego, że fizjologia pacjenta wskazywała na nadchodzącą sepsę.

Szerszy problem w sztucznej inteligencji w szpitalach

Model sepsy firmy Epic jest wdrażany w setkach szpitali od lat, jednak błąd wycieku danych pozostawał ukryty, dopóki ukierunkowane działania walidacyjne go nie ujawniły. Ten incydent ilustruje systemową słabość: większość projektów AI w systemach ochrony zdrowia nie posiada kontroli operacyjnych niezbędnych do wczesnego wykrycia takich problemów.

  • Brak zewnętrznych testów – Szpitale nie przeprowadzały zewnętrznych testów.
  • Brak ciągłego monitorowania – Nie prowadzono monitorowania.
  • Brak jasnej odpowiedzialności – Bez wyznaczonego zespołu odpowiedzialnego za jakość danych i wydajność modelu, problemy umykają uwadze.

Te luki sprawiają, że wiele inicjatyw AI utyka w „pułapce projektów pilotażowych”, nigdy nie wychodząc poza etap dowodu koncepcji (proof-of-concept).

Ukryty koszt rozproszonych danych

Przypadek sepsy pokazuje również, jak pofragmentowane ekosystemy IT w ochronie zdrowia sabotują sztuczną inteligencję. Typowe przeszkody obejmują:

  • Dokumentację pacjentów uwięzioną w przestarzałych modułach EHR, które nie wymieniają danych automatycznie.
  • Systemy obrazowania i laboratoryjne, które nie potrafią ze sobą współpracować, co wymusza ręczne przesyłanie plików.
  • Duplikujące się identyfikatory pacjentów, które rozdzielają dane jednej osoby na wiele kart.
  • Notatki kliniczne i parametry życiowe przechowywane w oddzielnych silosach, które nigdy nie są łączone na potrzeby trenowania modelu.

Gdy model jest trenowany na czystym, wyselekcjonowanym zbiorze danych, a następnie otrzymuje rzeczywiste, nieuporządkowane dane, jego wydajność po cichu spada. Klinicyści szybko tracą zaufanie; pielęgniarka, która musi śledzić alerty na wielu ekranach, będzie je ignorować, nawet jeśli sam algorytm jest technicznie poprawny.

Cztery „nudne” fundamenty niezawodnej AI

Funkcjonalne wdrożenie AI opiera się na czterech praktycznych zdolnościach, które rzadko trafiają na nagłówki gazet:

  1. Interoperacyjność – Dane muszą przepływać między systemami EHR, laboratoriami, platformami obrazowania i narzędziami wspomagania decyzji bez konieczności ręcznego eksportu i importu.
  2. Governance (Zarządzanie) – Odpowiedzialna osoba lub zespół musi czuwać nad jakością danych i monitorować wyniki modelu w czasie.
  3. Integracja z procesem pracy – Alerty muszą pojawiać się w istniejącej kolejce zadań klinicysty; dodatkowe kliknięcia lub ekrany zabijają adopcję systemu.
  4. Skalowalna operacyjność – Zautomatyzowane monitorowanie, analiza zmęczenia alertami oraz cykliczne potoki (pipelines) dotrenowywania modelu są niezbędne, zanim model trafi do fazy produkcyjnej.

Pominięcie któregokolwiek z tych kroków naraża projekt na tego typu cichą awarię, jaką zaobserwowano w modelu sepsy firmy Epic.

Pytania, które warto zadać przed zakupem rozwiązania AI

Szpitale mogą uniknąć kosztownych błędów, żądając konkretnych odpowiedzi:

  • Czy potraficie prześledzić dane pojedynczego pacjenta we wszystkich systemach, których będzie używał model?
  • Kto, konkretnie (z imienia i nazwiska), odpowiada za utrzymanie jakości danych i nadzór nad wydajnością modelu?
  • Czy alerty zostały przetestowane z klinicystami podczas realnej zmiany, a nie tylko w środowisku testowym (sandbox)?
  • Czy istnieje udokumentowany plan monitorowania, który określa, w jaki sposób zostanie zidentyfikowany i rozwiązany dryft wydajności?

Jeśli dostawca nie potrafi wskazać osoby, procesu lub pulpitu nawigacyjnego do monitorowania, organizacja powinna wstrzymać się z decyzją i dokonać ponownej oceny.

Wnioski

Model sepsy Epic nie zawiódł dlatego, że uczenie maszynowe nie nadaje się do szpitali; zawiódł, ponieważ brakowało towarzyszącego mu potoku danych i struktur zarządzania. Model, który przewiduje decyzję samego lekarza, stanowi ostrzeżenie, że to warstwa inżynierii danych, a nie algorytm, wymaga dopracowania. Budowanie godnej zaufania sztucznej inteligencji w ochronie zdrowia wymaga tej samej „nudnej” infrastruktury, która zapewnia działanie każdego krytycznego systemu IT: czystych, połączonych danych, jasnej odpowiedzialności, alertów zintegrowanych z procesami pracy oraz proaktywnego monitorowania. Bez tego nawet najbardziej zaawansowany model będzie ostatecznie generował błędne ostrzeżenia dla niewłaściwych osób.