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
