Care Pricing Tools - Arlo Health

Overview

Three read-only tools answer the questions patients can’t answer themselves at booking time.

Tool	Question it answers
`search_care_prices`	Where can I get a service nearby, and what does each place charge under my plan?
`check_network_status`	Is this specific provider or facility in-network for me, and what do they charge?
`get_provider_evidence`	What does public data say about this one provider?

All three are free: they never charge the user, never start a consultation, and work without an active care request. Estimates come from insurers’ published machine-readable rate files and Medicare’s fee schedules, plus public CMS data about providers.

Coverage. US only. Supported: Anthem, any Blue Cross Blue Shield plan through BlueCard, Blue Shield of California, UnitedHealthcare (including UMR, Oxford, and Surest), Cigna, Aetna, Blue Cross Blue Shield of IL/TX/OK/NM/MT (HCSC), and Original Medicare. Medicare Advantage plans are declined with the reason: their rates are not published. Kaiser, Medicaid, and Medi-Cal are not supported.

Estimates are never guarantees. Every response carries a disclaimer. Always relay it: the number is a negotiated rate, not out-of-pocket cost, and actual billing can differ, so the user should confirm cost and network status when scheduling.

The same lookups are served as a public HTTP API with no login at https://api.arlohealth.ai/api/pricing.v1, with identical response shapes. The Pricing API guide is the field-by-field reference for reading responses, including the Original Medicare section. This page covers what is specific to the MCP tools.

How plan matching works

With an Arlo account the plan can come from two places:

Linked insurance records. When the patient has connected records, the plan resolves from their coverage automatically (plan.payerSource: "linked_coverage"). If the records carry more than one active coverage, plan.coverageSelection says which one was used; pass planHints.payerName to pin a different one.
planHints. Identifiers from the patient: payerName, employerName, planName, groupNumber (HCSC only), or unavailable: true to stop the asks.

Pass patientId (from get_user_profile) to price for a family member. The response’s plan block says what the estimate is based on. Read matchTier and basis before relaying any number:

`matchTier`	Meaning
`ein_exact`, `employer_exact`, `plan_name_exact`, `group_exact`	The exact plan was found. `rate` is its negotiated rate
`payer_fallback`	Insurer known, plan not identified. `rateRange` across the insurer’s plans; `needsMoreInfo` asks for the employer or plan name
`payer_fallback_unbacked`	The exact plan was found but Arlo does not have its rate files yet. Ranges only; asking for more identifiers will not help
`medicare_schedule`	Original Medicare. `rate` is Medicare’s approved amount; `patientShare` says what the person owes
`no_payer`	No supported insurer. Read `needsMoreInfo` for what to tell the patient

plan.planHintsReceived reports whether your hints matched. When matched: false, don’t re-ask the patient for the same value.

Choosing the service

There is no free-text service input. You pass a CPT/HCPCS code from the supported catalog (about 170 common outpatient services), because codes carry patient facts the server cannot infer: age band, new versus established patient, screening versus diagnostic, body part, contrast.

The response echoes a service block with appliesTo (the fact baked into the code) and relatedCodes (siblings selected by a different fact). Verify appliesTo against the actual patient before relaying numbers, and switch codes when a sibling fits better.
When the code isn’t supported, or none was given, the response returns the full supportedServices catalog. Pick the closest code and re-call.
service.priceNote carries pricing semantics that change what the number means (per-15-minute therapy units, ACA preventive care usually $0 out of pocket, a facility fee that excludes the physician’s bill). Relay it whenever present.

search_care_prices

Find nearby in-network care options with estimated negotiated prices under the user’s plan. This is area discovery (“what does this cost around here”), not a clinic directory.

Parameters

Parameter	Type	Required	Description
`code`	string	Yes in practice	CPT/HCPCS code from the catalog
`latitude` / `longitude`	number	No	Preferred location
`zip`	string	No	5-digit ZIP if coordinates are unavailable
`radiusKm`	number	No	Search radius in km (default 40)
`limit`	number	No	Max facilities (default 25). Also widens the fetched provider pool
`planHints`	object	No	`payerName`, `employerName`, `planName`, `groupNumber`, `unavailable`
`patientId`	string	No	Family-member patient id from `get_user_profile` (defaults to the account holder)

Reading the results

Results are grouped into facilities, places of care (billing NPIs grouped by street address), and ordered by sortBasis: places with observed billing for the service first, each tier cheapest first. Present results place-first with the providers inside. Each provider carries:

Field	Meaning
`rate` / `rateRange` / `typicalRate`	Exact-plan rate, or the spread across the insurer’s plans, and the median among this payer’s members
`rateAssessment`	Set when the rate is far from typical (1.75x or more, 0.4x or less). Always relay
`serviceEvidence`	`observed` = this NPI bills this service in public Medicare claims; `category_observed` = bills near-identical services; `unconfirmed` = no record. Never say a provider does not offer a service
`note`	Per-provider caveat, for example a facility rate that excludes the physician’s separate fee. Relay when present
`billingOrg` / `multiEntity`	The legal entity whose contract the rate comes from. `multiEntity: true` means the NPI also prices under other entities and the shown rate is only the cheapest. Quote a specific clinic through `check_network_status`, not this row
`signals` / `medicareAnchor`	Public-CMS evidence and a Medicare reference point. Read as described under `get_provider_evidence`
`telehealthEligible`, `confidence`, `setting`	Delivery plausibility, match confidence, `office` or `facility`

Facility-level: activityNote (no provider here shows recent billing; verify the location is open), observedServiceBilling, and latitude / longitude / locationPrecision for maps. Top-level: totalFound (eligible providers in the area), rateFetchNote (the page is the nearest subset, a cheaper option may exist farther out), and signalDefinitions.

Named clinic, brand, or provider: call check_network_status first. This tool does not resolve who bills. The same brand can bill under different legal entities at 4x or more different rates by market, and that fork only shows in check_network_status.

check_network_status

Check whether a specific provider or facility is in-network for the user’s plan, and optionally what they charge for a service.

Parameters

Parameter	Type	Required	Description
`providerName`	string	No	Provider or facility name. Consumer brand names work (matched against NPPES “doing business as” records)
`npi`	string	No	10-digit NPI if known. Never required
`code`	string	No	Add a catalog code to get each match’s contracted rate, benchmarked against the typical rate
`latitude` / `longitude` / `zip`		No	The clinic’s location, to disambiguate. `location.applied` says whether it was consumed
`limit`	number	No	Max matches (default 50, max 100). Large systems bill under many NPIs whose network status and rates differ; the breadth is the signal
`planHints` / `patientId`		No	Same as `search_care_prices`

Interpreting network status

inNetwork: true: the provider appears with negotiated rates in the plan’s published network files. networkEvidence counts how many of the plan’s network memberships back it (1 to 2 is thin, 10 or more is broad).
inNetwork: false: “not found in the published files.” Read the match’s note for how strong that is. Never state a hard “out of network.” When every match is false, that is still not a verdict: the entity that actually bills may not carry the consumer name. Resolve the billing NPI (the provider_identity ask says how) and re-call.
identityCaution: a same-name person far from the given location. Verify before relaying anything.
matchNote: a match appended by re-searching the name inside the plan’s files. Often the system’s main billing entity at another address.
rateNote: in-network, but the published files carry no rate for the code. Don’t read a missing rate as “not covered.”

Which entity bills

On a rated match, read billingOutlook first:

`billingOutlook.mode`	What to do
`single`	One entity. Quote the rate
`resolved` / `likely`	Lead with the leading entity and its `basis`; mention alternatives
`partitioned`	The price depends on who bills, and the data cannot tell. Relay the outlook’s `ask` in plain words. Never quote one number while partitioned

A warning on the outlook is binding: a brand-name match does not establish the biller. billingCandidates lists one entry per legal entity that could bill (billingOrg, tin, rate or range, evidence tags), cheapest first. A past bill’s Tax ID matches tin and settles it; the billing NPI from an EOB is what you re-call with. When billingNote is present, surface the fork instead of a single price. When several matches share a legal name, facilityType, subpart, parentOrganization, and the top-level organizations tree say which kind of entity each is (the hospital, its FQHC subpart, student health). Never pick the cheapest same-name entity as the answer.

Example

// "Is One Medical in my network, and what's an office visit there?"
// Confirm the clinic's city or ZIP first: the same brand bills under
// different entities in different markets.
const result = await checkNetworkStatus({
  providerName: "One Medical",
  code: "99213",
  zip: "94110"
});

// Relay needsMoreInfo asks, billingOutlook.ask, rateAssessment flags, and the disclaimer.
// If the user can't provide plan identifiers:
const fallback = await checkNetworkStatus({
  providerName: "One Medical",
  code: "99213",
  zip: "94110",
  planHints: { unavailable: true }
});

get_provider_evidence

Public-data evidence about one provider: Medicare-derived experience (procedure volume, with a national percentile only when high), facility outcome context, what Medicare actually paid this provider per service, or an explained absence. On widget hosts it renders an evidence card for the patient.

When to call

Only once the conversation is focused on one specific provider: the patient asks about a particular doctor, or is choosing between named finalists (call once per provider). It needs the NPI, so resolve it first with check_network_status or from search_care_prices results.

Parameters

Parameter	Type	Required	Description
`npi`	string	Yes	The provider’s 10-digit NPI
`code`	string	No	Catalog code to scope the evidence to one service

Returns

Field	Meaning
`provider`	`npi`, `name`, `entityType`, `city`, `state`
`signals[]`	`type` is `volume`, `outcome_context`, `optout`, `absence`, or `exclusion`. Each carries a `display` sentence stating how it was derived
`medicareAnchors[]`	`{ code, setting, service, medicareAllowed, year }`. What Medicare paid this provider
`signalDefinitions`, `methodology`, `corrections`	A legend, and where the method and a corrections process are described

Binding rules

Relay each signal’s display sentence as written, or summarize without changing its meaning. Never compress a percentile into “best doctor” or any ranking language.
level: "facility" signals describe the facility, never the clinician.
Absence of data is never negative evidence. Pediatric, commercial-only, and newer practices legitimately lack Medicare data; absence and optout signals explain this.
An exclusion signal is a federal exclusion-list notice. Relay it plainly.
Medicare anchors are reference points, not the patient’s price and not a fair-price claim. The patient’s rate comes from search_care_prices or check_network_status.
There is no composite score, and evidence never re-ranks price results.

​Overview

​How plan matching works

​Choosing the service

​search_care_prices

​Parameters

​Reading the results

​check_network_status

​Parameters

​Interpreting network status

​Which entity bills

​Example

​get_provider_evidence

​When to call

​Parameters

​Returns

​Binding rules

Overview

How plan matching works

Choosing the service

search_care_prices

Parameters

Reading the results

check_network_status

Parameters

Interpreting network status

Which entity bills

Example

get_provider_evidence

When to call

Parameters

Returns

Binding rules