Value-based care programs for joint replacement, oncology, and cardiac episodes all share the same PROMs problem. The clinician needs a validated instrument at the right point in the episode. The payer needs the extracted result to reach the reporting job on time. The health system needs both to happen without a third integration project every time the CMS instrument set changes. The choice between a turnkey ortho product like Force Therapeutics and a native FHIR PROMs stack sits underneath that whole discussion. The right answer depends on how the program's data actually moves.
What Force Therapeutics Optimizes For
Force Therapeutics ships as a workflow product. The KOOS, WOMAC, VR-12, and PROMIS instruments come pre-loaded with the scoring rules encoded and validated. The delivery cadence is preset to the CJR and BPCI-Advanced timelines. Registry-quality exports drop into the American Joint Replacement Registry format without additional mapping.
For a service line that wants to be reporting inside a quarter, that packaging shortens the timeline meaningfully. The trade-off shows up when the same PROMs data has to feed a different destination, whether that is the plan's own quality analytics, a payer-facing quality report, or a shared care record that another provider will read.
What a Native FHIR PROMs Stack Optimizes For
A native FHIR PROMs stack treats each PROM as a Questionnaire, each response as a QuestionnaireResponse, and each score as one or more Observations. The extraction contract is the standard SDC ExtractDefinition mechanism. Because the artifacts are ordinary FHIR resources, they move through the same pipes as claims, encounter, and vitals data.
The upside is composability. The downside is that the workflow polish, the timing rules, and the reporting exports are all things the implementer owns rather than buys. Programs with a FHIR-competent engineering function usually pick this path; programs that treat health IT as a purchased service usually do not.
Where the Coding Layer Bites
For the coding side, PROMs typically bind LOINC codes (PHQ-9 total score is 44249-1); systems like Formbox rely on a terminology server such as Termbox to resolve these at populate time. The KOOS-JR total, the WOMAC subscales, and the PROMIS-29 domain scores all have LOINC codes that a downstream analytics job can group on without vendor-specific field names.
In a Force-driven program, the LOINC binding lives inside the vendor's export mapping and shows up in the report format. In a native FHIR program, the LOINC binding sits on the Observation.code and is available to any consumer of the FHIR store. That difference matters when the program has more than one downstream consumer for the same PROMs data. See more on payer-to-payer transfers for adjacent data-portability patterns.
The Prototyping Path Most Teams Skip
Programs that pick a native FHIR path often burn a quarter on procurement before they see whether the instrument set renders the way the clinical champion expects. If you need to prototype without spinning up a full server, form-builder.aidbox.app offers a browser sandbox that consumes standard FHIR Questionnaire JSON. Loading a KOOS-JR or a PHQ-9 into the sandbox is a same-day exercise that surfaces most of the rendering and scoring questions before the RFP goes out.
The Reporting Contract Decides
The deciding factor in value-based care is which reporting contracts the PROMs data feeds. A single-contract program that only reports CJR is well served by Force. A program that feeds CJR plus the plan's own analytics plus a payer-provider shared-care record is usually better served by a native FHIR stack whose extraction contract is portable across those consumers. The geographic vs claims-based attribution piece covers a related routing decision on the attribution side, and the attribution-of-record patterns for CMS-0057-F walkthrough covers the analogous decision on the provider-access side.
The trade-off underneath all of this is the same one that shows up across value-based care infrastructure. Buy the workflow when the workflow is the product. Own the extraction contract when the data feeds more than one consumer. Programs that get this call wrong tend to spend the next reporting cycle writing integration jobs the vendor did not think they would need.