Benefit Verification Overview

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.

Choose a processing mode

Set preferred_processing_mode when creating a benefit verification. The field defaults to standard.

Value	Behavior	Best for
`standard`	Uses the full benefit verification process and the broadest available input and completion paths.	Requests where completion rate is more important than latency.
`realtime`	Attempts real-time electronic benefit verification first, then automatically continues in standard mode when real-time processing is ineligible, unavailable, incomplete, or unsuccessful.	Latency-sensitive requests that should retain the broader standard process as a fallback.
`realtime_only`	Attempts only real-time electronic benefit verification. The request fails if real-time processing cannot complete; standard processing never starts.	Workflows that require a bounded real-time outcome and can handle a terminal failure without fallback.

Real-time capability must be enabled for your organization before you can request realtime or realtime_only. See Real-time Processing for eligibility requirements, processing-mode tracking, fallback behavior, insurance-card handling, and capacity constraints.

Recommended integration flow

Submit the strongest medication, insurance, patient, provider, and clinical information available.
Store the returned benefit verification ID.
Subscribe to benefit_verification.status_change or poll Retrieve Benefit Verification.
When using realtime, read current_processing_mode if your patient flow needs to distinguish real-time processing from standard fallback.
Wait for a terminal data.status before using the coverage result.
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.	Standard processing can use the card to identify the payer, plan, member, and pharmacy benefit routing information. Real-time processing does not scan card images, but standard fallback can use them.
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 and are required for real-time eligibility. In standard processing, card extraction can fill gaps when both sources are supplied.
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
Real-time electronic verification	80% of successful real-time BVs complete within 10 seconds; maximum 30 seconds.	Available only for eligible requests using `realtime` or `realtime_only`; every requested drug must complete before the timeout.
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 for lifecycle states, request errors, workflow failures, and recommended caller behavior.

Getting Started