Provenance Profile

Canonical	../StructureDefinition/nexus-emr-core-provenance
Status	draft · 1.26.0
Base	Provenance (constraint)
Source	FSH · JSON

Attribution for AI-mediated and cross-boundary writes: what was produced, when, by which agent (human or non-human), from what inputs, and -- for generated text -- which verbatim source passage each statement rests on. Used standalone against a produced resource, and contained in an AI-suggestion review Task against the suggestion contained alongside it.

Overview

Overview

The Nexus EMR Core Provenance profile records what produced or changed a resource: the activity, when it was recorded, the agents responsible (which may include a non-human agent), and the inputs the activity derived from. Its primary intended use is AI-action attribution -- keeping an AI-drafted resource traceable to the agent that drafted it, the human who accepted it, and the record context it was generated from. Like MessageHeader and Subscription, Provenance is infrastructure rather than clinical content: it describes how a record came to be, not a clinical fact about a patient.

Note that R4 Provenance has no identifier element, so the house identifier invariant deliberately does not apply here -- a detail that surprises implementers. Correlating a Provenance with an external record has to go through identifiers on agent.who or entity.what.

Two shapes: standalone and contained

A Provenance appears in one of two places, and which one tells you what stage the content is at:

• Standalone, targeting a resource that exists in the chart -- an accepted AI-drafted note, or a generated summary. The content has been produced; the Provenance says by whom and from what.
• Contained in an AI-suggestion review Task, linked from Task.relevantHistory and targeting the suggestion contained alongside it. Nothing has been asserted yet. The proposal and its citation trail are promoted, declined and retained as a single unit, and neither is independently readable or visible to type-level queries before approval.

The second shape is why target and entity.what tolerate local (#id) and identifier-only references: a contained Provenance points at a contained sibling, which has no independent identity.

What is stable, and what is not

Stable enough to build on:

• target (1..*) names the resources the activity produced or changed. Multiple targets are permitted and are the normal case for one action that writes a bundle -- one Provenance covering the set is preferred over one per resource, because the action was a single decision.
• recorded (1..1) is always present. occurred[x] is optional but is the preferred date: a provenance written asynchronously has a recorded well after the action, and dating the action to the bookkeeping timestamp misplaces it in every timeline.
• agent (1..*), with agent.type (1..1) and agent.who (1..1).

• entity (0..*) names the resources the activity read, and the attributedFact extension carries statement-level citations for generated text.

Open, and not to be depended on:

• Model and token accounting. No element on this profile carries model identity or token spend, and none should be assumed to appear in a particular place. Operational telemetry of this kind stays outside FHIR and is correlated by identifier.
• activity is unbound. R4's example binding does not anticipate AI-mediated authorship (draft-generated, AI-suggested, human-accepted), so no binding is asserted rather than one that would mis-describe the data. Read activity.text; a validator run against the base spec will warn that no code was supplied, and that warning is expected.
• entity for very large contexts. Listing every member of a chart-wide compartment load may be prohibitively large, and a summarizing convention -- the snapshot's own identifier rather than each member -- is the expected direction for that case.
• Coverage. Provenance is written for AI-mediated and cross-boundary writes; whether it is also written for ordinary human edits is undecided. Treat its presence as informative and its absence as inconclusive. A separate audit extension on meta also records who last changed a resource, so Provenance is not the complete audit record.

Agents: the AI and the human are both recorded

For an AI-mediated action there are normally two agents, and both matter: the non-human agent that generated the content (a Device), and the human who reviewed, accepted, or attested to it (a Practitioner). author plus attester is the expected agent.type pair. agent.onBehalfOf covers delegation, such as an agent acting for the supervising practitioner or the clinic.

agent.type is tightened to 1..1 here, aligning with US Core. It is the only element that says which agent did what -- without it, a Provenance naming two agents leaves AI-drafted content indistinguishable from human-authored content, the specific outcome this profile exists to prevent.

Attributed facts: per-statement citations for AI-generated text

When the target is AI-generated text produced under the cite-every-fact contract (summaries, chiefly), the repeating attributedFact extension carries the citation trail at a finer grain than entity: each factual statement in the generated text, with at least one verbatim quote from the source material it was derived from, labelled with the generating run's chunk id. entity says which resources the activity read; attributedFact says which statement rests on which passage.

Three things to know as a consumer:

• Order is significant. The facts repeat in the order they compose the generated text; preserve it.
• Chunk labels are opaque and run-relative (e.g. c3): stable within one Provenance instance, meaningless across instances. The quote is the durable, auditable part -- it remains checkable against the source document after the run's chunking is gone. Where the producer can resolve a chunk to its source resource, the optional source sub-extension carries that reference (which, like all references here, may be identifier-only).
• Every fact has a citation by construction (citation is 1..*): the generating pipeline refuses to emit a citation-free fact, and the profile makes that guarantee structural.

See the AI-generated summary example for the worked shape.

References may be identifier-only

Per the Nexus EMR logical-reference model, target and entity.what may carry an identifier with no literal reference, and a consumer resolving provenance must handle that case. Treating a reference-less target as absent is the most common cause of provenance appearing missing when it is in fact present. US Core's must-support on target.reference is deliberately not adopted, precisely because it would require literal references.