Someone reported a similar bug a long time ago. The fix that seemed to work was to change the logic to assume 5010 as the default state, and override if 4010 was explicitly specified.
Tony, if you test this fix and confirm that it works, it seems reasonable to bring this change into the official code base now since 4010 is defunct.
Alternately another approach would be to simply strip out the logic that supports both formats. Long term, it’s probably better that way to avoid future confusion, but there’s more chance for mistakes since there’s a lot more code that would need to be updated.
What you want to do with a bizarre bug is find out what’s causing it. It may have a larger scope than just the X12 version indicator.
What I suggest is adding some debug code that will pop up an error message with more information in the case of (strpos($claim->x12gsversionstring(), ‘5010’) === false).
That is of course the best practice. But since it’s (seemingly) random and
the customer needs to produce working/acceptable claim batches to get paid
can’t always do the slow model.
The other question is: does anyone still need 4010 at all? Should we plan
on removing it in the next patch release?
–
Please be aware that e-mail communication can be intercepted in
transmission or misdirected. Please consider communicating any sensitive
information by telephone. The information contained in this message may be
privileged and confidential. If you are NOT the intended recipient, please
notify the sender immediately with a copy to hipaa-security@mrsb-ltd.com and
destroy this message.
You can do both. Change the code to force 5010, and also to detect and generate an alert + debugging info when 5010 is not the requested standard from the Claim object.
After the puzzle is solved, I think it would be fine to remove 4010 support as a code cleanup project in the dev tip. There’s no compelling need for a patch for that.