Gather inputs
The original workflow combined patient data from an EMR with age, conditions, payer, history, claim-history context, and program requirements.
Result · greater eligibility-review capacity
Apply explicit eligibility rules across a large patient list without losing the reason path.
This historical case describes a rules-based workflow for prioritizing eligibility review across patient records—bringing payer, program, diagnosis, age, and history inputs into a structure that reviewers can inspect.
Business consequence
Repeated checks can make broad program screening too costly or slow to perform manually.
Eligibility work asks whether coverage applies to a program or procedure and what an out-of-pocket amount may be. For RPM, CCM, and RTM programs, the source describes teams reviewing payer, diagnosis, age, plan, and patient-history conditions across a broader panel.
The original case reports per-transaction API fees ranging from $0.75 to $4.00 and illustrates a 10,000-patient panel where only 8% might qualify. Those figures lack vendor, contract, date, payer mix, transaction definition, and independent validation, so they are context—not a savings guarantee.
Source-attributed historical result
The original case reports processing tens of thousands of patient records in under a minute.
Tens of thousandsthe scale described by the historical case report.
Under a minutethe reported elapsed time, without a published environment or measurement method.
Reason path retainedthe architecture attached rule inputs to a reviewable eligibility score.
The source does not provide the exact count, hardware, concurrency, dataset, start/stop definition, comparison baseline, period, sample, accuracy, completeness, eligibility correctness, independent validation, or customer identity. The report is not a throughput, latency, cost, or coverage guarantee.
Operating explanation
Replace repeated handoffs with a structured first-pass review.
Current workflow diagram labels
- Eligibility API with the separate label Costly
- Billing Staff with the separate label Manual Work
- Call to Payer
- Eligibility Decision
The case describes reports that vary by payer and may still require billing staff to interpret the result or call for clarification. That repeated work becomes more consequential when a practice wants to screen a broad panel before enrolling people in a program.
The aim was not to make a final coverage promise. It was to rank records for review and expose the conditions that contributed to that ranking.
A consistent rule path
Model the payer and program conditions explicitly, then keep a reviewer in the decision path.
Map the record
Represent those inputs in a healthcare ontology so differently shaped records can be evaluated against a common set of concepts.
Apply explicit rules
Rule trees model diagnosis codes, age thresholds, payer behavior, and program conditions rather than relying on an unexplained score alone.
Review the result
Rank records for review and retain the contributing rule path; human corrections can inform later rule refinements.
Eligibility model diagram key
- Patient data
- Eligibility ontology
- Rule-based models
The original case reports that Buffaly's Shadow framework represented rule-based eligibility patterns and that ontology-backed policy controls were used around LLM-assisted outputs. Those mechanisms are secondary to the operating result.
The source also reports a rollout that identified 300 high-probability RPM candidates in a morning and describes no per-transaction API fee in that workflow. It does not provide the panel size, threshold, review method, customer, infrastructure/labor cost, confirmation rate, or downstream enrollment outcome, so those claims are not used as proof of savings or correctness.
Technical reason to believe
Separate rule maintenance from record-by-record manual interpretation.
Ontologies supplied a structured vocabulary for diagnoses, age thresholds, payers, programs, and history. Buffaly represented rule trees and the path from source inputs to a ranked review result.
The architecture is designed to make rule changes inspectable, but the source does not independently establish deterministic behavior, complete explanations, audit readiness, eligibility accuracy, current deployment, data security, PHI handling, HIPAA compliance, certifications, or superiority.
Case authorMatt Furnari, CTO, Intelligence Factory
Talk to Us
Where does eligibility review constrain capacity?
Start with the program rules, available source data, review requirements, and the evidence needed before a coverage decision can be used.
Talk to Us