Greg, You say you have one payer EDI number. How was this assigned? Are you using the NAIC Co-code? Something else?
Kepa "Koller, Greg" wrote: > > Peter, > > This is some good information. I struggle with how data can be put into an > 835 from a paper form with so much data missing, but I will keep an open > mind. > > My big question relates to the topic of Provider EDI numbers. I agree, it > would be great to have that standardized set. With regards to payers, > however, that system is pretty much in place and one of the big advantages > of EDI is being able to utilize a single EDI number rather than trying to > figure out correct addresses for larger payers (BC of Wisconsin has one EDI > number compared to at least a dozen physical mailing addresses). With the > 837 requirement of Physical Payer address, this seems to be taking a step > backward. Any thoughts on how this should be handled? Are there > requirements that the physical address be accurate or can you use a single > dummy address? > > >From a systems perspective, this will increase the size and complexity of a > payer file exponentially. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 30, 2001 10:10 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Issue from a recent conference > > In the email exchange below there are a couple ideas that seem off the > likely > interpretation of the health plan mandate rule. So I would like to add some > > comments, which are attached. > > Peter > > Peter Barry > Peter T Barry Company > Ozaukee Bank Building > 1425 West Mequon Road > Mequon Wisconsin 53092 > (414) 732 5000 (national cell) > [EMAIL PROTECTED] > > -------------------------------- > In a message dated 10/28/2001 4:56:38 PM Central Standard Time, > [EMAIL PROTECTED] writes: > > > Subj: RE: Issue from a recent conference > > Date: 10/28/2001 4:56:38 PM Central Standard Time > > From: [EMAIL PROTECTED] (Rachel Foerster) > > Reply-to: <A HREF="mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED] > </A> > > To: [EMAIL PROTECTED] > > > > Wes, > > > > You raise excellent questions which can only be answered by any > enforcement > > rules. Such rules, as we all know, have yet to be proposed let alone > > adopted. Oh well..... > > > > About question b -- also a good question. But, the bigger issue becomes > what > > the potential economic liability might be to decide to "take a fine" > rather > > than comply. In the absence of enforcement rules, one could assume that a > > violation could be each instance of using a non-standard medical code. > This > > would make the transaction a violation as well...so the actual number of > > instances of violations could be quite high and thus not economically > > acceptable. I believe the definition of the standard to be each > transaction, > > each identifier, each code set, but I haven't located the actual language > > in > > the law. > > > > Re question c -- I know of at least one health plan that has already made > > the business decision to accept standard transactions only. Thus, if a > > provider is not ready, they must use a clearinghouse to accomplish the > > transformation of the non-standard to a standard. > > > > I would take a bit of issue with your statement about clearinghouses. I > > agree that a clearinghouse can conduct a non-standard transaction, but > only > > as a business associate of a covered entity and when transforming a > > non-standard to standard and vice-versa on behalf of a CE. This means > that > > the clearinghouse is actually a business associate of the covered entity > > performing a role that could otherwise be performed by the CE itself. > > However, when it comes to a clearinghouse-to-clearinghouse exchange, then > > this becomes one CE to another CE and the transactions must be conducted > as > > standard transactions. > > > > From the Transaction Final Rule: > > � 162.930 Additional rules for health care > > clearinghouses. > > > > When acting as a business associate > > for another covered entity, a health care > > clearinghouse may perform the > > following functions: > > > > (a) Receive a standard transaction on > > behalf of the covered entity and > > translate it into a nonstandard > > transaction (for example, nonstandard > > format and/or nonstandard data content) > > for transmission to the covered entity. > > > > (b) Receive a nonstandard transaction > > (for example, nonstandard format and/ > > or nonstandard data content) from the > > covered entity and translate it into a > > standard transaction for transmission on > > behalf of the covered entity. > > > > > > Would you agree? I had this discussion just this past week with an > attorney > > well-versed in all aspects of HIPAA, and this was his take as well. > > > > Rachel > > > > -----Original Message----- > > From: Rishel,Wes [mailto:[EMAIL PROTECTED]] > > Sent: Saturday, October 27, 2001 11:56 AM > > To: '[EMAIL PROTECTED]' > > Subject: RE: Issue from a recent conference] > > > > > > 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, go to: > http://snip.wedi.org/unsubscribe.cfm?list=business > and enter your email address. > > ********************************************************************** > To be removed from this list, go to: http://snip.wedi.org/unsubscribe.cfm?list�ss > and enter your email address. ********************************************************************** To be removed from this list, go to: http://snip.wedi.org/unsubscribe.cfm?list=business and enter your email address.
