OASIS ebXML Messaging Services TC

 View Only

[ebxml-msg] The PartyID Conundrum

  • 1.  [ebxml-msg] The PartyID Conundrum

    Posted 11-01-2001 01:14
    If by PartyID, we mean those unique IDs like D-U-N-S, EAN GLN, SCAC, ABA Routing code, etc., then there's certainly the possibility one or more of these (even in the same domain, e.g., two or more DUNS numbers) can be equated to one enterprise. None of these IDs is ever equated to multiple enterprises, though; if they could, it would defeat the purpose of an ID, wouldn't it? Maybe we've been hung up on this because <PartyId> as used in Messaging Services should have been called something like <EnterpriseId> or <OrganizationId>. The term Party is overloaded within ebXML. It's use in Core Components implies a functional area or person within an organization (e.g., Buyer, Accounting, Ship To ). It's nice that - for completeness - a low-level (and oft-changing) URL can be used for routing within Messaging Services, but I think trading partners would likely want to use the business (or Organization or Enterprise ) identifiers they're already familiar with. And they do that with a VAN today: they slap the DUNS into the X12 ISA or UN/EDIFACT UNB receiver field, and it's on its way, (somewhat) safely, securely and reliably - with nary a concern for the port the data will be shunted to. Internally, the recipient may use the functional group ID (from the GS) - or another internal routing designation - to ferry the data onward, but that's not the concern of the sender (or the VAN). I must not be alone in thinking businesses want to simply address their electronic data with a single organization identifier (which may be one of many IBM DUNS!). See the attached posting made to the WEDi Transactions listserve today, where a similar issue is being discussed in the context of HIPAA '96. Only the front part of the e-mail is important; participants in the WEDi SNIP forums have a tendency - like those in the OASIS ebXML forums - to carry along weeks' worth of a thread in the body of their postings! William J. Kammerer Novannet, LLC. From : Koller, Greg <gkoller@uwsi.com> To : 'PETERBARRY@aol.com' <PETERBARRY@aol.com>, transactions@wedi.org,business@wedi.org Date : Wed, 31 Oct 2001 07:55:53 -0600 Peter, This is some good information. I struggle with how data can be put into an 835 from a paper form with so much data missing, but I will keep an open mind. My big question relates to the topic of Provider EDI numbers. I agree, it would be great to have that standardized set. With regards to payers, however, that system is pretty much in place and one of the big advantages of EDI is being able to utilize a single EDI number rather than trying to figure out correct addresses for larger payers (BC of Wisconsin has one EDI number compared to at least a dozen physical mailing addresses). With the 837 requirement of Physical Payer address, this seems to be taking a step backward. Any thoughts on how this should be handled? Are there requirements that the physical address be accurate or can you use a single dummy address? >From a systems perspective, this will increase the size and complexity of a payer file exponentially.