Rachel I think I am on too many lists... My apologies to who ever quoted from the rule in this discussion... I clearly got the name wrong...
Jan Rachel Foerster wrote: > Jan, > > I'm not sure what "exception cited by Sujay" you're referring to. I didn't > see any message in this thread from a Sujay.....clarification please? > > Thanks, > > Rachel > > -----Original Message----- > From: Jan Root [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 23, 2002 8:26 AM > To: [EMAIL PROTECTED] > Subject: Re: questions on the appropriate way to reply when there are > error in a transaction request > > Rachel > Thanks for a good explaination of the details. It seems that banks, like > many entities, must look at what role they are playing in the process to > determine if they are HIPAA covered entities, business associates or > neither. Judging from the article David circulated, banks have only > recently become aware that HIPAA may impact them. I can understand that > such a realization would be > something of a shock. > > So, does the exception cited by Sujay apply when a bank is acting as a > clearinghouse, that is, as a covered entity and not as a 'financial > institution'? I would guess not...? > > Jan > > Rachel Foerster wrote: > > > 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. > > ********************************************************************** > 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.
