Black-Eyed Susan

A Small-Model RAG Assistant for Dental Insurance & Cost Transparency

1. The Problem

Dental front-desk teams spend a large share of their day answering the same handful of questions: "Is this procedure covered?" "What will I owe out of pocket?" "What does code D2740 mean?" "Do I need pre-authorization for this?"Answering correctly requires cross-referencing the patient's plan documents, the practice's fee schedule, and CDT procedure codes — tedious, repetitive, and low-ambiguity work that nonetheless eats staff time and creates a steady stream of billing surprises for patients.

This is exactly the kind of task that doesn't need a frontier model. It's narrow, document-grounded, easy to validate against source material, and low-risk when a human stays in the loop for anything unusual. That makes it a good fit for a small model wired into a retrieval pipeline rather than a large, expensive one reasoning from scratch.

Black-Eyed Susan is a packaged product built around that idea: a small-model RAG assistant that answers patient benefit and cost-estimate questions by grounding every response in the practice's actual plan documents and fee schedules, with automatic escalation to staff whenever confidence is low or the question touches something more complex than a lookup.

2. Scope of the Task

Black-Eyed Susan is deliberately narrow. It handles:

• Explaining what a CDT procedure code covers in plain language
• Checking whether a specific procedure is covered under a patient's plan, based on the practice's ingested payer policy documents
• Producing a good-faith out-of-pocket cost estimate from the practice's fee schedule and the patient's benefit summary
• Flagging when pre-authorization or a waiting period applies, based on policy text
• Citing the specific plan document and section its answer came from

It explicitly does not:

• Submit claims, file appeals, or make any binding coverage determination
• Handle disputes, denials, or anything requiring judgment calls
• Give clinical or treatment advice

Anything outside that scope is routed to a staff member automatically. This boundary is what keeps a small model appropriate here — the task is real but bounded, and the cost of an occasional wrong answer is caught by both a confidence check and a human escalation path rather than left to the model's judgment alone.

3. Architecture

Patient question (portal / kiosk / SMS)
        │
        ▼
Query embedding
        │
        ▼
Vector search over practice knowledge base
  (fee schedule, CDT code library, payer policy PDFs,
   patient's own benefit summary)
        │
        ▼
Top-k relevant chunks + query → small model
        │
        ▼
Structured answer generation
  (answer, cited source, confidence score, escalation flag)
        │
        ├── High confidence, in-scope  → shown to patient directly
        └── Low confidence / out-of-scope → routed to front-desk queue

Components

Escalation logic (illustrative)

if (
    confidence < 0.85
    or retrieval_score < 0.70
    or question_category not in SUPPORTED_CATEGORIES
    or mentions_dispute_or_denial(question)
):
    route_to_staff_queue()
else:
    return_answer_to_patient()

This mirrors the general principle that a small model earns its place by staying inside a well-defined lane, with clear, automatic handoff the moment a question steps outside it.

4. Implementation Timeline & Cost

These figures are illustrative estimates for a first packaged version, not audited financials — they're meant to show the kind of cost profile this architecture produces.

Build cost (one-time)

Ongoing cost (per practice, monthly, at typical volume of ~1,500 patient queries/month)

For comparison, running the same volume through a frontier model for full generation (rather than a small model over retrieved context) was estimated at roughly 6–8x the inference cost with no measurable accuracy gain on this task — the answers are already grounded in retrieved documents, so the model's job is synthesis and phrasing, not open-ended reasoning. That gap is the core economic argument for the small-model choice here.

5. Packaging & Availability

Black-Eyed Susan is packaged as a standalone product for dental practices and small DSOs (dental service organizations), sold as:

• Setup fee: one-time onboarding and knowledge-base ingestion, scoped to the practice's payer mix and fee schedule
• Monthly subscription: per-location pricing that covers inference, hosting, and ongoing knowledge-base refresh
• Optional add-on: SMS/text-based patient intake in addition to the portal widget

It's positioned as a lightweight, bolt-on tool rather than a platform replacement — it sits alongside existing practice-management software and reads from documents the practice already has, rather than requiring a new system of record.

6. Why a Small Model Fits Here

This product is a direct application of a broader principle: match model size to task risk and structure, not to reputation. The underlying task — explain a code, check a covered benefit, estimate a cost, cite the source — is repetitive, document-grounded, and easy to validate against the retrieved text. The risk that remains (an incorrect coverage statement) is handled by confidence thresholds and human escalation rather than by throwing more model capability at the problem. That combination is what makes the smaller model both cheaper and, in this specific lane, just as reliable.