Conecion

Practical FHIR notes on SDC form builders and terminology server implementations for healthcare integration teams.

Top 5 FHIR Form Builders for SMART on FHIR Apps in 2026

SMART on FHIR apps have a tighter set of constraints around form layers than general FHIR apps do. The form has to launch from an EHR context, respect the scopes the launcher granted, and behave reasonably when the user's session is short. A FHIR form builder that fits a SMART app keeps those constraints invisible. One that does not leaks them into every clinical workflow.

Five FHIR form builders that hold up inside SMART apps are listed below. The broader picture lives in the complete guide to FHIR form builders for modern healthcare stacks, and additional FHIR background reading covers the SMART context.

What SMART on FHIR Asks of the Form Layer

Three constraints come up in almost every SMART app:

  • OAuth scopes. The form layer should only request the scopes it actually needs. A form that asks for patient/*.read when it only writes a QuestionnaireResponse is a security smell that procurement notices.
  • Launch context. The app launches with a Patient and Encounter in context. The form should prepopulate from that context without an extra round trip.
  • Session lifetimes. SMART sessions can be short. The form needs to persist work in progress and recover gracefully when the token refreshes.

A FHIR form builder that addresses these in its core, rather than as an afterthought, is a much shorter path to a clean SMART app.

The 5 FHIR Form Builders for SMART Apps

  1. Aidbox Forms. Server-side validation and SDC support that work well with a SMART launcher's identity model. Strong fit when the SMART app also runs against an Aidbox-style FHIR backend.
  1. LHC-Forms in a SMART app. The renderer plays well with the SMART JavaScript clients, and the prepopulation hooks fit the launch context cleanly.
  1. Medplum form components. Typed React components inside a SMART app that also gives you a typed FHIR client. Good ergonomics for a small team.
  1. HAPI FHIR Questionnaire module. A practical option when the SMART app's backend already runs HAPI. The integration story is straightforward and the auth model fits.
  1. Open Health Hub Questionnaire engine. A fit for SMART patient-facing apps in particular, where the survey is asynchronous and the patient may complete it outside the launch window.

For the renderer side specifically, the top SDC renderers for React-based patient portals covers the patient-facing rendering choices in more depth.

Common Mistakes in SMART Form Layers

A few patterns that trip up SMART apps with forms:

  • Overscoping. The form layer requests broad read scopes because the renderer "might need" them. Trim to exact needs.
  • Ignoring launch context. The form is built without using the context that the EHR already provided. The clinician then re-enters the patient ID.
  • Token refresh mishandling. The form does not gracefully recover when the access token refreshes mid-session, and the clinician loses unsaved input.

All three are fixable, but they need to be addressed in the form layer itself, not patched on top.

A Quick SMART Form Check

A short test to run on any candidate FHIR form builder inside a SMART app:

  1. Launch the app from a SMART sandbox with the most realistic scope set.
  2. Open a representative form and watch what gets prepopulated. Compare to expectation.
  3. Wait long enough for a token refresh, then continue filling out the form. Check for data loss.
  4. Submit, then verify the QuestionnaireResponse lands with the right references.

A FHIR form builder that handles all four steps without surprises is a strong candidate. One that fails on the refresh or scope checks usually requires more engineering than the alternatives.

Sources

— Tara Buckman