Building an NLP Pipeline for Medical Coding: CDT/CPT Extraction, Cross-Coding, and Payer Rules

The Medical Coding Challenge at Scale

Medical coding is the translation between clinical documentation and billing. Every diagnosis maps to an ICD-10 code, every procedure to a CPT or CDT code, and every combination must be linked and modified to satisfy payer-specific requirements. The taxonomy is large: ICD-10-CM has 72,000+ diagnosis codes, CPT has 10,000+ procedure codes, CDT has 882 dental codes. The rules governing valid combinations change with annual code set updates, quarterly payer bulletins, and local coverage determinations. It is a domain where the complexity is in the rules, not the algorithms.

The practice we worked with employed 24 certified coders who manually reviewed clinical notes, assigned codes, and validated claims. Despite their expertise, first-pass claim acceptance was around 71%, meaning nearly 30% of claims needed rework. Average coding time was over 8 minutes per encounter, and the team had a 6-week backlog that delayed claim submission. The goal was to build an AI-assisted coding system that could suggest codes from clinical notes and validate them against payer rules, letting coders review and approve rather than code from scratch.

This was explicitly not a "replace the coders" project. The target was the 80% of encounters that follow standard patterns, where AI suggestion plus one-click coder approval is faster and more consistent than manual coding. The remaining 20% of complex cases still need human expertise, and that is where the coders should be spending their time.

NLP Architecture for Clinical Note Understanding

Clinical notes are free-text narratives that vary enormously across physicians. One dentist writes "extracted #32 due to periapical abscess" while another writes "surgically removed lower right third molar, chronic infection at root apex with purulent drainage." Both describe the same procedure and should map to the same code, but the NLP system needs to handle both phrasings and the spectrum in between. This variability is the fundamental challenge.

The Language Model

We fine-tuned a 350M parameter encoder model on de-identified clinical notes spanning dental, primary care, and specialty medicine. The base model was pre-trained on biomedical literature, which gave it medical vocabulary. Fine-tuning on actual clinical notes (rather than published literature) was important because clinical documentation uses abbreviations, shorthand, and colloquialisms that do not appear in journal articles. "Pt c/o SOB x 3 days" is common in notes but would never appear in PubMed.

The model performs four tasks through multi-task learning: entity recognition (procedures, diagnoses, anatomical sites, modifiers), relation extraction (linking procedures to their sites and indications), negation detection (distinguishing "rule out pneumonia" from "confirmed pneumonia"), and temporal classification (current vs. historical vs. planned). Multi-task learning was the right choice here because these tasks share features. A model that understands negation is better at entity recognition because it can disambiguate entities in negated contexts.

Entity-Level Performance

On a held-out test set of 50,000 annotated clinical note segments:

• Procedure identification: 97.2% F1 score. Procedures tend to be stated explicitly in notes, which makes this the easiest entity type.
• Diagnosis extraction: 95.8% F1. Harder because diagnoses are sometimes implicit ("swelling at the gumline" rather than "gingival abscess").
• Anatomical site linking: 96.1% accuracy linking procedures to specific teeth, body regions, or structures.
• Negation detection: 98.4% accuracy. Critical because a negated finding that gets coded as present is a billing error and a clinical error.
• Overall: 96.7% weighted average. We set 95% as the minimum threshold for clinical deployment. The model clears it, but the remaining ~3% of errors still need human review, which is why the system augments rather than replaces coders.

CDT/CPT Code Suggestion Engine

Extracting clinical entities is half the problem. The other half is mapping those entities to the correct billing code from the appropriate code set. This is not a lookup table. The CDT and CPT code sets have hierarchical structure, and choosing the right code requires evaluating qualifying factors that may be scattered across the clinical note.

Hierarchical Code Selection

We built a hierarchical classification model that mirrors how expert coders think. Step one: identify the code family (extractions, endodontics, preventive, etc.). Step two: within the family, narrow to the specific code based on qualifying factors. For dental extractions, the model evaluates whether the extraction was simple or surgical, whether bone removal was required, whether the tooth was erupted or impacted, and the impaction classification. Each decision point is a separate classifier trained on examples specific to that branch.

This hierarchical approach outperforms flat multi-class classification (predicting 882 CDT codes or 10,000+ CPT codes directly) because it decomposes a hard problem into a series of easier problems. For CDT, top-1 accuracy is 93.4% and top-3 accuracy is 98.7%. For CPT, which has a larger and more complex code space, top-1 is 89.1% and top-3 is 96.2%. Presenting the top 3 options is important: it lets coders confirm the correct code with a click rather than searching the entire code set, which was the main time sink in the manual workflow.

Modifier Selection and Evidence Linking

Modifiers are two-character codes appended to procedures that affect reimbursement. Missing or incorrect modifiers are a top-three denial cause. The system suggests modifiers based on clinical context: bilateral procedure gets modifier 50, distinct procedural service gets modifier 59, and so on. We handle 47 commonly used modifiers with about 95% suggestion accuracy.

Each code suggestion is linked to the specific text in the clinical note that supports it. This evidence linking serves two purposes. First, it lets coders quickly verify suggestions by reading the supporting documentation rather than re-reading the entire note. Second, it creates an audit trail that demonstrates medical necessity for every coded procedure. This traceability is valuable during payer audits, where the question is always "what documentation supports this code?"

Cross-Coding Validation and Compliance

The dual dental-medical practice created a specific optimization opportunity: many procedures can be coded under either CDT or CPT, and the reimbursement depends on the patient's insurance structure. A procedure reimbursed at $150 under dental benefits might yield $800 under medical if the clinical indication supports it. Choosing the wrong path is not a compliance issue (both codes are legitimate), but it leaves money on the table.

Dual-Path Evaluation

For every encounter with a valid cross-coding path, the system evaluates both options. It considers remaining dental benefits, medical deductible status, contracted rates for each code, the payer's historical acceptance rate for each path, and the documentation requirements for medical necessity. Both options are presented to the coder with estimated reimbursement and a confidence score for acceptance. The coder makes the final decision.

In practice, a meaningful number of encounters have a higher-reimbursement alternative path. Not all are actionable because some require additional clinical documentation that the treating physician needs to provide. The system queues documentation requests to physicians with specific guidance on what information is needed, which keeps the process moving without burdening the coder with follow-up.

Bundling and Unbundling Validation

Bundling rules determine when multiple procedures should be reported under a single comprehensive code versus separately. Incorrect unbundling (billing component parts of a bundled procedure separately) is a compliance risk and a common audit trigger. Our validation engine checks every code combination against CMS National Correct Coding Initiative (NCCI) edits, the ADA's CDT guidance, and payer-specific bundling rules. The validation is conservative by design: it flags potential bundling issues for human review rather than auto-resolving them, because bundling decisions sometimes require clinical judgment about whether procedures were truly distinct.

• Cross-coding mappings: 342 validated CDT-to-CPT relationships covering oral surgery, TMJ, sleep medicine, and oral pathology.
• Bundling validation: Thousands of potential unbundling issues caught before submission. This is the compliance feature that payer auditors care about most.
• NCCI edit compliance: All code pairs validated against current NCCI edits, updated within 24 hours of quarterly CMS releases.
• Modifier pair validation: Incorrect modifier combinations caught and flagged. Some modifier combinations are never valid; others are valid only in specific clinical contexts.

Building the Compliance Rules Engine

Medical coding compliance is governed by federal regulations, state laws, payer contracts, and professional guidelines, all of which change at different cadences. The rules engine evaluates every code assignment against a large rule set drawn from CMS guidelines, OIG workplan focus areas, payer-specific policies, and the practice's own compliance policies.

Rule Categories and Enforcement Levels

Rules are categorized into three enforcement levels. Hard stops block claim submission until resolved. These cover clear violations: unbundling, upcoding beyond documentation support, coding for undocumented services. Soft stops generate warnings that coders must acknowledge. These cover potential issues that may be legitimate but warrant review: unusual code combinations, high-complexity E/M codes, atypical modifier usage. Advisory rules provide informational guidance: documentation improvement suggestions, alternative coding options, upcoming rule changes.

The rule definition format is declarative JSON: trigger condition, evaluation logic, enforcement level, and remediation guidance. Non-technical compliance staff can create advisory rules through a web interface. Coding specialists handle soft and hard stop rules. This separation is important because regulatory changes come faster than software release cycles, and the compliance team needs to update rules without waiting for a developer.

Provider-Level Pattern Monitoring

Beyond individual claim validation, the system tracks provider-level coding patterns over time. It monitors for statistical anomalies that payer auditors look for: code distributions that differ significantly from specialty peers, unusual modifier usage patterns, outlier rates of high-complexity E/M codes, and charge amounts that deviate from expected ranges. When a provider's pattern drifts outside normal bounds, the system alerts the compliance officer and generates a focused review queue. The goal is to identify and address patterns before a payer does.

• Rule count: Over 12,000 compliance rules across three enforcement levels. The maintenance burden is real and requires dedicated staff to keep rules current.
• Update cadence: Rules updated within 72 hours of regulatory changes. Annual code set updates require the largest batch of rule modifications.
• Hard stop effectiveness: All compliance-critical violations caught before submission in production.
• OIG alignment: Automatic rule generation for OIG workplan focus areas, which change annually and represent the highest audit risk categories.

Integration and Deployment Strategy

The system integrates with the practice's EHR systems through direct API connections and embedded widgets. The design goal was zero additional clicks in the coder's workflow: suggestions appear automatically when a clinical note is completed, and approval is a single click.

EHR Integration

For the dental side (Open Dental), we built a plugin that fires on clinical note completion. When a dentist signs a note, the plugin sends the text to the coding API, which returns suggestions in under 2 seconds. Suggestions appear in a panel alongside the standard coding interface with confidence scores, supporting note text, and compliance flags. For the medical side (Athena), we used the Marketplace API to embed the coding widget in the charge capture workflow. Both integrations had to respect the existing UX patterns of each system, which required different UI approaches for the same underlying functionality.

Phased Deployment

We deployed in three phases. Phase 1 (shadow mode, 4 weeks): the model generated suggestions but coders did not see them. We compared AI output to human coding decisions to measure baseline accuracy and identify gaps. Phase 2 (assist mode, 8 weeks): suggestions were shown as non-binding recommendations. Every accept/reject decision was logged for model refinement. Phase 3 (production mode, ongoing): suggestions became the default starting point, with coders reviewing and approving.

This phased approach mattered. During Phase 1, we found 14 specialty-specific accuracy gaps that would have eroded coder trust if they had been exposed in the first week. During Phase 2, coder feedback drove 2,400 corrections that improved accuracy by several percentage points. By Phase 3, coders had seen enough correct suggestions to trust the system, and adoption happened quickly. Skipping the shadow and assist phases would have been faster but would likely have resulted in lower adoption and more pushback.

• API response time: Under 2 seconds from note submission to code suggestions, including NLP processing and compliance validation.
• Availability: 99.95% uptime over 12 months, with graceful degradation to manual coding during downtime.
• Adoption: 96% of coders using AI suggestions as their primary workflow within two weeks of Phase 3 launch.
• Model updates: Weekly retraining incorporating coder feedback, with A/B testing of model updates before production deployment.

Outcomes and What We Learned

After 12 months processing over a million encounters, here are the measurable outcomes and the lessons behind them.

Accuracy and Throughput

• First-pass acceptance: Improved from 71% to 94%. The improvement came from more consistent coding (the system applies every rule to every claim) and better modifier selection.
• Coding accuracy: Clinically significant error rate dropped from 3.7% to 0.4%. The AI system is more consistent than human coders on routine encounters but less capable on genuinely ambiguous cases.
• Suggestion acceptance: Coders accepted 87% of suggestions without modification, modified 9%, and rejected 4%. The 4% rejection rate is our best signal for where the model needs improvement.
• Coding time: Dropped from over 8 minutes to about 2 minutes per encounter. The 6-week backlog was cleared within 60 days.

What Mattered Most

Cross-coding optimization generated meaningful additional revenue from encounters that were already being performed but billed suboptimally. The denial rate reduction saved rework costs and accelerated cash flow. The coding staff reduction through natural attrition reduced labor costs. But the single largest impact was throughput: eliminating the coding backlog meant claims were submitted days after the encounter instead of weeks, which compressed the entire accounts receivable timeline.

The nature of the coding role changed. Coders went from manual code assignment on every encounter to exception-based review. They spend their time on the 13% of encounters where the AI suggestion needs modification or rejection, which are the complex and ambiguous cases that benefit from human expertise. This is more engaging work and requires more skill, which improved retention.

The key engineering lesson: the accuracy of the NLP model matters less than the accuracy of the compliance rules engine. A wrong code suggestion that gets caught by the compliance layer and flagged for coder review is harmless. A correct code suggestion that violates a bundling rule and passes validation is a compliance risk. We invested more engineering time in the rules engine than in the NLP model, and that was the right allocation.