An injury assessment questionnaire typically asks about the injury itself -- location, mechanism, pain level, when it happened -- and the responses go into a queue for staff to review. The gap is that severity varies enormously across submissions, and a flat queue doesn't reflect that: a report describing sudden severe pain with loss of function sits next to a routine follow-up about a mild, improving strain, both waiting for the same scheduled review, unless something in the form itself flagged the difference at intake.
Building severity detection into the questions themselves
The questions an injury assessment already asks -- pain level, specific symptoms, mechanism of injury -- carry real severity signal individually, and combined, they carry more. The structural opportunity is using that combination to flag a submission the moment it's answered, rather than only after a person reads the full response.
- Identify which specific symptom combinations should trigger a flag, in advance. Not a single "severity" self-rating (people are notoriously inconsistent raters of their own pain), but specific reported symptoms -- numbness, loss of function, symptoms in combination that point toward something requiring prompt evaluation -- defined by whoever sets your clinical or intake protocol, not left to the form to guess at generically.
- Combine mechanism of injury with reported symptoms, not either alone. A given symptom can mean different things depending on how the injury happened -- the combination is more informative than either factor considered separately, and a rules-based system can evaluate both together.
- Flag the submission distinctly the moment a rule matches, before anyone reviews it manually. A flagged submission should be visibly different in the response queue from a routine one -- tagged, not just described in text a reviewer has to read closely to catch.
- Route flagged submissions to whatever your actual protocol calls for, whether that's a specific message to the respondent about seeking prompt in-person care, or internal escalation -- defined by your clinical or compliance team, not assumed generically by the form.
A questionnaire that collects severity information and doesn't act on it until a person reads it later collected the signal and then wasted it.
Being precise about what a form-level flag is and isn't
A rules-based flag on specific symptom combinations is a triage aid -- it surfaces submissions that likely need faster attention, based on rules your clinical or legal team defines. It is not a diagnosis or a substitute for professional evaluation, and the respondent-facing messaging on a flagged outcome should say so plainly, directing toward appropriate next steps (urgent care, an in-person evaluation) rather than implying the form itself determined anything clinically.
Building this without a developer
Multi-condition rules combining reported symptoms and mechanism of injury, flagging matching submissions distinctly in the response queue, are buildable visually using the logic engine's branching. The work is defining the specific symptom combinations that should trigger a flag, per your protocol, not building the flagging logic itself.