By Bundle Validation

Audit Trails Grounded in Structural Bundle Validation

Editorial illustration in botanical-sketch style depicting a botanical audit chain of leaf specimen cards with one red-sealed validator entry

Audit trails in FHIR-based health-data programs typically record who accessed which resource and when. That framing misses the earlier question of whether the payload the resource arrived in was ever validated. Grounding the audit trail in structural Bundle validation adds a checkpoint before access is even relevant.

Programs that skip the checkpoint inherit a trail that starts mid-lifecycle. Related engineering material sits under the FHIR engineering reference for teams building the retention layer.

The Fields Every Audit Entry Needs

An audit entry that names a Bundle-layer validation event has to carry enough context to reconstruct the check months later:

  1. Bundle identifier — a stable ID (payload hash or transaction ID) that ties the entry to the payload.
  2. Validator version — the exact version of the validator implementation that produced the result.
  3. Profile package version — the exact package and version applied at the check.
  4. Timestamp — the moment the validator produced the verdict.
  5. Verdict — pass, fail, or partial, with the counts of issues per severity.
  6. Report reference — a link or hash to the full OperationOutcome for later inspection.

Missing any of these fields leaves the audit entry unfalsifiable, which is the shape of an audit trail that regulators tend to reject.

Retention Alignment With the Data

Audit entries share a retention horizon with the payloads they describe. Programs that retain payloads for seven years should retain the validation entries for the same period. Trails that expire before the payloads leave the audit surface partially exposed.

The inline-versus-external trade-off is the recurring decision here. Inline entries live in the same store as the payload and simplify retention alignment. External entries live in a dedicated audit ledger and simplify cross-payload analysis. Both patterns work; the choice depends on the program's audit tooling. A pass through the site's Bundle JSON check illustrates the verdict shape that either pattern retains.

Immutability and Signing

Regulators that ask about audit trails also ask about immutability. Signed trails, whether via a cryptographic ledger or a write-once-read-many store, prevent post-hoc edits. Programs that skip signing accept the risk that an audit-trail entry could be modified after the fact, which undermines its evidentiary weight.

Signing is not a validator concern; it is a storage-layer decision made once. The validator's job is to produce a report the storage layer can sign.

Reading the Trail Later

An audit trail that is technically complete but operationally unreadable serves no one. Trails should be queryable by Bundle ID, by vendor, by verdict, and by validator version. For the reader-side view of the same data, reading FHIR validation output as a non-developer stakeholder covers the questions to ask.

Contract Language That Requires the Trail

Interop contracts that mandate structural Bundle validation should also mandate the retention and access model for the audit trail. Contracts that leave the audit language implicit usually discover the gap in a compliance review. For the contract wording, Bundle validation as an interop contract term collects the common clauses.

An audit trail grounded in structural validation is the record that lets a program answer, months later, whether the data it accepted was ever verified.

Botanical-sketch diagram of a chain of audit ledger entries as hand-drawn linked cards with a Bundle submission on the left, a validator log stamp in muted red at the middle, and immutable ledger sheets stacking on the right

Sources