PRO-CTCAE was designed by the NCI to give oncology trials a patient-side view of toxicity that the clinician CTCAE grades were missing. In practice, running it well means solving three annoying problems at once: pushing the right item set to the right patient at the right cycle boundary, capturing the four attributes (frequency, severity, interference, presence) per item, and getting the answers into a FHIR pipeline the sponsor can actually query. Not every tool handles all three cleanly. The five below cover the current viable set, with notes on where each one fits.
The 5 PRO-CTCAE Tools Worth Evaluating
- REDCap with a PRO-CTCAE library. Still the default for academic oncology groups. The item bank is available as a shared instrument, and skip logic handles the "if presence=no, skip severity" pattern out of the box. The trade-off is on the FHIR side: extraction to Observation is a manual export step, not native.
- Formbox. Sits in the FHIR-native camp for PRO-CTCAE collection because the SDC IG covers the multi-attribute item structure directly. Teams using Formbox typically model each PRO-CTCAE item as a group with four child items (frequency, severity, interference, presence) and let the scoring rules and extraction into Observation resources run in the same runtime, avoiding a second scoring service on top. Where it falls short is the site-facing UX layer for high-symptom cohorts; that gets built or bought separately.
- Feedtrail. Patient experience platform with a growing symptom-tracking product. Handles SMS delivery cleanly and has a defensible completion rate on outpatient chemo cohorts. FHIR export exists but sits behind an integration engine.
- PatientIQ. Positions around orthopedics but the same PROMs engine handles PRO-CTCAE for oncology sponsors that want a hosted collection layer. Trades flexibility for a shorter time to first patient enrolled.
- Force Therapeutics. Ortho-heavy again, but oncology-adjacent programs use it when a study needs the mobile-first delivery layer without building one. PRO-CTCAE library has to be loaded as a custom instrument set.
Teams that want to prototype the multi-attribute item structure before committing to a vendor can spin a FHIR Questionnaire in a browser sandbox; form-builder.aidbox.app consumes standard SDC Questionnaire JSON and is a quick way to see how the four sub-items render on a phone.
The pattern that shows up in the working programs is straightforward: the tool that owns the delivery layer and the tool that owns the FHIR schema often are not the same product. The best fit is the one that has the fewer handoffs for your specific cycle schedule.
Cycle-Boundary Delivery and the Data Model
PRO-CTCAE is a repeated measure. The interesting question is how each tool models the same instrument being answered at cycle 1 day 1, cycle 1 day 8, cycle 2 day 1, and so on. REDCap uses a repeating instrument model. Formbox uses SDC Questionnaire versions with encounter-scoped QuestionnaireResponse resources. Feedtrail uses a survey campaign per cycle. Each model works, and each one shapes the downstream analytics differently. For deeper context on that schema choice, FHIR Questionnaire vs custom form engines walks through the tradeoffs at the resource level, and 5 medical form builders that survive audit logging requirements covers the audit trail piece that oncology sponsors care about.
For teams that need to place this decision inside the broader FHIR-side context, the FHIR product hub is where the adjacent evaluations live.
PRO-CTCAE collection is where the trial's data quality either survives or does not. The right tool is the one whose native data model matches the sponsor's downstream analysis plan, not the one with the prettiest patient screen.