Mary, The trading partner agreement could specify things like protocol, ASCII vs EBCDIC, speed, text vs. binary, record length, blocking size, transparency, etc. Some of these parameters could affect the transmission of the data. But, beyond data transmission parameters, one trading partner should not force another trading partner to create the files in a specific way.
For example, the receiving trading partner should NOT specify what are the required delimiters in the X12 stream. The choice of delimiters (segment terminator, element separator, sub-element separator) is up to the sender of the transaction, and the receiver should accommodate the sender's choice of delimiters. The receiver could make recommendations, for instance, clarifying that certain "control characters" should not be used as delimiters because they could interfere with the communications protocol, but that is different from requiring specific delimiters. Kepa Zubeldia Claredi On Thursday 13 March 2003 08:44 am, Mary Burkinshaw wrote: > 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
