Availity, Waystar, Optum, Office Ally and direct payers
We connect your product to the clearinghouses and payers your customers use: enrollment filed and tracked, SFTP and API connections built to each partner's conventions, acknowledgements routed correctly, and every 835 dollar reconciled. Built by engineers who know where these connections break.
Per payer, per provider, per transaction: filed in week one and tracked.
SFTP folders or APIs, IP allowlists and each partner's filename rules.
Inbound files routed by content, 277CA and 277 told apart by BHT06.
835 CAS adjustments read correctly and matched to claim lines.
The short answer
A clearinghouse connection looks simple on a vendor slide: send files, get files. In production it means payer enrollment that takes weeks, IP allowlists, per-clearinghouse filename and folder rules, a real-time API that may be a separate contract, two different transactions that both call themselves 277, and 835 adjustment codes that are easy to misread. We build connections to Availity, Waystar, Change Healthcare (Optum), Office Ally, API-first clearinghouses and direct payer endpoints that handle all of it, so your product reaches payers without your team learning each trap the expensive way.
Integration targets
Each route has its own transport, contract model and conventions. These are the ones buyers ask us about most.
| Target | Typical transport | Strength | What we design for |
|---|---|---|---|
| Availity | EDI clearinghouse over SFTP, plus APIs for eligibility, claim status and more | Deep direct connectivity with large commercial and Blue plans | Which APIs your contract includes, and payer-specific enrollment through Availity |
| Waystar | SFTP batch with extension-based routing; REST APIs as a separate product line | Broad payer list and strong claim management tooling | Filename extensions that route the file, write-only upload folders, and confirming API entitlement before scoping real time |
| Change Healthcare (Optum) | SFTP batch and APIs | One of the largest payer networks | Reconnection and fallback planning after the February 2024 outage |
| Office Ally | SFTP and web upload | Popular with small practices and cost-sensitive products | Its own file naming, response formats and enrollment forms |
| API-first clearinghouses | JSON APIs over X12, such as Stedi | Developer-friendly real-time eligibility and claims | Mapping JSON back to X12 meaning: CAS groups, status codes, companion rules |
| Direct payer and Medicare MAC | Payer SFTP or API; MAC connectivity through a network service vendor | No intermediary on high-volume payers | Separate enrollment, submitter IDs and test cycle per payer |
We integrate with the clearinghouse your customers already use and design a second route so an outage does not stop your cash flow.
What we build
Each workstream ships with a specification, tests and an owner.
A tracker for every payer, provider identifier and transaction that needs enrollment: claims, 835 ERA and EFT through CAQH EnrollHub where payers use it. We file in week one and chase it, because enrollment usually sets the go-live date.
ERA · EFT · CAQH EnrollHub · submitter ID · payer ID
EDI enrollment timelines →Upload and download folders, filename and extension rules, polling, archive handling, IP allowlisting and credential rotation, plus real-time APIs where your contract includes them.
SFTP · REST · IP allowlist · key rotation
Clearinghouse integration in production →Inbound files routed by ISA and ST content, never by filename alone, with 277CA (BHT06 TH) and payer 277 status (BHT06 DG) sent to different handlers.
ISA · ST01 · BHT06 TH and DG · 999 · 835
Waystar 837, 835 and 277CA setup →Payer status never arrives on its own. We build a 276 aging schedule, or a real-time status API call, so claims do not sit silently past their expected turnaround.
276/277 · status category codes · aging rules
X12 EDI integration services →CAS repeats reason, amount and quantity triplets under one group code at position one. We parse it that way, keep contractual (CO) apart from patient responsibility (PR), and queue anything that does not match.
CAS CO, PR, OA, PI · CARC · RARC · PLB
Denial codes CO-45 and PR-27 explained →A second route with its own enrollment, so an outage or a contract change becomes a routing switch, not a crisis. We also migrate products between clearinghouses without losing in-flight claims.
Dual routing · in-flight claim tracking · cutover plan
Integration monitoring and support →Buyer decisions
Ask these questions before you sign. They decide how much integration work follows the contract.
| Question | Why it matters | What good looks like | Red flag |
|---|---|---|---|
| Is the API in our contract? | Batch EDI and real-time APIs are often sold separately | Eligibility and status APIs named in the order form | API access promised verbally only |
| Which payers are covered, and how? | Some payers route through another clearinghouse or need paper enrollment | Payer list with transaction support and enrollment method per payer | A single payer count with no transaction detail |
| What do acknowledgements look like? | 999, 277CA and proprietary reports differ per vendor | Standard 999 and 277CA delivered for every batch | Only a portal report, no machine-readable file |
| How are files named and routed? | Filename conventions change and are rarely contractual | Documented conventions plus stable ISA identifiers | Routing that only works on filename |
| What happens in an outage? | The February 2024 Change Healthcare outage stopped claims for weeks | Status page, SLA and a clean path to a second clearinghouse | No plan beyond waiting |
| How long does enrollment take? | ERA and claim enrollment gate go-live | Enrollment dashboard with per-payer status | Enrollment handled by email with no tracking |
We help run this evaluation and then build the connection to whichever clearinghouse you choose.
Integration boundaries
Most delays come from enrollment and access, not code. We write ownership down on day one.
Payer routing, front-end edits, 999 and 277CA acknowledgements, enrollment processing and contract terms.
Enrollment approval, adjudication, 277 status, 835 remittance and payment.
Contracts, provider identifiers (NPI, tax ID), billing policy and approval of enrollment forms.
Transport, routing, validation, correlation, polling, retries, replay and alerts. Defects here are ours to fix.
Files move over SFTP or TLS from allowlisted IPs, credentials are rotated, development uses synthetic files, and we sign a BAA and work inside our ISO 27001:2022 certified management system.
Deliverables
Everything below lands in your repository and your runbook.
Transport, folders, filenames, identifiers, transactions and the companion guide rules in force.
Every payer, provider and transaction with its enrollment status, owner and dates.
Versioned connector with per-clearinghouse profiles held in configuration.
How every inbound file type is identified and matched to its request.
Accepted, rejected and partially paid cases through the simulator and the clearinghouse test environment.
Replay, credential rotation, outage response and the switch to a backup route.
Delivery phases
A first clearinghouse connection typically takes 6 to 10 weeks. Enrollment runs in parallel and commonly takes two to six weeks per payer, longer for some government plans.
Weeks 1 to 2
API entitlement confirmed, IP allowlist and SFTP access requested, enrollment filed
Weeks 2 to 5
Connector, routing, correlation and 835 parsing built with synthetic files
Weeks 4 to 8
Test files exchanged, rejections closed, payer enrollments confirmed
Weeks 6 to 10
Cutover, first 835 cycle reconciled, monitoring and runbook handed over
Cost drivers
You get a fixed scope after one scoping call. These are the factors that move it.
One connection is the smallest unit. A backup route or a migration adds a second profile.
Real-time eligibility and status APIs add latency handling and rate limits on top of batch.
Eligibility, claims, status and remittance each add routing and correlation rules.
Many payers and provider identifiers mean more enrollment tracking and follow-up.
Auto-posting 835 remittance needs agreed rules for reversals, recoupments and PLB adjustments.
Monitoring, credential rotation and partner changes are priced per connection.
Proof
Client names are withheld. The code and tools linked here are public.
A drop-in stand-in for a real clearinghouse SFTP connection: 120 scenarios across 270/271, 278, 837, TA1 and 999, 277CA, 835 and 276/277, with your own control numbers, trace numbers and patient control numbers echoed back so correlation code is tested before enrollment finishes.
View the simulator on GitHub →Built and run for a US behavioral health group: the signed session note becomes the 837P claim, eligibility is checked before every visit, and denials land in a work queue with the payer's own CARC and RARC reason attached. Our first clearinghouse test passed when it should have failed, so every test now takes the exact path production takes.
Built for a US wound care provider group: coverage checked against the clearinghouse before the visit, the dense 271 benefit response read into plain terms for the front desk, and a CPT, modifier and NCCI scrub before any claim leaves the building.
Our browser-based X12 viewer decodes 837, 835, 270/271, 276/277, 277CA and 999 files segment by segment, explains CARC and RARC codes, and never uploads the file anywhere.
Open the EDI Inspector →We are ISO 27001:2022 certified and sign Business Associate Agreements for work that touches patient data.
FAQ
Clearinghouse integration connects your product to a healthcare clearinghouse that routes X12 transactions to payers. It covers enrollment, the SFTP or API connection, sending 270 and 837 files, receiving 999, 277CA, 271, 277 and 835 responses, and correlating every response back to the claim or inquiry it answers.
Start with the one your customers already use, since switching means re-enrollment. Availity is strong for commercial and Blue plans, Waystar for claim management, Change Healthcare (Optum) for reach, Office Ally for small practices, and API-first vendors for JSON and real-time eligibility. We connect to any of them and often to two.
Ask whether the API is in your contract, which payers are covered for which transactions, whether you get standard 999 and 277CA files, how files are named and routed, what the outage plan is, and how enrollment is tracked. Those answers predict most of the integration effort.
We build an SFTP connector that uploads 837 and 270 files with the clearinghouse's naming rules, polls the download folders, routes each inbound file by its ISA and ST content, and matches every acknowledgement, status and remittance back to the claim in your system.
Both use transaction code 277 in ST01. The 277CA is a claim acknowledgement from the clearinghouse or payer front end (BHT06 TH); the 277 claim status response comes from the payer (BHT06 DG). Routing on ST01 alone sends payer status into the acknowledgement handler and silently misreports claims, so we route on BHT06.
Enrollment is the paperwork that authorizes a provider to send claims or receive 835 ERA and EFT through a given route, filed per payer, per provider identifier and per transaction. It commonly takes two to six weeks per payer and longer for some government plans, so we file it in week one.
They classify each 835 adjustment. CO is a contractual obligation the provider writes off, PR is patient responsibility such as deductible or coinsurance, OA is other adjustments, and PI is payer-initiated reductions. Each CAS segment carries one group code followed by reason, amount and quantity triplets.
Usually most, rarely all. Some payers route through another clearinghouse, some need separate enrollment or paper forms, and support varies by transaction. We check your payer list against the clearinghouse's coverage before the build and plan direct connections for the gaps.
For any product whose customers depend on cash flow, yes. The February 2024 Change Healthcare outage stopped claims for weeks for many providers. A second route with its own enrollment turns an outage into a routing change, and we design the connector so switching is configuration.
Yes. We build the new connection and enrollment in parallel, track claims already in flight on the old route until their 835s arrive, and cut over by payer or by customer so nothing is lost between the two.
A first clearinghouse connection typically takes 6 to 10 weeks. Enrollment runs in parallel and often sets the go-live date. We build against our open-source clearinghouse simulator while enrollment and IP allowlisting move, so testing starts before access arrives.
Cost depends on the number of clearinghouses and direct payers, batch versus real-time APIs, the transactions in scope, enrollment volume, 835 posting automation and the support level. We give a fixed scope after one scoping call, before you commit.
Next step
Tell us your clearinghouse, payer list and transactions. An integration engineer replies with the enrollment you need, the traps in that connection and a fixed scope.
Send your details
Tell us the clearinghouse or payers, the transactions and where the current connection fails. Please do not send real EDI files with patient data.
