Sensors & devices

In one line

A sensor turns something physical — pressure, light absorbance, voltage — into a number. Every step between the patient's body and the number on the chart is a place that number can go wrong while still looking entirely plausible.

The chain nobody draws

The chart shows SpO₂ 94%. Here is what actually happened:

physiology → transducer → analogue signal → amplification → filtering
   → sampling (ADC) → processing/algorithm → display → transmission → EHR

Every arrow is a lossy step with assumptions baked in. The clinician sees the last box and reasonably treats it as a measurement of the patient. It is a measurement of the end of that chain.

Take the pulse oximeter, since it's the sensor everyone trusts most. It does not measure oxygen in blood. It measures how much red and infrared light gets through tissue, and infers saturation from the ratio, using a calibration curve derived from healthy volunteers. That inference is excellent — until the assumptions break.

When the number lies

The failure modes are specific, well-documented, and mostly invisible on screen:

• Poor perfusion — cold, shocked, or vasoconstricted patients: the pulsatile signal the algorithm needs is barely there.
• Motion — a shivering patient produces beautiful, wrong numbers.
• Nail polish, dirt, ambient light — physical interference with an optical device.
• Skin pigmentation. This one matters and was under-acknowledged for decades: pulse oximeters have been shown to overestimate saturation in patients with darker skin, meaning hypoxaemia gets missed in exactly the patients least well served by the system already. It's a calibration problem, and it is also a health-equity problem — the device was validated on a population that wasn't everyone.

The point generalises. A device is validated on a population, under conditions. Use it outside those and it doesn't error — it produces a confident number that means something different from what you think.

Sampling, aliasing, and why the waveform matters

Sampling rate decides what you can see. Sample too slowly and you don't just lose detail — you can reconstruct a signal that was never there (aliasing). This is why ECG has a specified sampling rate: too low, and morphology that carries the diagnosis simply disappears.

There's a practical consequence for informatics: the EHR usually stores the number, not the waveform. A heart rate of 103 is stored; the rhythm that produced it isn't. When you build analytics on charted vitals, you are analysing a heavily-processed summary of a signal you never saw — and any artefact the algorithm resolved, it resolved silently.

Getting the number into the record

• IEEE 11073 — the device-communication family that gives devices a common language and nomenclature, so a monitor and an EHR can agree what "MDC_PULS_OXIM_SAT_O2" means.
• BLE/GATT for wearables and home devices.
• HL7 v2 ORU messages still carry a great deal of device data into hospital systems; FHIR Observation is where new work goes.
• Edge processing — because streaming raw waveform from every bed to the cloud is neither affordable nor necessary.

The informatics lesson

Two habits worth forming:

Store the provenance. Which device, which mode, which timestamp — from the device's clock, not the server's, and be aware that those clocks disagree. When you later find an implausible value, provenance is the only thing that tells you whether it was the patient or the machine.

Distrust the smooth ones. Averaged, filtered, cleaned data looks better on a chart and hides exactly the artefacts you need to see. The digital twin lab is built on this: a model fitted to a plausible number that was wrong will produce a plausible prediction that is also wrong, and it will look great.