Which FHIR version should DSP sit on?

Three axes matter: deployment reality (what EHRs actually speak), conceptual fit (which version has the cleanest resources for DSP's shape), and transport capability (Subscriptions, $graphql, callbacks).

Matrix

Dimension	R4 (4.0.1, 2019)	R5 (5.0.0, 2023)	R6 (ballot, 2025+)
EHR deployment	Universal Epic, Oracle Health, Meditech, Athena, Veradigm, etc.	Sparse Mostly reference servers; no tier-1 EHR endpoint exposes R5 natively.	None Pre-normative.
Regulatory alignment (US)	HTI-1 / USCDI v3 / CMS-9115-F	Not required	N/A
US Core IG	6.x / 7.x — mature	Separate R5 IG in development; lags R4 branch	—
`MedicationRequest` fidelity	Good; dose/timing in `dosageInstruction`; `statusReason` exists	Better — `renderedDosageInstruction`, richer `Ingredient`/`ClinicalUseDefinition`, improved substitution	Iterative polish
`ServiceRequest` (labs/imaging/procedure/referral)	Single unified resource since R4	Minor refinements	Minor refinements
Certainty / confidence on requests	Extension-only (no native field on `MedicationRequest`/`ServiceRequest`/`Condition`)	Still extension-only for request resources; `Evidence.certainty` exists but is for EBM, not DSP orders	Likely expanded
Subscriptions (for DSP callbacks)	R4 has legacy Subscription; R4B adds topic-based (backport)	First-class `SubscriptionTopic` + `Subscription`	Normative track
`$graphql` operation	Defined; read-only in practice	Expanded — mutation via `Parameters` proposals, better tooling	Continuing
Cross-version extensions	Consumer: uses R5/R6 elements as xver extensions (mature pattern)	Producer: emit R5 elements natively	—
Tooling (validators, IG publisher, profile renderers)	Excellent	Good and improving	Unstable
Ballot stability	Normative for core infra resources	STU	Pre-ballot / early ballot

Verdict

Recommendation Anchor DSP-FHIR at R4, borrow from R5 selectively via cross-version extensions, treat R6 as directional input into the IG's profile design.

Why this wins on all three axes:

Deployment reality: Every partner EHR already speaks R4. Dragon's external_callback_url will land on an R4 endpoint in the real world. Picking R5/R6 forces translators on day one.
Conceptual fit: R4's Encounter, Condition, MedicationRequest, ServiceRequest, Composition, DocumentReference, Provenance cover ≈90% of DSP directly. The 10% gap is extension territory either way.
Transport: R4 + R4B topic-based Subscription + $graphql is enough for DSP's callback and projection patterns. R5's stronger SubscriptionTopic can be referenced in the IG but not required.

The cost of R5 is broken EHR integration. The benefit of R5 (certainty, nicer medication model) is recoverable in R4 via cross-version extensions. The asymmetry is clear.

Where R5 earns its keep

Even with R4 as the base, these R5 elements are worth promoting to DSP-FHIR extensions:

MedicationRequest.renderedDosageInstruction (R5) → cleanly holds DSP's free-text "take one a day for 3 days, then twice a day".
R5 Ingredient / ClinicalUseDefinition — richer representation for compound medications and substitution rules.
R5's pattern for grading uncertainty (used by Evidence.certainty) — informs the valueset for DSP's confidence-score extension even though no request-side element exists.
SubscriptionTopic — formalizes Dragon's callback contract with partners.
Condition.stage.assessment richer cardinality.

Where R6 earns its keep (forward-looking)

Continuing cleanup of narrative/structured boundary in Composition — relevant for DSP's document_section / structured-resources split.
Expanded ActorDefinition / role modeling — DSP's practitioner.roles and accompanied_by become cleaner.
Better GraphQL/query-parameter profiling — useful when publishing the DSP canonical $graphql query as part of the IG.

Do not wait for R6. By the time R6 is normative and adopted, DSP will have shipped many revisions. The IG should be authored against R4 today, with a documented migration path as R5/R6 become deployment-relevant.