Case Study 2 — The Derivative on the Night Shift: Reading a Patient's Vital Signs

Field: Medicine / biomedical engineering Calculus used: the derivative as a function (§6.2), the sign of $f'$ as direction (§6.4), higher derivatives and concavity (§6.6), numerical differentiation (§6.2 Computational Note)


It is 3 a.m. in an intensive-care unit. A single nurse is responsible for six patients, each wired to a monitor that streams blood pressure, heart rate, and oxygen saturation second by second. No human can watch six scrolling traces continuously for twelve hours, so software watches with them — and the software's eyes are derivatives. This case study follows one patient's blood-pressure trace through a developing crisis and shows, step by step, how the first and second derivatives of a measured signal turn raw numbers into a warning that can save a life.

The signal and what its slope means

Call the patient's mean arterial blood pressure $B(t)$, in millimetres of mercury (mmHg), measured once per second. By itself, a single reading like $B = 118$ says little; what matters clinically is where the number is going. That is precisely what the derivative captures (§6.2). The first derivative $B'(t)$ is the rate of change of pressure, in mmHg per second:

  • $B'(t) > 0$: pressure is rising.
  • $B'(t) < 0$: pressure is falling — and a sustained, steep fall is one of the most urgent signals in critical care.
  • $B'(t) \approx 0$: pressure is steady, whatever its level.

The sign of $B'$ is exactly the §6.4 dictionary applied to a real measured function: where the trace rises, its derivative is positive; where it falls, negative; where it levels off, zero. A monitoring algorithm that knows only $B(t)$ is reading the present; an algorithm that computes $B'(t)$ is reading the trend.

But a falling pressure is not the whole story, and this is where the second derivative earns its keep. $B''(t)$ is the rate of change of the trend — the acceleration of the pressure (§6.6). Pairing the signs of $B'$ and $B''$ distinguishes situations that a first derivative alone would lump together:

$B'(t)$ $B''(t)$ Clinical reading
$< 0$ $< 0$ falling, and the fall is accelerating — deteriorating fast
$< 0$ $> 0$ falling, but the fall is decelerating — possibly stabilizing
$> 0$ $> 0$ rising and accelerating — rapid recovery (or rebound)
$\approx 0$ $\approx 0$ steady — no action needed

The middle two rows are the subtle ones. A patient whose pressure is dropping but whose drop is easing (negative $B'$, positive $B''$) may be responding to treatment; one whose drop is steepening (negative $B'$, negative $B''$) is heading toward collapse. The second derivative is what lets the algorithm tell the difference before the pressure itself reaches a dangerous level — the same concavity idea from §6.6, now doing triage.

A simulated crisis

Here is a trace built to mimic a real episode: a normal pressure with a gentle physiological oscillation, followed by a sudden hemorrhage-like crash beginning at $t = 180$ s. We compute the first derivative numerically with np.gradient, which uses the symmetric central difference of §6.2 internally, and raise an alarm when the pressure is falling faster than a chosen threshold.

import numpy as np
import matplotlib.pyplot as plt

rng = np.random.default_rng(0)
t = np.arange(0, 300)                              # 5 minutes, 1 Hz
B = 120 + 5 * np.sin(2 * np.pi * t / 60) + rng.normal(0, 0.6, t.size)
B[180:] -= 0.5 * (t[180:] - 180)                   # crash starts at t = 180 s

dB = np.gradient(B, t)                             # first derivative (mmHg/s)
threshold = -0.3                                   # falling faster than 0.3 mmHg/s
alarm = dB < threshold

fig, (ax1, ax2) = plt.subplots(2, 1, figsize=(10, 6), sharex=True)
ax1.plot(t, B, 'b-', lw=1)
ax1.fill_between(t, 80, 140, where=alarm, color='red', alpha=0.25, label='alarm')
ax1.set_ylabel('BP (mmHg)'); ax1.set_title('Blood-pressure trace'); ax1.legend()
ax2.plot(t, dB, 'r-', lw=1)
ax2.axhline(threshold, color='k', ls='--', label='alarm threshold')
ax2.set_xlabel('time (s)'); ax2.set_ylabel("dB/dt (mmHg/s)"); ax2.legend()
plt.tight_layout(); plt.show()

Figure CS2.1 — Top: the pressure holds near 120 mmHg with a slow oscillation, then crashes after $t = 180$ s. Bottom: its derivative $B'(t)$ hovers near zero during the stable period and plunges below the alarm threshold the moment the crash begins. The derivative flags the emergency essentially at onset — well before the absolute pressure would trip a simple low-value alarm.

The point of the figure is the timing. A naive monitor that alarms only when $B$ drops below, say, 90 mmHg would stay silent through the early, fastest part of the crash and sound only once the patient is already dangerously low. The derivative-based monitor reacts to the slope, so it fires while the pressure is still in a survivable range — buying the minutes that matter.

Why two time windows

Real monitors rarely compute a single derivative. Noise in the sensor makes the second-by-second slope jittery, and a genuine trend can be slow. So algorithms typically compute the slope over several windows at once: a fast derivative over roughly one minute, to catch acute crashes like the one above, and a slow derivative over fifteen minutes, to catch a gradual decline that no single second would reveal. This is the same derivative, estimated at two scales — and it illustrates a recurring numerical lesson from §6.2: the step size you use to estimate a slope changes what you see. Too short a window and noise dominates the estimate; too long and you blur away the very event you are hunting.

A note on noise and sampling. If you resample the trace at 100 Hz instead of 1 Hz, the raw central-difference derivative becomes worse, not better: the spacing $h$ shrinks, so sensor noise of fixed size gets divided by a tiny number and explodes. The cure is to smooth the signal before differentiating. This is a genuine subtlety — the limit definition says smaller $h$ is better in exact arithmetic, but with noisy real data there is an optimal, non-zero $h$. We meet the clean theoretical version of this trade-off in the error analysis of Chapter 23.

Beyond pressure: detecting each heartbeat

The same derivative reasoning runs at a much faster timescale inside the ECG. The electrocardiogram is a voltage signal $V(t)$, and each heartbeat produces a sharp spike called the QRS complex. A spike is exactly a place where $V$ rises very fast and then falls very fast — that is, where $|V'(t)|$ is momentarily huge. Beat-detection algorithms therefore do not look for the spike's height; they look for the spike's slope, flagging each instant where $|V'(t)|$ exceeds a threshold. Counting those slope events per minute is the heart rate. Heart rate, in other words, is a derivative of a derivative-detected count — calculus stacked two deep, running in the chest-lead amplifier of every monitor in the building.

Why this matters

Manual reading of monitor traces is slow and vulnerable to fatigue, and at 3 a.m. with six patients, no clinician can track every slope. Derivative-based algorithms flag a worsening trajectory within seconds of onset, and the gains are real: validated early-warning scores such as NEWS2 fold rate-of-change features into a single deterioration index, and machine-learning models trained on millions of patient-hours have learned subtler derivative signatures still, some of them able to anticipate cardiac arrest hours in advance. None of this is exotic mathematics. It is the derivative of a measured function — the central object of this chapter — pressed into service as an early-warning sense the human eye cannot match.

Connections to Other Chapters

  • The derivative as a function (§6.2): $B(t)$ is the function; $B'(t)$ is the trend the monitor actually watches.
  • Sign of $f'$ as direction, sign of $f''$ as concavity (§6.4, §6.6): the rising/falling/accelerating triage table.
  • Numerical differentiation (§6.2 Computational Note): np.gradient and the noise-versus-step-size trade-off.
  • Looking ahead — Chapter 18: integrating a rate gives an accumulated dose or total exposure; the integral of a vital-sign trace appears in long-term outcomes research as the area under the curve.

Discussion Questions

  1. Two patients both have blood pressure of 95 mmHg right now. One has $B'(t) \approx 0$; the other has $B'(t) = -2$ mmHg/s. Why should the monitor treat them completely differently, and which calculus quantity makes the distinction?
  2. Explain, using the sign table above, how the second derivative can signal that a falling patient is stabilizing before the pressure itself stops dropping.
  3. Why does a derivative-based alarm catch a crash earlier than a fixed-low-value alarm? Sketch the two traces and mark when each alarm fires.
  4. Increasing the sampling rate from 1 Hz to 100 Hz makes the naive numerical derivative less reliable. Using the limit definition's step size $h$, explain why — and what smoothing accomplishes.
  5. Consider the costs of false positives (alarm fatigue) versus false negatives (a missed crash). How should those costs shape where you set the derivative threshold?

Your Turn — Mini-Project

Simulate a heart-rate trace: random fluctuations around a baseline of 70 bpm, then a "fever response" beginning at $t = 600$ s in which the rate climbs by 40 bpm over the next five minutes. Then write a script that:

  1. computes the first and second derivatives of the trace with np.gradient;
  2. raises an alarm when the first derivative exceeds $+1$ bpm/s for a sustained interval;
  3. plots the trace, its derivative, and the alarm window together.

Bonus. Re-simulate at 100 Hz and recompute the raw derivative. Watch it dissolve into noise, then apply a moving-average smoother before differentiating and compare. You will have rediscovered, on real-looking data, the §6.2 lesson that estimating a derivative from measurements is a balance between resolution and noise.

Further Reading

  • Drew, B. J., et al. (2014). "Insights into the problem of alarm fatigue with physiologic monitor devices," PLOS ONE 9(10): e110274. The clinical cost of false alarms — exactly the trade-off behind threshold-setting in this case study.
  • Smith, G. B., et al. (2013). "The ability of the National Early Warning Score (NEWS) to discriminate patients at risk...," Resuscitation 84(4): 465–470. How rate-of-change features enter a deployed early-warning score.
  • Pan, J., & Tompkins, W. J. (1985). "A Real-Time QRS Detection Algorithm," IEEE Transactions on Biomedical Engineering BME-32(3): 230–236. The classic beat-detector built on the derivative of the ECG — the slope-threshold idea described above.

Derivatives are not abstractions confined to a textbook. They are running right now, in every monitor in every ICU, watching for the instant a patient's trajectory bends the wrong way.