Medical coding

Medical coding, checked before the claim leaves.

CPT, HCPCS and ICD-10-CM coding, modifier review, E/M support, coding audits and documentation review.

Get a Free RCM Assessment Request pricing

Example Encounter AFrom the signed note to releaseIllustrative encounter · No patient data

Provider’s note

The source for every code

Documentation reviewed: ReadySigned note read for what it supports
Diagnosis linkage: Clarification NeededQuestion sent to the provider
Provider answered: ReadyNote addended by the provider
Codes and modifiers checked: ReadyRecoded from the note as it now stands
Coding QA sample: ReadySecond review complete

Released to billingReady

An illustrative encounter with no patient data and no codes. Not a Kitronixe result or a client’s record.

The work

Coding starts with what the note supports.

Coding decides whether a claim survives review. Coding issues can contribute to preventable denials when documentation, code selection, modifiers or claim details do not align, which is why accuracy here matters.

Kitronixe codes to the documentation, flags where documentation will not support the service delivered, and feeds that back to providers rather than silently down-coding.

Documentation to code

From the signed note to a claim-ready line.

Six steps sit between a provider finishing a note and a coded encounter reaching billing. Choose a step to see what happens there, what can hold it, and what it hands on. The flags underneath mark where work most often pauses.

Documentation to a claim-ready line

Choose a step. Amber flags mark where work can pause.

The provider’s documentation is the source. Coders do not change it: where a note is unclear or incomplete, they ask the provider, and the provider decides.

Incomplete documentation
Provider clarification, where appropriate
Unsupported specificity
Modifier review needed
Coding inconsistency

Clinical Documentation

Step 1 of 6: what happens

The provider sees the patient, documents the encounter and signs the note in the EHR.

What can hold it

A note left unsigned, or one that does not yet describe everything that was done.

What it hands on

A signed note, which is the only source the coding is built from.

Incomplete documentation
Step 1 of 6: what happens
The provider sees the patient, documents the encounter and signs the note in the EHR.
What can hold it
A note left unsigned, or one that does not yet describe everything that was done.
What it hands on
A signed note, which is the only source the coding is built from.
Provider clarification, where appropriate
Unsupported specificity
Modifier review needed
Coding inconsistency

Gap routing

Each kind of gap takes a different route.

Not every documentation problem is handled the same way. Choose a gap to see where it goes before the encounter can be coded and released.

Documentation gap map

Choose a gap to follow its route

Educational example

Gap

Route

Then

Coding hold

Review and clarification

Coding QA

Documentation follow-up

Back to coding, then releaseOnce the gap is resolved

Missing documentation
Coding hold
Back to coding, then release

Missing documentation → Coding hold

Without a signed note there is nothing to code from. The encounter waits on a coding hold until the documentation is completed by the provider.

An educational example of routing, not a rule. How each gap is handled is agreed with the practice and depends on its policies and, where applicable, payer guidance.

Coding quality checks

Five checks, then one readiness call.

Every coded encounter passes the same checks. Ready for billing is not a separate judgement: it follows from the five checks before it. Choose any cell to see what that check asks.

Coding quality matrix

Choose any cell to see what the check asks

Illustrative encounters · No patient data

Ready
Review Needed
Clarification Needed

Documentation Complete

Code Supported

Modifier Review

Diagnosis Linkage

Audit Status

Ready for Billing

Example Encounter A

Office visit

Example Encounter B

Visit with a same-day procedure

Example Encounter C

Diagnostic service

Example Encounter B · Modifier Review

What the check asks

Where a modifier may apply, does the record support it, and has the applicable payer guidance been checked?

In this example

A modifier may apply to the visit; a second reviewer checks the record and the applicable payer guidance.

Review Needed

Example Encounter A
Office visit
Derived outcome
Example Encounter B
Visit with a same-day procedure
Derived outcome
Example Encounter B · Modifier Review
What the check asks
Where a modifier may apply, does the record support it, and has the applicable payer guidance been checked?
In this example
A modifier may apply to the visit; a second reviewer checks the record and the applicable payer guidance.
Review Needed
Example Encounter C
Diagnostic service
Derived outcome

Illustrative encounters with no patient data and no codes, to show how the checks combine. Not a Kitronixe result or a client’s encounters.

On the coding desk

The coding desk, line by line.

What the coding team covers for each practice, from the Services record.

CPT, HCPCS and ICD-10-CMLine 01Coded to documentation by experienced medical coding professionals.
Modifier reviewLine 02Applied correctly, with NCCI and MUE awareness.
Coding auditsLine 03Sampling against documentation, with findings returned as education.
Documentation reviewLine 04Gaps flagged before they become a denial or an audit finding.

Provider clarification

When the note is unclear, the provider decides.

Queries are non-leading: they ask what the provider meant, never suggest the answer that pays more. Only the provider amends the documentation.

01
Ask
The coder sends a plain, non-leading question that points to the part of the note in question.
Coder
02
Answer
The provider responds and, if they choose to, amends or addends the note under their own signature.
The provider’s decision
03
Recode
The encounter is coded again from the documentation as it now stands.
Coder
04
Release
The encounter goes on to billing, with the query and the answer kept in the trail.
Coder, then billing

Specialty context

Specialty context changes what a coder looks for.

The same checks apply everywhere, but what matters inside them depends on the kind of service. Three example contexts, described generally. The specialty workflow for a practice is agreed during onboarding.

Example context

Procedural services

Procedures bring more lines per encounter and more places where a modifier or a bundling question may apply, depending on payer.

What coders look for

The procedure note matches what was performed
Separate services are documented as separate
Modifiers only where the record supports them

Coding operations

See the coding queue, not just the output.

A coding team should be able to show where every encounter sits. These are the views practice management receives, with the definitions agreed up front.

Queue by statusEncounters waiting on documentation, in coding, in QA, awaiting the provider, and released.
Open provider clarificationsQuestions sent, answered and still open, by provider, so none sit unseen.
QA findings by themeWhat coding QA found, grouped by kind of issue rather than by coder.
Documentation education topicsRecurring documentation gaps, turned into short topics for provider education.

Sample coding operations viewIllustrative data

Invented counts of encounters for a fictional practice, to show what the view contains. Not a Kitronixe result.

Encounters Ready
46
Signed notes waiting to be coded
Documentation Pending
11
Notes not yet signed or complete
Waiting on someone else
Coding Review Queue
23
Being coded now
QA Review
8
Sampled for a second review
Provider Clarification
5
Waiting on a provider answer
Waiting on someone else
Ready for Billing
38
Released to billing today

Coding work queue by status

Encounters at the end of each sample work day. Choose a day for its breakdown.

In coding review
In QA review
Awaiting provider
Released to billing

Fri · In coding review: 23
Fri · In QA review: 8
Fri · Awaiting provider: 5
Fri · Released to billing: 38

Audit support

Audit support and claim readiness.

Coding sits in the middle of the cycle: after charge capture, before the claim is scrubbed and sent. What it releases should stand up to a later look.

A trail for every encounterWhich note was coded, which questions were asked and answered, and what QA found, kept together.
Samples for an auditFor an internal or external review, encounters can be pulled with their documentation trail, as the auditor requests.
A clean handoff to billingEncounters are released only once open questions are closed, so billing is not left to guess.

Where Medical Coding sits in your revenue cycle

01Patient Scheduling & Pre-Registration
02Eligibility & Benefits Verification
03Prior Authorization
04Charge Capture (this service)
05Medical Coding (this service)
06Claim Scrubbing & Submission (this service)
07Payment Posting & Reconciliation
08Denial Management & Appeals
09A/R Follow-Up & Recovery
10Patient Billing & Collections
11Reporting, Analytics & Revenue Integrity

04Charge Capture· Mid Cycle
05Medical Coding· Mid Cycle
06Claim Scrubbing & Submission· Mid Cycle

Where the work happens

Coding inside the practice’s own records.

Coders work in the systems the practice grants access to. Nothing is moved to a separate tool to be coded.

DocumentationThe provider’s signed note: the source every code is taken from.
EHRWhere notes are read and, where the practice’s setup allows, queries are sent.
Coding workflowThe queues, the query log and the QA samples the coding team works from.
Claim handoffCoded charges passed to billing for charge entry and claim scrubbing.

Coding questions

Questions about medical coding

All FAQs

How do you handle provider documentation questions?

Through a query process agreed with the practice. The coder writes a short, non-leading question that points to the part of the note in question and sends it through the channel the practice prefers, often the EHR’s messaging where available. The encounter is held until the provider answers, and the question and answer are kept with it.

Do you support specialty-specific coding workflows?

Yes, where the practice needs one. During onboarding we agree the services the practice performs, the payer guidance that applies to them and what the QA sample should focus on. Coders assigned to a practice work to that agreed workflow. We will say plainly if a specialty is outside what we can support well.

How is coding QA handled?

A second reviewer samples coded encounters against the documentation, based on a QA plan agreed with the practice: how many, which providers and which kinds of service. Findings are logged by theme, corrected before release where the encounter is still open, and used for coder and provider education.

Do you change what the provider documented?

No. The documentation belongs to the provider. Coders code from what the note supports; when something is unclear or incomplete, they ask the provider. Only the provider decides whether to amend or addend the note, under their own signature.

Can you support an internal or external coding audit?

Yes. For an internal review we can pull a sample of encounters with their documentation trail, queries and QA findings. For an external audit we can prepare the requested encounters and the coding rationale for the practice’s team. The findings and any response remain the practice’s; we do not give legal advice.

Talk to us about your coding workflow.

Tell us how coding runs today: who codes, how queries reach providers and how QA works. We will walk through where a documentation-led process would fit.