The short answer to this article's title is, "You don't!".
There is obviously more to the answer, right? Yes, there is much more, but the answer is still the same. However, before I explain why you can't make such a change, let me first provide a bit of context by telling you a story...
If I have personally handled any of your support requests, you are likely aware that I prefer to educate users versus providing simple how-to answers. When it's appropriate, I will attempt to pull a user's focus away from simply completing a task. Instead, I like to ask directed questions in an effort to nudge a user into thinking beyond that task.
This method often results in the users answering their own questions and ultimately feeling more confident as an ElderSuite user and in their job role. I find users gain a better understanding of the provider business, a better understanding of ElderSuite as an application, and ultimately a better understanding that ElderSuite is actually more than an application. They begin to understand that ElderSuite is actually a management system which is designed specifically for Adult Day Care and Adult Day Service providers.
Recently, I was assigned a support ticket that asked one simple question which prompted me to write this article. That question was, "How do I change the Taxonomy Code in ElderSuite?". As soon as I read the question I kind of sunk in my chair because I knew this would be a long discussion with the user unsatisfied with my answer. However, I quickly regained my posture and morphed into professor mode. I knew it would be tough as always, but I wanted the user to understand why they were asking this question, preparing them for the answer. So, I responded with my answer which was basically, "You don't...", but, "Where did you get a this new Taxonomy Code you wish to use and who gave it to you?". I received a quick reply and the answer confirmed my speculations. Unfortunately, this meant there was going to be problems for the provider, but I needed them to understand the actual issue.
There is a point, I promise...
Now, just as this user did, we request that all users initiate support requests by creating a Support Ticket via the ElderSuite Help Center. The ElderSuite Help Center can be accessed directly from within ElderSuite by clicking the Help Center button found on ElderSuite's main navigation bar, or by accessing it through a web browser at support.eldersuite.com. There are many reasons we prefer this, but one of the main reasons is because a Support Ticket will be generated to record the support incident from beginning to end. This allows all of our support engineers to quickly find solutions for incidents they aren't familiar with. In this case, I was aware that were plenty of documented support tickets regarding this specific issue. Further, I felt there was way too much to explain through e-mail which would further delay solving the real problem, the provider's cash flow. Basically, the provider's claims were being incorrectly denied by a payer and said payer demanded they change the Taxonomy Code for any denied claims and resubmit those denied claims.
So, I picked up the phone and contacted the user directly. On most occasions that I'm asked a question about changing a Taxonomy Code, the conversation, and more specifically my answer, seems to understandably frustrate customers. This in turn frustrates me because I understand their frustration, I understand the underlying cause of their frustration, and I understand why they think we should be able to solve their issue. Unfortunately and understandably, we initially appear to be at fault. However, I promise we aren't.
Before continuing, it's important to note a little statistic that most aren't aware of. That statistic is that ElderSuite currently helps more than 3,500 users in 26 different states across the nation. I make note of this because I have only been asked this specific question by Texas providers!
After I finished the call and I was completing my notes and closing the support ticket. As I closed the ticket, I recognized this oddity and I thought it had to be an anomaly. How is this even possible? Why only Texas providers?
My first thought was the reason had to be because Texas is my territory. I happen to be the one most familiar with Texas rules and regulations. So, most support tickets generated for Texas providers are assigned to me. However, curiosity got the best of me and I started searching the ElderSuite Help Center database. I searched for any support tickets from Non-Texas Providers that were related to changing Taxonomy Codes. Guess What? I couldn't find any!
I initially thought the results were incorrect and I jumped to the conclusion that there must be something wrong with our search functionality. My mind started racing about all the possible implications and I decided I needed to look into the issue.
My first step was to isolate the data to ensure my results wouldn't be affected by some unknown, but more importantly, to prevent the possibility of my actions permanently affecting our help desk database. So, I exported every support ticket ever recorded and created a separate and isolated database. This allowed me to write T-SQL against the data without any repercussions. After all the time and effort spent, in the end my concern was unsubstantiated and fruitless. The search functionality in our front-end interface was working perfectly and the results I found were identical.
The fact is, there have only been a handful of support tickets created which contain the word Taxonomy and were also created by providers not located in Texas. Actually, the only inquires I found matching this search criteria were from a few privy providers who understood they needed a Taxonomy Code for specific payers, but couldn't locate a Taxonomy Code field in ElderSuite.
There's a reason why they couldn't find such a field and I'll get to that soon, but the short answer is because there isn't a Taxonomy Code field users can access. At this point of the story there seems to be an anomaly in which only Texas providers ask this specific question, even though Taxonomy Codes are used across the nation.
A benefit of ElderSuite is that it alleviates the need for users to memorize rarely used and odd codes such as a Taxonomy code. In addition it prevents administrative error by preventing changes to data which simply shouldn't change, such as the Taxonomy Code. ElderSuite is designed to be smart and knows what codes to use in certain situations based on specific criteria such as provider type and provider location. The Taxonomy Code is one of these codes. ElderSuite always uses the correct Taxonomy Code for the Provider Type and location which is determined when an ElderSuite Account is generated. It also uses the Taxonomy Code automatically, but only when required. For example, in Texas the Taxonomy Code is only used when for claims submitted to the payer, Superior HealthPlan. Oddly enough, they are the only payer that requires it to be submitted. What do they use it for? I don't know for certain, but my guess would be that it's collected for internal reporting and Texas Medicaid enrollment verification.
What is a Taxonomy Code and why do you need one?
How does Superior HealthPlan determine which Taxonomy Code you should be using?
Well, I'm not 100% certain, but I would guess the provider originally supplies it to the payer or to the Health & Human Services Commission (HHSC) during their enrollment process. That's important because if the provider or HHSC provides inaccurate information to the payer claims will get denied. Additionally, it's going to be an uphill battle getting it corrected in a timely fashion. When reimbursement for services is concerned, I doubt it can get corrected fast enough!
What happens when a submitted Taxonomy Code doesn't match what the payer has recorded for a provider's enrollment?
As mentioned, claims will be denied by the payer and the provider must go through the process of getting it corrected because the payer won't be able to correctly verify the provider's Texas Medicaid enrollment.
How could this possibly happen?
Again, I'm not 100% certain, but I assume it happens because of human error. We all make mistakes, but that's not the question to ask.
How can we fix this problem?
This is the question to ask. Let's take this provider who's been billing a payer successfully for years (literally years) using the same Taxonomy Code. Then one day...claims begin being denied. Huh? The provider goes through the process of trying to determine why their claims are getting denied and the payer ultimately tells the provider they are using the wrong Taxonomy Code. Huh? That doesn't make sense, but it also doesn't take much thought to realize that something is amiss. However, because the payer said it's wrong, it must be wrong, right? No! The issue in this case is the provider is likely speaking to the first representative that answered their call and that representative is likely in a call center. Unfortunately, that first level of support at a call center doesn't understand your business. The representative is likely reading the same message the provider received in the billing report explaining why their claims were rejected. Simply changing the Taxonomy Code in ElderSuite is not the answer and will still result in denied claims because the enrollment information is still incorrect. Basically, claims will still be denied because the billing codes ElderSuite submits for Adult Day Care services won't match up with the incorrect Taxonomy Code which is actually for a Custodial Care Facility.
Now, I'm certainly not trying to reprimand anyone and I hope I'm not coming across as if I am. autoHowever, the provider needs to know their business. The provider should know that answer doesn't make sense. Wouldn't the provider know if their business suddenly morphed into a Custodial Care Facility?
Let's take a look at the letter below that the provider received from the Texas Health & Human Services Commission (HHSC).
This is a notification letter from HHSC explaining to the provider that they are successfully enrolled in Texas Medicaid as a long-term services and support provider. We notice the date of enrollment verification letter is dated 6/12/2018 and the incorrect Taxonomy Code. So, who's fault is this? We'll never know! Either the provider submitted incorrect information when enrolling or HHSC made a mistake during the enrollment process. The point is the provider should have double checked this information as soon as they received notification.
After doing a quick google search I found this notice below on Superior HealthPlan's website.
You'll notice this alert is dated 8/1/2018 and that Superior HealthPlan alerts providers to ensure their enrollment information is accurately reflected or claims will be denied.
So, who's fault is this?
There's no way for me to know and it's really not important, but I'm certain it doesn't have anything to do with ElderSuite. The fact is mistakes happen. However, it's the provider's responsibility to double check their enrollment information and ensure it's accurate. In this case the provider had almost 3 months to realize the mistake and have it corrected, but it when unnoticed.
The Rest of the Story...
After further research in the provider's support notes, (amazingly) this issue actually went uncorrected for over a year. Additionally, I found previous requests from the provider asking us to fix the Taxonomy Code issue in ElderSuite. As of the time I published this article, I'm still not sure if the provider has corrected their provider enrollment information, but there isn't anything we can fix with ElderSuite to address their issue. Simply changing the Taxonomy Code in ElderSuite will still result in denied claims because the enrollment information is still incorrect for the provider type.
In the past, users were allowed to change the Taxonomy Code in ElderSuite, but it became too much of a support issue because providers would change the Taxonomy Code in these instances and claims would still get denied. When this happens, the instinct for users is to blame ElderSuite for the problem. That's human nature and there's no offense taken. Users aren't software engineers and I totally understand the assumption.
The frustrating part for me is that I still have no idea why this issue seems to occur only for Texas providers!
I hope you learned something and thanks for listening!