Picture a US integration team pushing a first live payload to a new partner health system. The Bundle passed every local validator they ran. The CI dashboard is green. The partner responds with a terse OperationOutcome saying the payload is not acceptable. The natural reaction is to assume the partner made a mistake. Usually the partner is right, and the definition of validation used by each side is the source of the disagreement.
A FHIR Bundle can be spec-valid and receiver-invalid at the same time. It can also be receiver-valid but drift out of spec-valid on a future upgrade. Working out which side of the split a given failure sits on is often the fastest way to get unstuck. For related integration reading, FHIR integration resources is where the wider set lives.
Two Different Questions Sharing One Word
Spec validation asks whether the payload matches the base FHIR specification the world agreed on. That is a fixed target for a given FHIR version. If your Bundle passes a stock R4 validator with no extra profiles loaded, it is spec-valid.
Receiver validation asks whether the payload matches what a specific receiver has decided to accept. That is not a fixed target. Each receiver publishes its own profile package, or maintains an internal one, and the acceptance criteria are the union of the base spec plus those rules. For the deeper split on what a stock validator catches versus what it deliberately skips, what a Bundle validator actually checks is the reference.
Where the Two Diverge in Practice
Cardinality tightening is the most common driver. The base R4 spec says Patient.identifier is 0... US Core says 1... A Bundle that omits identifiers is legal against base R4 and illegal against US Core, and the same Bundle will get opposite verdicts from two validators depending on which profile package is loaded.
Extension requirements are a second frequent split. A partner may require a race-and-ethnicity extension on every Patient. The base spec knows nothing about it; the partner's IG or house rules do. A stock validator has no way to catch that unless you tell it to.
Terminology narrowing is a third. Base R4 says Observation.code is bound to a huge value set. A partner's profile may narrow it to LOINC-only, or to a specific LOINC panel. Codes that were legal at the wider layer are rejected at the narrower one.
The Both-Valid and Neither-Valid Cases
Both-valid is the happy path. Your Bundle passes the stock R4 validator and it also passes the partner's profile-aware validator running the same package you loaded locally. That is what you want CI to enforce every time. For how to wire that up, profile-aware validation when the base R4 schema falls short is the developer-side walkthrough.
Neither-valid is louder but easier. The base validator flags a structural error, the receiver rejects the payload, the fix is unambiguous. You have a code bug in the generator and you go fix it. A quick pass through the FHIR R4 Bundle lint tool catches these cases fast.
The confusing case is the middle one. Spec-valid, receiver-invalid. The base validator says green. The partner says red. Neither side is wrong; they are answering different questions. The remedy is to load the partner's profile package into your local validator and rerun. The result is the profile-aware view, and it is the only view that will match what the partner enforces.
Why This Matters When You Onboard Partners
Every partner has a slightly different definition of receiver-valid, and the definition drifts as their IG evolves. If you treat receiver-valid as a moving target, you can build for it: publish their profile package into your CI, re-pin it on their release, and gate every merge on it. For a specific walkthrough of that flow, using a Bundle validator to onboard new EHR partners covers the operational side.
Naming the split, and then loading the profile package that turns it into a single verdict, is the shortest path from a red partner response to a green build. The rest of the tooling either supports that flow or gets in its way.
Sources
- HL7 US Core Implementation Guide STU 6.1.0 - HL7 US Core Implementation Guide STU 6.1.0, canonical receiver-side profile package enforced by US clinical systems