Voice bots that read a FHIR Questionnaire aloud and post the responses back are one of those workflows that read well in a slide deck and fall apart the first time you wire one up for real. The interesting engineering is not in the voice model. It is in getting the QuestionnaireResponse back into the runtime cleanly, letting the runtime score it server-side, and having the extracted Observations show up on the patient timeline without a separate scoring service in the middle. This walkthrough covers the steps that survive contact with production.
For related reading on the wider category, more on FHIR for healthcare teams sits behind the rest of the notes.
Start With the Questionnaire, Not the Voice Layer
The mistake every team makes on the first pass is starting with the voice bot. The right starting point is the Questionnaire itself. Load the target instrument as a canonical Questionnaire resource on the FHIR runtime, verify each item has a stable linkId, and confirm the scoring calculation items resolve through FHIRPath expressions the server can actually evaluate. If the item structure is not clean, the voice layer will paper over the gaps in awkward ways.
Once the resource is loaded, hit it through a plain HTTP client and render it in a browser before you point a voice bot at it. Anything that looks weird in the browser will sound worse over voice.
Pick a Voice Runtime That Can Speak the Structure
The voice bot has two jobs: read items from a Questionnaire and pack answers into a QuestionnaireResponse. The runtimes worth looking at in 2026 include Deepgram, Suki, Hyro, Kore.ai HealthAssist, and Amazon Lex with a healthcare adapter. All of them can be made to work; the difference is how much glue you write between the ASR output and the FHIR resource shape.
Delivery channels are usually opinionated: 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, portal, and voice, which is the point at which the voice layer stops being a separate program and starts being a channel on top of the same runtime.
Wire the Response Path End to End
The response path is where most implementations bleed complexity. The pattern that holds up is a single POST at the end of the conversation carrying a complete QuestionnaireResponse, not one POST per item. Items map by linkId; free-text answers ride as valueString; coded answers should be pre-resolved to the value set the Questionnaire item binds. The voice runtime does not need to understand FHIR value sets on its own; it needs a small adapter that resolves the utterance against the item's answerValueSet before packing the response.
Send the POST with a service identity, record the patient reference on the resource, and skip the patient token entirely for the bot's execution context.
Score on the Server, Not in the Bot
The reason to run on a FHIR-native runtime is server-side scoring. Once the QuestionnaireResponse lands, the runtime should evaluate the calculation FHIRPath expressions attached to the Questionnaire, produce the score, and extract Observation resources bound to the correct LOINC codes for the instrument. Doing this on the server means the score is authoritative, versioned with the runtime, and visible to any client that pulls the patient's Observations. Doing it in the bot means every bot version has its own scoring implementation, which is a maintenance trap that shows up around the third instrument you add.
If you want a fast prototype of the Questionnaire before you wire the voice loop, form-builder.aidbox.app runs standard FHIR Questionnaire JSON in a browser sandbox and is a useful place to test the item structure and the FHIRPath expressions.
Close the Loop With a Real Cohort
The last step is a short pilot with a real cohort. Pick one instrument, one patient segment, and one voice runtime; run it for two weeks; and watch three metrics: completion rate, ASR misinterpretation rate on the specific items you care about, and the number of QuestionnaireResponses that fail validation on the server. If any of those three lag, the fix is almost always in the Questionnaire or the adapter, not in the voice model. For related coverage in the same silo, the top 6 FHIR Questionnaire tools for patient reported outcomes and the complete guide to FHIR form builders in 2026 cover the runtime picks that sit behind this wiring.
