Healthcare Payer Integration: US Guide to Eligibility, Claims, EDI and APIs (2026)

Short answer: healthcare payer integration connects your software to health plans so it can check eligibility, send claims, read claim status and post payments. Most teams do this through a clearinghouse, using HIPAA X12 EDI transactions behind an API or SFTP connection, and add FHIR payer APIs where they need patient, provider or prior authorization data.

For how a US claim moves end to end, see our RCM integration guide.

Updated October 2026. CMS rules, code lists and vendor documents were read on 30 October 2026.

This US payer integration guide is for the engineering lead or founder sizing the work, and for health plans planning EDI integration for health payers. To have a team build or repair it with you, see our payer and clearinghouse integration services.

Watch: How a US Healthcare Claim Actually Moves: 270, 837, 999, 277CA, 835 Explained for Engineers (11:07).

Which transactions does eligibility and claims integration need?

Eligibility and claims integration needs the 270/271 pair, the 837 claim, the 999 and 277CA acknowledgements, the 276/277 status pair and the 835 remittance. Add the 278 for prior authorization and, on the plan side, the 834 and 820.

Two changes are on the way. HHS adopted the first HIPAA claims attachment standards in a rule published on 24 March 2026, and compliance is due by 26 May 2028, so plan for attachments if you send clinical records with claims. X12 has also asked HHS to move past version 5010; we found no final rule adopting a newer version, so 5010 stays the working target for 270, 837 and 835 today.

Direct payer connection or clearinghouse?

Use a clearinghouse unless you are the health plan or nearly all your volume goes to one payer. A clearinghouse gives you one connection and one contract for many payers, while each direct connection brings its own setup, testing and upkeep.

The transport choice matters as much as the vendor. An API suits a check that a user is waiting on. SFTP batch suits large claim and remittance files. A REST API can be a separate product from the batch connection, so ask whether it is in your contract before you scope real-time work.

Healthcare EDI API options compared

A healthcare EDI API accepts JSON or X12, sends X12 to the payer and returns the response in a form your code can read. The options below are not ranked, because the right one depends on your payer mix, volume and contract.

Buyers often ask which payer provider integration providers are recognized for robust integration capabilities. We know of no neutral ranking we would rely on. The better test is a sandbox run with your top payers' real response shapes, followed by a pilot. These tools also fill different roles: a single integration point between payers and multiple health vendors is a clearinghouse job, and a platform that combines EOB delivery with provider payments is usually a revenue cycle product. So the best platform depends on the job. The same goes for the top solutions for ERA, EFT plus payment tracking dashboards, and for real-time eligibility and benefits verification for payers, so judge each against your own workflow.

How does real-time eligibility verification work?

Your system sends a 270 with the member, provider and date of service, and the payer answers with a 271. CAQH CORE operating rules set a maximum of 20 seconds for a real-time response and next-day return for batch, which gives you a basis for timeouts and for what to tell front-desk staff. A health tech startup can add eligibility checks through an API quickly in a sandbox, but production speed depends on your contract and on payer setup.

This synthetic 270 asks for general plan coverage. All names and IDs are invented, and the NPI is the CMS documentation example.

ISA*00*          *00*          *ZZ*SENDERID       *ZZ*RECEIVERID     *261030*1200*^*00501*000000001*0*T*:~
GS*HS*SENDERID*RECEIVERID*20261030*1200*1*X*005010X279A1~
ST*270*0001*005010X279A1~
BHT*0022*13*REF0001*20261030*1200~
HL*1**20*1~
NM1*PR*2*EXAMPLE HEALTH PLAN*****PI*EXPLN01~
HL*2*1*21*1~
NM1*1P*2*EXAMPLE CLINIC*****XX*1234567893~
HL*3*2*22*0~
NM1*IL*1*TESTPATIENT*ALEX****MI*TEST000001~
DMG*D8*19800101~
DTP*291*D8*20261030~
EQ*30~
SE*12*0001~
GE*1*1~
IEA*1*000000001~

The delimiters are set in the ISA header: * separates elements, ~ ends a segment and : separates components. NM1*PR names the payer, NM1*1P the provider and NM1*IL the member. EQ*30 asks about health benefit plan coverage, which is the usual place to start.

The 271 returns coverage status, plan details, copay, coinsurance, deductible and limits in EB segments. Payers fill these differently, so the same deductible can sit in a different place from one plan to the next. Keep the raw response, then map it into your own model.

// Illustrative. Field names differ by clearinghouse.
async function verifyEligibility(patient, provider, serviceDate) {
  const request = {
    payerId: patient.payerId,            // from this clearinghouse's payer list
    provider: { npi: provider.npi, organizationName: provider.name },
    subscriber: {
      memberId: patient.memberId,
      firstName: patient.firstName,
      lastName: patient.lastName,
      dateOfBirth: patient.dob
    },
    dateOfService: serviceDate,
    serviceTypeCodes: ['30']             // health benefit plan coverage
  };

  const response = await clearinghouse.eligibility.check(request);
  await store.saveRaw(patient.id, response);   // keep the source for disputes

  if (response.errors?.length) {
    return { status: 'needs_review', errors: response.errors };
  }
  return { status: 'checked', benefits: normalizeBenefits(response.benefits) };
}

For coverage answers on the schedule, including payers with no electronic route, see our real-time eligibility verification service. When you compare insurance eligibility verification providers on integration options, look at payer coverage, how much of the 271 they parse, and what they return on an error.

A payer API can return data beyond eligibility. Types of payer data include claim status (276/277), remittance (835), prior authorization status (278), and, through FHIR, claims history, encounters, clinical data and coverage. Patient identity verification sits outside these standards, so you need a separate tool or step for it.

How does claims integration work end to end?

Your system builds and checks an 837, the clearinghouse returns a 999 and a 277CA, the payer adjudicates, and an 835 tells you what was paid. A claim can stop at either of the first two checkpoints without any payer decision, so treat each one as its own state.

1. Generate. Map the encounter to ICD-10-CM and CPT or HCPCS codes, then add the billing and rendering NPIs, member data and any authorization number. The 837P matches the CMS-1500 form and the 837I matches the UB-04.
2. Scrub. Check NPIs against NPPES, code validity, payer rules from the companion guide, filing deadlines and duplicates before anything leaves your system.
3. Read the 999. It covers file syntax only. An accepted 999 says nothing about whether the claim will be paid.
4. Read the 277CA. It reports acceptance or rejection for each claim. Do not route on the transaction number alone, because the 277CA and the 277 status response share ST01 = 277. BHT06 tells them apart: TH for the acknowledgement and DG for the status response.
5. Poll with the 276. Acknowledgements and remittance arrive on their own, but current payer status usually comes only when you ask. Build the 276 loop for aging claims from the start. This is how claims status and remittance advice get automated between provider billing and payer systems.
6. Post the 835. Match it to the original claim using the patient control number in CLP01, then match the money to the bank deposit using the TRN segment.

This synthetic 835 fragment shows a $150 claim that paid $95:

CLP*TESTCLAIM001*1*150*95*20*12*PAYERREF0001*11~
NM1*QC*1*TESTPATIENT*ALEX****MI*TEST000001~
CAS*CO*45*35~
CAS*PR*3*20~

The arithmetic is 150 minus 35 minus 20, which leaves 95. CO is a contractual adjustment that the provider cannot collect from the patient, and PR is patient responsibility, here CARC 3 for a copay. Each CAS segment has one group code at the start, followed by repeating sets of reason, amount and quantity. A loop that assumes a group code in every set will misread the quantity. For the posting side, see our guide to payment posting automation.

Clearinghouses may return normalized remittance and denial reason codes in JSON. Ask for a sample, and confirm the raw CAS values come back too, so you can audit the mapping. Common codes, using the wording from the X12 code list:

What does a 278 transaction example look like?

A 278 carries a prior authorization request from the provider to the plan, which the X12 standard calls the utilization management organization. Here is a trimmed, synthetic EDI 278 example, for illustration only, so check it against the implementation guide and the payer's companion guide before you reuse it.

ISA*00*          *00*          *ZZ*SENDERID       *ZZ*RECEIVERID     *261030*1200*^*00501*000000002*0*T*:~
GS*HI*SENDERID*RECEIVERID*20261030*1200*1*X*005010X217~
ST*278*0001*005010X217~
BHT*0007*13*REF0002*20261030*1200~
HL*1**20*1~
NM1*X3*2*EXAMPLE HEALTH PLAN*****PI*EXPLN01~
HL*2*1*21*1~
NM1*1P*2*EXAMPLE CLINIC*****XX*1234567893~
HL*3*2*22*1~
NM1*IL*1*TESTPATIENT*ALEX****MI*TEST000001~
HL*4*3*EV*0~
UM*HS*I*AG**11:B:1~
DTP*472*D8*20261130~
SE*12*0001~
GE*1*1~
IEA*1*000000002~

NM1*X3 names the plan, NM1*1P the requester and NM1*IL the member. UM*HS*I marks an initial health services review. Support for the 278 varies by payer, and many still use portals, phone or fax for some requests. See our prior authorization automation work for how this fits a live workflow.

What do health payers need for EDI integration?

Health payers EDI processing runs the same transactions in reverse: receive 270s and 837s, return 271s, 277s and 835s, and take in 834 enrollment files and 820 premium data. The hard part is usually linking these feeds to core claims and member systems without changing medical policy logic.

• Gateway: trading partner setup, control numbers, 999 and 277CA generation, and a record of every file.
• Member matching: eligibility and enrollment integration services must answer 270s from current 834 data, so late enrollment files show up as false denials.
• Vendor feeds: carriers and TPAs often share eligibility, claims and prior authorization feeds with outside vendors. Agree on file format, schedule and error handling for each feed. Onboarding timelines depend on the carrier's IT capacity, so get them in writing.
• EDI automation for managed care payment: reconcile 835 and 820 data, and test Medicaid managed care rules state by state.

How do Medicare, Medicaid and commercial payers differ?

They use the same X12 standards with different rules around them. Medicare runs through regional Medicare Administrative Contractors, each Medicaid program is run by a state, and commercial plans set rules in contracts and companion guides.

Payer IDs cause much of the routing trouble. For the UnitedHealthcare EDI payer ID, UnitedHealthcare's May 2026 claims payer list shows 87726 for many of its plans, but affiliates can differ. UnitedHealthcare also says to check the member's ID card and warns that a clearinghouse's list may not match its own. Treat a payer ID as a lookup per clearinghouse, transaction and plan, and test it. UnitedHealthcare EDI payments have a separate ERA payer list as well.

What do CMS rules require for FHIR payer APIs?

CMS-0057-F requires impacted payers to run Patient Access, Provider Access, Payer-to-Payer and Prior Authorization FHIR APIs by 1 January 2027. It covers Medicare Advantage, Medicaid and CHIP programs and plans, and QHP issuers on the federal exchanges, so most employer plans are not directly covered.

Drugs are outside the prior authorization provisions. CMS recommends Da Vinci and CARIN implementation guides, such as PDex, PAS, CRD and DTR, and HHS has said it will not enforce the X12 278 requirement against a covered entity using an all-FHIR Prior Authorization API. For patient-directed access, your app uses SMART on FHIR and reads resources like this trimmed, synthetic example:

GET https://payer-fhir.example.com/fhir/ExplanationOfBenefit?patient=Patient/example-001
Accept: application/fhir+json
Authorization: Bearer {smart_access_token}

{
  "resourceType": "Bundle",
  "type": "searchset",
  "entry": [{
    "resource": {
      "resourceType": "ExplanationOfBenefit",
      "status": "active",
      "use": "claim",
      "patient": { "reference": "Patient/example-001" },
      "billablePeriod": { "start": "2026-10-01", "end": "2026-10-01" },
      "payment": { "amount": { "value": 95.00, "currency": "USD" } }
    }
  }]
}

X12 and FHIR will run side by side for a long time, because the rule covers data sharing and prior authorization and leaves claims and remittance on X12. Expect uneven payer API quality at first, and test each payer on its own.

How do you get claims data out of a payer portal programmatically?

Use the standard routes first: 276/277 for status, 835 enrollment for remittance, and FHIR APIs where the payer offers them. Portal scraping should be a last resort, for a gap with no other route, and only if the payer's terms allow it.

Some clearinghouses and payer portals are hard to integrate with, usually because of enrollment paperwork, thin test data and rules that appear only in production. Why is building payer integrations so hard? Mostly because a standard format leaves room for each payer's own rules. Teams work around this with a payer rules table, saved test files and a slow rollout.

You may also see the term payer adoption services. It has no fixed definition, but it typically means outreach and onboarding that gets payers or providers using a new connection, including enrollment, testing and support. Ask for the scope and duration in writing, because programs run for different lengths.

What breaks most payer integrations?

Most launch delays come from enrollment, routing and data mismatches, with parsing bugs behind them. Each of these can be caught before a real claim goes out.

• Wrong payer ID: validate it at registration, per clearinghouse and transaction.
• Enrollment gaps: each provider may need enrolling with each payer for each transaction type, such as ERA. This is paperwork that takes real calendar time, so read our EDI enrollment timeline before you promise a date.
• NPI and taxonomy mismatch: individual versus organization NPI, or a taxonomy that differs between NPPES and the payer's file.
• Coordination of benefits errors: bill the primary first, then send its adjudication data on the secondary 837. Medicare Secondary Payer rules add further cases.
• Companion guide deviations: a loop that is optional in the standard can be required by one payer.
• Duplicate submissions: use an idempotency key and a claim state machine, and reuse control numbers correctly across retries.

How should you test payer integrations before going live?

Test in layers: synthetic files locally, the clearinghouse sandbox, payer test routes where they exist, then a small live pilot. Timelines depend on enrollment and payer response, so set the plan per payer.

1. Local simulation: run the full conversation without PHI, including failures you cannot ask a payer to produce. Our open-source X12 clearinghouse simulator answers 270s and 837s with 271, 999, 277CA and 835 files over SFTP.
2. Clearinghouse sandbox: confirm format and auth. Remember that canned responses do not prove a payer's behavior.
3. Payer test paths: try paid, partly denied, denied and secondary claims where the payer supports them.
4. Live pilot: send a small batch of known-good claims, follow them through to posting, and only then raise volume.

How should you design the integration layer?

Put the clearinghouse behind your own interface, keep payer rules in data, and store every raw file. That way you can change vendors, add a payer and answer a billing dispute without rewriting product code.

• Adapters: define eligibility, claim, status and remittance interfaces, with one adapter per vendor. Our X12 EDI integration services cover this layer.
• Payer configuration: IDs per clearinghouse, filing limits, enrollment status and companion guide rules.
• Route inbound files by content: read ISA and ST values, because file names are not a reliable contract.
• FHIR-ready models: Coverage, Claim and ExplanationOfBenefit map well to internal data, which eases later API work. Treat that as our design view, since it adds mapping work now.
• Monitoring: track request and response errors, acknowledgement gaps and aging claims so that troubleshooting starts from the failed transaction ID.

Where Nirmitee fits

Our payer and clearinghouse work covers new connections and repairs to live ones for US healthcare software teams. In one anonymized clearinghouse claims case study, we worked inside a live X12 pipeline that another team had built. We also publish open-source Da Vinci CRD, PAS and DTR servers tested with Inferno. We are ISO 27001:2022 certified and sign BAAs. We are not a clearinghouse, so you would still hold your own network contract.

If you are planning an eligibility and claims integration, or a live one is causing billing problems, talk to our integration team. Bring your payer list and your current connection type, and we will tell you where we would start.