Skip to main content

​
Automatic Eligibility Checks

Automatic Eligibility Checks let Solum verify a patient’s coverage after the patient enters a workflow stage configured with the Verify Insurance action. For each payor that has enough information, Solum runs a real-time eligibility check and saves the result on the Eligibility Checks page. This feature is enabled per company and runs alongside the normal verification workflow. A verification task is still created; the automatic check supplies an early coverage result without replacing the rest of the workflow.

​
Configure automatic checks

  1. Go to Settings → Eligibility.
  2. Review the Automatic eligibility checks status.
  3. Under Default service type, select up to two service types for automatic checks.
  4. Save the settings.
Automatic-check enablement is managed by Solum because each check makes a paid eligibility-network request. The Eligibility settings page shows whether the feature is enabled and lets you configure its default service types. Contact your Solum administrator if the feature needs to be enabled or disabled.
The configured default is used before referral disciplines when a payor has no services of its own. Leaving the default empty allows referral disciplines to drive the checks. See How service types are selected.

​
Requirements

​
Workflow stage

The patient must enter a workflow stage whose actions include Verify Insurance. The stage change schedules both the verification task and the automatic eligibility run.

​
Provider NPI

Solum chooses a provider NPI separately for each payor:
  1. If an insurance is pinned to a credentialing record with Use this NPI for automatic checks, that NPI is used for the payor.
  2. Otherwise, Solum looks at active Entity credentialing records. It uses a unique state match, one NPI repeated across multiple locations, or the configured default Entity NPI—in that order.
  3. If several genuinely different NPIs remain ambiguous and there is no per-insurance or default selection, that payor is skipped.
For state matching, the patient’s state is used first. If it is blank, the state of the patient’s assigned location is used.

​
Payor

Each payor is evaluated independently. A payor is eligible for an automatic check when it:
  • Is active.
  • Has a responsibility tier: Primary, Secondary, Tertiary, or Quaternary.
  • Has a Member ID.
  • Belongs to an insurance with an Eligibility Payer selected.
  • Resolves to at least one service-type code, unless that eligibility payer is configured to require the general Health Benefit Plan Coverage code.
Member IDs are normalized before submission. Spaces and punctuation are removed, and payer-specific normalization is applied where required. If no letters or digits remain, the payor is skipped. Patient name and date of birth are included in the eligibility request when available. They are not a separate scheduling gate in the automatic-check service.

​
How service types are selected

Service-type resolution is performed per payor. It is not a simple first-non-empty fallback in every case:
  1. Eligibility-payer override. A small set of eligibility payers requires Health Benefit Plan Coverage (30). For those payers, code 30 is used regardless of payor services, company defaults, or referrals.
  2. Payor services. When the payor has services, their codes form one check, capped at two distinct codes. Any active-referral disciplines not already covered by that group are added as separate single-code checks. This prevents a previously verified discipline from hiding a newer referral discipline.
  3. Company default. When the payor has no services, the configured Default service type is used next, as one check capped at two distinct codes.
  4. Referral disciplines. When neither payor services nor a company default resolves, Solum uses every distinct service type across the patient’s active referrals. Each discipline becomes its own single-code check.
  5. No resolved code. If none of these rules produces a code, the payor is skipped. There is no general code-30 fallback for every payer.

​
How a run works

  1. The patient enters a stage configured with Verify Insurance.
  2. The verification task is scheduled using the normal stage-action delay.
  3. The automatic eligibility run waits approximately 90 seconds so recent insurance-card processing can finish. If the patient leaves the stage during that window, the run is cancelled.
  4. Solum finds eligible payors and resolves the provider NPI and service-type groups for each one.
  5. Solum skips a service-type group when the same patient, eligibility payer, normalized Member ID, and all requested codes were already checked within the previous 24 hours.
  6. Every new result is saved to Eligibility Checks and linked to the patient.
  7. Results with definitive Active or Inactive coverage are matched to the target payor when it is safe to do so. Pending or failed results remain available for review but are not matched.
The date of service is the current calendar date in the company’s configured timezone, falling back to UTC when the timezone is missing or invalid.

​
Safeguards and limitations

The manual eligibility check flow remains available for a different date of service or a one-off combination of service types.

​
Verify the setup

  1. Confirm the company shows automatic eligibility as Enabled under Settings → Eligibility.
  2. Confirm the target workflow stage includes the Verify Insurance action.
  3. Confirm the patient has an active payor with a responsibility tier, Member ID, and an insurance linked to an Eligibility Payer.
  4. Confirm the payor can resolve both a provider NPI and at least one service type using the rules above.
  5. Move the patient into the stage and wait about 90 seconds.
  6. Open Eligibility Checks and look for the new check. If it returned Active or Inactive coverage and matching was safe, open the patient to confirm the result was attached to the intended payor.
  7. Move the patient out of the stage and back in. An equivalent check should not be created again during the 24-hour recheck window.

​
Troubleshooting