W3C PROV: The PROV-DM Data Model, PROV-O Ontology, PROV-N, and HL7 FHIR Mapping

W3C PROV is a family of World Wide Web Consortium (W3C) specifications—ratified as W3C Recommendations in April 2013—that defines a domain-agnostic model, ontology, and serialization syntax for exchanging interoperable data provenance across heterogeneous computing environments. Provenance describes the entities, activities, and people or software systems involved in producing a piece of data or physical artifact, providing the formal lineage needed to evaluate data quality, reproducibility, and regulatory trust.

In biomedical informatics, computational biology, and clinical data management, W3C PROV provides the mathematical and semantic graph structure behind both Linked Data knowledge graphs (stored in an RDF triple store) and the HL7 FHIR Provenance resource used by Electronic Health Records (EHRs) and clinical trial data pipelines.

Architecture of the W3C PROV Specification Suite

Rather than enforcing a single serialization format, the W3C Provenance Working Group structured PROV as a modular family of specifications so that relational databases, XML document stores, RDF graph engines, and workflow orchestrators can exchange the same underlying lineage concepts:

• PROV-DM (PROV Data Model): The foundational conceptual model that defines the core node types (Entity, Activity, Agent), the seven primary directed relationships between them, and modular extensions for collections, bundles (provenance of provenance), and alternates/specializations.
• PROV-O (PROV Ontology): The W3C OWL2 Web Ontology Language encoding of PROV-DM (bound to the namespace http://www.w3.org/ns/prov#), organized into three progressive tiers: Starting Point classes and properties for simple binary triples, Expanded terms (such as prov:Bundle, prov:SoftwareAgent, and prov:wasRevisionOf), and Qualified pattern classes that attach timestamps, roles, or plans to n-ary relationships.
• PROV-N (PROV Notation): A compact, human-readable functional notation designed to express PROV-DM instances unambiguously in technical specifications, audit logs, and formal proofs without the syntactic verbosity of RDF/XML or Turtle.
• PROV-CONSTRAINTS: A formal specification defining structural validity and equivalence rules—such as temporal ordering constraints (an entity cannot be used before it is generated) and derivation acyclicity—used by automated reasoners to validate provenance graphs.

PROV-DM Core Triad: Entities, Activities, Agents, and Directed Relations

At the heart of PROV-DM is a directed graph built around three core classes and seven causal or responsibility relations (which by convention point backward in time toward the origin of the data):

1. prov:Entity: A physical, digital, conceptual, or other kind of thing with some fixed aspects. In clinical research, an Entity might be a raw DICOM series, an HL7 v2 laboratory message, a cleaned CDISC SDTM domain table, or a trained machine learning model weight file.
2. prov:Activity: Something that occurs over a period of time (bounded by prov:startedAtTime and prov:endedAtTime) and acts upon or with entities. Examples include a laboratory assay run, an ETL de-identification script execution, or a clinical chart sign-off encounter.
3. prov:Agent: Something that bears some form of responsibility for an activity taking place, for the existence of an entity, or for another agent’s activity. PROV-DM distinguishes three standard subclasses: prov:Person, prov:Organization, and prov:SoftwareAgent.

PROV-DM Relation	PROV-O Property (Subject → Object)	PROV-N Functional Syntax	Semantic Meaning in Research Workflows
Generation	Entity prov:wasGeneratedBy Activity	wasGeneratedBy(e2, a1, t)	Completes production of a new entity (e.g., an imputed dataset produced by an R script).
Usage	Activity prov:used Entity	used(a1, e1, t)	Marks an input entity consumed or read by an activity (e.g., raw eCRF export read by a transformation job).
Communication	Activity prov:wasInformedBy Activity	wasInformedBy(a2, a1)	Indicates that Activity a2 used an unspecified entity generated by Activity a1.
Derivation	Entity prov:wasDerivedFrom Entity	wasDerivedFrom(e2, e1, a, g, u)	Links a transformed entity directly to its source entity (subtypes: wasRevisionOf, wasQuotedFrom, hadPrimarySource).
Attribution	Entity prov:wasAttributedTo Agent	wasAttributedTo(e2, ag1)	Assigns responsibility for an entity to an agent without requiring an explicit intermediate activity.
Association	Activity prov:wasAssociatedWith Agent	wasAssociatedWith(a1, ag1, plan)	Assigns an agent’s responsibility for an activity, optionally linking the prov:Plan (protocol or code script) executed.
Delegation	Agent prov:actedOnBehalfOf Agent	actedOnBehalfOf(ag2, ag1, a1)	Captures authority chains (e.g., an automated ETL service account running on behalf of a principal investigator or sponsor).

Qualified Relations and Bundles in PROV-O and PROV-N

In RDF, a simple binary triple such as :cohortTable prov:wasGeneratedBy :etlRun42 cannot directly carry edge attributes like the exact role the entity played or the protocol followed during the activity. PROV-O solves this using the Qualification Pattern:

• Qualified Association and Plans: To record which exact software script or Statistical Analysis Plan (SAP) governed an activity, an RDF graph attaches a prov:qualifiedAssociation blank node or URI of class prov:Association, linking the responsible prov:Agent via prov:agent, the role via prov:hadRole, and the version-controlled script (typed as prov:Plan, a subclass of prov:Entity) via prov:hadPlan.
• Specialization and Alternate Entities: Mutable clinical records require distinguishing between an abstract resource and its immutable timestamped snapshots. PROV defines prov:specializationOf (linking a specific versioned snapshot :patient_101_v2 to the general concept :patient_101) and prov:alternateOf (linking two snapshots :patient_101_v1 and :patient_101_v2 that represent the same underlying clinical entity at different points in time).
• prov:Bundle (Provenance of Provenance): A prov:Bundle is a named set of provenance descriptions that is itself a prov:Entity. In multi-center data catalogs built with W3C DCAT, each contributing site can package its local lineage assertions into a signed named graph (prov:Bundle), enabling the central coordinating center to record when and by whom the provenance metadata itself was ingested.

Mapping W3C PROV to the HL7 FHIR Provenance Resource

In healthcare interoperability, the HL7 FHIR standard explicitly bases its normative Provenance resource on the W3C PROV data model. Rather than embedding provenance fields inside every clinical resource, FHIR treats each Provenance instance as an event-level wrapper around one or more generated or updated FHIR resource versions (similar to a W3C PROV Activity plus its surrounding Entity and Agent edges):

W3C PROV-DM / PROV-O Concept	HL7 FHIR R4 Provenance Element	Clinical & Research Informatics Usage
Generated prov:Entity (output of wasGeneratedBy)	Provenance.target (1..* Reference)	Points to the specific versioned FHIR resource(s) created or modified by the event (e.g., Observation/bp-102/_history/1).
prov:Activity & timestamps	Provenance.activity, occurred[x], recorded	Encodes the action performed (e.g., CREATE, UPDATE, APPEND, or ANONYM) and when it occurred vs. when it was logged.
prov:Agent, wasAssociatedWith, actedOnBehalfOf	Provenance.agent.who, agent.type, agent.onBehalfOf	Identifies the author, verifier, transmitter, or assembler (Practitioner, Device, or Organization) and organizational delegation.
prov:Plan / Governing Policy	Provenance.policy (uri) & reason	References the governing consent directive, IRB protocol URI, or data transformation specification authorizing the activity.
Precursor prov:Entity (used / wasDerivedFrom)	Provenance.entity.what & entity.role	Links input source artifacts (e.g., raw CDA document or HL7 v2 message) using roles mapped from W3C PROV: derivation, revision, quotation, source, or removal.

By preserving this structural isomorphism, clinical data warehouses can ingest FHIR Provenance resources from hospital EHRs (satisfying ONC USCDI author and timestamp requirements) and project them directly into W3C PROV-O RDF graphs to trace end-to-end lineage from bedside vital-sign capture through statistical table generation.

Frequently Asked Questions

What is W3C PROV and how is it used in clinical research and healthcare?

W3C PROV is a suite of World Wide Web Consortium (W3C) specifications—centered on the PROV Data Model (PROV-DM), PROV Ontology (PROV-O), and PROV Notation (PROV-N)—that standardizes how systems represent the lineage of data across the web. In clinical research and healthcare, it models how datasets, clinical observations, and machine learning artifacts (Entities) are produced by computational pipelines or clinical encounters (Activities) under the responsibility of clinicians, researchers, or software systems (Agents).

What standards or regulatory requirements govern W3C PROV?

W3C PROV is governed by the W3C PROV family of Recommendations (published in April 2013), including PROV-DM, PROV-O (OWL2 ontology at http://www.w3.org/ns/prov#), PROV-N, and PROV-CONSTRAINTS. In clinical informatics, HL7 FHIR directly incorporates W3C PROV concepts into the normative FHIR Provenance resource used to meet ONC USCDI provenance requirements and regulatory audit-trail expectations.

How does W3C PROV integrate with EHR and health informatics workflows?

Health informatics platforms map W3C PROV’s Entity-Activity-Agent triad directly to the HL7 FHIR Provenance resource: Provenance.target represents the generated Entity, Provenance.activity and occurred[x] represent the Activity, Provenance.agent (who and onBehalfOf) represents the Agent and delegation chain, and Provenance.entity represents precursor source records via derivation, revision, or quotation roles.