A medical weight-loss intake commonly needs BMI as part of qualifying a prospective patient for a program or flagging them for clinical review before a consultation. The common way this gets handled is asking for height and weight as separate fields, then either asking the respondent to state their own BMI (which most people don't know off the top of their head) or leaving the calculation for staff to do after the form is submitted. Both add friction or delay to a step that a form's own logic can just handle.
Height and weight in, BMI out -- computed, not requested
BMI is a straightforward formula from two numbers the form already needs to collect. Computing it live, the moment both fields are filled in, removes an entire manual step -- for the respondent, who never has to know or look up their own BMI, and for staff, who receive a submission that already includes the computed value instead of raw inputs to calculate from later.
Structuring the intake around the computed value
- Collect height and weight as clean numeric inputs, with unit selection (imperial/metric) handled explicitly. A respondent shouldn't have to do unit conversion in their head before entering a number -- letting them pick their preferred unit and computing correctly regardless removes a source of bad data.
- Compute BMI immediately as a derived value, then use it in the form's own branching logic. Once BMI is computed, it becomes a variable the rest of the form can act on -- routing to different follow-up questions, or flagging the submission, based on which range it falls into.
- Branch clinical-relevant follow-up questions by the computed range, not a fixed set everyone answers. A respondent whose computed BMI falls in a range relevant to certain program eligibility criteria might need additional health-history questions that don't need to be asked of someone outside that range -- keeping the intake shorter for people who don't need the extra questions.
- Flag submissions in specific ranges for clinical review rather than automatic program assignment. Depending on your program's actual clinical protocol, certain computed ranges should route to a "requires provider review before proceeding" outcome rather than straight into a standard intake flow -- this is a protocol decision for your clinical team to define, not something a generic form template should assume for you.
A patient shouldn't have to leave your intake form, calculate their own BMI on a separate tool, and come back with the number. The form already has what it needs to compute it.
Being precise about what the form is and isn't doing
Worth stating plainly: a computed BMI value is a straightforward, well-defined calculation, and using it to branch an intake form's questions or flag a submission for review is a form-logic decision. What ranges mean for actual program eligibility, and what should trigger a required clinical review versus routine intake, is a clinical protocol decision that belongs with your provider or clinical team -- the form should be built to reflect whatever that protocol already specifies, not to invent the thresholds itself.
Building this without a developer
Computing BMI live from height and weight inputs, and branching follow-up questions or flagging submissions by the resulting value, is buildable visually using the logic engine's computed variables. The work is encoding your program's specific clinical protocol into the branching rules, not building the calculation itself.