Insurance eligibility verification that finishes before the patient arrives.

The phone call is replaced by an electronic transaction that most payers are required to support. In practice, tomorrow's schedule is checked overnight and your staff arrive to a short list of exceptions instead of a full day of calls. Being straight about the limit: where a payer returns thin benefit detail, or the answer is ambiguous for the specific service, somebody still picks up the phone — the calls that remain are the ones that genuinely needed a human.

They are the standardized pair that carries an eligibility check. The 270 is the inquiry you send; the 271 is the payer's response, carrying coverage status, plan dates, copays, deductibles, out-of-pocket maximums and plan limitations. Both are HIPAA-mandated for covered entities at version 005010X279A1. Worth knowing where that stops: workers' comp, auto and liability medical payers are generally not HIPAA covered entities and are not obliged to support 270/271 at all — if they are a meaningful share of your mix, those stay manual.

No. Eligibility asks whether coverage exists — is the plan active, what does it cover, what will the patient owe. That is the 270/271 pair, and it is largely automatable. Prior authorization asks whether the payer will approve this specific service — that is a different transaction, the 278, a different workflow, and a much harder automation problem. A patient can be fully eligible and still be denied for lack of authorization.

There is a federal floor most vendor pages skip: the CAQH CORE operating rules require a 271 to return patient financial responsibility for a defined set of high-volume service types, alongside real-time response and defined error reporting. So the floor is mandated and everything above it is not — outside those defined service types, what comes back varies by the payer's own systems and data quality. That is why per-payer response mapping is real work rather than a configuration screen.

It depends which one. On the dental side, Open Dental is a delivered, documented connection — the eligibility work described in the proof section runs against it in production. Denticon, Dentrix and Dentrix Ascend are not connections we hold, and we have said so in writing rather than implying otherwise. The eligibility transaction is the same everywhere, so the only variable is the write path into your system.

Yes, and for a platform that is usually the right shape. We build the transaction layer, the per-payer mapping and the write path underneath your interface and return structured results through your API. The one thing worth planning for: your cost scales with the number of payers your customers bill, not the number of customers you sign.

Mostly automation. What gets marketed as insurance verification AI is usually this pipeline with a model doing two specific jobs: reading a payer response that does not follow a predictable shape, and deciding whether a thin answer is good enough to pass. The eligibility transaction itself involves no intelligence at all. The question worth asking any vendor is not how good the model is — it is which payers they have actually mapped, and what happens on the ones they have not.

Custom, and on this workflow more of it is already standing than on most. The real-time check, the scheduled and on-demand triggers, patient-side capture and batch verification all run on connections we already hold. What gets built for you is the per-payer response parsing, the mapping into your system's fields, and the exception queue your staff work. What stays yours is the rule about what counts as verified.