Numeric delays are fixed within a case, different between cases¶

With each numeric's algorithm held fixed, delays were fitted for every case and every 30-minute block. They do not drift within a case, but 40–70% of their variance lies between cases, so a single population delay is wrong by up to 2 s for HR and 1 s for the others. Each case gets its own delay label.

Data¶

900 random cases with SNUADC and Solar8000, then 6,387 of 6,388 cases (one file too large for the analysis machine); Primus ETCO₂ and PIP refitted in all 6,199 Primus cases on 13 October.

Method¶

The pilot's consensus algorithm for each track; the delay fitted per case and per 30-minute block with the same uniform-phase likelihood; variance split by a one-way random-effects model on the block delays (between-case SD, within-case SD, intraclass correlation); case delays compared with set-up variables and across tracks.

Results¶

• No drift within cases (median 0 s/h).
• Shared offsets within a device family: the three arterial pressure delays correlate at ρ 0.86–0.92; across families hardly at all.
• HR is the only track whose delay follows the Solar8000 port (η² 0.35): two groups (Two heart-rate delay groups, one poll apart).
• The first Primus fit gave ETCO₂ a delay of −1.5 s, which the availability rule forbids: the hold until the next breath had been counted twice. Refitted with a one-record phase, every median delay is positive.

Discussion¶

One delay per case is enough; per-record labels are not needed. Per-case labels (numeric_delay) carry the delay, its standard error (median 0.15–0.29 s, 1.0 s for RR) and a quality flag; 607 per-case delays that still come out below zero are flagged weak. The population distribution is the prior where a case cannot be fitted.

Observations it supports¶

Worked examples¶

Code¶

• vitaldb-bench: tools/numeric_delay_variability.py, tools/numeric_delay_labels.py

Figures¶