Automated coding has been a popular topic ever since I first started blogging about EMR software 7.5 years ago. In fact, back then the discussion was usually around how great automated E&M coding was going to be for a doctor. Everything from increased coding levels to firing your billing person were talked about. However, I think the reality is that we’ve seen something much different happen.
Many people hate the automatic E&M coding in EMR because it is wrong so often. If they can’t trust it to do the right coding, then what savings are they really getting from the automation? To put it in the words above, they still need their billing person. Plus, the idea of coding higher is great because it can mean more revenue. However, it also can be seen as upcoding and give you plenty of grief as well. “My EMR told me to do it” isn’t a great defense for over coding a visit.
As I think about these automatic E&M coding engines, it makes me wonder why we don’t have someone who’s created a really great coding engine like we have with drug databases. Since there isn’t that means that every one of the 300+ EMR vendors has their own coding engine. That means we have 300 different E&M coding engines all with different ways to approach coding.
I imagine many would argue the reason the E&M coding engine needs to be part of the EMR is because it needs deep integration with the EMR data. This is true, but the same is going to be true as we enter the world of smart EMR software with deep CDS applications. EMRs aren’t going to build all of these pieces. They’re going to have to enable entrepreneurs to build some really cool stuff on top of their EMR. Why not do the same with E&M coding?
Although, it’s also worth consider, is medical billing one area where human touch is better than automated coding?
E&M Coding guidelines are so old. They’re from 1995 and 1997. If we look at what the guidelines say, it starts with the basics – whether the patient encounter was Brief (1-3 elements)or Extended (4 or more elements). This is just for the History of Present illness, where HPI Elements include: location, quality, severity, during, timing, context, modifying factors and associated signs/symptoms.
This is the easy part.
Then you look into ‘complexity’, data reviewed, and ‘risk of complications’.
We are not at a point where ‘systems’ can evaluate risk and complexity. Also, as doctors frequently tell me, it may not be a complex case or may not be that high of a risk, but if the patient is talkative, and I spend more than 30 minutes with the patient, my level of coding may jump up.
Secondly and more important, these guidelines may be rendered totally obsolete if healthcare reform progresses where reimbursements would be tied to ‘continuum of care’ rather than pure ‘episodic’.
Just additional food for thought.
I recently attended a conference where a physician said in his speech that CPT should be eliminated. It makes coding quite complicated and HIM directors will tell you that CPT codes (maintaining the codes and selling the books) are a revenue stream for the AMA.
That said, the rules for coding are complex and the penalties for upcoding are pretty steep. It makes sense that a human is looking over the codes that a physician chooses through the EMR. The documentation MUST support the codes.
Considering 3M has 80% of the coding market with their encoder, I would be surprised there is much variation in the coding engines being used. Would love to hear how the various EMRs and organizations are handling coding. Coding is where the revenue comes from. : )
Definitely a lot of things wrong with CPT codes. Too bad they’re not open source. Although, I don’t see a path to their disappearance.
I think 3M has a great footprint with CPT codes, but not as the EMR coding engine.