Payer Network

Overview

The Payer Network is a comprehensive list of supported payers and their automation capabilities. This provides the discovery layer that enables developers to understand which payers support specific features and what requirements must be met to integrate with each payer's systems. The Payer Network serves as the authoritative source for:

• Feature Discovery: Check which automation features are available for specific payers
• Integration Planning: Understand portal requirements and authentication methods before implementing automation workflows
• Data Synchronization: Use createdAt and updatedAt timestamps to keep local payer databases in sync
• Payer Resolution: Map various payer identifiers (common IDs, alternate IDs, names) to Zuub's stable primary payer IDs

See what payers are supported

Core Concepts

Payer Identification Strategy

Payers are often identified differently depending on the clearinghouse, third party administrator (TPA) or the payer's own requirements. These IDs often change over time as insurance plans change their source for health information. To assist mapping payers to make automation requests, Zuub provides multiple IDs.

Primary Payer ID

Zuub's unique, stable identifier for each payer. This 6-character alphanumeric code (e.g., X26ZCF) never changes and serves as a reference for syncing payer lists.

Note: Primary payer IDs are not used in any request and are available to sync the list in integrated systems

Common Payer ID

A widely-used industry identifier that often groups related payers together.

Note: Common IDs are not unique - multiple payers may share the same common ID. For example, GP133 represents various UnitedHealthcare plans across different states.

Alternate Payer IDs

Additional identifiers that the payer is known by at other clearinghouses throughout the industry. These help with cross-referencing and integration with existing systems.

Feature Support Model

Each payer's automation capabilities are represented through a features map with the following characteristics:

Feature Types

• Credential Validation: Validation of portal login credentials
• Insurance Verification Asynchronous: Asynchronous insurance verification from a direct source
• Insurance Verification Synchronous: Real-time insurance verification from a baseline source

Support Lifecycle

• Active: Fully supported and recommended for new integrations
• Deprecated: Still functional but discouraged for new integrations; support will end at a future date
• Undefined: If a feature is not present in the features map, it indicates no support exists

Feature Requirements

Features may have requirements that must be satisfied to use automation. Requirements use a discriminated union pattern with the type field identifying the specific requirement. Each payer may have different combinations of requirements based on their verification processes.

Portal Requirements

Portal-based automation requires authentication with one or more payer portals:

Authentication Methods:

• Basic: Username and password authentication
• TwoFactorSms: SMS-based two-factor authentication
• TwoFactorEmail: Email-based two-factor authentication
• None: No authentication is required and is usually based on searching for provider and member identifiers

Login Methods:

• Native: Standard portal login process
• SSO: Single sign-on authentication
• None: No login is required and is usually based on searching for provider and member identifiers

Portal Usage Patterns:

• Any: Choose one portal from the available options. Common when multiple portals provide the same functionality
• All: All portals must be used together. Required when different portals provide complementary data (e.g., one for eligibility, another for claims history)

Credential Storage Requirements

Many payers require additional information beyond portal credentials for insurance verification. These requirements ensure that verification requests can be accurately matched to the correct provider records in the payer's system:

Requirement Type	Description	Usage Types
OfficeAddress	Full office address (street, city, state, zip code)	Exact
OfficeAddressWithSuite	Office address including suite/unit number	Exact
OfficeName	Dental office or clinic name	Exact, Partial
OfficeTaxId	Office tax identification number (TIN/EIN)	Exact
OrganizationNationalProviderId	Organization-level NPI (Type 2 NPI)	Exact
ProviderFirstName	Individual provider first name	Exact
ProviderLastName	Individual provider last name	Exact
ProviderNationalProviderId	Provider-level NPI (Type 1 NPI)	Exact

Usage Types:

• Exact: The value must match exactly as registered with the payer (no partial or fuzzy matching)
• Partial: The value may be partially matched (e.g., "Smith Dental" could match "Smith Dental Clinic")

Note: Only the OfficeName requirement supports partial matching. All other requirements require exact matches.

Common Requirement Patterns

Different payers have varying requirements based on their verification systems:

Minimal Requirements (e.g., Anthem):

{
  "requirements": [
    { "type": "Portal", "usage": "Any", "portals": [...] },
    { "type": "ProviderNationalProviderId", "usage": "Exact" }
  ]
}

Standard Requirements (e.g., UnitedHealthcare Alabama):

{
  "requirements": [
    { "type": "Portal", "usage": "Any", "portals": [...] },
    { "type": "OfficeName", "usage": "Exact" },
    { "type": "OfficeAddress", "usage": "Exact" },
    { "type": "ProviderNationalProviderId", "usage": "Exact" },
    { "type": "OrganizationNationalProviderId", "usage": "Exact" }
  ]
}

Comprehensive Requirements (e.g., Molina Healthcare):

{
  "requirements": [
    { "type": "Portal", "usage": "Any", "portals": [...] },
    { "type": "OfficeName", "usage": "Exact" },
    { "type": "OfficeAddress", "usage": "Exact" },
    { "type": "OfficeTaxId", "usage": "Exact" },
    { "type": "ProviderFirstName", "usage": "Exact" },
    { "type": "ProviderLastName", "usage": "Exact" },
    { "type": "ProviderNationalProviderId", "usage": "Exact" },
    { "type": "OrganizationNationalProviderId", "usage": "Exact" }
  ]
}

Variant IDs for Aggregate Portals

Some portal platforms serve multiple payers through a single interface. Variant IDs distinguish between different payers using the same portal infrastructure.

Example: DentalHub (https://app.dentalhub.com) serves many UnitedHealthcare variants. Each state or plan type has a unique variant ID:

• United Healthcare Arkansas: va_01jt3z5g03fvgvdcknnzva76zk
• United Healthcare California: va_01jt3z5g03fvgvdckza24dz2tb

When a portal has a variantId, it must be included in automation requests to ensure the correct payer context.

Best Practices

1. Cache Payer Network Data: Cache the response and use timestamps for incremental updates rather than fetching the entire network repeatedly.

2. Handle Feature Absence Gracefully: If a feature is not present in the features map, it means no support exists. Don't assume features are available.

3. Validate All Requirements Before Submission: Check both portal requirements and credential storage requirements. Ensure you can collect all required information (office name, address, NPIs, tax IDs, provider names) before initiating automation workflows.

4. Collect Required Data Upfront: When building user interfaces, use the requirements array to determine what information to collect from users during credential registration. This prevents failed verifications due to missing required fields.

5. Handle Requirement Types with Discriminated Unions: The type field identifies the requirement type. Use this field to determine what data is needed and how to present it to users.

6. Respect Usage Types for Matching: When a requirement specifies "usage": "Exact", ensure the data matches exactly as registered with the payer. For "usage": "Partial" (OfficeName only), allow for variations in matching.

7. Monitor Deprecation Status: Regularly check for deprecated features and plan migration strategies. Deprecated features will eventually be removed. These changes will be communicated before any change of support.

8. Use Common Payer IDs for API Calls: Always use the commonPayerId for making requests.

9. Handle Variant IDs Carefully: When variant IDs are present, they are typically required for successful automation. Missing or incorrect variant IDs will cause automation failures.