B2B: Desenhar um novo parâmetro clínico para um monitor de UCI: UI de RFP, cenários de segurança e documentação pronta para risco

Investigação de utilizadores e insights

Comecei por separar as suposições dos factos. As notas iniciais dos stakeholders estavam direcionalmente corretas mas inconsistentes na formulação (por exemplo, “erro %” vs “exatidão em rpm”, e “valores de idade” vs “valores H”). Convergi a linguagem para o que sobreviveria a uma revisão formal: valores envelhecidos , exatidão expressa em rpm , e herança de alarme da plataforma alinhada com o comportamento Delta padrão.

De seguida, mapeei o que não devemos duplicar . O SpO₂ já cobre o fluxo físico de selecionar o sensor, aplicar o sensor, ligar o cabo, confirmar os valores numéricos, pelo que criar um segundo conjunto completo para RFP seria ruído e diluiria a revisão de segurança. Em vez disso, limitei o RFP ao conjunto mínimo de comportamentos de UI distintos e relevantes para a segurança que ainda não estão cobertos.

Ao redigir estes cenários, assinalei as exatas incertezas de UI que quebrariam a validade dos cenários e mais tarde a qualidade da UFMEA:

O que acontece exatamente na seleção de Neonatal (diálogo, estado desativado, desativação automática, feedback)?

Onde exatamente é o RFP ativado/desativado (menu de parâmetros, alternância na barra lateral, menu de contexto), e como é representado o estado predefinido de ativo para Adulto/Pediátrico?

Como é que a UI torna inequívoco qual a fonte de respiração atualmente ativa (ECG vs. derivada de pleth), sobretudo quando ambas estão disponíveis?

Para resolver a dependência de design, preparei perguntas dirigidas aos stakeholders (arquiteto de UI / SMEs) focadas estritamente no comportamento observável , não em detalhes de implementação, para que os cenários se mantenham defensáveis em revisão.

Concetualização

Partindo da investigação de utilizadores, imaginámos o ICU Angel como uma interface unificada que:

Acompanha a progressão da ARDS através de gráficos algorítmicos.

Alerta os profissionais de saúde em tempo real para quaisquer alterações críticas.

Integra-se perfeitamente com os sistemas hospitalares existentes para preencher automaticamente os dados do doente.

Wireframing

Criámos esboços de baixa fidelidade que delineavam:

1. Visualizações Baseadas em Fases: Cada fase de ARDS (em risco, grave, etc.) tem um código de cor para reconhecimento rápido.
2. Gestão de Alertas: Um sistema hierárquico que apresenta os alertas urgentes em primeiro plano, minimizando a fadiga de alarmes.
3. Acompanhamento da Medicação: Uma secção dedicada à visualização de horários e dosagens de administração de fármacos.

Prototipagem e ciclo de feedback do utilizador

De seguida, desenvolvi protótipos interativos para simular os fluxos de trabalho centrais, desde a admissão e o agendamento da medicação até à monitorização dos sinais vitais em tempo real.

1. Testes Práticos: O pessoal de UCI e os investigadores principais testaram estes protótipos em sessões estruturadas.
2. Feedback Chave: Os médicos desejavam limiares de alerta personalizáveis, os enfermeiros pediram formulários de entrada de dados mais simples e o pessoal de TI defendeu enquadramentos robustos de segurança de dados.

Contexto e definição do problema

A Philips estava a introduzir ou a refinar capacidades clinicamente relevantes mas fáceis de usar incorretamente sob condições de UCI:

Os utilizadores operam sob interrupções, fadiga de alarmes, carga cognitiva e pressão de tempo.

Novos parâmetros (como o RFP) podem ser tecnicamente “parte do SpO₂”, mas ainda introduzem novos comportamentos de UI e novos modos de falha (por exemplo, latência até ao primeiro valor, restrições neonatais, comportamento de limite de alarme partilhado).

Para os fluxos de smart cable ContTemp, os riscos incluem a seleção errada de acessórios, a configuração incorreta e falhas de controlo de infeção durante a desconexão/eliminação.

A lacuna não era “ecrãs em falta”. A lacuna era falta de clareza operacional:

O que faz o utilizador , vê , decide e verifica e onde é que isso pode correr mal?

Decisões de design que impus

1. Fronteira de herança: a configuração física permanece nos cenários de SpO₂; os cenários de RFP começam apenas quando a cadeia de sensor já está ligada.
2. Gestão de expectativas: o RFP pode surgir mais tarde; o cenário trata explicitamente a disponibilidade atrasada como normal e não como um erro.
3. Linguagem de valores envelhecidos: usei formalmente o termo “valores envelhecidos” (valores com idade conhecida, ainda apresentados).
4. Alinhamento de alarme: o comportamento de alarme predefinido é herdado do alarme Delta padrão, incluindo os limites; o RFP não introduz um “sistema de alarme” separado.

A restrição neonatal é uma fronteira de segurança: o bloqueio tem de ser explícito na UI, e não uma regra oculta.

Resultados

Este trabalho transformou um “add-on de algoritmo” num design de interação revisível com um perímetro de segurança definido. Em vez de debater o RFP e o add-on do dispositivo Delta de forma abstrata, os stakeholders podiam agora validar:

o que o clínico vê, quando o vê e o que o sistema espera que ele faça

como a restrição neonatal é imposta de uma forma testável

como o RFP encaixa no comportamento existente de alarme e de fonte de respiração sem criar estados de UI contraditórios

Mais de 14 cenários desenhados para onde se usam dispositivos add-on de e para o monitor à cabeceira, eliminando riscos de perda de dados, risco para o doente e problemas de gestão.