# Gallagher Guide: benefits data supplier landscape

**Research date:** November 9, 2026  
**Decision:** Which integratable data suppliers can give Gallagher Guide the information needed to answer employees' benefits questions accurately across medical, dental, vision, prescriptions, care search, cost, and support?  
**Evidence:** Official vendor product/API documentation, government guidance, six user-supplied prototype screenshots, and the user's direct statement that **H1 eligibility is commercially available to Gallagher Guide as a paid option**. No live vendor API or member transaction was performed.

## Executive view

**H1 is a strong candidate for provider and network data. Zelis is the strongest additional supplier to investigate for a combined provider, procedure-cost, and member-cost API. Stedi is the clearest developer-oriented eligibility/benefit transaction benchmark; Availity, Optum/Change Healthcare, and pVerify are alternatives to test against the same payers.** Ideon may help with standardized plan design and network data, but its public plan/rate API is especially focused on individual and small-group markets; fit for a specific large or self-funded employer plan must be proven. Turquoise and Serif are specialist price/network sources, and Flexpa is a consented history source. [H1 API](https://ribbon.readme.io/docs/welcome-to-the-ribbon-health-api), [Zelis API catalogue](https://marketplace.zelis.com/), [Stedi healthcare](https://www.stedi.com/docs/healthcare), [Ideon API](https://docs.ideonapi.com/).

The critical finding is that **no public data-broker catalogue establishes every fact Gallagher Guide needs by itself**. An employee's actual plan terms and support routes must be supplied or approved by the employer, administrator, carrier, or applicable benefit program. A provider directory, a payer eligibility response, a published negotiated rate, and an EOB are different kinds of evidence. Gallagher Guide needs to join them without promoting an unknown into a confirmed answer. The U.S. Department of Labor describes the Summary Plan Description (SPD) and Summary of Benefits and Coverage (SBC) as core sources for plan rules, benefits, cost sharing, and limits. [DOL plan information](https://www.dol.gov/general/topic/health-plans/planinformation).

This report evaluates integratable data suppliers; employee-facing experience vendors are outside scope. The earlier [MRI demo deep dive](mri-demo-deep-dive.md) remains available as a specific stress test; MRI is **one demonstration**, not the product's scope.

## The data Gallagher Guide needs

| Employee question | Required evidence | Likely source |
|---|---|---|
| “Is this covered?” | Current plan year, service category, exclusions, visit/annual limits, prior-authorization and referral rules | Employer/administrator-approved SPD, SBC, plan documents, formulary, benefit configuration |
| “What deductible or out-of-pocket maximum remains?” | Member-specific accumulator, individual/family and in/out-of-network scopes, effective/as-of date | Carrier/TPA accumulator feed or payer eligibility response where returned |
| “Which provider can I use?” | Exact member network, provider **at a location**, service capability, current participation evidence | H1, Zelis, Ideon, Serif, carrier directory; confirmation when evidence is weak |
| “What will it cost with my coverage?” | Specific service/code, contracted/allowed rate or quote, member benefit rule, current balances, all billing components | Price broker plus payer/TPA benefit data and deterministic calculation; sometimes a vendor-supplied personalized estimate |
| “What happened to my claim or bill?” | Claim/EOB status, allowed amount, member liability, denial reason, relevant plan rule | Carrier/TPA claims feed, claim-status transaction, or consented record source |
| “Who can help me?” | Correct carrier/TPA, pharmacy, dental, vision, spending-account, HR, care-advocate and appeal contact; case/authorization status | Employer/program configuration and administrator systems, not a generic provider directory |

The prototype screenshots show why these distinctions matter. Gallagher Guide displays a medical plan, separate dental and vision cards, benefit balances, a provider search, plan-rule answers, and a calculator. The screenshots explicitly mark the data as fictional/demo; they do not verify live enrollment, balances, provider network, pricing, or a data contract. The displayed medical labels—Aetna plan administrator and UHC Choice Plus · Tier 1 network—also require reconciliation before any vendor can map a real member to a network. The BCBS North Dakota card is dental, not medical.

## Supplier comparison

**Reading key:** “Documented” means the supplier describes an API/data product for that category. “Conditional” means the capability depends on payer, client feeds, contract, plan support, or a separate module. “No public proof” is not a claim that the supplier cannot offer it privately.

| Supplier | Strongest data role | Member benefits / balances | Provider + network | Price / member cost | Main qualification |
|---|---|---|---|---|---|
| **H1 / Ribbon** | Provider and network foundation | **Conditional:** paid eligibility is available to Gallagher per direct conversation | **Documented:** providers, facilities, network plans, locations | **Conditional:** procedure and price modules/add-ons | Exact plan mapping, entitlement, joined facility/rate record, freshness |
| **Zelis** | Broad member-search and financial API suite | **Conditional:** accumulations and benefit data where client integration provides them | **Documented:** provider/facility search | **Documented/conditional:** TiC and procedure cost; member estimate depends on benefit data | Payer/client setup and data rights; verify Gallagher's access path |
| **Stedi** | Eligibility/benefit transaction layer | **Documented, payer-dependent:** 270/271 medical, dental, vision | No provider directory established | No facility-specific member quote established | Payers may return generic or incomplete benefit detail |
| **Availity** | Multi-payer transaction alternative | **Documented, payer-dependent:** coverage, deductible, OOP and other fields | No independent directory established here | **Conditional:** payer-specific estimator products | Submitter rights, payer enrollment, NPI and commercial access |
| **Optum / Change** | Enterprise transaction alternative | **Documented, payer-dependent** | No independent directory established in standard eligibility API | **Conditional:** other Optum products | Do not confuse standard Eligibility API with narrower Optum Real scope |
| **pVerify** | Eligibility alternative across medical/dental/vision | **Documented, payer-dependent** | No general provider directory established | No complete member quote established | Compare actual payer fields, terms, and digital-health rights |
| **Ideon** | Plan-design and network data for quoting/benefits platforms | **Documented plan design;** live member balances unproven | **Documented:** provider/network lookup | **Documented:** plan rates, not member claim cost | Public API focus on individual/small-group ACA; employer-plan fit unproven |
| **Turquoise Health** | Shoppable-service/facility pricing | **Conditional:** supported-plan estimate flow | Facility/service search documented | **Documented:** rates and supported-plan estimates | Specialized cost module, not general benefits data |
| **Serif Health** | Payer-network and negotiated-rate data | No live member balance established | Provider/network APIs documented | Negotiated rates documented | Transparency-file gaps/lag; not a final member quote |
| **Flexpa** | Consented coverage/claims history | Historical coverage/EOB context | Curated directory not offered | Historical claim amounts, not prospective price | Claims lag; patient-consented workflow |
| **WEX Benefits APIs** | HSA/FSA/HRA account data where WEX administers the account | Account/transaction data, not medical deductibles | No provider directory established | Account balances, not medical service price | Relevant only for employers using WEX accounts. [WEX developer center](https://www.wexinc.com/resources/blog/wex-launches-new-developer-center/). |
| **RxSense** | Prescription-benefit data where the PBM/platform relationship permits it | Pharmacy eligibility, benefit, formulary, and drug-price APIs are advertised | Pharmacy network, not medical provider network | Drug pricing is advertised | Contracted RxSense/PBM scope and Gallagher display rights must be proven. [Developer portal](https://developer.rxsense.com/). |

### H1: likely provider/network backbone, with paid eligibility worth testing

H1's Ribbon-derived API documents provider and location search, insurance/network matching, specialties, procedure data, and price/quality add-ons. Its location search includes imaging centers, but the value is broader: the API can populate provider choices for many kinds of care. H1 compiles directory data from claims, payer/hospital directories, vendors, and public sources. A published case study says Rightway's member-navigation service uses H1 provider data by API, illustrating the supplier role Gallagher could pursue. [H1 directory](https://ribbon.readme.io/docs/ribbon-directory), [network data](https://ribbon.readme.io/docs/insurances), [product packages](https://ribbon.readme.io/docs/ribbon-products), [Rightway case](https://h1.com/resources/h1-partners-with-rightway-on-custom-data-integration/).

The user has directly confirmed that H1 eligibility is an available **paid** option in current discussions. That is stronger, relationship-specific evidence than the public reference page, which still says the product is being upgraded for new customers. Confirm the contracted endpoints, supported payers, response fields, coverage of medical/dental/vision, price, and start date in the proposal. H1's own network-mapping guide says matching an employer's plan to H1's plan UUID can require manual work. Its eligibility API describes deductible, out-of-pocket, copay, and coinsurance fields, but payer support and actual field completeness must be demonstrated. [Eligibility guide](https://ribbon.readme.io/docs/eligibility), [public eligibility status](https://ribbon.readme.io/reference/geteligibilityinsurancepartners), [network mapping](https://ribbon.readme.io/docs/network-mapping).

**Strength:** one plausible provider/network foundation with adjacent modules. **Weakness:** no public evidence that H1 alone supplies employer-specific plan rules, every current member balance, support contacts, or a complete member-cost answer. Verify that provider, network, procedure price, and eligibility records can be joined for the same plan, location, and service; public docs present these as separate modules. [H1 products](https://ribbon.readme.io/docs/ribbon-products), [price reference](https://ribbon.readme.io/reference/getpricingproviders).

### Zelis: strongest new all-in-one data conversation

Zelis' API marketplace documents provider and facility search, a Transparency in Coverage search that can return negotiated rates and member cost-sharing elements, and a Procedure Cost API that estimates member out-of-pocket expense. Its TiC product describes accumulations, prerequisites, benefit limits, place-of-service differences, and in/out-of-network details. The marketplace also lists claims and ID-card APIs. This breadth makes Zelis a serious comparator to an H1-plus-eligibility-plus-price stack. [Provider Search](https://marketplace.zelis.com/product/provider-search/), [Provider Search with TiC](https://marketplace.zelis.com/product/provider-search-transparency-coverage/), [Procedure Cost](https://marketplace.zelis.com/product/procedure-cost/), [API catalogue](https://marketplace.zelis.com/).

**Strength:** documented APIs align with “find care and explain what it may cost with my coverage.” **Weakness:** the cost-sharing and accumulator result depends on member benefit data being available to Zelis through the client/payer integration; the public catalogue does not prove Gallagher can access those records for its employers. Ask whether Zelis is willing to supply data/API modules for Gallagher Guide, which networks and TPAs it can support, and what must be provided by the employer or payer. A TiC-compliant estimate is still an estimate, not a guaranteed final claim. [Zelis S365](https://www.zelis.com/solutions/member-engagement/s365/), [Provider Search with TiC](https://marketplace.zelis.com/product/provider-search-transparency-coverage/).

### Stedi, Availity, Optum and pVerify: compare payer answers, not feature lists

**Stedi** provides developer-oriented JSON/X12 eligibility transactions and publicly lists medical, dental, and vision payers. Its documentation explains service-type-specific benefits and warns that the payer may provide generic rather than precise detail; eligibility does not verify a named provider's network participation or guarantee payment. Public pricing and a mock sandbox make technical evaluation straightforward. [Supported payers](https://www.stedi.com/docs/healthcare/supported-payers), [active benefits](https://www.stedi.com/docs/healthcare/eligibility-active-coverage-benefits), [pricing](https://www.stedi.com/pricing).

**Availity** documents JSON/transaction APIs for eligibility/benefits and related claim-status/authorization workflows. Its payer-specific products and payer connectivity may make it useful where Stedi's response is weak. Confirm Gallagher's submitter eligibility, required NPI, payer enrollment and contracts, and whether payer-specific estimates are available for the exact target plans. [Transaction guide](https://developer.availity.com/blog/2025/3/25/hipaa-transactions), [API guide](https://developer.availity.com/blog/2025/3/25/availity-api-guide), [partner contact](https://developer.availity.com/partner/contact-us).

Availity also documents an optional Patient Cost Estimator/predetermination transaction. It depends on payer support and professional or institutional billing details; it should be tested as a targeted cost path, not assumed to produce universal estimates. [Transaction guide](https://developer.availity.com/blog/2025/3/25/hipaa-transactions).

**Optum/Change Healthcare** is the enterprise eligibility alternative. Its standard API returns the payer's response, so detail varies; the newer Optum Real feature set should not be assumed available across all payers. [Eligibility FAQ](https://developer.optum.com/eligibilityandclaims/docs/eligibility-api-faqs), [Optum Real scope](https://marketplace.optum.com/products/optum-real-for-medical/optum-real-apis-for-medical-providers.html).

**pVerify** advertises developer APIs for medical, dental, vision, and related eligibility checks. It is worth a bounded benchmark if dental/vision response quality or access terms are weak elsewhere. Its public descriptions do not remove the payer-response limitation. [Developer APIs](https://pverify.com/api-developers/), [eligibility explanation](https://pverify.com/what-is-an-eligibility-api/).

For all four, run the **same** member/plan/service questions and compare actual deductible, out-of-pocket, visit limit, co-pay, coinsurance, exclusion, authorization, and as-of fields. A vendor's payer count is not proof that the payer returns the required detail for a given plan.

There is also a practical access gate: Stedi's live eligibility requests require a provider identifier, usually an NPI, and some payer transactions require enrollment. Availity's examples likewise use a provider NPI and its payer list exposes contract/enrollment flags. Before assuming an employee-facing app can call any 270/271 broker, verify Gallagher's authorized submitter/provider arrangement and payer terms. [Stedi request requirements](https://www.stedi.com/docs/healthcare/send-eligibility-checks), [Stedi enrollment](https://www.stedi.com/docs/healthcare/credentialing-and-enrollment), [Availity transaction guide](https://developer.availity.com/blog/2025/3/25/hipaa-transactions).

### Ideon: benefit-plan and network data, with a market-fit question

Ideon advertises APIs for standardized plan/rate data, provider networks, and carrier enrollment connectivity; its documentation includes benefit objects and plan-document URLs. That could reduce plan-data normalization work, especially for quoted or offered plans. However, its public medical search endpoint centers individual and small-group ACA markets. It does not establish current accumulators or exact coverage for an employer's self-funded group plan. [Ideon HR/BenAdmin](https://ideonapi.com/hr-and-benadmin/), [API docs](https://docs.ideonapi.com/).

**Test:** provide one actual employer plan structure and ask Ideon to show whether it can return the approved plan document, network identity, benefit limits, and plan year—not simply an ACA plan with a similar label.

### Specialist data sources

**Turquoise Health** can enrich shoppable-service and facility price questions, with supported-plan personalized estimates. Its cost-share support is narrower than its rate coverage; exact payer/TPA support requires checking. It is a useful cost module, not the core source for everyday plan-rule or support questions. [Consumer Pricing API](https://turquoise.health/api/docs/), [personalized estimates](https://turquoise.health/api/docs/personalized-estimates/).

**Serif Health** offers provider/network and negotiated-rate APIs, a useful alternative or cross-check when H1 or Zelis coverage is weak. Serif itself documents gaps and lag in transparency-file data, so a rate or network inference should carry freshness and uncertainty. [APIs](https://www.serifhealth.com/platform/products/apis), [data limits](https://help.serifhealth.com/articles/4596348272-why-does-a-provider-e-g-an-npi-an-ein-that-says-they-are-in-network-with-a-payer-not-show-up-in-the-data).

**Flexpa** provides patient-consented coverage, claims, EOB and clinical history. It can help explain a past claim or personalize context, but its own documentation says it does not provide curated provider contact/quality data or rate-file tooling, and adjudicated claims are historical. [Network](https://www.flexpa.com/docs/network), [what it does not do](https://www.flexpa.com/docs/what-we-dont-do).

**Garner's provider API** is a possible quality/ranking data add-on for clinician searches. It is less compelling as the broad foundation: its directory lookup documentation excludes facilities, and its employer concierge/incentive experience is a separate product from raw data access. [API](https://garnerhealth.redoc.ly/).

**Kyruus Health's APIs** can supply plan-aware provider search in a payer/health-system partnership, but public material does not establish a universal member benefit feed for Gallagher. It is a targeted care-search comparator to H1 or Zelis, subject to partnership rights. [Search for health plans](https://kyruushealth.com/solutions/search-for-health-plans/), [developer API](https://kyruushealth.com/solutions/developers-api/).

**Benefits administration and account systems** may matter more than a universal broker for the broadest employee questions. Benefitfocus and bswift describe employer/carrier integration hubs; WEX has developer APIs for accounts it administers. These are potential sources of selected benefits, account balances, or program routing **only where the employer uses that system and grants access**. They do not supply a universal answer to medical network or service cost. [Benefitfocus integrations](https://www.benefitfocus.com/platform/integrations), [bswift connectivity](https://www.bswift.com/connectivity-hub/), [WEX developer center](https://www.wexinc.com/resources/blog/wex-launches-new-developer-center/).

**Prescription data needs its own feed.** RxSense's developer portal advertises member pharmacy eligibility, benefit details, formulary, pharmacy network, and real-time drug-price APIs. This is a candidate where the employer's PBM relationship and commercial rights permit access; it is not proof of universal prescription coverage. Surescripts also documents patient-specific real-time prescription benefits, but its published availability is for prescribers and their staff within prescribing workflows, so that product should not be assumed available to Gallagher's employee-facing app. The first step is to identify each employer's PBM and its authorized formulary, pharmacy-network, authorization, and price feed. [RxSense developer portal](https://developer.rxsense.com/), [Surescripts Real-Time Prescription Benefit](https://surescripts.com/products/real-time-prescription-benefit).

## Proposed vendor evaluation

### 1. Confirm the source map before buying APIs

For each employer, identify the owner and delivery mechanism of: plan documents and amendments; enrollment and selected network; medical/dental/vision/Rx benefit configuration; deductible and out-of-pocket accumulators; claims/EOBs; spending-account balances; formularies; provider network; rates; prior authorization; and support/appeals contacts. Record the permitted uses, refresh cadence, and responsible contact. A data broker may fill some columns but cannot repair a missing employer/administrator agreement by inference.

### 2. Run a question portfolio

Use fictional fixtures first, then consented live cases under the right agreements. Ask each supplier to return the raw record, provenance, date, plan/member identifiers, and failure/unknown behavior for:

1. A medical coverage question with a plan exclusion or prior-authorization condition.
2. Current individual and family deductible and out-of-pocket balances, distinguishing in-network and out-of-network.
3. A dental annual maximum and a vision allowance with usage unknown versus used.
4. A prescription tier, pharmacy network, and authorization question.
5. A clinician and facility search against the exact selected network, at a specific location.
6. A service-cost estimate, separating negotiated rate, plan share, member estimate, and missing price components.
7. A denied claim or surprising bill with an EOB and the correct appeal/support route.
8. The MRI demo as a composite test of multiple sources, rather than the sole decision criterion.

### 3. Compare three concrete configurations

| Configuration to test | Why it is worth testing | Critical proof |
|---|---|
| **H1 + paid H1 eligibility** | Potentially fewer contracts and a strong provider foundation | Exact paid entitlement, payer and benefit-field coverage, provider/plan linkage, price add-on, SLA |
| **H1 + Stedi (or Availity/Optum)** | Separate best-of-breed directory and payer transaction layers | Same plan identity across systems; response detail for medical, dental and vision; latency/cost |
| **Zelis suite** | Potentially integrated provider, rate, accumulator, and member-estimate APIs | Whether Gallagher can access the required payer/client benefit data and reuse the result in its own UI |

Test Ideon as an additional plan-design/network feed if its employer market scope fits, and add Turquoise or Serif only where the chosen stack lacks usable cost data. This is a research prioritization, not a procurement decision.

## Diligence questions for the next H1 conversation

1. Which exact paid eligibility product, endpoints, payer list, benefit fields, environments, and contract dates are offered to Gallagher Guide?
2. Can it return current medical, dental, and vision deductible/OOP/limit details for the target carriers and TPAs? What is absent or payer-dependent?
3. How are an employer's exact plan and network mapped to H1 UUIDs, and who maintains that mapping as plans change?
4. Can H1's provider, network, eligibility, procedure, and price modules return coherent records for the **same** member, plan, service, and location?
5. What are the source and last-confirmed date for network participation and provider address? What does a conflict look like in the API?
6. What rights does Gallagher have to display, cache, explain, and use these fields in an AI-assisted employee answer? What are the PHI/BAA requirements and support SLAs?
7. Which plan-rule content and support-contact data must Gallagher or the employer provide outside H1?

## Evidence limits

Public API catalogues show potential product surfaces, not the data Gallagher is entitled to receive or the quality of a particular payer response. The user's direct H1 commercial update is specific to Gallagher's current discussion and should be confirmed in a written proposal. No source reviewed proves one supplier can deliver all employer-specific plan rules, member balances, network status, prices, and support routes. The screenshots are a fictional prototype; live verification and contract/data-rights review remain the next gates.