William, My observation is as follows: Clearing houses are at a crossroad. There is an enormous potential for them to make lots of money and sign up many new clients, even lure them into a per-transaction charge. WebMD, aka Envoy-NEIC, is working hard on a HIPAA product, whereby they import claims through UB92/HCFA-1500 files or some other ways, convert them in a desktop system to their own format, transmit them to the clearing house and eventually turn them into X12. Then they handle all the EDI functions for providers, Remittance advices, 277s etc. and give reports etc. to the providers. I am still waiting on more details but it is definetely in the works. WebMD does well as it is, without HIPAA EDI and I know hospitals where WebMD was a god send gift. Right now WebMD does not make money, Microsoft invested in them to buy Envoy. I believe that their plan is to get market share and then raise charges. Then there are clearing houses that either belong to the software vendors or have a tight relationship with them. For example McKesson HBOC, the leading hospital software vendor, offers only HIPAA transaction sets in conjunction with their own clearing house. You cannot handle your own EDI transactions, even when you buy for $$$ the EC2000 HIPAA component. Their business model is definetely geared towards dependence and creating a tap into the revenue stream. Then again other, independent clearing houses seem asleep at the wheel and I can't blame them. HIPAA EDI is much more complicated then to handle purchase orders for supplying widgets to WalMart.
Coming back to the hospitals that I work with. There is always a frantic need to save money and those per-transaction charges add up. If a hospitals could save money by doing their own EDI they would. There is business to be had for software houses who develop a HIPAA frontend for provider systems. Of course the provider's software vendors might discourage them and conjure threatening szenarios. Payers on the other side don't want to take in "dirty" EDI files, they rather deal with a limited set of trading partners. In Maryland, by regulation payers can only receive files from "certified" trading partners, whatever that means. Still I think the issue with "dirty" files can be resolved with EDI testing tools. HIPAA states that payers have to be able to process EDI files if a provider so desires. Does that mean that they also have to provide a drop-off mechanism? We can't expect providers to sign up for all the clearing houses in order to submit claims to payers. Neither can we expect payers to be happy if they have to go through a clearing house and pay a fee for each submission that a provider gives to the payer. I come back to email as a highly attractive and cost saving solution. I think the transport and routing mechanisms are still open and it is up to us, in this group, to establish workable solutions. Martin Scholl Scholl Consulting Group, Inc. 301-924-5537 Tel 301-570-0139 Fax [EMAIL PROTECTED] www.SchollConsulting.com ----- Original Message ----- From: "Christopher J. Feahr, OD" <[EMAIL PROTECTED]> To: "Deepan Vashi" <[EMAIL PROTECTED]>; "Martin Scholl" <[EMAIL PROTECTED]>; "William J. Kammerer" <[EMAIL PROTECTED]>; "WEDi/SNIP ID & Routing" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: "David Kibbe" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, June 18, 2002 4:55 PM Subject: Need for payor and CH input (was the email thread) > Deepan, > This reminds me of a line in an old song (Amazing Rhythm Aces): "I got both > ends meetin' in the middle, but I can't seem to get 'em tied!" > > The prevailing post-Hday expectation seems to be as follows (but this needs > confirmation): > -Payors do NOT seem to want to manage a lot of direct-connecting, > low-volume, nouveau-EDI-enabled provider relationships. > -A large volume (possibly most) of the claims currently flow into payors > from CH's and payors are likely to "institutionalize" this practice by > designating one or several CHs as their preferred "front doors". > -There is a question (as yet, unanswered) as to whether the CH industry > will even want to handle all these new/little provider accounts. First of > all, I'm not sure how many *new* accounts we are talking about, because > providers will likely drop the claims for obscure/rare payors back to > paper. I.e., a provider *might* drop everything to paper that cannot be > pushed out to his existing CH. In that case, the CH industry would NOT get > an onslaught of new EDI customers, but the volume of paper direct to payors > would increase... not good for payor, who *might* refuse to accept paper or > tack on a $5 charge for paper claim processing... thus improving the value > proposition for direct-connect solutions like the one Deepan appears to be > working on. > > I agree that the "tunnel" we've been in here looks "dark", but we MUST have > some input (light!) from the payors and CH community: > > 1. What IS happening today (i.e., claim volume/% arriving at your doors in > paper, NSF/1500, non-std 837, and std-837) and > 2. What do you THINK will be different about this in 17 mos? I.e., do the > CHs expect increase or decrease in overall volume of small provider > direct-connect? Do payors expect increase or decrease? What about the > %/volume change expected to be coming in these various formats (paper vs. > non-std-electr. vs. standard-electr.) > 3. Most important: what volume-change can you or do you want to > *handle*? Are CHs really in any better position to handle a flood of new > EDI submitters than payors? What exactly are the problems related to such > a shift in business... why would an increase be problematic? for payors > and/or for CHs? > 4. Is any of this related to the fact that the "Provider non-std. > CH > > "standard in there for a milisecond" >non-std to payor" scenario might mask > some of the much talked about, but still unresolved gaps between the old > formats and the 837? > > There ARE going to be problems... unless the industry simply refuses to > change any of the existing connection, TPA negotiation, and transport > mechanisms currently in place. Without such change, however, > standardization of the messages will not help anyone on either end with the > costlier parts of the present system. So what ARE the big problems going > to be?? Or should we fold up our tent (as Rachel suggests) because no one > is anticipating either changes or problems with > "routing/addressing/transport"... at least, not for several years. > > I'm afraid that PMS vendors will have to continue shooting in the dark > until the industry agrees on a set of addressing/transport-related > "problems", from which we can extract a set of hard > addressing/transport-related "requirements". Here is one way we can force > some of this to the surface: PMS VENDORS GET TOGETHER WITH SMALL PROVIDER > ASSOCIATIONS and, between the two camps, you help the providers to nail > down their short and long-term business requirements and objectives. Then > you build solutions for *provider* requirements. > > HIPAA does put the provider in the driver's seat... now all we have to do > is hand them the keys! > > Best regards, > Chris > > At 02:35 PM 6/18/02 +0530, Deepan Vashi wrote: > >For payers it might be easy to decide on their Internet strategy. > >I represent a Provider Software Vendor, offering Browser based interface. > > > >We have no choice but to design a system that will handle all ftp, smtp, > >http and any other vendor specific methods to make sure that provider claims > >(and transactions) reach payers. > > > >Moreover, Final Security Regulations might completely changes the choices > >available for transaction routing. > > > >All this talk about transaction routing, appear like a *dark tunnel*. > > > >What internet and routing strategy should be adopted by a web based provider > >software vendor like us? > >I believe there will be many like us in the industry offering practice > >management software to doctors; what are they planning for routing > >treansactions? > > > >Any *ray of hope* will be appreciated. > > > >Deepan Vashi > > > >www.ipmsolution.com > >Efficient Healthcare Delivery and Practice Management > > > > > >----- Original Message ----- > >From: "Martin Scholl" <[EMAIL PROTECTED]> > >To: "William J. Kammerer" <[EMAIL PROTECTED]>; "WEDi/SNIP ID & Routing" > ><[EMAIL PROTECTED]> > >Sent: Tuesday, June 18, 2002 5:51 AM > >Subject: Re: Route through email and attach EDI files > > > > > > > William, > > > thanks for your in-depth analysis of the email aspect. I like your > > > description of "push" versus "pull". This stresses one of the main > > > advantages of the email route. > > > I have not really followed the ebXML thread much. All I understand is > >that > > > its aim is to communicate a set of Trading Partner parameters in a > >response > > > to a standard XML query. > > > For email we would need something like this > > > > > > <email> > > > <address> email address</address> > > > <maxsize> maximal mbytes of attachemnts </maxsize> > > > <maxnumber> maximal number of attachments </maxnumber> > > > <encryption> > > > <yesno> Yes No Always Sometimes</yesno> > > > <type>PGP or whatever</type> > > > <publicKey> Public Key </publicKey > > > </encryption> > > > </email> > > > > > > This is my first stab at this, please, anyone amend/delete at your liking > > > and feed it back to the group > > > > > > Martin Scholl > > > Scholl Consulting Group, Inc. > > > 301-924-5537 Tel > > > 301-570-0139 Fax > > > [EMAIL PROTECTED] > > > www.SchollConsulting.com > > > . > > > > > > > > > > > > > > > ----- Original Message ----- > > > From: "William J. Kammerer" <[EMAIL PROTECTED]> > > > To: "WEDi/SNIP ID & Routing" <[EMAIL PROTECTED]> > > > Sent: Monday, June 17, 2002 11:43 AM > > > Subject: Re: Route through email and attach EDI files > > > > > > > > > > Martin: > > > > > > > > E-mail is an excellent model which shows up some of the inherent > > > > disadvantages of the payer-centric mailbox system we have today. I > > > > don't go to the sender's server to retrieve my e-mail - it's "pushed" to > > > > me. I only have to remember my incoming POP3 mail server name or > > > > address, the outgoing SMTP server name or address, my logon and > > > > password, and various authentication and port settings of my one or few > > > > mailboxes (maintained on my server or at my ISP). Accordingly, I need > > > > only poll my one (or few) mailboxes. If I tire of the bad service or > > > > impertinence of a particular ISP, I switch to another one. This is > > > > flexibility that payers and providers should demand when moving around > > > > standard transactions. > > > > > > > > Now imagine if e-mail were built around the payer-centric, or "pull" > > > > model: I'd have to have e-mail client account settings to access the > > > > mail server for anyone I ever anticipated receiving mail from! I would > > > > have to arrange - through an out-of-band channel - for server names, > > > > passwords, port settings, and so on, with each and every correspondent. > > > > Actually I wouldn't: I probably would just use the U.S.P.S. > > > > > > > > Indeed, e-mail is also a very viable option for the transport of > > > > standard transactions; it (SMTP) is definitely one of the supported > > > > delivery channels for both EDIINT (AS1) and ebXML. But as Cory Dekker > > > > reminded us, e-mail is not quite the answer to all which ails us. > > > > Realtime or fastbatch processing will probably require more exotic > > > > transport methods, like HTTP and SOAP. > > > > > > > > We'll have to account for any technique likely to be used by any two > > > > partners when designing the EDI Address (DeliveryChannel) component of > > > > the CPP electronic partner profile. Actually, we may only have to > > > > enumerate them: the OASIS ebXML CPP/A Technical Committee will probably > > > > be able to help us with the "meat" of the definitions if we can just > > > > tell them our requirements. Perhaps you could start by listing the > > > > combinations you see needed for using e-mail to transport interchanges; > > > > in the body or as an attachment; zipped or unzipped; S/MIME or PGP/MIME; > > > > etc., etc. The advantage of EDIINT AS1 is that one only has to say he's > > > > using that standard with a few variables, and all the detail will be > > > > understood by the other end; it also provides a formal model for > > > > acknowledgements not available with ordinary e-mail. > > > > > > > > By the way, the metric system has been "legal" (though not mandatory) in > > > > the U.S. since 1866. In any case, the metric vs. English system > > > > dichotomy is not an apt analogy to HIPAA. We have a working system of > > > > weights and measures - even if the English is demonstrably inferior to > > > > the Metric - which everyone (in the U.S.) pretends to understand. In > > > > healthcare, we have a hodgepodge of proprietary formats and non-standard > > > > X12 subsets for use with each payer (or CH). The HIPAA X12 standard > > > > transactions will give us one "standard." Even if X12 is arguably > > > > inferior to UN/EDIFACT, there would be no compelling reason to switch - > > > > for many of the same reasons we don't switch to the metric system. > > > > > > > > William J. Kammerer > > > > Novannet, LLC. > > > > Columbus, US-OH 43221-3859 > > > > +1 (614) 487-0320 > > > > > > > > ----- Original Message ----- > > > > From: "Martin Scholl" <[EMAIL PROTECTED]> > > > > To: "David A. Feinberg, C.D.P." <[EMAIL PROTECTED]>; "WEDi/SNIP ID > > > > & Routing" <[EMAIL PROTECTED]> > > > > Sent: Saturday, 15 June, 2002 09:24 AM > > > > Subject: Re: Route through email and attach EDI files > > > > > > > > Well Dave, > > > > > > > > Sure it is possible to use the body of the email for the transmission. > > > > You can concoct a gruel email with multiple transaction sets of > > > > differing code set in numerous groups all into one ISA envelope. That > > > > thing would be so ugly, you wouldn't even have to encrypt it :-) But > > > > kidding aside, I think attachements make EDI more manageable. You can > > > > have several attachments to one email, you can open the email and see > > > > that there are attachments, it makes it just clearer. And clear and > > > > simple is what we need urgently. > > > > > > > > Also, call me an anarchist, but I really don't care much for the > > > > realtime requirement of the 270/271 exchange. 2 to 30 seconds seems so > > > > arbitrary. Can your database even handle that? What if it takes 31 > > > > seconds? Will the HIPAA police come at 2 am, knock at your door and ship > > > > you to a navy brigg? I doubt it. > > > > > > > > But what I don't doubt is that if we don't make HIPAA EDI easily > > > > adoptable with common sense solutions, then HIPAA will go the way of > > > > metrification. Remember the 70's, when the US by law adopted the metric > > > > system? It went nowhere. We still deal with feet, inches, gallons and > > > > send Mars probes crashing into orbits below the surface. HIPAA > > > > transactions could easily go the same way. If the politicians in > > > > November 2003 see the healthcare delivery threatened by overly > > > > bureaucratic demands, then HIPAA will be rescinded faster then we can > > > > say "EDI". Then all our efforts will be in vain and the considerable > > > > investment in time and money would never result in a pay-back. That's > > > > why I propose email as a viable solution for routing. We can still > > > > investigate CPP and ebXML, VANs and ftp, CDs with FedEx, Floppies with > > > > bike messenger but email is here to stay. Providers would not need a > > > > clearinghouse and pay an extra per-transaction fee. > > > > > > > > It's Saturday and my wife gives me the evil eye for working. Let's keep > > > > this discussion going next week, > > > > > > > > Martin Scholl > > > > Scholl Consulting Group, Inc. > > > > 301-924-5537 Tel > > > > 301-570-0139 Fax > > > > [EMAIL PROTECTED] > > > > www.SchollConsulting.com > > > > > > > > ----- Original Message ----- > > > > From: David A. Feinberg, C.D.P. > > > > To: [EMAIL PROTECTED] > > > > Sent: Saturday, June 15, 2002 1:49 AM > > > > Subject: Re: Route through email and attach EDI files > > > > > > > > > > > > Paul, Martin, Cory, et. al., > > > > > > > > Since it's been a verrry long day this Friday, and I'm on a bit of a > > > > roll, allow me to raise the ante another nickel. > > > > > > > > Since X12 [and HL7] transactions are strictly ASCII text, who needs > > > > attachments? > > > > > > > > Happy weekend. > > > > > > > > Dave Feinberg > > > > Rensis Corporation [A Consulting Company] > > > > 206-617-1717 > > > > [EMAIL PROTECTED] > > > > > > > > > > > > ----- Original Message ----- > > > > From: Paul Weber > > > > To: [EMAIL PROTECTED] ; [EMAIL PROTECTED] > > > > Sent: Friday, June 14, 2002 8:35 AM > > > > Subject: Re: Route through email and attach EDI files > > > > > > > > > > > > I see Martin's 2 cents and raise a nickle. He makes a good point --- > > > > especially for small volume batches. However where things get dicey is > > > > when attachments start getting too large to get through firewalls and/or > > > > negatively impact network performance. For example, I worked for a large > > > > west coast HMO that had a 1.5MB limit on attachments. We did a lot of > > > > secure e-mailing of capitated patient rosters to IPAs and medical > > > > groups. Some of these were too big to go through the firewall so we > > > > either broke them up into smaller files or (horrors!) burned CDs. > > > > > > > > Paul Weber > > > > > > > > [EMAIL PROTECTED] > > > > > > > > ----- Original Message ----- > > > > From: Martin Scholl > > > > Date: Thu, 13 Jun 2002 15:39:29 -0400 > > > > To: WEDi/SNIP ID & Routing > > > > Subject: Route through email and attach EDI files > > > > > > > > > > > > Content-Type: text/html; charset=iso-8859-1 > > > > > > > > > > > > After following the discussion now for a few months I begin to > > > > believe that we have not solved routing, one of the most basic issues of > > > > EDI. All this talk about CPP and ebXML makes my head spin; and to be > > > > honest, having my hands full with transaction sets, I don't see myself > > > > studying now XML too. > > > > > > > > Why don't we use email as the preferred mode of routing? > > > > > > > > This would solve most problems. > > > > a.. email is secure. Encrypting email with PGP, Pretty Good > > > > Privacy is cheap, proven and common place > > > > b.. Attachments can be relatively large, mega bytes if need be and > > > > numerous too > > > > c.. routing of email is long solved and works great as we all know > > > > d.. Identifiers are left between you and your trading partner. We > > > > don't have to invent or find a unique ID as long it is 15 digits long. > > > > e.. virus filters and such are widely available and HIPAA Security > > > > can be attained at low costs > > > > f.. By having a robot check the inbox every minute or so, > > > > "realtime" or something reasonably close to that can be achieved. > > > > g.. TA1, 997,271,277 ..... are send back as an attachment > > > > h.. You can also send back the detailed analysis information. EDI > > > > compliance checker software produces verbose output and when you send > > > > that back in the body of the email to the message provider, you can give > > > > near instant feedback and go through the training and testing phase > > > > faster. > > > > i.. Off course, if you need to submit 10gig of EDI to CMS, this > > > > does not work, but for the traffic between providers and payers, email > > > > would solve the routing question > > > > I just started to test my payer oriented software with a provider > > > > software house in India. We tried ftp and were frustrated. We were > > > > fighting firewall issues, I had power outages and my server was down, my > > > > IP lease expired and India is about 12 hours ahead of me so that we > > > > could never communicate in real time. Moving the communications over to > > > > email solved all these problems and now we can concentrate on > > > > transaction set issues. > > > > > > > > My 2cents > > > > > > > > Martin Scholl > > > > Scholl Consulting Group, Inc. > > > > 301-924-5537 Tel > > > > 301-570-0139 Fax > > > > [EMAIL PROTECTED] > > > > www.SchollConsulting.com > > > > -- > > > > > > > > > > > > > > > > Christopher J. Feahr, OD > http://visiondatastandard.org > [EMAIL PROTECTED] > Cell/Pager: 707-529-2268 >
