# Benefit coordination

  A patient rarely holds one cover. Most hold several, and deciding between them is not
  the clinician's job, nor the biller's.

## The situation

A teacher walks into a facility. She holds a public scheme through the national fund, a
second public scheme through her employer, and a private policy through her spouse's
employer. Her child, standing next to her, is a beneficiary on three of those four.

None of this is unusual. It is the ordinary case.

What is rare is a system that handles it well. The usual failure is quieter than a crash.
The software picks the wrong cover on its own, or it asks the front desk to pick while
giving them nothing to pick with, and the consequence lands weeks later as a rejected claim
or an out-of-pocket charge the member should never have paid.

## The shapes this takes

Multiple cover comes in a handful of recurring shapes, and which one you are in decides the
answer:

| Situation | Who goes first |
| --- | --- |
| Employer scheme alongside the national fund | The employer scheme; the national fund sits behind it |
| Two employers, one member | The primary employment; the second employer sits behind it |
| A child on both parents' schemes | The parent whose birthday falls earlier in the calendar year, which is not always the older parent |
| National fund plus a private top-up | Neither, in the ordinary sense. The two are complementary: the national fund carries inpatient, the top-up carries outpatient or dental. There is nothing to sequence |
| Retiree cover plus a spouse's active scheme | The spouse's active scheme; the retiree cover sits behind it |

Two rows deserve a second look. The birthday rule surprises almost everyone who meets it for
the first time, and you cannot derive it from anything on the member record you already hold.
The complementary case is the one where coordination is the wrong question, because those
covers divide by benefit rather than by order, and sequencing logic applied to them returns
a wrong answer with full confidence.

## What failure actually costs

When nobody sees the second cover, the money goes astray on a long and expensive loop:

<BuildSequence
  steps={[
    "The claim reaches the first payer with no mention of the second. It is paid in full.",
    "The same encounter reaches the second payer. It is also paid in full. The provider has now been paid twice for one visit.",
    "Months pass. An audit at the first payer surfaces the duplicate.",
    "A recovery request goes out, often on paper, to a counterpart with no shared record of the event.",
    "The dispute runs six to twelve months on who paid first and who should therefore recover.",
    "Recovery typically fails. Both sides write it off.",
  ]}
/>

Manual recovery of duplicate payments succeeds in well under a fifth of attempts. That is the
number sitting behind the phrase "claims get corrected later": mostly they are not corrected,
and somebody absorbs the loss.

The member pays as well, quietly. One episode of care draws down the balance on both covers,
nobody tells them, and they find out on the next visit when a benefit they should still have
is gone.

The rail changes one thing here. Eligibility drives the claim, instead of the claim going out
blind and being corrected afterwards.

## Why this is hard without a rail

Coordinating benefits means answering five questions, and each one lives in a different
system:

- Which covers are live today? Each has its own validity window and its own anniversary. One resets in October, another in July.
- Which of them are usable here? Empanelment is per facility, sometimes per practitioner, so a cover that is valid nationally can be unusable in this building.
- What does each one actually pay for? Not "outpatient" but the specific intervention, at this facility's tariff, with this facility's panel status.
- What is left on each? Balances are live, and they are often counts rather than money.
- Which should go first? And when the first is exhausted mid-visit, what happens to the rest of the bill?

Answering these directly means integrating with every scheme, holding a model of each
one's rules, and keeping that model current as the rules change underneath you.

## What the rail does

**It surfaces every cover in one shape.** One call after identity returns all of them, public
schemes and private policies together, with payer, member identifier, policy window and
current status normalised into a single list. That is enough to render a chooser without
waiting on a balance check for each cover.

**It filters to what is usable.** A cover that cannot be billed at this facility does not
appear in the list, so an empty result is an answer rather than something you have to go and
investigate.

**It makes the choice explicit and visible.** A person selects the cover, with the information
needed to choose. That selection is then frozen onto the visit, because it determines tariff,
limits, required documents and combination rules for everything that follows.

**It resolves entitlement against the chosen cover.** The shape is the same whichever payer it
is, so your screens do not branch.

## Principles worth building in

<BuildSequence
  steps={[
    "Store covers as a list, never as a field. A member with one cover today has three next month, and a single cover_id column is a migration waiting to happen.",
    "Never auto-select silently. If your system picks a cover without showing the operator why, a financial decision has moved somewhere nobody can audit.",
    "Re-check rather than cache. Eligibility is cheap by design, so re-run it when the desk changes its mind mid-conversation.",
    "Treat exhaustion as a workflow branch rather than an error. A benefit running out mid-visit is expected; what matters is that the operator sees it while the patient is still present.",
    "Keep the selection visible on every billing screen. The commonest coordination bug is a biller who does not know which cover they are billing against.",
  ]}
/>

## What is settled, and what is not

It is better to be straight about the boundary here than to sound complete.

**Settled today:** covers are surfaced together in one normalised list, filtered to what is
usable at this facility; the selection is explicit and is frozen onto the visit; entitlement
and billing resolve against that single selection; the claim is dispatched to the right
payer without you choosing an endpoint.

**Not settled today:** automatic sequencing across covers within a single visit. The shape it
would take is well understood: one encounter generating two claims, the first payer settling
its share, and the second claim carrying the first payer's remittance advice so the shortfall
is computed rather than guessed. What is not settled is that the API does this for you. Today
a visit runs against one selected cover. Where a second cover should pick up a shortfall, that
is currently a separate commercial and workflow decision.

If your product depends on automatic top-up behaviour, raise it now rather than designing
around an assumption. This is an active area, and integrator requirements shape where it
lands.

## Where this shows up on the rail

Coordination is not a stop of its own. Most of it sits at
**[02 · Verify cover](/rail/stops/Entitle)**, where covers are listed, chosen and expanded into
billable items, and the rest of it shows up at **[07 · Bill](/rail/stops/Bill)**, where the
patient's own share is separated from the payer's.

**Next:** [Ride the rail from the start](/rail/stops/Authenticate)