Provenance — A resource's genesis

How did this Observation come into the system? Who signed it? From what source? Provenance documents the lineage of a resource, aligned with W3C PROV.

Purpose

Provenance records the lineage of one or more target resources: who created it, from what source, in what context, on what legal basis. It's the piece required to:

• Digitally sign a resource (signature).
• Trace an external data import (e.g. PDF imported as DocumentReference).
• Document a transformation (a FHIR Bundle generated from an HL7 v2 message).
• Guarantee longitudinal integrity: who, when, how, on what.

Key fields

Provenance vs AuditEvent

Two resources, two purposes:

• Provenance: Who produced this resource? Where does it come from? — created once at creation (and on amendments) of the target resource.
• AuditEvent: Who accessed this resource? When? Successfully? — created on every access, read, modification.

In production, a typical Patient resource has 1 Provenance (created at admission) + N AuditEvents (one per read/write).

JSON example

Provenance of a consent signed by Dr Jones and verified by the patient, with detached XML signature:

{
  "resourceType": "Provenance",
  "id": "consent-signature",
  "target": [{ "reference": "Consent/consent-example-signature" }],
  "occurredDateTime": "2026-05-14T15:30:00+02:00",
  "recorded": "2026-05-14T15:32:00.000Z",
  "policy": ["http://acme.com/policies/Consent_2026"],
  "location": { "reference": "Location/clinic-room-3" },
  "authorization": [{
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/v3-ActReason",
      "code": "TREAT",
      "display": "treatment"
    }]
  }],
  "activity": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/v3-DataOperation",
      "code": "ATTEST",
      "display": "attest"
    }]
  },
  "agent": [{
    "type": {
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
        "code": "author"
      }]
    },
    "who": { "reference": "Practitioner/dr-jones" }
  }, {
    "type": {
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
        "code": "verifier"
      }]
    },
    "who": { "reference": "Patient/example" }
  }],
  "entity": [{
    "role": "source",
    "what": { "reference": "DocumentReference/consent-form-template" }
  }],
  "signature": [{
    "type": [{
      "system": "urn:iso-astm:E1762-95:2013",
      "code": "1.2.840.10065.1.12.1.1",
      "display": "Author's Signature"
    }],
    "when": "2026-05-14T15:30:00+02:00",
    "who": { "reference": "Practitioner/dr-jones" },
    "sigFormat": "application/signature+xml",
    "data": "Li4u"
  }]
}

Common pitfalls

• No author agent — every Provenance MUST identify at least one author.
• Missing Provenance for external imports — a PDF or an HL7 v2 message transformed into FHIR MUST be accompanied by a Provenance pointing back to the source.
• Confusing basedOn and entity — basedOn is a parent activity, entity is a source data item.
• Non-detached signature — prefer a detached signature (XML-DSig or JWS) referencing target by hash rather than inline.
• Shared Provenance across unrelated resources — a Provenance may reference several targets, but only if the creation event is identical for all.

Related resources

• AuditEvent — who accessed (vs Provenance = who produced).
• Consent — frequently referenced legal basis.
• DocumentReference, Composition — frequent Provenance targets.
• Signature — embedded data type.