Dave: I'm not sure we really need exotic business models at all. Our project scope is limited to devising recommendations which effect the identification and routing (safely, securely and reliably, I might add) of complete X12 interchanges. Whether claims, eligibility requests, claim attachments, status requests or responses, or remittances are included in those interchanges is probably of little matter to us: we're only concerned with routing standard transactions hither and yon.
And the parties are (or should be) symmetric: everyone will have the same capabilities to define EDI addresses, supported transactions, etc., etc. It should matter little whether the CPP belongs to a payer, a TPA, a billing service, a re-pricer, a clearinghouse, a hospital or even a doctor. And it shouldn't make any difference if a payer wants to send a 269 to another payer, or a provider wants to make a claim: the rules for navigating and interpreting the CPP Electronic Partner Profile will be the same. The only difference between individual CPPs is that a large payer or CH would probably exercise more of the features available to everyone: multiple DeliveryChannels (with finer breakdown of transaction sets per DeliveryChannel - e.g., to support real-time vs. batch), more supported transactions, and so on. We do have to examine a number of business use cases simply to devise capabilities. For example, maybe a payer has a number of plans, some of which need to have claims against them go to a re-pricer before being forwarded on to the payer. Since plans handled by the same payer have to be treated differently, it stands to reason that the creator of the CPP (generally the payer) has to have some means of distinguishing between plans for some functional groups. Perhaps claims (set apart by their functional group IDs) for a set of plans are directed to the DeliveryChannel (or "EDI Address") describing a portal at the re-pricer. The provider submitting a claim for one of those plans would be none the wiser (unless he reviewed the copious free-form comments the payer included in the CPP XML document!) that his 837 was being shunted off to the payer's business associate, the re-pricer - directly (using an explicit definition of the re-pricer's portal) or indirectly (by referring to the re-pricer's CPP). I'm not pretending to know any of this stuff - everything I know about what goes where, and who does what, came mostly from some of your long e-mails! Before you wrote in, I had no idea that a "re-pricer" or "reviewer" even existed! Which is why I have to double check and make sure I got your valuable postings in the right places within the Overview "brain" dump before we go over this stuff in the teleconference on Friday. You also have shared with us some definitions of various parties in the past (e.g., 02-26 in RE: Requirements Gathering - Information Flows), but I don't want them in the overview document. Instead, I want to make sure they're elevated to - or used to augment already existing definitions in - the HIPAA Glossary, as Bruce Horn has urged. I'm pretty confident that we can devise any kind of "doo-hickeys" for describing how routing of interchanges is to be accomplished within a particular CPP, as long as the deviser of the CPP knows ahead of time the criteria for decision-making. For example, the payer knows ahead of time where his portals are, what plans he has, and things like that, so decisions based on these "static" criteria should be able to be described in the CPP. On the other hand, it's going to be a little tougher to make decisions based on who's looking at the CPP, or on details impossible to enumerate; for example, how would a Blue in their CPP describe that claims for an out-of-area patient are to go to another Blue altogether? William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 ----- Original Message ----- From: "Dave Minch" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, 20 June, 2002 04:39 PM Subject: RE: HIPAA Privacy, Security and the Intersection with EDI Kim & all, The model i've been working with allows for the trading partner (whether payer, provider, CH, or any other third party) to list themselves under multiple identifiers, as Chris explained in an earlier communication. The listings will all point to the CPP, wherever it lives (whether in some public repository, or more likely in the trading partner's home site). The CPP will provide several options for transaction transmission based on combinations of factors such as batch vs real-time, test vs live, transaction type, and possibly even transmission mode (push vs pull). The CPP design needs to be open enough to accommodate creation of a trade agreement between any 2 parties, considering even payer-to-payer types of trade agreements for exchange of COB claims, and must accommodate all potential transmission modes. The CPP will also state what specific identifiers are to be used in various loops and segments for each transaction type, including the ISA and GS. In response to Rachel, I agree that the business model is needed, and i've tried to make some stabs at it from the provider's perspective, a couple of which i've posted to the listserve a while back. Unfortunately I haven't received much review response, so I'm not sure I'm headed in the right direction with the analyses, and haven't taken them any further. I haven't seen any equivalent efforts from someone from the CH or payer industries either, and certainly don't feel qualified myself to attempt them. Since most people seem to agree that the business model is needed first, shouldn't we try to coerce some equivalent effort from other perspectives so we can get the business model shaped up? Dave Minch T&CS Project Manager John Muir / Mt. Diablo Health System Walnut Creek, CA (925) 941-2240 discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.
