Billing & Coding

Where the clinical record meets the claim — code capture, documentation sufficiency, and the gap between what was done and what gets billed for it.

Placeholder — not yet written

This page is a deliberate stub. It exists so the concept has a home and a link from the demo hub; the frame below is scaffolding for the real write-up. No coding logic, no rules, and no figures have been decided, and nothing here is wired to an engine.

What this is for

The problem shape

Two failure directions, and they pull against each other. Under-coding leaves work uncompensated because the documentation does not support what was actually done. Over-coding is a compliance exposure. Both are usually documentation problems rather than intent problems — the encounter happened, the note did not carry the evidence.

The interesting question is whether the supporting evidence can be surfaced at the point of documentation, while the clinician still remembers the visit, instead of reconstructed weeks later by a coder working from an incomplete note.

Frame

Pieces this would touch

PieceStatusNote
Code reference dataNEWThe CPT / HCPCS / ICD-10 sets in scope, and their update cadence. Versioned, never hand-maintained.
Documentation sufficiencyNEWDoes the note actually support the code — the core check, and the hard one.
Setting mismatchNEWCodes valid in one place of service and not another; a known recurring class of error.
Clinician-facing surfaceEXTENDSuggestions at documentation time, never silent auto-application.
Audit trailNEWEvery suggestion, acceptance, and override recorded — non-negotiable for anything touching a claim.

Design constraints

Non-negotiable
  • Never auto-submit a code. The system proposes; a human attests. A billing surface that acts on its own is a compliance liability, not a feature.
  • Never invent a code or a modifier. Every suggestion traces to reference data and to specific text in the note. An unsupported suggestion is worse than none.
  • Show the evidence inline. A suggestion the clinician cannot check in one glance will be accepted blindly, which is the failure mode this is supposed to prevent.
  • Bias toward under-suggesting. A missed suggestion costs revenue; a wrong one accepted costs far more.

Open questions

Needs a decision before this page becomes real
  • Scope: outpatient E/M only, or procedures and remote monitoring too?
  • Where does it live — inside the note surface, or as a separate reconciliation queue?
  • Who is the user: the clinician at documentation time, or a coder downstream? The two want very different products.
  • What is the source of truth for code reference data, and who owns keeping it current?
  • What accuracy bar has to be cleared before a suggestion is shown at all?

Deliberately not here

No specific codes, no dollar figures, no worked billing examples. Concrete codes on a placeholder page get read as guidance and repeated, and an incorrect one carries real regulatory consequence. Those land once the scope and the reference-data owner are settled.

Concept placeholder · not a product · not wired to any engine · no PHI · not billing, coding, or compliance advice. Created 2026-07-24 as a stub to be filled in.