Very good! I'm sure you got a bonus for your work with that too. Hopefully
you will. Take care - keep me posted about the house :-)
-----Original Message-----
From: Gentile, Rob [SMTP:[EMAIL PROTECTED]]
Sent: Wednesday, July 17, 2002 11:34 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Multiple ISA/IEA segments
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.
**********************************************************************
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.
