Eligibility checking—the process of determining whether a patient’s insurance will cover a particular medical program or procedure and what their out-of-pocket cost will be—remains one of the most frustrating, expensive, and opaque aspects of modern healthcare. This is especially painful for small and mid-sized practices, who lack the financial resources and IT staff of large health systems, but are expected to compete on the same playing field.Multiple clients have come to me asking the same thing: how can we perform eligibility checks at scale, accurately, and without spending a fortune on per-transaction APIs? I built a solution that delivers exactly that.
Today, many providers rely on third-party eligibility APIs that cost anywhere from $0.75 to $4.00 per patient. These reports are often incomplete, vary wildly in formatting depending on the payer, and are so confusing that most billing staff still end up picking up the phone to call the insurance company directly. That’s not a technology solution—it’s a symptom of a system designed to be hard to navigate.For clinics launching RPM, CCM, or RTM programs, the challenge is even greater. You might want to check eligibility on 10,000 patients to see who qualifies. But paying $2 per check when only 8% of your panel might be eligible is economically impossible. Worse, you can’t just guess or rely on black-box scoring. These are real patients, and they deserve real answers.
I didn’t build this for the megasystems that already have data science teams and robotic automation. I built this for the small, independent practices that actually do the hard work of delivering care but are forced to operate with tools that were never designed for them.I believe these clinics deserve technology that works just as well—if not better—than what large hospitals use. That belief drives everything I build.
Conventional AI systems—especially LLM-based ones—aren’t a good fit for eligibility. There are thousands of insurers, each with dozens or hundreds of plans, all of which change yearly. You can’t train a general-purpose model to know every possible combination, and even if you could, it would be a black box. That’s unacceptable.In eligibility checking, every "yes" or "no" must come with a "why."
I built a deterministic, explainable system using Buffaly and our ontology engine to solve eligibility at scale.Here’s how it works:
Before implementation, a billing specialist might manually check 100 patients a day, identifying maybe 7–10 eligible candidates. After deployment, clients can process tens of thousands of patients in under a minute.In one rollout, a team that previously relied on spreadsheets and PDFs was able to identify 300 high-probability RPM candidates in a morning—with zero API cost and complete traceability.
Eligibility is full of nuance. Diagnosis codes, age thresholds, payer quirks—it’s not just a lookup problem. I use ontologies because they let me build a structured, expressive model of the real world that scales. I don’t need to retrain a model every year. I just update the rules.The key is precision. I don’t need to guess what a payer might do. I need to know what it has done—and why—so I can model it explicitly. That’s how I keep things transparent, explainable, and defensible.
Eligibility is full of nuance. Diagnosis codes, age thresholds, payer quirks—it’s not just a lookup problem. I use ontologies because they let me build a structured, expressive model of the real world that scales. I don’t need to retrain a model every year. I just update the rules.The key is precision. I don’t need to guess what a payer might do. I need to know what it has done—and why—so I can model it explicitly. That’s how I keep things transparent, explainable, and defensible.
