Just a point of information re using the IBM bisync comm protocols of 2770, 3770 and 3780 - years ago in the mid-1980's I learned that when using these protocols you should set transparency such that any control characters found in the data stream, (such as a CR (Hex0d) for example) are not recognized as such by the comm protocol. . . . Can't remember if it's transparency on or off and I no longer have the IBM resource manual on these protocols.
Additionally, the data transfer blocksize should be set appropriately and agreed to between the two communicating systems. Lastly, there are all kinds of comm protocol emulators and many of them don't always emulate these IBM bisync protocols exactly the same way.... Rachel Foerster -----Original Message----- From: Kepa Zubeldia [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 8:02 AM To: 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
