Insurance eligibility verification

How do we verify a patient's insurance eligibility at booking, with the member identifier captured and masked, the coverage checked before the visit, and the result written to the registration record?

Check coverage when the visit is booked, not when the claim denies. Callvu prefills the insurance on file, asks the patient for the member identifier and the card images where they are missing or changed (captured on a secure screen and masked in the record), runs the eligibility check with the payer for active coverage on the date of service, the plan, the network status, the benefits and the patient's share, classifies the result (active, inactive, a different plan, a coordination of benefits question, a referral or authorization required), chases the patient for a corrected card where the check fails, routes an unresolved failure to patient access in the Decision Desk before the visit, and writes the result with its date to the registration record in the EHR. Live at Ministry of Health, under national rules outside the US.

Live at Ministry of HealthSimpleCallvu moves: prefill, chase and verify, write back

Talk to an expert Try it in the sandbox

Last updated November 7, 2026.

The problem today

The visit happened, the claim denied for inactive coverage, and the patient received a bill for a service they thought was covered.

Today, without Callvu

Eligibility is checked at the front desk on the day, if at all, from a card the patient hands over. The payer's response is a screen nobody reads closely; the plan changed in January; the referral the plan requires was never obtained. The claim denies weeks later, the rework begins, and the patient's trust in the bill is gone.

Eligibility verification is a transaction with a standard: the request with the member identifier and the date of service, the response with the coverage status, the plan, the benefits and the patient's share; the member identifier is protected data that should be masked in the record; the result has a date and should be re-run close to the service. A failed check before the visit is a conversation; after it is a denial.

The check at booking is cheap, and the denial is not.

How it runs

From the requestto the system of record.

A visit or service is booked, or the patient reports a new insurance. Callvu opens the verification for the date of service.

Patient: Provides or confirms the member identifier and the card images on a secure screen.
Payer: Returns the eligibility response through the standard transaction or the portal.
Patient access: Resolves unresolved failures in the Decision Desk.
Callvu: Prefills, captures and masks, runs the check, classifies, chases, routes and writes.

Prefill and capture
The insurance on file, the subscriber and the relationship are prefilled; the patient is asked by text or in the portal to confirm or provide the member identifier and the card images (through the card capture process) where they are missing, expired or changed; the identifier is captured on a secure screen and masked in the record and the screens.
Chase and verify with the payer
The eligibility request is sent to the payer for the date of service and the service type; the response is read: active coverage, the plan and the product, the network status of the facility and the provider, the benefits for the service type, the deductible and the patient's share, the primary and secondary coverage, and whether a referral or an authorization is required; a payer that does not respond electronically is checked through its portal with the result recorded the same way.
Classify and decide
The result is classified: active and in network (proceed), inactive or not found (chase the patient for a corrected card or another plan), a different plan than on file (update and re-check), a coordination of benefits question (route to the coordination process), a referral or authorization required (route to those processes); an unresolved failure before the visit goes to patient access in the Decision Desk with the result and only the allowed outcomes (proceed as self-pay with the estimate, reschedule, or obtain the missing item).
Write back
The eligibility result with its date, the plan, the benefits, the patient's share and the required referral or authorization flags are written to the registration record in the EHR and the billing system, the check is re-run on the schedule the policy sets before the date of service, and the patient sees their expected share through the estimate process.

Where it ends: Coverage was verified for the date of service at booking, with the identifier protected, the failures resolved before the visit and the result on the registration record the claim will use. The Decision Trace shows the check, the classification and any decision; the Audit Trace shows the capture, the payer response and the write with time.

Runtime enforcement

What is enforcedwhile the work runs.

The regulations preloaded in Callvu Studio and the bank's own policies, applied as steps that run, not lines in a binder. A step that breaks a rule does not run, so a completed run was compliant.

Regulations

US requirements shown. Ministry of Health runs this process under national rules outside the US; Callvu loads each market's rules as policies the same way.

HIPAA Privacy and Security Rules (45 CFR 164.502 and 164.312) and the HIPAA eligibility transaction standard (45 CFR 162, the X12 270/271): The member identifier and the eligibility response are protected health information handled under the minimum necessary standard with access controls and masking; the eligibility inquiry and response use the adopted standard transaction, which payers must support, with the operating rules setting the response content and timing.
Payer eligibility rules: Each payer sets the coverage effective dates, the network and referral requirements, the service types that require authorization, the benefit accumulators and the coordination of benefits rules; the response is read against them, and a required referral or authorization starts its process before the service.
Price transparency and the patient's share (the No Surprises Act good faith estimate and the hospital price transparency rules): The verified benefits and the patient's share feed the estimate the patient is entitled to before a scheduled service; an uninsured or self-pay patient receives the good faith estimate through its process.

Company policies

Eligibility is checked at booking for the date of service and re-run before the visit on the policy's schedule.
The member identifier is captured on a secure screen and masked in the record.
A failed check is resolved with the patient before the visit, in the Decision Desk where it cannot be resolved by rule.
The EHR registration record and the billing system hold the result with its date.

Controls

Insurance prefill and secure capture with masking.
Standard eligibility transaction with portal fallback.
Result classification with referral and authorization flags.
Patient chase for corrections.
Decision Desk for unresolved failures.
EHR and billing write with scheduled re-check.

Clocks and deadlines

Check at booking: On the booking, for the date of service.
Re-check: On the policy's schedule before the visit (commonly within a few days of the service).
Failure resolution: Before the visit, with the patient chased on the visit-date clock.

Documents and checks

The insurance on file and the capture
The eligibility request and response
The classification and any decision
The registration record and the billing write

In the Decision Trace

The check and the classification.
Any decision and the person.

In the Audit Trace

The capture with time (masked).
The payer response with time.
The write and the re-checks.

The handoff

Between the front doorand the back office.

The front door

A text or portal request from the booking; the patient confirms or provides on a secure screen.

The back office

Patient access sees only unresolved failures before the visit; the claim uses the verified result.

The Decision Desk

An unresolved failure before the visit goes to patient access in the Decision Desk with the result and only proceed as self-pay with the estimate, reschedule, or obtain the missing item.

Proof

Live at Ministry of Health.Published results only.

Each result is a published claim, with its code on agents.callvu.com, where its status, source and last verified date are kept.

At the Ministry of Health, patient intake checks that the person is insured, and patient profiles are created and updated in real time.

HLT-04 · Self-asserted · verified 2026-11-05

The Ministry of Health hospital network runs 23 hospitals on Callvu and keeps adding more, with 3x faster procedure approvals, 78% faster patient consent and more than 1M pages of paper eliminated.

HLT-01 · Self-asserted · verified 2026-11-05

PHI masking is tested and live.

ENF-08 · Self-asserted · verified 2026-11-02

Questions

What buyers ask next,answered plainly.

When is coverage checked?

At booking for the date of service, and again before the visit on the policy's schedule, through the standard eligibility transaction or the payer's portal.

What is done with the member identifier?

Captured on a secure screen, used for the check, and masked in the record and on the screens as protected health information.

What if the check fails?

The patient is chased for a corrected card or another plan before the visit; an unresolved failure goes to patient access to decide self-pay with an estimate, a reschedule, or the missing item.

Related processes

Insurance card and ID capture New patient intake with insurance check Pre-registration for scheduled services Coordination of benefits updates Try it in the sandbox All healthcare processes

Bring this process, or the one that costs you most.

We build it against your policies and your systems, train your team and stay with you through launch. You are live in weeks.