B2B: Gestaltung eines neuen klinischen Parameters für einen ICU-Monitor: RFP-UI, Sicherheitsszenarien und risikofertige Dokumentation
Über das Projekt
Projektübersicht
Rolle: Senior Product Designer/Usability Engineer bei Philips (über 10 Jahre UX-Erfahrung)
Klinische/technische Anforderungen in End-to-End-Nutzer-Workflows übersetzt, die von Risk + Clinical + Engineering überprüft werden können.
RFP-spezifische Szenario-Deltas definiert (was ist wirklich neu vs. was ist von SpO₂ übernommen).
Produkt: Philips-Patientenüberwachung am Krankenbett (Fähigkeiten der IntelliVue/Delta-Plattform)
Schwerpunktbereiche:
SpO₂-Überwachungs-Workflows (Sensoranlegung, Quellen-/Label-Auswahl, Alarmeinstellungen)
Continuous-Temperature-Workflows (ContTemp) (Smart Cable + Sonden, duale Temperaturdifferenz)
RFP (Respiration From Pleth) als abgeleiteter Parameter aus dem SpO₂-Pleth-Signal (nur Erwachsene/Pädiatrie)
Patientenüberwachung als Funktion der gesamten Delta-Plattform
Ziel: Sicherstellen, dass neue/aktualisierte Fähigkeiten sicher, verständlich und testbar sind, indem klare Nutzer-Workflows (Anwendungsszenarien) entworfen und sicherheitsrelevante Nutzeraufgaben für die Risikobewertung (uFMEA) und Studienplanung identifiziert werden.
Ich führte eine strukturierte Stakeholder-Discovery durch, um festzuhalten, was faktisch ist vs. Annahme:
Habe mit Clinical-, Risk-, Engineering- und Capability-Ownern abgestimmt, um das Konzept der Aged Values und den Alarmierungsansatz zu bestätigen und zu validieren: Standard-Delta-Grenzwerte übernehmen , und RFP kann aktiviert/deaktiviert werden , aber die Alarmgrenzen sind nicht pro RR-Quelle trennbar (Grenzwerte gelten für den RR-Parameter allgemein). Außerdem habe ich die 70-rpm-Obergrenze für RFP gegenüber höheren Obergrenzen für andere RR-Quellen markiert (ein echter Sicherheits-/Logik-Grenzfall).
Nutzerforschung & Erkenntnisse
Ich begann damit, Annahmen von Fakten zu trennen. Frühe Notizen von Stakeholdern waren in der Richtung korrekt, aber in der Wortwahl inkonsistent (z. B. „error %“ vs. „rpm accuracy“ und „age values“ vs. „H values“). Ich vereinheitlichte die Sprache auf das, was eine formale Prüfung überstehen würde: Aged Values , Genauigkeit ausgedrückt in rpm und Plattform-Alarm-Vererbung im Einklang mit dem Standard-Delta-Verhalten.
Als Nächstes kartierte ich, was wir nicht duplizieren dürfen . SpO₂ deckt bereits den physischen Workflow ab – Sensor auswählen, Sensor anlegen, Kabel anschließen, Zahlenwerte bestätigen – daher wäre ein vollständiger zweiter Satz für RFP Rauschen und würde die Sicherheitsprüfung verwässern. Stattdessen fasste ich RFP auf den minimalen Satz eindeutiger, sicherheitsrelevanter UI-Verhaltensweisen, die nicht bereits abgedeckt sind.
Beim Entwurf dieser Szenarien markierte ich die genauen UI-Unsicherheiten, die die Szenariogültigkeit und später die uFMEA-Qualität untergraben würden:
Was genau passiert bei der Neonaten-Auswahl (Dialog, deaktivierter Zustand, automatische Abschaltung, Feedback)?
Wo genau wird RFP ein-/ausgeschaltet (Parametermenü, Sidebar-Toggle, Kontextmenü), und wie wird der Standard-Ein-Zustand für Erwachsene/Pädiatrie dargestellt?
Wie macht die UI unmissverständlich klar, welche Atmungsquelle gerade aktiv ist (EKG vs. pleth-abgeleitet), insbesondere wenn beide verfügbar sind?
Um die Design-Abhängigkeit aufzulösen, bereitete ich gezielte Stakeholder-Fragen (UI-Architekt / SMEs) vor, die sich strikt auf beobachtbares Verhalten konzentrieren, nicht auf Implementierungsdetails, damit die Szenarien in der Prüfung verteidigbar bleiben.
Konzeptualisierung
Aufbauend auf der Nutzerforschung stellten wir uns ICU Angel als einheitliche Oberfläche vor, die:
Den ARDS-Verlauf mithilfe algorithmischer Diagramme verfolgt.
Medizinisches Fachpersonal in Echtzeit über kritische Veränderungen alarmiert.
Sich nahtlos in bestehende Krankenhaussysteme integriert, um Patientendaten automatisch zu befüllen.
Wireframing
Wir erstellten Low-Fidelity-Skizzen, die Folgendes umrissen:
- Stufenbasierte Visualisierungen: Jede ARDS-Stufe (gefährdet, schwer usw.) ist zur schnellen Erkennung farblich kodiert.
- Alarm-Management: Ein hierarchisches System, das dringende Alarme in den Vordergrund stellt und Alarmmüdigkeit minimiert.
- Medikamenten-Tracking: Ein eigener Bereich zur Ansicht von Verabreichungszeiten und Dosierungen.
Prototyping & Nutzer-Feedback-Schleife
Als Nächstes entwickelte ich interaktive Prototypen, um die Kern-Workflows zu simulieren, von der Aufnahme und Medikamentenplanung bis zur Echtzeit-Überwachung der Vitalwerte.
- Praktische Tests: ICU-Personal und Prüfärzte testeten diese Prototypen in strukturierten Sitzungen.
- Zentrales Feedback: Ärzte wünschten sich anpassbare Alarmschwellen, Pflegekräfte baten um einfachere Dateneingabeformulare, und IT-Mitarbeiter plädierten für robuste Datensicherheitskonzepte.
Kontext & Problemstellung
Philips führte Fähigkeiten ein oder verfeinerte sie, die klinisch bedeutsam, aber unter ICU-Bedingungen leicht falsch anzuwenden sind:
Nutzer arbeiten unter Unterbrechungen, Alarmmüdigkeit, kognitiver Belastung und Zeitdruck.
Neue Parameter (wie RFP) mögen technisch „Teil von SpO₂“ sein, führen aber dennoch neue UI-Verhaltensweisen und neue Fehlermodi ein (z. B. Latenz bis zum ersten Wert, Neonaten-Einschränkungen, gemeinsames Alarmgrenzenverhalten).
Bei den ContTemp-Smart-Cable-Workflows umfassen die Risiken falsche Zubehörauswahl, fehlerhafte Einrichtung und Infektionsschutzfehler beim Trennen/Entsorgen.
Die Lücke war nicht „fehlende Bildschirme“. Die Lücke war fehlende operative Klarheit:
Was tut , sieht , entscheidet und verifiziert der Nutzer – und wo kann das schiefgehen?
Designentscheidungen, die ich durchgesetzt habe
- Vererbungsgrenze: Der physische Aufbau bleibt unter den SpO₂-Szenarien; RFP-Szenarien beginnen erst, sobald die Sensorkette bereits verbunden ist.
- Erwartungsmanagement: RFP darf später erscheinen; das Szenario behandelt verzögerte Verfügbarkeit ausdrücklich als normal, nicht als Fehler.
- Aged-Values-Sprache: Der Begriff „Aged Values“ formal verwendet (Werte mit bekanntem Alter, die weiterhin angezeigt werden).
- Alarm-Ausrichtung: Das Standard-Alarmverhalten wird von der Standard-Delta-Alarmierung übernommen, einschließlich der Grenzwerte; RFP führt kein separates „Alarmsystem“ ein.
- Die Neonaten-Einschränkung ist eine Sicherheitsgrenze: Die Sperre muss in der UI explizit sein, keine versteckte Regel.
Ergebnisse
Diese Arbeit verwandelte ein „Algorithmus-Add-on“ in ein überprüfbares Interaktionsdesign mit einem definierten Sicherheitsperimeter. Statt RFP und das Delta-Geräte-Add-on abstrakt zu diskutieren, konnten Stakeholder nun Folgendes validieren:
was der Kliniker sieht, wann er es sieht und was das System von ihm erwartet
wie die Neonaten-Einschränkung auf eine testbare Weise durchgesetzt wird
wie RFP in das bestehende Alarm- und Atmungsquellen-Verhalten passt, ohne widersprüchliche UI-Zustände zu erzeugen
Mehr als 14 Szenarien entworfen für den Einsatz von Add-on-Geräten hin und her zum Bettmonitor, wodurch Risiken von Datenverlust, Patientenrisiko und Managementproblemen eliminiert werden.
