Adding a new clinical parameter to an ICU patient monitor, safely

01

Project overview

We turned clinical and engineering requirements into workflows that the risk, clinical, and engineering teams could review together.

We separated the new Respiration From Pleth (RFP) behaviour from the existing SpO₂ workflow.

Product: Philips bedside patient monitoring, including IntelliVue and Delta platform capabilities.

The work covered:

SpO₂ monitoring workflows (sensor application, source/label selection, and alarm settings)

Continuous Temperature (ContTemp) workflows (smart cable and probes, and dual temperature difference)

RFP (Respiration From Pleth), a parameter derived from the SpO₂ pleth signal (adult and pediatric only)

Patient monitoring within the wider Delta Platform.

Objective: Write clear use scenarios so the updated capabilities could be understood and tested, and then identify the safety-related tasks for uFMEA and usability-study planning.

We worked with stakeholders to separate confirmed behaviour from assumptions.

Clinical, risk, engineering, and capability owners confirmed the aged-values concept, the standard Delta alarm limits, and the ability to enable or disable RFP. Alarm limits apply to the RR parameter as a whole, so each RR source doesn’t get its own. We also flagged the 70 rpm ceiling on RFP, because other respiration sources allow higher limits.

02

Context and problem statement

The new and revised capabilities could be misread under ICU conditions:

Clinicians work through interruptions, alarm fatigue, and time pressure.

RFP is derived from SpO₂, but it still brings new interface behaviour and failure modes, including a delay before the first value appears, neonatal restrictions, and shared alarm limits.

For Continuous Temperature smart-cable workflows, the risks included choosing the wrong accessory, setting it up incorrectly, and making an infection-control mistake during disconnection or disposal.

The team needed to agree on the observable workflow:

What does the clinician do, see, decide, and verify, and where can that sequence fail?

03

User research and insights

Early stakeholder notes used inconsistent terms, including “error %” versus “rpm accuracy” and “age values” versus “H values.” We standardised the review language around aged values, accuracy in rpm, and the standard Delta alarm behaviour.

The SpO₂ scenarios already covered sensor selection, sensor application, cable connection, and numeric confirmation. If we’d repeated those steps for RFP, the new risks would have been harder to see, so the RFP scenarios only covered the safety-related behaviour specific to RFP.

While drafting the scenarios, we wrote down the interface questions we had to answer before anyone could trust the scenarios or the uFMEA:

What exactly happens when Neonate is selected (dialog, disabled state, auto switch-off, or feedback)?

Where exactly is RFP turned on and off (parameter menu, sidebar toggle, or context menu), and how does the UI show that it’s on by default for Adult/Ped?

How does the UI make it obvious which respiration source is active (ECG or pleth-derived), especially when both are available?

We took these questions to the UI architect and subject-matter experts. We focused on the behaviour a clinician could actually observe, and left implementation details out of it.

04

Conceptualization

The interface concept needed to:

Show the derived respiration parameter and its source clearly.

Use the existing Delta alarm model without implying a separate alarm system for RFP.

Explain delayed values, aged values, and source changes without making them look like device failures.

05

Wireframing

The low-fidelity sketches covered:

Source visibility: The active respiration source has to stay clear when ECG and pleth-derived respiration are both available.

Restriction handling: Selecting a neonatal patient must produce an explicit, testable RFP lockout.

Value states: When RFP is delayed or values are aged, the monitor must show them as known states, so they don’t look like device failures.

06

Cross-functional review and validation

We used the scenarios and interface artifacts to walk clinical, risk, engineering, and capability owners through the end-to-end behaviour.

Each review checked the same observable sequence: what the clinician sees, what they decide, what they can change, and what the monitor shows after the action.

The questions and decisions that came out of these reviews fed into uFMEA, formal usability planning, and implementation review, so they didn’t stay as ambiguous product notes.

07

Design decisions we enforced

Inheritance boundary: Physical setup stays in the SpO₂ scenarios. The RFP scenarios only start once the sensor chain is already connected.

Expectation management: RFP is allowed to appear later, and the scenario explicitly treats that delay as expected behaviour instead of an error.

Aged values language: We used the term “aged values” formally, meaning values whose age is known and that are still displayed.

Alarm alignment: RFP inherits its default alarm behaviour, including limits, from standard Delta alarming. It doesn’t introduce a separate “alarm system.”

Neonate restriction: This is a safety boundary, so the lockout has to be explicit in the UI, where clinicians can see it.

08

Outcomes

The work gave stakeholders an interaction design they could review, and a clear safety boundary for RFP and the Delta device add-on. With it, they could validate:

what the clinician sees, when they see it, and what the system expects them to do

how the Neonate restriction is enforced in a way that can be tested

how RFP fits into the existing alarm and respiration-source behaviour without creating UI states that contradict each other

We documented more than 14 scenarios covering how clinicians connect, use, and disconnect add-on devices at the bedside monitor. The scenarios identified risks around data loss, patient safety, and device management, but they don’t claim to eliminate those risks on their own.