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, 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 preceded 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, especially when you need RTD from it. We recommend against a manual onset override here: the muscle began activating before the dip, and no marker position on the chart can tell you how far before, so the early window is compromised wherever you put it. The trial happened, but its metrics should not propagate. Re-run it with a steady, light hold on the strap before the cue.
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 you can" 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 Control metrics on the plateau (Drift from peak, Steadiness and Smoothness: nRMSE, CV and 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 the Control 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.
Try it in the Dynamometry Lab: practice keep-or-exclude calls on nine real and simulated trials, with feedback on each.
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