Here are a few musings, to see if we can agree to these three concepts before we take the discussions much further. Time for fresh popcorn.
We need to distinguish between the concepts of identity, address, and route. Most of you already know the differences, but let me try to put this in writing so we can use it later. The identity is a permanent characteristic of an entity or a person. It is defined either by a third party with authority to define identities for a specific domain, or by the person itself. For example, D&B issues the D-U-N-S number, the IRS issues the TIN/EIN, the NAIC issues the co-codes, the DHHS will issue the PlanID and NPI, my parents gave me and my siblings a name, and I can take on a different name later. But, in general, it is very stable and of a permanent nature. And supossedly unique. At least unique within the domain of the "issuer". This "uniqueness" property is some times very hard to achieve, as there could be many people named John Doe. So, to achieve the uniqueness we may need to qualify the identity and/or create a "composite" like name + DOB + SSN. Since it is possible for a DUNS, SSN, and an EIN to have exactly the same digits, they use different placement of the hyphens as a "hint" of the type of number. The DUNS looks like aa-bbb-cccc, the SSN like aaa-bb-cccc and the EIN like aa-bbbbbbb. This is OK for humans, but for EDI we use an ID "qualifier". For the purpose here I will use something like SSN:123456789 or DUNS:123456789 to keep them apart. And for names I will say NAME:Kepa_Zubeldia. By now you are starting to see that I can have several different identities. In fact, most entities will have several identities, some of which may not be strictly unique (e.g. name) like: - NAME:Claredi - EIN:123456789 - DUNS:123456789 Interestingly enough, an Academic Medical Center (AMC) with multiple departments could very well operate under a single EIN/TIN and distinguish the departments with a "SubID" created by the AMC itself, like EIN:123456789-1234 creating a sort of "composite". And each one of those departments would have a different "name". We must look at the "composite" of EIN and SubID as another form of EIN with 13 digits. Even though this EIN was not assigned by the IRS, it is common to use this sort of ID in healthcare. So, in reality, even though they are sharing the IRS-assigned EIN, they are not sharing the "IRS based" identity made out of the EIN and SubID composite. A problem is that we don't have an X12 qualifier for this EIN+SubID sort of situation. So, having multiple identities, I can choose to use whichever one is appropriate, in my judgement, to each case. For example, a healthcare payer may choose to use the NAIC Co-code in one situation and an EIN in another situation. How do I know that these two identities actually represent the same "entity"? I don't! Can you see the potential difficulty to conclusively identify all the potential identities of each "entity"? It would be OK if the "entity" would voluntarily list all of its identities somewhere, in some sort of directory or web page. But, since this is not likely to happen accross the board, HIPAA comes to the rescue by issuing a Health Plan ID or a National Provider ID (NPI) to be used as the unique healthcare identity for those entities. But we don't have the PlanID or NPI yet... Even then, once HHS has issued the NPI and PlanID, there are billing services that serve multiple providers; Payers and TPAs that administer multiple health plans; PBMs and clearinghouses that process transactions for multiple payers (or TPAs or providers or other clearinghouses). So there are multiple health care players, outside of the NPI/PlanID system that would benefit from a unique health care "identity". In the mean time they will use whichever one of their current identities that they feel more convenient or appropriate. Enough about identity. Let's talk about addresses for a while. An address is a location where I choose to receive certain correspondence. It could be paper mail, or electronic mail, or EDI transactions. The address is expressed in a form usable by both my correspondents and by the transport mechanism. In general, one identity has one or more addresses. It is also possible for multiple identities to reside at the same address. Clearly there is not a one to one mapping between addresses and identities. Let me use a simple mail example to illustrate this. An entity, such as Claredi, can receive snail mail at each one of our offices. And each office can have a street address and a PO Box. I may choose to give some of these out, whereas other addresses are kept more private. For example, we want all of our customer payments to go directly to our southern California accounting office, specifically to the PO Box in Montclair, CA. But we want to receive all of our general correspondence in our Utah address. And each one of these addresses has multiple identities, as you can send a letter to Larry or to Kepa or to Skip, all of which are different "entities" located at the same address. This is even more obvious for a TPA that administers multiple health plans out of the same office, or for a repricer PPO that reprices for multiple health plans. When I publish my address I need to give some flexibility to my correspondent. For example, if I was to only publish the PO Box of our accounting office in Montclair and not publish the street address, my correspondents would be forced to use the USPS and could not use FedEx, for example, as FedEx cannot deliver to a PO Box. Ultimately I publish several addresses that get to me. I can publish instructions that say: for claims use this address, for payments use that address, for general inquiries use another address. And I can publish alternative addresses for the same purpose, in order to accomodate my correspondents. And, regardless of my explicit instructions, should also provide a mechanism to re-route mail sent to the wrong address, if possible transparent to my correspondent. And a big waste basket for all the unsolicited junk. Also, for workflow or other reasons, I will have an "unpublished" mechanism to route the documents between our offices. This is similar to a health plan that designates a specific PPO repricer as the ecommon entry point for all claims. Then the repriced claims are sent by the PPO to the health plan to an "unlisted" address. Of course, if the health plans happens to get claims that have not yet been repriced because the providers sent them directly to the health plan, the health plan needs to have an internal mechanism to send those to the PPO for repricing, or needs to reject them back to the provider as being sent to the "wrong" address. For the addresses to work, the trick is in a couple of areas: completeness of the address for the intended routing mechanism, and mapping between the identity and the address. Complete addresses are important. While [EMAIL PROTECTED] is a complete address for electronic mail, for paper mail you should use something more descriptive, like Kepa Zubeldia, Claredi, 371 Sanders Lane, Kaysville, UT 84037. This is a little bit of overkill, as you could say that my name does not need to be in the envelope. By saying Claredi in the envelope, the envelope would get to the proper mail room and from there, after opening the envelope, they could send the correspondence to me. But this would preclude confidential correspondence. In any case, it is the sender's choice to either send the letter to a general delivery address for the company, or send it to an individual. We also note here the ability of the system to handle incomplete addresses or to correct errors. The USPS, in general, does a good job at this. They can route letters without ZIP codes, although it takes longer. And, if you have a distinguished name, they can route correspondence with minimal address components. For example: IRS Service Center, Ogden, UT, will get your tax return to the right place. But the biggest problem is mapping an "identity" to an "address". We get this information from multiple places in the environment: Advertising, Yellow Pages, business cards, web sites, etc. There is not a single source for it. And, when we get the mapping between identity and address, it can easily be a "many to many" or at least "one to many" or "many to one" mapping. How fun :-) And, then, the mapping is not constant. Entities change their address periodically, or change their preference as to where they want their correspondence delivered. This is just a fact of daily life. Rollodex made a business from this fact. So, we need to map the identity into one or more addresses. Then we can choose which one of those addresses to use. Probably the safest bet is to ask the entity itself. I can call my correspondent on the phone (first entity to address mapping) to find out what the mailing address is (second mapping) for a FedEx package to the accounting office. Or I could look up a paper directory or a web server (first mapping) to decide which of their addresses posted there are good for my case (second mapping). This process is called "address discovery". The "reverse address discovery" would be a case where I have the address and I want to know what entity or entities are serviced by that address. In general this is rather difficult to do. Probably the most succesful example is the "Reverse DNS" used through the Internet to determine what is the registered host name for a specific IP address. But since host names can have "aliases" and a single IP address can serve multiple hosts, this process is still not totally conclusive. In terms of health care, if you have the address for a TPA, you don't necessarily know all the identities of the health plans served by that TPA. So, as long as we know that the mapping of identity into address is going to give us multiple addresses, that the addresses for an identity may change periodically, and that multiple identities can map to the same address, we are doing good. This does not make the problem easier to solve, but at least we will not expect a simple solution. And we will probably come up with something that even gets closer to providing "a" solution. Also, if you are trying to map from address to identity you know that your chances of success are slim. OK, so let's take a look at "routes" and how they are different from addresses. The route is the actual path taken by a message to get from one point to another. In general, the routes change frequently and are not under the control of the sender or the receiver. And, in general, the route is not important as long as the message gets to the receiver as expected. For example, the USPS may take a letter from Salt Lake city to Baltimore through Denver, but, if there is a big snow storm in Denver, it could go through Phoenix instead. This is transparent to the correspondents most of the time. But some times things go wrong. The postal facility that handles my mail could catch fire, or have a flood, in which case my particular piece of mail could be delayed, damaged, or destroyed. But, in most cases, the route is totally outside of the control of the sender or the receiver. The routing decisions are made at routing points along the way by whoever is transporting the message. And the "transporters" bundle messages and packages to make the process more efficient. Same as the clearinghouses bundle transactions. If my favorite newsletter is shipped by the USPS in the same crate as a package with an improperly packed liquid, and it leaks, my newsletter is going to get wet. Nothing I can do about it. OK, the newsletter could be shipped ina sealed plastic envelope... These routes take advantage of bulk volumes, and the analogy with health care clearinghouses is clear. If you don't see the analogy of the paper mail and clearinghouses, let me know. But, the bottom line, is that I don't have a lot of control over the route. In certain cases I have some choices that influence the route, but that is it. For example, if I send a letter via FedEx, I know it is going to go to Memphis, but that is all I know about the route. And certain addresses limit my routing choices. For example, if the address is to a PO Box, the only choice is to send the message via the USPS, as FedEx, UPS, or other couriers cannot deliver to a PO Box. In summary: The sender and receiver know each other by their respective identities. The receiver specifies what are the addresses at which it can receive messages, along with an indication of what type of message to send where, or a preference for certain addresses. The sender chooses which transport mechanism to use, and delivers the message to the entry point of the transport mechanism, giving it a delivery address that is adequate for that transport mechanism. The transporter chooses the route most appropriate to deliver that message. In some cases the transporter will provide a "trace" or "status" mechanism that describes where in time and space to locate the message in its way to the delivery. In some cases there is a mechanism to "probe" the validity of a delivery address in conjunction with a transporter. FedEx will reject up front a package addressed to a PO Box, without having to take it through the system. The post office will tell me that an address is incomplete and cannot be routed without having to take it all the way to the destination. And, in some cases the sender can explore the different choices. I can go to the post office with a letter and they will say: You can send it First Class for $.34, or Priority Mail for $3.50, or Express Mail for $12, and they give me some sense of how long it is going to take with each route. Then it is my choice of service level. The Internet Email also has a mechanism to explore deliverability. All SMTP servers respond to a probe asking whether a specific address is deliverable or not, even before the delivery of mail to the server is attempted. I am sure you have seen the resulting bounced messages. I hope this email clarifies the concept of identity, address, and route, so we can all be in sync on these terms before the meeting. Please feel free to add to it. Kepa
