And it is probably a good idea to consult with your company's legal counsel if there is any doubt about your particular situation. I for one would much rather have our attorney's directive in my hand as opposed to a copy of messages from a listserve if I'm ever questioned as to why a particular strategy was chosen relative to an ambiguous HIPAA issue.
----- Original Message ----- From: "Weber, Karen (DHS-PSD)" <[EMAIL PROTECTED]> Date: Thu, 9 May 2002 11:46:21 -0700 To: "''James Kelly''" <[EMAIL PROTECTED]>, "''[EMAIL PROTECTED]''" <[EMAIL PROTECTED]> Subject: RE: 834 Enrollment and Maintenance transactions > At a WEDi/SNIP meeting awhile back, Stanley Nachimson gave us these > guidelines on how to determine if a transaction needs to be in the > HIPAA-mandated format. > > 1. Read the definitions of the three Covered Entities. If your organization > is a covered entity, go to step 2. If you aren't a covered entity, you can > stop here. > 2. Read the definitions of the Transactions on pages 50370-72 of the Final > Transaction Rule. If the activity you're performing meets the definition of > the transaction, you need to use the HIPAA-mandated format whenever you > send/receive the transaction electronically. > > This is a really simple roadmap that's easy to understand, and gives you an > accurate answer every time. > > > > -----Original Message----- > From: James Kelly [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 09, 2002 11:35 AM > To: Paul Weber; [EMAIL PROTECTED] > Subject: Re: 834 Enrollment and Maintenance transactions > > > Paul, > > Thanks for your input. I appreciate your position that X12 does not develop > guides for the Federal government. I am new to this so I may be off base, > but it is my understanding that the IG's were adopted as "THE STANDARD" (45 > CFR 162.1502). Therefore, I would interpret anything in the guides as > having the full force of law. If the guide says to not use something and I > do, I am not compliant. If I use a code set that is not allowed in the > guide, I am not compliant. > > I think the other authors of this thread and myself were hoping for a legal > perspective. Are the transfers we described "covered transactions". For me > it is a big difference as I write payer software. My first take on this was > I had to accept an 834, not generate one. Now I am not sure. I do not want > to spend limited resources implementing a transaction I am not required to > use. On the other hand, if my clients do have to use this, then I better > build it in. > > I agree in the future that we may have to back out of an 834 and use a 271 > roster. But as the rules change and new transactions are covered, it is > something we need to do anyway. I also would say that as we move forward we > may add other non HIPAA transactions to our software to give us a > competitive advantage. But for right now, I am working in a budget and need > to know how to spend my resources. > > So if anyone from HHS is listening, I would appreciate feedback as to your > interpretation. > > >----- Original Message ----- > From: "Paul Weber" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, May 09, 2002 11:51 AM > Subject: 834 Enrollment and Maintenance transactions > > > > As one of the many volunteers who work on the 834 guide, I feel compelled > to jump into this discussion. > > > > All of the X12N implementation guides were written as industry guides that > were subsequently adopted by the secretary of HHS. It is not within our > charter to develop guides for the federal government. Hence I would be > reluctant to get into interpreting HIPAA regulations within our IGs. Can the > definition of a payer for the 834 be revised in a future edition of the > IG...sure, anything's possible. But I certainly don't want to be the one > responsible for interpreting the intent of HIPAA regulations. That's what > statutes and case law are for. > > > > The issue of the 271 vs 834 eligibility roster seems to rear its ugly head > periodically. Here's my take: The purpose and scope of the 834 transaction > set do not explicitly prohibit its use for an eligibility roster. However > X12N has the 271 transaction set as mentioned below in this thread. The 271 > work group is actively developing an implementation guide for eligibility > rosters and it is my understanding that they are close to publication. > > > > Therefore those who adopt the 834 as an eligibility roster solution may > find themselves having to go back and retrofit their systems to support the > 271 transaction. Especially when smart money says the 271 roster gets named > in the next round of HIPAA. > > > > I think what would help clarify some of this is a determination of whether > the parties in question are enrolling membership in the sub-contracted plan > or are verifiying eligibility for services. For instance, if claims are to > be paid by the sub-contractor, then they would likely need to have > enrollment (834). If the sub-contractor is capitated by the primary plan, > then they likely need an eligibility roster (271) and/or interactive > eligibility (270/271). > > > > Paul Weber > > 916-449-6970 > > [EMAIL PROTECTED] > > > > ----- Original Message ----- > > From: Tucci-Kaufhold, Ruth A. > > To: '[EMAIL PROTECTED]' > > Sent: Wednesday, May 08, 2002 7:14 AM > > Subject: RE: 834 Enrollment and Maintenance transactions > > > > > > I also have such customers that indicated their interpretation of the > situation as James stated. > > > > I just pointed out to the customer that the law defines them as the > covered entity and they are responsible for the work that they contract out > to PPOs, PBMs, etc. for specific health care transactions such as pharmacy, > vision, prior auth, referrals, etc. The law is clear on that. There should > be a change made to IG to relay a consistent message on the definition of > health plan in an 834 and in the law. > > > > Now whether not they want to "interpret" it that way is a different story. > So, in that case I just suggested to them that they "document" their > understanding of the law, and that will explain to CMS when audit times > comes around. > > > > 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: James Kelly [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, May 07, 2002 10:32 PM > > To: Stuart Thompson; [EMAIL PROTECTED] > > Subject: Re: 834 Enrollment and Maintenance transactions > > > > > > Stuart, > > > > I too have questions on this. I have numerous clients (Taft-Hartley union > benefit plans) who contract with outside vision networks, dental and medical > PPO's, and PBM's. Some of these companies are taking the position that they > can still use their proprietary formats since the 834 is from an employer to > a health plan. Their logic seems to be that they are not a payer since they > are not ultimately responsible for the benefit payment. > > > > I, however, agree with your analysis. > > > > In regards to item 1, the 834 IG on page 8 defines a payer/insurer as: > > > > "The payer is the party that pays claims and/or administers the insurance > coverage,benefit, or product. A payer can be an insurance company; Health > Maintenance Organization (HMO); Preferred Provider Organization (PPO); a > government agency, such as Medicare or Civilian Health and Medical Program > of the Uniformed Services (CHAMPUS); or another organization contracted by > one of these groups." > > > > On item 2, I also agree. That section adopts the above quoted > implementation guide as the standard. > > > > On item 3, I have heard of a 271 roster transaction. This transaction is > used to send a list of covered members to another business associate. When > a poll was done at the Wedi-Snip conference in Baltimore, most attendees > indicated they were going to use the 834 for this transaction. > > > > I think the problem is that the definition of a payer in the IG does not > match the definition of a health plan in the law. Also section 162.1501 > says specifically that the 834 transaction is "to a health plan to establish > or terminate insurance coverage." > > > > Hopefully some of the more learned members of this list will share their > opinions on this. > > > > Jim Kelly > > TPA Computer Corp > > From: Stuart Thompson > > To: [EMAIL PROTECTED] > > Sent: Monday, May 06, 2002 7:49 PM > > Subject: 834 Enrollment and Maintenance transactions > > > > > > I would like to receive opinions regarding the following: > > > > Title 45, CFR �162.103 defines "Health plan" to include an individual or > group plan "that provides, or pays the cost of, medical care...". "Health > Plan A" is a major medical health plan that contracts Company B to provide > specialized medical care (for example, vision or dental care) to Company A's > enrollees. "Company B" provides that specialized medical care through its > contracted providers and pays those providers = for=20 such services. To > carry out its contract obligations, Company B needs to receive data > identifying Health Plan A's enrollees. > > > > Do you agree or disagree with the following? In either case, please > explain why: > > > > 1. Company B falls within the definition of "Health plan" because it > provides or pays the cost of medical care. > > 2. 45 CFR 162.1502 allows Health Plan A to send Company B the necessary > data via an 834 transaction. > > 3. A data transmission from Health Plan A to Company B cannot be deemed a > compliant 271 eligibility response absent a 270 eligibility inquiry. > > > > Thank you in advance for any opinions that you would be willing to share. > > > > Stuart Thompson > > Vision Service Plan > > Rancho Cordova CA > > > > [*Please note: The above statements and questions are my own and do not > necessarily represent the views of my employer]. > > > > > > -- > > _______________________________________________ > > Sign-up for your own FREE Personalized E-mail at Mail.com > > http://www.mail.com/?sr=signup > > > -- _______________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup
