Question-Why would anyone go through the trouble to send an 835 to a bank?
Our EFT process includes sending the 835 to the provider and the EFT
transaction to the bank. This deposits a gross amount in the providers bank
account with a tracking number while providing the detail of the remittance
to the provider.
It seems confusing to route ANSI Standard HIPAA compliant transactions
through a financial institution.
Thank you,
Terry Christensen
[ IS Administration Simplification EDI
Telelphone: (402)351-6370
Fax: (402)351-8025
e-mail: [EMAIL PROTECTED]
"Rachel
Foerster" To: [EMAIL PROTECTED]
<[EMAIL PROTECTED] cc:
tcom.com> Subject: RE: questions on the appropriate
way to reply when there are
error in a transaction request
04/22/2002
04:01 PM
Please respond
to
transactions
Jan,
It's a mistake to believe that the banks translate the X12 interchange into
an ACH format. That's simply not true. When an X12 interchange is sent to a
bank with payment instructions and table 2 data (RA stuff) the entire
interchange is dumped into a CTX format. It's just a wrapper around the X12
stuff and no translation takes place.
When the banks perform this activity with no other value-add services being
done either on behalf of the payee or payer, they are simply a conduit and
they are neither a business associate or a covered entity under HIPAA.
On the other hand, if the bank provides additional services, such as
reformatting the received table 2 data in an 835 into another format and
then forwards that on to its customer, the provider, it is acting as a
clearinghouse, thus becoming both a covered entity and a business
associate.
I also believe the same would be true if the bank received the 835 table 2
data and put it on paper to send to its customer.
Encrypting is the entire interchange is not an option if sending the
complete 835 through the banking system. The 835 table 1 data must be in
the
clear since this is where all of the payment instructions are found. In
this
case, then encyrpting table 2 would be the only option for ensuring the
confidentiality of the PHI. But, this approach, of course, has all sorts of
issues and challenges.
And deciding to separate the data from the dollars has its own set of
issues
as well, not the least of which is the receiving system's ability to
receive
the 835, recognize that its RA only, that payment will be made
electronically and thus to suspend posting of the RA until notified by the
bank that the funds have been received, matching the 835 to the funds
received notice from the bank, etc.
Rachel
-----Original Message-----
From: Jan Root [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 22, 2002 12:36 PM
To: [EMAIL PROTECTED]
Subject: Re: questions on the appropriate way to reply when there are
error in a transaction request
I could be way wrong or stating the obvious, but I thought banks were ruled
to (possibly) be covered entities when they qualified to be classified as
clearinghouses under HIPAA...? See quote from FAQ:
"The definition of Business Associate at 45 CFR 160.103 applies generally
to
a person or organization that performs, on behalf of a covered entity, a
function or activity involving the use or disclosure of protected health
information or any other function, activity, or service covered by the
Administrative Simplification regulations. If the network in the question
accesses or uses
protected health information on behalf of a covered entity, whether for
translation or payment or quality assurance or other purposes, it is
onsidered a business associate. "
Translating payment data (associated with a particular person - there may
be
additional privacy issues possibly involved here as well if banks get
classified as clearinghouses) in and out of the ACH format meets the
definition of a clearinghouse, no? And the 835 is designed with the option
of sending it to a bank. I thought this was why Finance got involved in
the
discussion with the
835 WG. They realized that HIPAA might be applied to them.
Let me know if I'm off base here....
Jan Root
"William J. Kammerer" wrote:
> Hey! I have one for you all! Take a look at the 837 Professional IG
> (004010X098) - it uses a loop (2440) at the end of the transaction which
> IS NOT in the underlying 004010 standard! What would you do in this
> case? Send back a negative 997 indicating an X12 syntax error if the
> 2440 loop were actually used? See if you can make hay with that!!
>
> I agree with Ajay that the 997 *could have* been made to report
> elegantly on IG errors, but as Rachel has informed us, the DM to change
> the 997 failed - though I wouldn't have used her term "resoundingly
> disapproved." The 997 DM was actually approved by the full X12
> membership, but X12 constitutional legerdemain was used by X12F Finance
> to find new votes (pregnant chads) after the fact in order to kill it.
>
> Anyway, X12N Insurance was apparently interested in trying to resurrect
> the 997 capable of reporting on the IGs. The battles are now heating up
> between X12N and X12F: we actually witnessed a scene last February at
> the X12 meeting where X12F accused X12N of bastardy. Well, actually, to
> be truthful, the term liberally used was "illegitimate": "in the
> illegitimate 835 implementation guide...", "...the illegitimate 'DSMO'
> process...," and "specific Implementation Conventions (such as those
> illegitimately published by Insurance)."
>
> Finance wants the 997 left as it is, for X12 syntax reporting only.
> Further, X12F isn't even all that wild about X12N's proposed changes to
> fully support IG reporting in the 824! After all the mutual anathemas
> were cast about, the only "compromise" countenanced by the X12F
> patriarchs is for someone to build an entirely new transaction set
> modeled on the 997 for reporting on IG syntax errors: the
> eschatologically monikored "666" - the Mark of the Beast.
>
> Finance didn't like a 997 which could report on implementation guide
> errors. Banks thought for some reason they could be exposed to some
> kind of liability if they received a negative IC-specific 997 from the
> payee in response to an 820 (or 835) - the payee bank would not be
> prepared to handle the "tuned" 997. I didn't understand all the
> scenarios, which involved dealing with parties not customers of the
> bank: 820 RAs travel through the ACH network, but there would be no way
> to get the IG-specific 997 back to the original sender, or something
> like that. And because the funds had already been transferred, one or
> both banks wouldn't know what to do.
>
> Of course, if banks didn't kludgily send remittances through ACH, the
> problem wouldn't exist. And they can't do this anyway with the advent
> of HIPAA because EOBs contain PHI. Payment shouldn't be confused with
> remittance. The 835, like the 820, seems to have been designed to mimic
> the old paper remittance, which included the check under a perforation.
> This document paradigm has been carried over to the electronic arena.
> An EFT payment is an order to one's own bank (with whom you already have
> a relationship) to deposit funds in another account, usually at another
> bank. The payee has no (necessary) relationship with the payer's bank -
> though the banks themselves have a relationship through the ACH system.
>
> The remittance, or EOB, on the other hand, explaining the payment (and
> containing PHI), is none of any bank's business - payer's or payee's.
> It's strictly between the payer and payee. Banks are not CEs and can't
> even legally look at the stuff: it has to be encrypted. But if the 835
> were encrypted, how would the bank read the BPR? Why the two - EOB and
> dollars - should ever travel together is beyond me, unless to slavishly
> mimic the paper remittance. And so banks can bill themselves as "Value
> Added Banks," Unfortunately, this practice has caused all this ruckus
> over the innocuous IG-reporting 997.
>
> William J. Kammerer
> Novannet, LLC.
> +1 (614) 487-0320
>
> ----- Original Message -----
> From: "Ajay K sanghi" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, 22 April, 2002 08:36 AM
> Subject: RE: questions on the appropriate way to reply when there are
> error in a transaction request
>
> Rachel,
>
> Thanks for your response.
>
> I guess, for a translator vendor, it means, support "both" ways of doing
> it, since some customers will probably use only 997 while some will use
> combination of 997 and 824 to report HIPAA guide errors, especially in
> absence of clear guidelines mandated by HIPAA.
>
> Regards,
>
> Ajay
>
> ----- Original Message -----
> From: "Rachel Foerster" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, 21 April, 2002 01:17 PM
> Subject: RE: questions on the appropriate way to reply when there are
> error in a transaction request
>
> The implications are, in my mind, that forward thinking EDI management
> systems vendors will see the opportunity to add new capabilities to
> their product offerings that serve the needs of a very large potential
> market. Just because current EDI systems don't automatically generate an
> 824 today like they can for a 997, doesn't mean that they couldn't if
> they wanted to. The X12 standards neither require nor prohibit either
> approach. Furthermore, other industries beyond health care also have
> this need.
>
> And, several of the country's leading EDI management systems vendors are
> actively involved in the current work being done at X12N on adding new
> codes, etc. to the 824 to support the insurance industry's needs, but
> also, as Ruben has pointed out, are hard at work developing an
> impelemtation guide for the industry to use for the 824. These companies
> include IBM, Sybase, Unisys...and my apologies to others whose names I
> can't immediately recall.
>
> Lastly, the pioneers that created our X12 standards also recognized that
> standards must be able to change to meet new needs. Thus, if the issues
> you mentioned relative to the 824 prevent it from supporting the needs
> of the users, changes will be proposed and modifications made to meet
> the new requirements. That's why the current body of X12 standards
> includes hundred's of transactions, technical reports and guidelines
> over the first version of the X12 standards in 1983 which contained 6-10
> transactions only, no technical reports or guidelines.
>
> Rachel
>
> ----- Original Message -----
> From: "Ajay K sanghi" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, 21 April, 2002 01:13 AM
> Subject: RE: questions on the appropriate way to reply when there are
> error in a transaction request
>
> Rachel,
>
> You wrote:
> >The need for the 824 is crucial to effectively managing the HIPAA error
> reporting environment.
>
> Possibly, even though at this time I am not convinced.
>
> Looking at 824 (particularly OTI segment), it seems that "unlike" 997,
> 824 is "not meant" to be generated directly by the translator
> (Translators will still be able to directly generate it, is a separate
> issue). Reason for this is because fields like "transaction/group
> control numbers", which are "not" normally communicated to business
> application are "optional" in 824 (mandatory in 997). Rather, business
> identification fields (please see OTI02, OTI03) are mandatory.
>
> What implications would this have?
>
> You wrote: > While the 997 can be kludged to report guide syntax errors,
> such as missing mandatory segment or element or an invalid ***X12***
> code, it cannot report an invalid medical code, for example, nor any
> semantic errors, nor inter-segment dependency errors.
>
> I respectfully disagree. Please reject 997 (and use 824 instead) for
> right reasons and not wrong reasons.
>
> For example,
>
> (a) invalid medical code (I assume you mean codes from external code
> sets).
>
> This can be "easily" reported using AK403[7]. Even non-coded data
> elements, where a certain "pattern" of text is desired, can "also" be
> reported using AK403[7]
>
> (b)inter-segment dependency errors
>
> All these errors, ultimately boils down to a "situational"
> element/segment being "required" or "not used".
>
> This can also be "easily" reported. Use AK304[3] (Mandatory Segment
> Missing) for "situational" segments, which are "required" in certain
> situations. Use AK304[2/7] (Unexpected Segment/Segment not in proper
> sequence) for "situational" segments, which are "not used" in certain
> situations.
>
> Ditto for other situations, there's no problem. Please tell me
> situations, where there is difficulty in reporting such errors. Is there
> a document, which list situations that cannot be reported using 997 but
> can be reported using 824 (related to compliance of HIPAA messages
> only)?
>
> Please note, in 997 we can also report sequence number (exact position
> of the segment in the interchange file, which triggered this error)
>
> Some situations for which there is difficulty in reporting errors using
> 997, possibly cannot not be reported even by 824! For example, "a
> situational element is required if the corresponding value was already
> received (I think this was in relation with 2nd 837P being generated to
> a secondary payer in response to 835 received from the primary payer)".
>
> I re-iterate from my earlier email:
>
> There was no difficulty in generating a corresponding 997 for following
> cases:
>
> (a) Inter-element dependencies within segment.
> (b) Inter-element dependencies between two different segments of same
> hierarchy.
> (c) Inter-element dependencies between elements of different hierarchy.
> (d) Inter-segment dependencies in the same hierarchy within a loop.
> (e) Inter-segment dependencies between segments in different hierarchy.
> (f) Dependencies on external code set for certain elements (both simple
> and qualifier based (SV101)).
> (g) Dependencies on certain "patterns" of text in some elements."
>
> Ajay
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Rachel Foerster
> Sent: Friday, April 19, 2002 10:00 PM
> To: [EMAIL PROTECTED]
> Subject: RE: questions on the appropriate way to reply when there are
> error in a transaction request
>
> Ajay,
>
> Absolutely not! The 824 is the only transaction that can effectively
> support semantic non-compliance errors with a guide. While the 997 can
> be kludged to report guide syntax errors, such as missing mandatory
> segment or element or an invalid ***X12*** code, it cannot report an
> invalid medical code, for example, nor any semantic errors, nor
> inter-segment dependency errors.
>
> The need for the 824 is crucial to effectively managing the HIPAA error
> reporting environment.
>
> There is a snowball's chance in Hell of the X12 Committee membership to
> agreeing to modifying the 997 to report implementation guide and
> semantic errors. This has already been attempted and the voting members
> resoundingly disapproved, with me being one of them.
>
> Rachel
> Rachel Foerster
> Principal
> Rachel Foerster & Associates, Ltd.
> Professionals in EDI & Electronic Commerce
> 39432 North Avenue
> Beach Park, IL 60099
> Phone: 847-872-8070
> Fax: 847-872-6860
> http://www.rfa-edi.com
>
> **********************************************************************
> 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.
**********************************************************************
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.
