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]
-----Original Message-----
From: David Frenkel [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 22, 2002 6:55 PM
To: 'WEDi/SNIP ID & Routing'
Subject: RE: Electronic Trading Partner Agreements
Dick,
I think where you are going with this is are they using a secured leased
line or is the file encrypted. I can find out next week.
Regards,
David Frenkel
Business Development
GEFEG USA
Global Leader in Ecommerce Tools
www.gefeg.com
425-260-5030
-----Original Message-----
From: Dick Brooks [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 22, 2002 3:43 PM
To: David Frenkel; 'WEDi/SNIP ID & Routing'
Subject: RE: Electronic Trading Partner Agreements
David,
Would you mind sharing "how" these transactions are being transmitted by
the
Fortune 100 company to the insurer?
Thanks,
Dick Brooks
Systrends, Inc
7855 South River Parkway, Suite 111
Tempe, Arizona 85284
Web: www.systrends.com <http://www.systrends.com>
Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714
-----Original Message-----
From: David Frenkel [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 21, 2002 11:30 AM
To: 'WEDi/SNIP ID & Routing'
Subject: RE: Electronic Trading Partner Agreements
I spoke to a Fortune 100 company that is sending HIPAA compliant
employee benefit enrollments (834) to its health plans. None of the
health plans is requiring trading partner agreements (TPA's).
Regards,
David Frenkel
Business Development
GEFEG USA
Global Leader in Ecommerce Tools
www.gefeg.com
425-260-5030
-----Original Message-----
From: William J. Kammerer [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 20, 2002 6:17 AM
To: WEDi/SNIP ID & Routing
Subject: Electronic Trading Partner Agreements
The issue of Trading Partner Agreements arose in the Business Issues
Teleconference yesterday. Discussion led me to believe that it's still
unclear whether paper Trading Partner Agreements will be needed or
desirable under HIPAA. For background, you should definitely look at
the WEDi document "Trading Partner Agreements: A White Paper Describing
the Business Issues and Recommended Solutions Associated with Trading
Partner Agreements," by Doug Renshaw. It's available under
"Transactions Workgroup White Papers" at the WEDi/SNIP site at
http://snip.wedi.org/public/articles/Trading113000.pdf.
The topic came up because one of the callers wanted to know how - other
than by using a TPA - a sponsor (employer) would know whether to send to
the payer a full compilation of enrollees, vs. just the changes since
they last "talked." Other things a TPA might be required to resolve are
the situations (as in "situational") where data is expected or desired.
Fortunately, there seemed to be nothing in the discussion of a legal
nature - i.e., everything was technical, which means a mechanical or
electronic Trading Partner Agreement might suffice.
Besides these issues the caller brought up, I wanted to see what Doug
and his team came up with. His document is an excellent compendium of
the situations calling for agreement ahead of time. But, fortunately, I
saw nothing which could not be mechanized! Though he had the usual
stuff like specifying communication protocols, Clearinghouse
designations, and agreements on maximum numbers of claims (e.g., 5000
claims in the 837), he mentioned nothing that would require Lawyer Man
to get in the way of real business.
I probably can't emphasize enough how paper TPAs will gum up the works
in automated partner recruitment - to the point where our work in the
WEDi/SNIP ID & Routing Special Interest Group might be rendered moot.
What's the point of automated "discovery" of trading partner technical
requirements (communications and protocols) if that stuff may as well
travel with the paper TPA? Marcallee Jackson has confirmed that signed
paper TPAs would involve so much overhead that they "will cause the
labor costs associated with EDI enrollment to sky rocket." Rachel
Foerster has also related the story of the (bad) experience with TPAs
when required by the Federal Government.
Even though we have sub-projects for looking seriously at the ebXML CPP
(basically a mechanical Trading Partner Agreement or Profile) and the
838 - led by Dick Brooks and Dave Minch, resp. - I'm suggesting that we
move the concept of Electronic Trading Partner Agreements to the
front-burner. If we can mechanically represent in them everything Doug
has enumerated in the white paper, we'll be better prepared to fight the
conservative tendency to require paper TPAs.
Electronic Trading Partner Agreements fit into our scheme quite
elegantly, in that Kepa's DNS "directory" would be used to find a
trading partner's profile based on identifier. The profile itself would,
in addition to the stuff mentioned in the white paper, have the
technical routing information for interchanges. In effect, you'd be
"discovering" electronic trading partner agreements, not "inboxes,"
"portals," or "front doors."
William J. Kammerer
Novannet, LLC.
+1 (614) 487-0320
