FHIR Provenance vs AuditEvent: GxP Traceability Matrix

FHIR (Fast Healthcare Interoperability Resources) offers two resources that both touch traceability, and they are not interchangeable. HL7 states that Provenance "tracks information about the activity that created, revised, deleted, or signed a version of a resource" (^[1]), while AuditEvent is "a record of an event relevant for purposes such as operations, privacy, security, maintenance, and performance analysis" (^[2]). HL7 also says the two contain overlapping information, with AuditEvent "created as events occur, to track and audit the events" (^[3]). The practical split is by creator and subject: the application that initiates a create or update prepares Provenance, whereas AuditEvent is often created by the application that responds to the event.

This report converts that distinction into a scenario crosswalk for create, read, update, delete, transformation, import, approval, signature, disclosure, configuration and purge events. As a rule of thumb (an editorial choice, not a standard), assertions about how a specific record version came to exist belong in Provenance, assertions about who did what to which system and with what outcome belong in AuditEvent, regulated create, update and delete events usually warrant both, and physical deletion, infrastructure configuration, clock management and immutable retention sit in external validated controls. FHIR itself says servers "would not generally accept update or delete operations" on AuditEvent (^[4]) yet may "completely delete the resource and its history" (^[5]), so FHIR alone cannot guarantee immutability.

Using FHIR resources does not by itself establish compliance with 21 CFR Part 11 or EU Annex 11. Part 11 requires validation of systems, including "the ability to discern invalid or altered records" (^[6]), and secure, time-stamped audit trails that do not "obscure previously recorded information" (^[7]). The FDA scope guidance is nonbinding (^[8]), says Part 11 will be "interpreted narrowly" (^[9]), and leaves predicate-rule retention duties intact (^[10]). The in-force Annex 11 text dates from 2011 and asks for audit trails based on a risk assessment (^[11]); as of the 27 October 2026 check, the Commission index still listed "revision January 2011" (^[12]) and the 2025 consultation page showed the response period had ended (^[13]).

Version status matters. R5 (5.0.0) is the current published release (^[14]), both resources are Trial Use at maturity level 4 in R5, and R6 appears only as ballot and snapshot drafts. Teams should pin the release and profile they validate against and measure four ratios (event coverage, versioned-reference resolution, cross-system correlation, and restore success) against thresholds from the system's own risk assessment. This is an implementation reference, not legal advice or a certification claim.

Clinical integration engineers who expose regulated records through FHIR face a recurring design question: which traceability assertion goes where? The two resources are easy to conflate, so this report builds a decision aid for FHIR architects, security and privacy teams, and GxP (good practice quality guidelines, such as GCP, GLP and GMP) validation owners. This report does not rank vendors or products. Where the text recommends something, it is labelled as an editorial implementation choice.

Statements in this report fall into five labelled classes:

• Standard text: what HL7, IHE, W3C or IETF documents say about resource semantics.
• Regulatory expectation: what a regulator or regulator-affiliated body writes, dated and attributed.
• Guidance: nonbinding recommendations, including FDA guidance, which carries a "Nonbinding Recommendations" label (^[15]).
• Editorial choice: one possible architecture proposed by the authors.
• Example: synthetic data that illustrates a pattern and is not validated against any profile.

The regulatory frame is context-dependent. Part 11 states that its criteria are for records FDA treats as "trustworthy, reliable, and generally equivalent to paper records" (^[16]), and FDA's 2003 scope guidance, announced in the Federal Register on 5 September 2003 (^[17]), states that "part 11 remains in effect" (^[18]). Which records fall under Part 11 depends on predicate rules, the underlying regulations such as 21 CFR 312 (investigational drugs) or 211 (drug manufacturing). The MHRA (UK Medicines and Healthcare products Regulatory Agency) data-integrity guidance describes itself as a resource on the core elements of a compliant data governance system (^[19]). Applicable rules vary by record, process, region and system, and a qualified regulatory and quality professional should confirm scope; this report does not do so.

Sample events cannot prove completeness or tamper resistance in a deployed system. The report contains no private implementation experience, conversion results, error rates, costs or performance benchmarks, and none should be inferred.

Capabilities

Provenance is a record-keeping assertion about the context in which information in a resource was obtained, and HL7 positions it as W3C PROV-based. The mappings page says "all the parts of the resource are formally mapped to the PROV-O" ontology (^[20]), and W3C defines provenance as "information about entities, activities, and people involved in producing a piece of data or thing" (^[21]). The resource design draws on HL7 v2, v3 and CDA headers and on IHE ATNA.

The main R5 elements form an entity-activity-agent model:

• target: the resource versions the assertion is about. Target references are usually version specific but might not be (^[22]).
• recorded and occurred: recorded is the instant the activity was recorded and can differ from the resource timestamp when recording is delayed; occurred[x] (serialised as occurredDateTime or occurredPeriod) holds when the activity happened.
• agent: the participants, with onBehalfOf naming the delegating agent (PROV defines association as "an assignment of responsibility to an agent for an activity" (^[23])).
• entity: source or revised inputs, each with a role describing how it was used.
• authorization: the purpose of use or authorization behind the event.
• signature: a digital signature on the target, where "the signer should match a Provenance.agent" (^[24]).

One Provenance corresponds to a single activity, and several records may exist for one resource. R5 prefers provenance-like elements inside other resources, such as meta.source, where adequate, and directs users to a full Provenance for additional detail.

Adoption

Adoption evidence is mixed in depth. US Core 9.0.0 (based on FHIR R4) defines a Provenance profile limited to minimal, basic lineage information. The Bulk Data Access implementation guide states that default exports SHALL include available Provenance resources (^[25]), and C-CDA guidance prioritizes the organization most recently responsible for a meaningful clinical update or for compiling the data. An August 2026 AWS implementation used a "FHIR Provenance-aligned schema tracking origin, transformations, and operators" (^[26]); this is a vendor example, not a regulatory authority.

Strengths and Limitations

Strengths: versioned targets, explicit agents and a signature slot make Provenance the natural home for "how did this version come to be" statements, including deletions, where R5 says a record "can be recorded to indicate who deleted a Resource" (^[27]).

Limitations are equally concrete:

• Maturity: Provenance is Trial Use, maturity level 4, in R5 (^[28]).
• Dependency on versioning: adopting Provenance "may introduce requirements for versioning and unique identification" on source systems (^[29]).
• Optional server support: servers may ignore the X-Provenance header, so client-supplied provenance is not guaranteed to be stored.
• Depth: a peer-reviewed proof of concept found its own element-level metadata offered "significantly more detailed contextual information" than FHIR Provenance (^[30]), although it was tested only with simulated data (^[31]).

Capabilities

AuditEvent records events relevant to operations, privacy, security, maintenance and performance analysis. It is "based on the IHE-ATNA Audit record definitions" (^[32]), jointly managed by HL7, DICOM and IHE, and BALP relies on ATNA for transport and query (^[33]). The lineage runs through RFC 3881, which explicitly "is not a candidate for any level of Internet Standard" (^[34]), and DICOM PS3.15, which defines the audit message format and minimum attributes (^[35]).

The model answers who (agent), what (entity), where (source), what kind (category and code), which action (create, read, update, delete or execute), when (recorded) and with what outcome. Key points from the R5 text:

• Every actor records: all actors involved in an auditable event "should record an AuditEvent" (^[36]), and duplicate entries from different actors are expected.
• Scope beyond REST: security-relevant events include start-up, login, configuration and policy changes, not only RESTful calls.
• Search as execute: a search is recorded as an Execute action (^[37]), and the response contents should not be copied into the AuditEvent.
• Version-specific entities: the entity reference should be version specific, and an optional patient element identifies the data subject.

R4 to R5 renamed several elements, for example purposeOfEvent became authorization (^[38]), so a mapping that reads R4 AuditEvents with R5 expectations will fail silently unless tested.

Adoption

The FHIR security page describes audit logging as recording as much detail as is reasonable at event time, notes that ATNA events can be searched or subscribed to as AuditEvents, and points to IHE BALP (Basic Audit Log Patterns) for RESTful events and authorization decisions. BALP 1.1.4 is built on R4 and focuses on "privacy centric AuditEvent logs" (^[39]); it defines Create, Read, Update, Delete and Search patterns (^[40]) and advises deriving more specific events from them (^[41]). IHE ATNA specifies "the foundational elements needed by all forms of secure systems" (^[42]).

Strengths and Limitations

Strengths: broad event coverage, an established standards lineage and a client-plus-server recording pattern that BALP says "enables forensic analysis to detect failures better" (^[43]).

Limitations:

• Immutability is advisory. R4 and R5 say only that servers would not generally accept update or delete, which is not a SHALL.
• Sensitivity. The R6 continuous-integration page says an AuditEvent "includes very sensitive information" and access should be "highly privileged and controlled" (^[44]); BALP warns that even a minimal AuditEvent "would still contain sensitive data" (^[45]).
• Not a replacement. The same R6 draft text says AuditEvent is "not intended to replace other audit logs, but rather used to enhance them" (^[46]).
• Maturity. AuditEvent is Trial Use at maturity level 4 in R5 (^[47]).

Attribute comparison

Table 1 below summarizes the two resources using the R5 specification text as it stood in October 2026; the preceding sections cite the support for each row.

Attribute	Provenance (R5)	AuditEvent (R5)
Question answered	How did this version of the record come to be (create, revise, delete, sign)?	What happened in a system, to what, by whom, with what outcome?
Typical creator	Application initiating the create or update	Often the application responding to the event
Reference pinning	Target usually version specific	Entity reference should be version specific
Mutability expectation	Ordinary resource; stored and versioned like any other	Servers "would not generally accept update or delete"
Signature element	Yes, detached digital signature	No dedicated element in the R5 element list reviewed; sign via an external mechanism (editorial)
Standards lineage	W3C PROV	IHE ATNA, DICOM, RFC 3881

Table 1 shows why neither resource alone suffices for regulated records. Provenance gives lineage and a signature slot but no write-protection expectation; AuditEvent gives the event stream and a protection expectation but does not describe record derivation. HL7 acknowledges the overlap, so the design question is which event needs which assertion.

Scenario-by-scenario decision table

Table 2 below crosswalks eleven scenarios to Provenance, AuditEvent, both, or an external validated audit system. It is an editorial decision aid, not a regulatory requirement; each organization should adjust it through its own risk assessment.

Scenario	Provenance	AuditEvent	Verdict (editorial)	Evidence to retain
1. Create a regulated resource via API	Target = new version; agent, recorded; submitted with the target in one transaction	Create (C) event with outcome and X-Request-Id entity ([40])	Both	Version id, both records, transaction log ([48])
2. Read or search	Not applicable: read does not generate a version	Read or Execute event; omit result bodies	AuditEvent	Event with patient link ([49])
3. Update (correction)	New version as target, prior version as revision entity, reason in authorization	Update (U) event; entity pinned to new version	Both	Both versions, reason, agent identity ([50])
4. Logical delete	Provenance showing who deleted	Delete (D) event	Both	Tombstone history entry
5. Physical purge or retention-end destruction	Not reliable: the target may no longer exist	FHIR cannot guarantee history	External validated records system	Destruction approval, certificate, retention basis
6. Transformation (HL7 v2, CDA or ETL to FHIR)	Derivation: source as source entity, tool as agent	Batch run event and outcome	Both	Source hash, mapping version, run id ([51])
7. Import of external data	Entity = external source, agent = import service	Import execution event	Both	Source manifest, receipt, validation report
8. Approval or review	Approval activity with agent role and meaning	Workflow decision event, if security relevant	Provenance (plus external workflow log)	Approver identity, meaning, timestamp ([52])
9. Electronic signature	Provenance.signature with matching agent	Signing-attempt and authentication events	Both	Signature blob, verification result, key custody records ([53])
10. Disclosure or export	Optional: lineage of the exported set	Disclosure or export event; BALP covers privacy disclosure patterns	AuditEvent	Recipient, scope, authorization ([54])
11. Configuration, role and clock changes	Not applicable to resource versions	System event; but changes to audit settings need a protected log	External, mirrored to AuditEvent	Change record, approver, before and after values ([55])

Table 2 supports two observations. Only scenarios that change or derive a resource version need Provenance, so read-heavy traffic generates AuditEvents only. And scenarios 5 and 11 depend on controls FHIR cannot enforce: the specification lets servers delete history, and Part 11 expects change control over system documentation (^[56]).

R5 (5.0.0) is the current published release as of the October 2026 HL7 check (review by January 2027); because an R6 snapshot is labelled "Stable", re-check the HL7 release page before relying on R5-only mappings. The release directory shows R4B and R4 as earlier releases, while R6 appears only as a second full ballot and a snapshot labelled "FHIR R6 Stable (Sept 2026)" (^[57]). The R6 continuous-integration build warns it "will be incorrect/inconsistent at times" (^[58]) and was generated on 21 October 2026 (^[59]). HL7 defines Trial Use content as reviewed and ready for production use but not yet widely used. In practice: validate against a published release, treat R6 text as a preview, and record the release and profile versions in the validation plan.

Version differences affect Provenance and AuditEvent mappings:

• Provenance R4 to R5: reason was renamed authorization (^[60]), and the R4 page defined it simply as the reason the activity took place.
• Removal modelling: R5 uses a Provenance to show who deleted a resource. The R6 draft says target and entity both reference the removed resource (^[61]) and recommends multiple Provenance resources for multiple removals (^[62]). A mapping built to one text will not reproduce the other.
• Profiles lag specification: US Core 9.0.0 and BALP 1.1.4 both build on R4 (^[39]), so a deployment can legitimately combine R4 profiles with R5 narrative.

Versioned references are the core of replayable traceability. FHIR notes that version-specific references are "usually associated with audit trail or provenance information" (^[63]). Provenance requires references that identify their target uniquely and unambiguously, even if not resolvable, and requires version information when versions matter. The catch: servers "SHOULD provide full version support" (^[64]) but may omit versioning, and a versionId can never be reused within a resource. A client cannot know the new version before an update, so HL7 advises submitting the target and its Provenance together in a transaction (^[65]), which succeeds or fails as a single unit.

Transformations deserve explicit lineage. W3C PROV defines derivation as "a transformation of an entity into another" (^[66]), and Annex 11 asks that migrated data are "not altered in value and/or meaning" (^[51]). The editorial pattern: for each conversion, write a Provenance whose entity is the source artifact (with a hash held in the external record) and whose agent is the conversion service version, and log the batch run as an AuditEvent. The AWS pipeline reviewed writes lineage annotations per job and relies on CloudTrail data events for audit logging (^[67]), which illustrates the same separation.

Part 11 distinguishes electronic signatures, defined as "a computer data compilation of any symbol or series of symbols executed, adopted, or authorized by an individual" (^[68]), from digital signatures, "based upon cryptographic methods of originator authentication" (^[69]). Signed records must show the date and time (^[70]) and the meaning, "such as review, approval, responsibility, or authorship" (^[52]), and signatures must be linked so they "cannot be excised, copied, or otherwise transferred to falsify an electronic record by ordinary means" (^[53]). Annex 11 similarly expects signatures to be "permanently linked to their respective record" (^[71]).

The FHIR Signature datatype can hold either a cryptographic signature (XML DigSig or JWS) "which is able to provide non-repudiation proof" or a graphical or process-based type (^[72]). The limits matter:

• Electronic versus digital. An image of an ink signature does "not protect the signed content from change" (^[73]).
• Detached by design. The JWS form keeps signed content separate from the signature, and the IHE document-signing profile likewise notes detached signatures leave the signed document unmodified (^[74]).
• Policy-dependent verification. FHIR suggests SHA-256, defines several verification levels (signature block, signer standing, unmodified content), and leaves acceptability to site validation policy. Signing also freezes URLs, identifiers and internal references.
• Open maturity. HL7 calls RESTful signature use "a poorly understood area" (^[75]), and it permits local policies that accept other methods, including scanned wet signatures.

JWS itself is defined in RFC 7515 (^[76]), and trusted time evidence can come from an RFC 3161 time-stamping service, which supports "proof that a datum" existed before a given time (^[77]). None of this establishes who the person was. Part 11 additionally expects at least two distinct identification components for non-biometric signatures (^[78]), and NIST's non-repudiation control asks for "irrefutable evidence" that an individual performed an action (^[79]). Both are identity-and-access-management obligations outside FHIR. Editorial reading: a Provenance.signature proves that a key holder signed specific bytes; manifestation of printed name, meaning and time, identity proofing, key custody and revocation handling must be validated separately.

Immutability. Part 11 audit trails must be "secure, computer-generated, time-stamped" and independent (^[80]), record changes must not "obscure previously recorded information" (^[7]), and entries must be retained "for a period at least as long as that required for the subject electronic records" (^[81]). MHRA expects users to be unable to "amend or switch off the audit trail" (^[82]), PIC/S (Pharmaceutical Inspection Co-operation Scheme) says audit trail functionality should be enabled and locked (^[55]), and the EMA clinical-trial guideline wants entries "protected against change, deletion, and access modification" (^[83]). FDA's 2024 clinical-investigation Q&A says audit trails "should be protected from modification and from being disabled" (^[84]). FHIR's behavior is weaker: past versions are "retained for audit/integrity purposes" (^[85]) and a delete creates a history entry, but servers may delete history entirely, and a server need not keep history at all.

Candidate external controls include WORM (write once, read many) storage. Cloud vendors document their own retention-lock features: AWS says compliance mode protects object versions from deletion "including the root user" (^[86]), Azure describes a WORM state, with a new policy initially "unlocked for testing purposes" (^[87]) (^[88]), and Google Cloud says a locked policy cannot be removed or reduced (^[89]). These are vendor statements about vendor features; validation must verify the configuration.

Access. AuditEvent content is meant for security administrators, and FHIR warns that even HTTP logs reveal a rich set of information about clinical records. Part 11 asks for authority checks (^[90]), and 21 CFR 211.68 requires controls so that only authorized personnel change records (^[91]). The HIPAA Security Rule requires mechanisms that "record and examine activity" in information systems (^[92]).

Clock. FHIR instant values must be precise to the second and "include a timezone offset" (^[93]), lastUpdated is server-set, and ATNA notes "correct time is needed to generate audit records with a correct timestamp" (^[94]). IHE Consistent Time targets a median error under one second (^[95]), using NTP (Network Time Protocol) (^[96]). NIST AU-8 uses internal system clocks for audit timestamps (^[97]). A Provenance recorded can lag the activity, so tests should compare occurred, recorded and AuditEvent times.

Retention and deletion. Retention follows predicate rules, which FDA states still apply in full (^[10]). Examples appear in the Data Analysis section. For purge, the R6 ballot defines a Patient $purge operation that removes "all current and historical versions" (^[98]) and leaves audibility to local policies. That means purge events need an external, retained record, because both the Provenance and the audited resource may be gone.

Traceability across an EDC (electronic data capture) system, a FHIR server, an ETL pipeline and an archive requires identifiers that survive hops. FHIR's guidance is specific:

• Business identifiers "are the preferred basis to recognize the same content on different systems" (^[99]), and systems should preserve the identifiers they receive.
• Logical ids are local. A logical id is unique per type within a server, and exchanged resources may receive new ids.
• References and namespaces. A literal reference is preferred over a logical one, resolving a logical reference needs business context, and identifier system URIs are chosen by the implementer organization, so the registry of systems is a controlled document.
• Request ids. X-Request-Id exists to help connect requests with logs and audit trails (^[100]), X-Correlation-Id echoes the client's id, and BALP says to record a known X-Request-Id in an entity (^[101]).
• Distributed tracing. W3C Trace Context addresses the problem that traces from different vendors "cannot be correlated" without a shared identifier (^[102]); it is an optional mechanism for the same purpose.

Operations may also generate AuditEvent resources as side-effects visible in history, so history bundles can interleave resource and audit entries. NIST control AU-6(3) asks for correlation of audit records "across different repositories" (^[103]). Editorial choice: define one end-to-end correlation key per business transaction, carry it in an Identifier on the Provenance, in an AuditEvent entity, and in external logs, then test that the join works in both directions.

Part 11 validation is about accuracy, reliability and "the ability to discern invalid or altered records" (^[6]). PIC/S says audit trail functionality "should be verified during validation of the system" (^[104]), and Annex 11 expects user requirements "traceable throughout the life-cycle" (^[105]). FDA's 2003 guidance repeatedly ties scope to "a justified and documented risk assessment" (^[106]). Accordingly, every threshold below is a placeholder to be set by the system's own risk assessment. No benchmark or universal threshold is claimed.

Table 3 lists tests, negative cases, the metric and the evidence artifact. The metrics are the four ratios proposed in this report, plus functional negative tests.

Test	Negative case	Metric or pass criterion	Evidence artifact
Event coverage	Critical event with no Provenance or AuditEvent	Covered critical events / inventoried critical events	Event inventory, trace to requirements ([105])
Reference resolution	Unversioned or dangling target	Resolvable versioned references / sampled references	Sample list, resolver output
Cross-system correlation	Orphan event in one system	Correlated events / expected events	Join report on correlation key
Archive restore	Restored file unreadable or fields lost	Retrieval and parse success after restore	Restore log, parse report ([107])
Write protection	Update or delete against audit store succeeds	Attempt rejected and itself logged	Role-based test script ([83])
Signature tamper	Edit signed content, then verify	Verification fails	Verification output
Clock drift	Skewed node clock	Skew detected and alarmed	Time-sync records ([97])
Sensitive content	Search response bodies in AuditEvent	Absent per design	Sampled events ([54])

Table 3 is explicit about negative cases because a positive sample proves little. FDA notes it is "not necessary to record every key stroke in an audit trail" (^[108]), so the event inventory, not volume, sets the denominator. For archive tests, Annex 11 expects archived data to be "checked for accessibility, readability and integrity" (^[107]), NIST CP-9(1) calls for assurance that backups can be "reliably retrieved" (^[109]), and MHRA requires archives permitting "recovery and readability" (^[110]).

(Hypothetical Example) If a risk assessment inventories 40 critical events and 38 have verified coverage, the ratio is 0.95; whether that passes depends on the threshold the plan sets. The numbers are arithmetic only.

The following synthetic fragments (Example, R5 element names, not validated against any profile) show one corrected observation recorded both ways. Security and quality reviewers should validate any production equivalent.

{
  "resourceType": "Provenance",
  "id": "prov-0001",
  "target": [{"reference": "Observation/obs-1001/_history/4"}],
  "occurredDateTime": "2026-03-02T14:05:09+00:00",
  "recorded": "2026-03-02T14:05:11.470+00:00",
  "activity": {"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v3-DataOperation", "code": "UPDATE"}]},
  "agent": [{"who": {"reference": "Practitioner/pr-synthetic-07"}}],
  "authorization": [{"concept": {"text": "Correction per synthetic query Q-2041"}}],
  "entity": [{"role": "revision", "what": {"reference": "Observation/obs-1001/_history/3"}}]
}

{
  "resourceType": "AuditEvent",
  "id": "ae-0001",
  "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/audit-event-type", "code": "rest"}]}],
  "code": {"coding": [{"system": "http://hl7.org/fhir/restful-interaction", "code": "update"}]},
  "action": "U",
  "severity": "informational",
  "recorded": "2026-03-02T14:05:11.482+00:00",
  "outcome": {"code": {"system": "http://terminology.hl7.org/CodeSystem/audit-event-outcome", "code": "0"}},
  "patient": {"reference": "Patient/pt-synthetic-01"},
  "agent": [{"who": {"reference": "Practitioner/pr-synthetic-07"}, "requestor": true}],
  "source": {"observer": {"reference": "Device/dev-gateway-a"}},
  "entity": [
    {"what": {"reference": "Observation/obs-1001/_history/4"}},
    {"what": {"identifier": {"system": "urn:example:x-request-id", "value": "req-7f3a"}}}
  ]
}

Both fragments pin version 4 of the same observation and share the agent; the AuditEvent adds a request identifier. A useful negative test removes the history entry for version 4 and confirms the suite flags the unresolvable reference.

Review is a procedure, not a resource. MHRA expects routine data review to include a documented audit trail review where risk assessment determines (^[111]), and WHO says routine review of GxP data and metadata "should include audit trails" (^[112]). PIC/S expects review before a critical decision relies on the data (^[113]). The EMA clinical-trial guideline requires "risk-based trial specific audit trail reviews" (^[114]), and FDA ties the decision to review to a risk assessment (^[115]).

The July 2025 draft revision of Annex 11 (a consultation draft, not adopted as of the October 2026 check) would go further: it proposes functionality that "automatically logs all manual user interactions" (^[116]), audit trails "enabled and locked at all times" (^[117]), reviews by personnel "not directly" involved (^[118]), and review before batch release unless later detection can be justified (^[119]). It also states that flat and locked files are not acceptable (^[120]). These are proposals; the in-force text remains the 2011 revision (^[121]).

For inspection and export, the evidence must be usable, not merely present:

• Copies: Part 11 expects "accurate and complete copies of records in both human readable and electronic form" (^[122]), and audit trail documentation "shall be available for agency review and copying" (^[123]).
• Format: FDA recommends audit trails be retained in a format that is "searchable and sortable" (^[124]) and copies should include metadata and audit trail information (^[125]).
• Archive character: the EMA trial master file guideline says the "dynamic character of the audit trail should be preserved" in archiving (^[126]).
• Bulk export of lineage: Bulk Data servers that do not retain provenance should return an error for provenance requests (^[127]).

The quantitative core of this topic is dates, versions, maturity levels and retention periods, not benchmarks; no public performance or error-rate benchmarks exist in the sources reviewed.

Standards and release status (as of October 2026 checks):

• FHIR R5: 5.0.0 is the current published release (^[14]); Provenance and AuditEvent are maturity level 4, Trial Use (^[28]) (^[47]).
• FHIR R6: second full ballot and snapshot drafts listed; a continuous-integration page was generated on 21 October 2026 (^[59]).

Regulatory dates:

• Annex 11: in-force revision has a 30 June 2011 deadline for coming into operation (^[121]); the revision consultation's response period has ended (^[13]).
• ICH E6(R3): adopted 6 January 2025 (^[128]); the EMA step 5 text lists effective dates of 23 July 2025 and 15 January 2027 for different parts (^[129]).
• EMA computerised systems guideline: adopted 7 March 2023 (^[130]) and effective 9 September 2023 per the EMA SME newsletter (^[131]).
• PIC/S PI 041-1: entry into force 1 July 2021 (^[132]).

Retention anchors (predicate-rule examples, not a complete list):

• 21 CFR 312.57 (sponsor): 2 years after a marketing application is approved (^[133]).
• 21 CFR 312.62 (investigator): 2 years after approval (^[134]).
• 21 CFR 211.180 (CGMP): at least 1 year after batch expiration (^[135]).
• 21 CFR 58.195 (GLP): one alternative period is at least 5 years after results submission (^[136]).
• 45 CFR 164.316 (HIPAA security documentation): 6 years from creation or last effective date (^[137]).
• EU clinical trial master file: at least 25 years after trial end (^[138]), and 30 years after product expiry for some advanced therapy documents (^[139]).

Read these as examples of why a single retention default is unsafe: the periods differ by rule and trigger, so audit trail retention must follow "the subject electronic records" (^[81]) rather than a global setting. ICH E6(R3) itself defers to the period required by applicable regulation (^[140]).

AWS healthcare lineage implementation (August 2026)

An AWS storage blog describes a demonstration pipeline that stores a lineage annotation on each object using a FHIR Provenance-aligned schema (^[26]). Annotations travel with objects during copy and replication (^[141]), while access auditing uses CloudTrail data events (^[67]). The response shown uses Provenance-aligned fields rather than a full resource instance (an editorial reading), and the post is a vendor-authored demonstration, not regulatory authority.

Community Part 11 design for FHIR (undated, release 0.2.2)

A community implementation guide argues that signing every FHIR transaction individually is not enough, because "an insider attacker can still delete the resource and the audit log entry" (^[142]). It proposes signed Provenance plus a write-only journal, and says no full blockchain is mandatory (^[143]). It is a non-normative proposal and not a regulator position.

Several moving parts will change this guidance. If R6 is published with the Provenance and AuditEvent text now shown in the draft, removal modelling and the Patient purge operation will need re-mapping (^[61]). If the Annex 11 revision is adopted as drafted, locked audit trails and pre-release review would become European expectations (^[117]) (^[119]), which would raise the value of external, protected audit stores. ICH E6(R3) Annex 2 takes effect in the EU in January 2027 per the EMA text (^[129]), and E6(R3) already expects that audit trails are not disabled (^[144]), that data changes and deletions are documented (^[145]), and that source record changes are traceable (^[48]).

For architecture teams, an editorial sequence follows: inventory critical events from predicate rules and risk assessments; assign each to Provenance, AuditEvent, both or an external system using Table 2; pin the FHIR release, profiles and terminology; define correlation keys; design retention and restore tests with owners; and retain evidence of review. This report does not rank vendors or products, and organizations should involve their quality unit and legal counsel for compliance determinations.

What is the difference between FHIR Provenance and AuditEvent for GxP?

Provenance records the activity, agents and entities behind a resource version; AuditEvent records operational and security events. GxP traceability often needs both, plus protected external storage (Table 2).

Can FHIR Provenance replace an audit log?

HL7 states the resources overlap but differ in when and by whom they are created. The R6 draft says AuditEvent supplements, not replaces, other audit logs (^[46]).

Does a FHIR audit trail satisfy 21 CFR Part 11?

Not by itself. Part 11 requires validated systems and secure audit trails (^[6]) (^[80]); protection, retention, review and validation are system and procedural controls.

What do FHIR AuditEvent and Provenance resource examples look like?

The synthetic JSON in the validation section shows both: an AuditEvent with category, code, action, recorded, outcome, agent, source and version-pinned entity, and a Provenance with target, recorded, activity, agent, authorization and a revision entity. BALP provides reusable AuditEvent patterns (^[40]), and HL7 publishes informative Provenance examples, including a delete and a signature (^[146]).

How does Provenance support data integrity and ALCOA?

FDA expands ALCOA as including contemporaneously recorded and original or true copy attributes (^[147]), and MHRA treats ALCOA and ALCOA+ as equal in expectation (^[148]). Editorially: agent supports attributable, recorded supports contemporaneous, versioned targets support original, and retention controls support enduring and available.

What are GxP audit trail requirements and how do they apply to FHIR?

Requirements differ by regime: Part 11 (^[80]), Annex 11 (^[11]), WHO (^[149]), and EMA trial guidance (^[150]). FHIR can represent events, but compliance depends on how the deployed system enforces them.

How can Provenance support traceability in clinical trials?

It can link each data version to agents and sources, support transformations and carry signatures. Trial-specific requirements include EMA field-level audit trails (^[151]) and archive controls (^[152]).

How should AuditEvent test cases be designed?

Use the event inventory, versioned reference, correlation, restore and negative tests in Table 3, with thresholds from the risk assessment.

Provenance and AuditEvent answer different questions. Provenance says how a version of a record came to be, with agents, sources and an optional signature. AuditEvent says what happened in or around the system, with actors, entities, outcomes and security context. HL7's own text acknowledges the overlap and assigns the creator roles differently. Regulated programs rarely need to pick only one: create, update, delete, transformation, import and signature events usually benefit from both, with external validated controls for physical deletion, configuration, time, immutable retention and identity.

FHIR resources describe events; they do not enforce protection, retention, review or validation. The release in use, the applicable predicate rules and the system's risk assessment determine what must be proven. Teams should date-stamp the standards and regulatory versions they rely on, recheck regulator catalogs and implementation guides before release, and treat the four coverage ratios as measurements against thresholds they set themselves.