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.gradientand 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
- 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?
- Explain, using the sign table above, how the second derivative can signal that a falling patient is stabilizing before the pressure itself stops dropping.
- 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.
- 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.
- 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:
- computes the first and second derivatives of the trace with
np.gradient; - raises an alarm when the first derivative exceeds $+1$ bpm/s for a sustained interval;
- 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.