B2B: Diseñando un nuevo parámetro clínico para un monitor de UCI: UI de RFP, escenarios de seguridad y documentación lista para el riesgo
Sobre el proyecto
Resumen del proyecto
Rol: Senior Product Designer/Ingeniero de Usabilidad en Philips (más de 10 años de experiencia en UX)
Traduje requisitos clínicos/de ingeniería en flujos de trabajo de usuario de principio a fin que pueden ser revisados por Riesgo + Clínica + Ingeniería.
Definí los deltas de escenario específicos de RFP (qué es realmente nuevo frente a qué se hereda de SpO₂).
Producto: Monitoreo de pacientes a pie de cama de Philips (capacidades de la plataforma IntelliVue/Delta)
Áreas de foco:
Flujos de monitoreo de SpO₂ (aplicación del sensor, selección de fuente/etiqueta, ajustes de alarma)
Flujos de Temperatura Continua (ContTemp) (cable inteligente + sondas, diferencia de temperatura dual)
RFP (Respiration From Pleth) como parámetro derivado de la señal pleth de SpO₂ (solo adultos/pediátricos)
Monitoreo de pacientes como una función de la Delta Platform general
Objetivo: Asegurar que las capacidades nuevas/actualizadas sean seguras, comprensibles y testeables diseñando flujos de trabajo de usuario claros (escenarios de uso) e identificando las tareas de usuario relacionadas con la seguridad para la evaluación de riesgos (uFMEA) y la planificación de estudios.
Realicé un descubrimiento estructurado con stakeholders para precisar qué es factual frente a suposición:
Coordiné con los responsables clínicos, de riesgo, de ingeniería y de capacidad para confirmar y validar el concepto de valores envejecidos, el enfoque de alarmas: heredar los límites estándar de Delta , y que RFP puede activarse/desactivarse , pero los límites de alarma no son separables por fuente de RR (los límites se aplican al parámetro RR de forma amplia). También señalé el techo de 70 rpm para RFP frente a techos más altos para otras fuentes de RR (un caso límite real de seguridad/lógica).
Investigación de usuarios e insights
Empecé separando las suposiciones de los hechos. Las notas iniciales de los stakeholders iban bien encaminadas pero eran inconsistentes en la redacción (p. ej., “% de error” vs “precisión en rpm”, y “valores de edad” vs “valores H”). Convergí el lenguaje hacia lo que sobreviviría a una revisión formal: valores envejecidos , precisión expresada en rpm , y herencia de alarmas de plataforma alineada con el comportamiento estándar de Delta.
A continuación, mapeé lo que no debíamos duplicar . SpO₂ ya cubre el flujo físico seleccionar sensor, aplicar sensor, conectar cable, confirmar valores numéricos, así que crear un segundo conjunto completo para RFP sería ruido y diluiría la revisión de seguridad. En su lugar, acoté RFP al conjunto mínimo de comportamientos de UI distintos y relevantes para la seguridad que no estaban ya cubiertos.
Mientras redactaba estos escenarios, señalé las incertidumbres exactas de UI que romperían la validez de los escenarios y, más adelante, la calidad del uFMEA:
¿Qué ocurre exactamente al seleccionar Neonato (diálogo, estado deshabilitado, apagado automático, feedback)?
¿Dónde se activa/desactiva exactamente RFP (menú de parámetros, toggle en la barra lateral, menú contextual), y cómo se representa el activado por defecto para Adulto/Pediátrico?
¿Cómo hace la UI que sea inconfundible qué fuente de respiración está activa actualmente (ECG vs. derivada de pleth), especialmente cuando ambas están disponibles?
Para resolver la dependencia de diseño, preparé preguntas dirigidas a los stakeholders (arquitecto de UI / SMEs) centradas estrictamente en el comportamiento observable , no en los detalles de implementación, para que los escenarios se mantuvieran defendibles en la revisión.
Conceptualización
Partiendo de la investigación de usuarios, concebimos ICU Angel como una interfaz unificada que:
Rastrea la progresión del SDRA mediante gráficos algorítmicos.
Alerta a los profesionales de la salud en tiempo real ante cualquier cambio crítico.
Se integra sin fricciones con los sistemas hospitalarios existentes para poblar los datos del paciente automáticamente.
Wireframing
Creamos bocetos de baja fidelidad que definían:
- Visualizaciones por etapas: Cada etapa del SDRA (en riesgo, grave, etc.) se codifica por color para su reconocimiento rápido.
- Gestión de alertas: Un sistema jerárquico que muestra las alertas urgentes en primer plano, minimizando la fatiga de alarmas.
- Seguimiento de la medicación: Una sección dedicada a ver los tiempos y dosis de administración de fármacos.
Prototipado y bucle de feedback de usuarios
A continuación, desarrollé prototipos interactivos para simular los flujos de trabajo centrales, desde el ingreso y la programación de medicación hasta el monitoreo de constantes vitales en tiempo real.
- Pruebas prácticas: El personal de UCI y los investigadores principales probaron estos prototipos en sesiones estructuradas.
- Feedback clave: Los médicos deseaban umbrales de alerta personalizables, los enfermeros pidieron formularios de entrada de datos más simples y el personal de TI abogó por marcos robustos de seguridad de datos.
Contexto y planteamiento del problema
Philips estaba introduciendo o refinando capacidades que son clínicamente significativas pero fáciles de usar mal en condiciones de UCI:
Los usuarios operan bajo interrupciones, fatiga de alarmas, carga cognitiva y presión de tiempo.
Los parámetros nuevos (como RFP) pueden ser técnicamente “parte de SpO₂”, pero aun así introducen nuevos comportamientos de UI y nuevos modos de fallo (p. ej., latencia hasta el primer valor, restricciones para neonatos, comportamiento de límite de alarma compartido).
Para los flujos del cable inteligente de ContTemp, los riesgos incluyen la selección incorrecta del accesorio, la configuración incorrecta y los fallos de control de infecciones durante la desconexión/desecho.
La brecha no eran “pantallas faltantes”. La brecha era la falta de claridad operativa:
¿Qué hace , ve , decide y verifica el usuario, y dónde puede salir mal?
Decisiones de diseño que impuse
- Límite de herencia: la configuración física permanece bajo los escenarios de SpO₂; los escenarios de RFP comienzan solo una vez que la cadena del sensor ya está conectada.
- Gestión de expectativas: se permite que RFP aparezca más tarde; el escenario trata explícitamente la disponibilidad retrasada como algo normal, no como un error.
- Lenguaje de valores envejecidos: usé el término “valores envejecidos” formalmente (valores con antigüedad conocida, aún mostrados).
- Alineación de alarmas: el comportamiento de alarma por defecto se hereda del sistema de alarmas estándar de Delta, incluidos los límites; RFP no introduce un “sistema de alarmas” separado.
La restricción para neonatos es un límite de seguridad: el bloqueo debe ser explícito en la UI, no una regla oculta.
Resultados
Este trabajo convirtió un “complemento de algoritmo” en un diseño de interacción revisable con un perímetro de seguridad definido. En lugar de debatir RFP y el complemento del dispositivo delta de forma abstracta, los stakeholders ahora podían validar:
qué ve el clínico, cuándo lo ve y qué espera el sistema que haga
cómo se aplica la restricción para neonatos de una forma que es testeable
cómo encaja RFP en el comportamiento existente de alarmas y fuentes de respiración sin crear estados de UI contradictorios
Más de 14 escenarios diseñados para el uso de dispositivos complementarios de ida y vuelta al monitor a pie de cama, eliminando riesgos de pérdida de datos, riesgo para el paciente y problemas de gestión.
