X12 837 claim submission and X12 270/271 eligibility verification are both EDI and are opposite workloads. A claims batch is asynchronous, high-volume, ordering- and acknowledgement-sensitive, and tolerant of minutes. An eligibility check is synchronous, low-volume per transaction, and fails outright if the answer takes longer than the caller’s timeout — often a few seconds, with a person waiting. Platforms optimised for orchestrated batch flow handle the first well and add latency to the second; platforms optimised for API-style request/response handle the second well and struggle with envelopes, control numbers and acknowledgement reconciliation. The common outcome is two platforms and a boundary nobody owns. iQBus is built to carry both on one runtime, in your own Azure tenant.
Every healthcare integration estate carries at least two shapes of traffic, and because both of them say “X12” on the tin, they get scoped as one problem.
They are not one problem. A claims batch and an eligibility check make almost opposite demands of a platform, and the mismatch shows up not at design time but eight months into a replacement programme, when the batch side is working nicely and the real-time side is timing out.
01 / Two shapes
The same standard, opposite requirements
| Batch — 837, 835, 834, 820 | Real-time — 270/271, 276/277 | |
|---|---|---|
| Interaction | Asynchronous. Submit, wait, reconcile later. | Synchronous. Someone or something is blocked on the answer. |
| Success measure | Throughput and completeness. Did all 40,000 claims land, in order, once each? | Latency and availability. Did the answer come back inside the caller’s timeout? |
| Tolerance for delay | Minutes are fine. Hours are often fine. | Seconds. A registration desk with a patient in front of it does not wait. |
| Failure mode | Rejection or partial acceptance, resolved through 999 and 277CA reconciliation, potentially days later. | Timeout. There is no acknowledgement to reconcile — the answer either arrived or it did not. |
| What matters most | Envelopes, control numbers, ordering, idempotency, acknowledgement matching. | Connection reuse, warm compute, predictable tail latency, graceful degradation. |
| Volume shape | Enormous, concentrated in a window. | Modest per transaction, spread across the working day, spiky at open. |
Read down the two columns and the engineering conflict is obvious. Everything the batch column wants — durable queuing, ordered delivery, store-and-forward, reconciliation state — adds latency. Everything the real-time column wants — bypass the queue, keep the connection warm, answer now — removes the guarantees the batch column depends on.
02 / How estates end up with two platforms
The failure is architectural, not technical
Nobody decides to run two integration platforms. It happens in four steps, and each step is individually reasonable.
The replacement is scoped on the loud workload
Claims volume is what everyone can see and what the business talks about. The platform gets evaluated against it, and it evaluates well. Eligibility is a line in the requirements document.
Real-time is deferred to a later phase
Sensible sequencing on paper. In practice it means the eligibility flows stay on the legacy platform while the batch flows leave, which is the moment two platforms start running in parallel with no end date attached.
The later phase discovers the latency budget
Somebody measures end-to-end response time on the new platform and finds it acceptable at the median and unacceptable at the 99th percentile — which is the one the registration desk experiences on Monday morning. The workaround is a direct path that bypasses the platform.
The bypass becomes permanent, and unowned
Now eligibility runs on a path with none of the platform’s tracking, none of its error routing, and none of its governance — and because it works, nobody revisits it. The estate has two integration platforms and a third thing that is not on either.
The bypass is never in the architecture diagram, because it was built during a go-live weekend to solve a latency problem, and go-live weekends do not produce diagrams.
Where the third platform comes from
03 / What to test before you choose
Four questions that settle it early
All four are answerable in a proof of concept and none of them is answerable from a feature matrix. Ask them of any platform, including ours.
Ask these before the contract, not during phase two
04 / What an ESB does about it
Both shapes, one runtime, your tenant
This is the case for an ESB rather than a workflow service or an API gateway, and it is narrower than the usual pitch: the value is not that it does more, it is that both traffic shapes live under one set of controls.
What the batch side gets
837 · 835 · 834 · 820
- Pipelines that stay pipelines — disassemble, validate, decode as staged, deterministic steps
- Envelope and control-number handling as a first-class concern rather than custom code
- Message-level tracking across the whole batch, so a single claim inside 40,000 is findable
- One-click replay for the ones that failed, without resubmitting the batch
What the real-time side gets
270/271 · 276/277
- Serverless Azure compute that scales with concurrency instead of a fixed host fleet
- XSLT 3.0 transformation on the synchronous path, not a separate mapping technology
- The same tracking and the same error routing as the batch path — one place to look
- Configuration changes live with no build and no restart, so a timeout tuning change is minutes rather than a release
And both of them run inside your own Azure tenant with Entra ID — which for anyone moving PHI is not a preference. Eligibility traffic carries member identifiers by definition; a multi-tenant service processing that is a conversation with your privacy office that you may not win.
05 / Honest limits
Three things this does not solve
The payer is still the slow part
Most eligibility latency is spent waiting for the counterparty, not inside your platform. A faster ESB improves the part you control, which is real but is not most of the budget. Measure where the milliseconds actually go before optimising anything.
Batch and real-time still need separate capacity thinking
One runtime does not mean one sizing exercise. Serverless helps because the batch window and the eligibility peak are different times of day, but a platform is not a substitute for knowing your own concurrency numbers.
If you only have one shape, you may not need an ESB
An estate that is genuinely batch-only, or genuinely request/response-only, has simpler and cheaper options and we will say so. This whole argument rests on the mix — the mix is what makes single-shape platforms expensive.
06 / Next
Run the mixed-load test
The Starter tier installs free from the Azure Marketplace into your own subscription, which makes the second proof-of-concept question cheap to answer for real: put a representative batch through it and measure eligibility latency at the same time. That single test predicts more about the next three years than any feature comparison will.
If your estate runs claims and eligibility on the same platform today, keep it that way deliberately rather than by accident. The parity breakdown against BizTalk, including EDI and pipeline handling, is on the alternative page.
Frequently asked questions
Why can’t the same platform handle X12 batch and real-time EDI equally well?
Because the two workloads want opposite things. Batch transactions such as 837 claims depend on durable queuing, envelope and control-number handling, ordered delivery and acknowledgement reconciliation — and every one of those guarantees costs latency. Real-time transactions such as 270/271 eligibility need that pipeline bypassed, because a caller is blocked on the answer and will time out in seconds. A platform tuned for one will force the other into a shape it does not fit.
What is the difference between X12 837 and X12 270/271 from a platform perspective?
837 is asynchronous claim submission measured by throughput and completeness, resolved through 999 and 277CA acknowledgement reconciliation potentially days later. 270/271 is a synchronous eligibility request and response measured by latency and availability, where the failure mode is a timeout and there is no acknowledgement to reconcile. They share the X12 standard and almost nothing else.
How do organisations end up running two integration platforms?
In four reasonable steps. The replacement is scoped against the loud workload, which is usually claims volume. Real-time is deferred to a later phase, so eligibility stays on the legacy platform. The later phase discovers the 99th-percentile latency is unacceptable even though the median is fine. A direct path is built to bypass the platform during go-live, it works, and it becomes permanent — with none of the platform’s tracking, error routing or governance attached to it.
What should we test in a proof of concept for a mixed EDI workload?
Four things: the 99th-percentile synchronous response time under realistic concurrency rather than the median on a warm request; what happens to eligibility latency while a large claims batch is processing on the same runtime; whether both paths can be traced by one operator in one place; and how the platform degrades when a payer endpoint is slow rather than down. The second is the one most often skipped and the one that matters most, because simultaneous is the only mode production runs in.
Does iQBus handle both batch and real-time EDI?
Yes, on one runtime. The batch side keeps pipelines as staged deterministic steps with envelope and control-number handling, message-level tracking across a whole batch and one-click replay for individual failures. The real-time side runs on serverless Azure compute that scales with concurrency, uses the same XSLT 3.0 transformation and the same tracking and error routing, and configuration changes take effect live without a build or restart.
Where does eligibility latency actually go?
Mostly to the counterparty. Most of the round-trip time on a 270/271 exchange is spent waiting for the payer, not inside your own platform, so a faster integration layer improves the portion you control rather than the majority of the budget. Measure where the milliseconds go before optimising anything — including before changing platform.
Does eligibility traffic have data-residency implications?
Yes, by definition — a 270 request carries member identifiers, and the 271 response carries coverage detail. Processing that through a multi-tenant service means that data transits a vendor’s environment, which is a conversation with your privacy office. iQBus deploys inside your own Azure tenant with Entra ID, so messages and data never leave your environment.
Run this on iQBus instead of legacy middleware.
One-click install from the Azure Marketplace. Same standards, modern runtime.