Understanding medical coding: how a visit becomes a set of codes

A provider spends twelve minutes with a patient, types half a page of notes, and walks to the next room. Somewhere downstream, that half page becomes three or four codes that decide what the visit is worth and whether the payer agrees to pay it. The person doing that turning is a medical coder, and the job leans on reading far more than most newcomers expect.

That's the part that surprises people. You don't sit down and recall from memory that a mid-level established-patient office visit is 99213. You read what the provider documented, work out what actually happened in the room, and then go find the code that matches, checking it against rules you don't keep in your head. Coding is translation, and like any translation the hard part is staying faithful to a source you didn't write.

The note is the only thing that's real

Everything a coder does starts from the documentation, and one rule sits under all the others: if it isn't written down, it didn't happen. The note is both your source and your ceiling. You may code every detail the provider recorded, and you may not code a single detail they left out, however obvious it looks from where you're sitting.

That sounds like a technicality until you're staring at a line that reads "excised lesion, left forearm" with no size and no mention of whether it was benign or malignant. You can see the procedure plainly. You still can't code it, because the CPT code for a lesion excision changes with the size and with benign versus malignant, and guessing either one is how a coder quietly invents a claim. The right move isn't to reach for the most likely code. It's to query the provider and ask. New coders resist querying because it feels like admitting they can't do the work. Experienced coders query all the time, because the alternative is putting a number on the record that the chart won't back up the moment someone reviews it.

So the first real skill of coding isn't lookup at all. It's reading a clinical note closely enough to know exactly what it does and doesn't say, then having the discipline to code only the part that's actually there.

Three books, one encounter

A single visit usually needs codes from more than one system, and learning which book answers which question is most of the early climb.

CPT codes say what was done: the office visit, the chest X-ray, the biopsy. ICD-10-CM codes say why it was done: the low back pain, the diabetes, the fall that brought the patient in. HCPCS Level II picks up what CPT leaves on the floor, mostly drugs, supplies, and equipment, like the injectable that got administered or the crutches the patient took home. Each one is its own small world with its own logic, and I've written a separate walk-through of CPT, ICD-10-CM, and HCPCS Level II if you want the mechanics of a given book. What ties them together is the encounter, because a real visit rarely stays inside one of them.

Take a patient with diabetes who comes in for a foot ulcer and leaves with a fresh dressing. The visit itself is a CPT E/M code. The ulcer and the diabetes are ICD-10-CM codes, and ICD-10-CM wants them linked, not floating separately, because the diabetes and the ulcer are treated as one connected story rather than two coincidences. The dressing supply may be HCPCS. Miss any of the three and the claim is incomplete. Assemble them in the wrong relationship and it comes back denied.

That relationship is the piece beginners underestimate. The codes aren't a list you gather independently and staple together. The diagnosis has to justify the procedure, or the payer reads a service with no documented reason for it and declines. A coder isn't filling three separate boxes. They're building one internally consistent account of a visit.

Abstraction: reading a note the way a coder does

The actual process of turning a note into codes has a name coders use: abstraction. It's a repeatable order of operations, and running it the same way every time is what keeps you from missing things under pressure.

You read the whole note first, start to finish, before touching a manual. The temptation is to grab the first codeable thing you see and start looking it up, and that's how coders miss the second procedure buried in the last paragraph. Then you pull out the billable services, the things that map to CPT and HCPCS. Then the diagnoses, everything the provider treated or that affected the care, which become your ICD-10-CM codes. Only then do you match them, making sure each service is tied to a reason that supports it. That order matters because it forces you to see the visit whole before you start pricing its parts.

None of this is fast at first. It gets faster the way sight-reading music gets faster, by doing it enough that the pattern arrives before the effort does. What never goes away is the reading. A coder who stops reading carefully and starts pattern-matching on the first few words is the coder whose error rate climbs the moment the notes get complicated.

The guidelines decide, not the index

Here's the thing that took me a while to accept early on: finding a code in the book is the easy half. The index will hand you a candidate in seconds. Whether that candidate is actually right is a separate question, and it's answered by the guidelines, not the index.

Every code set carries instructions. CPT opens each section with rules and buries parenthetical notes under individual codes telling you what's bundled and what to report instead. ICD-10-CM has its official guidelines plus the notes in the Tabular List that overrule a tempting Index entry. The index gets you to the neighborhood. The guidelines tell you which house, and on any exam or audit the wrong answer is usually the code you'd have picked if you stopped reading at the index. This is also why coding being "open book" helps less than people hope. The book only speeds you up once you know where its rules hide, which is a trained skill rather than a lookup, and it's a big part of why I keep telling students to prep their code books properly instead of trusting they'll find things on the fly.

Specificity is what gets the claim paid

Payers keep tightening what they'll accept, and unspecified codes are the first thing they push back on. If the note says the fracture is in the left radius, coding it as an unspecified side leaves documented detail on the table, and increasingly the payer treats that missing detail as a reason to deny. Coding to the highest specificity the documentation supports isn't perfectionism. It's the line between paid and denied, which I've gone into separately in why claims get denied.

That ceiling rule comes straight back here, though. You code to the highest specificity the note supports, and not one notch higher. If the provider didn't record the laterality, the answer is a query, not your best guess. Specificity and honesty pull in the same direction: the most defensible code is the most specific one the documentation will actually stand behind.

Where the codes go next

A coder's work doesn't end the visit; it starts the next stage. Those codes get handed to the billing side, attached to charges, assembled into a claim, and sent to the payer, and everything that happens to them there is the subject of how medical billing actually works. Both desks share one pipeline even when they're different people in different rooms, which is exactly why billing and coding get taught together despite being distinct jobs.

Knowing that downstream path changes how you code. A "clean claim rate," the share of claims that go through on the first try, is a coding number as much as a billing one, because most denials trace back to a coding decision made weeks earlier. A coder who understands what a payer does with their work codes to full specificity and queries the provider instead of guessing. Those habits look like extra caution on a slow afternoon. They look like the whole job the first time you watch a sloppy claim come back unpaid.

Once the process clicks, the intimidation fades. Medical coding is a disciplined reading of a note, translated faithfully into the code sets and checked against the rules that govern them. Our study guide and exam simulator is built to drill exactly that sequence: 700 exam-style questions with a written rationale behind every answer, and 7 full-length timed mocks, so the abstraction workflow becomes automatic well before it counts on exam day.