After you have looked at enough Bundles, the same handful of structural mistakes start to feel familiar. They are not exotic. They are not tricky new bits of the spec. They are the same five patterns showing up across teams, EHRs, and integration middleware, and they account for most of the noise a validator flags in a working pipeline.
If a broader tour of validation is useful first, what really breaks when you skip Bundle validation covers the why. This is the specific list. Reading it now saves the twenty-minute stare at related FHIR explainers when you inherit a Bundle from someone else.
1. Missing or Wrong `fullUrl` on Entries
Every Bundle.entry should have a fullUrl that other entries in the same Bundle can reference. When it is missing, transaction Bundles cannot resolve internal references, and even collection Bundles get harder to debug.
The frequent variant is a fullUrl set to a partial URL like Patient/123 in a transaction where the spec wants either a full URL or a urn:uuid: reference. Both patterns validate structurally in isolation but produce silent broken references at the receiver.
2. Reference Points to a Resource That Is Not in the Bundle
Observation.subject.reference set to Patient/456 when there is no Patient/456 inside the same Bundle and the receiver has no way to resolve it externally. Structurally the resource is fine. Semantically it points at nothing.
Validators with reference-resolution enabled catch this. Structural checks alone will not. If your ingest is receiving Bundles from a partner, this is one of the first things worth checking, because it typically indicates the sender copy-pasted resources without adjusting the references.
3. Required Cardinality Missed on a Profile Element
The base R4 spec is permissive. Profiles are where the tighter rules live. A US Core Patient must have an identifier. A US Core Observation must have a category. When teams generate Bundles against the base spec without profile awareness, these show up as missing-required errors the moment you run the Bundle through a profile-aware validator.
For the wider frame on how profile checks fit next to base structural checks, structural check vs terminology check walks through the split. The fix here is nearly always to update the generator, not the validator.
4. Bundle Type Does Not Match the Payload Shape
Bundle.type set to transaction when there is no entry.request on any entry. Or set to searchset on a payload that clearly is not a search response. The Bundle type dictates what other elements are required, and mismatches produce a cascade of errors that all trace back to the type field.
When you see fifteen errors that all name Bundle.entry[N].request or Bundle.entry[N].fullUrl, check Bundle.type first before touching the entries. Nine times out of ten it is the top-level field that was set wrong.
5. Datetime Precision That Does Not Match the Data
Patient.birthDate set to a full ISO datetime when the spec expects a date. Observation.effectiveDateTime set to a bare year when the receiver expects at least a day. These are the errors that pass casual review because the JSON looks fine, and only surface when a validator checks the primitive type against its regex.
The habit is to think in terms of what the field represents and pick the coarsest precision that is honest for the data. If you only know a birth year, birthDate should be 2004 and not 2004-01-01T00:00:00Z. For the tools side of catching this quickly, how to read a FHIR validation error shows how to spot the primitive-type errors fast. The site's Bundle validator will call these out on the first pass.
The Pattern Under the Patterns
All five are the same shape: the payload looks fine at a glance, but a rule in the spec is being quietly broken. Validation is what turns "looks fine" into "is fine", and once these five patterns are on your radar, most of the noise in a validator response starts to make sense.
Sources
- HL7 FHIR Bundle Resource Spec - HL7 FHIR core specification of the Bundle resource, canonical rules for fullUrl, entry.request, and batch/transaction semantics
