FHIR validator output tends to arrive in a shape optimized for developers: a flat list of issues, each with a FHIRPath location and a controlled-vocabulary code. Stakeholders responsible for the data-quality program, the vendor relationship, or the compliance audit trail need the same information in a different arrangement. Reading the output as a non-developer means grouping issues by decision, not by line.
The reading habit that scales is a small set of triage questions applied to every validator report. Related material sits under the FHIR implementation playbook for teams building shared vocabulary across roles.
Question One: How Many Payloads Failed
The first useful metric is the failure rate over a bounded time window. A single Bundle rejection is a data point; a rejection rate of five percent over a week is a signal that acceptance criteria have drifted or that a producer regression has landed. Validator reports that surface per-payload counts serve this question directly.
Reports that only list issues without payload counts hide the denominator. Programs should insist on both, and validator implementations that support both are the ones worth budgeting for. A pass through the site's Bundle JSON check illustrates the per-payload framing on a single Bundle.
Question Two: Which Vendors Reject
Rejection rates by vendor are the next lens. A vendor that rejects at ten times the rate of others is either enforcing stricter acceptance criteria or receiving payloads with vendor-specific drift. Both cases are worth investigating and neither is visible without vendor-labeled reports.
The rejection taxonomy also travels with the vendor label. A vendor that consistently rejects with required codes tightened cardinality relative to base R4; a vendor that rejects with code-invalid narrowed terminology bindings. The pattern is signal, not noise.
Question Three: Which Codes Dominate
Validator issue codes are a small controlled vocabulary. Grouping issues by code exposes the underlying root causes:
- required — a mandatory element is missing.
- code-invalid — a coding is outside the bound value set.
- invariant — a profile-level FHIRPath rule failed.
- structure — a primitive or shape does not match the spec.
- reference — an internal or external reference cannot be resolved.
A report that shows the code distribution answers where to invest fix effort. Reports that only surface diagnostic strings force the reader to reconstruct the grouping every time.
Question Four: What Landed in the Audit Trail
Every validated payload should leave an audit-trail entry regardless of the verdict. Stakeholders responsible for compliance need to answer, months later, whether a given payload was validated, when, and against which profile package version. For the audit-trail specifics, audit trails grounded in structural Bundle validation covers the retention model.
Audit trails that only record failures leave the passes unnamed, which is a data-quality gap in its own right.
Question Five: What Did Not Get Fixed
The final lens is the aging report: which issues have been open for longer than the acceptance program allows. Aging tracks fix effort and exposes structural blockers where a vendor's IG update is required. For the downstream cost dimension, the true cost of shipping an invalid FHIR Bundle is the accompanying reference.
Reading validator output as a non-developer is a matter of picking the right lens and asking the right five questions.
Sources
- HL7 FHIR core specification of the OperationOutcome resource - HL7 FHIR core specification of the OperationOutcome resource, canonical anatomy of severity, code, location, expression fields