Part 1 of a two-part series. This part covers what a clearing house does and how the transaction set fits together. Part 2 covers building an integration that survives production.
Any HealthTech team building software for providers eventually collides with the same wall: the product documents care beautifully, but getting the provider paid is a different, harder problem. Billing is where clean architecture meets thousands of payers, a 1970s-era data format, and responses that arrive weeks after the claim was sent. Get it wrong and revenue silently leaks; get it right and nobody notices — which is exactly the point.
This guide explains the piece of Healthcare IT that sits in the middle of all of it: the clearing house. We'll cover what it actually does, why the transactions are identified by cryptic numbers like 270, 837, and 835, how to read the transaction set, and the single distinction — rejection versus denial — that most integrations blur and later regret. Part 2 turns to the engineering: timing, reconciliation, security, and choosing a vendor.
A note on terminology: the term appears as both one word (clearinghouse) and two (clearing house). Both refer to the same thing. The two-word form is more common in finance; in US healthcare, both are in use. This document uses the two-word form throughout.
1. What a clearing house actually does
A healthcare clearing house is an intermediary that accepts a transaction from a provider, validates and translates it into the standardized format a payer requires, routes it to the correct payer, and returns the payer's response.
In practice, the integrating system sends JSON, and the clearing house handles the EDI formats, the payer-specific variations, and the correlation of responses that arrive days or weeks later.
Summary. A clearing house is a hub that replaces N × M direct payer integrations with N + M. It moves information about money, not money itself. The transactions are identified by number (270, 837, 277CA, 835), and knowing which transaction arrives at which point is most of the integration work. Submission is straightforward; everything following it is asynchronous.
Scope of this series. In scope: provider-side billing for medical claims — eligibility verification, claim submission, acknowledgment handling, status inquiry, and remittance processing. Out of scope: retail pharmacy claims, which use NCPDP standards rather than X12 and require a separate integration; claim attachments beyond a summary reference; payer-side implementation; and vendor-specific API syntax.
2. The integration problem: why an intermediary exists
The difficulty in healthcare billing is structural rather than clinical.
The United States has thousands of payers, including commercial insurers, Medicaid managed-care organizations, state fee-for-service programs, and Medicare administrative contractors. Each payer maintains its own enrollment process, submission requirements, and rules governing which fields are mandatory and which codes it accepts. A provider billing five payers therefore maintains five relationships, five sets of credentials, and five distinct definitions of a valid claim.
Multiplied across every software vendor serving those providers, direct connections produce a combinatorial problem. An intermediary reduces it to a linear one — the same interoperability logic that underpins Health Information Exchange and modern Healthcare APIs. Each application integrates once, and each payer is connected once. The clearng house maintains the payer-side connections on behalf of every appliccation using it.
3. Why the transactions have numbers
Healthcare EDI in the United States runs on ASC X12 transaction sets, mandated by HIPAA and currently at version 005010. X12 predates the web. It is positionally delimited, hierarchical, and extremely terse, having been designed when bandwidth was expensive and every character counted.
A claim on the wire takes the following form. The example is abbreviated and is not a valid claim; it is included only to illustrate the format.
Each line is a segment (ISA, GS, ST, NM1, CLM). Segments nest inside loops under strict ordering rules. ISA and GS are envelopes carrying control numbers that must be incremented and matched. The value 005010X222A1 identifies the implementation guide the file claims to conform to.
An incorrect delimiter, an incorrectly nested loop, or a mismatched control number causes the entire file to be rejected before any claim is read.
This defines the core value a clearing house provides: the integrating system sends JSON, and the clearing house generates and parses the X12. The format is not impossible to implement directly, but correctness is measured against each payer's own companion guide, and maintaining that knowledge is a full-time specialty.
4. The transaction reference
Here is the full set of X12 transactions used in provider billing. Learning which number means what — and which direction it travels — is most of the conceptual work.
5. Rejection compared with denial
This distinction underpins the rest of the series and is frequently blurred in general explanations. The two outcomes originate from different systems, arrive on different transactions, and require different responses.
A rejection is inexpensive and fast to resolve, provided the system surfaces it. A denial is expensive. Systems that collapse both outcomes into a single failed state train users to ignore both.
6. The transactions in detail
This is the technical heart of Part 1. Each transaction has timing behavior and failure modes worth understanding before you write a line of integration code.
6.1 Transactions 270 and 271: Eligibility inquiry and response
Timing: before care is delivered, ideally at intake. Real time, within seconds.
The integrating system sends a 270 containing the member identifier, name, and date of birth, the provider identifiers, and one or more Service Type Codes (STCs) specifying what to check. The payer returns a 271 containing coverage status, plan dates, and benefit detail.
Three characteristics of this exchange cause most integration problems.
Service Type Codes determine the response, and some payers reject them. STC 30 ("Health Benefit Plan Coverage") is the general code for confirming that coverage exists, while narrower codes query specific benefit categories. Payer behavior varies widely: some return detailed service-level information, some return generic coverage data regardless of the code submitted, and some reject the inquiry because they do not accept that STC for the submitting provider type.
RECOMMENDATION — attempt a short fallback chain of Service Type Codes until one returns the required benefit, then persist the code that succeeded for that payer. This converts the lookup into a one-time cost per payer rather than a per-request guess.
Eligibility failures arrive in AAA segments, and a response can fail while still containing benefits. This is the most frequently missed detail in eligibility integration. The 271 reports rejections in AAA segments, covering conditions including member not found, payer unavailable, and provider not eligible for the inquiry.
REQUIREMENT — treat a 271 containing any AAA errors as a failure, even when the same response also contains benefits data. Partial success is not success. Do not display an active-coverage status derived from a response that has not been checked for AAA errors.
A clean 271 is evidence, not a guarantee. Active coverage does not promise payment. It confirms that the member exists and that the plan is live. Treat the response as a risk-reducing signal before the visit rather than as a contractual commitment. The 271 may also carry an authorization indicator signaling that prior authorization is required — surface this prominently, because the information is far less costly before the visit than after the denial.
6.2 Transaction 837: The claim
Timing: after services are delivered.
Three variants exist, and they are not interchangeable.
An 837 carries a hierarchy of parties. Confusing them is the most common structural error.
Billing provider. The entity that receives payment, typically an organization holding a Type 2 (group) NPI.
Rendering provider. The individual who delivered the service, holding a Type 1 (individual) NPI, carried per service line.
Subscriber or patient. The covered person, identified by member ID, legal name exactly as printed on the insurance card, date of birth, and address.
Service lines. One line per billable service, carrying procedure code, modifiers, date of service, place of service, charge amount, and units.
The billing provider and the rendering provider each carry a separate taxonomy code. These are distinct fields holding distinct values rather than one shared value, and payers reject claims that conflate them.
The Patient Control Number. The claim carries a Patient Control Number in CLM01. The integrating system generates this value, and the payer echoes it back on every subsequent transaction relating to that claim, which makes it the join key for the entire reconciliation flow. Its format rules are stricter in practice than the specification implies:
Use alphanumeric characters only. Many payers mishandle special characters.
Limit the value to 17 characters. X12 permits up to 20, but some payers truncate longer values in remittances and acknowledgments, leaving the returned value unmatchable against the original claim.
Generate the value randomly rather than deriving it. Predictable schemes such as sequential counters, or initials combined with date of service, risk collisions. A collision means matching a claim to the wrong remittance.
6.3 Transactions TA1 and 999: Technical acknowledgments
Timing: within seconds to minutes of submission, though an integrating system may never receive either one.
TA1 acknowledges the interchange envelope, meaning the ISA and IEA wrapper. A TA1 rejection indicates that the outermost packaging was malformed.
999 acknowledges conformance to the implementation guide, reporting syntax errors, missing required segments, invalid code values, and incorrect loop nesting. In HIPAA 5010, the 999 replaced the earlier 997 Functional Acknowledgment.
An API-first clearing house usually absorbs both. It constructs the envelope, so envelope-level failures largely cannot occur, and it runs its own claim edits before forwarding. When a claim fails those edits, the response is typically an immediate 277CA rejection issued by the clearing house itself rather than a 999. The integrating system still requires a state representing a claim rejected before the payer received it, but the transaction carrying that result is likely a 277CA with a rejection category, arriving within seconds from the intermediary. TA1 and 999 are primarily relevant to systems handling raw X12 directly.
6.4 Transaction 277CA: Claim acknowledgment
Timing: within seconds when issued by the clearing house's own edits, or up to several days when issued by the payer. This is the first business-level response.
The 277CA reports whether the claim was accepted into adjudication, using a status category code.
Codes A1 and A2 are not equivalent. Some payers issue only A1. They acknowledge receipt and never issue a separate acceptance. A state machine requiring an accepted status before it will honor a payment will hold those claims in a submitted state indefinitely, while the funds have already arrived. Test payers are particularly prone to this behavior, so the gap frequently surfaces only in production.
REQUIREMENT — a remittance must be able to close a claim on its own, without requiring an intermediate acknowledgment that may never arrive.
Code A3 is not a denial. The description "returned as unprocessable" resembles a denial but is not one. The claim never entered adjudication. The correct response is to correct and resubmit the claim rather than to appeal it.
6.5 Transactions 276 and 277: Claim status inquiry and response
Timing: initiated by the integrating system whenever a claim has produced no further response.
Note the naming distinction. A 277CA is an unsolicited claim acknowledgment arriving shortly after submission. A plain 277 is a claim status response, returned only in reply to a 276. Both share a base transaction but serve different purposes and arrive at different times.
Claims do not always produce a response. A 277CA can be lost, a remittance can be delayed, or a claim can remain unprocessed. The 276 queries a claim's status, keyed on the Patient Control Number. Status responses use a broader set of category codes than acknowledgments: alongside the A (acknowledgment) categories, responses use P categories for pending and F categories for finalized. A claim reported as P2 is in process, while an F category indicates that adjudication is complete and a remittance should follow.
RECOMMENDATION — implement status inquiry as a scheduled job rather than a user-triggered action. A workable policy is to send a 276 for any claim still awaiting a final outcome after 21 days, repeat at intervals, and escalate to a human at 30 days.
The reason to automate this is timely filing. Payer windows commonly range from 90 days to 12 months after the date of service, and a claim that ages past its window becomes unrecoverable revenue. The failure is silent, which makes it more damaging than a visible error.
6.6 Transaction 835: Remittance advice
Timing: days to weeks after acceptance.
The 835, also called an Electronic Remittance Advice (ERA), is the payer's account of its adjudication decisions: which claims it paid, at what amount, which it denied, and why. It closes the reconciliation loop and echoes the Patient Control Number so the response can be matched to the original claim.
Denials and adjustments arrive as two code families that are routinely conflated:
CARC (Claim Adjustment Reason Code) explains why the paid amount differs from the billed amount. This is the substantive reason: not covered, no authorization, duplicate, past timely filing, or patient responsibility.
RARC (Remittance Advice Remark Code) provides supplementary detail qualifying a CARC, often identifying what specifically was missing.
RECOMMENDATION — store both codes in raw form and render them in plain language. A denial displayed as CO-197 is not actionable. The same denial displayed as "prior authorization was required and not obtained" is.
Two further characteristics of the 835 warrant attention. A zero-pay remittance is still a remittance — a claim can be accepted, adjudicated, and paid nothing. That outcome is a denial arriving on an 835 rather than a rejection, and it routes to appeals rather than to correction. And the 835 is not the payment — it is the explanation. Funds move separately by EFT, arranged through the payer and frequently a third-party payment vendor, on a separate enrollment track. The two arrive independently and not necessarily together.
6.7 The remaining transactions
834: Benefit Enrollment and Maintenance. Carries membership and coverage changes from an employer or state agency to a payer. This is not a provider-billing transaction. You'll encounter references to it but are unlikely to send one.
275: Additional information. Carries attachments and supporting documentation. The transaction is standardized, but the workflow is still commonly handled through payer portals and fax, and it is usually appropriate to defer past a first phase.
Pharmacy uses a different standard. Retail pharmacy claims do not use X12. They run on NCPDP standards, with separate intermediaries and a real-time adjudication model. Pharmacy scope requires a separate integration rather than a variant of this one.
6.8 Coordination of Benefits (COB)
Coordination of Benefits determines which payer is responsible for paying first when a patient has more than one active insurance plan — such as employer-sponsored coverage and Medicaid, or plans from two working spouses covering the same dependent. Three points directly affect integration teams:
Medicaid is the payer of last resort. By federal and state rule, Medicaid pays only after all other applicable coverage has been billed and adjudicated; a claim sent to Medicaid without exhausting primary coverage is routinely denied or later subject to recoupment.
Eligibility responses can carry other-coverage information. A 271 may return details of a patient's other active plans; a workflow that stops at "coverage is active" without checking for a primary plan will misroute the claim.
The 837 carries COB data explicitly. Where a primary payer has already adjudicated a claim, its adjustments (from that primary payer's 835) are carried into the secondary claim so the secondary payer can calculate what, if anything, it owes.
How Bitsol approaches healthcare integration
Mapping X12 transactions to a clean internal data model is exactly the kind of work that determines whether a health product scales or stalls. At Bitsol, we treat billing and interoperability as first-class engineering problems, not afterthoughts. Our Healthcare APIs practice builds the connective tissue — FHIR, HL7, and payer-facing integrations — that lets your systems talk to clearing houses, payers, and partners without turning every new payer into a code change. And because protected health information moves through every one of these transactions, our teams design with HIPAA compliance and EHR/EMR integration built in from the architecture up. If your team is weighing whether to build an X12 stack in-house or integrate through a clearing house, let's talk through the tradeoffs →.
Conclusion: the map before the build
Understanding a clearing house is largely a matter of knowing which numbered transaction shows up when, and what each one means for the claim's state. Eligibility is synchronous and fast; the claim is the start of an exchange that unfolds over weeks. The single most valuable habit is refusing to collapse distinct outcomes — rejection versus denial, A1 versus A2, benefits-with-an-AAA-error versus true success — into one ambiguous "failed" state.
That mental model is the foundation. In part 2, we put it to work: the full claim lifecycle and its timing, the four functions a clearing house really performs, transaction enrollment (the timeline killer nobody documents), and the design decisions — idempotency, soft-failure handling, and Healthcare Data Security — that separate a HealthTech billing integration that survives production from one that leaks revenue quietly. The best billing infrastructure is the kind nobody notices — and that starts with knowing the map before you build the road.
