B2B: Проектирование нового клинического параметра для монитора ОРИТ: RFP UI, сценарии безопасности и готовая к оценке рисков документация
О проекте
Обзор проекта
Роль: Senior Product Designer/инженер по удобству использования в Philips (10+ лет опыта в UX)
Перевёл клинические/инженерные требования в сквозные пользовательские рабочие процессы, которые могут быть рассмотрены командами Risk + Clinical + Engineering.
Определил дельты сценариев, специфичные для RFP (что действительно новое против того, что унаследовано от SpO₂).
Продукт: Прикроватный мониторинг пациентов Philips (возможности платформы IntelliVue/Delta)
Области фокуса:
Рабочие процессы мониторинга SpO₂ (наложение датчика, выбор источника/метки, настройки тревог)
Рабочие процессы непрерывной температуры (ContTemp) (умный кабель + зонды, разница двойной температуры)
RFP (Respiration From Pleth) как производный параметр от плетизмографического сигнала SpO₂ (только взрослые/дети)
Мониторинг пациентов как функция общей платформы Delta
Цель: Обеспечить, чтобы новые/обновлённые возможности были безопасными, понятными и тестируемыми, проектируя ясные пользовательские рабочие процессы (сценарии использования) и выявляя связанные с безопасностью пользовательские задачи для оценки рисков (uFMEA) и планирования исследований.
Я провёл структурированное исследование заинтересованных сторон, чтобы точно определить, что является фактом, а что предположением:
Взаимодействовал с клиническими, риск-, инженерными владельцами возможностей, чтобы подтвердить и валидировать концепцию устаревших значений, подход к тревогам: наследовать стандартные лимиты Delta , и что RFP можно включать/выключать , но лимиты тревог не разделяются по источнику RR (лимиты применяются к параметру RR в целом). Также отметил потолок 70 rpm для RFP против более высоких потолков для других источников RR (реальный пограничный случай безопасности/логики).
Пользовательские исследования и инсайты
Я начал с разделения предположений и фактов. Ранние заметки от заинтересованных сторон были в целом верны по направлению, но несогласованы в формулировках (например, «% ошибки» против «точности в rpm» и «возрастные значения» против «H-значений»). Я свёл язык к тому, что выдержало бы формальное рассмотрение: устаревшие значения , точность, выраженная в rpm , и наследование тревог платформы, согласованное со стандартным поведением Delta.
Далее я определил, что мы не должны дублировать . SpO₂ уже покрывает физический рабочий процесс — выбор датчика, наложение датчика, подключение кабеля, подтверждение числовых значений — поэтому создание полного второго набора для RFP было бы шумом и размыло бы обзор безопасности. Вместо этого я ограничил RFP минимальным набором отдельных, значимых для безопасности вариантов поведения UI, которые ещё не покрыты.
При составлении этих сценариев я отметил точные неопределённости UI, которые нарушили бы валидность сценариев и позднее качество UFMEA:
Что именно происходит при выборе Neonate (диалог, отключённое состояние, автоматическое выключение, обратная связь)?
Где именно RFP включается/выключается (меню параметра, переключатель на боковой панели, контекстное меню) и как представлено состояние «по умолчанию включено» для Adult/Ped?
Как UI делает безошибочно ясным, какой источник дыхания сейчас активен (ЭКГ против производного от плетизмограммы), особенно когда доступны оба?
Чтобы разрешить зависимость дизайна, я подготовил целевые вопросы к заинтересованным сторонам (UI-архитектор / SME), которые фокусируются строго на наблюдаемом поведении , а не на деталях реализации, чтобы сценарии оставались защитимыми при рассмотрении.
Концептуализация
Опираясь на пользовательские исследования, мы задумали ICU Angel как единый интерфейс, который:
Отслеживает прогрессирование ОРДС с помощью алгоритмических графиков.
Оповещает медицинских специалистов в реальном времени о любых критических изменениях.
Бесшовно интегрируется с существующими больничными системами для автоматического заполнения данных пациента.
Вайрфрейминг
Мы создали низкодетализированные наброски, описывающие:
- Визуализации по стадиям: Каждая стадия ОРДС (риск, тяжёлая и т. д.) выделена цветом для быстрого распознавания.
- Управление оповещениями: Иерархическая система, отображающая срочные оповещения на первом плане, минимизируя усталость от тревог.
- Отслеживание приёма препаратов: Отдельный раздел для просмотра времени введения и дозировок препаратов.
Прототипирование и цикл обратной связи с пользователями
Далее я разработал интерактивные прототипы для симуляции ключевых рабочих процессов, от поступления и планирования приёма препаратов до мониторинга жизненных показателей в реальном времени.
- Практическое тестирование: Персонал ОРИТ и главные исследователи тестировали эти прототипы в структурированных сессиях.
- Ключевая обратная связь: Врачи хотели настраиваемые пороги оповещений, медсёстры просили более простые формы ввода данных, а IT-персонал выступал за надёжные фреймворки безопасности данных.
Контекст и постановка проблемы
Philips вводила или дорабатывала возможности, которые клинически значимы, но легко подвержены неправильному использованию в условиях ОРИТ:
Пользователи работают в условиях прерываний, усталости от тревог, когнитивной нагрузки и цейтнота.
Новые параметры (как RFP) могут технически быть «частью SpO₂», но всё же вводят новые варианты поведения UI и новые режимы отказа (например, задержку до первого значения, ограничения для новорождённых, поведение общего лимита тревог).
Для рабочих процессов умного кабеля ContTemp риски включают неправильный выбор аксессуара, некорректную настройку и сбои инфекционного контроля при отключении/утилизации.
Разрыв был не в «отсутствующих экранах». Разрыв был в отсутствующей операционной ясности:
Что пользователь делает , видит , решает и проверяет — и где это может пойти не так?
Дизайн-решения, которые я отстоял
- Граница наследования: физическая настройка остаётся в рамках сценариев SpO₂; сценарии RFP начинаются только после того, как цепочка датчика уже подключена.
- Управление ожиданиями: RFP разрешено появляться позже; сценарий явно трактует отложенную доступность как нормальную, а не как ошибку.
- Язык устаревших значений: использовал термин «устаревшие значения» формально (значения с известным возрастом, всё ещё отображаемые).
- Согласование тревог: поведение тревог по умолчанию наследуется от стандартных тревог Delta, включая лимиты; RFP не вводит отдельную «систему тревог».
Ограничение для новорождённых — это граница безопасности: блокировка должна быть явной в UI, а не скрытым правилом.
Результаты
Эта работа превратила «дополнение-алгоритм» в рассматриваемый дизайн взаимодействия с определённым периметром безопасности. Вместо абстрактных дебатов о RFP и дополнительном устройстве delta заинтересованные стороны теперь могли валидировать:
что клиницист видит, когда он это видит и что система ожидает от него
как ограничение для новорождённых обеспечивается способом, который тестируем
как RFP вписывается в существующее поведение тревог и источника дыхания без создания противоречивых состояний UI
Более 14 сценариев спроектировано для случаев использования дополнительных устройств туда-сюда к прикроватному монитору, устраняя риски потери данных, риска для пациента и проблем управления.
