Care Connect for TPAs — Payments & Data Companion

1. Scope and how to read this

The integration guide describes what Care Connect does and how the pieces fit together at a business level. This document is the field-level companion: what arrives, what every column and segment means, what happens at the edges, and what has to be true for your payments to reconcile against ours.

It assumes you have read the integration guide. It does not repeat it.

Everything in this document is version-sensitive. Where a field's meaning is not obvious from its name, the meaning is stated explicitly; prefer this document over inference from the header text.

2. The two billing modes, and how you get one

Care Connect bills a Company one of two ways, and they are mutually exclusive:

The integration guide states that "when using claims, there are no separate invoices." That means you are not billed twice — it does not mean the documents disappear.

An invoice PDF is still produced for each claim batch in claims mode, along with the same supporting spreadsheets. They cover exactly the activity in that batch, and they are available if you want them. Many partners find them useful for reconciliation, for finance teams who would rather read a PDF than an 837, or for passing a readable summary to the employer group. Others ignore them entirely. Both are fine.

What changes is their standing: in claims mode the invoice is a reference document, not a demand for payment. The obligation is the claim.

Operational rule for claims mode: pay against the claim and remit with an 835. Do not pay against the invoice PDF, and do not treat it as a second bill for the same care — it describes the same activity as the claims in that batch.

2.1 What selects the mode

The mode is configured per Company during onboarding. It is not something that varies by voucher, by provider, or by transaction.

2.2 Artifacts by mode

Everything we produce in invoice mode is also produced in claims mode. The difference is which artifact carries the obligation, not which artifacts exist.

Two consequences worth noting for claims mode:

• Payment status on the invoice artifacts tracks the claim. A line shows as settled once the corresponding claim is paid and the remittance reconciles — not because anyone paid the invoice.
• The outstanding items spreadsheet is a useful cross-check. It lists what is still open for a Company across periods, which is a quicker read than reconciling claim by claim when something has gone astray.

3. Key terms

Definitions for the terms used throughout this document and in the artifacts themselves.

3.1 Company

The billing entity on our side. A partner may have exactly one Company, or several — see §4.

A Company owns its own invoice cadence, payment method, and billing mode. Nothing about a Company's configuration is inherited from or shared with another Company under the same partner.

3.2 Group Name

The Group Name column in our spreadsheets is the provider organization that delivered the care — a hospital, ambulatory surgery center, imaging center, or physician group.

Invoice detail rows are grouped and subtotalled by this column, so those subtotals are per provider organization.

3.3 Group ID and Member ID

The subscriber group number and member identifier from the member's underlying insurance, captured at purchase and passed through unchanged. They appear as columns in the invoice detail spreadsheet and, in claims mode, as SBR03 and NM109 on the claim.

If you need Group ID and Member ID reliably populated — including for the Group ID-based separation described in §4.1 — tell us and we will make them required at purchase for your Company. Once required, a purchase cannot be completed without them.

Where they are not required and happen to be missing, the claim is still constructed and a placeholder is substituted in their place — a well-formed value such as member ID 1234567890 or group ID 12345 that is not a real identifier. If you are relying on either field, request that it be required rather than treating a placeholder as data.

4. One Company or several

A partner may be set up as a single Company or as several. This is one of the more consequential onboarding decisions, and it is worth making deliberately.

4.1 Start with one Company

For most partners, a single Company is simpler. All activity flows into one billing relationship — one invoice per period, one claims feed, one balance — and you separate it by client downstream using the Group ID supplied at purchase (§3.3).

The Group ID travels with every voucher and appears on both sides of the integration: as a column in the invoice detail spreadsheet, and as SBR03 on the claim. If your clients are already distinguishable by their subscriber group number, that is usually all the separation you need, and you get it without any additional setup on either side.

This works well when:

• Your clients map cleanly to distinct group numbers.
• You are content to receive one invoice or one claims feed and split it yourself.
• Commercial terms — cadence, payment method, billing mode — are the same across clients.

4.2 When to split into several Companies

Separate Companies are the right answer when the clients genuinely need to be separate financial relationships rather than separate slices of one. Typically that means:

• Different commercial terms — a client needs its own invoice cadence, payment method, or billing mode (§2). These are per-Company and cannot vary within one.
• Separate funding — the money comes from different accounts, and a combined invoice could not be paid as one. (Claims can be paid from multiple accounts as long as appropriate trace numbers are provided.)
• Separate reconciliation obligations — a client requires its own invoice document, its own balance, and its own audit trail rather than a filtered view of a shared one.
• Group ID is unavailable or unreliable for the clients in question.

The cost is setup and ongoing maintenance. Each Company is configured, tested, and maintained independently; nothing is inherited between them (§4.3). Each produces its own invoices, its own claims feed, and its own balance to track. Adding a client means adding a Company rather than just supplying a new group number.

The two approaches can be mixed — most clients under a shared Company, with a Company of their own for the handful that genuinely need it.

4.3 What is per-Company

Each Company independently carries:

• Billing mode (invoice or claims — §2)
• Invoice cadence: daily, weekly, or monthly
• Payment method
• Whether patient card payments may be split against the Company balance (§9.4)
• Whether claims carry the total price and the patient-paid amount, and whether encounters the patient paid in full are invoiced and claimed (§9.4) — both off unless you ask for them

Two Companies under one partner can legitimately be on different cadences and even different billing modes.

4.4 What is never aggregated across Companies

• Invoices. An invoice belongs to exactly one Company. There is no partner-level invoice.
• Invoice totals and balances.
• Claims. A claim traces to one voucher, which traces to one Company.

This is the practical consequence of §4.2: once split, there is no combined view back across Companies. If you want one, you build it.

4.5 Identifying the Company on an artifact

The 837 does not identify the Company. The billing provider on every claim we send is Tendo (§10.1), and no segment carries our Company identifier. Attribute claims using the subscriber group number (SBR03) you supplied at purchase — which is the same mechanism §4.1 recommends for splitting by client, and works whether you have one Company or several.

5. Artifact catalog

5.1 Invoice PDF

The payment summary, remittance instructions, and a line for every voucher activity in the period. Detailed in §7.

In invoice mode this is the request for payment, one per Company per billing period. In claims mode one is produced per claim batch as an informational summary of that batch (§2).

5.2 Invoice detail spreadsheet

Row-per-line detail behind a single invoice, with patient, provider, coding, and identifier columns that do not fit on the PDF. This is the working file for reconciliation. Field dictionary in §6.2.

5.3 Outstanding items spreadsheet

Every unpaid or partially paid line for a Company across all invoices, not just the current one. Use this to answer "what is still open" without walking invoice by invoice. Same column set as §5.2.

5.4 Invoice summary spreadsheet

One row per invoice rather than per line — invoice number, dates, totals, status. Use for invoice-level tracking and aging.

5.5 Voucher history spreadsheet

Every voucher for a Company regardless of billing status, including vouchers that were purchased and never used. Field dictionary in §6.3.

This is the widest view of activity we produce. It is the only source of unredeemed and cancelled vouchers as first-class rows, rather than as adjustments against a redemption, and the only artifact that reports the patient-paid portion of every purchase (§9.4) whatever your Company's settings.

Worth pulling even in claims mode. Unless your Company has the patient-paid options in §9.4 enabled, the claims feed alone will not tell you what a member paid or show encounters the Company was not billed for.

5.6 837 claims (837P / 837I)

Professional (005010X222A1) and institutional (005010X223A2) claims, in claims mode only. Detailed in §10.

5.7 835 remittance

Your remittance advice back to us. Detailed in §11.

5.8 Exchange

EDI is exchanged through the Optum iEDI clearinghouse in both directions. We do not exchange 837 or 835 files directly with partners; iEDI is the preferred and supported path.

PDFs and spreadsheets are delivered outside the clearinghouse, through the Care Connect interface and by notification when a report is ready.

6. Field dictionaries

6.1 A note on amounts

Unless a column says otherwise, every monetary value in every artifact is the amount invoiced to the Company. It is not a billed charge, not a provider's chargemaster rate, and not a contracted allowed amount. Care Connect prices prospectively: the amount was fixed and prepaid at purchase, before care was delivered.

The exceptions are the values that report the patient's share or the full price: Patient Responsibility and Total Procedure Price (§6.2), Procedure Price and Patient payment (§6.3), and — only for a Company with total price on claims enabled — the claim charge and the patient-paid amount on the 837 (§10.3).

This matters most when the value lands in a field whose name implies otherwise — see §10.3 for the claim-level consequence.

6.2 Invoice detail spreadsheet

Adjudicate against Encounter CPT Codes, not Procedure CPT Codes. The first is what was reported for the encounter. The second is the catalog of codes the purchased bundle may cover, and will often list codes that were not performed.

6.3 Voucher history spreadsheet

Status values:

Available is not the same as "never used." A voucher that was redeemed and then reversed returns to Available. Read it alongside Most Recent Redemption Date and Reason.

7. Reading an invoice

7.1 Structure

An invoice has a header (Company name, invoice number, invoice date, and the period it covers), a payment summary, remittance instructions, and up to three line sections.

7.2 The summary and the arithmetic

The summary reports three figures and a total:

  Vouchers redeemed this period          + redeemed
  Vouchers unredeemed this period        − |unredeemed|
  Adjustments this period                − |adjustments|
  ─────────────────────────────────────────────────────
  Total amount due                       = the balance

Reversals and adjustments are shown in parentheses and reduce the amount due. The total is what to pay.

7.3 The three sections

Vouchers Redeemed this Period. One line per redemption, with patient, voucher number, procedure and reported CPT, provider, date of service, and amount. Grouped by provider organization with a subtotal per group and a grand total.

Vouchers Unredeemed this Period. Reversals — vouchers whose redemption was undone. Columns differ from the redeemed table: in place of procedure and service date there is an Adjustment Description carrying the reason and any note. Amounts are negative.

Adjustments this Period. Other corrections, such as transfers between parties. Amounts are negative.

Sections are omitted entirely when they have no activity, so an invoice with no reversals has no unredeemed section rather than an empty one.

7.4 Why one voucher can appear twice with opposite signs

If a voucher is redeemed and then reversed within the same billing period, both events fall in the period and both appear: a positive line in the redeemed section and a negative line in the unredeemed section. They net to zero and the voucher contributes nothing to the total.

This is correct and expected. Do not treat the positive line as an amount owed — read the invoice's total, not the redeemed subtotal.

If the reversal happens after the invoice that billed the redemption, it appears instead as a credit on a later invoice. See §9.1.

7.5 Lines of $0.00

Where your Company has fully patient-paid encounters enabled (§9.4), an encounter the patient paid in full appears in the redeemed section as a $0.00 line, and its reversal as a $0.00 line in the unredeemed section. These lines are always Paid in Full, carry no balance, and change no total.

An invoice whose lines are all $0.00 totals zero and is created Paid in Full. There is nothing to pay against it.

8. Vouchers with more than one redemption

Read this before building anything that assumes one voucher equals one line or one claim.

8.1 What happens

Almost every procedure is paid out to more than one party. A surgery typically pays the facility and the surgeon separately; an imaging study typically pays the facility and the reading radiologist. This is the normal case, not an exception.

What varies is how that split reaches you:

• For most providers, the split happens on our side after a single redemption. The provider redeems the voucher once, we divide the payment among the parties internally, and you see one line on the invoice and one claim.
• For some providers, each party redeems their own portion separately. Each of those redemptions produces its own line on the invoice and its own claim in claims mode.

Where separate redemption is in effect, all the resulting lines and claims carry the same voucher number, and their amounts sum to the voucher's total price.

So a single $2,000 voucher may reach you as one line of $2,000, or as two lines — say $1,700 and $300 — depending on how that provider is set up. Both represent the same underlying payout to two parties; only the second exposes it as separate lines.

8.2 How common this is

Whether a provider redeems separately by party is a configuration choice tied to that provider — not to the procedure, the patient, or the Company — and it is stable for that provider over time.

You cannot assume one behavior or the other without checking a given provider. Build for both.

8.3 Reconciling the pieces back to one voucher

• On the invoice: group by Voucher Number. The lines for one voucher may not be adjacent, since rows are ordered within provider-organization groupings and the parties may belong to different groupings.
• In EDI: the claims share a bundle identifier derived from the voucher. They are distinct claims with distinct claim identifiers and must be adjudicated and remitted individually.
• Do not attempt to match a voucher's total price against a single line or claim amount. Match the sum.

8.4 Planned change

We intend to move providers that redeem separately by party to the single-line, single-claim behavior already used elsewhere, in a future release. No date is committed. The underlying payout to multiple parties is not changing — only whether it is exposed to you as separate lines.

When it lands, the effect will be a reduction in line and claim counts for affected providers with no change to totals.

9. Other edge cases and adjustments

9.1 Reversal after the redemption was invoiced

Where a redemption was billed on one invoice and reversed later, the reversal appears as a credit on a subsequent invoice, reducing that invoice's total. The original invoice is not restated or reissued.

Reconcile credits at the Company level across periods, not within a single invoice.

9.2 Re-redemption

A reversed voucher returns to Available and can be redeemed again — for example when a procedure is rescheduled rather than cancelled.

The second redemption produces a new claim identifier. It is not a correction or replacement of the earlier claim; it is a new claim for the same voucher. If your system keys on claim identifier, expect to see more than one over a voucher's life. If it keys on voucher number alone, expect repeats.

9.3 Reversal clears the service date

When a redemption is reversed, the reported date of service is cleared along with it, because the service is no longer asserted to have happened. A voucher that was redeemed, reversed, and is awaiting rescheduling will show an empty date of service.

9.4 Split payments and patient-paid amounts

Where a Company permits it, a single voucher can be funded partly by the patient at checkout and partly by the Company.

Only the Company portion is billed. The patient's portion is money we have already collected at checkout; it is not billed to you and does not appear in the amount due.

Patient-paid means paid by the patient at checkout by card, PayPal, ACH or CareCredit, and nothing else. The same definition applies everywhere this document reports a patient-paid amount.

Two options, per Company

Two options change what the invoice and the claim say about the patient's share. Both are configured per Company (§4.3), are off unless you ask for them, and are available only to a Company that permits split payments. Neither changes what the Company owes.

• Total price on claims. The claim charge becomes the full price of the encounter rather than the Company portion, and the patient-paid amount is sent alongside it in a 2300-loop AMT*F5 segment. You compute the Company portion as the charge less that amount (§10.3).
• Fully patient-paid encounters. An encounter the patient paid in full is placed on the Company's invoice as a $0.00 line, and in claims mode is sent as a claim whose charge and patient-paid amount are both the full price, so the Company owes nothing on it. In claims mode this option requires total price on claims as well.

Either option takes effect from the date it is enabled: claims and invoices already sent before then are not restated.

Where to find the patient-paid amount

If you need member out-of-pocket for accumulators, cost-of-care reporting, or member statements and your Company does not have total price on claims enabled, take it from the voucher history spreadsheet. It cannot be derived from the 837.

Encounters paid entirely by the patient

Where a patient funds a voucher in full, nothing is owed by the Company.

• Without the fully patient-paid option, no invoice line and no claim are generated for the encounter. It appears in the voucher history spreadsheet like any other voucher, with the whole amount under Patient payment, but it will not show up on your invoices or in your claims feed — which is then a record only of encounters the Company is billed for.
• With it, the encounter is a $0.00 line on the invoice (§7.5) and, in claims mode, a claim carrying the full price as both the charge and the patient-paid amount. Use these claims to post the member's out-of-pocket spend against deductibles and accumulators. Expect a claims feed that grows by these encounters from the date the option is enabled, with no change to the amounts billed.

Reversing a fully patient-paid encounter

When such a voucher is unredeemed, the reversal appears as a $0.00 line in the unredeemed section of a later invoice, or of the same one. No claim is sent for the reversal. If the encounter's claim has already reached you, contact us: the correction to the member's accumulators is agreed with you directly rather than sent as a claim.

9.5 Refunds and cancellations

A cancelled voucher is refunded to whoever funded it. Where the Company funded it and had already
been billed, the refund reaches the Company as a credit, following §9.1.

10. Outbound 837 — what to expect and what not to

Claims mode only. This section covers the ways our claims differ from claims you receive from a conventional provider, all of which follow from prospective bundled pricing.

10.1 The billing provider is always Tendo

The billing provider (NM1*85) is Tendo/MDsave on every claim we send — the same NPI (1073129623) and tax ID (45-4596653), file after file. It never varies and it never identifies the facility.

The organization that delivered care appears only as the rendering provider (NM1*82). Any provider-level logic — network status, contract selection, provider reporting — must key on the rendering provider.

10.2 Claim identifier

The claim identifier (CLM01) is minted by us and is unique per claim. It encodes the underlying order and the redemption event that produced the claim.

Two consequences, both covered above: a voucher with multiple redemptions produces multiple claim identifiers (§8), and a re-redeemed voucher produces a new claim identifier (§9.2).

§11.1 depends on this value being returned to us unchanged.

10.3 Charges are the agreed price, not billed charges

The claim charge (CLM02) is set by the prospectively agreed price. It is not a chargemaster figure and there is no expectation of a contractual adjustment against it. What it covers depends on whether your Company has total price on claims enabled (§9.4):

A claim adjudicated down from the amount owed is being adjudicated below the agreed price.

By default the charge is not the full cost of the encounter. Where the patient paid part of the price at checkout, the claim carries only the Company's portion and the patient-paid amount appears nowhere on it — see §9.4 for where to find it.

With total price on claims, AMT*F5 is omitted when the patient paid nothing. Read its absence as a patient-paid amount of zero: the Company owes the full claim charge, and the claim is the same as it would be without the option. It is never sent as zero.

A claim we re-send keeps its claim identifier (CLM01). It is a resubmission of the same claim that supersedes the earlier one, not a new claim, and should not be paid twice. Unlike a re-redemption (§9.2), it does not mint a new identifier. Its amounts are rebuilt with the Company's current setting, so a claim first sent before total price on claims was enabled and re-sent after it can arrive with the full price as the charge and an AMT*F5 segment. The amount the Company owes — the charge less AMT*F5 — is the same on both submissions.

10.4 Line-level charges are not itemized

Where a claim carries several service lines, the first line carries the entire claim amount and the remaining lines carry zero. The lines identify what the bundle covered; they do not apportion its price, because the price was never built up from line-level components.

Adjudicate at claim level. Line-level pricing logic will produce nonsense against these files.

10.5 Modifiers are not sent

Procedure modifiers are not transmitted. A service line carries the procedure code alone.

10.6 Fixed values

Certain elements carry constants rather than per-patient values and should not be interpreted:

A missing procedure or diagnosis code is substituted with a placeholder rather than left blank — CPT 97999 or ICD R69, both valid codes meaning "unspecified." Treat either as absent coding, not as a clinical finding.

10.7 Bundling

A bundle may be represented as more than one claim — see §8 for the multi-party case. Claims belonging to a bundle aggregate to the pre-negotiated total for that bundle.

10.8 Batching and cadence

Claims are submitted daily, triggered by the provider reporting the encounter rather than on a fixed calendar.

One file contains claims from exactly one billing provider — which, per §10.1, is always Tendo. A file therefore carries many claims across many patients and many rendering providers.

11. Inbound 835 — the contract

This is what we need from you. It is short, and the first item carries nearly all the risk.

11.1 The claim identifier must come back unchanged

CLP01 in your 835 must echo the CLM01 from our 837 byte-for-byte.

Matching is exact string equality. There is no fuzzy matching, no fallback to your own claim control number, no matching on amount, patient, or date.

If the value is padded, truncated, upper- or lower-cased, stripped of punctuation, or re-derived,
the payment will not match. It does not error and it does not reject — it lands in an unmatched
queue and waits for a person. The money may well have arrived; it simply will not be applied.

Your own claim control number is captured and retained, but it is not used for matching.

11.2 What we consume

11.3 What we do not consume

PLB — provider-level adjustments — is not processed.

A PLB segment will pass structural validation and will be silently ignored. Takebacks, forwarding balances, interest, and similar provider-level entries expressed this way will not appear anywhere in our reconciliation, and the remittance will appear to be out of balance against the claims it covers.

Express adjustments at claim or service-line level (CLP / CAS) so they attach to the claim they concern.

11.4 How we interpret the outcome

Claim outcome is derived by comparing the payment amount (CLP04) against the amount the Company owes, numerically. The amount owed is the total charge (CLP03) less the patient-paid amount on our claim (AMT*F5, §10.3), or the total charge when our claim carried none:

The comparison is numeric, so 100 and 100.00 are equivalent.

The patient-paid amount is taken from our claim, not from your 835, so CLP03 must carry the full charge we sent. With total price on claims (§9.4), a remittance that reports any other figure in CLP03 marks a correctly paid claim adjusted. A claim for an encounter the patient paid in full owes nothing, so a CLP04 of zero records it as paid in full.

Note the last row: absent amounts are never read as payment in full. A remittance that omits these amounts will mark the claim adjusted and hold it for review.

11.5 Matching the money

The claim-level match (§11.1) tells us which claims a remittance covers. It does not tell us the funds arrived.

The ACH trace number ties the remittance to the deposit. Send it, and send the same value your banking channel will present on the funds transfer. A remittance whose trace number is absent or does not correspond to a deposit remains pending confirmation — claims show as remitted but the payment is not confirmed, and the balance stays open.

Where funds for one remittance arrive as multiple deposits, or one deposit covers multiple remittances, tell us during onboarding; it is workable but not the default assumption.

11.6 Envelope

We expect a standard X12 005010 835. Files whose version we cannot map are not processed and are routed to an error path for investigation rather than partially ingested.

12. Reconciliation runbook

12.1 Invoice mode

1. Receive the invoice PDF; take the total amount due, not a section subtotal (§7.2).
2. Pull the invoice detail spreadsheet for line-level review.
3. For any line in question, check Encounter CPT Codes — not Procedure CPT Codes (§6.2).
4. For a voucher appearing more than once, confirm whether it is a multi-party redemption (§8) or a same-period reversal (§7.4). The former sums to the voucher price; the latter nets to zero.
5. Pay the total. Use the outstanding items spreadsheet (§5.3) to confirm what remains open across periods.

12.2 Claims mode

1. Receive 837s daily through the clearinghouse.
2. Adjudicate at claim level (§10.4) against the agreed price (§10.3): the claim charge, or — with total price on claims enabled — the claim charge less the AMT*F5 amount, treating an absent AMT*F5 as zero.
3. Return an 835 echoing CLP01 exactly (§11.1), with adjustments at claim or line level (§11.3).
4. Include the ACH trace number matching the funds transfer (§11.5).

The invoice PDF and spreadsheets for the batch are available throughout and carry the same patient, provider and coding detail in a more readable form (§2.2). Use them if they help — for a finance-side review, or to hand the employer group a summary — but pay against the claims.

12.3 "We paid this — why is it still open?"

In order of likelihood:

1. CLP01 did not match (§11.1). The most common cause by a wide margin. Compare the value you sent against the CLM01 on our claim, character for character.
2. Trace number missing or mismatched (§11.5). Claims matched, funds not confirmed.
3. Adjustment sent as PLB (§11.3). Ignored; balance remains.
4. Multi-party redemption paid as one claim (§8). The other portions are still open.
5. A reversal you have not yet seen (§9.1), which will credit on a later invoice.

12.4 What to send us

When something does not reconcile, send: the voucher number, our claim identifier if you have it,
your claim control number, the trace number, the remittance date, and the amount. Voucher number and
claim identifier are the two that let us find it immediately.

Appendix A — Worked example

One voucher, end to end, single redemption.

1. Purchase. A navigator purchases a voucher for a patient at an agreed price. Member ID and group number are supplied and captured. The voucher is prepaid.
2. Care delivered. The provider performs the procedure and reports the encounter, including the procedure and diagnosis codes actually applicable.
3. Redemption. The voucher is marked used, with a date of service and reported coding.
4. Billing.

• Invoice mode: the redemption appears on the Company's next invoice as one line under the provider organization's grouping, at the voucher price.
• Claims mode: a claim is transmitted with Tendo as billing provider, the treating provider as rendering provider, the voucher price as the claim charge, and the supplied member and group identifiers.

5. Remittance.

• Invoice mode: the Company pays the invoice total.
• Claims mode: the TPA adjudicates at claim level and returns an 835 echoing the claim identifier, with the ACH trace number.

6. Confirmation. The trace number is matched against the deposit, the payment is confirmed, and the balance closes.

Appendix B — Sample claims

We can provide example claim files on request. Check with your account representative.