FHIR Provenance Resource: target, recorded, agent, activity & signature Elements, US Core Profile & AI Data Lineage

The FHIR Provenance resource is the foundational metadata and data-lineage resource in HL7 Fast Healthcare Interoperability Resources (FHIR) that records the entities, clinical practitioners, organizations, and software agents involved in creating, modifying, verifying, or transmitting one or more clinical resources. Aligned with the W3C PROV Data Model (PROV-DM) and mandated by the HL7 US Core Implementation Guide, Provenance provides verifiable chain-of-custody auditing across health information exchanges (HIEs), clinical trial eSource pipelines, and AI-generated clinical documentation.

What Is FHIR Provenance and How Is It Used in Clinical Research and Healthcare?

While individual FHIR resources (such as Observation, Condition, or DocumentReference) carry basic inline metadata like meta.lastUpdated and a single author reference, clinical informatics and regulatory compliance require a far richer audit record when data crosses organizational boundaries or undergoes automated transformation. Defined in HL7 FHIR R4 (https://hl7.org/fhir/R4/provenance.html), Provenance answers six core lineage questions without bloating the clinical resource itself:

Provenance Element	Cardinality (FHIR R4)	Data Type	Lineage Question & Technical Function
target	1..*	Reference(Any)	What resource(s) does this apply to? Points to the specific version-specific or version-independent FHIR resource(s) created or updated.
occurred[x]	0..1	Period | dateTime	When did the clinical activity happen? Captures the period or timestamp of the underlying clinical or data-processing activity.
recorded	1..1	instant	When was this provenance logged? Immutable system timestamp (`YYYY-MM-DDThh:mm:ss.sss+zz:zz`) when the activity was recorded.
activity	0..1	CodeableConcept	Why/how was the target modified? Codes the operation (e.g., CREATE, UPDATE, APPEND, LA legal authentication, or ANONY de-identification).
agent	1..*	BackboneElement	Who or what was responsible? Identifies each human, organization, or software system (`agent.who`), their participation type (`agent.type`), and their institutional principal (`agent.onBehalfOf`).
entity	0..*	BackboneElement	What upstream sources were used? Links to input resources or external CDA/HL7 v2 messages (`entity.what`) with role codes `derivation`, `revision`, `quotation`, `source`, or `removal`.
signature	0..*	Signature	How is integrity proven? Carries digital signatures (JWS/JSON Web Signature or XML-Sig) over the target resource for non-repudiation.

Tracking Lineage for AI-Generated Clinical Data

As healthcare organizations deploy ambient AI scribes, clinical NLP pipelines, and predictive clinical decision support models, Provenance serves as the standardized mechanism for separating AI-synthesized content from human-authored records:

• AI Model as assembler / author Agent: The AI model or software pipeline is represented as a FHIR Device resource (capturing model name, version, and UDI/software identifier) referenced in Provenance.agent.who with agent.type = assembler (code system http://terminology.hl7.org/CodeSystem/provenance-participant-type).
• Clinician Attestation as verifier / attester Agent: When the attending physician reviews, edits, and signs the AI-drafted note, a second entry in Provenance.agent records the human Practitioner with agent.type = verifier or attester.
• Source Grounding via Provenance.entity: Every upstream encounter audio transcript, laboratory Observation, or prior note consumed by a Retrieval-Augmented Generation (RAG) prompt is listed in Provenance.entity with role = derivation or source, providing an auditable input-to-output lineage graph.

What Standards or Regulatory Requirements Govern FHIR Provenance?

Three major US regulatory and interoperability frameworks govern the implementation of Provenance:

1. ONC/ASTP USCDI and the HL7 US Core Provenance Profile: Under 45 CFR § 170.315(g)(10) and the US Core Provenance Profile (https://hl7.org/fhir/us/core/StructureDefinition-us-core-provenance.html), certified EHR APIs must support “last-hop” provenance—recording at minimum the Author Organization (`agent.type = author`) and, when data was received from an external exchange, the Transmitter (`agent.type = transmitter`) alongside the `recorded` timestamp.
2. FDA 21 CFR Part 11 and eSource Guidance in Clinical Research: In EHR-to-EDC clinical trial data extraction, Provenance satisfies FDA 21 CFR Part 11.10(e) electronic audit trail requirements and CDISC SDTM origin traceability by proving who originated an eSource measurement, when it was recorded, and whether any middleware transformed the units or coding.
3. HIPAA Security Rule Audit Controls (45 CFR § 164.312(b)): While `AuditEvent` logs read/query access events, `Provenance` permanently binds creation, amendment, and cryptographic signature accountability (`Provenance.signature`) to clinical records.

How Does FHIR Provenance Integrate with EHR and Health Informatics Workflows?

Because client applications querying an EHR for a patient’s allergies, problems, or notes do not know the server-assigned IDs of the associated Provenance resources in advance, US Core mandates support for the RESTful reverse-include parameter _revinclude=Provenance:target:

GET [base]/DocumentReference?patient=patient-101&category=clinical-note&_revinclude=Provenance:target

In response, the FHIR server returns a single searchset Bundle containing both the matching DocumentReference resources (with search.mode = match) and all Provenance resources whose target points to those notes (with search.mode = include):

{
  "resourceType": "Provenance",
  "id": "prov-ai-progress-note-01",
  "meta": {
    "profile": [
      "http://hl7.org/fhir/us/core/StructureDefinition/us-core-provenance"
    ]
  },
  "target": [
    {
      "reference": "DocumentReference/docref-progress-note-992/_history/1"
    }
  ],
  "recorded": "2026-11-09T15:42:10Z",
  "activity": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/v3-DataOperation",
        "code": "CREATE",
        "display": "create"
      }
    ]
  },
  "agent": [
    {
      "type": {
        "coding": [
          {
            "system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
            "code": "assembler",
            "display": "Assembler"
          }
        ]
      },
      "who": {
        "reference": "Device/ambient-ai-scribe-v4"
      }
    },
    {
      "type": {
        "coding": [
          {
            "system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
            "code": "verifier",
            "display": "Verifier"
          }
        ]
      },
      "who": {
        "reference": "Practitioner/practitioner-md-22"
      },
      "onBehalfOf": {
        "reference": "Organization/org-univ-hospital"
      }
    },
    {
      "type": {
        "coding": [
          {
            "system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
            "code": "author",
            "display": "Author"
          }
        ]
      },
      "who": {
        "reference": "Organization/org-univ-hospital"
      }
    }
  ],
  "entity": [
    {
      "role": "derivation",
      "what": {
        "reference": "Media/encounter-audio-transcript-881"
      }
    }
  ]
}

Frequently Asked Questions

What is FHIR Provenance and how is it used in clinical research and healthcare?

FHIR Provenance is the HL7 metadata resource that tracks the origin, authorship, modification history, and upstream source derivation of clinical records—used in healthcare and clinical research to audit HIE data exchanges, satisfy FDA 21 CFR Part 11 eSource traceability, and document which AI models and human clinicians generated or verified a clinical note.

What standards or regulatory requirements govern FHIR Provenance?

FHIR Provenance is governed by the HL7 US Core Provenance Profile under ONC/ASTP 45 CFR § 170.315(g)(10) interoperability rules (which mandate author and transmitter agent tracking), W3C PROV-DM lineage principles, and FDA 21 CFR Part 11 electronic signature and audit trail regulations.

How does FHIR Provenance integrate with EHR and health informatics workflows?

EHRs expose Provenance records inline with clinical queries using the mandatory reverse-include parameter _revinclude=Provenance:target (for example, GET /Observation?patient=[id]&_revinclude=Provenance:target), returning both the clinical resources and their linked Provenance lineage records in a single FHIR Bundle.