Specialty groups, ambulatory networks, behavioral health, community hospitals, home health. Assumes an EHR, a practice management or billing system, and a clearinghouse that do not share identifiers cleanly.
No-show prediction and smart overbooking
In one line: Predicts which appointments will not happen, so the schedule can be filled instead of sitting empty.
Who uses it and when: the scheduler, the day before, on a short list of slots at high risk of a no-show instead of finding out at check-in time. It changes one decision: which slots get a reminder call or a backup booking.
What it does not do: it will not fill the slot itself. It flags which ones are at risk; the scheduler still decides what to do about it.
Usually needs work.
It depends on the appointment calendar, which already exists because the practice runs on it. The problem is that it is a live calendar, not a record: a cancelled slot gets overwritten by whatever replaces it, so the evidence of the no-show disappears the moment it happens. Nothing new has to be built. The calendar keeps every status change instead of overwriting it, and then enough weeks accumulate to predict from.
The pain: “We lose a chunk of every provider’s day to no-shows and we only know about it that morning.”
What it runs on
- One row per: one scheduled appointment slot. One patient, one provider, one slot. Cancelled and no-show appointments must stay as rows. The ones that did not happen are the training data.
- Described by: patient, provider, location, appointment type, payer, referral source, date and time of day, lead time from booking, scheduling channel, prior no-show count.
- Must agree across systems: patient, provider, and location. Provider identity is the usual troublemaker: the scheduling module, the EHR, and billing often carry three different provider IDs for the same person.
- History: you need history. Every status change with its timestamp: booked, rescheduled, confirmed, arrived, no-show. The path matters more than the endpoint.
Why it usually fails: the schedule is a live calendar, not a record. A cancelled appointment is overwritten by the one that replaced it, so the evidence of the no-show is deleted the moment it happens. You cannot predict from data the system throws away.
Claim denial prevention
In one line: Flags the claim that is going to be denied before it is submitted, with the reason, while it can still be fixed.
Who uses it and when: billing staff, before the claim goes out, on a flagged line with the likely denial reason attached instead of a rejection three weeks later. It changes one decision: whether that claim gets fixed now or filed as is.
What it does not do: it will not correct the claim. It flags which one and why; someone still has to fix it before it goes out.
Usually needs work.
It depends on claim lines that are already captured, one procedure per claim per encounter. Payer names are typed free-hand at registration, so the same payer appears a dozen different ways, and the remittance that says why a claim was denied lives at the clearinghouse and never gets tied back to the claim. Nothing new has to be built. Payer names get normalized to one list, and the remittance feed gets joined back to the claim it answers.
The pain: “We work denials for a living. Every one of them is a claim we already paid staff to file once.”
What it runs on
- One row per: one claim line. One procedure code on one claim on one encounter. Not one row per claim. A claim with six lines is six measurements, and denials happen at the line.
- Described by: patient, rendering provider, payer, specific plan, place of service, procedure, diagnosis, modifiers, date of service, date submitted, adjudication outcome, denial reason.
- Must agree across systems: payer and plan first, then provider, procedure code set, and location. A payer with forty plans behaves like forty payers, and rolling them together destroys the signal.
- History: you need history. Payer rules and fee schedules that applied on the date of service, and provider credentialing status at that date. Both change, and both drive denials.
Why it usually fails: payer names are typed free-hand at registration, so one payer appears fifteen ways and the per-payer denial rate is meaningless. The other half of the problem is that remittance data lives at the clearinghouse and never comes back to sit next to the claim that produced it, so nothing ever closes the loop.
Referral leakage visibility
In one line: Shows which referrals never got scheduled and which walked to a competitor, while there is still time to call the patient.
Who uses it and when: the referral coordinator, a set number of days after a referral goes out, on a short list of the ones never scheduled instead of silence. It changes one decision: whether to call the patient this week.
What it does not do: it will not schedule the visit. It shows which referrals went cold while there is still time to follow up.
Usually needs building.
It depends on referrals becoming data, and most of them do not: they arrive by fax and phone and never become data at all, so there is no denominator to measure leakage against. Where a referral is recorded, the referring provider is a typed name rather than an identity, and whether the patient was ever actually seen is never captured. Building a record that starts when a referral is sent and closes when the patient is seen is the project. The feature is what happens after it.
The pain: “We refer patients out and never find out whether they were seen, by us or by anyone.”
What it runs on
- One row per: one referral, carried through its life and updated as it advances. Sent, scheduled, seen, or dropped, with the date at each step. One row that gets updated in place, not a new row per step.
- Described by: patient, referring provider and their organization, receiving provider and specialty, payer, location, date sent, date scheduled, date seen.
- Must agree across systems: provider, specialty, and location. A referring provider has to be one identity whether the referral came in by fax, portal, or phone.
- History: the referral row itself is updated as it moves, so today’s picture works there. Provider affiliation is the exception: it needs history, because a physician who joined the group last quarter changes what counts as leakage.
Why it usually fails: referrals arrive by fax and phone and never become data at all, so there is no denominator. Where they are recorded, the referring provider is a typed name and the date the patient was actually seen is never captured, which means the funnel has a top and no bottom.