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?
This question references multiple technical reports by transaction, but always related to dates that were received in a claim. The TR3s returning claim dates to the provider identify the related information using descriptions including the terms "Claim Dates" or "Service Dates" or "Service Line Dates". The basic requirement is to return the date received in that prior claim transaction. There is no requirement that the date be 'logical'. Therefore, returning the dates as received on the claim, even if they are illogical dates, is required by the guides.
The guides do not impose any requirement that the century in any claim or service dates be 19, 20 or 21.
ASC X12 can't address any HIPAA regulations that may or may not be related to this issue
Health plans also have the option to identify claims that contain illogical dates on the front end using the Health Care Claim Acknowledgement (277). The illogical date still needs to be included as part of the edit/rejection transaction, but eliminates the issue for the 835.