B2B : Conception d’un nouveau paramètre clinique pour un moniteur de soins intensifs : UI RFP, scénarios de sécurité et documentation prête pour le risque
À propos du projet
Aperçu du projet
Rôle: Senior Product Designer/Usability Engineer chez Philips (plus de 10 ans d’expérience UX)
Traduction des exigences cliniques/techniques en workflows utilisateur de bout en bout pouvant être examinés par Risque + Clinique + Ingénierie.
Définition des deltas de scénarios spécifiques au RFP (ce qui est réellement nouveau vs. ce qui est hérité du SpO₂).
Produit: Surveillance patient au chevet de Philips (capacités de la plateforme IntelliVue/Delta)
Domaines clés :
Workflows de surveillance SpO₂ (application du capteur, sélection source/étiquette, réglages d’alarme)
Workflows de température continue (ContTemp) (câble intelligent + sondes, différence de température double)
RFP (Respiration From Pleth) comme paramètre dérivé du signal pléthysmographique du SpO₂ (adulte/pédiatrique uniquement)
Surveillance patient comme fonctionnalité de l’ensemble de la Delta Platform
Objectif: Garantir que les capacités nouvelles/mises à jour soient sûres, compréhensibles et testables en concevant des workflows utilisateur clairs (scénarios d’usage) et en identifiant les tâches utilisateur liées à la sécurité pour l’évaluation des risques (uFMEA) et la planification des études.
J’ai mené une découverte structurée auprès des parties prenantes pour distinguer ce qui relève du fait vs. de l’hypothèse :
J’ai assuré la liaison avec les responsables cliniques, du risque, de l’ingénierie et des capacités pour confirmer et valider le concept de valeurs vieillies, l’approche d’alarme : hériter des limites Delta standard , et le fait que le RFP peut être activé/désactivé , mais que les limites d’alarme ne sont pas séparables par source de FR (les limites s’appliquent au paramètre FR de manière large). J’ai aussi signalé le plafond de 70 rpm pour le RFP vs. des plafonds plus élevés pour les autres sources de FR (un vrai cas limite de sécurité/logique).
Recherche utilisateur & insights
J’ai commencé par séparer les hypothèses des faits. Les premières notes des parties prenantes allaient dans la bonne direction mais étaient incohérentes dans la formulation (par ex. « % d’erreur » vs « précision en rpm », et « valeurs d’âge » vs « valeurs H »). J’ai convergé le langage vers ce qui survivrait à une revue formelle : valeurs vieillies , précision exprimée en rpm , et héritage d’alarme de plateforme aligné sur le comportement Delta standard.
Ensuite, j’ai cartographié ce que nous ne devons pas dupliquer . Le SpO₂ couvre déjà le workflow physique — sélectionner le capteur, appliquer le capteur, connecter le câble, confirmer les valeurs numériques — donc créer un second jeu complet pour le RFP serait du bruit et diluerait la revue de sécurité. À la place, j’ai réduit le RFP au minimum de comportements d’UI distincts et pertinents pour la sécurité qui ne sont pas déjà couverts.
En rédigeant ces scénarios, j’ai signalé les incertitudes d’UI précises qui compromettraient la validité des scénarios et, plus tard, la qualité de l’UFMEA :
Que se passe-t-il exactement lors de la sélection Nouveau-né (boîte de dialogue, état désactivé, désactivation automatique, retour d’information) ?
Où exactement le RFP est-il activé/désactivé (menu de paramètres, bascule de barre latérale, menu contextuel), et comment l’état activé par défaut est-il représenté pour Adulte/Pédiatrique ?
Comment l’UI rend-elle indubitable la source de respiration actuellement active (ECG vs. dérivée du pléthysmogramme), surtout lorsque les deux sont disponibles ?
Pour résoudre la dépendance de design, j’ai préparé des questions ciblées pour les parties prenantes (architecte UI / experts) portant strictement sur le comportement observable , et non sur les détails d’implémentation, afin que les scénarios restent défendables en revue.
Conceptualisation
En nous appuyant sur la recherche utilisateur, nous avons imaginé ICU Angel comme une interface unifiée qui :
Suit la progression du SDRA à l’aide de graphiques algorithmiques.
Alerte les professionnels de santé en temps réel de tout changement critique.
S’intègre parfaitement aux systèmes hospitaliers existants pour renseigner automatiquement les données patient.
Wireframing
Nous avons créé des esquisses en basse fidélité décrivant :
- Visualisations par stade: Chaque stade du SDRA (à risque, sévère, etc.) est codé par couleur pour une reconnaissance rapide.
- Gestion des alertes: Un système hiérarchique affichant les alertes urgentes au premier plan, minimisant la fatigue d’alarme.
- Suivi des médicaments: Une section dédiée à la consultation des heures et dosages d’administration des médicaments.
Prototypage & boucle de retour utilisateur
Ensuite, j’ai développé des prototypes interactifs pour simuler les workflows clés, de l’admission et la planification des médicaments jusqu’à la surveillance des signes vitaux en temps réel.
- Tests pratiques: Le personnel de soins intensifs et les investigateurs principaux ont testé ces prototypes lors de sessions structurées.
- Retours clés: Les médecins souhaitaient des seuils d’alerte personnalisables, les infirmiers ont demandé des formulaires de saisie de données plus simples, et le personnel informatique a plaidé pour des cadres robustes de sécurité des données.
Contexte & énoncé du problème
Philips introduisait ou affinait des capacités cliniquement significatives mais faciles à mal utiliser dans les conditions de soins intensifs :
Les utilisateurs opèrent sous interruptions, fatigue d’alarme, charge cognitive et pression temporelle.
Les nouveaux paramètres (comme le RFP) peuvent être techniquement « une partie du SpO₂ », mais introduisent tout de même de nouveaux comportements d’UI et de nouveaux modes de défaillance (par ex. latence jusqu’à la première valeur, restrictions nouveau-né, comportement de limite d’alarme partagée).
Pour les workflows du câble intelligent ContTemp, les risques incluent une mauvaise sélection d’accessoire, une configuration incorrecte et des défaillances de contrôle des infections lors de la déconnexion/élimination.
La lacune n’était pas des « écrans manquants ». La lacune était un manque de clarté opérationnelle :
Que fait , voit , décide et vérifie l’utilisateur — et où cela peut-il mal tourner ?
Décisions de design que j’ai imposées
- Frontière d’héritage: la configuration physique reste sous les scénarios SpO₂ ; les scénarios RFP ne commencent qu’une fois la chaîne du capteur déjà connectée.
- Gestion des attentes: le RFP est autorisé à apparaître plus tard ; le scénario traite explicitement une disponibilité différée comme normale, et non comme une erreur.
- Langage des valeurs vieillies: utilisation formelle du terme « valeurs vieillies » (valeurs d’âge connu, encore affichées).
- Alignement des alarmes: le comportement d’alarme par défaut est hérité de l’alarme Delta standard, y compris les limites ; le RFP n’introduit pas de « système d’alarme » distinct.
La restriction nouveau-né est une frontière de sécurité : le verrouillage doit être explicite dans l’UI, et non une règle cachée.
Résultats
Ce travail a transformé un « add-on d’algorithme » en une conception d’interaction examinable dotée d’un périmètre de sécurité défini. Au lieu de débattre du RFP et de l’add-on du dispositif Delta de manière abstraite, les parties prenantes pouvaient désormais valider :
ce que le clinicien voit, quand il le voit, et ce que le système attend qu’il fasse
comment la restriction nouveau-né est appliquée d’une manière testable
comment le RFP s’intègre au comportement existant des alarmes et de la source de respiration sans créer d’états d’UI contradictoires
Plus de 14 scénarios conçus pour l’utilisation d’appareils add-on faisant des allers-retours vers le moniteur de chevet, éliminant les risques de perte de données, de risque patient et de problèmes de gestion.
