Thursday, August 12, 2010
The Shortcut to Being a Coding Professional
Okay, a quick side note: DRGs are the result of the codes assigned on a single inpatient claim - adding, removing, or changing a code can potentially change the DRG. For example, I recently reviewed a record for a coder and changed just the fourth digit on one code and it changed the DRG. So wanting to know how to audit DRGs without being a coder is like wanting to perform surgery without knowing how to use a scalpel.
Anyway, at that moment, two things ran through my brain. 1) This woman wants the job I consider to be my next step in the career ladder and 2) She just insulted me by seriously underestimating what it takes to be a successful coder, let alone a successful coding auditor.
The Shortcut to Being a Coding Professional
Each week I jot down blog ideas and often the short snippets scrawled on my note pad show a common theme. This week, the theme is summed up by a quote from Randy Pausch in the Last Lecture (I'm almost finished reading!): "A lot of people want a shortcut. I find the best shortcut is the long way, which is basically two words: word hard." And last night as I watched the last night of performances on So You Think You Can Dance, I was further moved by a simple statement by judge Nigel Lythgoe: "People believe they can be a star without working hard."
Now I am not trying to discount this woman's abilities in her chosen field of study. And although I have 15 years of experience in coding, if tomorrow I decided to be a computer programmer, I wouldn't expect someone to hire me because I have 15 years of experience in an unrelated field. I would have to study and become and apprentice all over again. It's a long journey, but the shortcut really is the long way: work hard. Would there be skills I could bring from my background? Absolutely and I would advertise those skills. But if you take one thing away from this blog posting, let it be this. You could unintentionally insult your potential employer by discounting what it takes to get to their level. And insulted people don't hire the people who insult them.
Spending Time in the Trenches
I've been a consultant for over 9 years and the best compliment I receive from a client is when they tell me that they can tell I've worked in the hospital environment and understand the process and issues. It seems simple, but in health care, we do everything differently - especially the business side of health care. Hospitals and physicians have been in business for centuries treating patients. But it's only been the last few decades that it's become necessary to combine the human health care aspect with the concept of running a facility like a business. And that's due to the increase in health care costs and the attempts to try to control those costs. The result is an industry built around human care and retrofitted for finance. How many businesses do you know that operate that way?
When I took a health care finance class a few years ago I already had several years of coding experience and was well versed in how a hospital's revenue cycle works. So as our professor talked about the process, I decided to observe the other students in the class that came from other industries - in particular, an attorney. And as the professor talked about the charge master and codes coming from different departments and payer mixes, the attorney thought it was crazy and unreasonable. It was a completely foreign concept to her. And it will be a completely foreign concept to you too until you get your foot in the door and start observing.
The woman who called me about how to be a DRG auditor eventually got frustrated with me and hung up. I wasn't the first person to give her the community college answer.
Within a few years I was a DRG auditor and I have to say it was one of the hardest experiences I've ever had. We traveled in teams of auditors (safety in numbers!) with our laptops and portable printers. Each time we finished a record that had a coding or DRG change, we printed out an audit sheet and sent the record and audit sheet back to the original coder. At the end of the week, we sat down with the coders and they had the opportunity to refute our findings. It took a few exit interviews and a lot of tough skin to build my abilities as a coding auditor. The terrific thing about coders is that they will dig to find an answer until they can prove they're right. Some of the coders I audited were right. And sometimes (I like to think more often than not!) I was right. My point is, I worked hard and I have a lot of confidence now in my ability to both conduct and defend a DRG audit.
That Annoying Overqualified Coder
I'll never forget my first encounter with a coding auditor. She was very qualified. As a matter of fact, all of my coworkers thought she was overqualified. She was brought in to do an audit of our work and then do some education. We all sat around a table at our first meeting and introduced ourselves. She started. She listed off her years of experience, degrees and credentials, and a long list of states she'd visited and audited. It took her about 5 minutes. And then she turned to her left and looked at me and asked me to introduce myself. My introduction went something like this, "Uh, hi. My name is Kristi and I just graduated and will sit for my ART [now RHIT] exam in October... That's it."
I was humiliated that I didn't have the credentials this woman had. I sounded ridiculous after her 5 minute speech about her experience. Afterward, my coworkers said they found the whole thing hilarious. They were not happy about being audited and most of them thought the consultant was overbearing and way to focused on credentials. They thought my response was perfect. And they all reassured me that no one could possibly expect me to have any experience - I had just graduated!
Now I think back to that consultant. Was she overbearing? Maybe. Did she have experience? You bet. Was she good at what she did? Absolutely. She taught me 2 things: 1) even if you have an encoder, you should always have a CPT code book on your desk because, "The encoder took me there" is not a valid response to why you coded something the way you did, and 2) how to code bunionectomies. That first introduction sticks with me too because now I'm the consultant who to some may seem overqualified. But I will tell you this. It feels so good when someone asks me a question and my answer includes the phrase, "When I was... [a coder, a coding manager, etc]." And I know it gives me credence with the people I'm talking to.
The Brick Walls are There for a Reason
The Randy Pausch quotes will be with me for awhile because so often as I've read this book, I find myself pumping a fist in the air and saying, "Yeah!" I spend a lot of time on thinking and self reflection and much of what Pausch wrote is in line with my thinking. Anyway, another favorite quote is this:
"The brick walls are there for a reason. They're not there to keep us out. The brick walls are there to give us a chance to show how badly we want something."
Yes, it's a quote worth bolding. I have no doubts that if you really want to be a coder and have the skill and talent for it, you will be a coder. The question is, how hard are you willing to work to scale that brick wall? We all started somewhere. People have asked me how I got so far in such a short time frame (15 years). I think I like the answer that Randy Pausch gave whenever someone asked him how he got his tenure so early: "It's pretty simple. Call me any Friday night in my office at ten o'clock and I'll tell you."
Monday, August 9, 2010
Top Ten Reasons to be a Coding Professional
Some of these are a bit dated, but most still ring pretty true and I updated Ms. Scichilone's credentials as she is still a well-respected practicing HIM professional. I hope you enjoy this little bit of levity!
Top Ten Reasons to be a Coding Professional
by Rita Scichilone, MHSA, RHIA, CCS, CCS-P, CHC
10. You love to read really small print.
9. Carrying around code books is better weight training than those cute little dumbbells you buy at the fitness store.
8. Classification systems and nomenclatures make great party conversation. "I'll bet you don't know what SNODO* is!"
7. If a patient can do it, get it, or hurt it, you can code it.
6. You love explaining what you do each day - "Oh, I typically transform sixty-five or so pages of complicated clinical information written in a foreign language (medical terminology) into numeric codes that will fit on a one-page form."
5. When you get carpal tunnel syndrome from turning those pages and burning up a computer keyboard, you'll know how to code it for your insurance company.
4. You can impress your friends by saying you'll meet them after work for some 94.38 at your favorite hangout."**
3. You are passionate about acronyms (DRG, APG, HCPCS, HCFA, HEDIS, CPT, UHDDS, ICD-9-CM, CHMIS, WEDI, UB-92)***
2. When you hear "The AR days dropped again today," you get goosebumps.
1. The eternal mysteries of ICD-9-CM and HCPCS CPT-4 are transformed at your touch into essential mastery of critical clinical data indexing that can change the health of America!
*Standard Nomenclature of Disease and Operations (SNODO) was a coding system that predated ICD-9-CM
**94.38, Supportive verbal psychotherapy
*** Ambulatory patient groups (APGs) were proposed prior to the use of ambulatory payment classifications (APCs); the Health Care Financing Administration (HCFA) was renamed the Centers for Medicare and Medicaid Services (CMS) in 2000, the uniform bill 1992 has been updated and replaced with the uniform bill 2004 (UB-04)
Wednesday, August 4, 2010
What Are You Going to do About It?
I will be the first one to admit when I’m bad at something (like math), but as far as joke-telling goes, I think I’m actually quite good. It’s the remembering part that’s tricky. But I do have a few favorite jokes in my arsenal – a blonde joke or two (it’s okay, I’m blonde!), a couple of jokes that are only truly appreciated by kids under the age of 8, and one joke that teaches a lesson. I am going to share the latter with you now.
A damn broke uphill from a town and the entire town had to be evacuated before the eventual flooding and devastation that was going to occur. One man began to pray and asked that God protect him from the flood. The police came to his door and told him to evacuate and he said, “No thank you. I believe and have faith that the Lord will provide.” The police left. Soon the flood waters were starting to make their way into the town and the man was forced to move to the second story of his home. He prayed again and asked God to protect him. A motor boat with rescuers came by offering to take the man to safety but again he said, “No thank you. I believe and have faith that the Lord will provide.” The rescuers sighed and shook their heads and moved on. Soon after that, the flood waters were so high the man had to take refuge on his roof. He maintained his prayer for safety. In one final attempt to clear the town, rescuers came by in a helicopter but the man refused to get on board. He said, “No thank you. I believe and have faith that the Lord will provide.” Soon there was no place left to climb and the unfortunate man drowned. When he got to heaven and spoke to God he said, “Lord, I believed in you and had faith that you would save me. Why did you let me drown?” And God said to him, “I provided you with the police, a motor boat, and a helicopter. What else was I supposed to do?!”
I’ve heard the joke many times – sometimes as part of a sermon, sometimes as an anecdote to get people to realize they have more control over their lives than they think. I receive many phone calls and emails from students and novice coders who are frustrated with the hiring process. And since I’ve committed to mentoring, I try to find time to respond to each of those emails. I am always happy to give a little pep talk or give a little advice that may guide them in the right direction. But occasionally, I get an email that is a series of complaints and blame games and all I can think is: what are you going to do about it?
Don’t get me wrong. No one loves a good venting session more than me. I even have friends that I can email and rant to and they won’t take it personally. I can type a 2 page email and usually get the response, “Feel better now?” and usually I do. I am all for venting frustration. But at some point, you have to make a decision to do something about the problem or change course. Otherwise you’ll go crazy. Think of Einstein’s famous quote about the definition of insanity: “doing the same thing over and over again and expecting different results.” So if you’re stuck in venting mode or you haven’t tried a different attempt at getting what you want, it’s time to break the monotony and move on.
I recently started reading The Last Lecture by Randy Pausch with Jeffrey Zaslow. I don’t get a lot of time to read and I am by no means a speed reader, so it will probably take me at least a week to get through this “quick read.” The story, if you are unfamiliar, chronicles the last lecture given by Randy Pausch, a professor at Carnegie Mellon University before he succumbed to pancreatic cancer. He was 47-years-old and left a wife and three young children behind. His lecture entitled “Really Achieving Your Childhood Dreams” was really directed at his children (the lecture was recorded) and is so inspiring, it yielded a spotlight on a national TV news program, the book, and countless videos on YouTube.
In the book, Pausch dedicates an entire chapter to his parents and their parenting skills. One of the things his parents did for him was to encourage him to find answers to the unknown. This is something I felt I had in common with him – my parents were always telling me to “look it up” if I didn’t know an answer. In fact, my mother always told me, “Knowledge isn’t what you know; it’s whether or not you know where to find the answer.” And as much as I hated the look-it-up-response (I actually thought they were lazy), I appreciate it now because now I don’t rely on someone else to figure everything out for me.
I am at a point in my life where I am probably the happiest I’ve ever been. And I’ve noticed that as a happy person, the last people I want to be around are unhappy people. Unfortunately, I have a few in my life – friends, acquaintances – who every time I talk to them dump every last problem on me and then wait for me to speak. Sometimes I mess up and give them advice. What I’ve found to be more effective is to ask them what they plan to do about it. If all they want to do is complain about their situation and aren’t willing to do anything about it, there’s really not much else I can do other than listen and wait it out until they’re done. But every once in awhile, I see something flicker in their eyes and I can tell they haven’t really thought what they would do about it. And I sometimes suspect they’re waiting for someone to tell them what to do. My hope is that my question is a virtual slap-in-the-face to get them past the complaining stage and onto the fixing stage.
Are you one of these people? Are you waiting for the magic opportunity that will get you into the coding profession? Have you really tried everything to get into the industry? I defer again to Randy Pausch, who created a list of childhood dreams. On that list was “being in zero gravity.” His students won a contest that enabled them to experience NASA’s plane “The Weightless Wonder,” which helps astronauts get used to a zero gravity environment. Unfortunately for Pausch, no faculty was allowed. So he found a loophole and withdrew his application as faculty and resubmitted it as press (for which he had to do some additional work to get the story into the media). It worked and Pausch was able to cross one thing off his childhood to do list. So I ask you again, if you’ve tried to get a job and have failed, what are you going to do about it?
Tuesday, August 3, 2010
Happy Summer!
But fear not! I will be posting some small blog posts to tide you over until September and I just submitted a couple of blog posts to AHIMA's HI Careers website, so you won't miss out. Be sure to check out my latest HI Careers post entitled "Experience for the Inexperienced" at www.HICareers.com and be sure to also check out the other blogs and offerings the website has to offer.
Friday, July 23, 2010
Now Blogging in Two Places!
AHIMA's HI Careers website
Thursday, July 22, 2010
Even My Dad's on Facebook - Are You?
I'm not one of those people who is afraid to "friend" my parents. They're actually pretty cool and I get along well with them. Plus, I subscribe to the idea that if I'm uncomfortable having my father read it, I shouldn't be posting it on Facebook to begin with. But my dad has only recently become semi-tech savvy. I received my first email from him about a year ago. So getting a Facebook request from him was major. Mom's request came in soon after his and was a little less shocking because she's into gadgets and is one of the few people I actually text.
My point (and I do have one) is this: so many people tell me they don't do Facebook because it's too much work. These people are often people who are looking for jobs. And all I can think of is, if Facebook is too much work and you want to be a coder (and potentially code from home), you are looking into the wrong business.
Let me demonstrate. I have 7 email accounts in varying states of maintenance. One personal, one for my company, one for The Coder Coach, two for clients, and the rest are accounts that were set up for miscellaneous purposes and very few people have those email addresses. I have 2 Facebook accounts, a LinkedIn account, and a Twitter account - although I only tweet professional tidbits because I personally find it a bit ridiculous to let people know what I'm up to at every moment of the day. I also have an instant messenger (IM) account, which one of my clients uses for quick questions.
And that's just "social" media. I am able to VPN into 2 of my clients in order to access their systems, which consist of a logon to the VPN, a logon to their server, a logon to the electronic medical record (EMR), a logon to their coding system, and an encoder. I also have various online memberships (e.g., AHIMA, AAPC) that require passwords to access member-only information. And frequent flier and hotel point programs. I currently maintain over 100 passwords.
In order to maintain all these accounts and passwords, I have my main work laptop, laptops from some of my clients, and an iPhone. I also have a personal laptop, which gets turned on about once every 3 or 4 months because I can't stand to be on the computer when I'm not working. I run dual monitors on my desk so I can look at applications side by side. I have 2 phone numbers, a fax number, and 2 different ways to connect to the internet. In other words, I'm well connected - at least when all the computers are working properly.
I admit - this is extreme. For the typical coder working from home, though, there will be at least a computer and 1 or 2 huge monitors for reading EMR documentation (remember, paperless means no paper - everything is online) and the login credentials to get into a VPN, remote server, and whatever systems you'll be using. When something goes wrong or doesn't work properly, you are the first line of IT defense. You can't just get an IT guy over to your house right away.
So if you want to be a coder and work from home and you aren't on Facebook because it's "too complicated," think about either changing your reason for not being connected, get connected, or find a new career that doesn't involve computers. And try to filter what you tell a potential employer about your issues with technology. As medical records move to an electronic format, you will need to be more tech savvy. After all, if my dad can do it, so can you!
Wednesday, July 7, 2010
Getting Through an Operative Report - Without Crying
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.