5010X298 Triggering HL "numeric" edit on 2010AA
When generating a 5010X222 this edit does not occur, but when using the 5010X298, it seems like Optum triggers this edit once the HL01 >= 10 in the 2010AA.
This edit doesn't occur for other HL's in other loops. All HL's are incrementing by 1 appropriately. 2010AA HL's with single digits don't seem to have this issue, either.
I'm kind of stumped. I'm convinced it's a bug with Optum, as the implementation guides for 5010X222 and 5010X298 are exactly the same in their structure, looping, requirements, and detail text for these scenarios.
Anyone able to replicate this?
A "solution" was repeat the ST/SE multiple times inside of the X298 and limit the 2010AA's to a single loop per ST/SE. That way, the HL01 for the 2010AA is always 1. But that can't be the answer? Is it just a bug?
@joe-cerulli Are you referring to the 2000A? 5010X298 2010AA loop is the NM1 loop
@ross Apologies for the error, I've been investigating this "bug" with Optum's validation engine all night.
Yes, the 2000A.
The issue is repeatable--if I stack all the 2000A's at the top of the file, the edit occurs once the HL01 for the 2000A hits 2 digits. It doesn't make sense that it wouldn't be "numeric"--it's very much an integer and the max field length is still reported as 12.
If there are 10 unique 2000A's with 10 unique subscribers that repeat BP/SUB/BP/SUB, it will trigger on the 5th 2000A (HL10).
In the same scenario, with the looping repeating BP/BP/BP/etc./SUB/SUB/SUB/etc., it will trigger on the 10th 2000A (HL10).
I am hoping that this is truly just a bug with Optum and there is no such limitation in the X298 that would cause this, or result in a "one 2000A per ST" scenario to ensure that all 2000A HL's are always "1" to avoid it.
@joe-cerulli There is no max repeat on the x298 in the 2000A loop.