Conditional logic in SDC forms is one of those features that vendor demos handle gracefully and production deployments expose mercilessly. The Structured Data Capture IG defines enableWhen and enableBehavior as core mechanisms for showing or hiding questions based on previous answers, plus the heavier expression-based dynamic behavior using initialExpression, calculatedExpression, and answerExpression. Tools that implement the basic case well are common; tools that implement the expression-driven case reliably are fewer.
This piece looks at five SDC form engines that handle conditional logic credibly in production. The wider buyer-side context is in FHIR form builders for US hospitals: what you need to know in 2026; the related repeat-groups challenge sits next to it in 4 FHIR form tools that handle repeat groups without pain. For the FHIR knowledge collection, the rest of the series adds context.
What Conditional Logic in SDC Actually Means
There are two layers. The simpler layer is enableWhen: a question or group becomes visible based on a comparison against earlier answers (show this question only if the patient is over 65). Most renderers handle this layer adequately because the logic is declarative and bounded.
The heavier layer is expression-driven: calculated expressions that compute a result from previous answers, initial expressions that pre-populate a question from FHIR context, and answer expressions that evaluate a value set against runtime state. This layer relies on FHIRPath evaluation against the in-progress QuestionnaireResponse, which is where implementations diverge.
A form engine that handles both layers is one that holds up against real clinical forms.
The Five Engines That Handle It
The list below leans on what shows up in real production deployments with non-trivial conditional logic. Order reflects fit-for-purpose, not feature count.
- LHC LForms. The Lister Hill team's open-source library implements enableWhen and the SDC expression set reliably, with strong FHIRPath support and a clean approach to evaluating expressions against the partial QuestionnaireResponse. It is the reference quality bar for open-source SDC.
- OntoServer Forms. CSIRO's tooling extends OntoServer's terminology engine with form-rendering and expression evaluation. The advantage is integration: terminology-driven expressions (answer lists from a current ValueSet expansion) work without manual glue.
- Aidbox SDC IDE. Aidbox SDC handles the expression layer cleanly and supports the calculated-expression patterns that real clinical forms use. The IDE is a useful design-time tool, and the runtime evaluates expressions against the in-progress response without surprises.
- Smile Digital Health Forms. Smile's form layer evaluates SDC expressions through the broader HAPI FHIRPath implementation, with managed-service operational tooling on top. The vendor relationship covers the runtime side.
- Formbox. Designed around the expression-driven SDC patterns from the start, with a runtime evaluator that handles answer expressions and calculated expressions in patient-facing contexts (including offline-capable mobile renderers).
Where Conditional Logic Tends to Break
A few failure patterns recur in form engines that claim conditional logic support but stumble in production.
- enableBehavior with mixed any/all conditions is handled inconsistently. Some engines treat all conditions as a logical AND regardless of the declared behavior.
- Calculated expressions that depend on terminology lookups time out or return stale values when the terminology server is slow.
- Initial expressions that pull from FHIR context (patient resource, encounter) silently fail when context is not pre-loaded.
- Expressions that reference repeating groups produce unpredictable results because the FHIRPath engine treats the indexing differently than the form designer expected.
The fix in each case is to test conditional logic with the actual forms you intend to deploy, not the vendor's demo forms.
How to Pick
For research-leaning workflows where the validated instrument library matters, LForms is the default. For terminology-heavy clinical forms with deep ECL-driven value set expressions, OntoServer Forms is the closest fit. For full-stack Aidbox or Smile deployments, the in-platform tooling is usually the right answer.
The deeper repeat-groups challenge is where these same engines show different behaviors, and the 4 FHIR form tools that handle repeat groups without pain breakdown covers the parallel question.
Conditional logic is the SDC feature that production traffic tests hardest. The engines that handle it well save your team from writing custom evaluation code, which is the kind of cost that adds up fast across a portfolio of forms.
Sources
- Base Questionnaire StructureDefinition (enableWhen, expressions, evergreen) - HL7 SDC IG v4.0.0-ballot
- Clinical Reasoning Questionnaires (expression evaluation, evergreen) - HAPI FHIR project docs
- SDC enableWhen and expression handling in NLM tooling - PDF slides, Ye Wang (NLM), DevDays 2024