RE: Whose name is it, anyway?

[Ronald Bowron]

With the number of Healthcare Delivery Networks, Physician Practices and Commercial, State, Fed insurance programs, TPA's and a traveling population, it can easily get out of hand.  So I'm not sure the point-to-point model works for healthcare.   If part of the problem is the ability to determine WHERE the document must go.  I know the Banking industry faced this obstacle with checks.  So they've created a standard routing code that is imprinted on every check.  Using this as a model, where does the routing identification process begin in retail - when patron presents the check to the cashier.  The business has the choice of investing in a check verification system or simply waiting for the bank to deny/accept the check. (Does the banking industry have a master repository for their routing/sorting systems? Have they established a National Banking ID system?)   Therefore, is it reasonable to consider defining a standard routing information format to be imprinted on every Insurance ID card?  (Most insurance cards contain human readable information - Group, PayerID, etc., but it is typically located in all different places on the card.)   Scheduling or admissions is most likely WHERE the information gathering process first begins - patient enters hospital - (hopefully presents card).  Or is Insurance Card Routing Number information standards out of scope for the routing efforts, or WEDI/SNIP as a whole?   Ronald Bowron     >>> "Dick Brooks" <[EMAIL PROTECTED]> 01/23/02 09:03AM >>> I believe Chris has provided a reasonable "framing" of the core problem. This problem exists, and has been addressed, by other industries, using different approaches. In order to conduct electronic exchange of data a party must: 1. Acquire Routing, Identification and, potentially, other information of the party they wish to exchange data with. 2. Choose an interoperable mechanism to exchange data Regarding the first requirement: In the Energy industry, for example, two parties wishing to exchange data electronically must exchange three key pieces of information: - DUN's Number (Identification) - URL of the system to receive incoming data (Routing) - Public keys for encryption/digital signature processing (CAIN/PAIN) The URL may belong to a third party clearinghouse or it may be a system owned and operated by the trading partner. The sender of a message may not be aware who the URL belongs to. All they "need to know" is "send data for this DUN's Number to this URL". The DUN's Number, URL and keys are provided by the parties when they establish their trading relationship. Note: Within the Energy industry model all business data is exchanged using a "push-push" model. Mailboxing facilities (like VAN's offer) may be offered by third parties (e.g. clearinghouses). A system MUST be available 24x7 to receive electronic transactions at the URL listed, in order for this model to function. Another model that seems to be gaining momentum is the central repository approach (e.g. UDDI or ebXML Registry and Repository). With this model parties "publish" their identification and routing information in a searchable repository. Anyone that wishes to can search/retrieve identification, routing and other information from the repository. For example, imagine that Yahoo contained DUN's Number, E-Commerce URL and Public key for the companies in their database. Anyone with access to Yahoo could retrieve this information and setup a relationship to exchange data electronically. For the second requirement it's a matter of choosing a "standard mechanism". There are lots of options available, for example: ebXML's Message Service, EDIINT AS2, GISB EDM, AIAG E-5, EDIINT AS1, generic e-mail, standard FTP, Secure FTP, proprietary solutions such as MQSeries, SOAP and the list goes on. It is simply a matter of choosing "the" solution that fits the needs of HIPAA/Healthcare. If you would like to read about the Energy Industry's experience in this regard take a look at: http://b2b.ebizq.net/std/brooks_1.html With regard to Requirement 1, I believe either approach may provide a good starting point for the healthcare industry. The approach used by the Energy industry works well if the Trading Community is a manageable size and the entities know each other, e.g. less than 500 trading relationships per entity. The "central repository" approach works well if the Trading Community is large or the parties don't know who they wish to conduct business with electronically. With regard to requirement two, "pick your poison!".... 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: Christopher J. Feahr, OD [ mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 22, 2002 8:16 PM To: [EMAIL PROTECTED] Subject: Re: Whose name is it, anyway? OK,here's one more stab at framing "the core problem": The sender (of any interchange-type message) needs to know WHERE/HOW to send the message... from HERE... i.e., the "physical address of the next hop/destination on the way to Receiver X" and the correct "outer" addressing requirements... i.e."outside" of the ISA sender/receiver info coded inside the message. In the parcel shipping analogy below, this would be the identification of the correct "drop box". While there certainly can be ambiguity about the ID of the ultimate receiver, that would seem to be outside the scope of this WG and is probably well (enough) addressed with the assortment of identifiers offered in the IG. The problem seems analogous to someone having a line of drop-boxes out in front of his office for shipping parcels: one for FedEx, one for UPS, one for Airborne, etc. , and needing to know which one to use in each shipping scenario. Having an authorization from the carrier (the drop-box owner) to use a particular box and knowing the usernames and passwords for these drop-boxes would seem to be be outside of our scope. Once we have all the parameters for defining these entry points, then each receiver would have to publish (somehow) all the possible "drop-boxes" into which a HIPAA transaction intended for it could be placed by a sender... maybe with one flagged as "preferred". If it receives traffic via large "common carrier" type VANs or CHs, then the sender would also need a list of possible entry points or "drop box" definitions for each of the "common carriers" that feed his target receiver. Each standard drop-box definition would have to include the transport mechanism (FTP, secure email, Z-modem, etc.), therefore implying all the other requirements the sender would have to meet to get the thing into the stream. Is this sounding "right" so far?? -Chris At 02:28 PM 1/22/02 -0500, you wrote: >I would like to reiterate - these ID are sometimes (frequently) an integral >part of the security of an EDI system. For instance, that proprietary ID >assigned by the payer to the submitter (provider/billing service or >clearinghouse) may be the ID of an ID/password pair used in securing access >to mailboxes, etc (sorry - no plug intended). > >In our case, we use that ID/password to regulate access, and then correlate >the ID against the providers within the transactions, to validate that the >source of the transaction is authorized as an agent of the provider. A >similar process is used on the response side. > >Bob Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268