> ## Documentation Index
> Fetch the complete documentation index at: https://docs.develophealth.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Benefit Verification Overview

> How to submit reliable benefit verifications, plan for completion times, and interpret results.

Benefit verification checks whether a patient's insurance plan includes
prescription drug benefits and, for each requested medication, whether it is
covered, whether prior authorization is required, and what the copay is when
available. The workflow is asynchronous: creation returns an ID, and the
completed result is delivered through the retrieve endpoint or a webhook.

## Recommended integration flow

1. Submit the strongest medication, insurance, patient, provider, and clinical
   information available.
2. Store the returned benefit verification ID.
3. Subscribe to `benefit_verification.status_change` or poll
   [Retrieve Benefit Verification](/api-reference/medication-benefit-check/get_item).
4. Wait for a terminal `data.status` before using the coverage result.
5. Correct and replace failed requests when the error identifies an input
   problem; otherwise use your existing verification process when the result is
   urgent.

## Provide the strongest inputs available

Complete inputs improve routing, completion, and the specificity of the result.

| Input                | Recommendation                                                                                                          | Why it matters                                                                                                                                                         |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Medication           | Prefer a coded drug with the exact NDC. Include every exact NDC you want evaluated, up to seven drugs per request.      | Coverage can differ by manufacturer, strength, dosage form, and brand versus generic. An exact NDC is less ambiguous than a drug name.                                 |
| Insurance card       | Provide clear images of the front and back whenever available.                                                          | The card helps identify the payer, plan, member, and pharmacy benefit routing information.                                                                             |
| Structured insurance | Populate `insurance_content` with known values, especially member number, payer name, Rx BIN, Rx PCN, and Rx group.     | Structured values avoid OCR ambiguity. When both card images and structured values are supplied, the structured values take precedence and card extraction fills gaps. |
| Patient              | Supply complete demographics that match the insurance record, including name, date of birth, address, and phone number. | Payers use these values to locate and verify the member.                                                                                                               |
| Provider and entity  | Supply the prescribing provider's NPI and the associated legal entity information when available.                       | Some payers require both provider and entity details before they will disclose benefits.                                                                               |
| Clinical context     | Include relevant ICD-10 diagnoses and drug history.                                                                     | Clinical context can help answer coverage questions and reduce follow-up work.                                                                                         |

If a workflow needs to compare brand and generic coverage, submit the exact NDC
for each option rather than relying on a free-text name to represent both.

## Completion time and verification methods

Develop Health automatically selects the available verification route for the
patient's plan. A single request can use more than one method before it reaches a
terminal state.

| Method                           | Typical timing                  | Notes                                                                                                        |
| -------------------------------- | ------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| Electronic or direct integration | Seconds to a few minutes        | Used when the plan and submitted data support an electronic route.                                           |
| AI-assisted phone verification   | Commonly 30–60 minutes          | Timing depends on payer menus, hold times, and whether the needed information can be gathered automatically. |
| Human phone verification         | Usually within one business day | Payer availability and difficult-to-reach plans can extend the long tail beyond one business day.            |

These ranges are planning guidance, not a service-level guarantee. Keep the
integration asynchronous regardless of the expected route, and do not schedule
downstream patient activity around the fastest path. Completed responses expose
the methods used in `verification_methods`.

## Response handling

A successful create response means the benefit verification was accepted, not
that it completed. See [Benefit Verification Response Handling](/api-reference/medication-benefit-check/response-handling)
for lifecycle states, request errors, workflow failures, and recommended caller
behavior.