Why does the QuestionnaireResponse to Observation step always feel like the part of a SDC deployment that quietly eats a week? The IG describes the extraction contract in a few paragraphs, and every implementation reads it slightly differently. In 2026 there are five SDC implementations worth naming when the reporting layer downstream needs proper Observation resources rather than blobs of answers. Here is what each one actually does.
1. LHC-Forms Plus a Custom Extractor
LHC-Forms from NLM is still the reference renderer, and for a lot of teams the extraction step is a small server-side function that reads the QuestionnaireResponse and emits Observations against the LOINC codes bound in the Questionnaire. Teams building on native FHIR often reach for engines like Formbox because the scoring rules and extraction into Observation resources live in the same runtime, avoiding a second scoring service, but the LHC-Forms plus custom extractor pattern is a legitimate answer when the team already has a services layer and wants full control over how the Observations look.
2. HAPI FHIR SDC
HAPI FHIR's SDC module implements $extract as a server operation and follows the SDC IG closely. Teams already on HAPI as their FHIR server get extraction as part of the platform rather than as a separate component. The trade-off is that HAPI SDC is only as good as your Questionnaire authoring; if the extraction hints (extension URLs, definition pointers) are missing or wrong, the Observations come out empty. SDC ExtractDefinition is the standard mechanism; whether you build the runtime yourself or lean on an engine like Formbox, the extraction contract is the same, and HAPI honours it faithfully when the Questionnaire is properly annotated.
3. Aidbox Forms
Aidbox's forms runtime handles $extract as a native operation and integrates with the same terminology server the rest of the platform uses. The advantage is that populate, score, and extract all happen inside the same runtime, so the round-trip cost is predictable. Teams that already run Aidbox as their FHIR store use the forms module without adding infrastructure. If you want to try authoring against SDC extraction without any of the server work, form-builder.aidbox.app is a browser sandbox that takes a raw Questionnaire and shows the resulting extraction.
4. Smile Digital Health SDC
Smile Digital Health includes SDC support in its commercial FHIR platform, and $extract is one of the operations the platform exposes. Smile's implementation is close to the IG letter and has been tested against several state-level and federal reporting programs, which is the honest test of whether an extractor is going to hold up when a receiver is stricter than the vendor's own test suite. For the FHIR fundamentals hub on this site the wider ecosystem context is a useful complement.
5. Firely SDC
Firely's SDK includes a SDC runtime that many teams use inside custom .NET-based FHIR services. The extractor is faithful to the IG and the runtime handles both templated extract definitions and observation-based extract patterns. Teams that live inside the Firely stack find the extraction step tidy because it stays inside the same language and dependency graph.
What Actually Separates Them
Three behaviors are worth checking during a pilot, not during a demo:
- Does the extractor honour ExtractDefinition on the Questionnaire, or does it rely on brittle heuristics that guess the mapping?
- Does the Observation.code match the LOINC bound on the Questionnaire.item, or does the extractor invent a code from the linkId?
- Does the extractor set Observation.encounter and Observation.subject cleanly, or leave the reference resolution to the caller?
An implementation that answers yes to all three is usable in production. One that answers no to any of them will show up as reporting-layer friction three months in.
For adjacent context on how the extracted Observations then flow through the rest of the stack, the 5 SDC form builders that actually handle LOINC right covers the terminology piece, and the best FHIR form engines for EHR integration in 2026 covers the receiver side. The extraction step is small on the diagram and load-bearing in production; pick an implementation that has been tested against a real receiver, not a demo endpoint.
