Build
CQL or flow logic?
These are spec citations, not product capabilities. The validation workbench does not execute CQL or run $next-question. The CQL Simulator runs curated teaching ELM against synthetic bundles only. For what CQL is and why DTR uses it, see the library card.
Static enableWhen
Client and payerDeclarative show/hide rules on Questionnaire items — no server round-trip for simple branching.
Standard and adaptive Questionnaires SHALL use logic — including static enableWhen (and enableWhenExpression for expression-based rules) — so only questions and answer choices required for the intended purpose are shown, based on answers already provided or pre-populated. For adaptive forms, DTR servers SHOULD return as many items as possible in one call when simple enableWhen logic is enough to decide what is enabled.
Caveats that matter in practice
Client vs payer obligations
Flow control (enableWhen, $next-question) and pre-population (initialExpression) split across both sides: payers author Questionnaires, Libraries, and adaptive responses; DTR apps and Full EHRs render, populate, validate, and complete QuestionnaireResponses. Inferno’s payer-server suite checks that returned Questionnaires include libraries and expressions to support pre-population — not that a client executed CQL correctly.
What Inferno actually tests
For payer servers, Inferno checks that CQL is present for pre-population in returned Questionnaires but does not currently validate correctness or executability of that CQL. The MAY-alternative rule (spec-63–64) governs clients — it is not what Inferno exercises on a payer server response.
What ImOnFHIR does today
The validation workbench does not execute CQL, run $next-question, or pre-populate QuestionnaireResponses. The CQL Simulator executes curated teaching ELM against synthetic bundles only — not live DTR. This page is a spec explainer.