B2B: Progettare un nuovo parametro clinico per un monitor di terapia intensiva: UI RFP, scenari di sicurezza e documentazione pronta al rischio
Il progetto
Panoramica del progetto
Ruolo: Senior Product Designer/Usability Engineer presso Philips (oltre 10 anni di esperienza UX)
Tradotti i requisiti clinici/ingegneristici in workflow utente end-to-end revisionabili da Rischio + Clinico + Ingegneria.
Definiti i delta di scenario specifici per RFP (cosa è davvero nuovo rispetto a ciò che è ereditato dall'SpO₂).
Prodotto: Monitoraggio del paziente al letto Philips (capacità della piattaforma IntelliVue/Delta)
Aree di focus:
Workflow di monitoraggio SpO₂ (applicazione del sensore, selezione sorgente/etichetta, impostazioni degli allarmi)
Workflow di Temperatura Continua (ContTemp) (cavo smart + sonde, differenza di temperatura duale)
RFP (Respiration From Pleth) come parametro derivato dal segnale pleth SpO₂ (solo adulti/pediatrico)
Monitoraggio del paziente come funzionalità dell'intera piattaforma Delta
Obiettivo: Garantire che le capacità nuove/aggiornate siano sicure, comprensibili e testabili, progettando workflow utente chiari (scenari d'uso) e identificando i compiti utente legati alla sicurezza per la valutazione del rischio (uFMEA) e la pianificazione degli studi.
Ho condotto una scoperta strutturata degli stakeholder per definire cosa è fattuale rispetto a ciò che è supposizione:
Mi sono coordinato con i responsabili clinici, di rischio, ingegneristici e di capacità per confermare e validare il concetto di valori invecchiati, l'approccio agli allarmi: ereditare i limiti standard Delta , e che RFP può essere abilitato/disabilitato , ma i limiti di allarme non sono separabili per sorgente RR (i limiti si applicano al parametro RR nel suo complesso). Ho inoltre segnalato il tetto di 70 rpm per RFP rispetto ai tetti più alti delle altre sorgenti RR (un vero caso limite di sicurezza/logica).
Ricerca utente e insight
Ho iniziato separando le supposizioni dai fatti. Le prime note degli stakeholder erano direzionalmente corrette ma incoerenti nella terminologia (ad esempio, “% di errore” vs “accuratezza in rpm”, e “valori di età” vs “valori H”). Ho fatto convergere il linguaggio verso ciò che avrebbe superato una revisione formale: valori invecchiati , accuratezza espressa in rpm ed ereditarietà degli allarmi di piattaforma allineata al comportamento standard Delta.
Successivamente, ho mappato ciò che non dobbiamo duplicare . L'SpO₂ copre già il workflow fisico seleziona sensore, applica sensore, collega il cavo, conferma i valori numerici, quindi creare un intero secondo set per RFP sarebbe rumore e diluirebbe la revisione della sicurezza. Ho invece definito l'ambito di RFP al set minimo di comportamenti UI distinti e rilevanti per la sicurezza non già coperti.
Mentre redigevo questi scenari, ho segnalato le esatte incertezze UI che avrebbero compromesso la validità degli scenari e in seguito la qualità dell'UFMEA:
Cosa accade esattamente alla selezione di Neonato (dialogo, stato disabilitato, spegnimento automatico, feedback)?
Dove esattamente si attiva/disattiva RFP (menu del parametro, toggle nella barra laterale, menu contestuale) e come è rappresentato il default-attivo per Adulto/Pediatrico?
Come rende la UI inequivocabile quale sorgente di respirazione è attualmente attiva (ECG vs derivata da pleth), specialmente quando entrambe sono disponibili?
Per risolvere la dipendenza di design, ho preparato domande mirate agli stakeholder (architetto UI / SME) focalizzate rigorosamente sul comportamento osservabile , non sui dettagli implementativi, così che gli scenari restino difendibili in revisione.
Concettualizzazione
Partendo dalla ricerca utente, abbiamo immaginato ICU Angel come un'interfaccia unificata che:
Traccia la progressione dell'ARDS usando grafici algoritmici.
Avvisa i professionisti sanitari in tempo reale di qualsiasi cambiamento critico.
Si integra perfettamente con i sistemi ospedalieri esistenti per popolare automaticamente i dati del paziente.
Wireframing
Abbiamo creato schizzi a bassa fedeltà che delineavano:
- Visualizzazioni per stadio: Ogni stadio dell'ARDS (a rischio, grave, ecc.) è codificato a colori per un rapido riconoscimento.
- Gestione degli allarmi: Un sistema gerarchico che mostra gli allarmi urgenti in primo piano, riducendo l'affaticamento da allarmi.
- Tracciamento della terapia: Una sezione dedicata alla visualizzazione degli orari di somministrazione e dei dosaggi dei farmaci.
Prototipazione e ciclo di feedback utente
Successivamente, ho sviluppato prototipi interattivi per simulare i workflow principali, dal ricovero e dalla pianificazione della terapia al monitoraggio dei parametri vitali in tempo reale.
- Test pratici: Il personale di terapia intensiva e i ricercatori principali hanno testato questi prototipi in sessioni strutturate.
- Feedback chiave: I medici desideravano soglie di allarme personalizzabili, gli infermieri hanno richiesto moduli di inserimento dati più semplici e lo staff IT ha sostenuto la necessità di solidi framework di sicurezza dei dati.
Contesto e definizione del problema
Philips stava introducendo o perfezionando capacità clinicamente significative ma facili da usare in modo errato nelle condizioni della terapia intensiva:
Gli utenti operano sotto interruzioni, affaticamento da allarmi, carico cognitivo e pressione temporale.
I nuovi parametri (come RFP) possono essere tecnicamente “parte dell'SpO₂”, ma introducono comunque nuovi comportamenti UI e nuove modalità di guasto (ad esempio, latenza al primo valore, restrizioni per neonati, comportamento condiviso dei limiti di allarme).
Per i workflow del cavo smart ContTemp, i rischi includono la selezione errata dell'accessorio, la configurazione scorretta e i guasti al controllo delle infezioni durante la disconnessione/lo smaltimento.
La lacuna non erano “schermate mancanti”. La lacuna era la chiarezza operativa mancante:
Cosa fa l'utente , vede , decide e verifica e dove può andare storto?
Decisioni di design che ho imposto
- Confine di ereditarietà: la configurazione fisica resta sotto gli scenari SpO₂; gli scenari RFP iniziano solo una volta che la catena del sensore è già collegata.
- Gestione delle aspettative: a RFP è consentito comparire più tardi; lo scenario tratta esplicitamente la disponibilità ritardata come normale, non come un errore.
- Linguaggio dei valori invecchiati: usato il termine “valori invecchiati” formalmente (valori con età nota, ancora visualizzati).
- Allineamento degli allarmi: il comportamento di allarme di default è ereditato dall'allarme standard Delta, inclusi i limiti; RFP non introduce un “sistema di allarme” separato.
La restrizione per neonati è un confine di sicurezza: il blocco deve essere esplicito nella UI, non una regola nascosta.
Esiti
Questo lavoro ha trasformato un “add-on algoritmico” in un design dell'interazione revisionabile con un perimetro di sicurezza definito. Invece di discutere RFP e l'add-on del dispositivo delta in astratto, gli stakeholder potevano ora validare:
cosa vede il clinico, quando lo vede e cosa il sistema si aspetta che faccia
come la restrizione per neonati viene applicata in modo testabile
come RFP si inserisce nel comportamento esistente degli allarmi e della sorgente di respirazione senza creare stati UI contraddittori
Più di 14 scenari progettati per l'uso di dispositivi add-on trasferiti da e verso il monitor al letto, eliminando i rischi di perdita di dati, rischio per il paziente e problemi di gestione.
