Getting Through an Operative Report - Without Crying

One of the things I love about the mentoring I do for students is it reminds me of what it was like to be a newbie. And I don't just mean the excitement of being on the cusp of a new career. I am also grateful to be humbled and reminded that I knew absolutely nothing when I got started. These days when I stand in front of an audience of coders or students and teach the latest and greatest on whatever topic I'm discussing for that day, it's the culmination of years of experience and hours (or weeks) of research and preparation. But you might be interested to know that in my first coding job I did come home from work on more than one occasion in tears.

I can't explain that helpless feeling when you've trained so hard - and studied and taken numerous tests and graduated, etc. etc. etc. - and you land that first job and they hand you an operative report. And you freeze. Because it's like Greek. You have no idea what to do. Where are the short coding scenarios you learned in school? What does that first paragraph really say? You know you could find the code if you could just figure out what the heck the darn report says (incidentally, I now consider myself trilingual: English, medical terminology, and coding!). You know you're qualified, but are you really?

So I sometimes forget when I'm working with new students what it was like. Of course, there are still days when I feel like crying because I keep getting myself into uncharted territory. I actually relish researching and "figuring out" things that other people may abandon because they are too foreign or "difficult." But it wasn't always that way. I used to be an overconfident novice coder who, when a chart was placed in front of her, did a lot of tap dancing to make it look like she was competent. The good news is, 15 years later, I feel competent (most of the time anyway!).

The Word Search
I've worked in coding education now for about 8 years. In that time I've been asked to work on a lot of different projects related to coding education. In addition to training coders, I've been asked to evaluate people to see if they would make good coders. And I always start with the word search test. Do you like word searches? If not, you might want to consider a different career. Because coding is one big word search. You have to decipher the medical record (or operative report) and decide which words are important and which ones you can ditch.

Bunionectomies are a Kick
The first time I was given a bunionectomy report to code, I'm pretty sure I cried. After all, the procedure title was something like "Mitchell-Chevron," which meant nothing to me. And I knew enough about coding to know I had to read the report to figure out if it really was a Mitchell-Chevron. And the report was surely about 4 pages - pretty standard for a thorough podiatrist. And when I went to a class to learn how to code bunionectomy procedures, I realized that out of the entire 4 pages, I focused on about 3 sentences. That was it. The rest was coding garbage. In case you're wondering, a Mitchell-Chevron bunionectomy involves removing the medial eminence (AKA bunion) and making an osteotomy (bone cut) into the first metatarsal (the foot bone connected to the big toe). I'm still amazed that it takes 4 pages to describe that.

Deciphering the Operative Report
I am often asked to explain how to decipher an operative report. Well, it depends on the procedure, really. And if you are a new coder and you ever have the opportunity to go to a seminar where they will present case studies, this is the best way to learn. I've taught dozens of classes and nothing drives home my point more than walking through the cases and coding them. But I will give you some basic elements here to get you started. While these rules don't apply to all specialties (e.g., interventional radiology has "special" rules that drive the even the most experienced coders - that would be me - batty!), this should get you started on some of those basic surgical reports.

• Rule 1 - Doctors Lie: Admit it, you watch House and have heard him say on more than one occasion that patients lie. Well, Dr. House, I would like to point out that doctors lie too. They will state the procedure one way in the title and then proceed to describe a completely different procedure in the body of the report. For example, the doctor may state a left heart catheterization was done, but after reviewing the report, the catheter never made it all the way to the heart - only to the coronary arteries. So keeping this in mind, you should never believe what you read in the procedure title. Honestly, I rarely even read the procedure title anymore - it's often fiction. As for Dr. House, I would love to see a strong-willed coder have it out with him on the show about his documentation, which I'm sure is a mess.
  

• Rule 2 - Get a Medical Dictionary: There's no excuse anymore. When I learned how to code, we were still using Windows 3.1, so there was no way the hospital was using the internet. But even without online resources, I had a medical dictionary on my shelf. And it was used often. How will you know if something is important if you don't even know what it means? While you're at it, make sure you also have access to an English dictionary. I know it's a novelty, but you will also find complex nonmedical words in the operative report (or even in your code descriptions). If you don't know what it means, look it up. Tedious, I know, but you will learn. Of course, you might feel like Billie Dawn from Born Yesterday, but you will learn. (Don't understand the movie reference? Look it up!).

• Rule 3 - Just Like Ragu, It's Probably in There: In school we hear terms like "it's bundled" or "separate procedure" but what does that really mean? Well, it means it's integral to the main procedure and don't code it out separate. What's included? Well, pretty much anything that has to be done in order to accomplish the main procedure. Taking out an appendix? Well, then the incision (or creation of ports for laparascopic instruments) is included. So is the closure at the end of the procedure. I don't know about you, but if I have my appendix taken out I sure hope the physician remembers to suture me closed at the end. All those things are like regular ingredients in Ragu pasta sauce - tomatoes, oregano, garlic. It's in there! So don't code each component out separately. Now, had they decided to do a liver biopsy while in there, that's different. That's like throwing a banana in the pasta sauce. So it gets coded separately.
  

• Rule 4 - You Will Only Use 10-20% of the Operative Report: Don't feel like you need to use every word in the operative report to code the case. The fact is, the operative report isn't about you, it's about the patient and it's a communication tool for clinicians. It just happens to double nicely as a recording of everything that happened to the patient and can substantiate coding and billing. It's up to you to determine what's important in the documentation. There's a reason we use coding for billing - your codes actually fit on a 1-page claim form so the insurance company doesn't have to read through every single medical record.
  

• Rule 5 - Know the Procedure: Okay, maybe I should have led off with that one. Medical terminology is, quite literally a foreign language. In fact, it's at least two foreign languages: Latin and Greek. So when you say "it's Greek to me," you're being quite literal. A really good medical terminology class will solve a lot of problems. You may think esophagogastroduodenoscopy is a really big word until you break it down and realize it's visualization (scopy) of the esophagus (esophago), stomach (gastric), and part of the small intestine (duodeno). You also need to know your anatomy. You need to know when they operate on a structure that's part of a bigger structure (e.g., mesentary of the intestines) vs. a different organ altogether (like in the appendix/liver example above). After you learn medical terminology and anatomy and physiology, that's half the battle. The rest of the battle can typically be solved with Google. Come to think of it, there are few things that can't be solved with Google. I'm pretty sure there will be a support group some day for Google-aholics, but in the mean time, I highly encourage you to google a procedure if you don't know what it is. I never remember what a Whipple procedure is. But I can google it in about 10 seconds. Just be careful which website you select from your Google search list - something from the Mayo Clinic is probably more reliable than lazy-Dan-explains-medical-procedures.com.

• Rule 6 - There is Crying in Coding, Just Don't Let Anyone See It: Oh, how I wish I could tell you I had that one down. But I'm pretty transparent when it comes to being frustrated. And I've had students cry in frustration when trying to code case studies. But try to minimize your public displays of tearful frustration and remember this - we've all been there and this is hard. It's okay to not know all the answers all the time.
  

I hope this at least gets you moving in the right direction. When people ask me how I learned everything I know I, 1) laugh, because I know there is so much more for me to learn, and 2) tell them how the rules above worked for me.

Coding is Just Looking up a Code in a Book…

…or is it?

When I was taking coding classes on Thursday evenings in the mid-90s, everyone in my class – including the instructor – had the same dilemma. There was a great new show on TV called “ER.” And it was on during coding class. Bearing mind that DVR didn’t exist at the time, sometimes we were able to talk our instructor into letting us go early and she would joke with us and tell us she’d give us extra credit if we went home and coded “ER,” that is, translate the conditions of the patients of the week into codes. I don’t know if anyone actually did. I certainly didn’t because I was just trying to understand the clinical lingo and decide what was important and what wasn’t. So now it’s your turn – how would you code this hospital inpatient scenario?

“CC: Pt adm w/ c/o CP, SOB, fever, weakness. PMH: CHF, HTN, DM type 2. Findings: Temp 102. BP: 100/65. CXR w/ infiltrates. Labs: WBC 40,000, sputum (-), BC (-). Assessment: sepsis, pna. Plan: IV abx, IVF, repeat BC.”

Statements such as these are a reality and before you can look up a code in a book, you first have to know what to look up. It often reminds me of my elementary school teachers telling me if I didn’t know how to spell a word to look it up in the dictionary. I remember thinking, “How do I look it up in the dictionary if I can’t spell it?!” Of course, we all learned to sound out the word and attempt to look it up in the dictionary. But coding is a little trickier because physician short hand is difficult to decipher if you don’t have any clinical knowledge. And before you can translate a clinical statement into codes, you first have to translate it into English!

Have you figured out the scenario above? Here’s the answer:
-038.9 Unspecified septicemia
-995.91 Sepsis
-486 Pneumonia, organism unspecified
-428.0 Congestive heart failure, unspecified
-401.9 Unspecified essential hypertension
-250.00 Diabetes mellitus, without mention of complication, Type II or unspecified

But how do you get there? That’s the question. So I will break down the coder’s thought process as he/she reads the statement and determines what to code.

Step 1: Translate the clinical shorthand into English.
The statement above, if written out long hand, would read as follows: “Chief complaint: patient admitted with complaints of chest pain, shortness of breath, fever, and weakness. Past medical history: congestive heart failure, hypertension, type 2 diabetes mellitus. Findings: Temperature 102 degrees. Blood pressure: 100/65. Chest x-ray with infiltrates. Labs: white blood count 40,000, negative sputum culture, negative blood cultures. Assessment: sepsis, pneumonia. Plan: intravenous antibiotics, intravenous fluids, repeat blood cultures.”

Step 2: Determine what brought the patient to the hospital and the underlying cause of that problem.
The patient had several complaints: chest pain (CP), shortness of breath (SOB), fever, and weakness. The patient’s fever was high and blood pressure was low. Tests showed infiltrates on chest x-ray, which is indicative of pneumonia and labs showed a high white blood cell (WBC) count, which is indicative of infection and blood and sputum (respiratory secretions) cultures did not grow any bacteria – but if the patient was on antibiotics before the cultures were taken, they may not grow any bacteria. The final assessment was sepsis and pneumonia. Symptoms of sepsis are weakness, fever, hypotension (low blood pressure), and high WBC count. Symptoms of pneumonia are chest pain, shortness of breath, fever, high WBC count, and weakness.

Step 3: Assign codes for the reason that brought the patient to the hospital.
Knowing that we don’t code symptoms when an established associated condition is present, we can narrow the final coding down to the sepsis and pneumonia. Coding rules tell us that coding for sepsis requires two codes: 038.9 and 995.91 and pneumonia without further specification is coded to 486. Of course, if this were a real hospital, we hopefully would have more specific documentation telling us the causative organism of both the sepsis and the pneumonia. That would require more digging through the record.

Step 4: Determine if there are other conditions that should also be reported.
In this case, the patient has a past medical history of congestive heart failure (CHF), hypertension, and type 2 diabetes mellitus. All of these are chronic conditions that impact the care of the patient and should therefore be coded. We can then add codes 428.0, 401.9, and 250.00. We can’t assume a cause and effect relationship between the CHF and hypertension because it’s not documented by the physician and we would want to look for documentation of a specific type of congestive heart failure (e.g., acute on chronic diastolic heart failure) and any diabetic complications.

So coding is just looking up a code in a book. At least that’s the tangible part of it. The rest of it is the thought process that goes behind it and explains why, if you watch coders work, you will see them spend most of their time staring at a computer screen or flipping through a medical record. I often compare coding to doing a word search: you have to sort through all the gobbledygook (i.e., pages of clinical mumbo jumbo) to find the right word to look up in the codebook.

You either found this explanation horribly boring or oddly fascinating. If you belong in the latter category, welcome to the wonderful world of coding. You're going to love it.