AI Adoption GuideHealthcareAccess
Real-time eligibility verification
ML queries payer APIs against patient demographics at booking and flags coverage gaps before the appointment is confirmed, using tools like Waystar or AKASA.
Healthcare processAccessIntakeAssessDiagnoseTreatDischargeBillFollowup
By Don, DoneThat’s AI coach · updated
Lock demographics before the payer query
Query the payer only after name, date of birth, member ID, and subscriber relationship are locked on the booking record. If those fields are still changing, do not send the request. A response against a draft name or a transposed member ID looks like an official eligibility result and is simply the answer to the wrong person.
The check belongs at booking, before the appointment is confirmed. Freeze the demographics for this attempt, call the payer eligibility API or the clearinghouse in front of it, and wait for a structured payload. Waystar, AKASA, Epic, and athenahealth all sit in this class of access and clearinghouse tools: they send the identity you supplied and return the fields the payer chose to send. They cannot repair a bad lock.
Lock means the registrar or the scheduling workflow has accepted the values for this attempt. A typed member ID that has not been read back to the patient is not locked. A card scan that did not pass a character check is not locked. Put the four fields on the eligibility panel in a read-only state for the duration of the call, with a clear action to unlock and query again if the patient corrects something.
If a conversational scheduling agent collects a correction after the query is already in flight, cancel that check and start a new one with the corrected values. Do not merge a live edit with a response that was built on the previous identity. That mix is a common source of coverage flags that are actually mismatches.
The registrar confirms the lock. If the member ID is missing, do not reuse one from a prior visit unless the patient has confirmed it for this date of service. Send no query until identity is complete, and leave eligibility empty in the meantime.
Cite the payer field on every coverage-gap flag
A usable flag names the payer response field that triggered it and the demographic values that were queried. Without those two cites, do not write coverage gap onto the worklist. Staff cannot verify a claim that has no field and no identity.
Write the flag so a registrar can read it once and know what to look at next. One pass might look like this: Active coverage not returned. Payer field: planStatus = inactive. Queried on member ID XYZ8891, date of birth 1984-03-12, relationship self. That sentence is enough to call the payer, ask the patient for a current card, or keep the visit and document the gap. The model does not choose among those options.
If the payload says the patient is eligible and a specific benefit line is absent, cite that benefit field and stop. Do not infer a dollar amount. Do not copy copay, deductible remaining, or coinsurance from a neighboring plan, a household member, or last year's visit. An insurance benefits explainer can later explain the fields the payer actually returned. It must not mint a number the eligibility payload never contained.
Keep this check apart from autonomous prior authorization. Eligibility answers whether a plan is active for this identity on this date of service. Authorization is a different payer question. If you fold both into one blocked state, a coverage flag starts to look like a denial.
Keep eligibility empty when the payer is silent
If the payer times out, returns an unstructured error, or sends a payload with no coverage indicator, do not invent a gap. Leave eligibility status, copay, and remaining deductible blank. Put a work-queue note that the check did not complete, with the timestamp and the payer or clearinghouse error code when one exists.
A gap with no payer field is the first failure mode. Silence is not a lapse. It is the absence of a cite. Staff who treat a timeout as inactive coverage cancel visits that were covered, or they tell patients the plan denied them when the payer never spoke.
Do not backfill from an older eligibility snapshot unless clinic policy says that snapshot is still valid for this date of service, and you show the snapshot date next to every reused value. Even then, do not present an old copay as current if the new response has no copay field. The copay on the visit stays blank.
Patients who need language support can use a multilingual patient navigation agent to supply a corrected member ID or a card image. That agent still must not type a copay into a blank field.
Confirm the appointment after you read the flag
A registrar still confirms the visit. The flag is a prompt to look, not a cancellation rule, and not a denial.
If the flag cites an inactive plan, the registrar verifies with the patient and, when needed, the payer, then keeps the appointment, converts it to self-pay, or reschedules. A missing secondary does not, by itself, cancel a visit. If the only issue is a blank because the payer was silent, the registrar can confirm the slot, retry the check, and document that eligibility is unverified.
Treating the flag as a denial is the second failure mode. Auto-canceling on any red icon teaches patients that the computer denied them, and they never reach a person who can read the cite. Inventing a copay so the estimate looks complete is the third. That figure gets quoted, posted, and disputed. If the payer did not return a copay field, say that plainly: copay not returned by payer, confirm at check-in.
Here is the path in miniature. A new patient requests a Tuesday new-patient slot. Demographics lock. The eligibility response includes planStatus = active and no copay field. The worklist shows active coverage, cites planStatus, cites the member ID and date of birth that were sent, and leaves copay blank. The registrar confirms Tuesday, tells the patient that a copay was not on the payer response, and does not key a habitual amount because that is what this plan usually charges.
Store the query, the flag, and the confirmation together
The visit record should hold four things in one place: the locked demographics used for the query, the stored payer or clearinghouse fields, the flag text with cites, and the registrar's confirmation or override. If any of those four is missing, do not describe the visit as eligibility-verified.
Retry next to that record, not in a hidden loop. A silent payer can be retried after a short wait or after a new member ID. A cited inactive plan should not be re-queried on a timer without a demographic change; you already have a cite. A cited active plan with a blank copay should not be retried only to fish for a number.
Downstream staff inherit this record. Blank eligibility means unverified, not uninsured. A cited gap is read by field name before anyone talks to the patient. That is the quality bar: a flag a registrar can defend, blanks that stay blank, and a visit a person still confirms.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first