The primary payer has paid, and the hard part starts: a secondary claim that carries the primary's decision exactly, and a second payer that has to work out what it owes. Agnotic Technologies builds software for both sides of coordination of benefits, for providers, billing companies, health plans and TPAs.
Trusted by global innovators
Secondary claims and COB software handles everything after the first payer pays. On the provider side it builds a clean secondary 837 from the primary 835 remittance. On the payer side it confirms the order of coverage and calculates the secondary plan's share. Agnotic Technologies builds this software for providers, billing companies, health plans and TPAs.
The same transaction looks different from each end. Most of our COB projects sit on one side, and some billing companies and TPAs need both.
Turning the primary remittance into the next claim, then posting what the secondary pays.
Receiving a claim where another plan has already paid, and deciding what this plan owes.
Most secondary problems are data problems: something from the primary payer's decision did not travel to the next claim.
Wrong order: the plan billed as secondary is really primary, so the first claim was denied as covered by another payer and the second one never should have gone out in that form.
Lost line detail: the primary paid by service line, but the secondary claim reports only a claim total, so the second payer cannot apply its benefits line by line.
Adjustments that do not balance: charge, paid amount and adjustments on a line do not add up, and the claim is rejected before anyone looks at it.
Reason codes rewritten: group or reason codes from the primary remittance are changed or dropped, so the secondary payer cannot tell deductible from a contractual write-off.
Duplicates with crossovers: a claim the primary forwarded automatically to the secondary is also billed by the provider.
Stale coverage: the patient changed plans, but the order of coverage on file still reflects last year.
Each row is a piece of the primary payer's decision, where it goes on the secondary 837 and the edit we build to stop a claim that is missing it. Segment and element detail follows the X12 implementation guides your team licenses.
| From the primary 835 | Where it goes on the secondary 837 | Edit that catches it when missing |
|---|---|---|
| Primary payer identity and the payer's claim control number | The other payer section of the secondary claim | Block release when the other payer on the claim does not match the payer that sent the remittance |
| Claim-level paid amount | Other payer paid amount at claim level | Paid amount present, and equal to the sum of line payments when the primary paid by line |
| Service line payments (835 Loop 2110) | Line adjudication detail for each matching line (837 Loop 2430), with the adjudication date | Every billed line matched to a primary line, or explained as denied or not covered |
| Adjustments with group and reason codes (CO, OA, PI, PR) | Adjustments carried at the same level, with the group and reason codes unchanged | Charge, paid and adjustment amounts reconcile on each line before release |
| Patient responsibility: deductible, coinsurance and co-payment (reason codes 1, 2 and 3) | Reported in the patient responsibility adjustments the secondary uses to apply its benefits | Warn when the primary applied a deductible but the claim carries no patient responsibility |
| Reason code 22 (care may be covered by another payer) | Not a secondary claim yet: the order of coverage needs review | Route to coverage review instead of building a secondary claim |
On the payer side, the share is a calculation the plan has to be able to explain on appeal. We build it as configured rules, not code changes.
Other coverage on file is checked against the claim. If this plan should be primary, the claim pends for coverage review instead of paying as secondary.
The primary payer's paid amount and adjustments come from the claim itself, so the calculation starts from what the other plan actually did.
Each plan's coordination method sits in its benefit configuration, with an effective date, so a change in plan design does not need a release.
Where Medicare is the secondary payer, its own rules set the amount, including the lowest of three amounts and no payment when the provider accepts the primary payment in full.
Modules we build for providers, billing companies, health plans and TPAs.
A work queue that builds the secondary claim from the primary remittance and shows each edit failure in plain words.
Coverage on file per patient and date of service, with the reason each plan sits in its position.
Primary remittances parsed and matched to the original claim lines, including split and bundled lines.
Claims the primary forwards to the secondary are flagged, so the provider does not bill them again.
The secondary plan's payment calculated from the primary decision and the plan's COB method, with every step stored.
The same logic run again for a third payer, carrying both earlier decisions.
Secondary claims waiting, rejected or paid, by payer, reason and age.
Drafting a summary of why a secondary claim failed or suggesting likely other coverage from claim history, always reviewed by a biller or examiner.
The provider-side path we build, from the 835 arriving to the secondary payment posted.
The primary remittance is received from the clearinghouse and parsed, and each claim payment is matched to the original claim.
Coverage on file confirms who is next. A reason code 22 denial goes to coverage review, not to a secondary claim.
Payer identity, paid amounts, line adjudication and adjustments are copied onto the secondary claim without rewriting codes.
Line matching, balancing and patient responsibility checks run before the claim can leave.
If the primary forwarded the claim to the secondary itself, the system waits for that payment instead of billing again.
The secondary 837 goes out, acknowledgments and status are tracked, and the next 835 is posted against it.
The transactions, code sets and tools behind the secondary claims software we build.
Measures we build dashboards around, agreed with your billing or claims leads.
Primary paid, secondary not built, by age and payer.
Secondary claims rejected, grouped by the edit that would have caught them.
Claims denied as covered by another payer, and how long review takes.
Time from the last payer's payment to the patient statement.
A HIPAA-ready maternal health platform enabling remote patient monitoring, care coordination, and personalized engagement from pre-pregnancy through postpartum.
A women’s health product experience focused on guided care journeys, education, and compliance-aware workflows to support long-term engagement.
Common first releases, each scoped to one workflow.
Secondaries built from the 835 with edits, for a billing team that does them by hand today.
Coverage records reviewed and corrected before claims go out.
Forwarded claims matched to payments so nothing is billed twice.
A secondary share engine for a plan or TPA that calculates it manually.
Workflows for claims where Medicare pays after another plan.
One secondary process across many provider clients and payers.
The systems that hold coverage, claims and payments.
We build secure, scalable products designed for privacy, interoperability, and regulatory readiness from day one across every sector we serve.
Protect PHI with privacy-first architecture, encrypted storage and transmission, and strict access controls.
We combine deep technical expertise with industry-specific knowledge to deliver solutions that aren't just functional, but transformational.
We implement rigorous security protocols and compliance standards (HIPAA, GDPR, SOC2) across all industrial solutions to protect sensitive data.
Our architectures are built to handle massive data loads and user bases, keeping performance steady whether you're serving ten or ten million.
Using our suite of internal tools and proven frameworks, we cut setup work so your first release reaches users sooner.
Beyond simple wrappers, we build deep-learning integrations and predictive analytics directly into the core of your industry-specific workflows.
We start from your own rejected and stuck secondary claims. Timing depends on scope; we agree a fixed first release on the scoping call.
We look at your claim volumes by payer, your clearinghouse and where secondaries stall today.
Your team shares de-identified remittances and rejected secondaries; we map each failure to an edit.
One workflow, such as the secondary work queue for your main payers, live with audit logging.
More payers, tertiary claims, crossovers or the payer-side calculation added on the same rules.
Rule and code set updates when X12 code lists or payer requirements change, under agreed change control.
Short facts behind the transactions and calculations, each linked to its primary source.
HIPAA defines the coordination of benefits transaction as the transmission from any entity to a health plan of claims or payment information, for the purpose of determining the relative payment responsibilities of the health plan.
Source: 45 CFR 162.1801 (eCFR)For the coordination of benefits transaction, HIPAA adopts the ASC X12 837 Version 5010 claim standards for professional (005010X222), institutional (005010X223) and dental (005010X224) claims, and the NCPDP Telecommunication Standard for retail pharmacy drug claims.
Source: 45 CFR 162.1802 (eCFR)X12 claim adjustment reason code 22 says the care may be covered by another payer per coordination of benefits, and code 23 reports the impact of prior payer adjudication, including payments and adjustments, for use only with group code OA.
Source: X12, Claim Adjustment Reason CodesFor services paid on a fee schedule or reasonable charge basis, the Medicare secondary payment is the lowest of three amounts: the charge minus the primary payment, what Medicare would pay with no primary payer, or the higher of the Medicare amount and the primary payer's allowable charge minus the primary payment.
Source: 42 CFR 411.33(a) (eCFR)Medicare makes no secondary payment when the provider or supplier is obligated to accept, or voluntarily accepts, as full payment a primary payment that is less than its charges.
Source: 42 CFR 411.32(b) (eCFR)We don't just build products; we forge lasting partnerships. See how we've helped industry leaders transform their vision into technical reality.
“I can clearly see how Agnotic has a unique way of handling end-to-end development. They are always active on quick chat and provide support quickly.”
Aaron Phelan
Founder, Benchmark
“Agnotic combines deep technical expertise with strong domain knowledge. They understand the business context, anticipate challenges, and make collaboration smooth and effective.”
John Pasmore
Founder, Latimer
“Agnotic is the best technical team we evaluated. Their engineering excellence made our work dramatically easier and allowed us to stay focused on what matters most for maternal care outcomes. They took full ownership of the technical execution, and we are always happy to continue working together.”
Kim Smith
Founder, My Lauren
This page covers the claim after the first payer pays. These pages cover the primary claim and the payer systems around it.
Intake, benefit rules, pricing and pend queues for payers and TPAs.
The provider revenue cycle from registration to payment.
Automated claim building, scrubbing and submission.
837, 835 and eligibility transactions with clearinghouses and payers.
Membership, benefits and claims for health plans.
Explore other production-grade engineering platforms we deliver across healthcare.
The technical patterns behind this platform translate naturally into adjacent verticals.
