Once you've confirmed a patient's coverage, the next question is obvious: "Can they actually see this provider?". That's where the Network Status API comes in. It answers the second half of the eligibility story - verifying whether a provider is in-network for the patient's active plan.

How the Network Status API Works

The Network Status API checks whether a provider group is in-network for a given patient. You provide a Verification ID and the response returns a list of provider groups with an indication of whether they are in or out of network for the patient.

Networks

For this to work effectively, you first need to define your networks. A network could be as broad as "all UnitedHealthcare plans" or as narrow as "Aetna and Cigna EPO and PPO plans in Florida excluding any HMO plans".

In the Sohar dashboard you can create the rules that define each of your networks. The pseudo-YML example below shows what this might look like:

name: "Aetna & Cigna EPO and PPO"

conditions:

  # Match if the payer is Aetna or Cigna
  - key: payer
    operator: EQUAL
    value: "Aetna"
  - key: payer
    operator: EQUAL
    value: "Cigna"

  # Match if the plan name includes EPO or PPO
  - key: plan
    operator: INCLUDES
    value: "EPO"
  - key: plan
    operator: INCLUDES
    value: "PPO"

  # Match if the state is Florida
  - key: state
    operator: EQUAL
    value: "FL"

  # Exclude HMO plans
  - key: insuranceTypeCode
    operator: NOT_EQUAL
    value: "HM"

The attributes in the Verification response are compared against these conditions to determine whether the patient is included in this network.

Provider Groups

With your networks defined, you are ready to associate them with provider groups. It might be that your New York provider group is in-network with your Aetna network, but your Florida provider group is out of network.

The diagram below shows the relationship between patients, networks and provider groups:

Calling the API

To automate patient intake, you would typically make a request to the Network Status API once a Verification has resolved successfully with a complete.eligible status. The Network Status API is synchronous, so there's no need to wait for a webhook response.

Creating a request is simple - the API only needs a valid Verification ID:

curl --request GET \
  --url https://api.soharhealth.com/v1/network-status/{verificationId} \
  --header 'Authorization: Bearer <token>'

The response indicates the network status for your organization, with a list of provider groups and their respective network status:

{
  "status": "inn",
  "verificationId": "fb701ac1-1246-4860-b1ec-bd916b97a990",
  "payer": {
    "id": "60054",
    "name": "Aetna"
  },
  "labels": [],
  "providerGroups": [
    {
      "id": "992d71b7-ef7e-47e3-92c4-1a1c459d3333",
      "name": "My Group",
      "tin": "123456789",
      "status": "inn"
    }
  ]
}

Best Practices

  • Always verify first: Run Verification to ensure the plan is complete.eligible before checking network status
  • Cache results: Provider-plan relationships rarely change; cache results for 30 days
  • Handle unknowns: Some API requests may return with a "pending" status if a matching network is not found - use this information to create or modify your network conditions

Where This Fits in Flows

  • Verification → Network Status: Confirm both eligibility and network status before scheduling
  • Network Status → Cost Estimate: Use in-network results to ensure accurate patient cost estimates
  • Discovery → Verification → Network Status: Build a full intake workflow from minimal data to network status confirmation

Network Status is a powerful tool to extend Verification with routing and decision logic - the foundation for building intelligent patient intake workflows. More on that soon.