Gloria, I've looked at the flow you propose, and am researching with our payer entity whether or not we have the same situation here (I suspect that we do). It'll help me with the response if I can interpret from the manual processes we presently follow.
For the P-->T-->R-->P, you are correct that you need to work that out internally, although you could (depending on the sophistication & segmentation of your application) use a P-->T-->R1-->R2-->P, where the R1 is nothing more that an automated routing mechanism that uses information from loop 2000A or 2000B to determine which R2 to route to. For the P-->R-->T-->R-->P, you are certainly on the right track. The reviewer would determine for that specific transaction that an eligibility check is needed, and send off a 270 to you, holding the 278 in suspense until the 271 is received back from you. This is a perfect example of where a real-time 270/271 transaction set would be a great advantage since it could be dealt with as a serial synchronous process at the reviewer's site. However, if the reviewer doesn't even understand that they are a covered entity, they probably wouldn't have the sophistication to take advantage of it... Your other question is slightly more difficult in that the 278 transaction is really meant to flow between the UMO (reviewer) and the provider. In fact, on page 15 of the IG for the 278, it states that: "It is the role of the UMO to forward that request [referring to a decision which the payer or payer's representative must make, like your eligibility scenario] to the payer, receive the response from the payer, and then return the response to the requester." The IG is clearly expecting a binary process where there are only 2 parties involved. I don't know from the phrasing of the 278IG that even if you had a business partner relationship with R, that they would allow the original 278 to be forwarded to you for decision and return to P. When multiple decisions must occur (for example, if the reviewer had some decision capabilities, but had to refer on to another party like you or even the payer for other decisions), the IG says that there would be multiple 278s created: P(278A)-->R, then R(278B)-->T, T checks coverage and if none (HCR03=88), then T(278B)-->R who then informs the provider R(278A)-->P. If coverage is there, but the payer must decide on benefits, then T(278C)-->A, A decides and returns A(278C)-->T, who in-turn responds T(278B)-->R, followed by R(278A)-->P. An alternate path reflecting the fact that R must decide on whether or not a third party (A) needs to be involved in the decision would be: P(278A)-->R, R(270)-->T, T(271)-->R, R(278B)-->A, A(278B)-->R, R(278A)-->P In either case, the 278 is binary meaning it only has 1 paring of sender & responder. Ouch, my head hurts... Hope this helps - I'll let you know if anything else comes out of my research. Dave P.S. - I'm sending this on to the listserv since it represents yet another set of requirements for Rachel's growing list. Dave Minch T&CS Project Manager John Muir / Mt. Diablo Health System Walnut Creek, CA (925) 941-2240 -----Original Message----- From: Gloria Harris [mailto:[EMAIL PROTECTED]] Sent: Saturday, February 16, 2002 12:14 PM To: [EMAIL PROTECTED] Subject: Requirements Gathering - Information Flows Dave, Thanks, your transaction paths are useful. You mentioned that you weren't mapping out the information requests yet because the transactions are entirely manual now. Darn. I'm saying darn because I could use some advice, and I'm starting with you based upon some of your prior emails. If you know of someone else that would be better suited for my questions, please let me know. Here at my company, I have been assigned the 278 transaction and am very new to the EDI world. I have been working on the flow process for this transaction and been surprised at how my information flow has changed in the last couple of weeks. Not only that, we are having many discussions as to what is necessary to comply for all aspects of HIPAA and DOL regs. Anyway, my transaction flow changes according to client and type of request. For example: The "simple" process P --> T --> R--> P It turns out that the R can be in two separate departments within our company. We have to determine the type of request and then forward to the correct department. So, it's not so simple anymore! (We will work that out.) The flow that I just found out about: P --> R -->T -->R --> P Here is where we are getting stuck! In this case, I've discovered that the Reviewer is an outside source. Our company (TPA) is trying to determine how EDI flow will work, because under the new HIPAA and DOL Regs, the outside source will need to verify eligibility prior to sending information on to the provider or member. So, my initial thoughts are that my information flow will be: 278A: P--> R, pend, R:270 --> T, 271:--> R, pend, 278B: R --> P,U This flow description has a new letter, U. U = Insured The 278 transaction goes to an outsourced Reviewer. The Reviewer needs to verify eligibility prior to notification. So, they pend the 278A and send us (TPA) a 270 request. We return a 271 to the Reviewer. The Reviewer finds the correct 278 transaction and returns it (278B) to the Provider with a paper letter to the Insured. At least, this is what we are thinking we need to do. Do you know if we are on the right track? I'm asking this question because the outside Reviewer has never heard that they fall under HIPAA (can you believe it?), and we believe they do because they work for the Plan. Also, there is discussion as to whether or not the 278 would/could be forwarded to us, with us sending it on to the provider after determining eligibility. If so, the flow would look like this: 278: P--> R, pend. 278 & 270?: R--> T. 278 only: T--> P, N = paper I don't think that this will fly because this flow has us passing on the independent Reviewer's findings. I think there is a fuduciary responsibility issue here that has to be discussed further. In other words, we may not be able to pass the 278 on because the findings/results belong to that particular vendor and not to us. But, for this case, let's just say that this happens. Would the outside Reviewer be required by HIPAA to send us a 270? Or, would they only need to forward the 278 on to us as a Business Associate and not as a Trading Partner? Again, if you have read this far, thanks for listening and for any advice you can provide. I am meeting with our Operations VPs and National HIPAA director late next week (22nd) and need all of these questions answered prior to the meeting. Gloria Harris [EMAIL PROTECTED] Business Analyst Zenith Administrators, Inc. Seattle, WA 206-301-1547
