conecion

conecion

FHIR Questionnaire vs Custom JSON Forms for Patient Surveys

Patient surveys sit at an interesting fork in the road for modern healthcare apps. The team can model the form as a FHIR Questionnaire and lean on the standard, or roll a custom JSON schema and own every behavior. Both choices work; they fail in different ways. Knowing which failure mode the team can absorb is the real decision.

Below is a head-to-head on the parts that matter. For the broader landscape, see the complete guide to FHIR form builders for modern healthcare stacks, and the FHIR reference shelf covers the surrounding standard.

The Case for FHIR Questionnaire

FHIR Questionnaire brings four things that are hard to recreate by hand:

  • A widely adopted shape for survey data, which makes the responses useful to downstream apps and registries.
  • Built-in concepts for conditional rendering (enableWhen), calculated expressions, and value set binding.
  • A QuestionnaireResponse resource that pairs with the Questionnaire and slots into the rest of the FHIR record cleanly.
  • A growing ecosystem of renderers, validators, and authoring tools.

For teams that need patient survey data to be queryable, exchangeable, or comparable across cohorts, FHIR Questionnaire is the safer default.

The Case for Custom JSON

A custom JSON form schema brings two things that FHIR Questionnaire makes harder:

  • Total freedom over the schema shape. If the survey needs a structure that FHIR did not anticipate, custom JSON lets you express it without bending the standard.
  • A smaller runtime footprint. Custom JSON does not require an SDC renderer; a small TypeScript module can interpret the schema and render the form.

Teams that ship a small fixed set of surveys, or surveys that will never travel beyond the host app, sometimes find custom JSON easier to maintain.

Where the Real Cost Hides

The cost of the FHIR Questionnaire path is the learning curve and the runtime surface area. The cost of the custom JSON path is everything you have to rebuild over time: conditional logic, validation, terminology binding, versioning, response migrations. Most teams underestimate the second cost in the first month and rediscover it in the second year.

For teams that ship many surveys or that need the data to integrate with other clinical workflows, the best FHIR Questionnaire tools for enterprise healthcare covers the production tooling that takes the runtime work off the team.

A Practical Decision Path

A short decision rubric that holds up:

  1. Will the survey responses ever need to be exchanged with another system? If yes, FHIR Questionnaire wins by a wide margin.
  2. Does the survey need conditional logic beyond two or three branches? FHIR Questionnaire with enableWhen and FHIRPath expressions saves you from writing the same logic by hand.
  3. Does the survey need terminology binding (LOINC items, ValueSet answer options)? Custom JSON makes this painful.
  4. Is the survey a one-off marketing or research instrument with no clinical reuse? Custom JSON is acceptable.
  5. Is the team comfortable shipping and maintaining their own renderer over multiple years? Custom JSON requires that comfort.

In modern healthcare stacks, the answer almost always lands on FHIR Questionnaire. The exceptions are usually narrow: a single low-stakes survey, a research instrument outside the clinical workflow, or a team that has a specific reason to avoid the FHIR ecosystem.

A FHIR Questionnaire is rarely the most exciting piece of a patient survey project, but it tends to be the piece that ages best. Custom JSON looks easier at the start and harder at year three. Picking based on the year-three cost is usually the right call.

Sources