Maybe this should be in the HELP forum, but we got this set errors on every TMHP claim and there answers seem to conflict with what the normal rules are.
Message Type: R Message Code: 01601
Message Loop: Message Segment:
Message Element:
Message Text: BILLING PROVIDER NPI/API TO TPI COMBINATION OR NPI/API INFORMATI
ON IS INVALID
Message Type: R Message Code: 01604
Message Loop: Message Segment:
Message Element:
Message Text: BILLING PROVIDER TAXONOMY IS MISSING
Message Type: R Message Code: 00420
Message Loop: Message Segment:
Message Element:
Message Text: RECORDS INDICATE PROVIDER IS NOT ENROLLED IN THIS PROGRAM. …
What TMHP says to do is in total conflict as with the rest of the carriers as near as I can tell, here it is sanitized and commented on…
1) Do not use the *Facility* NPI number, Bill under *The Service Providers NPI*
2) Use the bill provider physical address not the PO Box ---- ** THAT won’t work we have multiple locations and one billing address for the check to be sent**
3) the 307 field and benefits code needs to be left blank we use the texas health steps under chips not tmhp ---- *unclear what that means, yet*
4) Taxonomy Code Seg PRV03
4a) 9 digit zip REF – *I’m pretty sure we got rejects on 9 digit zip with some other carrier)
4b) Qualifier LU02 – **clueless**
4c) Taxanomy code is 363LF0000 – ** This code is fixed at the Provider level, how could it be different by carrier? ***
So far the error rate on electronic claims submission for all kinds of reason is about 98% which i unacceptable, it way to easy to make mistakes and way, way too hard to correct them.
Complain to your congressperson? Standards are supposed to make communication easier, but if nobody is enforcing proper use of them, then payers will just abuse them to fabricate even more reasons to reject claims.
By that you mean that you agree with my summation that what they are asking for is different, I presume and, therefore, not do-able without customization?
–Tony
Tony, my guess is that your summation is correct, but I couldn’t put my seal of approval on it without digging into the details. I do have direct experience with Medicare having nonstandard requirements for paper claims.
For what it is worth, I had a host of conflicting rejects for the Aetna and UnitedhealthcareCD.com portals X12 submits, even while EXACTLY the same data was perfectly fine as SOP with the others.
It turned out that both Aetna and UHC used the same intermediary, and their HIPAA reject codes were both unclear and pointed to the wrong problem. Both also rejected if a Zip + 4 code was used (and do not leave the hyphen). And there were some other problems as well.
My approach was to recognize that there will be some which have unique "interpretations", and so I built a handler which simply modified ONLY if the Payer Code matched theirs, leaving the rest as is. That allowed all to process properly with no further action by myself nor the biller using OpenEMR X12 code directly.
I posted to the forums on one example - where the "Onset" was unknown. My client wants to put a zero date unless they actually know, but those two portals reject any zero for the MM portion. So the handler in the X12_gen file merely substitutes the DOS if it has a zero set in the field for submittal, even though it leaves the actual data intact.
I think doing that will be far less painful than trying to even determine what is actually going on. And I wholeheartedly concur with Rod’s description of the REAL motivations. Even the Techs at UHC/Aetna could not explain their paradoxes. I know you are not HAPPY with that, but at least it can remove the monkey from your back. I suspect that will be a sad reality, since even Medicare, which promulgates HIPAA regs, admits to violating them. And I have my doubts about CCHIT success until ALL adhere to the same rules, which I do not forsee for a LONG time. So a case by case basis may be required indefinitely. Sorry.
That was (of course) the problem with the NSF format back in the 1990s, I had hoped the industry was past that.
That means the normal end users can NOT use electronic claims by themselves, period. A boon to us support people I guess. Terrible otherwise.
I think a serious discussion of the architecture of X12 generation is in order. It will require a model that lets you have by carrier or clearing house rule sets or modules of some sort.
Not in this thread, however. I’ll start a new topic.