# 02 · Verify cover This is where an identified person becomes a claim someone will pay. The answer is not a yes or a no; it is a named cover, plus the items that cover will pay for at this facility today. ## What this step is [01 · Identify](/rail/stops/Identify) told you who is in front of you. This step answers the money question, and it asks two separate questions to do it. Do not run them together. Keeping them separate is what stops a member with nine active covers waiting on nine balance checks before anyone has asked which one they are using. They are also ordered. Coverage, meaning whether this member is paid up and current, is settled first by the systems that handle contributions. Only then is it worth asking what a cover makes available here. Calling both at once, or reading the second before the first has answered, produces a benefit list you cannot trust. The rule that makes it work is that a person is not covered. A person holds covers, and exactly one of them pays for this visit. Two things are worth knowing before the detail starts, because they decide how much of this you have to build yourself. Both are expanded below, under [what you are responsible for](#the-multiple-cover-case) and [when the choice becomes final](#when-the-cover-choice-becomes-final). If you read nothing else on this page, those two sentences are the ones that change how you build. ### The four moves There are four of them, and the split between the first two is the part that matters most. Every scheme this member can use here, with who contributes to it and how long it runs. It is light enough to render a chooser without waiting on{" "} balances. ), }, { do: "Select one, visibly", detail: ( <> An operator chooses. Do not auto-select silently.{" "} This is a financial decision, and nobody can audit a choice they cannot see. ), }, { do: "Walk down to a billable service", detail: "Benefit, then category, then procedure. The procedure is the unit that carries the access point, the payment mechanism and the preauthorisation flag.", }, { do: "Check the balance where there is one", detail: ( <> Many benefits are not balance-tracked, so there is often nothing to check and that is normal. Where a figure does exist,{" "} read it before quoting an amount, because limits can apply to the whole household rather than this member, so one that looks generous may already be partly spent. ), }, ]} /> None of that is a gate. A missing balance does not block care and rarely blocks a claim. It means this benefit is not tracked that way. Read it when it is there, say so plainly when it is not, and carry on. If you only remember one thing: the cover is chosen once, explicitly, and everything priced afterwards hangs off that choice. ### What it looks like at the desk Three ways to look at the step: the screens, the sequence and the branch points. The simple case, and also the common one: one usable cover, selected and carried forward. The banner is the verdict on the member, and the row beneath it is the cover that will pay.} /> The same screen when nothing pays. A red banner is not the end of the encounter. The patient exists and is identified, only the money has failed, and the response carried both the reason and a remedy.} /> With a cover chosen, the step continues downward: benefits, then categories, then the billable unit. Access point is what catches people on this screen. An inpatient-only category selected during an outpatient visit is refused three stops later, and the error there mentions codes rather than access points.} /> Four attributes decide how the rest of the encounter behaves: the code, the access point, whether preauthorisation is required, and how it is paid. The same clinical work can differ on all four between two funds, which is why the fund belongs on the row.} /> Two fields on this screen cause most disputes: whose limit it is, and whether a blank means unlimited or unknown. Render both explicitly rather than defaulting them to zero.} /> >R: Eligibility for this patient at this facility R->>P: Coverage and contribution status P-->>R: schemes[], one entry per scheme per contributor R-->>H: Member, covers, banner status D->>H: Selects one cover H->>R: Benefits for that cover R-->>H: Categories, filtered by access point H->>R: Procedures in the chosen category R-->>H: Codes, access point, preauth flag, payment mechanism H->>R: Balance for the chosen procedure R-->>H: Utilised, available, whose limit it is Note over H,R: Keep the cover selection and the procedure.
Everything after this prices against them. `} /> B["Eligibility check"] B --> C{Any cover active?} C -- No --> D["Red banner + reason + remedy
continue as cash, or retry after payment"] C -- Yes --> E["List every cover:
scheme x contributor"] E --> F["Operator selects one, visibly"] F --> G["Benefit to category to procedure"] G --> H{Access point matches the visit?} H -- No --> I["Wrong category.
Fails at Bill if it proceeds"] H -- Yes --> J{Balance available?} J -- No --> K["Show next available date.
Check whose limit it is first"] J -- Yes --> L{Needs preauthorisation?} L -- Yes --> M["06 · Preauthorize before anything is done"] L -- No --> N["Carry on to 03 · Consent"] `} /> ## A member can hold many covers, and be a dependant on some of them This is the part that surprises people, so it is worth stating plainly before any payload. So the list is a product rather than a set. There is one row per scheme, per contributor, which means a member with three contributors across three schemes has nine rows, all of them valid. Without it, nine rows look like a duplication bug and an operator picks the first one. With it, the screen reads correctly: *SHIF, contributed by her employer* is a different cover from *SHIF, contributed by her father*, with a different policy number and a different balance. `memberType` tells you which case you are in: `PRIMARY` when the member contributes, `BENEFICIARY` when they are covered through someone else. On a beneficiary row, `principalContributor` names the person whose cover it is, their relationship and their employer. Store it with the encounter: every audit conversation about a dependant's claim opens with "under whose cover?". On screen, that looks like this. Five rows for one person, all of them valid. The rows are uncoloured on purpose, because green belongs to the banner, which is the verdict on the member, rather than to the covers underneath it. What distinguishes a row is its payer and its contributor, so say those in words.} /> ### There is no ranking, so do not build one A member with several covers is not a puzzle with a correct answer. Pick any of them and you see the benefits that cover supports. The covers frequently overlap, since the same eye-health benefit can exist on two of them, so there is nothing to sort and no precedence to apply. So the chooser has one job, which is to show what each cover is and who contributes to it, then let a person decide. Group rows by payer if that helps the eye, but do not pre-select across payers and do not imply an order that the rail does not enforce. Which payer each row belongs to, and who contributes to it. A list of five schemes without those two facts cannot be used correctly by anyone, and the operator will pick the first row. Two consequences follow from the same member holding several covers. A dependant can be covered under more than one principal at the same time. A child whose mother holds one public-officer fund and whose father holds another comes back with covers from both households. One of them is used for a given item, and which one decides the tariff, the limits, the required documents and the combination rules, so the choice is not cosmetic. Nor is it irreversible: see [when the choice becomes final](#when-the-cover-choice-becomes-final). Benefits are also filtered by member type. Principal, spouse and child see different things on the same scheme: maternity is hidden from child dependants regardless of gender, and paediatric benefits disappear at 18. The same scheme genuinely offers the mother and the child different sets, so do not cache one member's benefit list and reuse it for a relative. What should happen when a member holds two covers with different validity windows, or one has expired, is not yet defined. Until it is, show both covers with their dates and let a person decide, rather than encoding a rule that may turn out to be wrong. A member may legitimately hold a public-officer cover that you cannot use. Empanelment is per facility, so if the site you are calling from is not empanelled for that fund, the cover comes back inactive with a reason, and its benefits are absent from the benefit list entirely. That is the correct answer rather than a fault, and it is why an empty benefit list is worth reading carefully. The member is covered, but this facility is not a place where that cover pays. Surface the reason on the row and let the operator select a different cover, rather than showing an unexplained empty list. ## The household behind the covers A cover usually belongs to a household rather than to a person. That is where the extra covers on the previous screen come from: a member appears on their own cover as principal, and on a relative's cover as a dependant. One person, one day, two entries. A minor. Under 18s are{" "} verified differently ), }, ], [ { label: "Faith W***", kind: "text", swatch: 1, span: 1 }, { label: "CR54***780-1", kind: "text", swatch: 1, span: 1 }, { label: "9 Sep 2015", kind: "text", swatch: 1, span: 1 }, { label: "CHILD", kind: "text", swatch: 1, span: 1 }, ], [ { label: "Household limits are shared", kind: "field", tone: "attention", span: 4, note: "Where a limit applies to the household, all five draw on the same pool, and one admission can exhaust what another needs." }, ], ]} caption={<>Five people, one cover. Two of them contribute to covers of their own, which is exactly why this member's cover list has more rows than they expect.} /> An empty household is also a real answer. Reaching a dependant through a principal is covered at 01 · Identify. What matters here is that their spending may come out of the same limit as everyone else's.} /> ## One cover, or several Everything so far has assumed you pick a cover and move on. That is the common case and it is worth stating separately from the harder one, because the two behave differently and the difference decides who pays. ### The single-cover case One usable cover. Select it, and it becomes the effective coverage for the encounter: a snapshot of that cover taken at the moment of choosing, stored against the authorisation. Everything after it resolves against that snapshot rather than re-reading the member's covers, including the benefits, the balances, the tariffs, the preauthorisation and the claim. Snapshotting matters because coverage is live data. A member's contribution status can change during an admission; the encounter should not silently re-price itself when it does. ### The multiple-cover case A member may hold several usable covers at once: their own, plus one or more where they are a dependant on somebody else's. All of them may be valid, and only one pays for a given item. It helps to picture where you are by this point. The member was identified, a cover was chosen when the visit opened, and care has happened. You are now in the billing workflow, adding items to a bill or a preauthorisation, and the operator can be offered the same choice again, because the cover on those items is still theirs to set. The green card is the cover in force, and every item inherits it. Badge it explicitly: an operator who cannot tell which of two covers is active will not trust either.} /> Now the operator changes their mind, perhaps because this benefit has more left on the father's cover, or because the mother's limit is nearly spent. They pick the other card. The same bill, a different payer behind it. One call moved the effective cover, the items re-priced, and every line now names the contributor it will be assessed against.} /> One call makes that switch. You send the cover the operator chose against the encounter, and the rail updates the effective coverage, which is what every later balance, tariff and assessment reads from. See [the effective-coverage call](/rail-api/02-verify-cover) in the reference. List the covers, let the person at the desk choose one, and send that choice back. That is the whole of your responsibility for cover coordination. Everything underneath it is the rail's problem: which fund pays, which tariff applies to that fund, whose balance is read, how a dependant's cover relates to a contributor's, what a household limit has already consumed, and how the claim is assessed against the cover it carries. You do not reconcile payers, rank schemes or compute what is left. You surface a choice and you report it. ### What gets stored, and why it is scoped to a contributor The chosen cover is persisted as a snapshot alongside the authorisation, and it carries the contributor as well as the scheme. The cover this encounter is currently billing against, with the contributor behind it and any secondary coverages. You can change it until the request is submitted. Both effective-coverage calls — reading it and setting it — answer 404 on the development gateway today. What the snapshot means has not changed, and `covers/select` is what freezes the choice; treat the pair below as the shape to expect rather than a call to wire in now. `principal_cr_no` is the field that does the work here, for three reasons. One encounter holds more than one cover through `primary_coverage` and `secondary_coverages`. The cover frozen at visit start is the primary, and a cover chosen for a particular item links to it as a secondary. The structure exists so that "who paid for what" is answerable per item rather than per visit. Do not model the cover as a single value on the visit. Model it as a default on the visit and an override per item, then show the fund on each line. A provider who bills two contributors in one encounter and cannot see which line went where will not be able to answer a query about either. ### The two views, side by side >R: Valid covers for this member here R-->>H: Covers, public and private, each with its contributor D->>H: Selects one at visit start H->>R: Freeze it as effective coverage (primary) R-->>H: Snapshot stored on the authorisation Note over H,R: Benefits, balances and tariffs now resolve
against the snapshot, not live coverage. C->>H: Bills an item H->>R: Balance for this procedure, for this contributor R-->>H: What that contributor has left C->>H: Chooses a different cover for this item H->>R: Link it as a secondary coverage R-->>H: Item carries its own scheme and fund `} /> B{How many are usable?} B -- One --> C["Select it, and it becomes the primary
effective coverage"] B -- "More than one" --> D["Group by payer, rank funds inside
each, operator chooses"] D --> C C --> E["Benefits, balances and tariffs resolve
against the snapshot"] E --> F{Does this item belong to
a different contributor's cover?} F -- No --> G["Bill against the primary"] F -- Yes --> H["Select that cover for the item
linked as a secondary coverage"] H --> I["Balance and reserved amounts read
for THAT contributor"] G --> J["Item carries its scheme and fund"] I --> J `} /> ## When the cover choice becomes final The most useful thing to know about cover selection is that it sets a default rather than a commitment. Right up until you submit, it can be changed. Providers assume the first screen commits them, so they either stall the encounter while somebody works out the "right" cover, or they proceed and treat a wrong choice as an unrecoverable error. Neither is necessary. Open the visit on any valid cover, treat care as the priority, and settle the cover question before the request goes out. Two things follow for the software. Make the cover visible and editable on the request, not only on the visit. If the only place a cover can be chosen is the screen that opens the encounter, every correction becomes a cancellation. Put it on the preauthorisation and the claim, with the fund shown per item. Re-price on change, and say so. Because a procedure carries a tariff per fund, switching cover can change the amount. Recompute rather than carrying the old figure forward, and show the operator that the number moved, since a silently changed amount is worse than a visibly changed one. cover set as default"] --> B["Items billed
per-item override allowed"] B --> C["Preauth / claim drafted
still changeable"] C --> D{Submitted?} D -- "Not yet" --> C D -- Yes --> E["Fixed, and assessed against
the cover on the request"] `} /> ## Once a cover is chosen Everything above answers *which cover pays*. The second half of the question, what that cover pays for, is a tree you walk, and it is long enough to have its own page. Benefits, categories and procedures, one level at a time. How the tree is shaped, why the same rule lives at different depths for different payers, what a procedure declares, and where balances come from, with the screens, the sequence and the calls to go with them. ## The call Two calls answer the cover question, and they run in order: coverage first, then what that cover makes available here. The calls that walk the benefit tree are on [the next page](/rail/guides/Benefit-Tree). Open [**02 · Verify cover in the Rail API reference**](/rail-api/02-verify-cover) to read or run them, with a **Try it** console for when the sandbox is live. The field names quoted below come from one payer's current responses, included so they are recognisable when you meet them. Other payers use their own names for the same things, and the rail is normalising them, so treat the names as illustrative and the shapes as real. Exact names come from the reference once the contracts are signed off. ### What an eligibility response carries Every payer answers this call with the same three things, whatever they call them: who the member is, which cover the answer was resolved against, and a set of flags that later stops depend on. The reference has it field by field. What follows is what to do with the flags, because those are the ones that catch people out. Member, contacts, cover and the flags later stops depend on, including the biometric and one-time-code flags that decide what Consent can offer. The `/api/v1/beneficiaries/…` calls on this page — eligibility, coverage, and the retired `covers/valid` — answer 404. The prefix is registered nowhere in the service, so nothing behind the gateway serves them. What is live is [`GET /api/v2/patients/{unique_patient_id}/covers`](/rail-api/02-verify-cover), which returns the covers, their schemes, `status` and `selectable`, and a `next_action`. It does not carry the biometric and one-time-code flags described below, and nothing else does either. That is by design rather than by omission: in v2 the factors on offer are decided server-side per consent request and surfaced by the launch, not fetched by the integrator. Read what follows as the shape of a payer's eligibility answer, and let [03 · Consent](/rail/stops/Consent) decide the factor. Some fields here are not about cover at all, and they matter later. `isBiometricsEnabled`, `isFingerprintEnrolled`, `otpOnlyAllowed` and `biometricStatus` decide which consent factors are even offered at [03 · Consent](/rail/stops/Consent). A member who is not enrolled for fingerprints cannot consent by fingerprint, and finding that out at Consent looks like a broken scanner. `benefits: []` is worth reading too. An empty array here does not mean "no benefits". It means this response did not carry them, and you fetch them per cover in the calls below. ### Coverage: one answer per scheme, per contributor This is the response that produces several rows for one person, and it behaves the same way whoever the payer is. A national fund returns one entry per scheme per contributor; a private insurer returns one per policy, and a member holding both gets both sets. Nothing deduplicates them for you, and nothing ranks them. Every scheme the member is covered under, one entry per contributor. This is the response that legitimately returns five rows for one person. Four things to read correctly, on any payer's version of it: ## Public-officer and teachers' covers are a different rule set They look like another scheme in the list. They are closer to a parallel rule set, and four differences matter enough that treating them as a variation produces claims that cannot be paid.