Effective Communication

Featured coffee – Matterhorn Flavored Coffee

Last week, I shared “Respect for Coders,” well this week, I’m adding Part 2.

Congratulations!  You’ve achieved the next level of coding, you’re an Auditor.  That means you have obtained the level of subject matter expert in the industry.  You know the guidelines, and you stay up to date on coding changes and guidelines, and you know how to delve into an issue.

You can audit a coder and determine if the codes are appropriate and if guidelines and coding conventions were followed.  If you fail the record, do you know how to communicate that to the coder?  The course you studied and the exam you passed to become a certified auditor does not teach you how to effectively present your findings.  Well, that’s where real-world experience comes in.

Always remember, you were once that coder.  How would it have affected you to merely be told that your codes were incorrect and no additional feedback was provided?  No opportunity to learn from the coding expert, and you were left to investigate your own errors?

So, let’s establish some rules:

1. If you do not have a guideline or other credible source to support your position, don’t fail the record. We all have opinions, but in this industry, “Cite Your Source (Your Opinion Doesn’t Matter).”
2. Your finding should explain the reason for the fail, including your source and your rationale based upon the source.
3. Always have a discussion with the coder. Your finding is not final until the coder has an opportunity to defend the code, coding convention, or guideline.  Your preliminary report should be forwarded to the coder for review and then a meeting scheduled later for discussion.  This allows time for the coder to review the note(s) again.  Sometimes the coder will have that ah-ha moment and recognize the mistake.  If the coder disagrees with your finding even after reviewing your rationale, the coder will have time to gather credible resources for the discussion.
4. It’s not personal, it’s coding. Go into the meeting with a positive and respectful attitude.  It’s an opportunity for you to discover the coder’s approach and how the coder interprets guidelines as well as an opportunity for the coder to understand you.  You may find one of you coded based upon an outdated guideline or misinterpreted a guideline.  For the auditor, if you made an error, acknowledge it.  It’s not a “loss” for you.  It’s a reminder for you to verify your findings.   If it’s a coder error, it’s not a “win” for you; it’s a teachable moment for the coder.
5. Review the guidelines together and discuss the differences in interpretation. Be prepared to provide examples of scenarios that align with the guideline.
6. If you’re unable to reach an agreement during the meeting, it’s okay.  It means that you need another opinion.  If you subscribe to AHACoding Clinic^® or CPT® Assistant, submit a query and send a copy to the coder.  If you do not have access to either, submit a query to a colleague.  When you receive a response, be sure to follow up with the coder.  Then you finalize the audit results.

 

 

 

All content is original and owned by diaryofamedicalcodingauditor/coffeewithamedicalcodingauditor

ICD-10® is copyrighted by the World Health Organization (WHO)

Coding Clinic® is a registered trademark of the American Hospital Association

 

 

 

 

Respect For Medical Coders

Featured coffee – Italian Chocolate Flavored

One of the numerous tasks assigned to coding auditors is to review documentation and validate the codes abstracted by the coders.  We pass or fail the coder, create a report of findings, and submit the report.

Of course, the steps between creating and submitting the report of our findings depends upon the workflow of the organization, and consequently, omitting steps can cause conflicts between the coders and the auditors.

I’ve encountered coders who were apprehensive about being audited, and as a coder, I understand their feelings when they’re not given opportunities to review and discuss the findings.  We should always give coders opportunities to defend their codes even when we find the codes are incorrect.

Meeting with the coders also gives auditors opportunities to understand the coders’ approaches to abstracting and provide education when mistakes are identified.  And auditors, there will be times when we will amend our finding after discussing an issue with the coder.  This is the respect that we should convey to coders and they, in turn, will respect us.

Early in my auditing career, I audited a coder, and as instructed, I delivered the report of my findings to the coding manager without any discussion with the coder.  The manager met with the coder and informed her that she failed the audit.  There was no feedback given to the coder, and she was not allowed to defend her codes.

Critical errors were made because of the workflow of this organization, and it made clear to me why the coders were unreceptive to audits.

1. Audits were not presented as educational opportunities
2. Feedback was not provided to coders to strengthen their weaknesses
3. Their strengths were not acknowledged

Decades have passed since then, and whether as an employee or an independent contractor, I follow my workflow.  I always perform the initial review and meet with the coder to discuss the findings.  We review the notes together and we both explain our rationale.  Only after that discussion is the final report submitted.

What Year Is It?

Featured coffee – Chunky Monkey Frappuccino

When you’re contracted as the coding consultant or auditor, you’re not always accepted by the staff.    Some may feel that you are there to replace them or point out all of their mistakes and cause problems for them.  It’s key to remember that yes, you are hired as the expert but no, you are not there to argue with or dismiss anyone’s value.

So, how do you handle it when the staff is second-guessing you? Foremost, keep a humble heart.

The chief of a large physician group contracted with me to audit his providers. I coordinated the audits and feedback sessions with the office manager.  She forwarded the notes, and I completed the reviews and reports off-site.

I went into the office to meet with one of the doctors.  The office manager and I chatted while waiting for the doctor to come into the conference room.  I pulled out my coding books while we were talking.  She asked, “What year is this?” I thought it was an odd question, but I told her the year.   She questioned why I had the previous year’s coding books with me.

The question didn’t bother me as much as her tone.  I paused (had to maintain my calm), and I reminded her that she sent notes from the previous year, so I had to use that year’s books to do the audit.  I told her the current year’s books were in my car if she wanted to see them.

She had nothing else to say.