Skip to main content
Home▸Docs▸Configure Plan Networks

Configure Plan Networks

Connect plan-level network tiers to distinct in-network and out-of-network cost sharing, then verify the tier selected during adjudication.

Two related configurations

The plan defines tier identities and cost-sharing behavior. Provider participation determines which tier applies to a claim. Test both sides of that boundary.

Network Model

Provider participation
Provider + plan + network
→
Network tier
Tier 1 or Tier 2
→
Benefit rule
Copay / coinsurance
TierExample network IDTypical cost sharing
Tier 1 — In-NetworkCHO-PREMIERLower copay and coinsurance
Tier 2 — Out-of-NetworkCHO-EXTENDEDHigher cost sharing and deductible

1. Configure Network Tiers

Open the plan in the portal and select Networks. The tier table shows the priority, operator-facing name, and stable network organization ID used to resolve provider participation.

Cloud Health Office Networks tab showing preferred and out-of-network tiers with priorities, stable network IDs, and edit and remove actions.
The Networks tab makes the complete effective tier set visible instead of collapsing the plan to its primary network.

Choose Add Network Tier. Set a unique priority beginning with Tier 1, enter a human-readable tier name, and use the same stable organization ID referenced by provider participation. Duplicate tier levels and network IDs are rejected.

Add Network Tier dialog with tier level, tier name, and stable network ID fields.
The editor explains the provider-participation boundary and makes the version-safe publish behavior explicit before saving.

Select Add Network Tier to publish the successor version. Use the pencil action to revise a tier or the delete action to remove it; each operation replaces the complete tier set atomically on one new published version, preserving the prior version for audit.

Optional: automate the complete tier set through the API

For repeatable environment setup, send the complete desired collection. This endpoint uses the same amendment-and-publish behavior as the portal.

Shellreplace network tiers
curl -fsS -X PUT \
  "${BENEFIT_PLAN_URL}/api/v1/plans/${PLAN_ID}/network-tiers" \
  -H "Content-Type: application/json" \
  -H "X-Tenant-ID: ${TENANT_ID}" \
  -d '[
    {
      "tierName": "Premier Network",
      "tierLevel": 1,
      "networkId": "CHO-PREMIER"
    },
    {
      "tierName": "Out-of-Network",
      "tierLevel": 2,
      "networkId": "CHO-EXTENDED"
    }
  ]' | jq
Replace semantics

The API body is the complete desired tier set. Omitting an existing tier removes it from the successor version; retrieve and review the current plan before automating an update.

2. Inspect the Effective Provider Roster

Below the tier table, choose a plan network tier and an as-of date, then select Load effective roster. The portal resolves the stable plan network ID against provider-service and displays the network’s name, type, line of business, effective period, active version, and date-filtered providers.

Cloud Health Office provider participation verification panel showing an active network organization and its date-effective provider roster.
The plan’s CHO-PREMIER tier resolves to the active provider network and the providers effective on the selected date.

Roster rows connect provider identity to the exact participation record: NPI, specialty, plan, network tier, effective dates, and cached integrity status. A provider omitted from the roster may still have a historical or future participation, so use the individual check before concluding that no relationship exists.

Shelleffective roster API
curl -fsS \
  -H "X-Tenant-ID: ${TENANT_ID}" \
  "${PROVIDER_SERVICE_URL}/api/v1/networks/${NETWORK_ID}/roster?asOfDate=${SERVICE_DATE}&pageSize=25" |
  jq '{pageSize,nextCursor,providers:[.items[] | {npi:.provider.npi,name:.provider.displayName,planId:.participation.planId,tier:.participation.networkTier,effectiveDate:.participation.effectiveDate}]}'

3. Verify One Provider’s Participation

Select the shield action on a roster row, or enter any 10-digit NPI and select Verify participation. This calls the same date-sensitive membership endpoint used by the claims adjudication network-and-credentialing stage.

Cloud Health Office network membership result confirming that a provider NPI is an active member of the selected plan network on the service date.
The positive result proves the NPI, stable network ID, service date, network tier, and line of business used for enforcement.
ResultMeaning
Active memberA participation satisfies effectiveDate <= asOf < terminationDate and may select this network tier.
Not activeA participation exists, but it is future, terminated, suspended, or pending on the selected date.
No participation recordThe NPI has no relationship with this stable network ID in the tenant.
Shellsingle membership API
curl -fsS \
  -H "X-Tenant-ID: ${TENANT_ID}" \
  "${PROVIDER_SERVICE_URL}/api/v1/networks/${NETWORK_ID}/members/${NPI}?asOf=${SERVICE_DATE}" |
  jq '{networkId,npi,isActiveMember,asOfDate,participationStatus,networkTier,lineOfBusiness}'

4. Configure Tiered Cost Sharing

Each covered-service rule can carry both in-network and out-of-network values:

JSONoffice visit benefit
{
  "benefitType": "medical",
  "serviceCategory": "98",
  "description": "Professional Office Visit",
  "inNetworkCopay": 30.00,
  "outNetworkCopay": 60.00,
  "deductibleApplies": false,
  "oopApplies": true,
  "priorAuthRequired": false
}

For deductible-based services, configure the plan’s in-network and out-of-network deductible and OOP maximum fields as well as the service-level coinsurance.

5. Verify Both Adjudication Paths

  1. Retrieve the member view and confirm that the category exposes the expected In-Network and Out-of-Network values.
  2. Confirm the provider is an active network member on the claim’s service date.
  3. Submit a synthetic claim for the participating provider and confirm the in-network tier and lower cost sharing.
  4. Repeat with a synthetic nonparticipating provider and confirm the out-of-network rule.
  5. Test an emergency scenario separately; emergency and surprise-billing protections can override ordinary network treatment.
Shellinspect the member view
curl -fsS \
  -H "X-Tenant-ID: ${TENANT_ID}" \
  "${BENEFIT_PLAN_URL}/api/v1/benefit-plans/${PLAN_ID}/member-view?serviceDate=2026-07-15" |
  jq '.categories[] |
      select(.serviceCategory == "98") |
      {displayName,inNetwork,outOfNetwork}'
Completion check

The stable plan network ID resolves to an active provider network, the roster and single-NPI result agree for the service date, the member view exposes both tiers, and otherwise equivalent claims produce the configured in-network and out-of-network responsibility.

Evaluator Review Questions

  • Can the reviewer trace a provider’s participation record to the plan network ID?
  • Are network-tier fields present for every service category that permits out-of-network care?
  • Do accumulator buckets align with network-specific deductible and OOP values?
  • Are emergency and regulatory exceptions covered by explicit test cases?