gBell is software that carries patient calls through scheduling, intake, system updates, and staff handoffs for clinics and hospitals. It is a software product, not an agency or a staffing service.

Small and mid-size medical and dental practices where the front desk is understaffed, and every missed call is a patient who books somewhere else or a no-show nobody confirmed.

Is gBell HIPAA compliant, and does it sign a BAA?

gBell operates as a business associate under HIPAA and signs a Business Associate Agreement with a practice before any patient information moves. The BAA governs how protected health information is handled and takes precedence over the standard terms of service. A vendor claiming its terms of service already cover HIPAA is not describing how the law works.

Yes. The agent states at the start of every call that the caller is speaking with an automated assistant and that the call is recorded. A practice can adjust the wording and the voice but cannot remove the disclosure or move it later in the call. If a caller asks not to be recorded, the agent offers to take a message or transfer to a person. Several states, California among them, require every party to a confidential conversation to consent before it is recorded.

Does gBell use patient data to train AI models?

No. Protected health information is not used to train, fine-tune, or evaluate any AI model, and agreements with model providers prohibit them from doing so with data gBell sends. Where a provider offers zero data retention it is enabled. Where a provider retains data briefly for abuse monitoring, that retention is covered by a business associate agreement and the data is still not used for training.

What happens if a caller has an emergency?

The agent is instructed to tell a caller describing an emergency to hang up and call 911, and to flag the call to staff at the highest priority. gBell is not an emergency service, cannot dispatch help, and must not be relied on as a triage mechanism. A practice remains responsible for an emergency plan that does not depend on the service being available or correct.

What happens when a call needs a human?

The call escalates to staff, who receive the transcript and a patient summary before they pick up rather than after. Practices configure when, how, and to whom calls escalate.

Can patients book without calling?

Yes. gBell provides an embeddable self-scheduling widget a practice can place on its own website, and patients who booked by phone can reschedule or cancel through a link sent to them.

How does gBell protect patient information in emails and text messages?

Patient-identifying detail is not placed in email or SMS message bodies. Those messages carry a link, and the patient verifies with a one-time passcode before anything is shown, so a forwarded message or an unlocked phone does not expose someone’s appointment.

Does gBell verify insurance?

Yes. gBell sends a 270 eligibility request, reads the payer’s 271 response, explains the returned coverage and benefits, and routes missing detail to the next action.

Does gBell post EOBs and ERAs?

Yes. gBell Payment Posting matches an EOB or ERA to the right claim lines, applies approved posting rules, and reconciles the remittance to its check or EFT before clean work reaches the practice system.

Does gBell include a clinical scribe?

Yes. gBell Scribe turns post-visit clinician dictation into a case-specific draft with exact source quotes, uncertainty review, clinician approval, and export.

Does a practice keep its own phone number?

Yes. Practices keep their own number, their own calendar, and their own tone. The agent answers in the practice’s name, not the vendor’s.

Insurance & eligibility · August 2026 · 6 min read

Eligibility checks vs prior authorization: what clinics mix up

Two different questions get collapsed into the word "verification," and the collapse costs practices real money in both directions: staff run prior auths that were never required, and visits happen on coverage nobody confirmed. The two questions have different answers, different timelines, and completely different plumbing.

An eligibility check asks: does this person have active insurance, and what do they pay for a normal visit? Prior authorization asks: will the payer approve this specific expensive service before it happens? The first is about the patient. The second is about the service.

Eligibility: a 30-cent question answered in seconds

The eligibility check runs on a standardized rail, the 270/271 transaction, that HIPAA requires every payer to support electronically. Your system sends a 270 with the clinic's NPI and the patient's member ID and date of birth; the payer answers with a 271: coverage active or terminated, plan name, copay, deductible remaining, whether a referral is required. Under CAQH CORE operating rules, real-time responses come back within 20 seconds, and in practice usually in a few.

It applies to essentially every encounter. A routine office visit, a follow-up, a sick visit: all of it should sit on a verified eligibility check, because coverage churns constantly as people change jobs and plans lapse. Cost is trivial, a few tenths of a dollar through a clearinghouse API, which is why the right frequency is "every appointment," not "when someone remembers."

Prior authorization: a per-service application decided in days

Prior auth exists for the expensive stuff: advanced imaging, surgeries, specialty drugs, some referrals to specialists under managed plans. The payer wants clinical justification before agreeing to pay, so someone at the practice submits documentation, medical necessity notes, sometimes peer-to-peer review, and waits. Days is normal. There is no clean universal electronic rail the way there is for eligibility; the work lives in payer portals, faxes, and phone queues, which is exactly why an entire venture-funded software category exists to automate it.

Note what prior auth is not: it isn't a coverage check. A prior auth can be approved for a patient whose policy terminates before the procedure, and an active policy doesn't imply a service is approved. The two checks answer different risks, and a clean revenue cycle runs both where each applies.

Side by side

The questionEligibility: is this person covered, and what do they owe? Prior auth: will you approve this specific service?

Applies toEligibility: every visit. Prior auth: a defined list of services per plan, mostly imaging, procedures, and specialty drugs.

SpeedEligibility: seconds, real time, mandated. Prior auth: days, sometimes longer, with appeals when denied.

PlumbingEligibility: standardized 270/271 through any clearinghouse. Prior auth: payer portals, faxes, phone calls, and a growing pile of automation startups.

Cost to runEligibility: cents per check. Prior auth: staff hours per request, which is the entire problem.

Who needs to care at bookingEligibility: the front desk, on every booking. Prior auth: the clinical and billing team, triggered by what was ordered, not by the appointment existing.

Where the confusion bites

A patient books a routine visit and staff, hearing "verify insurance," go hunting for an authorization requirement that doesn't exist for office visits. Time burned, nothing gained.

A patient's MRI gets a dutiful prior auth, but nobody re-checks eligibility before the scan date, the policy lapsed on the 1st, and the approved procedure is billed to dead coverage. Denied, and the auth was irrelevant.

A referral-required HMO plan surfaces in the 271, nobody reads the flag, and the specialist visit is denied even though coverage was active and no prior auth was needed. The eligibility check contained the warning; it just wasn't acted on.

The operating rule that falls out of all this: eligibility is a booking-time, every-time check, cheap enough to automate completely. Prior auth is an order-time, sometimes check, expensive enough that it deserves dedicated workflow. Systems that blur them do neither well.

What no appointment ever needs

Nobody prior-authorizes an appointment. If your front desk's booking flow ever blocks on "authorization," something is mislabeled. The booking flow's insurance job is eligibility: active coverage, copay, deductible, referral flag, all knowable in seconds while the patient is still on the phone. That's the check we built into gBell's booking flow design, and it's the reason this distinction matters to us enough to write up.

Common questions

Does a regular office visit need prior authorization?

Under almost all plans, no. Routine and sick visits need active coverage, and under some HMO plans a referral for specialists, but not prior authorization. Prior auth attaches to specific costly services defined in the plan's rules: imaging, procedures, specialty medications.

Can an eligibility check tell me if a service needs prior auth?

Partially. A 271 response can carry service-level detail including some authorization-required indicators, but the reliable source is the payer's own auth requirement lists for the specific CPT code. Treat the 271 as a flag to investigate, not a clearance.

How fast is each?

Eligibility is real time: CAQH CORE rules require payers to answer 270/271 inquiries within 20 seconds, and typical responses come in a few. Prior authorization is measured in days, because a human or an algorithm at the payer reviews clinical documentation before answering.

gBell

gBell is the AI operations layer for medical practices. Calls answered and booked, reminders run, after-hours covered, and the intake and insurance work behind the phone carried. It's the product these notes come from.

See how it works

Sources