Every clinician who runs an isometric assessment runs trials that shouldn't count. The patient doesn't follow instructions, the strap slips, the rep starts with a countermovement, the device drifts. The question isn't whether to exclude data, it's whether to keep the record of it.
ForceIQ separates the two actions deliberately.
Exclude vs delete
- Exclude keeps the trial on the session document. It still renders in the trial navigator, the data is still in the log, but it's flagged as excluded so it's pulled out of patient-level rollups (the dashboard trend lines, the LSI weighted average, the per-metric means).
- Delete removes the trial from the session entirely. The data is gone from the patient record. There's no audit trail of why and no path to recover it.
The right default is exclude. You want the audit trail. A clinician three months from now (possibly a different clinician on the same patient) should be able to look back and see that a trial was run but disregarded, and ideally why. That history is part of how clinical reasoning compounds.
Delete is reserved for cases where the trial genuinely shouldn't have been on the patient at all: wrong patient ID at upload, the file contained a calibration run, the assessment was aborted and re-run. Those are the cases where the audit trail is misleading rather than informative.
The common cases
1. Countermovement at onset
The patient anticipates the cue and pre-loads. The strain gauge sees a small downward dip in the moment before onset, the auto-detected onset may shift, and the RTD Early window opens "late" because muscle activation preceeded tension on the dynamometer. The slope you see isn't what you think you measured. The early-RFD literature is explicit about the cost: simple threshold-based onset detection has been shown to miss the true onset by 24 to 30 ms (Tillin et al. 2013), which is more than enough to invalidate an early-window RFD calculation on its own.
What to do. Exclude the trial, expecially for RTD metrics. We recommend against using a manual onset override because conceptually, it is impossible to know the extent of preactivation of the muscle. Click on the chart at the actual start of the rise. If the dip is pronounced enough that the contraction started from a non-zero baseline, exclude. The trial happened, but its metrics should not propagate.
2. Noisy baseline and poor effort
The patient is hesitant on the cue, the limb shifts mid-attempt, or the contraction simply never lands. The recording shows a small, slow rise that plateaus well below the patient's true capacity, and the pre-onset window often shows step-pattern noise from limb adjustments rather than a quiet resting baseline. The onset detector may still find a segment in the rise, but what it found is not a maximal effort.
What to do. Exclude, then re-run with a clear "as hard and as fast as possible" cue and a settled pre-trial baseline. Quiet the patient on the strap for two or three seconds before you say go. If repeat trials all look like this, the issue is usually setup (strap tension, posture, cue delivery, limb comfort), not the patient.
3. Downward drift through the plateau
The patient loses grip, fatigue sets in, effort wanes, or the strap migrates mid-contraction. Force decays steadily across what should have been a sustained hold. RTD values from this trial are fine because the early phase was real, but the plateau metrics (nRMSE, CV, Yank) reflect the slipping strap, not the patient's motor control.
What to do. If you only need RTD, keep the trial and note in the session notes that plateau metrics should not be read on this one. If you need a clean plateau, exclude and run another trial.
4. Spike artifact in an otherwise clean trial
One or two samples of impossible force, well past the patient's capability, drop into the middle of an otherwise clean trial. Usually a BLE dropout, or a connector glitch on a wired rig.
What to do. Spike outliers inside the active window are removed automatically before metrics are computed. You should see this on the chart: the spike disappears, the trace continues normally, no action required. If the spike was large enough to also corrupt onset detection (rare), override the onset manually.
5. Wrong file uploaded
You meant to upload patient A's right knee, but accidentally uploaded the file from the rep just before, which happened to be patient B's calibration run. Or a file from a previous session ended up duplicated on the same patient.
What to do. This is the case for delete. The trial was never part of this patient's assessment, and leaving it on the record (even excluded) implies it was.
What clean looks like
A clean trial has a sharp onset, a smooth ramp to peak, a sustained plateau, and a controlled release. Compared side by side with the trials above, the difference reads on the curve, not just in the numbers.
Why exclude is the default
The earlier prototype let clinicians delete trials with one click. That choice felt fast but it lost context. A clinician would exclude a trial in the moment, forget why, and have no way to reconstruct what happened later. The audit trail isn't paperwork; it's the thing that lets you and the clinician next to you reason about the same patient at different points in time.
You're going to exclude trials. That's normal. Use the default for the normal case, and reserve delete for the trials that don't belong on the record at all.
References
- Tillin NA, Pain MTG, Folland JP. Identification of contraction onset during explosive contractions. Response to Thompson et al. J Electromyogr Kinesiol. 2013;23(4):991-994. doi:10.1016/j.jelekin.2013.04.015