A patient books a cardiologist. Booking screen: "Co-pay: 160." Payment screen after the teleconsult: "Amount due: 320." The plan changed its specialist co-pay tier two weeks ago. Cached data at booking, live data at payment. Same appointment, two amounts, one support call, one lost patient.

Insurance is the most financially sensitive flow in health apps. A wrong co-pay creates billing disputes, rejected claims, and support tickets that cost more than the consultation itself. This guide covers the 6 stages of insurance flow, what breaks at each, and how Drizz validates that what a patient sees at booking matches what they're charged at payment.

For the complete health app flow map, see The Complete Guide to Consumer Health App Flows. For prescription validation, see How Drizz Validates Prescription Screens.

Key Takeaways

• Insurance flows have 6 stages (eligibility, pre-authorization, co-pay calculation, cashless processing, claim submission, claim tracking), each owned by a different system, each a potential failure point.
• The most expensive bug is co-pay inconsistency between booking and payment. The patient sees one amount when they book, another when they pay. This single bug generates more support tickets than any other insurance issue.
• Co-pay is calculated from 4+ dynamic inputs: patient's plan, doctor's network status, consultation type, and deductible status. Asserting a specific amount in a test is instantly fragile because any input can change.
• Insurance flow testing requires cross-screen validation: the co-pay at booking must match the co-pay at payment, the coverage shown on the doctor card must match the coverage applied at checkout.‍
• Drizz validates insurance flows visually across screens: reads the co-pay at booking, reads the co-pay at payment, and confirms they match, without depending on element IDs that change with every UI update.

The 6 Stages of Insurance Flow (And What Breaks at Each)

Stage 1: Eligibility Verification

Before a patient can book, the app must verify: is this patient covered under their insurance plan for this type of consultation with this doctor?

What happens: The app sends the patient's insurance ID and the doctor/consultation details to the insurer's API. The response says: covered (proceed with co-pay), not covered (show full price), or requires pre-authorization (block booking until approved).

What breaks:

• Stale eligibility cache. The app caches eligibility results to avoid calling the insurer's API on every screen load. The patient's plan was terminated yesterday. The cache still says "covered." The patient books, consults, and the claim is rejected days later.
• Wrong plan matched. A patient with two plans (employer plan + personal plan) gets eligibility checked against the wrong one. The co-pay shown is for the employer plan (160) but the claim is filed against the personal plan (320).
• Timeout handling. The insurer's API takes 8 seconds to respond. The app times out at 5 seconds and shows "unable to verify" but still allows booking with a "pay full price" fallback. The patient pays full price for a covered consultation and has to file a reimbursement manually.

Stage 2: Pre-Authorization

Certain consultations, procedures, and tests require insurer approval before they happen. A specialist consultation may need pre-auth. A diagnostic scan almost always does.

What happens: The app submits a pre-auth request with clinical justification. The insurer approves, denies, or requests more information. The patient can only proceed after approval.

What breaks:

• Pre-auth not enforced. The app lets the patient book a specialist consultation that requires pre-auth without submitting the request. The consultation happens. The claim is rejected two weeks later because pre-auth was never obtained. The patient is billed the full amount unexpectedly.
• Approval status not reflected. Pre-auth is approved by the insurer but the app still shows "pending" because the status webhook failed. The patient can't book despite being approved.
• Partial approval. The insurer approves the consultation but not the prescribed lab tests. The app shows "approved" without specifying what's covered and what isn't.

Stage 3: Co-Pay Calculation

The co-pay is the amount the patient pays out-of-pocket. It's calculated from multiple inputs that can each change independently.

The calculation: consultation fee (set by doctor) x coverage percentage (set by plan) = insurer's share. Remainder = patient's co-pay. Plus: deductible status (has the patient met their annual deductible?), co-pay caps (some plans cap specialist co-pays at a maximum), family vs individual deductible tracking, and in-network vs out-of-network rates.

What breaks:

• Booking vs payment mismatch. The co-pay shown during booking uses one data snapshot. The co-pay charged during payment uses another. If the plan terms, the doctor's fee, or the deductible status changed between these two moments, the amounts differ. This is the #1 insurance bug patients report.
• Deductible not tracked correctly. The patient has met 80% of their annual deductible. The co-pay should reflect this. But the deductible tracker uses yesterday's data, not today's (the patient had another consultation this morning that pushed them past the deductible). The co-pay is higher than it should be.
• In-network vs out-of-network inconsistency. The doctor card shows an "In-Network" badge (based on the patient's primary plan). The co-pay calculation uses out-of-network rates (based on a secondary plan the system defaulted to). Badge says one thing. Price says another.

Stage 4: Cashless Processing

In cashless transactions, the insurer pays the provider directly. The patient pays only the co-pay. This requires real-time coordination between the app, the insurer, and the provider.

What breaks:

• Cashless denied at payment. The eligibility check said "cashless eligible" at booking. At payment time, the insurer denies cashless processing (daily cashless limit reached, provider not in cashless network for this plan). The patient must pay full price and file for reimbursement. The app didn't warn them this was possible.
• TPA delays. In India, Third Party Administrators (TPAs) process cashless claims between insurers and providers. TPA approval can take 30 minutes to 4 hours. The patient completes a teleconsult but can't download their prescription until the TPA approves the cashless claim. The prescription is held hostage by insurance processing.
• Partial cashless. The insurer covers the consultation cashless but not the prescribed medicines. The pharmacy order requires full payment. The patient expected everything to be covered because the consultation was cashless.

Stage 5: Claim Submission

After the consultation, a claim is submitted to the insurer with: consultation details, diagnosis codes, prescription, invoice, and any supporting documents.

What breaks:

• Missing documents. The claim requires the prescription PDF, but the PDF generation failed (see our prescription validation blog). The claim is submitted without the prescription. The insurer rejects it.
• Wrong diagnosis code. The doctor selects a diagnosis from a dropdown. The code mapped to their selection is wrong (ICD-10 mapping error). The insurer rejects the claim because the diagnosis code doesn't match the consultation type.
• Duplicate claim. The patient retries claim submission after a timeout. Two claims are submitted. The insurer flags it as fraud. The patient's account is frozen pending investigation.

Stage 6: Claim Tracking

The patient tracks their claim: submitted, under review, approved, rejected, settled, payment disbursed.

What breaks:

• Status not updating. The insurer approved the claim 3 days ago. The app still shows "under review" because the status webhook failed or the polling interval is 24 hours.
• Rejection without explanation. The claim is rejected. The app shows "Claim Rejected" without the rejection reason, the rejected amount, or the next steps (appeal, resubmit with additional documents).
• Settlement amount mismatch. The claim was for 800. The insurer settled 640 (80% coverage). The app shows "Claim Settled: 800" without clarifying that 640 went to the provider and 160 was already paid as co-pay. The patient thinks they're getting 800 back.

Why This Varies Globally

Insurance flow complexity differs by market, but the testing challenges are universal:

United States: Copay, coinsurance, and deductible are three separate calculations. A patient may have a $30 copay for primary care, 20% coinsurance for specialists (after meeting a $2,000 deductible), and a separate out-of-pocket maximum. Each variable changes the amount due. HSA/FSA eligibility adds another layer.

European Union: Cross-border care under the European Health Insurance Card (EHIC) means a patient in Germany can consult a doctor in France with coverage. The app must handle cross-border eligibility, currency conversion, and different billing formats per country.

India: ABHA (Ayushman Bharat Health Account) integration for government-covered patients, TPA-mediated cashless processing, corporate health benefits with different coverage for employees vs family members, and co-pay structures that vary by state.

Middle East (GCC): Mandatory health insurance with government-regulated benefit categories. DHA (Dubai Health Authority) and HAAD (Abu Dhabi) have different coverage rules. The app must enforce region-specific benefit limits.

The testing challenge is the same everywhere: dynamic co-pay calculation from multiple inputs, cross-screen consistency between booking and payment, and claim lifecycle tracking across external systems.

Why Traditional Testing Fails at Insurance Flows

Co-Pay Values Are Dynamic

A test asserting co_pay == 160 breaks when: the plan terms change (quarterly), the doctor's fee changes (annually), the patient meets their deductible (any day), or the network status changes (monthly contract renewals). Static value assertions on dynamic calculations produce constant false failures.

Cross-Screen Consistency Requires Visual Comparison

The co-pay displayed on the booking screen must match the payment screen. These are two different screens, often rendered by different components, pulling from different API endpoints. Appium tests each screen independently. If the booking test passes with co-pay 160 and the payment test passes with co-pay 320, both tests are green. The inconsistency is invisible because the tests don't compare across screens.

Insurance UI Changes Frequently

Insurance display is A/B tested aggressively: where to show the co-pay breakdown, whether to display "You save 640" vs "Insurance covers 80%," how to present the "In-Network" badge, whether to show the deductible meter. Each A/B variant changes element positions and IDs.

How Drizz Tests Insurance Flows

Drizz validates insurance flows visually across screens, catching the cross-screen inconsistencies and display bugs that isolated element testing misses.

Cross-Screen Co-Pay Consistency

Search for a doctor
Verify "In-Network" or "Covered" badge is visible on doctor card
Tap doctor profile
Note the co-pay amount displayed on booking screen
Complete the booking
Navigate to payment screen
Verify co-pay amount on payment matches the booking amount
Verify plan name displayed matches patient's profile

Drizz reads the co-pay amount visually on the booking screen, carries that value through the flow, and compares it against the payment screen. If they differ, the test fails with: "Expected co-pay 160 (shown at booking) but payment screen shows 320."

Eligibility Display Validation

Log in with a patient who has active insurance
Search for a covered doctor
Verify insurance badge is visible on doctor card
Verify co-pay amount is displayed (not "Price unavailable")
Search for an out-of-network doctor
Verify full price is displayed without insurance badge
Verify "Out of Network" or "Not Covered" indicator is shown

Drizz validates the visual difference between covered and uncovered doctors. If the insurance badge renders on an out-of-network doctor (display bug), the test catches it.

Claim Status Tracking

After completing a consultation
Navigate to claim status
Verify claim shows "Submitted" with submission date
Wait for status update (or trigger via test API)
Verify status changes to "Under Review" or "Approved"
Verify the claim amount, covered amount, and co-pay are displayed
Verify rejection shows a reason and next steps (if rejected)

Drizz reads the claim status screen visually, confirming that status transitions render with the correct labels, amounts, and action items.

Pre-Authorization Enforcement

Search for a specialist requiring pre-auth
Tap "Book Appointment"
Verify pre-authorization prompt appears before booking completes
Verify booking is blocked until pre-auth status is approved
Simulate pre-auth approval (via test API)
Verify booking proceeds after approval

If the app allows booking without pre-auth when it's required, Drizz catches it because the pre-auth prompt never appeared on screen.

Corporate Health Benefits

Log in with corporate health account
Verify plan shows company name and coverage type
Search for a doctor
Verify co-pay reflects corporate plan rates (not personal plan)
Book appointment
Verify invoice shows company as billing entity
Verify employee vs dependent coverage is correctly applied

‍Conclusion

Insurance flows are where health apps make or lose money. A co-pay calculation that's wrong by 160 creates a support ticket that costs more to resolve than the error itself. A pre-auth requirement that's not enforced creates a claim rejection that the patient discovers weeks later. A cashless denial at payment time creates the worst possible patient experience: surprise full-price billing after a covered consultation.

The most dangerous insurance bug isn't in any single screen. It's in the gap between screens: the co-pay at booking that doesn't match payment, the eligibility badge that doesn't match the calculation, the claim amount that doesn't match the settlement. These cross-screen inconsistencies pass every test that validates screens in isolation.

Drizz catches them because it reads every screen the way the patient reads it, carries the numbers through the flow, and flags the moment they stop matching. One visual test that flows from booking to payment to claim catches what isolated element checks on three separate screens cannot.

Get started with Drizz

Frequently Asked Questions

Why is insurance the hardest flow to test in health apps?

Insurance flows depend on external systems (insurer APIs, TPA platforms) that return dynamic data based on the patient's specific plan, deductible status, and network configuration. The co-pay for the same doctor changes based on which patient is logged in, whether they've met their deductible, and whether the doctor's network contract has been renewed. Static test assertions can't handle this dynamism.

How do you test co-pay calculations without real insurance plans?

Use test patient profiles with known plan configurations in a staging environment. Create profiles for: fully covered patient (0 co-pay), 80% coverage patient (20% co-pay), out-of-network patient (full price), and deductible-not-met patient (higher co-pay). Validate the visual display for each profile rather than asserting specific dollar amounts.

Can Drizz test the actual insurance claim submission?

Drizz validates the visual claim submission flow: the submit button works, the confirmation screen appears, the claim status updates. Verifying that the claim was actually received and processed by the insurer requires API-level validation against the insurer's system.

What's the most common insurance flow bug?

Co-pay inconsistency between booking and payment. The booking screen uses cached plan data while the payment screen uses live data. If the plan terms changed between booking and payment (even by hours), the patient sees two different amounts for the same consultation.

How do you handle different insurance systems across countries?

Test structurally, not system-specifically. "Verify co-pay is displayed, verify plan name matches, verify booking and payment amounts are consistent" works across US copay/coinsurance, Indian TPA cashless, and EU cross-border coverage. The visual patterns are the same even though the underlying insurance systems differ.