By Bundle Validation

Vendor Bundle Acceptance Criteria for Health Data Programs

Editorial illustration in botanical-sketch style depicting a botanical vendor-handoff card with producer stalk, receiver leaf, and a red validator gate

Vendor acceptance criteria for FHIR Bundles are the concrete list of rules a receiving system enforces before a payload lands in production. Programs that treat acceptance as a black box usually discover the criteria one rejection at a time; the durable path is to enumerate them up front and gate outbound Bundles against the same list.

Most acceptance criteria in US health-data programs cluster into a small set. Related product context sits under more on FHIR product trade-offs for teams choosing between validator implementations.

The Common Criteria List

  1. Structural conformance — Bundle.type, entry.fullUrl, and entry.request fields match the transaction rules for the intended semantics.
  2. Profile conformance — every resource declares meta.profile when the receiver expects it, and the referenced profile is one the receiver loads.
  3. Cardinality tightening — profile-level 1.. rules are honored where base R4 would allow 0...
  4. Terminology binding — every Coding matches the value set bound by the profile the receiver enforces.
  5. Reference resolution — internal references inside the Bundle resolve to a fullUrl in the same payload or an already-persisted resource on the receiver.
  6. Extension awareness — mandatory extensions the receiver has declared are present and populated.

Each criterion maps to a validator check that runs in isolation. A single validator run against the receiver's profile package covers all six, provided the package has been loaded correctly. A quick pass through the site's Bundle JSON check captures the structural subset before the payload leaves the sender.

The Rejection Response Shape

A vendor that rejects a Bundle typically returns an OperationOutcome with severity, code, and location fields per issue. Acceptance programs that log these responses build a rejection taxonomy over time, and the taxonomy becomes the operational language for negotiating with vendors. The three most frequent codes are required, code-invalid, and invariant.

Each code maps to a specific acceptance criterion: required to cardinality, code-invalid to terminology binding, invariant to profile-level FHIRPath rules. Naming the code up front is faster than parsing the diagnostic string every time.

Package Version Pinning

Acceptance criteria drift as vendors upgrade their profile packages. US Core 6.1.0 and US Core 7.0.0 differ on several cardinality rules and value-set bindings. A program that treats "US Core" as a single moving target inherits the drift as unexplained rejection spikes.

The disciplined response is to pin the package version explicitly in every acceptance contract and to schedule upgrades as their own project artifact. For the wider contract framing, Bundle validation as an interop contract term covers the language that makes drift auditable.

Coordinated Rehearsal Before Live Traffic

Programs that publish acceptance criteria without a rehearsal window usually run the first weeks of live traffic as a de-facto integration test. That posture creates operational risk and inflates the rejection count for reasons that a rehearsal window would catch cheaply. The alternative is a scheduled rehearsal against a staging endpoint with fixture Bundles that mirror expected traffic. For the migration-specific version of that pattern, Bundle validation as an EHR migration risk control covers the operational shape.

Acceptance criteria are not adversarial; they are the shared contract that lets both sides know what green looks like. Enumerating them up front is the shortest path to a stable exchange.

Botanical-sketch diagram of a vendor handoff flow with a hand-drawn producer node, a validator gate stamp, a consumer receiver leaf, and a muted red audit sink at the bottom

Sources