We certainly don't want to miss how things are done today with respect to transport protocols. Tim Collins, at [EMAIL PROTECTED], has "volunteered" to catalog transport protocols for use in Peter Barry's "Attributes of the address" (which include questions of media, packaging, security, and communications capabilities). Please write to Tim (or to the list) with specific examples to make sure nothing is inadvertently dropped.
It's unrealistic to restrict transport methods to the common TCP/IP protocols. We need to support all the "legacy" dial-up connection types - to assuage fears of the open Internet's security "problems" or to simply support the PM systems out there already - with some means of describing scripts, logins, passwords, modem-settings, etc. etc. in our Electronic Trading Partner Agreement. Of course, I want to emphasize again that we are only concerned with the packaging, routing and securing of STANDARD (HIPAA X12 and NCPDP) transactions between any two entities. We are not looking at situations where practice management software is generating or receiving proprietary formats through a CH; proprietary links (those not using standard transactions) to a CH or business associate are out of scope. We are, after all, the Workgroup for "Electronic Data Interchange." I'll ask again what I asked on the 11th: "...does anyone know of any OASIS, W3C, IETF, etc. effort for devising XML files to describe all communication capabilities of a partner? .... I want to see something that says 'this is a dial-up using Kermit with this phone number.' Surely someone has devised a schema for describing communication capabilities. There's no sense in us reinventing the wheel." As an aside, Dick Brooks has in the past brought up the need to assign a username/password to each trading partner before granting access to a B2B server - how is this to be automated, and what effect does this have on the use of electronic Trading Partner Agreements? Maybe userids and passwords could be avoided altogether if B2B servers were somehow to employ digital certificates instead for granting access - e.g., they could grant access to legitimate providers who hold one of those AMA/Verisign issued digital certificates. Otherwise, if someone wants to ensure ahead of time who will be sending transactions before assigning a userid and password, then there seems to be no way around some kind of manual interaction - whether it is a paper TPA or a web registration. At least an Electronic Trading Partner Agreement could give the URL where a provider is to manually register, so the userID and password can be e-mailed. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 ----- Original Message ----- From: "Wolinski, Robert" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, 25 February, 2002 10:22 AM Subject: FW: Electronic Trading Partner Agreements Good morning all. I have been reading the discussions on this list server for several weeks now. My current position is with Coventry Health Care, a nationally based Health Insurer. We currently receive our Inbound 837 claims from WebMD. We also receive Authorization requests from WebMD in a proprietary format. We send to them a number of other transactions, including 835 remittance information. This is all accomplished through the use of a T1 line and the FTP Protocol. No file encryption involved. For our inbound enrollment data, some of it does come to us utilizing PGP file encryption, and other data we dial out and retrieve using FTP, ZMODEM, and even old XMODEM. Prior to coming to Coventry, I was with one of the nations largest Practice Management Software companies, now called Misys Health Care. They own one of the largest Clearing Houses as well. All the providers that utilized that Clearing House did so through the use of a modem and dial up connection, utilizing FTP to transfer the files. This was for 837 and 835 transactions, as well as reports. I believe, as it appears to me, most of you do, that the Internet will be the transfer method of the future. My concern is that this group may have missed how things are working today and that the vast majority of Providers, not Hospitals, are not connected to the Internet through their PM Products. These Providers, for the most part, do not have the staff in place to implement anything outside of what their PM Software Company provides. It has been a year and a half since I have been on the PM Software Development side, so things may have change. I would like to hear from some PM Software groups to see what functionality they currently have, as well as what they see the future being, and when they expect to be there. Bob Wolinski Business Consultant EDI Production Support Team Coordinator Coventry Health Care 724/778-5314 [EMAIL PROTECTED]
