Mary, a segment terminate that consists of the tilde, a carriage return and a line feed would be 3 characters and would absolutely non-compliant X12 - I believe what Kepa and others (and by the way, this topic was discussed in excruciating detail a few months back as well so you may wish to search the archives) were indicating that in some cases, na�ve programmers of EDI transaction generators only seem to be able to work in an ASCII text mode which puts a CRLF after each segment as the segment terminator.
While this is not acceptable X12 syntax, which requires a single character as the terminator character, over the years in most industries where there are PC-based systems interacting with other platforms, most of the major commercial EDI management systems can handle a CRLF as the segment terminator. Additionally, of course, this character combination would have to be specified with that specific trading partner's profile on the respective systems. Thus, the practice of using ONLY a CRLF as a segment terminator shouldn't really be a cause for rejection of the Interchange. Rachel Foerster -----Original Message----- From: Mary Burkinshaw [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 9:44 AM To: WEDI SNIP Transactions Workgroup List Subject: RE: Valid file formats Kepa, I recall reading that post (but no longer have it) but I guess that recollection too raised the question in my mind. I have used the Cleo 3780 bisync for Wal*Mart and as I recall, the data did come in the "unwrapped format" (That was in 1996, and I do not always trust my 'memory'). Too, that was Retail.. a different animal. And I have seen files with "padded" spaces beyond the segment terminator, other than transmission slowdown, they caused no problem. Lisa's post made me stop and think. I did not want to go into 'comm' details to confuse the issue, but I guess that IS a big part of it. My concern was for the original question, as to whether or not this is acceptable... if it is beyond the Interchange and is actually related to the transmission. So in that regard, a file that is received in the "~ cr-lf" format is not one that is necessarily "Non Compliant" or "Rejectable", but more so related to a Trade Agreement and/or Communications Protocol. Correct? Thanks again! Mary Burkinshaw Axiom Systems, Inc. The Managed Care Technical Experts Germantown, MD 763.783.9024 Direct (Mpls.) 612.385.3015 Cell http://www.axiom-systems.com -----Original Message----- From: Kepa Zubeldia [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 8:02 AM To: Mary Burkinshaw; WEDI SNIP Transactions Workgroup List Subject: Re: Valid file formats Mary, It was Dave Feinberg that posted a very good explanation about this a couple of months ago. See below. In general the translators will produce a single byte segment terminator, but then the communications channel (e.g. 3780 bisync) may convert the segments into "records" thus producing an additional CR-LF after each record. Or perhaps the way the segments are stored in the file system cause this conversion into separate lines if it is stored as a "text" file in certain file systems. In fact I have seen datasets stored with a fixed line length of 320 bytes, with one segment per line, padded with spaces all the way up to 320 bytes. Talk about non-standard! As Dave explained, HIPAA does not set a standard for telecommunications or for storage of the data on disk. The data stream must be an X12 data stream with one byte as the segment terminator, but if your own communications or data storage system forces the addition of padding or record separators, that is your own problem. HIPAA does not force you to store these files as a byte stream in your own system. Keeping in mind that X12 is a data interchange standard independent of the telecommunications infrastructure, you should be able to produce the syntactically correct standard, feed it to the communications mechanism appropriate to each trading partner, and it should work. If the communications mechanism requires the data to be separated into "records" or "text lines", that is a telecom problem, not a HIPAA problem. Dave compared this to the 7 layers of OSI. The HIPAA requirements are for the application layer (Level 7) to be in X12 format or NCPDP format, with only one byte as the segment terminator. Layers below the application may add additional encapsulation requirements, including CR-LF, but those are outside of the scope of HIPAA. However, having said that, if the communication layer does not require you to do this sort of padding or encapsulation into "lines" or "records" then, don't do it. And, it would be inappropriate for a trading partner to require you to send the data encapsulated in an artificial manner over a communications channel that does not require such encapsulation. They should accept the X12 data without changes to the syntax. But, if their communications infrastructure only supports 3780 bisync in text mode, then you will have to break up the data segments into "records". -------------------------------------- A message Mon, 30 Dec 2002 17:29:20 -0800 from "David A. Feinberg, C.D.P." <[EMAIL PROTECTED]> (Rensis Corporation) said: Dave and Zena, Using the International Standards Organization's Open Systems Interconnect (ISO/OSI) model for reference, X12N's HIPAA-adopted Implementation Guides (IG's) generally specify only particulars for level 7 [Application] and level 6 [Presentation]. Very little is noted in the IG's regarding levels 5 [Session], 4 [Transport], and below. As long as the payors' or clearinghouses' blocking requirements are only for ISO/OSI levels 5, 4, and perhaps below, it is not generally covered by the IG's, and, as far as HIPAA is concerned, could be consequently subject to negotiation and documentation via trading partner agreements or companion guides. My guess from your messages is that this may be what you're writing about. If this is the case, you may wish to discuss the blocking requirements further with your translator suppliers. If my guess is in error, please let us all know. Dave Feinberg Rensis Corporation [A Consulting Company] 206-617-1717 [EMAIL PROTECTED] ----------------------------------------- I hope this clarifies it some. Kepa Zubeldia Claredi On Wednesday 12 March 2003 08:39 pm, Mary Burkinshaw wrote: > Kepa, > > I apologize, I miss-read Lisa's post. I was thinking of cr-lf as the > segment separator itself. > > I have seen many X12 documents sent "unwrapped" with the "~(cr-lf)", > but generally smaller 'test' files, where they were intentionally > unwrapped for > readability. I never really thought too much of it with concentrating > on data issues, that sort of thing seemed relatively minor. What > happens often > is they stream or block the data when they test the transmission > and/or go into production. > > I do not know of many translators that can 'create' a two-character segment > separator. That kind of "unwrapping" is often done outside of the > translator - or perhaps with a home grown mapper. > > Question: Would the file then be considered "non HIPAA compliant" with > a 2 character segment terminator? If it violates X12, should it in > reality be rejected? Just curious. > > Thanks, > Mary Burkinshaw > > Axiom Systems, Inc. > The Managed Care Technical Experts > Germantown, MD. > www.axiom-systems.com > > > -----Original Message----- > From: Kepa Zubeldia [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 12, 2003 8:00 PM > To: WEDI SNIP Transactions Workgroup List > Subject: Re: Valid file formats > > > Lisa, > > The X12 syntax specifies that the segment terminator is ONE single > byte. In > your case, it would be the tilde. To follow the segment terminator > with a Carriage Return, New Line, or both (CR-LF) is not correct > according to the X12 syntax. For chapter and verse, look at X12.6 or > even the somewhat simplified description in the IGs at Appendix A, > section A.1.2.7 where it says the delimiter is ONE byte. Or the note > #1 for the ISA segment (Page B.3 of the IGs). The definitive document > on X12 syntax issues is X12.6. > > Having said that... most translators will accept a Return or New Line > or both after the segment terminator without complaining too much, > even though it is > technically in violation of the X12 syntax. > > The X12 syntax calls for a "byte stream" but the tradition has been to send > a > byte stream whenever possible and accept a line-oriented transaction > set as > an alternative mechanism when receiving files. > > I hope this helps. > > Kepa Zubeldia > Claredi > > > > On Wednesday 12 March 2003 11:21 am, Eney, Lisa wrote: > > Can an 837P (or any other transaction) file which is formatted so > > that segment identifiers are aligned to the left (with tildes > > essentially functioning as hard returns) be considered a HIPAA > > compliant format? > > > > For example: > > > > ST*837*0001~ > > BHT*0019*00*0001*20020824*0000*CH~ > > REF*87*004010X098D~ > > > > I do not think that it would be, but now that I find myself in a position > to > > defend that idea, I am unable to find the chapter and verse in the > > IG to support it. Any help in this matter would be greatly > > appreciated. > > > > Thanks, > > Lisa > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Lisa Eney > > Project Manager > > HIPAA Claims Transaction Code Sets > > ADMS - Baltimore > > 410.209.5216 > > [EMAIL PROTECTED] --- The WEDI SNIP listserv to which you are subscribed is not moderated. The discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-transactions as: [EMAIL PROTECTED] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org --- The WEDI SNIP listserv to which you are subscribed is not moderated. The discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-transactions as: [EMAIL PROTECTED] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org
