EDI X12 version 4010 message - can non-composite elements contain sub-element separator character?

Version 4010 x12 messages support segments with composite elements (like REF04) which contain sub-elements that are separated by sub-element separators. Here is 开发者_JAVA百科an example of a segment which uses ; [semicolon] as a segment separator, * as an element separator and : [colon] as a sub-element separator:

REF*ACT*12345678901234*ACCOUNTING CODE*3X:SUB CONTRACT NUMBER 1234567;

My question is this: If there is another segment in the message (for example N1) which is not a composite element and it happens to contain a sub-element separator, should the message be: a.) Accepted, which means the sub-element separator in N102 (see example) gets ignored and treated as a regular character that is part of the element data b.) Rejected, because sub-element separators can only appear inside composite elements, therefore it cannot be present in a N1 segment.

Example (with same separators as above - note that a colon appears in N102 as part of the data): N1*PE*TEST:PARTY ONE;

Any input would be helpful.

---

Based on the scenario you describe, I would reject the transaction. It violates X12 standards and would probably cause errors in most EDI translators or parsers.

The X12 standards have this to say about delimiters such as the subelement separator (ISA16):

Once specified in the interchange header, the delimiters are not to be used in a data element value elsewhere in the interchange.

Assuming this is an inbound transaction, your trading partner should take steps to ensure that none of the data they send to you will contain any characters that are the same as the element separator, subelement separator, or segment terminator. If the subelement separator is a colon and colons cannot be avoided in their data, then another subelement separator should be used.

As an aside, I would be careful about using semicolons as segment terminators. That is a character that often appears in data (e.g. addresses, product descriptions, etc.).

It may seem like a hardship at first, but the X12 standards greatly facilitate the exchange of data in the long run.

---

From my copy of the HIPAA ANSI 4010 270/271 Guide (emphasis added):

Users of this implementation guide should be aware that an application system may use some valid delimiter characters within the application data. Occurrences of delimiter characters in transmitted data within a data element can result in errors in translation programs. The existence of asterisks (*) within transmitted application data is a known issue that can affect translation software.translation software.

I know from experience that it can be difficult to get trading partners to update their ANSI producing applications to filter delimiters from field data. Asking them to do so is really the correct course of action. If they are unable or unwilling to then you may have to place some sort of pre-processor in front of your main translator.