Build

CQL or flow logic?

Da Vinci DTR Questionnaires can branch with declarative rules, adaptive server calls, or CQL-driven pre-population — and the spec names a fourth option for clients. Pick a mechanism to see what the IG requires and who it obligates.

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. To see the mechanisms rather than read about them, the DTR Forms Lab fills a static form and the Adaptive Exchange replay walks a recorded $next-question transcript.

Static enableWhen

Client and payer

Declarative 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.

Fill a static form in the Forms Lab →

Answer the controlling question and watch a gated item appear. An item whose gate cannot be decided is shown and marked indeterminate, never quietly hidden.

DTR — spec-17 (enableWhen / enableWhenExpression)

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.

    Inferno — DTR payer server test kit

  • 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.

    Inferno — DTR payer server suite description

  • 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.

    DTR — expression-based population overview