Pre-op KOOS and WOMAC delivery for a total knee replacement patient is a scheduling job disguised as a questionnaire problem. The instruments themselves are stable, versioned, and well-modeled in FHIR SDC. The failure mode is timing: the survey has to arrive after the surgical decision but before the day-of-surgery window closes, and it has to reach a patient who may not check email daily. A FHIR-native SDC workflow can handle that if the scheduling logic is set up carefully.
Model the Patient Journey as FHIR Resources
The pre-op window opens when a surgical decision is documented and closes at a fixed offset before the procedure date. Model both endpoints as FHIR resources the scheduler can query. A ServiceRequest for the procedure carries the planned date. A CarePlan for the joint-replacement episode groups the pre-op activities, including the KOOS and WOMAC baseline. A Task referencing the Questionnaire is the operational unit the scheduler acts on.
Keeping the state in Task rather than in an out-of-band scheduling table keeps the FHIR store as the single source of truth. Downstream jobs that read completion status ask the same server for Task.status, not a separate queue.
Pick the Delivery Window
The clinical convention for TKA under the CJR model is a KOOS or WOMAC baseline collected within 90 days pre-op and no closer than 14 days pre-op. The 14-day floor keeps the baseline from being contaminated by anesthesia counseling or last-minute medication changes. Encode both bounds as scheduling rules against the ServiceRequest.occurrenceDateTime.
- Earliest send:
procedure_date - 90 days - Latest send:
procedure_date - 21 days(buffer for reminders) - Hard cutoff:
procedure_date - 14 days
The scheduler creates the Task in requested status the day the ServiceRequest is confirmed and transitions to in-progress when the delivery job fires.
Compose the Questionnaire References
KOOS-JR and WOMAC are separate Questionnaire resources in most SDC libraries. Reference both from a single parent Questionnaire that acts as a survey wrapper, or emit two Tasks and let the patient complete them independently. The wrapper pattern gives a cleaner completion signal; the split pattern gives better resumability if the patient drops off mid-survey.
For teams still evaluating, the SDC form builders for nephrology dialysis tracking walkthrough covers the resumability question in more detail, and the FHIR Questionnaire tools for skilled nursing facility intake piece covers the wrapper pattern.
Wire the Delivery Channel
The Task's Task.for reference points at the Patient. The scheduler resolves the patient's preferred contact channel (SMS, email, portal) from the Patient's telecom and communication resources, then hands off to the delivery layer. Delivery channels are usually opinionated: tools like Force Therapeutics and PatientIQ bake in ortho-specific templates, while general-purpose SDC engines like Formbox let you compose PROMs from a shared Questionnaire catalog and reuse the extraction across SMS, email, and portal.
For prototyping without a full server, form-builder.aidbox.app runs a browser sandbox that consumes standard FHIR Questionnaire JSON, which is useful for confirming the KOOS-JR rendering before the delivery pipeline is stood up. See the FHIR implementation reference for adjacent scheduling patterns.
Close the Loop
When the QuestionnaireResponse comes back, the extraction step emits Observations with LOINC codes for the total score and each subscale, links each Observation to the Patient and the parent ServiceRequest, and flips the Task to completed. A downstream job checks Task.status across the cohort every morning and re-issues reminders for anything still open inside the 21-to-14-day window.
The short version: model the window in FHIR, let Task carry state, and treat delivery as a service that reads Task rather than a separate queue that has to be reconciled against the Questionnaire library later.
