By definition clearinghouses are permitted to conduct transactions in a non-standard format with one of the two other covered entities involved in the transaction.
The real questions, which remain unanswered, are: a) how will enforcement for the transaction standards occur? how aggressive will t be? b) will some covered entities take fines as the cost of doing business c) will covered entities who are ready choose to decline non-standard transactions from their stakeholder-trading partners who are not? -----Original Message----- From: Rachel Foerster [mailto:[EMAIL PROTECTED]] Sent: Saturday, October 27, 2001 9:27 AM To: WEDI SNIP 2 (E-mail) Subject: Issue from a recent conference] All, I'm behind in reading these messages, but below is my perspective that I sent to Kepa earlier today. I don't know if I've captured or identified the core issues, but let's continue the discussion. It certainly would help if someone who has been following this thread thoroughly could briefly enumerate the core issues/questions we are trying to address. In general terms here's my understanding of the law and regs: 1. Covered entities are defined in the law 2. Covered entities **must** conduct the specified transactions as standard transactions on and after 10/16/02 3. Covered entities **cannot* conduct transactions between themselves if a standard transaction and implementation specification has been adopted 4. A health care provider can choose to mix/match claims from paper to electronic - as long as the electronic are conducted as a standard transaction 5. Once a health care provider conducts **any** of the specified transactions electronically after 10/16/02 they become a covered entity; once a covered entity, always a covered entity, and therefore all the rules now apply. 6. A covered entity is not **required** to conduct a transaction as a standard transaction with a non-covered entity 7. Health plans and clearinghouses are **always** a covered entity and **cannot** conduct a transaction as a non-standard with another covered entity; all such transactions between covered entities must be conducted as a standard transaction What have I missed? Rachel -----Original Message----- From: Rachel Foerster [mailto:[EMAIL PROTECTED]] Sent: Saturday, October 27, 2001 10:28 AM To: 'Kepa Zubeldia' Subject: RE: [Fwd: Re: Issue from a recent conference] Kepa, I'm behind on email since I've been out on the road since last Sunday. However, a quick read of this message you forwarded below leads me to conclude that the assertion seems to be generally. . . 1: that any "person" can request a health plan to conduct a standard transaction 2: that the "request" may be unanticipated and dynamic by the mere act of receiving a transaction 3: that the "request" is dynamic and not pre-determined and pre-agreed to 4: that the "person" making the "request" can be any person or entity, not a "covered entity" Is this the essence of the discussion? Have I missed a key point? Whenever I'm unclear as to someone's interpretation of either the law or the reg, I first look to the law for clarity. In this case relative to #4, I would say that the law's section on applicability clarifies this issue when it defines to whom the law applies by describing/defining "covered entities." Thus, my conclusion is that everything else after that in both the law and the regs applies **only** to covered entities as defined in the law and further that the use of the terms entity or person refers back to a "covered entity." Thus, in my mind if the person requesting is not a covered entity, everything in the law and the regs is off the table and does not apply even though the health plan is a covered entity. So, let's take #1. Sure any person can request a health plan to conduct a standard transaction. But under the law, the health plan is required to conduct a standard transaction **only** with a covered entity, and further, that a health plan cannot conduct a non-standard transaction with a covered entity. On the other hand, a health plan is **not** obligated **under the law** to conduct a standard transaction with a non-covered entity, but as a matter of business, it may either **choose** or not choose to do so. Business reality would indicate that a health plan would certainly want to **standardize** by using the standard transactions wherever possible regardless of whether the trading partner is a covered entity or not. Re points #2-3. There is nothing in my read of the law that says that the health plan has to conduct a standard transaction on the fly with any person that **comes knocking on the door** without the prior establishment of such a relationship. In other words, a health plan must be prepared to receive a standard transaction without prior notice. On the other hand, my mind asks the question, "What about the non-contracted or non-participating provider that delivers health care to a member and now submits a claim for payment?" So, generally to this point, I would say that yes, a health plan must be prepared to **at a minimum** take in a standard transaction from another **covered entity** through the EDI front door. Once it's been accepted through the EDI door as a complying standard transaction, then other business rules may and should be applied to determine any subsequent processing. This is a bit different than what one finds in the non-health care EDI environment, where almost all EDI exchanges are established, agreed-to, and tested prior to the actual production exchange of messages. On the other hand, with the standardization (??!!) of both format and data content for health care, the dynamic receipt of standard transactions without knowing the originator in advance becomes a possibility -- but **only** (in my opinion) once the standard identifiers for providers, health plans and employers are adopted. Without these, the receiving entity has no way to authenticate the originator, and with assurance respond with **protected health information**. To do so would place the responder, i.e., the health plan, at risk for violating the disclosure of PHI provisions of the law and the privacy reg, and thus become subject to penalty. So, if I was the health plan I would keep in mind the privacy requirements and establish a policy regarding the receipt of unanticipated standard transactions from unauthenticated entities/persons. My policy and business rule might go along these lines: 1: If a standard transaction is received from an unknown and unauthenticated source, first validate that the transaction is in compliance with the standard, then authenticate the originator (tough to do with today's EDI systems that won't find a trading partner relationship set up - so this will require some innovative processing here). If the originator can be authenticated in compliance with our authentication rules, then further processing of the transaction **may** proceed. 2: It is our policy that all transactions will be conducted by us as standard transactions. Therefore, if a non-covered entity requests us to conduct non-standard transactions with them when a standard transaction can be used, we will deny that request and work with the requester to establish the exchange of standard transactions for the requested information exchange. And most certainly, the health plan (covered entity) **must** have its policies and rules established for **authenticating** any person/entity (covered or not) prior to responding to any request for information or to conduct a transaction (whether electronic or not) which would result in the disclosure of PHI. It's in this area that I think a lot of the privacy consultants/lawyers/gurus are overlooking the EDI aspect of HIPAA. Kepa, does this get to the heart of the matter, or have I missed something? Feel free to post my comments to the list in which this discussion started. Rachel -----Original Message----- From: Kepa Zubeldia [mailto:[EMAIL PROTECTED]] Sent: Friday, October 26, 2001 9:42 PM To: Rachel Forester Subject: [Fwd: Re: Issue from a recent conference] Rachel, Have you followed this thread ? Kepa -------- Original Message -------- Subject: Re: Issue from a recent conference Date: Fri, 26 Oct 2001 11:42:59 -0400 From: [EMAIL PROTECTED] Reply-To: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Kepa, Unfortunately I find myself in disagreement with both you and Jonathan. The only worse fate (for me) would be if Rachel agrees with you guys. It's hard to believe HHS could make something entitled "Administrative Simplification" so complicated. Best regards, Mark My interpretation of 162.925 and this issue between us is as follows: � 162.925 Additional requirements for health plans. (a) General rules. (1) If an entity requests a health plan to conduct a transaction as a standard transaction, the health plan must do so. (2) A health plan may not delay or reject a transaction, or attempt to adversely affect the other entity or the transaction, because the transaction is a standard transaction. (3 -5) omitted. The key words are "entity" and "requests". The wording does not say "covered entity", therefore the rule requires that ANY (non-covered) entity (sponsor, employer, etc) may require a standard transaction from the health plan. The other key word, "requests", is where I think you are getting it wrong. "Requests" are accomplished by deed (sending a standard transaction) not by word (written or otherwise). While some health plans may want to respond to all transactions (paper or otherwise) from all entities (non-covered) with a standard transaction, and are free to do so if the other (non-covered) entity agrees; these other (non-covered) entities cannot require (force) health plans to respond to a non-standard transaction with a standard transaction. Providers who submit paper are treated as any other (non-covered) entity for purposes of that transaction and any response to that transaction. The way any entity "requests" the health plan to conduct a standard transaction is by submitting a standard transaction. A "request" can not be done by throwing a paper claim through a window with a note attached with the words "send it back in a hipaa standard transaction". The submission of a standard transaction from a non-covered entity to the health plan is the "request" "............................... If a person conducts a transaction (as defined in � 160.103) with a health plan as a standard transaction, the following apply: ........... The health plan may not refuse to conduct the transaction as a standard transaction. ............" ".................We interpret this provision to mean that there should be no degradation in the transmission of, receipt of, processing of, and response to a standard transaction ...................................." (full text and cite below) The commentary at 50316 Federal Register / Vol. 65, No. 160 / Thursday, August 17, 2000 / Rules and Regulations speaking to 162:923 and 162.925 supports this. 4. Conducting the Transactions Proposal Summary: If a person conducts a transaction (as defined in � 160.103) with a health plan as a standard transaction, the following apply: (1) The health plan may not refuse to conduct the transaction as a standard transaction. (2) The health plan may not delay the transaction or otherwise adversely affect, or attempt to adversely affect, the person or the transaction on the ground that the transaction is a standard transaction. commentary omitted................... Response: Section 1175 of the Act prohibits a health plan from delaying a standard transaction, or otherwise adversely affecting, or attempting to adversely affect any person desiring to conduct a transaction referred to in � 1173 (a)(1) of the Social Security Act or the transaction on the ground that the transaction is a standard transaction. We interpret this provision to mean that there should be no degradation in the transmission of, receipt of, processing of, and response to a standard transaction solely because the transaction is a standard transaction. Thus, health plans must process standard transactions from any person, including, but not limited to, covered entities, in the same time frame in which they processed transactions prior to implementation of HIPAA. Kepa Zubeldia <Kepa.Zubeldia@cl To: [EMAIL PROTECTED] aredi.com> cc: Subject: Re: Issue from a recent conference 10/26/2001 02:10 AM Please respond to transactions I know this is not a very likely case, but a provider could choose to not send electronic claims at all, and still be a covered entity under HIPAA. Perhaps because the provider does electronic eligibility transactions. Perhaps because the provider desires to receive electronic remittance advice. If a provider desires to conduct a transaction, such as remittance advice, as a standard transaction, the health plan may not refuse to do so. Nowhere in HIPAA it says that a provider must submit an electronic claim before he can receive electronic remittance advice. Oh, well, I am sure this email did not make very many friends, and I am going to be flamed for this, but, I would like to understand where some of the logic in the messages below fits in HIPAA. As a common practice today, there are many payers that will send 835 transactions to providers that desire to receive 835s. In most of these cases, once a provider makes that choice, all the remittance advices are reflected in 835s, whether the claim was submitted on paper or electronic. I am not saying everybody does that, but as far as I know, most of the 835 files that I have seen also contain payments on claims that were submitted on paper. I don't see that practice changing with HIPAA. In fact, I think that if a provider desires to receive all its remittance advices electronically, the payer must do so. I don't think the payer can pick and choose certain payments to go on paper remittance advice and others to go on 835. At least as I understand the HIPAA regulations. Dissenting opinions are welcome. Kepa [EMAIL PROTECTED] wrote: > > I strongly disagree. 162.925 (the rule you quote as authority) is not > applicable to providers who conduct PAPER submissions. 162.925 et al are > only applicable to providers who conduct (submit) EDI transactions. The > definitions on applicability are clear on this: > > 50365 Federal Register / Vol. 65, No. 160 / Thursday, August 17, 2000 / > Rules and Regulations > � 160.102 Applicability. > Except as otherwise provided, the > standards, requirements, and > implementation specifications adopted > under this subchapter apply to the > following entities: > (a) A health plan. > (b) A health care clearinghouse. > (c) A health care provider who > transmits any health information in > electronic form in connection with a > transaction covered by this subchapter. > > > "Tucci-Kaufhold, Ruth > A." To: "'[EMAIL PROTECTED]'" > <Ruth.Tucci-Kaufhold@u <[EMAIL PROTECTED]> > nisys.com> cc: > Subject: RE: Issue from a recent conference > 10/25/2001 02:55 PM > Please respond to > transactions > > > > > The provider can submit paper and request that a payer provide an 835 > remittance. The rule allows this ... the health plan cannot refuse to > provide that provider with the 835 if that provider asks the health plan to > do so. (p. 50469 ss162.925) > > The issue of the lack of data can be solved by the payer requiring those > data elements from the provider ... that is permissible. > > Ruth Tucci-Kaufhold > UNISYS Corporation > 4050 Innslake Drive > Suite 202 > Glen Allen, VA 23060 > (804) 346-1138 > (804) 935-1647 (fax) > N246-1138 > [EMAIL PROTECTED] > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 25, 2001 2:41 PM > To: [EMAIL PROTECTED] > Subject: RE: Issue from a recent conference > > I haven't been fully following this thread, but on the question of a > submitter "requiring" an 835 response from a paper submission, I disagree > strongly. > > Paper transaction submissions are exempt from HIPAA transaction standards. > HIPAA transaction requirements are expressly limited to EDI transactions. > The content (lack of) of the paper claim submission would make a compliant > 835 EDI response difficult if not impossible. > > I fail to see how a submitter, who (at their option, by sending 'paper') > 'exempts' a transaction from HIPAA, may 'un-exempt' the same transaction > once it reaches the payor, by requiring an EDI response from the payor. > Where is this written? > > Lastly, a non-compliant EDI response to a paper submission, would place > only the payor in violation of HIPAA. To permit a submitter to force a > payor to respond to a paper submission with a non-compliant EDI > transaction, thereby risking violation and fine, where the reason for the > non-compliance is solely due to the format and content of data presented by > the submitter, is absurd. > > "Hauser, Tarry" > > <THauser@mahealt To: > "'[EMAIL PROTECTED]'" > hcare.com> <[EMAIL PROTECTED]> > > cc: > > 10/25/2001 02:31 Subject: RE: Issue from a > recent conference > PM > > Please respond > > to transactions > > Thanks all....I do think your approach Steve - and that of Jonathan - > is/are > the most reasonable given current circumstances. Though it is true that it > does raise more questions. > > -----Original Message----- > From: Hanson, Steve [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 25, 2001 1:24 PM > To: '[EMAIL PROTECTED]' > Subject: RE: Issue from a recent conference > > We assume that this is a matter that individual providers must work out > with > payers, and are modifying our provider demographic data to include controls > for this. We also assume that this control applies regardless of whether > or > not we receive an 837; that is, we must issue an 835 to a provider who has > previously requested this method of payment for both 837 and paper claim > submissions. > > Unfortunately, I can't tell you what parts of the regs we were looking at > when we reached this conclusion. > > Steve Hanson > Senior Product Technical Consultant, The TriZetto Group, Inc. > "Pluralitas non est ponenda sine necessitate" - Ockham's Razor (14th > century) > for which my favorite corollary is: > The simplest solution that is both necessary and sufficient is best. > > > -----Original Message----- > > From: Hauser, Tarry [SMTP:[EMAIL PROTECTED]] > > Sent: Thursday, October 25, 2001 8:30 AM > > To: '[EMAIL PROTECTED]' > > Subject: Issue from a recent conference > > > > > > > > "There did not seem to be a definite answer on how we know that we should > > send an 835 transaction back when we receive an 837. At one point there > > was to be a routing # if the Provider wanted the 835 back. However, there > > is nothing in the data field such as a routing # to know." > > > > This question cam back to me after one of our own attended an SPBA > > conference. Do we have an answer for this anywhere in the regs? > > > > Tarry L. Hauser > > Applications Specialist > > Medical Associates Health Plans > > 700 Locust Street Ste 230 > > PO Box 5002 > > Dubuque, IA 52004-5002 > > (319)584-4830 > > FAX (319)556-5134 > > > > > > > > > > ********************************************************************** > > 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. > > ********************************************************************** > To be removed from this list, send a message to: > [EMAIL PROTECTED] > Please noX-Mozilla-Status: 0009 to 72 hours to process your request. > > ********************************************************************** > 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. > > ********************************************************************** > 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. > > ********************************************************************** > 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. > > ********************************************************************** > 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. ********************************************************************** 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. ********************************************************************** 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. ********************************************************************** 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. ********************************************************************** 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.
