Thanks for your discussions on this, Kepa and Rachel. Joe Barton -----Original Message----- From: Kepa Zubeldia [mailto:[EMAIL PROTECTED]] Sent: Saturday, October 20, 2001 9:48 PM To: [EMAIL PROTECTED] Subject: Re: Segment separators - Translators
Rachel, Given my pragmatic nature, I think that all receivers should be as accommodating as possible and accept transactions even though they may not be strictly compliant with X12 syntax in the segment terminator. As you said, commercial translators can handle this sort of stuff without problems. Homegrown programs may be a different story. Personally I think (and I know that my opinion is just that, an opinion) that either strict X12 syntax, or a "segment per line" type of syntax should be acceptable by all HIPAA receivers of transactions without complaint. As you said, the transmitters normally don't even know they have a problem, and may not be able to do anything about it. As for Claredi, we can take lots of variations in the delimiters on incoming transactions, but we will be giving a "warning" message if the delimiters are not strictly compliant with X12 syntax. This should alert the tester to either correct the problem or to put a notice about this in the trading partner agreement. This may change and Claredi may have to enforce the strict X12 syntax rules for delimiters if it turns out that HHS interprets it that way. For now we are being lenient on this, as it does not seem to be a problem. Other people's comments? DHHS' opinion? I am listening... Our test transaction generator can generate multiple syntax "variants" that test this sort of thing, so the receivers can test their ability to receive these variants. What am I talking about? The receivers ought to be able to receive delimiters in at least some of these variants: traditional *:~, one segment per line with or without the segment terminator, one segment per line padded with spaces, control characters, 8 bit set characters, segments "wrapped" with line feeds every 80 bytes (or 132, or other length), and some combinations of the above. If you test all of these and make sure that you can receive and handle X12 transactions with this sort of hard to handle delimiters, you should be OK receiving the simpler stuff. I hope this helps. Kepa Rachel Foerster wrote: > > Kepa, > > Your advice is good. > > Re your observation that some systems generate a CRLF as a segment > terminator....this is often done by PC-based low-end systems. Most of the > major commercial EDI management systems have evolved over the years to be > able to handle this circumstance, even though we know that the X12 standards > specify that the terminator character is a single character. > > As is usually the case, it's the receiver of something not quite standard > that must find a way to handle it, especially since in many cases the > originator actually has little if any control over what is being generated. > > This does bring up an interesting point, however, in that the use of CRLF as > a segment terminator clearly is not compliant with the X12 standard, but > common non-health care EDI community practice over the years has evolved to > accommodating this variant. What do you think this might mean for any strict > compliance validation with the X12 standards? > > Rachel Foerster > Principal > Rachel Foerster & Associates, Ltd. > Professionals in EDI & Electronic Commerce > 39432 North Avenue > Beach Park, IL 60099 > Phone: 847-872-8070 > Fax: 847-872-6860 > http://www.rfa-edi.com <http://www.rfa-edi.com> > > -----Original Message----- > From: Kepa Zubeldia [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 18, 2001 12:49 PM > To: [EMAIL PROTECTED] > Subject: Re: Segment separators - Translators > > Joe, > > I think you have two choices: > > 1) fix the program in the mainframe to handle these very long files > without carriage returns in them. > > 2) pre-process the files to change the segment terminator into something > more palatable to your mainframe. > > However, be careful with option #2, because when you get a 275 > transaction (future claims attachment HIPAA transaction, in the works) > that contains an embedded HL7 transaction for which the delimiter will > also be the CR-LF, your translator could get pretty confused. > > And, for some people the new line is CR (e.g. macIntosh), for other > people it is LF (e.g. UNIX) and for other people it is CR-LF (e.g. > MS-DOS) and that is actually two bytes. X12 syntax say that the > delimiter is only one byte. > > Good luck. > > Kepa > > "BARTON, Joe" wrote: > > > > All the HIPAA transaction examples I have seen, and IG's use a tilde for a > > segment separator. This segment separator is defined in the ISA segment at > > the top of the transaction set. I have referenced in BizTalk server 2000 > > documentation where a carriage return is the most common choice as defined > > in X12 standards dictionary X12.22 Our Unisys mainframe can handle a > > segment as a record containing a carriage return very well, but not > several > > thousand segments as one record if the tilde is the separator. Your > comments > > on this matter are appreciated. > > > > Joseph "JP" Barton > > Information Technology Applications Specialist > > State of Washington DSHS/ASD/OIS > > (360) 664-6147 {mailto:[EMAIL PROTECTED]] > > > > CONFIDENTIALITY NOTICE: This email message is for the sole use of the > > intended recipient(s) and may contain confidential and privileged > > information. Any unauthorized review, use, disclosure or distribution is > > prohibited. If you are not the intended recipient, please promptly delete > > this message and its attachments from your computer system, and notify the > > sender. All messages to and from the Department of Social and Health > > Services may be disclosed to the public. > > > > . > > > > <<BARTON, Joe.vcf>> > > > > ********************************************************************** > > To be removed from this list, send a message to: > [EMAIL PROTECTED] > > Please note that it may take up to 72 hours to process your request. > > ********************************************************************** > To be removed from this list, send a message to: > [EMAIL PROTECTED] > Please note that it may take up to 72 hours to process your request. > > ********************************************************************** > To be removed from this list, send a message to: [EMAIL PROTECTED] > Please note that it may take up to 72 hours to process your request. ********************************************************************** To be removed from this list, send a message to: [EMAIL PROTECTED] Please note that it may take up to 72 hours to process your request. ********************************************************************** To be removed from this list, send a message to: [EMAIL PROTECTED] Please note that it may take up to 72 hours to process your request.
