none
BTS 2013 - How to Enable BizTalk to Use the Supplied ISA11 Value on a File Instead of the Value Set in the Agreement ("^", "U") RRS feed

  • Question

  • I have a case where a trading partner sends two separate file types: a 999 acknowledgement (uses the carat separator) and a 277U (uses the "U"). The trading partner uses the same ISA6/ISA8 identifiers. The 999 acknowledgement cannot be defined in the Transaction Set List so I need to support all transaction sets in the agreement. For the 277U, I can set the 277 in the set list, but then having multiple agreements with the same ISA6/ISA8 is not allowed. The type of file we accept is directed to an orchestration via the receive port/receive folder (999 files go to one folder and 277U files go to another).

    I would like to be able to accept the file and let BizTalk determine the repetition separator by reading it from the supplied ISA11 value rather than the set value in the agreement. Is this possible?

    Tuesday, February 24, 2015 4:04 PM

Answers

  • Here's the thing, all other HIPAA transactions define ISA11 as Repetition Separator so having an ISA11 value of 'U' on a 277U is an outlier. 

    Let me alter my advice...the first thing you should do is check their Companion Guide for the 277U to see if they have specified the interpretation of ISA11.

    But, looking at the 277CA Implementation Guide, ISA11 is defined as Repetition Separator.  I don't have have the official 277U IG but if you can get a copy, that will decide this definitively.

    So, I would raise it as a bug on their side.

    However, if they insist on remaining non-compliant, you then have to get them to document to you the exact meaning of ISA11 since they're causing some ambiguity.  If they are sending 'U' as Standards Identifier, they I would use a custom Pipeline Component to change 'U' to '^' in EDI.

    • Marked as answer by Angie Xu Tuesday, March 3, 2015 11:12 AM
    Tuesday, February 24, 2015 7:29 PM

All replies

  • This can get a little thorny, so first up, have you verified with the Trading Partner that the 'U' on the 999 is not a bug on their end?

    While there is no specific X12 rule on this, it's very bad form to use different ISA11 interpretations on different Interchanges.

    Meaning, I would pressure them to 'correct' it on their side.
    Tuesday, February 24, 2015 4:45 PM
  • It's actually response files coming directly from a State back to the submitter. In this particular case, they send a 999 ACK that is pretty standard (only slight differences from other states we work with) and it has the "^" repetition separator. Then they send a 277U which has the "U" standard. In both cases they use the same ISA6 to ISA8. Obviously, if it was just another value for ISA6, this would be a moot point--I could just setup another profile under the Party configuration. Getting the state to change their practice isn't easy, I am told. I was hoping there was a simple workaround that I wasn't thinking of.
    Tuesday, February 24, 2015 6:55 PM
  • Here's the thing, all other HIPAA transactions define ISA11 as Repetition Separator so having an ISA11 value of 'U' on a 277U is an outlier. 

    Let me alter my advice...the first thing you should do is check their Companion Guide for the 277U to see if they have specified the interpretation of ISA11.

    But, looking at the 277CA Implementation Guide, ISA11 is defined as Repetition Separator.  I don't have have the official 277U IG but if you can get a copy, that will decide this definitively.

    So, I would raise it as a bug on their side.

    However, if they insist on remaining non-compliant, you then have to get them to document to you the exact meaning of ISA11 since they're causing some ambiguity.  If they are sending 'U' as Standards Identifier, they I would use a custom Pipeline Component to change 'U' to '^' in EDI.

    • Marked as answer by Angie Xu Tuesday, March 3, 2015 11:12 AM
    Tuesday, February 24, 2015 7:29 PM