Sending a Knee Injury and Osteoarthritis Outcome Score to a post-op patient over SMS is one of those workflows that sounds trivial until you actually wire it up. KOOS is a 42-item Questionnaire with several subscales, four scoring formulas, and a rendering surface that has to feel calm on a phone six days after surgery. Doing it on a FHIR-native runtime keeps the whole loop, from delivery through scoring to Observation extraction, on the same standard rails. This walkthrough covers the concrete steps for a US orthopedic program moving KOOS off paper.
For related reading on the wider category, FHIR resources for US digital health covers the surrounding context.
Step 1: Load KOOS as a Standard FHIR Questionnaire
The starting point is a canonical KOOS Questionnaire resource. Do not rebuild it from the PDF; there is a community-maintained version keyed off the LOINC KOOS panel that most FHIR-native runtimes will accept as is. Load it into the runtime as a Questionnaire resource with a stable canonical URL, then verify the four subscale calculation items (Pain, Symptoms, ADL, Sport/Rec, QoL) resolve through FHIRPath expressions the runtime will evaluate at submit time. If the runtime does not evaluate the calculation items server-side, the SMS flow will land the patient's answers cleanly but leave the scoring to a downstream service, which defeats most of the reason to run this on FHIR.
Step 2: Wire the SMS Channel Around a One-Time Renderer Link
The SMS message itself is one line: a personalized greeting and a short link. The link resolves to a rendering surface that hydrates the KOOS Questionnaire for a specific patient and encounter. The trick is the link has to be single-use and time-bound. The clean pattern is a signed one-time token that the SMS gateway includes in the URL, the runtime checks against a short-lived record, and then swaps for a session scoped to that patient's Questionnaire instance. Skip the temptation to embed the patient ID in the query string; even a hashed identifier over SMS is a leak the compliance team will not sign off on.
For the SMS gateway itself, most US programs land on Twilio, Bandwidth, or the messaging module inside their patient engagement stack. The runtime does not care which gateway you pick; it only needs to accept a webhook delivery report so the workflow can track sent, delivered, and bounced.
Step 3: Render KOOS on the Phone Without a Login
Once the link opens, the patient should see the first KOOS section, not a login page. That means the rendering surface has to run stateless enough to accept the one-time token as its identity and produce a clean, phone-friendly layout of the Questionnaire items. KOOS has a lot of Likert-style items, so the renderer has to keep those readable on a small screen and support tap-to-answer without pinch-zoom. In the FHIR-native camp, tools like Formbox handle the full SDC IG including population and extraction inside the same runtime, which is the piece most engagement-first platforms leave to a separate integration engine and which matters here because the same renderer has to serve the SMS link and the portal path without divergence.
If you want a quick sandbox before wiring anything to production, form-builder.aidbox.app renders standard Questionnaire JSON in the browser and is a useful place to sanity-check the KOOS resource before pushing it into your runtime.
Step 4: Score at Submit and Extract to Observations
When the patient hits submit, the runtime should do three things in the same transaction: persist the QuestionnaireResponse, evaluate the KOOS subscale formulas, and extract the four subscale scores as Observation resources bound to the LOINC panel codes. Doing all three in one step keeps the clinical view clean, because when the orthopedic team pulls up the patient's chart the scores show up as Observations on the timeline, not as opaque form data. If your runtime skips the extraction step, the workflow ends with a QuestionnaireResponse the EHR cannot query, and the SMS delivery gains you nothing on the clinical side.
Step 5: Feed the Follow-Up Cadence
KOOS is not a one-shot form. Post-op orthopedic programs typically collect it at two weeks, six weeks, three months, six months, and twelve months. The runtime has to schedule follow-up sends and reconcile which patient is due for which visit's KOOS. Most teams end up with a small scheduler that reads from the orthopedic program's cohort list, checks the last KOOS submission timestamp, and enqueues the next SMS. Keep the schedule table close to the runtime; leaving it in a separate CRM is where cadence drift starts. For related patterns in the same silo, the top 4 FHIR Questionnaire engines for US telehealth visits and the top 5 SDC form builders for US outpatient intake are useful next reads once the KOOS loop is running.