Does anyone have any information on whether PPOs are business associates or covered entities? One of my co-workers recently attended a conference where the consultants and legal advisors were stating that PPOs were covered entities, we had previously been advised that PPOs were business associates.
-----Original Message----- From: Jan Root [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 23, 2002 6: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. ************************************************************************************************************* Confidentiality Statement-This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited, and that you have received this e-mail and any accompanying files in error.You may not copy, publish or use them in any way and you should notify Beech Street Corporation immediately by replying to this message and deleting them from your system.Beech Street Corporation does not accept responsibility for changes to Emails that occur after they have been sent. ************************************************************************************************************* ********************************************************************** 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.
