Home Forums Discussions Problems Error in 6.5 immunizations

Error 1: AC6.5 really is eating my time on this. Usually, my MA gives vaccinations. I'm a pediatrician, so there are many vaccinations. My MA gives the vaccinations, then forwards the chart to me to be signed and billed. The software automatically adds the immunization administration codes 90471 or 90472 for each vaccine. THIS HAS NOT BEEN RIGHT SINCE JANUARY 1 2011. For the last 3 years, these codes have not been correct for any patient under 18 (80% of my practice, 98% of my immunizations). We use codes 90460 and 90461, and it's not as simple as first and next shot--we have to know the components of each shot. So I get the forwarded chart then have to delete these incorrect codes, which no insurer in the USA will pay because they are flat wrong, and have to put in and calculate the correct codes. This has been wrong for years, and everybody knows about it. Well, except for.... Thanks AC [yes, sarcasm].

Error 2: AC6.5 has the bizzare and incorrect idea that it's a time-save if, when my assistant enters an immunization given then forwards a chart to me, the administration code is 90471. So a parent or one of my patients who's 18 or older comes in and want a Flumist nasal spray flu vaccine. The only correct code, the one that will get paid, is 90473.


I did NOT sign up to be a beta tester for 6.5. AC called me, de novo, and made an appointment to install 6.5 in my office. I allowed it, and after four hours for 3 computers, it was done. I regret it for this error alone. Advice: don't do it. They obviously have not done some basic things and are unaware of these key issues.

Are you really going to try and convince me that you give a damn about pediatrics? Can there be any coherent excuse for a major update like 6.5 still defaulting to head circumferences in inches (never used anywhere) or requiring decimal pounds for body weight (never heard of this, either: is my ideal body weight really 182.625 pounds?)? If I was able to write a little bit of code for my office on Google spreadsheets that makes pounds and ounces into decimal pounds, why could it not be done in AC? By the way, I had to do this for the benefit of AC. How much do they pay me for this coding work? And AC, please don't try to convince me that this isn't an issue for anyone else. It's a waste of my time and the time of any other FP or Pediatric office that sees babies and young children, where their health and safety and the standard of care is absolutely measured in ounces. So don't try to convince me you care about pediatric medical care, that you are adapting you software for pediatrics, or that you'd like me to speak to another physician thinking about AC. The cost/benefit investment analysis is slipping in the wrong direction.

This was a known release when V6.5 was released. Actually they generally discouraged pediatricians from upgrading to 6.5 because of this reason. It was widely publicized on the board. See this post:
http://amazingcharts.com/ub/ubbthre...Have_to_defer_upgrading_becaus#Post55185
or
http://amazingcharts.com/ub/ubbthre...Re_Input_from_those_using_6_5_#Post55205

The biggest error they made is that they should have warned you again before you installed. This is not a small error. I did not see this issue initially because I often bill before my MA puts the immunizations in the system.

Yes, the HC issue is a pain. I have no problem with decimal pounds because our scales can measure in this way, AC has always been this way and I can translate pounds to ounces in my head, as well as there was cheat sheet at the nurses station at one time (not sure it's still there.)

Not really an apology, more of an explanation. The HC change occurred probably in V5, it had been in cm's before that. Probably a programmer trying to be consistent. I would recommend that everyone send in a request to change it. The more complaints, the higher it may be on the list, (I hope.)

AC does listen to complaints. It isn't perfect. They do make mistakes. They do generally correct them, especially when they are of the magnitude of billing. Other complaints often languish, as we well know.

Thanks for the explanation, Wendell. I honestly appreciate it.

It's not my fault that I didn't decline their request because I'm not reading the user board enough. They cold-called me and set a date for the installation. Did they not notice the word Pediatrics in my business name, "Private Pediatrics Inc."?

I genuinely thank you for explaining what has happened. I don't want to spend the hours rolling back to an earlier version with or without their help.

Overall, I remain generally happy with AC, which I have been using since 2006. EPIC has taken over the 2 hospitals of which I'm on the medical staff, and it's a freakin' nightmare. So I don't believe the grass is greener on some other system. But this is the kind of error that is a coding error--something I used to do for a living long ago. The error is understandable, to be expected in this complex work.

But there is no excuse for 1. not informing the client (me) beforehand; and 2. not fixing it pronto once known. It requires no re-formatting, no anything. Just a brief subroutine that looks at the patient's age and how many components there are of the specific vaccine.

Somebody needs to care.

Thanks for the links to previous posts mentioning this problem.

Apparently, the problem was noted in 2011. Some clients were promised a fix by September 2011.

AC called me a month ago, in 2013, and requested and scheduled the upgrade to 6.5. They didn't warn me of the problem, and they haven't fixed this known problem in more than 2 years. I'm sure they are all working on something more revenue-producing, but there just isn't an excuse for ignoring this important problem. I am the one to fix the coding on every shot we give. I expect better.