On the contrary, encouraging providers toward full function systems, especially systems being capable of receiving unsolicited transactions in the provider's central receiving queue or port, is one of the more critical requirements for this project to target. It is highly desirable for a provider to be able to participate technically on an equal footing with any other participant. This principle was further discussed yesterday at the SNIP planning meeting. Provider's having equal full function communications systems will be essential for the medical round of HIPAA where unsolicited provider-to-provider communications will be required.
Can a provider, under the transaction rules, require a plan to transmit, say, an 835 to its central receiving queue or port rather than being required by the plan to poll a mailbox on the plan's computer? That is an ambiguity in the rules. My interpretation has been, yes, and have advised clients to expect providers to make the requirement of them. Plans that are not capable of responding can make a reasonable legal argument but will probably not prevail. I have a paper entitled EDI Communications Security and Interoperability Requirements, which discusses this question, that I would be willing to send to members of the project if you request it. I would ask that you not further disseminate it. Peter Peter Barry Peter T Barry Company Independent Consulting Health Care and Information Systems Ozaukee Bank Building 1425 West Mequon Road Mequon Wisconsin 53092 (414) 732 5000 (national cell) [EMAIL PROTECTED] -------------------------------- -In a message dated 6/14/2002 5:56:44 PM Central Daylight Time, [EMAIL PROTECTED] writes: > Subj: RE: The payer centric model > Date: 6/14/2002 5:56:44 PM Central Daylight Time > From: [EMAIL PROTECTED] (Rachel Foerster) > Reply-to: <A HREF="mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED] </A> > To: [EMAIL PROTECTED] ('WEDi/SNIP ID & Routing') > > And round and round the mulberry bush we go! Making the payer-centric > mailbox model go away or even enabling it to go away is not the objective of > this group. > > Rachel > Rachel Foerster > Rachel Foerster & Associates, Ltd. > Phone: 847-872-8070 > > > -----Original Message----- > From: William J. Kammerer [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 13, 2002 12:29 PM > To: WEDi/SNIP ID & Routing > Subject: The payer centric model > > > Payers are required to use standard transactions if the provider > requests that they do so. Somehow the messages have to be gotten to the > provider. In the typical supply-chain scenario using VANs and > interconnects, the sender merely "pushes" the interchange to his VAN. > Then the sender's VAN itself will worry about delivering it to the > receiver's mailbox (if coincidentally subscribed to the same VAN), to > another VAN to which the receiver is subscribed, or even directly to the > receiver (using a "push" model) if the receiver has arranged that > service with his VAN. > > It's not the sender's (the payer in our case) problem to arrange > mailboxing for the receiver. Quite a bit of time, trouble and money can > be saved if each payer didn't think it had to "play" VAN. And it > certainly shouldn't be the problem of the receiver (the provider in our > case) to go traipsing off to 20 or 30 payer websites to retrieve > standard transactions, going through each payer's notion of a logon > process and mailbox retrieval. It makes sense to learn that process for > your one and only VAN or clearinghouse - but it hardly contributes > anything to administrative simplification for the provider to have to > repeat that process for every payer with whom he expects to exchange > standard transactions. > > In a lot of ways, the payer-centric way of doing e-business reminds me > of the DDE conundrum, whereby each payer persists in expecting every > provider to learn the intricacies of his own eligibility web page rather > than merely supporting the 270/271 standard transactions in a > first-class manner as required by the TCS rule. > > William J. Kammerer > Novannet, LLC. > Columbus, US-OH 43221-3859 > +1 (614) 487-0320 > > ----- Original Message ----- > From: "Bruce T LeGrand" <[EMAIL PROTECTED]> > To: "WEDi/SNIP ID & Routing" <[EMAIL PROTECTED]> > Sent: Thursday, 13 June, 2002 10:56 AM > Subject: Re: An Overview or Primer Document > > There is a common thread that keeps showing up in this discussion that I > just cannot get past my reality check mechanism. > > Payers are required to support the standard transactions. They are not > required to transmit them. Rather, in the instances where I have > knowledge, Medicaid, Medicare and some Blues, they are going to put this > data in a mail box and it is up to the provider to come and get it. > > Earlier there was a statement that my views a payer centric. I would > argue that to follow the money, which is always the driving force in > this dialogue, you will still end up with the payer. You want the money > or the documentation, you do what the payer asks. > > ------------------( Forwarded letter 1 follows )-------------------- > Date: Wed, 12 Jun 2002 11:45:34 -0400 > To: WEDi/SNIP.ID.&.Routing[routing]@wedi.org.comp > From: William.J.Kammerer[wkammerer]@novannet.com.comp > Sender: [EMAIL PROTECTED] > Subject: Re: An Overview or Primer Document > > Rachel: > > I hadn't really thought of that before: using the "critical timelines" > to "sell" the concept of the Healthcare CPP and Registry. But now that > you bring it up, the overview should definitely include verbiage on how > the CPP especially facilitates the industry achieving these critical > milestones. Would you mind doing that part of the overview? > > Obviously, most folks are going to continue using Clearinghouses to help > them become HIPAA compliant, but as we've long said, the CPP and > Registry are useful to intermediaries also. With Internet connections > to clearinghouses and CMS, there are the new HIPAA mandated security > rules to deal with which require signatures and encryption - and the CPP > is the ideal mechanism for sharing and disseminating certificates. And > though it's a given that payers have to support all the standard > transactions, the CPP is critical for broadcasting the capabilities of > individual providers, avoiding onerous manual interaction as standard > transactions are brought online one at a time. > > Though I'm no big fan of *mandatory* certification, certification is > still a good thing to have: the CPP is the most efficient means of > conveying your certified capabilities to your partners. And though it > could be left unsaid - after all the discussion of the last couple of > weeks - I'll say it again: I think Open-EDI is going to spring on many > payers as a surprise by H-day, and only an automated infrastructure > provided by the CPP and the Registry will make that at all possible. > > Thanks again, > > William J. Kammerer > Novannet, LLC. > Columbus, US-OH 43221-3859 > +1 (614) 487-0320
