B2B: Projektowanie nowego parametru klinicznego do monitora OIOM: interfejs RFP, scenariusze bezpieczeństwa i dokumentacja gotowa na ocenę ryzyka
O projekcie
Przegląd projektu
Rola: Senior Product Designer / inżynier użyteczności w Philips (ponad 10 lat doświadczenia w UX)
Przełożyłem wymagania kliniczne i inżynieryjne na kompletne przepływy pracy użytkownika, które mogą zostać ocenione przez zespoły Ryzyka + Kliniczny + Inżynierii.
Zdefiniowałem różnice scenariuszy specyficzne dla RFP (co jest naprawdę nowe, a co odziedziczone po SpO₂).
Produkt: Monitorowanie pacjenta przy łóżku Philips (możliwości platformy IntelliVue/Delta)
Obszary skupienia:
Przepływy monitorowania SpO₂ (zakładanie czujnika, wybór źródła/etykiety, ustawienia alarmów)
Przepływy pomiaru temperatury ciągłej (ContTemp) (inteligentny kabel + sondy, różnica dwóch temperatur)
RFP (Respiration From Pleth) jako parametr wyprowadzony z sygnału pletyzmograficznego SpO₂ (tylko dorośli/dzieci)
Monitorowanie pacjenta jako funkcja całej platformy Delta
Cel: Zapewnienie, że nowe/zaktualizowane możliwości są bezpieczne, zrozumiałe i możliwe do przetestowania, poprzez zaprojektowanie przejrzystych przepływów pracy użytkownika (scenariuszy użycia) oraz identyfikację zadań użytkownika istotnych dla bezpieczeństwa na potrzeby oceny ryzyka (uFMEA) i planowania badań.
Przeprowadziłem ustrukturyzowane rozpoznanie z interesariuszami, aby ustalić, co jest faktem, a co założeniem:
Współpracowałem z osobami odpowiedzialnymi za kwestie kliniczne, ryzyko, inżynierię i możliwości, aby potwierdzić i zweryfikować koncepcję wartości przeterminowanych, podejście do alarmowania: dziedziczenie standardowych limitów Delta oraz to, że RFP można włączać/wyłączać , ale limity alarmowe nie są rozdzielne per źródło RR (limity dotyczą parametru RR ogólnie). Zwróciłem też uwagę na pułap 70 rpm dla RFP wobec wyższych pułapów dla innych źródeł RR (realny graniczny przypadek bezpieczeństwa/logiki).
Badania użytkowników i wnioski
Zacząłem od oddzielenia założeń od faktów. Wczesne notatki od interesariuszy były kierunkowo słuszne, ale niespójne w słownictwie (np. „% błędu” vs „dokładność w rpm” oraz „wartości wieku” vs „wartości H”). Ujednoliciłem język do takiego, który przetrwa formalną ocenę: wartości przeterminowane , dokładność wyrażona w rpm oraz dziedziczenie alarmów platformy zgodne ze standardowym zachowaniem Delta.
Następnie zmapowałem to, czego nie wolno nam duplikować . SpO₂ obejmuje już fizyczny przepływ pracy — wybór czujnika, założenie czujnika, podłączenie kabla, potwierdzenie wartości liczbowych — więc tworzenie pełnego drugiego zestawu dla RFP byłoby szumem i rozmyłoby ocenę bezpieczeństwa. Zamiast tego zawęziłem RFP do minimalnego zestawu odrębnych, istotnych dla bezpieczeństwa zachowań UI, które nie są jeszcze objęte.
Szkicując te scenariusze, oznaczyłem dokładne niepewności UI, które podważyłyby ważność scenariuszy, a później jakość UFMEA:
Co dokładnie dzieje się przy wyborze Noworodka (okno dialogowe, stan wyłączony, automatyczne wyłączenie, informacja zwrotna)?
Gdzie dokładnie włącza/wyłącza się RFP (menu parametrów, przełącznik na pasku bocznym, menu kontekstowe) i jak reprezentowany jest stan domyślnie włączony dla Dorosłych/Dzieci?
Jak UI sprawia, że jest bezbłędnie jasne, które źródło oddechu jest obecnie aktywne (EKG vs wyprowadzone z pletyzmografii), zwłaszcza gdy oba są dostępne?
Aby rozwiązać tę zależność projektową, przygotowałem ukierunkowane pytania do interesariuszy (architekt UI / eksperci merytoryczni), skupiające się ściśle na obserwowalnym zachowaniu , a nie na szczegółach implementacji, tak aby scenariusze pozostały obronialne w ocenie.
Konceptualizacja
Czerpiąc z badań użytkowników, wyobraziliśmy sobie ICU Angel jako jednolity interfejs, który:
Śledzi postęp ARDS za pomocą wykresów algorytmicznych.
Powiadamia personel medyczny w czasie rzeczywistym o wszelkich krytycznych zmianach.
Płynnie integruje się z istniejącymi systemami szpitalnymi, automatycznie uzupełniając dane pacjenta.
Wireframing
Stworzyliśmy szkice o niskiej wierności przedstawiające:
- Wizualizacje oparte na etapach: Każdy etap ARDS (zagrożenie, ciężki itd.) oznaczony kolorem dla szybkiego rozpoznania.
- Zarządzanie alarmami: Hierarchiczny system wyświetlający pilne alarmy na pierwszym planie, minimalizujący zmęczenie alarmami.
- Śledzenie leków: Dedykowana sekcja do podglądu godzin podawania i dawek leków.
Prototypowanie i pętla informacji zwrotnej od użytkowników
Następnie stworzyłem interaktywne prototypy symulujące kluczowe przepływy pracy, od przyjęcia i planowania leków po monitorowanie parametrów życiowych w czasie rzeczywistym.
- Testy praktyczne: Personel OIOM i główni badacze testowali te prototypy w ustrukturyzowanych sesjach.
- Kluczowa informacja zwrotna: Lekarze chcieli konfigurowalnych progów alarmowych, pielęgniarki prosiły o prostsze formularze wprowadzania danych, a dział IT opowiadał się za solidnymi ramami bezpieczeństwa danych.
Kontekst i sformułowanie problemu
Philips wprowadzał lub udoskonalał możliwości, które są klinicznie istotne, ale łatwe do niewłaściwego użycia w warunkach OIOM:
Użytkownicy działają w warunkach przerywania, zmęczenia alarmami, obciążenia poznawczego i presji czasu.
Nowe parametry (jak RFP) mogą być technicznie „częścią SpO₂”, ale wciąż wprowadzają nowe zachowania UI i nowe tryby awarii (np. opóźnienie do pierwszej wartości, ograniczenia dla noworodków, zachowanie wspólnego limitu alarmowego).
W przypadku przepływów pracy z inteligentnym kablem ContTemp ryzyka obejmują wybór niewłaściwego akcesorium, nieprawidłowe ustawienie oraz niepowodzenia kontroli zakażeń podczas odłączania/utylizacji.
Luka nie polegała na „brakujących ekranach”. Luka polegała na braku jasności operacyjnej:
Co użytkownik robi , widzi , decyduje i weryfikuje — i gdzie może to pójść nie tak?
Decyzje projektowe, które wyegzekwowałem
- Granica dziedziczenia: fizyczne ustawienie pozostaje w scenariuszach SpO₂; scenariusze RFP zaczynają się dopiero, gdy łańcuch czujnika jest już podłączony.
- Zarządzanie oczekiwaniami: RFP może pojawić się później; scenariusz wyraźnie traktuje opóźnioną dostępność jako normę, a nie błąd.
- Język wartości przeterminowanych: formalnie użyto terminu „wartości przeterminowane” (wartości o znanym wieku, wciąż wyświetlane).
- Zgodność alarmów: domyślne zachowanie alarmowania jest dziedziczone ze standardowego alarmowania Delta, wraz z limitami; RFP nie wprowadza osobnego „systemu alarmowego”.
- Ograniczenie dla noworodków to granica bezpieczeństwa: blokada musi być wyraźna w UI, a nie ukrytą regułą.
Rezultaty
Ta praca zamieniła „dodatek algorytmiczny” w możliwy do oceny projekt interakcji z określonym obszarem bezpieczeństwa. Zamiast dyskutować o RFP i dodatku do urządzenia Delta abstrakcyjnie, interesariusze mogli teraz zweryfikować:
co klinicysta widzi, kiedy to widzi i czego system oczekuje, że zrobi
jak ograniczenie dla noworodków jest egzekwowane w sposób możliwy do przetestowania
jak RFP wpisuje się w istniejące zachowanie alarmów i źródła oddechu bez tworzenia sprzecznych stanów UI
Ponad 14 scenariuszy zaprojektowanych dla sytuacji, w których urządzenia dodatkowe są podłączane i odłączane od monitora przyłóżkowego, eliminując ryzyko utraty danych, zagrożenia dla pacjenta i problemów w zarządzaniu.
