A mobile patient app that asks the user to fill out a FHIR Questionnaire needs an SDC renderer that produces a clean, finger-friendly form on a small screen. That sounds obvious. In practice, several otherwise capable SDC renderers ship a desktop-shaped layout that breaks the moment the form runs on a phone, and the team finds out only after the first batch of patient feedback. The four renderers below handle the mobile case well enough to ship without a long bring-up. For broader background, see related FHIR tooling reviews.
The FHIR SDC form builders reference guide covers the architectural picture; this list narrows it to mobile patient apps specifically.
The 4 Renderers Worth Knowing
- LHC-Forms. The open-source NLM renderer with a mobile-friendly default layout, used in mobile-first FHIR projects across NIH-funded research and clinical pilots.
- Aidbox FHIR Forms. The SDC form layer of the Aidbox FHIR stack, with mobile rendering that holds up cleanly under iOS Safari and Android Chrome.
- Formbox. Health Samurai's standalone SDC form builder, with a responsive renderer that fits well into embedded mobile webviews and progressive-web-app shells.
- Medplum Questionnaire UI. The form layer of the Medplum platform, with a React-based renderer that fits cleanly into React Native and Expo-based mobile patient apps.
What Matters in Mobile Patient Apps
Three rendering behaviors decide whether a renderer is usable on a phone.
The first is input-control selection. SDC questions can map to checkboxes, radios, dropdowns, or specialized controls; a renderer that picks the wrong control for a mobile screen, such as a desktop dropdown for a short list of answers, produces a tap-and-scroll experience that drives abandonment. The second is keyboard handling. iOS and Android keyboards behave differently around numeric input, date input, and autofill; a renderer that fights the OS keyboard produces a frustrating completion experience. The third is partial-state persistence. Patients pause and resume; the renderer has to support saving the QuestionnaireResponse mid-form without losing answers when the app backgrounds.
The top FHIR Questionnaire engines for telehealth walkthrough covers the broader engine choice that surrounds the renderer pick.
How to Approach the Decision
Selection turns on the mobile app's host stack and the team's appetite for owning the renderer.
A React Native app usually picks Medplum Questionnaire UI for the native React integration, or Formbox if the app is comfortable embedding a webview-hosted renderer. A Swift or Kotlin native app usually wraps LHC-Forms in a webview, since the FHIR-shaped logic is hard to reproduce natively and the LHC-Forms renderer holds up well in that pattern. A team already on Aidbox picks Aidbox FHIR Forms for the single-vendor experience and the integrated extraction pipeline.
For the validation side of mobile forms, the top FHIR form engines with strong validation walkthrough covers how the same renderers handle answer-constraint validation, which matters more on mobile than on desktop because the user cannot easily review a long list of errors on a small screen.
The honest test of an SDC renderer in a mobile app is patient completion rate. A renderer that produces a clean mobile experience does its job. Everything else is feature detail. A working layer in this part of the stack is mostly invisible; if the team is still discussing it weekly a year later, the layer is doing too much. Teams that get this right twice in a row tend to stop noticing the layer at all, which is exactly the goal.
Sources
- LHC-Forms widget - Docs, NLM LHNCBC, 2024
- SDC Introduction (rendering extensions) - IG, HL7, 2024
- On-the-Fly Data Capture for FHIR/HL7 V2 - PDF, NLM LHNCBC, 2018