The choice between static forms and SDC-driven FHIR Questionnaires is one of those decisions that looks technical at first and turns out to be mostly about organizational shape. A US practice that picks well saves itself months of operational pain; a practice that picks badly ends up rewriting its form layer eighteen months in. The criteria are not subtle, and they have less to do with FHIR per se than with who owns the form library and how often it changes.
This piece walks through the comparison for US practices. The wider buyer-side framing is in FHIR form builders for US hospitals: what you need to know in 2026; the LHC-Forms-versus-Form-Builder question is in LHC-Forms vs NLM Form Builder: a practical comparison. For additional FHIR walkthroughs, the rest of the series adds context.
What Each Approach Actually Is
Static forms are hand-coded UI in the practice's application stack, with the form structure expressed in HTML, JSX, or a similar template, and the data model defined ad hoc per form. They map well to a small number of stable forms and require an engineering effort to add or modify each one.
SDC-driven FHIR forms author the form as a Questionnaire resource, render it at runtime through an SDC-compliant renderer, and capture responses as a QuestionnaireResponse. The form is data, not code, which means non-developer staff can author and modify forms without an engineering ticket.
The architectural difference is whether the form library lives in code or in data.
Where Static Forms Still Make Sense
Static forms are the right choice when the form library is small and stable. A practice with five intake forms that change once a year does not benefit from the SDC machinery. The engineering cost of building five forms is lower than the cost of standing up a Questionnaire authoring workflow, especially in a greenfield product.
Static forms also fit when the form has heavy custom UX that the SDC spec does not cover. A diagnostic decision flow with a custom interactive visualization is not a FHIR Questionnaire, and trying to model it as one creates friction in both directions.
Where SDC-Driven Forms Pay Off
SDC-driven forms pay off when the form library is large or changes frequently. A practice with fifty or a hundred forms, with specialty-specific variations, with quarterly content updates from clinical informatics, benefits from a model where forms live as data the practice can author without engineering involvement.
SDC also pays off when the practice wants the form-driven data to land cleanly in the FHIR clinical store. QuestionnaireResponse extraction to Observations, Conditions, and Procedures is built into the SDC model. With static forms, that extraction is custom code per form.
The third advantage shows up at integration boundaries. A SMART on FHIR launched form on an Epic chart, a Cerner Open Forms intake flow, a patient-facing portal that shares forms with the EHR: all of these speak FHIR Questionnaire natively. Static forms have to be translated.
Operational Cost Profile
Static forms have a low cost per individual form (mostly engineering time) and a high cost per change (engineering deployment cycle). SDC-driven forms have a higher up-front cost (renderer, authoring tool, terminology integration) and a low cost per change (informatics-driven update).
The break-even is somewhere between 20 and 30 forms or one full change cycle, depending on the practice. Above that scale, SDC-driven forms are almost always cheaper to operate. Below it, static forms can still win.
How to Pick
Three questions usually settle it. How many forms will your practice have in production over the next three years. How often do those forms change in content. And does your clinical informatics team author content directly, or does it route through engineering.
For more than 30 forms, frequent changes, and informatics-led authoring, SDC-driven is almost always right. For fewer than 20 forms, infrequent changes, and engineering-owned content, static can still win. The middle ground is where the choice is least obvious and where most practices over-index on one path or the other.
The authoring-tool question is the natural next read, and LHC-Forms vs NLM Form Builder: a practical comparison covers the toolkit teams most often end up shortlisting.
Sources
- Base Questionnaire (defines the SDC-driven path, evergreen) - HL7 SDC IG v4.0.0-ballot
- FHIR Questionnaires WG (current SDC ecosystem discussion) - HL7 Confluence, May 2025
- PRO Data Collection Via Web/Mobile FHIR (real-world SDC vs static comparison context) - JMIR 2024