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
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 protocols. We need to support all the legacy dial-up connection types - to assuage fears of the open Internet's
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
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
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
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
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
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 TCS 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: 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
