A FHIR-first interoperability core for the Dragon Standard Payload.

DSP 1.0 is a bespoke, partner-facing JSON schema for Dragon Copilot. This site treats FHIR as the canonical interoperability model and asks one question: how do we make every DSP field first-class in FHIR without inventing a parallel data world?

Thesis

DSP is not a competitor to FHIR — it is a purpose-shaped projection of it. Encounters, practitioners, conditions, medications, labs, imaging, procedures, referrals, follow-ups, and document sections are all direct FHIR concepts. The DSP-specific bits (transcript turns, spoken forms, confidence scores, payload versioning) are thin envelope metadata that FHIR handles cleanly with extensions and $graphql.

The recommendation of this site: anchor at FHIR R4 (deployment reality), borrow R5/R6 via cross-version extensions where they materially improve fidelity, and publish DSP as a small Implementation Guide + a canonical $graphql query — not as a parallel schema.

Pick

R4 as the core

Universal EHR support, US Core, HTI-1 / CMS-9115-F alignment. This is where the wire lives.

Borrow

R5 via xver extensions

Certainty, improved MedicationRequest, Ingredient, Subscription/Topic for callbacks.

Watch

R6 as a direction

Still ballot. Use its profiling refinements to inform IG design, but don't bind yet.

What this site contains

DSP primer — the payload shape, distilled.
R4 vs R5 vs R6 evaluation — matrix + verdict.
$graphql as DSP transport — DSP-shaped response in one query.
Resource mapping catalog — every DSP concept to its FHIR home.
DSP-FHIR IG outline — profiles, extensions, bindings.
Gaps & open questions — where FHIR stretches and where we extend it.

Design principle. If a DSP field has a FHIR home, use it. If it doesn't, extend — don't fork. The IG's job is to make that boundary explicit.

DSP-FHIR is designed to layer under a downstream canonical patient-context model — see Interop & layering.