Review the US Core Provenance profile in the current US Core IG to identify must-support elements; as of recent US Core versions these include Provenance.target, Provenance.recorded, Provenance.agent (with role and who sub-elements), and Provenance.agent.onBehalfOf.
For each clinical FHIR resource created or exchanged, create a Provenance resource with Provenance.target referencing that resource; a single Provenance can target multiple resources if they share the same provenance context.
Populate Provenance.agent.type with a code from the appropriate value set indicating the agent's role (e.g., author, transmitter); verify the required value set binding in the current US Core Provenance profile.
Set Provenance.agent.who to a reference to a Practitioner, PractitionerRole, Organization, Device, or RelatedPerson — the must-support constraint requires this element to be populated.
Set Provenance.agent.onBehalfOf when the agent acts on behalf of an organization, which is a common pattern in provider-to-payer exchange.
Validate completed Provenance resources against the US Core Provenance profile to confirm all must-support elements are populated before including them in exchange responses.
Known gotchas
US Core Provenance must-support does not mean required for all implementers — must-support means that if the data exists, it must be populated and cannot be omitted; understand the obligation semantics for your actor role.
The agent role value set has changed across US Core versions — always verify the correct binding against the specific US Core version your implementation targets.
Provenance.recorded must be a precise timestamp; using only a date without time may cause validation warnings or failures depending on the FHIR server's validator configuration.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp