The first reason that a payer would enter into a TPA with a provider that we are recommending is the routing and addressing of "How to" send a transaction envelope. Especially for those providers that have not in the past sent any electronic communication to the payer.
Ruth Tucci-Kaufhold UNISYS Corporation 4050 Innslake Drive Suite 202 Glen Allen, VA 23060 (804) 346-1138 (804) 935-1647 (fax) N246-1138 [EMAIL PROTECTED] -----Original Message----- From: Marcallee Jackson [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 23, 2002 2:09 PM To: [EMAIL PROTECTED]; 'Tucci-Kaufhold, Ruth A.'; 'WEDi/SNIP ID & Routing' Subject: RE: The Chain of Trust Question This maybe outside the scope of this group, but I need help understanding TPA's between a payer and provider. I get VERY nervous when I hear folks talking about providers entering into TPA's with payers because this process can be incredibly labor intensive, drive down EDI transaction volume, drive up the cost of EDI implementation and expand the time frame to implement. >From a provider perspective, if a provider chooses to contract with a clearinghouse, the clearinghouse is its trading partner and will provide a TPA defining requirements for exchanging transactions. The provider should not have to enter into a proprietary individual TPA with every payer with which it might ever need to exchange a transaction. This is of particular concern because when these proprietary agreements are required, the cost of managing the process is disproportionately assigned to the providers and their clearinghouses. So, off the soap box and to the question - Why would a TPA be entered into between the payer and provider rather than between their third parties? Marcallee Jackson Long Beach, CA 562-438-6613 -----Original Message----- From: Rachel Foerster [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 23, 2002 10:17 AM To: 'Tucci-Kaufhold, Ruth A.'; 'WEDi/SNIP ID & Routing' Subject: RE: The Chain of Trust Question Ruth, Only to a point. The TPA typically is between the two trading partners, i.e., the provider and payer. The BAC would be between a provider and its 3rd party service provider or the payer and its 3rd party service provider. As you know, the BAC is to contractually obligate the business associate to all of the requirements of HIPAA. This contractual obligation is not needed between two covered entitities since individually each is already bound to comply with the law and regs. Thus, a TPA would not necessarily be in place between either a provider or payer and their respective business associate. On the other hand, I do agree that the identification, routing, and other requirements for exchanging HIPAA transctions belong in a TPA. Such other information as to whether the payer conducts transactions in real-time, interactive, or batch mode, what if any different identifiers might be required for each mode, key contacts, use of clearinghouses or other options for establishing connectivity, and other pertinent information to the exchange of EDI transactions would also be included. Rachel Foerster Rachel Foerster & Associates, Ltd. Phone: 847-872-8070 -----Original Message----- From: Tucci-Kaufhold, Ruth A. [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 23, 2002 12:04 PM To: 'WEDi/SNIP ID & Routing' Subject: RE: The Chain of Trust Question Good Idea, but there is the TPA. When an organization is reviewing its Legal HIPAA Tasks, shouldn't all three agreements be specifically noted? Can all three agreements be contained in one all encompassing document? If so, would the hierarchy be: Business Associate, contains COT, contains TPA? And within the TPA is the addressing and routing information? Ruth Tucci-Kaufhold UNISYS Corporation 4050 Innslake Drive Suite 202 Glen Allen, VA 23060 (804) 346-1138 (804) 935-1647 (fax) N246-1138 [EMAIL PROTECTED] -----Original Message----- From: Rachel Foerster [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 23, 2002 12:10 PM To: 'WEDi/SNIP ID & Routing' Subject: RE: The Chain of Trust Question I would like to suggest that the issue of a chain of trust agreement is out of scope. The concept of a chain of trust agreement emanates from the Security NPRM. Indications from DHHS are that the COT agreement concept will be brought into sync with the Business Associate agreement in the Privacy rule. These two types of agreements address the confidentiality and security of PHI. As we all know, all of the HIPAA transactions contain PHI. Thus all are covered by the privacy requirerments and the requirement to safeguard PHI. So, my opinion is that the concept of COT agreements is not in scope and we shouldn't get sidetracked into discussing how one entity contracts with another entity to achieve compliance with the Privacy rule and the security NPRM. Rachel Foerster Rachel Foerster & Associates, Ltd. Phone: 847-872-8070 -----Original Message----- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 22, 2002 6:44 PM To: WEDi/SNIP ID & Routing Subject: The Chain of Trust Question Ronald Bowron's Chain of Trust questions are really interesting! Until the time Rachel - who actually knows the difference between a Chain of Trust, Covered Entity and Business Associate - chimes in, let me add some random and possibly legally irresponsible (but oh so mathematically consistent) observations. Is it unreasonable to think a provider just needs one COT with each of the one or more clearinghouses she's subscribed to? Likewise, the CH would also have a COT with each of its subscribing payers. Since COTs are transitive, it stands to reason that any pairwise communication between any provider and any payer (via the CH) would be covered (by two separate COTs). Q.E.D. Interconnects just stretch the chain - each interconnecting VAN or CH would have a COT executed between themselves. Then no matter how many links are traversed between intermediaries, a COT exists to cover the transaction. I don't know what to make of Bowron's assumption that "...the Providers trading tables would contain the appropriate ISA-sender/receiver criteria based on the agreed chain of trust and registration information." Does it matter that the endpoints (the individual provider, and the payer to whom she is submitting a claim) have a COT executed between them? If not, there's no reason to overload trading partner tables with COT information: as long as the direct connection (the CH to the provider) is covered, then the provider should be safe in assuming all subsequent links are protected. Otherwise, why call it a "Chain"? William J. Kammerer Novannet, LLC. +1 (614) 487-0320 ----- Original Message ----- From: "Ronald Bowron" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, 22 January, 2002 05:55 PM Subject: Re: The ISA may only be one part of the problem. So, based on some of the recent discussions. I'm like to raise some questions regarding business problems with the current ISA sender/receiver pairs vs. the technical problems. Let's assume for a minute that a Provider decides to purchase a clearinghouse solution and send directly to their trading partners (as much as possible) and send ASC X12N transactions. In this scenario it appears that the responsibility of establishing connectivity, chain of trust agreements and all other activities, fall onto the Provider. For those payors that require the use of a VAN or Clearinghouse as a connectivity point, the provider must establish a chain of trust agreement with the clearinghouse (hopefully the payer covers transaction costs). I would then assume that the Providers trading tables would contain the appropriate ISA-sender/receiver criteria based on the agreed chain of trust and registration information. So, if the chain of trust process as defined by HIPAA is enforced, what business problem are we trying to solve with regards to ISA routing? If a chain of trust is not established with either the Payer or their designated VAN/CH, can the provider legally send data to them? Once the chain of trust is established and we are registered as a submitter, won't we know the ISA Sending/Receiving data requirements? Should the Sender be able to dictate their preference for a sender ID and the Receiver dictate the value for their ID based on the codes sets? (Chain of Trust can define this, but what is best practice?) Or must the receiver accept the ID sent by the submitter if it meets the code sets defined and has a valid value? Possible business administration problems - How do we know who to contact within the Trading Partners to establish the chain of trust and establish ISA Sender/Receiver values? Ronald Bowron
