I am running a few days behind in my emails, so this is arriving late in the discussion, but I thought I'd drop the list of protocols we are dealing with as a point of reference. We are limited, at least today, in that Medicare refuses to allow us to use any Internet application for their data, so our Internet approach is not as broad as perhaps we would like.
We support all of the standard dial-up protocols; X, Y, Z and Kermit. We also support a dial-up ftp, but not over the open internet. We do support a discrete type of transaction using HTTPS, encapsulating transactions in a proprietary XML dialogue, but this requires specialized software. We also support SNA, using NDM. And lastly, and a current lesser favorite of our technical staff, secure shell file transfer. ------------------( Forwarded letter 1 follows )-------------------- Date: Tue, 18 Jun 2002 10:54:04 -0400 To: WEDi/SNIP.ID.&.Routing[routing]@wedi.org.comp From: William.J.Kammerer[wkammerer]@novannet.com.comp Sender: [EMAIL PROTECTED] Subject: Re: Route through email and attach EDI files Deepan: Assuming your Practice Management System processes HIPAA standard transactions, and you intend to transport point-to-point, then I guess you have no choice but to support most conceivable means (protocol and packaging) of sending and receiving interchanges. An alternative is to support just the more common methods (whatever they are in healthcare: we need to determine this), and then encourage your customer to use a VAN or clearinghouse as an intermediary if the payer requires anything weird (e.g., 3780 BSC). Your core-competency is probably not communications software, so it's possible you're limited to the protocols supported in whatever third-party comm package you've perhaps integrated into your system. Just like with the Cleos, IpSwitches and EDIINT packages of the world, your customers will have onerous manual setup for each of their payers. I hate modems and comm settings (and printers), so I am only too relieved to have a single Internet connection to the world - that simplifies things quite a bit. But even with the internet (FTP, SMTP and HTTP) and the payer-centric mailbox model, there's still manual setup for each payer required. Eventually, if every payer (or their CH proxy) supported the CPP, you could write your software so your customer would be able to "insert" the CPP (Electronic Partner Profile) to auto-configure the communications settings. And then even later on, your software could be made smart enough to search the Healthcare CPP Registry so CPPs wouldn't have to be manually handled. That's the "vision thing," anyway. In the meantime, you're on your own. So to help us out in determining requirements for the EDI address (DeliveryChannel) part of the CPP, perhaps you could give us the details of communication methods demanded in your marketspace - in effect, the protocols supported by payers. We need "meat" and detail. I vaguely know there're some common ones supported by payers (e.g., XMODEM, XMODEM-1K, YMODEM, YMODEM-G, ZMODEM, etc. etc.), all requiring dial-up into the payer's system. Will payers and CHs be supporting SMTP, EDIINT, FTP or HTTP over the Internet? If so, please share the details. These aren't competitive trade secrets. This is also an invitation to payers and clearinghouses to share their supported communication protocols. Again, if you and Julie Thompson really have reason to think the Final Security regulations might "completely change the choices available for transaction routing," tell me what you believe - if only your speculation - and your rationale for believing so. I'm not a mind-reader, and would prefer to work with detail rather than vague pronouncements. I doubt seriously that any of the final regulations will specify (or disallow) particular transport methods, or change the requirement that encryption be used when transmitting PHI over the public Internet. Common sense will dictate that "encryption" excludes "home-grown" cipher techniques, whether or not explicitly stated in the regs: it would be irresponsible to use any but peer-reviewed encryption algorithms (in effect, "standards" such as the symmetric IDEA, RC2, RC4, DES, DES3 and Blowfish, and the asymmetric RSA), or PGP and X.509 PKIs. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 ----- Original Message ----- From: "Deepan Vashi" <[EMAIL PROTECTED]> To: "Martin Scholl" <[EMAIL PROTECTED]>; "William J. Kammerer" <[EMAIL PROTECTED]>; "WEDi/SNIP ID & Routing" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, 18 June, 2002 05:05 AM Subject: Re: Route through email and attach EDI files 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
