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.
Everything below elaborates this sentence.
What this step is
01 · 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.
| Call | What it does | What you keep |
|---|---|---|
Which cover pays? | A member holds covers, plural. Someone has to say which one today's visit runs against, and that choice has to be visible rather than guessed. | the selected cover |
What does it pay for? | Benefits, then categories, then procedures, each with an access point, a payment mechanism, whether it needs preauthorisation, and a balance. | procedure code |
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.
| Call | What it does | What you keep |
|---|---|---|
Your part is small | List the covers, let a person choose one, send the choice back. Which fund pays, which tariff applies, whose balance is read and how the claim is assessed are all the rail's problem. | one call |
Nothing here is final | The cover chosen at visit start is a default. It can be changed per item and changed again until the request is submitted. | room to correct |
Both are expanded below, under what you are responsible for and when the 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.
- 01List the coversEvery 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.
- 02Select one, visiblyAn operator chooses. Do not auto-select silently. This is a financial decision, and nobody can audit a choice they cannot see.
- 03Walk down to a billable serviceBenefit, then category, then procedure. The procedure is the unit that carries the access point, the payment mechanism and the preauthorisation flag.
- 04Check the balance where there is oneMany 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.
One usable cover here. The multiple-cover screen comes further down, where it is explained.
coverage.statuspayer, scheme, categoryvalidityThe same screen when nothing pays.
coverage.statuscoverage.reasoncoverage.messageWith a cover chosen, the step continues downward: benefits, then categories, then the billable unit.
access_pointsub_benefit_codeaccess_pointsub_benefit_codeaccess_pointsub_benefit_codeaccess_pointcodeaccess_pointneeds_preauthpayment_mechanismcodeaccess_pointneeds_preauthpayment_mechanismavailablenext_available_onlimit_scopeutilisationallocatedA 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.
| Call | What it does | What you keep |
|---|---|---|
One payer, several schemes | A single payer can grant more than one scheme at once, such as UHC and SHIF, with different windows and different rules. | one row each |
Several payers | A member may hold covers from more than one payer: a national scheme, an employer scheme, a private insurer. | one row each |
Principal or dependant, per cover | On some covers the member is the contributor. On others they are somebody's dependant, and both can be true of the same person on the same day. | memberType |
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.
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.
coverage.statusschemes[].schemeNamecoverage.endDateschemes[].schemeNamecoverage.endDatememberType: BENEFICIARYcoverage.endDateschemes[].schemeNamecoverage.endDatepayer, scheme, categoryvalidityThere 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.
| Call | What it does | What you keep |
|---|---|---|
What choosing a cover does | Scopes the benefit tree to what that cover supports. A different cover means a different tree, not a better or worse one. | the tree you get |
What it does not do | It does not rank, exclude or consume anything. Selecting a cover is not spending it. | — |
Overlap is normal | Two covers can both carry the same benefit, with different limits and tariffs. Neither is the right one in the abstract. | compare when it matters |
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.
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.
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.
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.
relationshipprincipalAn empty household is also a real answer.
principalOne 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.
| Call | What it does | What you keep |
|---|---|---|
Chosen at visit start | The cover selected when the encounter opens becomes the PRIMARY cover. It is the default for everything billed under this visit. | effective coverage |
Changeable at billing | When an item is billed, the operator can bill it against a different valid cover, typically one where the patient is a dependant and the benefit sits with that contributor. | the cover on that item |
Recorded per item | Each billed item and preauthorisation carries the scheme it was raised under, so one encounter can legitimately draw on two contributors. | scheme_code, scheme_name |
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.
principal_cr_no + badgeprincipal_cr_noprocedureamountscheme + contributorprocedureamountscheme + contributorprocedureamountscheme + contributorNow 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.
principal_cr_noprincipal_cr_no + badgeprocedureamountscheme + contributorprocedureamountscheme + contributorprocedureamountscheme + contributorOne 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 in the reference.
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.
scheme_code + principal_cr_noprincipal_cr_no is the field that does the work here, for three reasons.
| Call | What it does | What you keep |
|---|---|---|
Balances are read per contributor | A member's balance data holds one entry per policy, keyed by the contributor behind it. The chosen contributor selects which entry is read. | principal_cr_no |
Reserved amounts are scoped the same way | Approved preauthorisation amounts are subtracted per contributor, so a sibling's reservation under the same encounter does not eat this contributor's limit. | principal_cr_no |
Getting it wrong is silent | Without the contributor, the first policy would be read, quietly returning a different person's balance. That is why an unmatched contributor is an error rather than a fallback when several policies exist. | — |
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.
The two views, side by side
The cover is chosen twice: once as the visit default, and again wherever an item needs a different one.
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.
- 01At visit start, a default is setThe cover chosen when the encounter opens becomes the primary. Everything billed under the visit inherits it unless told otherwise.
- 02At billing, changeable per itemAn item can be raised against a different valid cover, typically one where the patient is a dependant of another contributor. The item carries the fund it was raised under.
- 03Before submission, still changeableA preauthorisation or a claim that has not been submitted can have its cover changed. Amounts re-resolve against the new fund, because tariffs and limits belong to the cover rather than to the procedure.
- 04On submission, fixedOnce submitted, the cover on that preauthorisation or claim is what it will be assessed against. Changing it afterwards means a new request, not an edit.
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.
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.
Continues onWhat a cover pays forBenefits, 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.
| Call | What it does | What you keep |
|---|---|---|
GET · eligibility | Member, cover and the flags later stops depend on. Answers whether this member is current before anything else is asked. | member identifier |
GET · coverage | Every scheme the member is covered under, one entry per contributor. This is the response that returns several rows for one person. | schemes[], policy numbers |
Open 02 · Verify cover in the Rail API reference to read or run them, with a Try it console for when the sandbox is live.
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.
member identifierSome 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. 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.
schemes[].policy.numberFour things to read correctly, on any payer's version of it:
| Call | What it does | What you keep |
|---|---|---|
The list is not deduplicated | Two entries naming the same scheme are two different covers when the contributor differs. Group by contributor when you render, and use the policy number as the row identity. | policy number |
Status is a code, not a word | Payers signal covered with a code and a human-readable message beside it. Switch on the code; show the message. Never pattern-match the text. | status |
Two date ranges, not one | The policy window and the coverage window are different things and can differ. Coverage is the one that decides whether today is paid for. | the coverage window |
An empty relationship is meaningful | Where the member is the contributor, the relationship field is legitimately blank. Render it as "self", not as missing data. | member type |
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.
| Call | What it does | What you keep |
|---|---|---|
Benefits downgrade, they do not vanish | Where a facility has no active contract of that type, public-officer benefits are hidden and the universal or standard equivalent is shown instead. An empty list is the wrong reading; a substituted list is the right one. | which set you are looking at |
Teachers' members are panel-restricted | Outside their panel, they see only their standard benefits. The same member gets different answers at two facilities, correctly. | — |
Tariffs come from a different matrix | Public-officer tariffs are different figures, published separately. If the member is a public-officer member, the standard tariffs do not apply, and reading the standard matrix misprices every one of those claims. | the public-officer tariff |
Combination rules differ | The same procedure codes, different rules about what may be billed together. | — |
What you keep
| Call | What it does | What you keep |
|---|---|---|
The selected cover | Which scheme and which contributor. Tariff, limits, documents and combination rules all follow from it. | policy number + memberType |
The principal contributor | On a beneficiary row, whose cover is being used. The first question any audit asks. | crNumber, relationship |
The procedure code | The unit everything later prices against, with its access point and payment mechanism. | code, access_point |
The effective coverage | The snapshot of the chosen cover, including the contributor behind it. Everything prices against this rather than against live coverage. | scheme_code + principal_cr_no |
The selection reference | The handle the benefit tree is read against, returned by covers/select. Short-lived and visit-scoped by design: re-run rather than caching it across days. There is no separate eligibility reference in v2. | selection_ref |
Consent hints | Biometric enrolment and OTP flags, read here and needed at the next stop. | isFingerprintEnrolled, otpOnlyAllowed |
What breaks here
| Where it surfaces | What the desk sees | What actually went wrong |
|---|---|---|
| Cover selection | "There are nine identical covers, which one do I pick?" | The contributor is not rendered. Each row is a scheme-and-contributor pair; without the contributor they look like duplicates and the operator picks the first. |
| Cover selection | "We picked a cover and the claim was rejected as not the member's" | A BENEFICIARY row was treated as the member's own. The claim has to carry the principal contributor for that cover, not the patient. |
| Cover selection | "The system says not covered, so we sent them away" | coverage.reason and message were dropped instead of shown. Identity resolved; only the money failed, and the remedy was in the response. |
| Bill | "The line was refused and the code looks correct" | Access point mismatch. An inpatient-only procedure was selected during an outpatient visit, and nothing failed at selection time. |
| Bill | "It said covered, but the amount came back zero" | A null allocated amount rendered as zero, or a household limit already spent by a relative. Read limit_applies_to before quoting a figure. |
| Preauth | "Nobody told us this needed approving" | needs_preauth was on the procedure and was not read. The flag is available at selection, hours before the patient is on a table. |
| Consent | "The fingerprint reader is not working" | The member is not enrolled for fingerprints. isFingerprintEnrolled said so at this stop. |
| Balance screen | "The balance shown belongs to the wrong parent" | The contributor was not sent with the balance request. Where a member has policies under several contributors, the first one is not a safe default, because it is a different person's limit. |
| Claim query | "We cannot say which cover paid for which item" | The cover was modelled as one value on the visit. It is a default on the visit and an override per item, and each item carries the scheme it was raised under. |
| Bill | "The price changed when we switched cover" | Correct. A procedure holds a tariff per fund, so the amount is a function of procedure, facility level and the cover being billed. |
| Balance screen | "It shows zero left on emergency care" | That benefit is not balance-tracked. There is no pool, so there is no figure, and rendering it as 0.00 tells a clinician the opposite of the truth. |
| Balance screen | "The limit says 2 and the amount is blank" | A count-based limit. Most limits here are numbers of visits or sessions rather than money, and a screen that only formats currency shows nothing useful. |
| Cover selection | "We used the mother's cover and it was refused for the child" | Benefits are filtered by member type, and a dependant may be covered under two principals. Whichever cover the request carries at submission is the one it is assessed against, so correct it before submitting rather than after. |
| Preauth or Bill | "The document list on the procedure looked short" | Requirements inherit from the benefit above it. Reading the leaf without resolving the chain misses everything set higher up. |
| Next day | "The eligibility reference stopped working" | It is visit-scoped and short-lived. Re-run eligibility rather than persisting the reference. |
One pattern runs through most of that list. The response said so and the screen did not. The contributor, the access point, the limit scope, the preauth flag and the biometric flags are all present at this stop, and every one of them, dropped here, becomes somebody else's problem later.
Errors
| Code | HTTP | What it means | What to do | fix_stage |
|---|---|---|---|---|
OUTSIDE_FACILITY_GEOFENCE | 403 | The call originated outside the configured radius of the facility. Checked before any stop-specific gate. | Read distance_m, allowed_radius_m and facility_code from the detail block. Test environments often use a different radius. | authentication |
COVER_INVALID | 404 | The cover does not resolve, or its status is not active. | Re-list covers and let the operator choose again. | cover |
COVER_EXPIRED | 409 | The cover's policy window does not include today. | Select a different cover, or collect payment another way. | cover |
SCHEME_CODE_REQUIRED | 400 | The cover is live on more than one scheme and no scheme was named in the selection. | Render schemes as covers so the operator makes one selection rather than two. | cover |
ELIGIBILITY_REF_NOT_FOUND | 404 | The eligibility reference is unknown or has expired. | Re-run eligibility. The reference is visit-scoped and short-lived by design. | eligibility |
PAYER_UNREACHABLE | 502 | The payer did not respond within the configured timeout. | Retry — it is safe and idempotent on the selection reference. Do not surface this to the front desk as a patient problem. | eligibility |
What carries forward
| Call | What it does | What you keep |
|---|---|---|
Selected cover + contributor | Taken by Consent, Visit, Preauth, Bill and the claim. The single most consequential choice on this page. | Store on the encounter |
Procedure code | Priced at Bill, approved at Preauth where required. | With its access point |
Consent hints | They feed the factor decision at 03 · Consent. You do not make that decision, but these are among its inputs. | Pass forward, do not re-derive |
Next: 03 · Consent. With a cover chosen, the member has to confirm they are present and willing.
A complete brief for this step — the calls to make, what to persist, and every failure path to handle. Nothing on this page is assumed.