Format at a glance
Which to pick
Dashboard / portal UI
Use
inferred_list. Our shape is pre-shaped for rendering status badges,
confidence scores, and dosage sigs. FHIR is too verbose for UI.EHR integration
Use
fhir_bundle. Standard R4 Bundle you can route straight into your
FHIR store with no translation layer. Get Provenance resources for
free at verbosity=full.CDS engine / rule engine
Use
inferred_list with verbosity=full. You get the richest provenance
trail (evidence tags, enrichments) in the most ergonomic shape.Pipeline / warehouse
Use
fhir_array. Flat list of FHIR resources ingests cleanly into
BigQuery / DuckDB / Snowflake. Each row is resourceType + payload.Example: the same request in all three formats
Request (body is the same; onlyformat changes):
format: "inferred_list" — our shape
format: "fhir_bundle" — FHIR R4 Bundle
format: "fhir_array" — flat list
verbosity: "full", fhir_array becomes a union: MedicationRequest
resources followed by Provenance resources. Filter by resourceType to
separate them.
Where does the meta block go?
inferred_list keeps meta (request_id, ruleset_version, timing, counts)
inside the response body for backwards compatibility.
For FHIR formats, the response body is a pure FHIR payload — no wrapping
allowed. We move the same information to response headers:
These headers are set on every response (including
inferred_list), so
you can use them uniformly regardless of format.
Combinations worth knowing
The two axes are fully orthogonal — every (verbosity, format) pair works:
FHIR extensions we emit
Confidence and inference evidence are not standard FHIR fields, so we attach them as custom extensions (safe for FHIR-conformant parsers — they can ignore unknown extensions without error):
These live under our root namespace so future IG publication can reference
them as-is.