Re: Electronic Trading Partner Agreements - 3/5 Conversation with DWT
I really appreciate Dave's and Marcallee's efforts in this area. I have no interest in seeing this discussion tabled. In the beginning, I would have agreed that TPAs are "out of scope." But since then, Marcallee has certainly convinced me that if the TPA "problem" cannot be gotten out of the way, then automated trading partner "discovery" has less value. As far as I know, we are the only WEDI/SNIP group worried about this issue - the impediment of paper TPAs - at the moment. If in their wisdom, the Business Issues SWG management finds it prudent to create a new group concerned with ways to lubricate healthcare e-commerce by eliminating or ameliorating the delays in trading imposed by paper TPAs, we in the WEDi/SNIP ID & Routing SIG will defer to that decision. In the meantime, I'm only too happy to see Dave and Marcallee succeed in developing a Clearinghouse Power of Attorney or the "WEDI Accord on TPAs" - if only to prove my good friend, Kepa Zubeldia, wrong for once in his life! At Chris Feahr's prompting, a new project objective was set forth for the group to evaluate; I proposed a change to the Project Purpose on 02 March: This project will publish implementation guidelines for (1) an Electronic Trading Partner Agreement (e-TPA) specification to mechanically configure communication and translation software, and (2) automatic "discovery" mechanisms for locating Trading Partners' e-TPAs on the Internet based on their business identifiers. It seems this change would be relatively uncontroversial, in that it simply follows the gist of many of our discussions. It broadens the scope by allowing us to investigate ways not only of describing EDI addresses and attributes, but also mechanical representations of companion documents, in the formation of electronic Trading Partner Agreements. A "directory" for "discovering" EDI addresses (or going a step further: e-TPAs) has always been implicit in the 6320 document, so it's only proper to explicitly include this requirement in the Project Purpose. This change, and the working documents I proposed we start on, can be discussed tomorrow, Friday March 8, on the WEDi/SNIP ID & Routing teleconference call from 1:30 - 2:30 EST, 703-736-7290, pin #1315331. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: "Rachel Foerster" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, 06 March, 2002 07:50 PM Subject: RE: Electronic Trading Partner Agreements - 3/5 Conversation with DWT I am concerned that this effort is very much "out of scope" of the original objective of this work group, to wit: (and from Peter Barry's Document #6320 dated 2/26/02) "This project is to define the syntax of a comprehensive, standard EDI address, including attributes..to define the associated code structure. Its deliverable is intended to have technical specificity." I am concerned that focus and attention of this work group will be shifted to an out-of-scope activity and that the original project objective will not be achieved. On the other hand, if it is the consensus of this work group that the original objective is no longer valid, then a new project objective should be set forth for the group to evaluate and agree to. Else, I suggest that any further activities related to this effort either be tabled until the primary objective of the work group is achieved.or this work effort be transferred to another work group. Rachel Foerster Principal Rachel Foerster & Associates, Ltd. Professionals in EDI & Electronic Commerce 39432 North Avenue Beach Park, IL 60099 Phone: 847-872-8070 Fax: 847-872-6860 http:/www.rfa-edi.com -Original Message- From: Dave Minch [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 06, 2002 1:23 PM To: '[EMAIL PROTECTED]' Subject: FW: Electronic Trading Partner Agreements - 3/5 Conversation with DWT To all I&A folks: We wanted to let you know that some progress is being made on the trading partner agreement front concerning the legal ramifications of creation of an entirely electronic eTPA. Yesterday William Kammerer, Marcallee Jackson, and I held a conference call with 3 legal types from the law firm of Davis, Wright, Tremaine (DWT), who have volunteered to provide some level of assistance to us pro bono as we wrestle with the non-technical privacy, security, and fraud-potential issues surrounding creation of an automated eTPA. The question posed to the teleconference group was "how can DWT work with our WEDI-SNIP workgroup"? We discussed our plans to move the industry toward an "electronic TPA" rather than (in place of) signed paper agreements. The TPA we have envisioned includes technical communication protocols, security and encryption, and potentially even the "
RE: Electronic Trading Partner Agreements - 3/5 Conversation with DWT
I am concerned that this effort is very much "out of scope" of the original objective of this work group, to wit: (and from Peter Barry's Document #6320 dated 2/26/02) "This project is to define the syntax of a comprehensive, standard EDI address, including attributes..to define the associated code structure. Its deliverable is intended to have technical specificity." I am concerned that focus and attention of this work group will be shifted to an out-of-scope activity and that the original project objective will not be achieved. On the other hand, if it is the consensus of this work group that the original objective is no longer valid, then a new project objective should be set forth for the group to evaluate and agree to. Else, I suggest that any further activities related to this effort either be tabled until the primary objective of the work group is achieved.or this work effort be transferred to another work group. Rachel Foerster Principal Rachel Foerster & Associates, Ltd. Professionals in EDI & Electronic Commerce 39432 North Avenue Beach Park, IL 60099 Phone: 847-872-8070 Fax: 847-872-6860 http:/www.rfa-edi.com -Original Message- From: Dave Minch [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 06, 2002 1:23 PM To: '[EMAIL PROTECTED]' Subject: FW: Electronic Trading Partner Agreements - 3/5 Conversation with DWT To all I&A folks: We wanted to let you know that some progress is being made on the trading partner agreement front concerning the legal ramifications of creation of an entirely electronic eTPA. Yesterday William Kammerer, Marcallee Jackson, and I held a conference call with 3 legal types from the law firm of Davis, Wright, Tremaine (DWT), who have volunteered to provide some level of assistance to us pro bono as we wrestle with the non-technical privacy, security, and fraud-potential issues surrounding creation of an automated eTPA. The question posed to the teleconference group was "how can DWT work with our WEDI-SNIP workgroup"? We discussed our plans to move the industry toward an "electronic TPA" rather than (in place of) signed paper agreements. The TPA we have envisioned includes technical communication protocols, security and encryption, and potentially even the "companion guide" type of information - all of that being generally classified as the "technical" business arrangement between the trading parties. Our most pressing concern is: even if we can get all of the nuances of the "technical" business arrangement included within our electronic definition, will there still be overriding legal barriers which will still require each trading partner to negotiate and sign a paper document to comply with the HIPAA regulations. DWT explained how business agreements can be implied under the UCC. As a simple example, when a customer sends an unsolicited order to a supplier, and the supplier fills the order, there is an implied business agreement under the UCC. DWT also indicated that there is now an extension to the UCC which is being adopted in most states that specifically addresses electronic business exchanges. After some discussion, their suggestion was that if we could promote a health care industry-wide accord, that it could act as an anchor point for creation of the compliance portion of the paperless interchange agreement and would embody language which safeguards the participants. Our next steps will be to work with DWT in drafting a "talking paper" over the next 3 weeks which lists some of the key elements that such an accord would have, and how the accord would be used in conjunction with the UCC to satisfy the regulatory needs (privacy/disclosure of PHI). Stay tuned... Dave Minch T&CS Project Manager John Muir / Mt. Diablo Health System Walnut Creek, CA (925) 941-2240
RE: Electronic Trading Partner Agreements
Chris, XML Global in Vancouver has some downloadable software that supports some of the ebXML Framework Specifications. I believe they also have available an ebXML-compliant registry, as does Sun Microsystems. As no doubt you've discovered, the ebXML CPP/CPA specifications are only a portion of the entire ebXML Framework, which also includes specifications for ebXML-compliant registries/repositories, Message Service Handling as well as an overall ebXML Architecture. Check out the ebxml.org web site where you can link to the first version of all of these specificattions as well as the next versions at OASIS. I believe that there are already some implementations of the ebXML technical specifications in other industries, and most notably, RosettaNet is adopting the ebXML specifications for the electronics components industry. However, the vision of ebXML is one of distributed registries/repositories, etc. Thus, it's entirely appropriate and timely for organizations in health care to take a leadership role. By copy of this message to both David RR Webber, a leader in not only XML but ebXML and a senior executive at XML Global, and Rik Drummond, another leader in the ebXML arena and tead lead for the Message Service Specifications, I'll ask them to provide this list with whatever he can that will aid us in evaluating ebXML, including CPP/CPA. Actually, I believe that Rik's organization, The Drummond Group, is working with the UCC on implementing portions of the ebXML framework specs. Rachel -Original Message- From: Christopher J. Feahr, OD [mailto:[EMAIL PROTECTED]] Sent: Monday, February 25, 2002 3:58 PM To: William J. Kammerer; WEDi/SNIP ID & Routing Cc: Ken Wood Subject: Re: Electronic Trading Partner Agreements William, I started reading through the draft spec. for ebXML CPP and it looks like everything we have been talking about is addressed. I've inserted a summary of the "PartyInfo" section below. The Transport elements section should be able to specify all those legacy dialup settings you mentioned. I understand Dick Brooks was also looking at this. I wonder if anyone is actually "hooking up" via a simple CPP-CPA negotiation... and then passing plain old EDI interchanges.. and then un-hooking. This does imply the existence of a [simple?] CPP registry in which each Collaboration Protocol Profile is an XML document indexed with a globally unique ID number... which could be either the ProviderID or the PlanID. Each of these XML documents can be digitally signed, so it would seem that all trading partners could upload new/signed CPPs whenever local conditions changed. Each time a sender wants to transmit an interchange, it appears that he would just query the national Plan or Provider CPP registry, auto-negotiate a CPA (essentially an electronic trading partner agreement for that one interchange... TPA could be logged) which would, in turn auto-configure his system with all the transport/addressing details... click SEND! Has any "industry" grabbed hold of this yet? We have a relatively "blank-slate" in vision care and the manufacturers, labs, and other entities in the eye doctor's supply chain are meeting next month for a high level discussion of doctor-lab EDI... VERY high level. The host entity, Vision Council of America is already thinking about handling some or all of the "standards maintenance" issues associated with a Doc-Lab purchase order standard. They might be willing to maintain an ebXML registry for all potential trading partners within the vision industry. Am I understanding this general process correctly? Thanks, -Chris The PartyInfo element consists of the following child elements: · One or more REQUIRED PartyId elements that provide a logical identifier for the 734 organization. 735 · A REQUIRED PartyRef element that provides a pointer to more information about 736 the Party. 737 · One or more REQUIRED CollaborationRole elements that identify the roles that this 738 Party can play in the context of a Process Specification. 739 · One or more REQUIRED Certificate elements that identify the certificates used by 740 this Party in security functions. 741 · One or more REQUIRED DeliveryChannel elements that define the characteristics of 742 each delivery channel that the Party can use to receive Messages. It includes both the 743 transport level (e.g. HTTP) and the messaging protocol (e.g. ebXML Message 744 Service). 745 · One or more REQUIRED Transport elements that define the characteristics of the 746 transport protocol(s) that the Party can support to receive Messages. 747 · One or more REQUIRED DocExchange elements that define the Message-exchange 748 characteristics, such as the Message-exchange protocol, that the Party can support. 749 At 12:23 PM 2/25/02 -0500, William J. Kammerer wrote: >It's unrealistic to restrict transport methods to the common TCP/IP >prot
Re: Electronic Trading Partner Agreements
William, I started reading through the draft spec. for ebXML CPP and it looks like everything we have been talking about is addressed. I've inserted a summary of the "PartyInfo" section below. The Transport elements section should be able to specify all those legacy dialup settings you mentioned. I understand Dick Brooks was also looking at this. I wonder if anyone is actually "hooking up" via a simple CPP-CPA negotiation... and then passing plain old EDI interchanges.. and then un-hooking. This does imply the existence of a [simple?] CPP registry in which each Collaboration Protocol Profile is an XML document indexed with a globally unique ID number... which could be either the ProviderID or the PlanID. Each of these XML documents can be digitally signed, so it would seem that all trading partners could upload new/signed CPPs whenever local conditions changed. Each time a sender wants to transmit an interchange, it appears that he would just query the national Plan or Provider CPP registry, auto-negotiate a CPA (essentially an electronic trading partner agreement for that one interchange... TPA could be logged) which would, in turn auto-configure his system with all the transport/addressing details... click SEND! Has any "industry" grabbed hold of this yet? We have a relatively "blank-slate" in vision care and the manufacturers, labs, and other entities in the eye doctor's supply chain are meeting next month for a high level discussion of doctor-lab EDI... VERY high level. The host entity, Vision Council of America is already thinking about handling some or all of the "standards maintenance" issues associated with a Doc-Lab purchase order standard. They might be willing to maintain an ebXML registry for all potential trading partners within the vision industry. Am I understanding this general process correctly? Thanks, -Chris The PartyInfo element consists of the following child elements: · One or more REQUIRED PartyId elements that provide a logical identifier for the 734 organization. 735 · A REQUIRED PartyRef element that provides a pointer to more information about 736 the Party. 737 · One or more REQUIRED CollaborationRole elements that identify the roles that this 738 Party can play in the context of a Process Specification. 739 · One or more REQUIRED Certificate elements that identify the certificates used by 740 this Party in security functions. 741 · One or more REQUIRED DeliveryChannel elements that define the characteristics of 742 each delivery channel that the Party can use to receive Messages. It includes both the 743 transport level (e.g. HTTP) and the messaging protocol (e.g. ebXML Message 744 Service). 745 · One or more REQUIRED Transport elements that define the characteristics of the 746 transport protocol(s) that the Party can support to receive Messages. 747 · One or more REQUIRED DocExchange elements that define the Message-exchange 748 characteristics, such as the Message-exchange protocol, that the Party can support. 749 At 12:23 PM 2/25/02 -0500, William J. Kammerer wrote: >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. Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
Re: Electronic Trading Partner Agreements
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]
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
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
RE: Electronic Trading Partner Agreements
Dick, The company uses a direct connection to the health plans for the 834's which would use a username/password on the receiving EDI gateway. They use a VAN for all other EDI transactions (non HIPAA). 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 7:54 AM 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? Is it a username/password protected site? 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
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
Re: Electronic Trading Partner Agreements: Transitivity
Rachel said that COTs (or, really, COTAs - Chain of Trust Agreements) are really out of scope since they actually pertain to the Security NPRM. And besides, they are agreements between business associates themselves, and between BAs and covered entities (payers, providers and Clearinghouses). I'm guessing a COTA would not be required directly between a payer and a provider (or payer and a CH) since, as covered entities, they are all required to be careful with protected health information. Everybody else coming into contact with PHI can freely disseminate it to the wind, unless otherwise covered by a COTA! When I said COTAs were transitive, I just meant that there was no need to have a COTA between A and C, using B as an intermediary, if there were already a COTA between A and B, and another one between C and B (I'm assuming COTAs are also associative). A Trading Partner Agreement, on the other hand, is by definition *between* trading partners - the "end points" - i.e., a payer and a provider, a payer and a bank, an employer and a payer, etc. But I suppose TPAs could be (somewhat) "transitive" too: maybe a CH could say if you sign up with us, you agree to certain common criteria and remedies, and to use the standard WEDi/SNIP Electronic Trading Partner Agreement accessible through Kepa's DNS "directory." The only signed contract (strictly speaking, not a "TPA") in this case would be between the CH and its customer (the payer, provider or yet another CH). This is the same "transitive" model used in the credit card business: I have (1) a signed agreement with my bank, and (2) my bank has a "member" agreement with VISA, (3) likewise, my merchant's bank has a "member" agreement with VISA, and (4) the merchant's bank has an agreement with the merchant himself. Add in some law, like Regs. E and Z, and you have an efficient system that obviates any need for a separate agreement between me and every merchant with whom I use my VISA card. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: "Ronald Bowron" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, 20 February, 2002 10:32 AM Subject: Re: Electronic Trading Partner Agreements William, I agree with your assessment that manual TPA's would render any automated routing methodology moot. I had previously raised the question as to why the TPA cannot be transitive like the COT? Better yet, why not combine the COT with the TPA? Then the COT/TPA assumes the Payer trusts the Clearinghouse or Repricer to ensure the validity of the Provider (Each CE carries the trust from the previous entity). Not being a legal person, I don't know if this would be advisable or not. There are Provider Credentialing services out there that will substantiate the licensing of an individual provider, as well. I believe the infrastructure exists today, although it is not coupled with the electronic transaction processing, and most likely not well supported by the electronic processing systems. If we could define the methodology for verifying the identity of a CE as part of the TPA process, then the TPA may be able to be automated. I've always advocated, if a manual processing works then consider automation. If it's broken and you automate - you exacerbate the problem 10,000 times more often. So, is the current manual TPA process working well enough that it is possible to introduce automation and standards? Have any of the larger payers moved to a Web Based TPA process? Would a notary model like Thawte (www.thawte.com) is using for certificates be acceptable, or overly complicated? So many questions, so little time. I believe Kepa has the appropriate approach to solving the lower level routing issues, but now we need to walk that back into the business process level and see what falls apart. If business requirements dictate a TPA between CE's before routing can occur, then we must address how TPA's can support our efforts to automate routing. Regards, Ronald Bowron
RE: Electronic Trading Partner Agreements
William, There is another listserv which is called HIT at [EMAIL PROTECTED] This listserv was established a couple of years ago when HIPAA regs started coming down and is a great forum for asking legal-type questions and getting opinions from the various participants. Our CCO (chief compliance officer) monitors this listserv. I'm checking back to see if anything specific has been posted on TPAgreements, but if we want to pose a specific question, I could post it and see what we get back. Dave Minch T&CS Project Manager John Muir / Mt. Diablo Health System Walnut Creek, CA (925) 941-2240 -Original Message- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 20, 2002 10:04 AM To: WEDi/SNIP ID & Routing Subject: Re: Electronic Trading Partner Agreements Can David Frenkel elucidate those things in a TPA that are of interest to lawyers? Could a general purpose, or default, TPA be devised that applies in the absence of a signed contract? - one that says the electronic version is good for all that ails you? Failure to take claims into adjudication and such are practically going to be "criminalized" under HIPAA, so what's the point of a private contract unless it were to spell out (additional) legal remedies? What if you needed a contract every time you bought a donut, newspaper or coffee? - or checked into a hotel? - that's right: commerce would grind to a halt. That's why laws and the U.C.C. have evolved over time to take care of these (default) issues. If all contingencies that the lawyers are interested in were codified into the HIPAA rule, then there might be a clean way to avoid separate contracts and TPAs. That may not solve the problem entirely, though: I once had a lawyer who insisted on copying - wholesale - entire sections of the Ohio Revised Code into agreements (I and the other party were both in Ohio, by the way, and presumably subject to its jurisdiction), as if this guy got paid by each Wordperfect edit. Are there any lawyers on this listserve listening who would be willing to help out? ebXML has their own resident lawyer, James "Jamie" Bryce Clark, General Counsel of McLure-Moynihan Inc., who has been eminently helpful to the ebXML Business Process Group. Does anyone know of a lawyer who wants to do some similar "pro bono" (Italian for "free") work here? William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: "David Frenkel" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, 20 February, 2002 10:55 AM Subject: RE: Electronic Trading Partner Agreements Ron, I don't think the TPA process works well today given that every legal department has a different flavor and it is a legal contract. Many legal departments may not want to loose control over this. Regards, David Frenkel Business Development GEFEG USA Global Leader in Ecommerce Tools www.gefeg.com 425-260-5030
RE: Electronic Trading Partner Agreements
William, I agree that TPA's could be standardized as you suggested, I don't disagree with any of your suggestions. There have been plenty of TPA stories on this listserv illustrating the problem including Marcalle Jackson's email earlier today. Unfortunately, the medical industry has no shortage of lawyers and it is not an easy comparison to selling donuts. I know of a large medical device company that has a law firm as their HIPAA consultants. 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 10:04 AM To: WEDi/SNIP ID & Routing Subject: Re: Electronic Trading Partner Agreements Can David Frenkel elucidate those things in a TPA that are of interest to lawyers? Could a general purpose, or default, TPA be devised that applies in the absence of a signed contract? - one that says the electronic version is good for all that ails you? Failure to take claims into adjudication and such are practically going to be "criminalized" under HIPAA, so what's the point of a private contract unless it were to spell out (additional) legal remedies? What if you needed a contract every time you bought a donut, newspaper or coffee? - or checked into a hotel? - that's right: commerce would grind to a halt. That's why laws and the U.C.C. have evolved over time to take care of these (default) issues. If all contingencies that the lawyers are interested in were codified into the HIPAA rule, then there might be a clean way to avoid separate contracts and TPAs. That may not solve the problem entirely, though: I once had a lawyer who insisted on copying - wholesale - entire sections of the Ohio Revised Code into agreements (I and the other party were both in Ohio, by the way, and presumably subject to its jurisdiction), as if this guy got paid by each Wordperfect edit. Are there any lawyers on this listserve listening who would be willing to help out? ebXML has their own resident lawyer, James "Jamie" Bryce Clark, General Counsel of McLure-Moynihan Inc., who has been eminently helpful to the ebXML Business Process Group. Does anyone know of a lawyer who wants to do some similar "pro bono" (Italian for "free") work here? William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: "David Frenkel" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, 20 February, 2002 10:55 AM Subject: RE: Electronic Trading Partner Agreements Ron, I don't think the TPA process works well today given that every legal department has a different flavor and it is a legal contract. Many legal departments may not want to loose control over this. Regards, David Frenkel Business Development GEFEG USA Global Leader in Ecommerce Tools www.gefeg.com 425-260-5030
Re: Electronic Trading Partner Agreements
Can David Frenkel elucidate those things in a TPA that are of interest to lawyers? Could a general purpose, or default, TPA be devised that applies in the absence of a signed contract? - one that says the electronic version is good for all that ails you? Failure to take claims into adjudication and such are practically going to be "criminalized" under HIPAA, so what's the point of a private contract unless it were to spell out (additional) legal remedies? What if you needed a contract every time you bought a donut, newspaper or coffee? - or checked into a hotel? - that's right: commerce would grind to a halt. That's why laws and the U.C.C. have evolved over time to take care of these (default) issues. If all contingencies that the lawyers are interested in were codified into the HIPAA rule, then there might be a clean way to avoid separate contracts and TPAs. That may not solve the problem entirely, though: I once had a lawyer who insisted on copying - wholesale - entire sections of the Ohio Revised Code into agreements (I and the other party were both in Ohio, by the way, and presumably subject to its jurisdiction), as if this guy got paid by each Wordperfect edit. Are there any lawyers on this listserve listening who would be willing to help out? ebXML has their own resident lawyer, James "Jamie" Bryce Clark, General Counsel of McLure-Moynihan Inc., who has been eminently helpful to the ebXML Business Process Group. Does anyone know of a lawyer who wants to do some similar "pro bono" (Italian for "free") work here? William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: "David Frenkel" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, 20 February, 2002 10:55 AM Subject: RE: Electronic Trading Partner Agreements Ron, I don't think the TPA process works well today given that every legal department has a different flavor and it is a legal contract. Many legal departments may not want to loose control over this. Regards, David Frenkel Business Development GEFEG USA Global Leader in Ecommerce Tools www.gefeg.com 425-260-5030
RE: Electronic Trading Partner Agreements
Today providers who use a CH complete 3 - 5 TPA/Enrollment forms - Medicare, Medicaid, BCBS and Champus are payers that almost always require agreements. In my experience it takes an average of 2 - 3 weeks for a CH to receive completed paperwork from the provider and an additional 6 - 8 weeks for approval from the payer (though BCBS often approves in 2 - 3). It takes providers as long to complete their part of the enrollment paper work for these payers as it does for most to complete testing, implementation, training and full production for payers who don't require it. That's if the enrollment process goes well. Many payers are very particular when it comes to their agreements. Some require the signature of every physician in a group (imagine that if you have 50+ physicians), most require a listing of every group number and provider ID, some require social security numbers, some that the agreement be sent in on a particular color of paper, others that only a particular color of ink may be used and most will reject the agreement for any error. Each agreement is proprietary. It often takes 2 or more attempts before the provider gets it right. The whole process is an incredible hassle. In other situations, the payer does not require a written agreement between the provider and payer but does require the CH to obtain authorization. This process, while still time consuming, is far easier than the one described above. I am strongly in support of TPA's combined with COT's and entered into only by the parties directly exchanging data. It also seems that some sort of power of attorney between the provider and CH should be sufficient to allow the CH to auto-enroll its clients with the payer, particularly for the simple exchange of data. More complicated data exchanges, such as EFT or split routing, may require a more manual process but those exchanges are not common today and not likely to be in the near future. I stress that the vast majority of payers today do not require any TPA or enrollment process between themselves and physicians who bill through a CH. These include payers such as Aetna, Cigna, United Healthcare, Coventry Healthcare, Humana and Prudential. I'd suggest we look at their current model and find ways to keep it. AFEHCT is very interested in this issue and I believe is also planning on a work group. Marcallee Jackson Long Beach, CA 562-438-6613 -Original Message- From: Ronald Bowron [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 20, 2002 7:33 AM To: [EMAIL PROTECTED] Subject: Re: Electronic Trading Partner Agreements William, I agree with your assessment that manual TPA's would render any automated routing methodology moot. I had previously raised the question as to why the TPA cannot be transitive like the COT? Better yet, why not combine the COT with the TPA? Then the COT/TPA assumes the Payer trusts the Clearinghouse or Repricer to ensure the validity of the Provider (Each CE carries the trust from the previous entity). Not being a legal person, I don't know if this would be advisable or not. There are Provider Credentialing services out there that will substantiate the licensing of an individual provider, as well. I believe the infrastructure exists today, although it is not coupled with the electronic transaction processing, and most likely not well supported by the electronic processing systems. If we could define the methodology for verifying the identity of a CE as part of the TPA process, then the TPA may be able to be automated. I've always advocated, if a manual processing works then consider automation. If it's broken and you automate - you exacerbate the problem 10,000 times more often. So, is the current manual TPA process working well enough that it is possible to introduce automation and standards? Have any of the larger payers moved to a Web Based TPA process? Would a notary model like Thawte (www.thawte.com) is using for certificates be acceptable, or overly complicated? So many questions, so little time. I believe Kepa has the appropriate approach to solving the lower level routing issues, but now we need to walk that back into the business process level and see what falls apart. If business requirements dictate a TPA between CE's before routing can occur, then we must address how TPA's can support our efforts to automate routing. Regards, Ronald Bowron
RE: Electronic Trading Partner Agreements
Ron, I don't think the TPA process works well today given that every legal department has a different flavor and it is a legal contract. Many legal departments may not want to loose control over this. Regards, David Frenkel Business Development GEFEG USA Global Leader in Ecommerce Tools www.gefeg.com 425-260-5030 -Original Message- From: Ronald Bowron [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 20, 2002 7:33 AM To: [EMAIL PROTECTED] Subject: Re: Electronic Trading Partner Agreements William, I agree with your assessment that manual TPA's would render any automated routing methodology moot. I had previously raised the question as to why the TPA cannot be transitive like the COT? Better yet, why not combine the COT with the TPA? Then the COT/TPA assumes the Payer trusts the Clearinghouse or Repricer to ensure the validity of the Provider (Each CE carries the trust from the previous entity). Not being a legal person, I don't know if this would be advisable or not. There are Provider Credentialing services out there that will substantiate the licensing of an individual provider, as well. I believe the infrastructure exists today, although it is not coupled with the electronic transaction processing, and most likely not well supported by the electronic processing systems. If we could define the methodology for verifying the identity of a CE as part of the TPA process, then the TPA may be able to be automated. I've always advocated, if a manual processing works then consider automation. If it's broken and you automate - you exacerbate the problem 10,000 times more often. So, is the current manual TPA process working well enough that it is possible to introduce automation and standards? Have any of the larger payers moved to a Web Based TPA process? Would a notary model like Thawte (www.thawte.com) is using for certificates be acceptable, or overly complicated? So many questions, so little time. I believe Kepa has the appropriate approach to solving the lower level routing issues, but now we need to walk that back into the business process level and see what falls apart. If business requirements dictate a TPA between CE's before routing can occur, then we must address how TPA's can support our efforts to automate routing. Regards, Ronald Bowron
Re: Electronic Trading Partner Agreements
William, I agree with your assessment that manual TPA's would render any automated routing methodology moot. I had previously raised the question as to why the TPA cannot be transitive like the COT? Better yet, why not combine the COT with the TPA? Then the COT/TPA assumes the Payer trusts the Clearinghouse or Repricer to ensure the validity of the Provider (Each CE carries the trust from the previous entity). Not being a legal person, I don't know if this would be advisable or not. There are Provider Credentialing services out there that will substantiate the licensing of an individual provider, as well. I believe the infrastructure exists today, although it is not coupled with the electronic transaction processing, and most likely not well supported by the electronic processing systems. If we could define the methodology for verifying the identity of a CE as part of the TPA process, then the TPA may be able to be automated. I've always advocated, if a manual processing works then consider automation. If it's broken and you automate - you exacerbate the problem 10,000 times more often. So, is the current manual TPA process working well enough that it is possible to introduce automation and standards? Have any of the larger payers moved to a Web Based TPA process? Would a notary model like Thawte (www.thawte.com) is using for certificates be acceptable, or overly complicated? So many questions, so little time. I believe Kepa has the appropriate approach to solving the lower level routing issues, but now we need to walk that back into the business process level and see what falls apart. If business requirements dictate a TPA between CE's before routing can occur, then we must address how TPA's can support our efforts to automate routing. Regards, Ronald Bowron
