Ronald Bowron brings up the interesting notion of using the ebXML CPP (Collaboration-Protocol Profile) to, in effect, define each healthcare participant insofar as their connectivity and security options go. As with UDDI, CPPs can be keyed on any number of IDs (or less importantly in the healthcare context: searched by type of business). Any number of Delivery Channels and Transport specifications can be specified to give the particular transport capabilities and security requirements of the trading partner. In light of the ubiquitous Internet, the only supported transport protocols are SMTP (e-mail), HTTP and FTP.
Let's put aside my assumption that packaging of EDI transactions would have to conform to ebXML's Messaging Specification. And let's also ignore the inconvenient fact that none of this ebXML stuff is ready for prime time, yet. Even then, is the CPP's restriction of transport to these common TCP/IP protocols (SMTP, HTTP and FTP) workable? It is for me: the last thing I would want to catalog would be all the (practically infinite) non-Internet protocols out there: BiSynch, Zmodem, Async, X.25, etc. etc. I hate modems and I hate printers: I figure once I have been connected to the Internet, it's free-sailing from there! As a matter of fact, I would think a payer might be sorely tempted to require some obscure protocol, necessitating the acquisition of strange modems and such, in order to do the "free" direct submission of claims as required under HIPAA. This is not unheard of in the retail world, where some 800 lb. gorilla "Big Box" stores require their vendors to use 9600 bps Bisynch dial-up. Though on the surface these requirements seem to be a perverse way of humiliating vendors, they could have some logic behind them, in that dial-up BiSynch would be perceived to be secure. This concern might be behind Claredi's new offering of dial-up connections for testing standard transactions (though its restriction to TCP/IP protocols vastly simplifies matters). So, when we get around to cataloging transport protocols to describe Peter Barry's "Attributes of the address" (which include questions of media, packaging, security, and communications capabilities), do we want to restrict them to the common TCP/IP protocols? William J. Kammerer Novannet, LLC.
