IRDAI claim form A and B without the back-and-forth.

Anyone who has filed a health insurance claim in India has met the two-form ritual. Form A is filled by the insured (or the family member doing the chasing). Form B is filled by the hospital. The two arrive at the insurer or the TPA in different envelopes, on different days, and the claim file does not move until both are present.

This post is about turning that ritual into one short workflow. We will go through what the forms actually require, where the back-and-forth comes from, and what a Mezdoc workflow looks like that ends with both forms signed, attached to the claim id, and webhook-delivered to the TPA.

What the two forms actually contain

Form A, filled by the insured

Form A is short. Name of the insured, policy number, member id, hospital where treatment was taken, date of admission, ailment, an itemised expense summary, bank details for reimbursement, and a signed declaration that the information is true.

Most of this data lives in the insurer's CRM. The policy number is in the customer record. The member id is in the family roster. The hospital name and admission date are in the pre-authorisation. The only fields the insured genuinely needs to fill are the expense breakdown and the bank details for reimbursement.

Form B, filled by the hospital

Form B is medical. Treating doctor's name and registration number, diagnosis with ICD code, treatment summary, room category, date of admission and discharge, an itemised bill summary (room rent, ICU charges, medicines, investigations, surgery), and the hospital's stamp and signature.

This data lives in the hospital's HIS. The diagnosis is in the discharge summary. The bill is in the billing module. The treating doctor's registration is in the hospital's panel record. The hospital's ops team is just transcribing it onto a paper form because that is what the insurer accepts.

Where the back-and-forth comes from

Three points of failure cause most of the email chains:

• The insured's Form A is missing the bank IFSC, or has a wrong ailment description that does not match the discharge summary.
• The hospital's Form B has a diagnosis that does not match Form A. The TPA flags it and asks both parties to reconcile.
• The signatures and stamps are smudged, or the form is photographed in landscape and rotated wrong. The TPA rejects the file and asks for a re-scan.

Every back-and-forth adds three to seven working days to claim settlement. For the insured who paid out of pocket, that is real money sitting outside their account.

Half the rejected claims in Indian health insurance are not rejected for fraud or coverage. They are rejected because the forms do not agree with each other.

The workflow with one template engine

Here is what the same claim looks like when both forms are templates behind a versioned API.

Form A and Form B are two templates in the same Mezdoc workflow. The workflow has shared fields at the top (policy number, member id, hospital name, admission date, discharge date) and per-document fields below (Form A has bank details, Form B has the diagnosis and itemised bill).

When a claim is initiated, the TPA's backend triggers a run:

curl https://api.mezdoc.com/v1/workflows/health_claim_v2/runs \
  -H "Authorization: Bearer $MEZDOC_KEY" \
  -H "Idempotency-Key: claim_HC-2026-00481" \
  -d '{
    "environment": "production",
    "data": {
      "policy_number":   "HC-2026-00481",
      "member_id":       "M-12-A",
      "insured_name":    "Rajesh Kumar",
      "hospital_name":   "City Care Hospital, Pune",
      "admission_date":  "2026-05-12",
      "discharge_date":  "2026-05-17"
    },
    "signers": {
      "form_a": { "name": "Rajesh Kumar",  "phone": "+919876543210" },
      "form_b": { "name": "Dr. Anita Rao", "email": "anita.rao@citycare.example" }
    }
  }'

Mezdoc generates two tokenised links. One goes to Rajesh by SMS to fill the remaining Form A fields (bank details, expense summary) and sign with Aadhaar OTP. The other goes to Dr. Rao by email to fill Form B (diagnosis, itemised bill) and sign with her registered DSC or typed signature.

Both signed PDFs land in your callback with the same claim id. The workflow record carries both, signed, version-pinned, ready to attach to the claim file.

Where the savings actually come from

Shared fields stay in sync

Policy number is entered once and lands in both forms. Admission date is entered once and lands in both forms. The diagnosis field on Form B is validated against the discharge summary attached to the workflow, so a typo on either form gets caught before the file moves.

Tokenised links collapse the email chain

The insured does not photograph a form. The hospital does not email a scanned PDF. Both fill a clean web form and sign once. The signed PDFs are deterministic, machine-readable, and arrive in your TPA system the moment they are signed.

Audit trail per signer

Each signed Form A and Form B carries the signer's name, the signature method, the IP address, the user agent, and a SHA-256 of the rendered PDF. If a claim is ever disputed (and they are), you can produce the audit record in one API call.

Conditional second-form skip

Some claims do not need Form B because the hospital is in the cashless network and the discharge summary plus the bill suffice. The workflow handles this with a single include condition. The insured signs Form A, the workflow closes, and the cashless route runs in parallel without polluting the same template tree.

What stays your problem

• The insurer still has to underwrite the claim. The workflow does not change the claim decision.
• The hospital still has to give honest information. We can validate format, not truth.
• The bank account verification (penny drop, name match) is your own gateway. Mezdoc does not do payouts.

Everything else is a versioned template, a tokenised link, and a webhook.

The US parallel

In the US, the equivalent of Form A and Form B is the CMS-1500 (HCFA 1500) for outpatient and physician services, plus the UB-04 (CMS-1450) for hospital institutional claims. Same logic: one form filled by the patient or the billing service, one filled by the provider, both have to agree before the payer processes the claim. The shared fields (patient demographics, diagnosis codes, dates of service, NPI, place of service) live at the workflow level. The provider-side form pulls from the EHR, the patient-side form pulls from the member portal, both render through the same Mezdoc template engine. The pain point and the fix translate directly across markets.

A practical starting point

• Take your insurer's current Form A PDF. Upload as a structured template. Drop fields with snake-case aliases that match your CRM keys.
• Repeat for Form B.
• Create a workflow that links both, with shared fields at the workflow level.
• Run one test claim end to end with a real signer in your own team. Watch both PDFs come back signed.
• Wire the workflow trigger into your claim-initiation event in the TPA system.

Two days of setup, and the next claim your team handles produces both forms as a side effect of opening the file. The chase emails do not happen because the form is already complete and signed when it arrives. See the request shape in the live demo if you want to feel the API before you commit code.