What is the policy regarding the use of delimiters in HIPAA non-composite data element fields for both the inbound claim (837) and the outbound remittance (835)? In working with clients, they have questioned why outbound 835s are not setting compliance errors when a data field (for example, the Patient Control Number - CLP01) contains a colon (exactly as it was submitted) even though the original input claim did not come in as a HIPAA 837. Example: A claim is received (non-HIPAA format) with a value of 123ABD:DEF as the Patient Control Number. The claim enters the system and finalizes. An outbound 835 is created with the Patient Control Number (CLP01) = 123ABD:DEF. It is not deemed non-compliant. When the 835 reaches the receiver, their system runs it through their editor and the 835 errors as non-compliant. By the same token, if a standard HIPAA 837 is submitted with a value in Loop 2300, CLM01, that contains a colon (123456:ABC), would the expectation be that the transaction fails compliance?
The X12 standard does not allow characters assigned as delimiters to be used as characters within the data elements of an interchange. This is true for all four delimiters and applies to both simple and composite data elements.
Health Plans should publish the characters they use as delimiters when they are the sender.
Providers that conduct any electronic transactions should seek to avoid submitting data elements that contain characters identified as delimiters. This is true for both their electronic and paper submissions.
As explained in X12.5 Interchange Control Structures and in appendix B of ASC X12 Technical Reports Type 3 (TR3), delimiters are assigned by the sender in the ISA control segment. Once delimiters are established by the ISA, senders must not use those characters in any data elements within the ISA/IEA interchange. If the assigned delimiters are transmitted within a data element structure, per your example, this would result in incorrect parsing of the data.
In both your 837 and 835 examples, the transactions do not comply with the governing TR3 if a delimiter is used within a data element. X12 cannot comment on the specific capabilities of, or differences between, compliance-testing products.
Further Discussion
ASC X12 uses the asterisk, carat, colon, and tilde as delimiters in examples within the TR3s, but delimiters are not restricted to these characters. Please note that the asterisk, carat, colon, and tilde may be used compliantly in data elements of an interchange that does not assign them as delimiters. Only the delimiters assigned in that specific interchange cannot be used within its data elements. Delimiters can be non-printable characters, or printable characters outside of the basic and extended character sets (TR3 sections B.1.1.2.2 and B.1.1.2.3) eliminating the possibility of this problem.