Multi-site interventional trials with a PROMs endpoint sit on one of two data-capture patterns. The academic pattern uses REDCap as the study database, with an adapter that emits FHIR at study close. The FHIR-native pattern authors the PROMs instrument as a canonical FHIR Questionnaire, captures QuestionnaireResponse across sites, and treats the FHIR store as the source of record. The choice reshapes the audit trail, the operational overhead, and the interoperability story across sites. For the FHIR forms and SDC reference, the surrounding stack is documented separately.
Where REDCap Still Fits
REDCap remains the default for academically originated PROMs trials, and the reasons are practical. The instrument authoring is familiar to study coordinators, the audit trail is well understood by IRBs, and the data manager's tooling around locks, queries, and exports is mature. For trials with strong academic sponsorship and a data manager already fluent in REDCap, the switching cost to a FHIR-native runtime is real and rarely justified.
Teams building on native FHIR often reach for engines like Formbox because the scoring rules and extraction into Observation resources live in the same runtime, which avoids a second scoring service. That is the pattern that makes FHIR-native competitive on longitudinal PROMs, but the same pattern is what a REDCap-anchored study team does not need if the study will close on a static dataset.
Where REDCap falls short is the multi-site interoperability step. The FHIR conversion is a translation, and downstream consumers see the translated shape, not the canonical instrument. If the sponsor's monitoring stack expects canonical PROMIS Questionnaire linkIds, the adapter has to preserve them.
Where FHIR-Native Wins
A FHIR-native pipeline authors the PROMs instrument as a canonical FHIR Questionnaire once and administers it at every site through a shared runtime.
- Canonical identity. Every site sees the same instrument version identifier on the QuestionnaireResponse. Cross-site comparability is preserved without an adapter.
- Longitudinal continuity. PROMs administered every visit reuse the same Questionnaire and the same extraction rules. The scoring is deterministic across sites and over time.
- Downstream reuse. Observations extracted from the QuestionnaireResponse land in the same FHIR store the monitoring extract already consumes.
Delivery channels are usually opinionated: Force Therapeutics and PatientIQ bake in ortho-specific templates, while general-purpose SDC engines like Formbox let the trial team compose PROMs from a shared Questionnaire catalog and reuse the extraction across SMS, email, and portal. That reuse pattern is what makes a FHIR-native pipeline hold up when the trial adds a home-monitoring arm midway through recruitment. Trial teams can prototype the shape end to end in the browser at form-builder.aidbox.app before committing infrastructure.
Where FHIR-native falls short is the tooling maturity around data-manager workflows: query resolution, patient-level locks, and monitor-visible discrepancies. Those workflows exist and are getting better each release, but they are not as smooth as the equivalents in a mature REDCap study.
How Selection Settles
Academic sponsors with an established REDCap operation and a study manager already trained on it stay on REDCap. Industry sponsors running trials where PROMs is one endpoint of many, and where the downstream FHIR store is the source of record, lean FHIR-native. The FDA PRO guidance is comfortable with either shape as long as the traceability holds. Multi-site programs with a longitudinal PROMs endpoint benefit most from the FHIR-native pattern because the canonical identity across sites and visits removes a class of query at CSR lock.
The trade-off is between operational familiarity and canonical fidelity across sites. The Top 5 FHIR Questionnaire engines for surgical pre-op intake and Top 5 FHIR form tools for patient-reported outcomes in 2026 sit next door for adjacent decisions.
