Eligibility
10 min read

Insurance and Licensure Rules in Provider Resolution

How Orita enforces insurance plan and license region constraints — including alias normalization, expiry windows, and the boundary between operational and clinical eligibility.

July 31, 2026
·By Orita Team

Insurance and licensure are the two most commonly misconfigured eligibility dimensions in provider resolution. This article explains how Orita stores, evaluates, and enforces them.

Important boundary

Orita evaluates operational provider eligibility — whether a provider is licensed in the required region, accepts the required insurance plan, and is operationally available.

Orita does not evaluate clinical eligibility — whether a patient's symptoms, diagnosis, or clinical need matches a provider's therapeutic approach. That determination belongs to the upstream application and clinical staff.

License records

Each provider can carry multiple license records:

{
  "licenseRecords": [
    {
      "licenseTypeCode": "psychologist",
      "regionCode": "US-NJ",
      "status": "active",
      "expiresAt": "2027-06-30",
      "verifiedAt": "2026-07-20T14:00:00Z"
    }
  ]
}

Evaluation logic

When licenseRegionCodes: { anyOf: ["US-NJ"] } is requested:

  1. Provider must have at least one active license for each required region
  2. License status must be active
  3. expiresAt must not be in the past
  4. License expiring within 30 days → passes but adds a warning
  5. verifiedAt missing or older than 1 year → treated as unknown
  6. No license records for the required region → treated as unknown

Evaluation states

| Condition | State | |---|---| | Active, non-expired, recently verified | matched | | Expired | failed (LICENSE_EXPIRED) | | Wrong region | failed (LICENSE_REGION_MISMATCH) | | No verification record | unknown | | No license records at all | unknown |

Insurance plan normalization

Platforms submit insurance plan codes in many formats. Orita normalizes common aliases to canonical codes before evaluation:

| Submitted | Canonical | |---|---| | "Blue Cross", "Anthem", "Highmark" | bcbs | | "United", "UnitedHealthcare", "Optum" | uhc | | "Evernorth" | cigna | | "Self pay", "cash", "out of pocket" | self_pay |

This means insurancePlanCodes: { anyOf: ["Blue Cross"] } will match a provider with ["bcbs"] in their profile.

Inspection

Exclusions include the required and actual values:

{
  "code": "INSURANCE_NOT_ACCEPTED",
  "field": "insurancePlanCodes",
  "required": ["aetna"],
  "actual": ["cigna"],
  "sourceStatus": "verified"
}

sourceStatus: "missing" indicates the provider has no insurance data at all.

Why AI agents must not infer eligibility

An AI agent must not infer insurance acceptance from provider descriptions, bios, or any unstructured text. Use only the structured insurancePlanCodes field.

If the field is empty, the evaluation state is unknown. The agent must surface this to the operator rather than assuming acceptance.

Related

Provider resolution infrastructure

Ready to build provider resolution into your application?

Import your provider network, apply eligibility rules, return explained options, and safely confirm the booking.

Get API Access

No credit card required · Free tier included