> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getsolum.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Automatic Eligibility Checks
> Run eligibility checks automatically when a patient enters an insurance verification stage
# 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](https://app.getsolum.com/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](#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
| Behavior | Detail |
| ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Recent equivalent checks are skipped** | A service-type group is skipped only when all its requested codes were already covered for the same patient, eligibility payer, and normalized Member ID during the previous 24 hours. |
| **Existing verification work is protected** | The eligibility result is saved, but matching is skipped when applying it would overwrite verification work already in progress or completed on the payor. |
| **Only definitive results are matched** | Active and Inactive results can be matched. Pending and Failed results are saved without changing the payor. |
| **Provider ambiguity skips only the affected payor** | A per-insurance NPI override can still allow one payor to run even when the company-wide Entity NPI selection is ambiguous. |
| **Invalid Member IDs are skipped** | A Member ID with no letters or digits after normalization is treated as missing. Other eligible payors continue. |
| **A failure on one payor does not stop the others** | Payor-specific lookup, eligibility-network, or matching failures are isolated so later payors can continue. |
| **Service types affect recheck behavior** | A recent check for one discipline does not suppress a new check for a different discipline. |
The [manual eligibility check](/guides/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
| Symptom | Likely cause | Resolution |
| ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| No check appears | Automatic eligibility is disabled | Check the status under **Settings → Eligibility** and contact your Solum administrator if it needs to be enabled. |
| No check appears | The stage does not include **Verify Insurance**, or the patient left during the delay | Check the stage actions and leave the patient in the stage for at least 90 seconds. |
| No check appears | An equivalent check was made during the previous 24 hours | Expected—wait for the window to pass or run a manual check. |
| No check appears | The payor is inactive, lacks a responsibility tier or Member ID, or its insurance has no Eligibility Payer | Complete the payor and insurance configuration, then re-enter the stage. |
| No check appears | No service type resolved | Configure payor services, set a company default under **Settings → Eligibility**, or add service types to an active referral. |
| No check appears for one payor | No provider NPI resolved for that payor | Configure a unique/default Entity NPI or enable **Use this NPI for automatic checks** on the appropriate credentialing-insurance link. |
| A check appears but is not attached to the payor | The result is Pending/Failed, or matching would overwrite existing verification work | Review the saved check and the payor's current verification state. |
| The wrong service type was used | A higher-priority rule supplied the code | Review the eligibility-payer override, payor services, company default, and active referral disciplines in that order. |