Hi, William & WEDI folks! Excellent comments! And I totally agree... in theory.
Life, and reality, though seldom work out the same as theory. Payers are dependent on sundry vendors just like providers are, meaning we use software that works similarly but exactly as advertised. It's that "not exactly as advertised" that affects even the business relationships we all have. Let me give a recent, real world example. I recently setup translators in our Hipaa enable interface engine to take inbound 4010 834's (enrollments) and 820's (premium payment) and create various flatfiles from them. I developed and successfully tested them on the sample files our partner provided, which were on the order of 20 k or so in size. Looking good so far. We're ready...or so we thought.... Fast forward: We receive the live file, but it's not the 20K or so sized files we tested with, rather, it's a single 45 MEGAbyte file which contains over 80,000 patient records. In theory, this was a perfectly acceptable, well formed, valid and HIPAA compliant file. Same as the testing file, only more so, right? Well, not exactly...Ya see, the problem was, it caused a core dump on our interface engine. (unix version of Blue Screen of Death). Not able to load the file. Oops. Not good. I contacted our software vendor: their response: 45 megs is too big.... workaround is to break it up before it gets to interface engine. Gee, thanks for stating the obvious. Good thing I can write code!... I had no choice but to spend many hours creating a script to break the 45 megabyte, 800+ ST/SE loop 834 file into many smaller chunks that would not hose our interface engine. >>>Input: 45 meg 834 with 800 ST/SE...output: 800 smaller, single ST/SE 834 files. Two weeks later, we received a 10 megabyte, single ST/SE segment 820. Guess what? It caused a core dump. Round 2: More stat coding. >>>Input: 10 meg 820 one ST/SE ...output: many smaller, single ST/SE 820 files. Fortunately, in the end, we were able to work around an unexpected software limitation. Unfortunately time limitations (we specifically needed to process the 834s for use downstream to create 80,000 id cards) forced me to create a preprocessor in one marathon 30 hour session, (no sleep). Other organizations may not have the same commitment or access to resources. If a provider cares about turnaround time for Accounts Receivable, and lives in the real (not theoretical) world, it's good business to make sure the 'other end' can really process what you want to send. Regards Rob Gentile Senior Systems Analyst / HIPAA Technical Lead Christiana Care Health System Voice (302) 324-3735 Fax (302) 324-3754 At any given moment, life is completely senseless. But viewed over a period, it seems to reveal itself as an organism existing in time, having a purpose, trending in a certain direction. -Aldous Huxley (1894-1963) > -----Original Message----- > From: William J. Kammerer [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, July 17, 2002 10:22 AM > To: [EMAIL PROTECTED] > Subject: Re: Multiple ISA/IEA segments > > As Jonathan Allen has assured us, it is certainly valid X12 usage to > include multiple interchanges within a single transmission. The HIPAA > IGs go even further, and confirm that it is perfectly permissible to > embed multiple transactions within a single functional group, or > multiple functional groups within a single interchange. There are even > pictures of this in the appendices covering control structures! > > So, certainly, if the implementation guides themselves say this is > acceptable, wouldn't a payer who refuses to accept, or rejects, > transactions packaged in Dana's example be non-compliant? If folks > thought this might be too difficult to handle, shouldn't the HIPAA IGs > have said something else - or explicitly put restrictions on the number > of functional groups per interchange or the like? > > Now, if I were cobbling together outbound transactions, I would probably > choose to use the simplest structure - in effect, the lowest common > denominator of a single transaction within a single functional group per > interchange - just to be safe. I'm a considerate and thoughtful guy. > But it seems the recipient would have no business *demanding* the > simpler structure in any case; if the sender insisted on submitting a > multiply packed interchange, I can't see how the receiver could balk at > processing it: she should either just fix her EDI translator or > manually break apart the transactions. Or she could always participate > in the DSMO process to have the HIPAA IGs changed. > > Jonathan suggests that there might be "trading partner considerations" > here. What does that mean? Are we back to one-off interpretations of > implementation guides, where the dominant partner (usually the payer) > arbitrarily re-interprets the standard? As it stands, there are > probably far too many places in the HIPAA IGs subject to partner > "negotiation." For example, use of "extended" characters (see Appendix > A.1.2.3) like the at-sign (@) and lower-case characters are presumably > subject to partner negotiation! Just how the heck do you send an e-mail > address in the PER segment without using the at-sign? Or do you have to > negotiate a tedious TPA just to use characters present on every > keyboard? Does it grate you that you need "permission" to use > lower-case characters? I've used those since 2nd grade; why can't payers > handle them? Wouldn't it be simpler for the HIPAA IG to say you can use > any character allowed by X12? - in effect, any graphic shared by EBCDIC > and ISO 8859 Latin-1 - so you should be able to handle names of those > with umlauted pretentiousness, like "Larry von B�low". Hmmm... are the > sundry testing and certification vendors checking for this type of > stuff? > > William J. Kammerer > Novannet, LLC. > Columbus, US-OH 43221-3859 > +1 (614) 487-0320 > > ----- Original Message ----- > From: "Jonathan Allen" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, 17 July, 2002 08:29 AM > Subject: Re: Multiple ISA/IEA segments > > > Dana Grant asked: > > > Can anyone tell me if it is within the ASC X12 standard to be allowed > to > > send multiple ISA/IEA segments? For example, within one file can > there be a > > sequence of segments > > ISA - GS - ST - SE - GE - IEA - ISA - GS - ST - SE - GE - IEA. > > Yes, this is a perfectly X12-valid set of segments, making up two > complete interchanges. Each ISA/IEA pair envelopes one interchange. > > > If this is a valid sequence, is an entity considered to be > non-compliant if > > they are unable to accept a multiple ISA/IEA enveloping structure? > > From a pure X12 standpoint, any receiver that cannot accept two > consecutive interchanges has a fairly broken translator. There may be > trading partner considerations of course ... > > Jonathan > ------------------------------------------------------------------------ > Jonathan Allen | [EMAIL PROTECTED] | Voice: > 01404-823670 > Barum Computer Consultants | | Fax: > 01404-823671 > --------------------------------------------------------------------- > > > > > > ********************************************************************** > 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. > > ====================================================== > 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/. > Posting of advertisements or other commercial use of this listserv is > specifically prohibited. ********************************************************************** 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. ====================================================== 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/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.
