Interop & layering

DSP-FHIR resources are complete-on-their-own R4 artefacts. They do not depend on any particular downstream model, and they compose cleanly into any canonical patient-context store that consumes standard FHIR.

1. Ambient capture — microphone, speaker turns, transcript.
2. DSP payload — Dragon Standard Payload 1.0 JSON envelope.
3. DSP-FHIR Bundle — R4 Bundle of Encounter, Composition, orders, DocumentReferences, Provenance.
4. Downstream canonical patient-context store — dedupes, reconciles, joins with the longitudinal record.
5. EHR of record — persistent clinical system.

Each boundary in that chain is a standard FHIR exchange. DSP-FHIR's job is to emit resources that the next hop can ingest without custom glue — and to not quietly occupy namespaces a downstream layer will later need.

Every DSP-emitted resource SHOULD carry a stable identifier so a downstream store can dedupe across replays, re-posts, and version bumps. DSP-FHIR reserves an identifier system family under https://dsp-fhir.org/identifier/....

Patient identifiers supplied by upstream DSP inputs (MRN, tenant-specific IDs, visit numbers) SHOULD be preserved verbatim on Patient.identifier with their original system and type. The downstream canonical store owns the mapping to its internal MRN / tenant identifier space; DSP-FHIR does not invent or normalise those.

Passthrough Patient identifier:

{
  "resourceType": "Patient",
  "id": "pat-67890",
  "identifier": [
    {
      "use": "usual",
      "type": {
        "coding": [{
          "system": "http://terminology.hl7.org/CodeSystem/v2-0203",
          "code": "MR", "display": "Medical record number"
        }]
      },
      "system": "urn:ehr:mrn:example-health",
      "value": "MRN-67890"
    },
    {
      "use": "secondary",
      "system": "https://dsp-fhir.org/identifier/source-ref",
      "value": "dsp-upstream-ref-9f3e"
    }
  ]
}

Inside a DSP-FHIR Bundle we reference resources by urn:uuid:* so the Bundle is self-contained and order-independent. When the Bundle is POSTed to a FHIR server, the server rewrites those to relative or absolute references.

A downstream canonical store SHOULD accept all three and normalise internally. It MUST NOT assume a DSP-FHIR Bundle has already been posted to its own FHIR base.

DSP-FHIR reserves https://dsp-fhir.org/StructureDefinition/* for profiles and extensions. A downstream canonical patient-context model SHOULD NOT mint extensions under this namespace; it should carry its own canonical and either pass DSP extensions through verbatim or map them into its own shape.

DSP-FHIR profiles derive from base FHIR R4, not US Core, IPA, or any other jurisdictional family. The rationale is layering: downstream consumers routinely need to stack US Core, IPA, or a national profile on top, and a formal inheritance chain through a jurisdictional profile would force double-constraint work and collide with regional variants.

In practice DSP-FHIR remains compatible with US Core on the vast majority of elements (names, identifiers, codings, must-supports), but does not formally inherit from it. Jurisdictional layering is the downstream store's concern.

Every DSP-originated resource carries meta.source = "dsp://..." and is referenced by a Provenance resource tied to the session. Together with the cross-cutting extensions (confidence-score, transcript-turn-refs, spoken-forms, search-terms), this is the downstream audit surface: any assertion can be filtered by confidence, re-verified against its originating transcript turn, or routed for human review without the downstream model inventing its own audit shape.

payload-version rides as a meta.tag (as well as a structured extension) so downstream stores can filter by DSP release — GET [base]/Encounter?_tag=https://dsp-fhir.org/CodeSystem/payload-version|1.0.0 — and evolve in step with DSP.

DSP-FHIR references audio recordings via Media.content.url, typically an external blob URL governed by the write side. A downstream server MAY inline or re-host the payload as a Binary resource referenced by the same Media. Both patterns are conformant; the choice is an operational one about custody and retention.

• External URL: Media.content.url = "https://blob.example.org/rec/abc.wav"
• Re-hosted: Media.content.url = "Binary/bin-001" (or an absolute reference to the downstream server).

The following resources are intentionally not emitted by DSP-FHIR 1.0. They are the downstream store's responsibility, either because they are reconciliation-shaped (not capture-shaped) or because they represent state that lives in the EHR of record.

The complete set of canonical URI namespaces DSP-FHIR owns. A downstream canonical patient-context model MUST NOT mint artefacts under these paths.