A surprising number of patient-survey projects still begin with the same question: do we really need SDC, or can we just ship plain HTML forms that POST to our backend? The answer depends less on the survey itself and more on what happens to the responses afterward. The trade-off is real, and the right choice is rarely the same across an entire health system. The FHIR form builder buyer's guide sets up the broader context; this comparison narrows in on the HTML-versus-SDC question specifically.
For more pieces in this format, the rest of our FHIR reviews cover adjacent comparisons.
Where Plain HTML Forms Are Honestly Fine
A plain HTML form is the lower-effort path, and for some uses it is the right one. A one-off marketing landing-page form, a single satisfaction survey, or a development-team feedback survey are all cases where standing up a FHIR-native authoring tool is overkill. The data is not going into the EHR, the questions are not going to be reused, and nobody is going to compute a risk score from the answers. In those cases the engineering time for plain HTML is genuinely shorter and the maintenance burden is lower.
Plain HTML also wins when the survey is short-lived and disposable. A flu-season screening form that will run for six weeks and never come back does not need to be authored as a FHIR Questionnaire. Treating SDC as the universal default produces a stack of FHIR resources nobody will ever query again.
Where SDC Pulls Ahead Quickly
For anything that touches the clinical record, the calculus flips. SDC stores the form definition and the response as FHIR resources, which means the same form is renderable on the patient portal, the kiosk, the clinician-facing intake screen, and the post-op follow-up app, without re-authoring per surface. That alone pays the SDC tax back within the first two or three clinical workflows that reuse a form.
Computable expressions are the second clear win. An SDC questionnaire can compute scores, validate inputs against value sets, and branch on conditions without a server round-trip. A plain HTML form that wants any of that ends up reinventing a small SDC engine inside the front-end, which is exactly what SDC was created to avoid. The best SDC form tools for pre-op patient intake review covers a workflow where this computation lift is non-negotiable.
Longevity is the third axis. Plain HTML forms tend to live as long as the front-end framework they were built in; SDC questionnaires outlive frameworks because the standard is the data model.
How to Pick for a Given Project
The honest decision rule is to ask three questions. Does the response data flow into the patient record? If yes, lean SDC. Will the form be rendered on more than one surface? If yes, lean SDC. Does the form need to compute or validate anything beyond required-field checks? If yes, lean SDC. If all three answers are no, plain HTML is the lower-friction path, and the open-source versus vendor-hosted FHIR form tools comparison is the read for when the answers start trending yes.
Sources
- SDC IG introduction and use cases - spec, HL7, evergreen
- FHIR R5 Questionnaire resource - spec, HL7, evergreen
- registry of conformant SDC implementations - wiki, HL7, evergreen