CodeBestie Foundations — Full Course (HFCM)

FOUNDATIONS COURSE

Your Learning Map

A guided system for building professional coding confidence through defensible thinking — not memorization.

Progress: 0%

Phase 1 • Orientation & Role Clarity

Lesson 1: What Medical Coding Actually Is

Purpose

This lesson builds a clear mental model of coding as translation + rules application. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Encounter—a visit or service where care is provided; Diagnosis—the condition(s) addressed during the encounter; Procedure/Service—the work performed (tests, treatments, evaluations); Guideline—the official rule that governs code selection/sequencing

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

If there are multiple plausible choices, decide by matching the documentation to the rule’s conditions. If a required element is missing, your path is to query the provider or select the best-supported alternative (depending on your setting’s policy).

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: A provider documents ‘shortness of breath, likely pneumonia; chest x‑ray ordered; started antibiotics.’

Apply CODE™:

Collect: Open the ICD-10-CM guideline section on uncertain diagnoses (inpatient vs outpatient) and the chapter notes for respiratory signs/symptoms vs confirmed conditions.

Observe: Identify whether the setting allows coding ‘likely’ as confirmed; note when symptoms are coded instead.

Decide: If outpatient/office, code the symptom and any confirmed diagnosis; if inpatient and criteria met, code the probable diagnosis per guideline.

Execute: Verify documentation supports the selection and document your decision trail.

Common Pitfalls to Avoid

Treating documentation as a code without checking rules.
Confusing signs/symptoms with confirmed conditions.
Skipping setting context (inpatient vs outpatient rule differences).
Not writing a defensible explanation for the chosen path.

Quick Checklist (use this every time)

☐ Identify encounter setting before applying any guideline.

☐ Locate the guideline section that governs certainty terms (probable, suspected, ruled out).

☐ Check chapter notes and excludes notes before finalizing.

☐ Write a one-sentence decision trail with the source location.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: When you’re unsure, treat the chart as an open-book problem. Identify what you need (the question), then locate where that answer lives (the source), then verify the rule, then document your decision path.

Depth Notes: Build a habit of writing a one-sentence justification for your choice. If you can’t justify it with a rule, a definition, or a referenced policy section, pause and re-check before committing.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Phase 1 • Orientation & Role Clarity

Lesson 2: What Coders Are Responsible For

Purpose

This lesson builds role clarity across quality, compliance, and communication. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Compliance—following laws, regulations, and official guidance; Medical Necessity—supporting why a service was reasonable/necessary based on documentation and policy; Query—a request for clarification when documentation is incomplete/unclear; Audit Trail—the record of how and why a decision was made

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: A note says ‘follow-up visit; meds adjusted; diabetes controlled.’ The claim denied for missing specificity.

Collect: Identify where specificity requirements are defined (ICD-10-CM conventions and the payer policy/denial reason).

Observe: Determine what specificity is required (type, manifestation, complications, control status) and whether documentation includes it.

Decide: If documentation lacks required specificity, prepare a compliant query; if sufficient, select the most specific supported code.

Execute: Document what was present, what was missing, and how you resolved it.

Common Pitfalls to Avoid

Trying to ‘fix’ documentation by guessing details.
Assuming denials mean the code is wrong (sometimes it’s policy or documentation).
Not using a standardized query approach.
Focusing on speed over defensible accuracy.

Quick Checklist (use this every time)

☐ Translate documentation into codes only when elements are supported.

☐ Use queries when required elements are missing.

☐ Separate ‘coding rules’ from ‘payer policy’—both matter.

☐ Keep an audit trail: what you saw, what rule you applied, what you chose.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Phase 1 • Orientation & Role Clarity

Lesson 3: Your CODE™ Workflow

Purpose

This lesson builds repeatable problem-solving under open-book conditions. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Collect—locate the right reference quickly; Observe—read the exact rule conditions and exceptions; Decide—choose the best-supported path; Execute—verify, document, and finalize

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: You’re unsure whether to code a symptom in addition to a definitive diagnosis.

Collect: Open ICD-10-CM guidelines for signs/symptoms and the chapter notes for the condition.

Observe: Identify whether the symptom is integral to the condition or separately reportable.

Decide: Choose to code separately only when guideline/notes indicate it is not integral or has special instructions.

Execute: Verify and document your decision trail.

Common Pitfalls to Avoid

Using memory alone instead of verification.
Reading only the code title and skipping notes.
Not recognizing ‘integral symptom’ logic.
Not reconciling guideline with payer edits/denials.

Quick Checklist (use this every time)

☐ Always open the guideline first when uncertain.

☐ Read all notes in the code range before final selection.

☐ Decide based on ‘integral vs separate’ instruction.

☐ Verify with a second check (index + tabular).

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 1 • Orientation & Role Clarity

Lesson 4: Confidence Without Guessing

Purpose

This lesson builds professional confidence built on verification and documentation. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Index—alphabetical lookup tool that points you to tabular codes; Tabular List—the authoritative, structured list with notes; Specificity—choosing the most detailed code supported; Defensibility—ability to justify decisions with sources

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: Index points you to a code, but the tabular notes show an exclusion.

Collect: Use index for initial direction, then open the tabular code and read notes.

Observe: Identify excludes, additional code instructions, and required characters.

Decide: If excluded, follow the note to the correct category.

Execute: Verify full code (characters, laterality, encounter) and finalize.

Common Pitfalls to Avoid

Stopping at the index and not verifying in tabular.
Ignoring excludes notes and additional code notes.
Selecting unspecified codes when specific documentation exists.
Not checking laterality/encounter requirements.

Quick Checklist (use this every time)

☐ Index → Tabular → Notes → Verify characters.

☐ Check excludes and ‘code first/additional code’ instructions.

☐ Use the most specific supported option.

☐ Record where you verified the rule.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 1 • Orientation & Role Clarity • Checkpoint

Checkpoint 1

Start with the interactive checkpoint. When you finish, open the Answer Key to compare your rationale.

Answer Key (compare after you submit)

Primary verification references: ICD-10-CM Official Guidelines for Coding and Reporting (uncertain diagnoses; signs/symptoms; documentation-supported coding).

Question 1 Multiple Choice

You are coding an outpatient visit note that states: “Patient with cough, likely pneumonia.” No imaging result is documented. What is the defensible diagnosis coding approach?

A) Code pneumonia as confirmed.
B) Code cough (symptom) and any confirmed diagnoses; do not code ‘likely’ pneumonia as confirmed in outpatient/office.
C) Do not code anything until imaging is done.
D) Code both cough and pneumonia always.

Correct Answer: B

Rationale: Outpatient/office settings generally do not code uncertain diagnoses (e.g., ‘likely,’ ‘probable’) as confirmed; you code signs/symptoms and confirmed conditions supported by documentation.

Cody Tip: If the note uses uncertainty words, your first question is: “What setting rule applies?” Verify before selecting.

Source to Verify: ICD-10-CM Official Guidelines — uncertain diagnoses (inpatient vs outpatient).

Question 2 Multiple Choice

In CODE™, what is the goal of the Observe step?

A) Pick a code quickly based on memory.
B) Read the exact rule conditions, definitions, and exceptions in the authoritative source.
C) Ask the provider for clarification immediately.
D) Write the claim and submit it.

Correct Answer: B

Rationale: Observe is where you extract what the rule actually says—definitions, scope, conditions, and exceptions—so your decision is defensible.

Cody Tip: Observation turns “I think” into “the rule states.” If you can’t point to the line, keep reading.

Source to Verify: Course method: CODE™ stages (Collect/Observe/Decide/Execute).

Question 3 Short Answer

Why is it not defensible to add diagnosis specificity that is not documented by the provider?

Correct Answer: Because coding must be based on provider documentation and official guidance; adding details not documented is fabrication and creates compliance/audit risk.

Rationale: Specificity must be supported by the medical record. If a required element is missing, the correct path is a compliant query or coding only what is supported (per policy).

Cody Tip: If it isn’t in the note, it isn’t yours to invent. Query or code what’s supported.

Source to Verify: Organization coding compliance policy; ICD-10-CM documentation-supported coding principles.

Question 4 True/False

Stopping at the ICD-10-CM Index is acceptable if the code title seems to match the diagnosis.

Correct Answer: False

Rationale: The Index is a finding tool; final code selection must be verified in the Tabular List, including notes, excludes, and required characters.

Cody Tip: Index is the map; Tabular is the law.

Source to Verify: ICD-10-CM conventions and general guidelines (Index vs Tabular).

Question 5 Multiple Choice

Which best describes a “decision trail”?

A) A list of codes without explanation.
B) A short justification linking documentation + rule source to your coding choice.
C) A copy of the entire chart note.
D) A denial appeal template used only after payment issues.

Correct Answer: B

Rationale: A decision trail documents how your choice is supported by documentation and authoritative guidance, improving QA defensibility.

Cody Tip: One sentence + one source location = confident coding.

Source to Verify: Course method; organization QA expectations.

Phase 2 • The Claim Ecosystem

Lesson 1: From Encounter to Claim: The Big Picture

Purpose

This lesson builds systems awareness of revenue cycle flow. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Charge capture—recording billable services from the encounter; Claim—the standardized request for payment; Clearinghouse—entity that routes/validates electronic claims; Remittance—payer response showing payment/adjustment/denial

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: A claim is rejected before adjudication due to missing patient identifier.

Collect: Review the rejection message and the claim format requirements.

Observe: Identify the exact field missing and whether it is a front-end validation issue vs medical necessity.

Decide: Correct the administrative field and re-submit; do not change clinical coding to fix a format rejection.

Execute: Re-validate and document the correction.

Common Pitfalls to Avoid

Treating rejections like denials and changing codes unnecessarily.
Not distinguishing administrative edits from clinical policy edits.
Failing to review the remittance codes and messages.
Skipping root-cause documentation.

Quick Checklist (use this every time)

☐ Classify the issue: rejection, denial, downcode, or adjustment.

☐ Match the message to the correct part of the lifecycle.

☐ Fix the smallest required item first.

☐ Document what changed and why.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 2 • The Claim Ecosystem

Lesson 2: Where Coding Fits: Documentation → Codes → Data

Purpose

This lesson builds clarity on coding’s downstream impact. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Data element—a coded item used for analytics/payment decisions; Edit—automated rule that checks for validity/consistency; Medical necessity—service must be reasonable/necessary per policy and documentation; Linkage—how diagnoses support services

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: A payer denies a diagnostic test for lack of medical necessity.

Collect: Read the denial message and locate the payer’s policy for the test.

Observe: Identify the covered indications and required documentation.

Decide: If documentation supports a covered indication, correct diagnosis linkage; if not, route for documentation review/query per policy.

Execute: Prepare an appeal packet with the relevant note excerpt and policy reference, or correct the claim and re-file as appropriate.

Common Pitfalls to Avoid

Assuming the test is ‘always covered.’
Linking vague diagnoses that don’t match policy indications.
Not including documentation excerpts in appeals.
Mixing coding errors with authorization errors.

Quick Checklist (use this every time)

☐ Read the payer policy for the service.

☐ Check diagnosis-service linkage against policy indications.

☐ Confirm documentation includes the indications.

☐ Appeal with documentation + policy reference when supported.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 2 • The Claim Ecosystem

Lesson 3: Common Claim Errors: How They Happen

Purpose

This lesson builds pattern recognition without oversimplifying. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

NPI—provider identifier used on claims; Modifiers—additional codes that clarify circumstances of a service; Timely filing—deadline to submit or resubmit claims; Coordination of benefits—rules when multiple payers exist

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: Claim paid less than expected due to missing modifier.

Collect: Compare the billed code set to the documented service and the payer’s modifier rules.

Observe: Determine whether the note supports the modifier circumstances.

Decide: If supported, submit a corrected claim; if unsupported, adjust internal charge capture and educate the team.

Execute: Verify corrected claim passes edits and document rationale for modifier use.

Common Pitfalls to Avoid

Adding modifiers to force payment without documentation support.
Ignoring timely filing windows.
Confusing patient responsibility vs payer denial.
Not reviewing EOB/RA adjustment codes.

Quick Checklist (use this every time)

☐ Modifier use must be supported by documentation.

☐ Check timely filing before choosing your action.

☐ Read adjustment reason codes carefully.

☐ Keep a correction log for recurring issues.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 2 • The Claim Ecosystem

Lesson 4: Denials & Troubleshooting: A Practical Workflow

Purpose

This lesson builds a repeatable denial-triage method. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

CARC/RARC—codes explaining claim adjustments/remarks; Appeal—formal request for reconsideration; Corrected claim—resubmission that replaces prior claim; Documentation support—note elements that justify coding/coverage

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: Denial for ‘insufficient documentation’.

Collect: Pull the denial reason (CARC/RARC), the payer policy, and the medical record.

Observe: Identify the missing element (history, exam detail, indication, interpretation, signature, etc.).

Decide: If the element exists, appeal with cited excerpt; if it doesn’t, follow your query/addendum policy.

Execute: Submit corrected claim or appeal with a clear decision trail.

Common Pitfalls to Avoid

Appealing without including the actual documentation excerpt.
Submitting a corrected claim when an appeal is required (or vice versa).
Not differentiating coding error vs documentation deficiency.
Not tracking denial trends.

Quick Checklist (use this every time)

☐ Start with the denial code/message (CARC/RARC).

☐ Pull the relevant payer policy and the exact note.

☐ Choose corrected claim vs appeal based on payer rule.

☐ Track denials by category to prevent repeats.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 2 • The Claim Ecosystem • Checkpoint

Checkpoint 2

Start with the interactive checkpoint. When you finish, open the Answer Key to compare your rationale.

Answer Key (compare after you submit)

Primary verification references: CMS Medicare Claims Processing Manual (Pub 100-04); payer remittance guidance (CARC/RARC); payer policies.

Question 1 Multiple Choice

A claim is rejected due to a missing required claim field (e.g., identifier/format requirement). What is the best first action?

A) Change the diagnosis codes to force the claim through.
B) Correct the missing administrative field and resubmit; keep clinical coding unchanged unless a separate coding error is confirmed.
C) File an appeal immediately.
D) Wait for the payer to request more records.

Correct Answer: B

Rationale: Rejections are often pre-adjudication format/EDI issues. Fixing the required field is the appropriate first step; changing clinical coding to solve a format issue is not defensible.

Cody Tip: Classify first: rejection vs denial. Fix the smallest required item first.

Source to Verify: Payer/clearinghouse EDI requirements; CMS claims processing resources.

Question 2 Short Answer

What do CARC/RARC codes on a remittance advice (RA/EOB) help you do?

Correct Answer: They explain why a line was paid/adjusted/denied and provide remarks guiding the next troubleshooting step (corrected claim vs appeal, documentation needs, etc.).

Rationale: These standardized codes are the payer’s structured explanation and are essential for denial triage and appeals/corrections.

Cody Tip: Never troubleshoot from memory—read the RA message codes and follow the breadcrumbs.

Source to Verify: Payer remittance advice documentation; X12 CARC/RARC code lists.

Question 3 Multiple Choice

Documentation supports a covered indication, but the diagnosis-to-service linkage on the claim was incorrect. What is typically the most appropriate action (payer rules permitting)?

A) Do nothing; it will auto-correct.
B) Submit a corrected claim with the supported diagnosis linkage (or follow payer correction process).
C) Appeal without changing anything.
D) Add a modifier to override coverage.

Correct Answer: B

Rationale: If the record supports coverage but linkage was wrong, correcting the claim to reflect the supported indication often resolves medical-necessity edits.

Cody Tip: If the note supports it, fix the linkage. If the note doesn’t, you can’t force coverage.

Source to Verify: Payer policy for the service; payer corrected claim rules; CMS Pub 100-04.

Question 4 True/False

A denial always means the code is wrong.

Correct Answer: False

Rationale: Denials can arise from authorization, documentation sufficiency, policy coverage limits, linkage issues, or administrative errors—not only coding selection.

Cody Tip: Denials are root-cause puzzles—separate coding rules from payer policy and admin edits.

Source to Verify: Payer denial guidance; CMS claims processing principles.

Question 5 Multiple Choice

Which is the best denial-triage sequence?

A) Guess the fix based on past experience, then resubmit.
B) Start with the denial reason/message → pull the policy → check the record → choose corrected claim vs appeal based on payer rules.
C) Appeal every denial to avoid rework.
D) Change multiple codes at once to increase chance of payment.

Correct Answer: B

Rationale: A consistent workflow reduces repeated errors and ensures the action matches payer requirements and filing windows.

Cody Tip: Root cause first, action second.

Source to Verify: Payer remittance guidance; payer appeal/correction rules.

Phase 3 • Understanding the Codebooks

Lesson 1: Why Multiple Code Sets Exist

Purpose

This lesson builds a structural understanding of code set roles and boundaries. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

ICD-10-CM—diagnosis classification used for reporting conditions; CPT—procedure/service codes (physician and outpatient reporting structure); HCPCS Level II—supplies, drugs, ambulance, and certain non-physician services; Code set governance—annual updates and rule authority

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: A chart includes a diagnosis, a procedure, and a supply.

Collect: Identify which code set answers each question: diagnosis = ICD-10-CM; procedure/service = CPT; supply/drug = HCPCS II.

Observe: Confirm in each code set’s intro what that code set is intended to represent.

Decide: Separate the coding tasks so you don’t force a diagnosis code to represent a procedure (or vice versa).

Execute: Verify each selection using that code set’s notes and rules.

Common Pitfalls to Avoid

Trying to code everything from one codebook.
Confusing diagnosis descriptions with procedure reporting.
Ignoring annual update timing and outdated references.
Skipping code set instructions and relying on titles.

Quick Checklist (use this every time)

☐ Identify the question: diagnosis vs service vs supply.

☐ Open the correct code set first.

☐ Verify with notes and instructions, not just titles.

☐ Confirm full code validity (characters, laterality, required info).

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 3 • Understanding the Codebooks

Lesson 2: Navigate Books Intentionally

Purpose

This lesson builds fast retrieval skills under open-book conditions. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Index—lookup tool for terms that points you to structured sections; Tabular—authoritative list with notes/conventions; Conventions—symbols/format rules that change meaning; Parenthetical note—instruction that guides selection/limitations

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: You find a code in the index but the tabular requires an additional character.

Collect: Use index to locate category, then open the tabular and read the instructional notes.

Observe: Identify required characters, placeholders, and laterality.

Decide: Choose the complete code that matches documentation.

Execute: Validate the code format and document where you confirmed the requirement.

Common Pitfalls to Avoid

Index-only coding.
Missing required 7th character or placeholder.
Overlooking laterality or episode-of-care requirements.
Not reading ‘code also’ or ‘use additional code’ instructions.

Quick Checklist (use this every time)

☐ Index → Tabular → Notes → Validate format.

☐ Check for required characters and placeholders.

☐ Confirm laterality/encounter/episode requirements.

☐ Record your verification source location.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 3 • Understanding the Codebooks

Lesson 3: Know Where to Verify

Purpose

This lesson builds source literacy and hierarchy. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Official guideline—primary authority for coding rules; Local policy—organization instructions that must align with official rules; Payer policy—coverage/payment rules that sit alongside coding rules; Hierarchy—which instruction governs when rules conflict

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: A local cheat sheet conflicts with an official guideline.

Collect: Pull the official guideline section and the local document.

Observe: Compare language and identify where the conflict occurs.

Decide: Follow the official guidance; escalate the local document for update.

Execute: Document that you verified the official source and note the escalation.

Common Pitfalls to Avoid

Treating unofficial summaries as authority.
Assuming payer policies change coding rules (they typically govern coverage, not classification).
Using outdated PDFs.
Not escalating conflicts in internal resources.

Quick Checklist (use this every time)

☐ Primary sources beat summaries.

☐ When unsure, read the official guideline/code instructions.

☐ Track version/date of any internal reference.

☐ Escalate conflicts to maintain compliance.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 3 • Understanding the Codebooks

Lesson 4: Apply CODE™ to Codebook Navigation

Purpose

This lesson builds making navigation a skill you can teach. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Term selection—choosing the right index term; Cross-reference—‘see’ and ‘see also’ index guidance; Notes-first mindset—instructional notes can change code choice; Verification loop—double-checking selection in authoritative list

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: Two index terms point to different categories.

Collect: Look up both terms, then open both tabular sections.

Observe: Compare definitions and inclusion terms.

Decide: Select the category that matches the documented condition/service precisely.

Execute: Verify excludes, additional code instructions, and completeness.

Common Pitfalls to Avoid

Picking the first match in the index.
Not following ‘see’ / ‘see also’ directions.
Skipping inclusion/exclusion terms.
Not validating complete code selection.

Quick Checklist (use this every time)

☐ Try multiple index terms when uncertain.

☐ Follow cross-references.

☐ Use inclusion/exclusion terms to match documentation.

☐ Complete the verification loop every time.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 3 • Understanding the Codebooks • Checkpoint

Checkpoint 3

Start with the interactive checkpoint. When you finish, open the Answer Key to compare your rationale.

Answer Key (compare after you submit)

Primary verification references: ICD-10-CM Official Guidelines (conventions); CPT section/range notes; HCPCS Level II introductory guidance.

Question 1 Multiple Choice

Which statement best describes the relationship between the Index and the authoritative list (Tabular/range instructions)?

A) The Index is authoritative; Tabular is optional.
B) The Index points you to a location, but the Tabular/range notes determine final code selection.
C) Either can be used alone interchangeably.
D) The Index is only for inpatient coding.

Correct Answer: B

Rationale: The Index is a finding tool; final selection must be validated in the authoritative list with notes and conventions.

Cody Tip: Index is the map; Tabular is the law.

Source to Verify: ICD-10-CM conventions and general guidelines (Index vs Tabular).

Question 2 Multiple Choice

A code requires an additional character (e.g., laterality or encounter). What must you do?

A) Submit the shortest code to avoid errors.
B) Select the complete code with all required characters supported by documentation; use placeholders if instructed.
C) Use an unspecified code even if details are documented.
D) Skip the code and bill only procedures.

Correct Answer: B

Rationale: Required characters are part of the code definition. Incomplete codes are not defensible and often fail edits.

Cody Tip: If the code isn’t complete, it isn’t a code yet.

Source to Verify: ICD-10-CM conventions (placeholders/required characters); Tabular notes.

Question 3 True/False

When a local cheat sheet conflicts with an official guideline, the official guideline should govern.

Correct Answer: True

Rationale: Primary sources are authoritative; internal summaries must align with official guidance. Conflicts should be escalated for correction.

Cody Tip: A rule without an official source is a rumor—verify and escalate.

Source to Verify: ICD-10-CM Official Guidelines; organization compliance expectations.

Question 4 Multiple Choice

A chart includes a diagnosis, a procedure, and a supply/drug. Which code sets typically address these three questions?

A) CPT for all three.
B) ICD-10-CM for diagnosis; CPT for procedure/service; HCPCS Level II for supplies/drugs (as applicable).
C) HCPCS Level II for diagnosis; ICD-10-CM for procedures.
D) ICD-10-CM for everything outpatient.

Correct Answer: B

Rationale: Each code set has a defined purpose; matching the question to the correct code set prevents forced, inaccurate coding.

Cody Tip: First decide what you’re coding: diagnosis vs service vs supply.

Source to Verify: Code set introductory guidance; ICD-10-CM/CPT/HCPCS purpose statements.

Question 5 Short Answer

What is the verification loop you should follow before finalizing a code found in the Index?

Correct Answer: Index → open the Tabular/range location → read notes/instructions (includes/excludes, code first/additional code, required characters) → validate completeness and documentation support.

Rationale: This process ensures selection matches authoritative rules and the code is complete and defensible.

Cody Tip: Map it, prove it, then code it.

Source to Verify: ICD-10-CM conventions/guidelines; CPT/HCPCS instructions as applicable.

Phase 4 • Reading Medical Documentation

Lesson 1: Identify Relevant Documentation

Purpose

This lesson builds finding signal in a busy chart. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Chief complaint—why the patient is being seen; Assessment/Plan—provider’s clinical conclusions and next steps; ROS/PE—supporting context; may or may not change coding; Diagnostic results—objective findings that may confirm conditions

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: A long note includes extensive history, but only one condition was assessed/managed.

Collect: Identify the section where the provider states assessment and plan.

Observe: Determine what was addressed vs merely listed as past history.

Decide: Code conditions that were evaluated/treated/managed as supported by documentation and setting rules.

Execute: Verify you can cite the note section supporting each coded item.

Common Pitfalls to Avoid

Coding every condition listed in the problem list without evidence it was addressed.
Missing objective results that confirm or refute a diagnosis.
Using template text as if it were unique clinical information.
Ignoring the assessment/plan because it’s shorter than the rest of the note.

Quick Checklist (use this every time)

☐ Start with Assessment/Plan.

☐ Confirm the condition was addressed (evaluated/treated/managed).

☐ Look for results that confirm the assessment.

☐ Cite the exact documentation location for each code.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 4 • Reading Medical Documentation

Lesson 2: Know Authority + Hierarchy

Purpose

This lesson builds understanding which documentation sources govern which decisions. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Attestation—statement verifying who performed/documented work; Author—the provider responsible for the note content; Signature—authentication element for many settings; Scope—what a given provider type may document for coding purposes in your policy

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: A diagnosis appears in a nursing note but not in the provider assessment.

Collect: Review your setting’s policy on acceptable documentation sources and the provider note.

Observe: Identify whether the provider confirms/adopts the diagnosis.

Decide: Code diagnoses based on acceptable authoritative documentation per policy and guidelines.

Execute: If needed, query for confirmation or ensure documentation reflects provider attribution.

Common Pitfalls to Avoid

Assuming any chart mention equals a reportable diagnosis.
Ignoring authentication/signature requirements.
Not distinguishing history vs current condition.
Failing to reconcile conflicting documentation.

Quick Checklist (use this every time)

☐ Confirm who documented the diagnosis and where.

☐ Check if the provider adopts/confirms it (per policy).

☐ Verify authentication when required.

☐ Resolve conflicts via query/escalation per policy.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 4 • Reading Medical Documentation

Lesson 3: Apply Collect & Observe Before Coding

Purpose

This lesson builds front-loading accuracy by reading with purpose. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Indication—why a test/service was performed; Severity—how advanced the condition is, when documented; Laterality—left/right/bilateral, when applicable; Temporal status—acute/chronic/history of, when documented

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: Imaging is ordered for pain; results show a definitive finding.

Collect: Identify the indication (reason for study) and the result.

Observe: Determine what is confirmed vs suspected and whether both are reportable in your setting.

Decide: Code the confirmed condition and any separately reportable symptoms as instructed by guidelines/notes.

Execute: Verify laterality/acuity and document the supporting lines.

Common Pitfalls to Avoid

Coding suspected findings as confirmed when not allowed by setting rules.
Ignoring laterality in documentation when required.
Failing to distinguish active vs history of conditions.
Not connecting the test indication to medical necessity.

Quick Checklist (use this every time)

☐ Identify indication + result.

☐ Determine confirmed vs suspected per setting rule.

☐ Check laterality/acuity/history wording.

☐ Document support lines and guideline reference.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 4 • Reading Medical Documentation

Lesson 4: Documentation-to-Code Mapping

Purpose

This lesson builds turning narrative into structured choices. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Clinical concept—the underlying condition/service behind the words; Documentation element—a required detail (site, type, cause, etc.); Query trigger—a missing or conflicting required element; Decision trail—your written justification

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: The note states ‘kidney disease’ without stage.

Collect: Find the guideline/convention requiring stage when documented and your query policy.

Observe: Confirm whether a stage is present elsewhere (labs, problem list, nephrology note) and whether it is acceptable per policy.

Decide: If not present in acceptable documentation, query for stage or code as supported.

Execute: Record your decision trail and any query action.

Common Pitfalls to Avoid

Assuming a stage from labs without policy support.
Using unspecified automatically without checking other documentation sections.
Failing to query when required for specificity.
Not documenting how you reached your decision.

Quick Checklist (use this every time)

☐ List required elements for the concept.

☐ Search the note for those elements in acceptable sources.

☐ Query if a required element is missing/conflicting.

☐ Write a decision trail with documentation + guideline cite.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 4 • Reading Medical Documentation • Checkpoint

Checkpoint 4

Start with the interactive checkpoint. When you finish, open the Answer Key to compare your rationale.

Answer Key (compare after you submit)

Primary verification references: Organization documentation standards and query policy; ICD-10-CM documentation-supported coding principles.

Question 1 Multiple Choice

Why do coders often start reviewing a note with the Assessment/Plan section?

A) It’s always the longest section.
B) It typically states the provider’s current conclusions and what was addressed/managed, which most directly supports reportable conditions/services.
C) It contains the billing codes.
D) It is required by law to be read first.

Correct Answer: B

Rationale: Assessment/Plan clarifies what was evaluated/treated/managed; other sections may include history or templated information not relevant for code assignment.

Cody Tip: Start where decisions are stated; use the rest to verify details.

Source to Verify: Organization coding policy; documentation-supported coding principles.

Question 2 True/False

Any condition listed in a past medical history/problem list must be coded every encounter.

Correct Answer: False

Rationale: Only conditions that are documented as evaluated/treated/managed (and meet setting rules) should be reported; history/problem lists alone may not indicate active management.

Cody Tip: List ≠ addressed. Look for action in the note.

Source to Verify: Organization policy; ICD-10-CM guideline principles for reportable diagnoses.

Question 3 Short Answer

A diagnosis appears in ancillary documentation but is not confirmed in the provider assessment. What is the safe approach?

Correct Answer: Follow documentation hierarchy/policy; do not code it as a provider diagnosis unless confirmed/adopted per policy; query if clarification is needed.

Rationale: Authority matters; unconfirmed mentions may be non-definitive and not reportable depending on policy and setting rules.

Cody Tip: Who said it matters—confirm authority before you code.

Source to Verify: Organization documentation authority policy; ICD-10-CM documentation-supported coding guidance.

Question 4 Multiple Choice

Which combination best represents high-signal documentation elements for coding decisions?

A) Header/footer template text + copied ROS.
B) Assessment/Plan + relevant objective results + documented indication.
C) Auto-populated problem list only.
D) Medication list only.

Correct Answer: B

Rationale: Current assessment and objective evidence support defensible choices and medical-necessity linkage when required.

Cody Tip: Signal = what was concluded, done, and proven—noise = copied filler.

Source to Verify: Organization documentation standards; chart review best practices.

Question 5 True/False

A “decision trail” should cite both (1) where the documentation supports your choice and (2) the rule/source that governs the choice.

Correct Answer: True

Rationale: Defensibility requires evidence and authority: what you saw and what rule you applied.

Cody Tip: Two anchors: chart line + rule line.

Source to Verify: Course method; organization QA expectations.

Phase 5 • Diagnosis & Procedure Logic

Lesson 1: Apply ICD-10-CM Logic

Purpose

This lesson builds a consistent way to choose diagnoses from documentation. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Principal/first-listed—the primary reason for the encounter (setting-dependent); Additional diagnoses—other reportable conditions addressed/impacting care; Integral symptom—a symptom typically part of a condition and not separately coded when instructed; Specificity—selecting the most detailed code supported

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: Patient seen for diabetes follow-up; note documents a complication.

Collect: Open relevant ICD-10-CM guideline sections for diabetes/complications and reportable additional diagnoses.

Observe: Identify required linkage (diabetes with ___) and whether documentation states the complication.

Decide: Choose the combination/linked code per guidelines and add additional codes when instructed.

Execute: Verify in tabular notes and document your decision trail.

Common Pitfalls to Avoid

Coding diabetes without linking documented complications.
Using vague codes when complications are clearly stated.
Separately coding integral symptoms when not instructed.
Not checking for ‘use additional code’ notes.

Quick Checklist (use this every time)

☐ Confirm what was addressed this encounter.

☐ Identify whether guidelines require linkage/combination coding.

☐ Check ‘use additional code’ and ‘code first’ notes.

☐ Verify specificity and document support.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 5 • Diagnosis & Procedure Logic

Lesson 2: Understand CPT/HCPCS Purpose

Purpose

This lesson builds knowing what procedure/service codes represent. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Procedure—a clinical intervention performed; Service—a billed professional/technical activity; Global concept—rules bundling related services (varies by setting); Modifier—a code add-on that clarifies circumstances

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: A procedure note documents an injection with a supply.

Collect: Identify the service/procedure and any separately reportable supplies/drugs per policy.

Observe: Review code range notes for inclusions/exclusions and any modifier instructions.

Decide: Select the service code and supply/drug code if appropriate and supported.

Execute: Validate documentation supports each element and apply modifiers only when rule conditions are met.

Common Pitfalls to Avoid

Reporting supplies that are already included per policy.
Using a modifier without documentation.
Choosing codes by name without reading range instructions.
Not distinguishing professional vs technical components when applicable.

Quick Checklist (use this every time)

☐ Start with the procedure description in the note.

☐ Read range instructions and parenthetical notes.

☐ Confirm whether supplies/drugs are separately reportable in your setting.

☐ Apply modifiers only when criteria are documented.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 5 • Diagnosis & Procedure Logic

Lesson 3: Verify Decisions

Purpose

This lesson builds verification loops to reduce errors. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Crosswalk—an unofficial mapping aid (must be verified); Edit check—payer/system validation rules; Bundling logic—rules that combine services under one report; Documentation requirement—elements needed to support the code

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: A tool suggests a code, but you’re unsure.

Collect: Open the official code instructions and any relevant guideline/policy.

Observe: Compare the tool suggestion to the rule conditions.

Decide: Accept the suggestion only if documentation and rules align; otherwise select the correct supported code.

Execute: Document the verification source and your rationale.

Common Pitfalls to Avoid

Trusting tool outputs without verification.
Ignoring payer edits until after denial occurs.
Assuming ‘common practice’ equals a rule.
Not documenting verification.

Quick Checklist (use this every time)

☐ Tool suggestions are starting points, not answers.

☐ Verify with primary sources every time.

☐ Check for bundling/edits when relevant.

☐ Keep a short decision trail.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 5 • Diagnosis & Procedure Logic

Lesson 4: Defensible Documentation Checks

Purpose

This lesson builds making sure the chart can support your choices. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Support—evidence in the note for the code requirements; Linkage—documentation connecting diagnosis and service; Query—clarification request when needed; Quality assurance—review process to maintain accuracy

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: A service is documented but the indication is unclear.

Collect: Identify required indication/documentation elements from policy/guidelines.

Observe: Check the note for those elements (symptoms, failed conservative care, risk factors, etc.).

Decide: If missing, follow query/addendum policy; if present, ensure linkage is clear.

Execute: Document the supporting lines and the policy/guideline reference.

Common Pitfalls to Avoid

Coding a service without a documented indication.
Failing to link diagnosis to service in the claim.
Not querying when the record is incomplete.
Assuming medical necessity without checking policy.

Quick Checklist (use this every time)

☐ Identify required elements for the service.

☐ Confirm the note includes those elements.

☐ Ensure diagnosis-service linkage is supported.

☐ Query/escalate when required, and document the path.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 5 • Diagnosis & Procedure Logic • Checkpoint

Checkpoint 5

Start with the interactive checkpoint. When you finish, open the Answer Key to compare your rationale.

Answer Key (compare after you submit)

Primary verification references: ICD-10-CM Official Guidelines (general/chapter); CPT range instructions and notes; HCPCS Level II guidance where applicable.

Question 1 Multiple Choice

What is the best first step when selecting an ICD-10-CM code for a documented diagnosis?

A) Choose the first code you remember.
B) Use the Index to locate a category, then verify in the Tabular List and read all relevant notes.
C) Choose unspecified to avoid mistakes.
D) Copy the code from a prior visit automatically.

Correct Answer: B

Rationale: Index-to-Tabular verification ensures completeness, correct instructional note use, and alignment with documentation.

Cody Tip: Find it, then prove it.

Source to Verify: ICD-10-CM conventions and guidelines.

Question 2 Short Answer

Why is diagnosis-to-service linkage important in many payer policies?

Correct Answer: It supports medical necessity by connecting the billed service to documented conditions/indications that meet the policy’s coverage criteria.

Rationale: Even correct codes can deny if the diagnosis pairing does not support coverage or is not documented as the indication.

Cody Tip: Correct code + wrong link = denial.

Source to Verify: Payer medical necessity policies; CMS claims/program integrity manuals.

Question 3 True/False

Modifiers should be applied whenever they increase the chance of payment.

Correct Answer: False

Rationale: Modifiers must be supported by documentation and allowed by the code/payer rules; using them without support is a compliance risk.

Cody Tip: A modifier is a statement—only say it if the chart proves it.

Source to Verify: CPT/HCPCS modifier guidance; payer policy.

Question 4 Multiple Choice

A tool suggests a code, but you’re unsure. What is the defensible next step?

A) Accept the suggestion to save time.
B) Verify the suggestion using authoritative guidance and documentation before finalizing.
C) Ask AI to confirm and submit.
D) Submit an unspecified code instead.

Correct Answer: B

Rationale: Tools can be wrong or incomplete; verification with primary sources is required for defensibility.

Cody Tip: Tool output is a hypothesis—your job is proof.

Source to Verify: ICD-10-CM guidelines; CPT instructions; organization compliance policy.

Question 5 Multiple Choice

Which is the most accurate statement about “integral symptoms”?

A) They are always coded separately.
B) They are never coded.
C) They may not be coded separately when guidelines/notes indicate they are integral to a confirmed condition.
D) They replace the diagnosis code.

Correct Answer: C

Rationale: Guidelines and tabular notes determine when a symptom is integral and not separately reportable versus when separate reporting is instructed.

Cody Tip: Don’t double-count the story—check the notes.

Source to Verify: ICD-10-CM guidelines for signs/symptoms; tabular notes for relevant categories.

Phase 6 • Compliance, Insurance & AI

Lesson 1: Understand Compliance Basics

Purpose

This lesson builds practical compliance literacy for everyday work. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Upcoding—reporting a code unsupported by documentation; Downcoding—reporting a lower code than supported (can also be an issue); Cloning—copying notes forward without reflecting current encounter; Audit—formal review of coding/documentation for accuracy

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: Template text includes exam elements not performed.

Collect: Review compliance policy and documentation standards.

Observe: Identify mismatch between documented statements and actual encounter evidence.

Decide: Code only what is supported; flag documentation issues per policy.

Execute: Document the concern and follow escalation guidelines.

Common Pitfalls to Avoid

Assuming template text is always true.
Coding services based on ‘what usually happens.’
Ignoring internal compliance escalation paths.
Not separating coding from documentation correction workflows.

Quick Checklist (use this every time)

☐ Code only what is supported by the authenticated record.

☐ Watch for cloned content and internal inconsistencies.

☐ Escalate documentation integrity issues per policy.

☐ Keep your decision trail and references.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 6 • Compliance, Insurance & AI

Lesson 2: Recognize Common Errors

Purpose

This lesson builds spotting patterns that create denials or audit risk. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Unsupported service—service billed without required documentation; Medical necessity mismatch—diagnosis doesn’t support coverage; Frequency limitation—service covered only at certain intervals; Duplicate billing—same service reported more than allowed

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: Repeated denials for frequency limits.

Collect: Pull payer policy and prior claim history.

Observe: Identify the time window and what counts as the same service.

Decide: Correct workflow to check history before billing; adjust claim when appropriate.

Execute: Implement a pre-bill check and document policy reference.

Common Pitfalls to Avoid

Not checking prior services within policy timeframes.
Appealing when policy clearly limits frequency.
Confusing similar services as separate when policy treats them as one.
Ignoring payer-specific rules.

Quick Checklist (use this every time)

☐ Check policy frequency limits before billing.

☐ Review claim history for the time window.

☐ Correct internal process to prevent repeats.

☐ Appeal only when documentation/policy supports it.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 6 • Compliance, Insurance & AI

Lesson 3: Use AI Safely

Purpose

This lesson builds a safe helper model for productivity without risk. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Assistive tool—AI used for summarizing or drafting, not deciding; Hallucination risk—AI can generate incorrect statements confidently; Primary source verification—checking AI output against authoritative guidance; PHI handling—protecting patient information

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: You ask AI to suggest codes for a note summary.

Collect: Remove PHI and define the question (what do you want AI to help with?).

Observe: Treat AI output as hypotheses; compare to guidelines/code instructions.

Decide: Select codes based on documentation + authoritative sources, not AI.

Execute: Document verification and keep PHI secure per policy.

Common Pitfalls to Avoid

Feeding PHI into tools that aren’t approved.
Accepting AI suggestions without verification.
Using AI to replace critical thinking.
Not documenting how decisions were verified.

Quick Checklist (use this every time)

☐ Use approved tools and remove PHI when required.

☐ Ask AI for structure/checklists, not final answers.

☐ Verify every suggestion with primary sources.

☐ Keep a decision trail that cites real references.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 6 • Compliance, Insurance & AI

Lesson 4: Professional Protection

Purpose

This lesson builds habits that keep you safe and respected. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Defensibility—ability to justify decisions with sources; Version control—knowing which year/version of rules you used; Escalation—raising issues through proper channels; QA culture—learning from feedback loops

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: A reviewer questions your code choice.

Collect: Pull your decision trail and the guideline/code instruction you used.

Observe: Compare the reviewer’s note to the rule text.

Decide: If you’re correct, explain with source; if wrong, update your rule notebook.

Execute: Apply the learning and prevent repeats.

Common Pitfalls to Avoid

Responding emotionally instead of with sources.
Not tracking which year/version of guidance you used.
Repeating errors because you don’t capture learnings.
Failing to use escalation channels for ambiguous cases.

Quick Checklist (use this every time)

☐ Keep references/version notes with your work.

☐ Use sources to discuss feedback, not opinions.

☐ Update a rule notebook after QA feedback.

☐ Escalate ambiguous cases to maintain consistency.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 6 • Compliance, Insurance & AI • Checkpoint

Checkpoint 6

Start with the interactive checkpoint. When you finish, open the Answer Key to compare your rationale.

Answer Key (compare after you submit)

Primary verification references: CMS Program Integrity Manual (Pub 100-08); organization compliance plan/PHI policy; payer documentation rules.

Question 1 Multiple Choice

What is the safest role for AI in a coding workflow?

A) Make final code and modifier decisions automatically.
B) Serve as an assistive helper for organizing/summarizing/drafting while the coder verifies all decisions with documentation and primary sources.
C) Replace reading payer policies.
D) Generate codes from PHI without restrictions.

Correct Answer: B

Rationale: AI can produce incorrect outputs; responsibility remains with the coder, who must verify with documentation and authoritative guidance.

Cody Tip: AI can speed up steps, not replace steps.

Source to Verify: Organization compliance/PHI policy; verification principles.

Question 2 True/False

Cloned/template documentation can create compliance risk because it may include statements not true for the current encounter.

Correct Answer: True

Rationale: If documentation is inaccurate, coding based on it can become unsupported, increasing audit risk and denials.

Cody Tip: If it looks copied, verify it twice.

Source to Verify: Organization documentation standards; CMS audit/compliance guidance.

Question 3 Short Answer

When should you appeal a denial versus submitting a corrected claim?

Correct Answer: Appeal when coding was correct and documentation/policy supports payment; correct when an error caused denial and payer rules allow correction.

Rationale: Choosing the appropriate pathway depends on payer rules, filing limits, and whether the claim needs correction or reconsideration.

Cody Tip: Root cause first, action second.

Source to Verify: Payer appeal/correction rules; remittance guidance.

Question 4 Multiple Choice

Which is a compliance red flag that should trigger a closer review before coding?

A) Clear documentation with objective results.
B) Internal consistency across sections.
C) Template text that contradicts the provider’s assessment.
D) A signed note with specific details.

Correct Answer: C

Rationale: Contradictions suggest documentation integrity issues that can lead to unsupported coding.

Cody Tip: When the chart argues with itself, pause and verify.

Source to Verify: Organization compliance plan; documentation integrity standards.

Question 5 True/False

If a payer policy clearly limits service frequency and the patient exceeds that limit, an appeal is always the best option.

Correct Answer: False

Rationale: If policy is clear and documentation does not meet an exception, appealing wastes time; the better approach is policy-driven correction/workflow prevention.

Cody Tip: Appeal when you have proof—not hope.

Source to Verify: Payer coverage policy; claim history/frequency guidance.

Phase 7 • Exams & Transition

Lesson 1: Exam Awareness

Purpose

This lesson builds what exams test: process, not just memory. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Stem—question scenario text; Distractor—plausible wrong answer choice; Time management—allocating time per question; Verification—finding the rule that proves the answer

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: A multiple-choice question asks for the best code; two answers look similar.

Collect: Identify the key term and look it up in the index.

Observe: Read tabular notes for both options, especially excludes and required characters.

Decide: Choose the option that matches documentation and rule notes.

Execute: Mark the source location you used so you can re-check quickly if needed.

Common Pitfalls to Avoid

Answering based on familiarity instead of proof.
Not reading notes for both close options.
Spending too long on one question and losing time.
Not extracting the real question from the scenario.

Quick Checklist (use this every time)

☐ Underline the question and key terms.

☐ Index search fast, then tabular proof.

☐ Compare close options with notes/excludes.

☐ Move on and return if time allows.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 7 • Exams & Transition

Lesson 2: Study Without Memorizing

Purpose

This lesson builds building navigation and rule application habits. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Spaced repetition—revisiting concepts over time; Rule notebook—short rule summaries with source locations; Scenario practice—short cases to apply rules repeatedly; Error log—tracking patterns in misses

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: You miss questions due to the same guideline.

Collect: Identify the guideline section that caused the miss.

Observe: Re-read the exact conditions and exceptions.

Decide: Write a 1–2 sentence rule summary with the source location.

Execute: Create 3 mini scenarios to practice the rule until it’s automatic.

Common Pitfalls to Avoid

Re-reading chapters without practicing retrieval.
Studying only what feels easy.
Not tracking why answers were wrong.
Ignoring source locations and losing time later.

Quick Checklist (use this every time)

☐ Keep a rule notebook with source locations.

☐ Practice with mini scenarios daily.

☐ Track misses by category (guideline, notes, definitions).

☐ Use spaced repetition and short sessions.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 7 • Exams & Transition

Lesson 3: Open-Book Search Strategy

Purpose

This lesson builds a repeatable method to find answers fast. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Keyword extraction—pulling the few words that matter; Index strategy—trying multiple terms; Tabular proof—finding the note that seals the choice; Fallback plan—what to do if you can’t find it fast

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: You can’t find the term quickly.

Collect: Try a synonym in the index and check cross-references.

Observe: Use inclusion terms to confirm you’re in the right category.

Decide: If still stuck, mark and move on; return with fresh eyes.

Execute: After practice, add the term/synonyms to your rule notebook.

Common Pitfalls to Avoid

Getting stuck on one term and panicking.
Ignoring ‘see also’ guidance.
Choosing an answer without tabular proof.
Not building a synonym list.

Quick Checklist (use this every time)

☐ Extract keywords from the stem.

☐ Try 2–3 index terms quickly.

☐ Find tabular proof or move on.

☐ Build a synonym list from practice.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 7 • Exams & Transition

Lesson 4: Readiness Check

Purpose

This lesson builds knowing when you’re ready and what to fix. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Benchmark—a target score/time you can repeat; Weak area—topic category that needs focused practice; Calibration—matching study time to impact; Confidence metric—how often you can prove answers with sources

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: Your score is improving but time is too slow.

Collect: Review which questions took the longest.

Observe: Identify whether the slow point is term lookup, note reading, or decision confidence.

Decide: Target the slowest step with focused drills.

Execute: Run timed sets and track both accuracy and speed.

Common Pitfalls to Avoid

Measuring only score, not time and proof.
Studying randomly without targeting weak areas.
Avoiding timed practice.
Not practicing the verification step.

Quick Checklist (use this every time)

☐ Track accuracy + time + proof.

☐ Target weak areas with drills.

☐ Do timed sets weekly.

☐ Build confidence by proving answers with sources.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 7 • Exams & Transition • Checkpoint

Checkpoint 7

Start with the interactive checkpoint. When you finish, open the Answer Key to compare your rationale.

Answer Key (compare after you submit)

Primary verification references: Codebook navigation (Index/Tabular); official guideline documents used in the course; practice sets.

Question 1 Multiple Choice

Two multiple-choice answers look similar. What is the most reliable way to choose?

A) Pick the one you’ve seen most often.
B) Find the tabular/range note or guideline language that proves which option matches the scenario.
C) Choose the longest code.
D) Choose unspecified to be safe.

Correct Answer: B

Rationale: Close options are resolved by definitions, required elements, excludes notes, and official guidance—not familiarity.

Cody Tip: Close answers are a note-reading test.

Source to Verify: Codebook notes/instructions; ICD-10-CM official guidelines.

Question 2 Short Answer

What should your rule notebook include for each rule you’re learning?

Correct Answer: A 1–2 sentence summary in your words plus the exact source location (section/chapter/range note).

Rationale: Source locations make your process repeatable and fast under time pressure.

Cody Tip: A rule without a location is a rumor.

Source to Verify: Course method; navigation principles.

Question 3 True/False

During timed practice, it’s best to spend as long as needed on each question to ensure correctness.

Correct Answer: False

Rationale: Time management matters; mark and move on, then return if time allows, prevents one item from costing multiple points.

Cody Tip: Skip smart now, learn deep later.

Source to Verify: Course strategy: timed ‘search-and-verify’ workflow.

Question 4 Multiple Choice

Which is the best first step in an open-book search strategy?

A) Read every option before reading the question stem.
B) Extract the key terms from the question scenario (keywords) and start with the Index.
C) Guess, then verify only if time remains.
D) Search for the longest phrase in the Tabular.

Correct Answer: B

Rationale: Keyword extraction speeds index lookup and reduces wandering; tabular proof follows after locating the right section.

Cody Tip: Underline the question, circle the keywords.

Source to Verify: Codebook index conventions; course search strategy.

Question 5 Multiple Choice

Your score is improving but you’re too slow. What is the best improvement approach?

A) Do more random questions without review.
B) Track which step is slow (lookup, note reading, deciding), then drill that step with timed practice.
C) Stop verifying to go faster.
D) Memorize only code titles.

Correct Answer: B

Rationale: Speed improves by targeting the bottleneck while preserving verification; skipping verification increases errors and rework.

Cody Tip: Speed comes from systems, not shortcuts.

Source to Verify: Course readiness-check method.

Phase 8 • Professional Integration

Lesson 1: Workflow Thinking

Purpose

This lesson builds a professional cadence for real charts. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Intake—reviewing chart context and encounter setting; Batching—grouping similar tasks for efficiency; Verification points—planned moments to confirm rules; Documentation trail—notes on reasoning and sources

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: You have a queue of charts.

Collect: Identify setting, specialty, and common services; batch similar charts.

Observe: For each chart, pull the key documentation and rule sources.

Decide: Choose codes with a consistent decision trail.

Execute: Apply a quick QA pass before releasing the chart.

Common Pitfalls to Avoid

Switching tasks constantly and losing focus.
Skipping verification to save time (costs time later).
Not tracking frequent rule lookups.
No QA step before release.

Quick Checklist (use this every time)

☐ Batch similar charts when possible.

☐ Use the same verification checkpoints every chart.

☐ Track repeat lookups to build speed.

☐ Always run QA before release.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 8 • Professional Integration

Lesson 2: QA Habits

Purpose

This lesson builds catching errors early. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Second-pass QA—a final review after initial coding; Mismatch—diagnosis doesn’t match documentation or service; Completeness—all required code characters/modifiers present; Consistency—documentation and code choices align

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: A chart passes edits but later denies.

Collect: Review your QA checklist and the denial reason.

Observe: Identify what QA missed (linkage, missing documentation element, policy limit).

Decide: Update your checklist so the miss becomes a future catch.

Execute: Apply the updated checklist moving forward.

Common Pitfalls to Avoid

Assuming ‘passed edits’ means ‘will pay.’
Not checking linkage and policy constraints.
Not updating QA checklists after misses.
Skipping peer feedback loops.

Quick Checklist (use this every time)

☐ QA includes policy/linkage checks, not just code format.

☐ Use denials as feedback to improve QA.

☐ Update your checklist after every trend.

☐ Build a habit of one final slow pass.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 8 • Professional Integration

Lesson 3: Defensible Documentation Checks

Purpose

This lesson builds aligning chart evidence to code requirements. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Requirement list—the elements needed to support a code; Evidence—where those elements appear in the note; Conflict—documentation inconsistencies needing resolution; Query workflow—standard process for clarification

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: Two sections of the chart conflict on laterality.

Collect: Identify the authoritative documentation source in your policy.

Observe: Find where laterality is clearly documented and authenticated.

Decide: If unresolved, query; if resolved, code with the supported laterality.

Execute: Document the support and your resolution path.

Common Pitfalls to Avoid

Choosing laterality based on guesswork.
Ignoring conflicts that should be resolved.
Not knowing which section is authoritative in your setting.
Failing to document your resolution.

Quick Checklist (use this every time)

☐ List required elements, then locate them.

☐ Resolve conflicts via policy-driven hierarchy.

☐ Query when necessary.

☐ Document the resolution path with sources.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 8 • Professional Integration

Lesson 4: Professional Integration Plan

Purpose

This lesson builds turning learning into daily performance. You will practice the CODE™ approach so your decisions are repeatable and defensible—not based on guessing.

Learning Targets

Describe the core concept in plain language.
Identify the best source to verify the rule.
Apply the rule to a simple scenario and explain your rationale.
Produce a “decision trail” you could defend in a QA review.

Key Terms (quick definitions)

Standard work—a repeatable routine for consistent outcomes; Metrics—accuracy, time, denial rate, QA findings; Feedback loop—review → adjust → improve; Career readiness—portfolio of defensible work habits

Section 1 — Collect: Where to Look First

In medical coding, confidence comes from knowing where answers live. Start with the source that defines the rule you’re about to apply:

For diagnosis conventions and sequencing: the ICD-10-CM Official Guidelines for Coding and Reporting.
For procedure reporting structure and instructions: the CPT code set instructions and the parenthetical notes in the code range.
For payer processing and claim rules: CMS manuals (and the payer’s published policies).

Your goal in Collect is not to read everything. It’s to find the exact section that governs your decision.

Section 2 — Observe: What the Rule Actually Says

Once you’ve located the right source, slow down. Observation is the difference between “I think” and “the rule states.”

Look for:

Definitions (what the term means in the source, not in everyday language)
Scope (what settings, providers, or services the rule applies to)
Conditions (if/then language, required documentation elements)
Exclusions or exceptions (when the rule does NOT apply)

Write down the rule in your own words, then confirm you can point to where you found it.

Section 3 — Decide: Pick a Defensible Path

A defensible decision has two parts:

The choice (what you will code, sequence, or report)
The justification (why your choice matches the rule and the documentation)

Section 4 — Execute: Verify + Document Your Decision Trail

Execution is where beginners either become accurate—or become inconsistent.

Before finalizing:

Re-check the documentation for the required elements.
Re-check the source for any notes that change selection or sequencing.
Document a short decision trail: “Because ___ is documented and the guideline ___ states ___, I selected ___.”

This turns your work into something you can defend in audit or QA.

Worked Example

Scenario: You want to improve accuracy without slowing down.

Collect: Track your error categories and time sinks.

Observe: Identify which step (Collect/Observe/Decide/Execute) is breaking down.

Decide: Choose one improvement focus per week.

Execute: Measure results and keep what works.

Common Pitfalls to Avoid

Trying to fix everything at once.
Measuring only speed or only accuracy.
Not using feedback to update habits.
No system for continuous improvement.

Quick Checklist (use this every time)

☐ Pick one improvement focus weekly.

☐ Measure both accuracy and time.

☐ Use feedback to update your process.

☐ Build standard work you can repeat.

Mini Practice (self-check)

Take a real chart note (or a training snippet) and do these three steps:

Write the question you’re answering (example: “Is this diagnosis coded as confirmed, suspected, or ruled out?”).
Write the source section you would open first (guideline/manual/codebook note).
Write a one-sentence decision trail you could defend in review.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Depth Notes: Avoid “pattern coding.” Similar words across notes can still lead to different coding outcomes depending on context, timing, intent, and documentation completeness.

Depth Notes: Quality comes from repeatable steps. Consistency beats speed; speed comes later once your verification process is automatic.

Phase 8 • Professional Integration • Checkpoint

Checkpoint 8

Start with the interactive checkpoint. When you finish, open the Answer Key to compare your rationale.

Answer Key (compare after you submit)

Primary verification references: Organization QA standards; payer policies; primary guidelines/codebook instructions used throughout the course.

Question 1 Multiple Choice

Why is a second-pass QA step valuable even when claims pass system edits?

A) It isn’t; edits catch everything.
B) Edits may not catch policy/linkage/documentation sufficiency issues; QA reduces denials and strengthens defensibility.
C) It increases denials by adding steps.
D) Only managers should do QA.

Correct Answer: B

Rationale: Many payment issues occur after adjudication against policy; QA is the safety net that catches issues edits miss.

Cody Tip: Passing edits is the start, not the finish.

Source to Verify: Organization QA standards; payer policies.

Question 2 Short Answer

Documentation conflicts on laterality (left vs right) for a service that requires laterality. What should you do?

Correct Answer: Follow documentation hierarchy/policy and resolve the conflict; if unresolved, query for clarification rather than guessing.

Rationale: Conflicts undermine defensibility; policy-driven resolution protects accuracy and compliance.

Cody Tip: If the chart argues with itself, pause and resolve—don’t pick a side.

Source to Verify: Organization documentation authority policy; query guidelines.

Question 3 True/False

Standard work in coding means a repeatable routine (intake → code → verify → QA → release) that produces consistent results.

Correct Answer: True

Rationale: Standard work reduces variability and supports quality under time pressure.

Cody Tip: Consistency is a skill—build it on purpose.

Source to Verify: Course workflow guidance; organization QA best practices.

Question 4 Multiple Choice

Which is the best way to improve your QA checklist over time?

A) Keep it unchanged to avoid confusion.
B) Update it using patterns from denials and reviewer feedback so past misses become future catches.
C) Remove policy checks to speed up.
D) Rely on memory rather than checklists.

Correct Answer: B

Rationale: Continuous improvement turns feedback into prevention and reduces repeated errors.

Cody Tip: Every denial is a lesson—capture it.

Source to Verify: Organization QA feedback loops; course professional integration plan.

Question 5 Multiple Choice

What is the most defensible way to handle an ambiguous documentation element that affects code selection?

A) Choose the most specific code anyway.
B) Choose the code that pays more.
C) Follow policy-driven hierarchy and query/escalate when needed; code only what is supported.
D) Ignore the ambiguity if the claim passes edits.

Correct Answer: C

Rationale: Defensibility requires documentation support and appropriate clarification; guessing increases compliance risk.

Cody Tip: Ambiguity = verify + clarify, not assume.

Source to Verify: Organization query policy; documentation standards; primary coding guidance.

Your Learning Map

Foundations Course Syllabus

Orientation & Role Clarity

Why this phase matters

What you will be able to do by the end of this phase

What you’ll build (your deliverables)

How to win this phase (the CODE™ approach)

How to study (without memorizing everything)

Primary references used in this phase (verification sources)

Lesson 1: What Medical Coding Actually Is

Purpose

Learning Targets

Key Terms (quick definitions)

Section 1 — Collect: Where to Look First

Section 2 — Observe: What the Rule Actually Says

Section 3 — Decide: Pick a Defensible Path

Section 4 — Execute: Verify + Document Your Decision Trail

Worked Example

Common Pitfalls to Avoid

Quick Checklist (use this every time)

Mini Practice (self-check)

Lesson 2: What Coders Are Responsible For

Purpose

Learning Targets

Key Terms (quick definitions)

Section 1 — Collect: Where to Look First

Section 2 — Observe: What the Rule Actually Says

Section 3 — Decide: Pick a Defensible Path

Section 4 — Execute: Verify + Document Your Decision Trail

Worked Example

Common Pitfalls to Avoid

Quick Checklist (use this every time)

Mini Practice (self-check)

Lesson 3: Your CODE™ Workflow

Purpose

Learning Targets

Key Terms (quick definitions)

Section 1 — Collect: Where to Look First

Section 2 — Observe: What the Rule Actually Says

Section 3 — Decide: Pick a Defensible Path

Section 4 — Execute: Verify + Document Your Decision Trail

Worked Example

Common Pitfalls to Avoid

Quick Checklist (use this every time)

Mini Practice (self-check)

Lesson 4: Confidence Without Guessing

Purpose

Learning Targets

Key Terms (quick definitions)

Section 1 — Collect: Where to Look First

Section 2 — Observe: What the Rule Actually Says

Section 3 — Decide: Pick a Defensible Path

Section 4 — Execute: Verify + Document Your Decision Trail

Worked Example

Common Pitfalls to Avoid

Quick Checklist (use this every time)

Mini Practice (self-check)

Checkpoint 1

Question 1 Multiple Choice

Question 2 Multiple Choice

Question 3 Short Answer

Question 4 True/False

Question 5 Multiple Choice

The Claim Ecosystem

Why this phase matters

What you will be able to do by the end of this phase

What you’ll build (your deliverables)

How to win this phase (the CODE™ approach)

How to study (without memorizing everything)

Primary references used in this phase (verification sources)

Lesson 1: From Encounter to Claim: The Big Picture

Purpose

Learning Targets

Key Terms (quick definitions)

Section 1 — Collect: Where to Look First

Section 2 — Observe: What the Rule Actually Says

Section 3 — Decide: Pick a Defensible Path

Section 4 — Execute: Verify + Document Your Decision Trail

Worked Example

Common Pitfalls to Avoid