dental-billing-mcp Architecture

An MCP server that reviews dental claim notes against the description of the billing code submitted — to catch mismatches, thin documentation, and likely-wrong codes before claims leave the office. Deploys on-premises inside a practice's LAN; PMS and clearinghouse systems remain untouched.

System topology

universal template · covers ~95% of US dental practice stacks
Biller / Coder
workstation · browser
  • reviews queued claims
  • fixes notes in PMS
Practice Management (PMS)
chart notes · codes · 837D export
  • Dentrix · Eaglesoft · Open Dental
  • Curve · CareStack · ABELDent
  • EagleSoft · SoftDent · PracticeWorks
Imaging Systems
x-rays · pano · 3D
  • DEXIS · Schick · Carestream
  • Planmeca · Vatech · i-CAT
Front-Desk / Intake
patient demographics · insurance
  • eligibility & benefits check (pre-visit)
  • feeds the PMS claim record
Local Web UI
localhost · no internet
  • paste-or-queue interface
  • renders verdict cards
dental-billing-mcp (MCP Server Core)
Python · FastMCP · localhost:8765
Rule Engine
  • keyword & regex
  • code→phrase map
  • deterministic
Code Matcher
  • tooth # parse
  • surface detect
  • quadrant logic
LLM Client
  • gated by BAA flag
  • temp=0, cached
  • fallback only
CDT Reference
SQLite · static
  • code numbers
  • paraphrased text
Audit Log DB
SQLite · append-only
  • signed verdicts
  • timestamp · user
Anthropic API
Claude Haiku / Sonnet
  • only if BAA enabled
  • ~$0.003/claim
  • prompt caching 90%
Clearinghouses
837D · 835 ERA · 270/271
  • DentalXChange · ClaimConnect
  • Change Healthcare · Vyne
  • Tesia · EDI Health Group
Payer Networks
adjudication · EOB
  • Delta Dental · Cigna · Aetna
  • MetLife · Guardian · Humana
  • UnitedHealthcare · BCBS
  • State Medicaid · CHIP · VA
Eligibility Networks
real-time 270/271
  • Pearly · Zuub · Vyne Trellis
  • called at patient check-in
Denial Review (future)
v1.2 roadmap
  • 835 ERA inbound
  • explain → fix → resubmit
dental-billing-mcp component connection overlay Arrows showing the pre-submission claim review data flow, with PMS reads (muted), user entry (blue), internal service calls (green), external LLM calls (orange dashed, gated), and the submission rail crossing the plane boundary (orange). read demographics · eligibility paste / queue verdict lookup append LLM fallback · BAA gated suggest fix (to biller) 837D batch (PHI) ERA · remit 835 ERA 270/271 835 denial feedback (v1.2)

Component details

dental-billing-mcp core

  • Stateless review service exposing an MCP tool set: review_claim, lookup_code, compare_batch.
  • Rule engine runs first. Most common miscodings (metal-type on PFM crowns, tooth-number mismatches, prophy vs SRP confusion) are caught by regex + keyword patterns — no LLM needed.
  • LLM fallback only when rules return low confidence. Gated by a ENABLE_LLM flag that requires a countersigned BAA on file.
  • Ships as Docker container + one-line installer; runs on existing office workstation or a $5 mini-PC.

CDT Reference & Audit Log

  • CDT Reference: SQLite file with code numbers + paraphrased descriptions + rule hints per code. Updated annually (CDT 2026, 2027, etc).
  • Audit Log: SQLite append-only table. Every verdict written once, never updated. Schema: verdict_id · claim_ref · code · rule_hits · llm_used · user · ts · sig.
  • HMAC signature per verdict so the log is tamper-evident — becomes the practice's defensible good-faith record during payer audits.
  • No patient PII stored — claim reference ID only. The biller's PMS is the system of record.

Biller & Local Web UI

  • Web UI is localhost only. No internet-facing route; not reachable from outside the office LAN.
  • Three entry modes: (1) single-claim paste, (2) CSV / 837D batch, (3) PMS integration where available (Open Dental first, Dentrix Connected API roadmap).
  • Verdict cards show match / gap / wrong-code with one-click "copy to clipboard" so the biller can paste the suggested note addition back into the PMS.

Anthropic API (LLM fallback)

  • Models: Haiku 4.5 for routine, Sonnet 4.6 for ambiguous — ~70/30 mix in practice.
  • System prompt + CDT context cached (5-min TTL) → 90% discount on repeated input tokens.
  • Temperature 0 + fixed seeding where supported → deterministic verdicts for the same input.
  • Outbound firewall egress rule limits connections to api.anthropic.com only.
  • Fully off-switch. Rule-based path is fully functional without any LLM connectivity — offline mode.

PMS integration surface

  • Tier 1 (Open Dental): public API. Full read access, writes disabled in v1.
  • Tier 2 (CareStack, Curve): REST APIs available under partner agreement.
  • Tier 3 (Dentrix, Eaglesoft): closed. Fallback to CSV export of the claim queue or 837D file drop. Partnership path exists via Henry Schein One but takes 6-12 months.
  • Tier 4 (SoftDent, PracticeWorks, ABELDent): legacy. 837D or screen-scrape only.

Submission rail (untouched)

  • The PMS → Clearinghouse → Payer path keeps running exactly as today. We do not replace, proxy, or instrument this flow.
  • Clearinghouses we're aware of: DentalXChange, ClaimConnect (NEA Powered), Change Healthcare (Optum), Vyne, Tesia, EDI Health Group.
  • Payer diversity is the hardest part of this domain — Delta Dental alone has 39 state entities with different adjudication rules. The tool is payer-agnostic; rules are keyed off CDT code, not insurer.

Risks & mitigations

HIPAA / PHI exposure

Risk
Claim notes contain PHI. Any network egress creates a BAA obligation. Wrong move here = $50K/occurrence OCR fines + malpractice exposure for the practice.
Mitigation
Rule-based path is fully local — no egress. LLM path is off by default; enabling requires (a) signed Anthropic BAA, (b) office countersignature, (c) env flag + runtime check. Telemetry never contains PHI — only counters (claims reviewed, rule hits, LLM calls).

CDT licensing (ADA IP)

Risk
The American Dental Association owns CDT codes and their descriptions. Shipping verbatim descriptions = copyright infringement. ADA has historically pursued license enforcement.
Mitigation
Ship paraphrased descriptions + code numbers only. Add an optional "licensed lookup" plugin for practices with CDT licenses that fetches verbatim text from ADA's authorized distribution (CDT Code on Demand). Legal review before shipping v1.

PMS vendor lock-in

Risk
Dentrix (Henry Schein One) has ~35% market share and is closed. If we require PMS API access, we're locked out of the majority of practices.
Mitigation
Launch with paste-in + CSV + 837D file drop — works universally. PMS integration is a v2 optimization, not a v1 requirement. Target Open Dental first (open API, fastest-growing).

Clearinghouse dependency

Risk
If we moved into the submission rail, Change Healthcare outage (like Feb 2024) would take our customers offline.
Mitigation
We sit pre-submission only. Zero dependency on clearinghouse uptime. If a clearinghouse goes down, our verdicts still work; claims just queue in the PMS as they do today.

LLM non-determinism

Risk
Two identical claim notes getting two different verdicts undermines the audit log's defensibility.
Mitigation
Temperature 0 + cached system prompt + pinned model version. Rule-based verdict is primary; LLM only augments with confidence < threshold. Deterministic test corpus in CI; any drift fails the build.

Audit / clawback exposure

Risk
If a payer audit finds miscoded claims, the practice owes the payer back plus interest. Tool could (a) miss an error and leave exposure, (b) be used as grounds to dispute the practice's good-faith coding.
Mitigation
Immutable signed audit log turns our tool into the practice's best defense: we recommended X, biller accepted, here's the timestamp + signature. Terms of service scope us to "advisory" — the biller is always in the loop. Practice retains final judgment.

Gaps & unknowns

Known gaps in this design

  • Medical cross-coding (CPT/ICD): not modeled. Sleep apnea, TMJ, accident-related dental often bill medical. Out of v1 scope.
  • Orthodontic phased billing: initial + monthly installment coding is unique and not yet ruled.
  • OMS / oral surgery: higher reimbursement, more complex documentation. Needs specialist rule set.
  • Provider documentation capture: we assume the dentist's chart note already exists. Voice-to-note (dragon, abridge) is out of scope.
  • Attachments (NEA FastAttach): radiographs, perio charts, narratives required for many codes. Roadmap v1.1.

Open questions to resolve

  • First customer profile — solo general practice, 2-5 location group, or billing service? Shapes integration priorities.
  • CDT data source — paraphrased ship-with vs. ADA licensed lookup. Legal review needed.
  • Open Dental API coverage — sufficient for v1 or does the file-drop path need to ship first?
  • Multi-doctor practices — whose signature goes on the audit log? Practice owner vs. billing coordinator.
  • International (Canada) — CDN codes overlap CDT ~80%. Might be a wedge market with lighter HIPAA equivalent (PIPEDA / PHIPA).

intentsolutions.io  ·  Privacy Policy  ·  Terms of Service  ·  Acceptable Use  ·  dental-billing-mcp v0.2.0-draft · generated 2026-04-24