• Abstract and Figures
• Public Full-text

Overview

Organization The SNIP ID & EDI Address project is cooperating with another project called the AFEHCT-WEDI Health Care Communications Security and Interoperability project.

The Problem This document would include background on the existing Healthcare EDI environment (where we are), the ideal (where we want to go), Identifiers as they relate to routing of transactions, a high-level description of an Electronic Partner Profile, a high-level description of the Healthcare Registry, along with some examples of how all this would look in practice. So I think what the team is trying to do is define a neutral, efficient technology that can serve both now and in the future, and that will be a significant achievement. Judging from our conversations over the last few months, it seems folks have a "problem" finding out how to exchange EDI transactions with their partners without burdensome and manual processes. If that's not a problem - i.e., either the processes are not that manual or burdensome, or just not worth fixing considering the exigencies of other HIPAA issues - then there's no need to devise requirements for a solution to an imaginary problem. And if there's no problem to solve, then there's certainly no need to deliver a solution "within any acceptable timeframe."

Either manual EDI enrollment processes are a problem, or they aren't. If they are, I believe that an open standard based on a Registry of electronic partner profiles is an effective technical solution worth pursuing by the WEDI/SNIP ID & Routing SIG.

This effort is/should be substantially above the business data level and be dealing with message addressing and various transport methods that may be supported/required by a trading partner.

Furthermore, the scope of this effort should not be limited to the HIPAA transactions, but serve all of health care.

Motivation (1) How would a provider know where to even send a standard transaction to whatever entity handles them on behalf of the plan or payer? (2) A payer might have multiple "portals" for different types of transactions (say, "real-time" vs. batch) - how does he convey that to any provider who might want to send standard transactions? (3) How does a payer know whether a provider even supports EDI in the first place? (4) Assuming a provider *does* EDI, how would a payer know that a particular provider supports particular transactions (e.g, an 835 EOB - there's nothing in the 837 which says 835s are expected in return). Where would the payer send the transactions? (5) How would a payer or provider tell trading partners the communication protocols he supports? If he's using some of dial-up system, how does he convey logon IDs and passwords? Where does his X.509 digital ID public key reside? (6) How does a payer say what his requirements are for ISA and GS fields? How can he tell the provider that he can't handle more than 5000 claims in an individual 837? (7) How does someone report errors beyond the standard TA1 and 997? Does he support the 824? Or e-mail? - if so, what e-mail address should be used for sending error messages?

You can add "or his agent" (such as a Clearinghouse, repricer or Third Party Administrator) to "provider" or "payer" above. This list certainly isn't exhaustive - I'm not the keenest when it comes to keeping crap organized, and Microsoft Project would only confuse me.

Any of these problems can be solved the old fashioned way: through telephone calls, e-mail and paper TPAs. They can sometimes be delegated to one's Clearinghouse. On the other hand, if we agree that paper TPAs, paper "Companion" documents and lots of e-mail and phone tag are undesirable, we might ask if any or all of these problems can be solved in an automated fashion. Or - along the road to complete automation of EDI enrollment - can this information be advertised somehow where partners know where to look? Can it be expressed in a mechanical fashion for consistency and rudimentary automation?

Do you agree that these are problems at least some payers and providers would like to see resolved? If any of these struck a chord, then our proposed solution - which entails recommendations based on the open ebXML CPP (electronic Partner Profile) and Registry specifications - seems to satisfy many of the requirements posed by the problems. Do you have alternative solutions? Are these problems so critical to solve that a solution has to be in place by April 2003?

Standard Transactions

HIPAA mandates the NCPDP Retail Pharmacy electronic transactions between pharmacists and payers for eligibility, claims and remittance advices.

Some of the hesitance to venture into NCPDP may simply be due to ignorance on our part, considering most of us are X12 types! Maybe there's no problem at all integrating NCPDP's needs - on a first-class basis - within our Healthcare CPP Registry.

Thanks for clarifying what you mean by "all of health care." We now know you certainly did not mean NCPDP, HL7 or Healthcare supply-chain. If I hear you correctly, I think you're saying we should accommodate the non-HIPAA (or yet to be HIPAA) X12N administrative transactions (like the 277/275 claims attachment and the 269 "COB"), in addition to the "final" HIPAA X12 transactions, in the recommendations we will develop for solving whatever problem we haven't determined yet. I would fully and enthusiastically concur.

For example, even though the NCPDP retail pharmacy transaction is a HIPAA standard transaction, we haven't discussed it much. Can somebody enlighten us on how it is currently used? Are Clearinghouses involved? Can a pharmacy be treated like any other provider? How are NCPDP transactions packaged and identified?

Information Flow Multiple 837s could result in a single 835, couldn't they? Claims could be sent throughout the day to the payer, with the payer waiting to process them in one run, resulting in a single 835 which the provider has to reconcile with any number of claims (sent in any number of 837s).

The 837 ceases to exist by the time it gets to adjudication: it has decomposed into any number of atomic claims. There's nothing to say an 835 reflects only claims from one 837 - and there's really no reason for the payer to retain any notion that a particular claim came from any particular 837. And this is in the direct point-to-point scenario between provider and payer, with no intervening Clearinghouse which may be munging claims together from multiple providers for the payer! Bob Poiesz has emphatically taught us that the 837 is nothing but an ephemeral package encapsulating any particular claim - only until the next moment when it is possibly captured in another 837's orbit.

But fortunately, I don't think we have to peer at the atomic level for solving our routing problems. We're only concerned with the physics of moving intact X12 transactions. The interaction P-->A-->P should really be decomposed into two separate (and possibly unrelated) sequences:

Provider ->(837) Payer Payer ->(835) Provider

We can't afford to ignore the technical acknowledgements in our information flows involving the 997 and the TA1 (and maybe even the 824). In the simplest cases where individual 837s are packaged in a single interchange, diagramming the interaction might be simple:

Provider ->(837) Payer ->(997) Provider

But what about when multiple transactions (and multiple transaction types - i.e., a mixture of 837s and 270s) are packaged in a single interchange? I don't think that really complicates things, in that all we really wanted to demonstrate is that the 997s (plural) go back to whoever sent the original interchange. You are correct when discussing an "837" as opposed to an atomic claim. My "flows" analysis was meant to show the routes that an atomic claim/payment or eligibility request/response traverse in our health system today, whether electronic or paper or phone. In fact, even when on paper, we tend to print / accumulate paper claims for a specific payer in a sequence that allows stuffing them into a single envelop when mailing (roughly equivalent to an 837). When the envelop reaches the payer, they open it and the "integrity" of that 837 grouping is lost the moment that the individual paper claims flow into their intake process (e.g. they are scanned into their electronic applications).

The 997 / TA1 is a concept that has no equivalence in the paper world, but does in the telephone inquiry - it is the acknowledgement that our admission & A/R follow-up people manually record when they call a payer to check on eligibility & claim receipt.

What you bring to light is the difference between what I am describing as the atomic "flows", wherein a certain event such as a claim would be expected to elicit a payment (or at least an RA) response, and the communication of that event between trading partners. As you correctly point out, an 837 (which I would look at as a package of 1 or more atomic claims), could elicit any number of responses: a 997, several 835s, 277s, and even 278s to TPAs and 837s to COB payers. These "response" events are temporally disconnected and unrelated to the original 837. What they each do have, however, is a specific relationship back to the atomic events that were gathered in the original 837 package.

Getting back to the "business requirement" here, I need to determine (using a definition here for "transaction" as the single atomic event that needs communication):

1) the final destination for each transaction to be sent; then, 2) based on that final destination (through some mechanism that will be engineered from the business requirements) discover the entry point address for each transaction to be sent; then 3) group the transactions by entry point address; then 4) create the electronic packages by entry point address; then 5) send the packages using methods described in my trading partner profile for each entry point address.

For the packages sent, I would expect to get (depending on the trading partner profile) a 997 for each package sent (regardless of destination).

From that point on, each atomic transaction sent out is monitored individually, without regard to the "package" it was sent in. In fact, we should not care at all how the transactions are repackaged and re-routed by the intervening parties as long as each transaction arrives expeditiously (I'd like to define that term at some point...) at the final destination.

When we receive a package of transactions from wherever, a 997 would be sent as an acknowledgement of receipt. Again, other than our sending of a 997 to the sender of the package, we would assume that the contents of the package have no particular relationship to each other. The package would then be parsed into its atomic transactions, each transaction attached to its initiating event, and each would finally be distributed to the originating application for automatic processing.

The 270/271 and the 276/277 allow for multiple Information Sources and Information Receivers. There is no concept here of routing an ISA from Provider (or direct agent) to Payer (or direct agent). One interchange (or transaction) can be for multiple final receivers and from multiple original submitters. There is NOT a guaranteed one to one relationship beyond the point to point of any specific leg of the ultimate path.

Transport HIPAA is silent when it comes to just how standard transactions are to be sent. So EDI could be sent via dial-up BBS, e-mail, bi-synch 3780, FTP, X.25, EDIINT, or whatever. But, generally, if you want to send direct to the payer (point-to-point), the payer dictates the protocol. Because of the multitude of various protocols, and the difficulty of finding the EDI "addresses" of trading partners, most providers will probably choose to use a Clearinghouse. It's unrealistic to restrict transport methods to the common TCP/IP protocols. We need to support all the "legacy" dial-up connection types - to assuage fears of the open Internet's security "problems" or to simply support the PM systems out there already - with some means of describing scripts, logins, passwords, modem-settings, etc. etc. in our Electronic Trading Partner Agreement.

Of course, I want to emphasize again that we are only concerned with the packaging, routing and securing of STANDARD (HIPAA X12 and NCPDP) transactions between any two entities. We are not looking at situations where practice management software is generating or receiving proprietary formats through a CH; proprietary links (those not using standard transactions) to a CH or business associate are out of scope. We are, after all, the Workgroup for "Electronic Data Interchange."

I'll ask again what I asked on the 11th: "...does anyone know of any OASIS, W3C, IETF, etc. effort for devising XML files to describe all communication capabilities of a partner? .... I want to see something that says 'this is a dial-up using Kermit with this phone number.' Surely someone has devised a schema for describing communication capabilities. There's no sense in us reinventing the wheel."

As an aside, Dick Brooks has in the past brought up the need to assign a username/password to each trading partner before granting access to a B2B server - how is this to be automated, and what effect does this have on the use of electronic Trading Partner Agreements? Maybe userids and passwords could be avoided altogether if B2B servers were somehow to employ digital certificates instead for granting access - e.g., they could grant access to legitimate providers who hold one of those AMA/Verisign issued digital certificates.

Otherwise, if someone wants to ensure ahead of time who will be sending transactions before assigning a userid and password, then there seems to be no way around some kind of manual interaction - whether it is a paper TPA or a web registration. At least an Electronic Trading Partner Agreement could give the URL where a provider is to manually register, so the userID and password can be e-mailed.

1.) How many of you are planning to use a VAN? 2.) How many will just set up an ftp server on your network and let trading partners drop off their files and pick up their files from a trading partner specific outbox? For the latter, you can put into the identifiers whatever you want. This is my intent for a payer solution that I am writing. It's cheap, (free, the ftp server comes with Windows/linux/Unix). Privacy is an issue that I could overcome with encryption but I don't want to touch this issue right now, maybe in two weeks. 3.) Are there other routing and EDI transport mechanisms out there that I forgot? Maybe email attachments? Those would be easy to encrypt at least.

Work Product Technically, this group is a WEDi/SNIP Business Issues SIG (Special Interest Group) for the purpose of developing a white paper to address the standard transaction routing problem. When I say we're going to develop a "White Paper," I'm just parroting what the BI leadership says we're to do. I would imagine they (BI) want a White Paper which describes the perceived problems, if any, with regard to identification and routing, and some suggestions for solving these problem(s).

This project will publish implementation guidelines for (1) an Electronic Trading Partner Agreement (e-TPA) specification to mechanically configure communication and translation software, and (2) automatic "discovery" mechanisms for locating Trading Partners' e-TPAs on the Internet based on their business identifiers.

Our near-term plan is to generate four "working" papers. These papers will eventually be combined into a "white" paper or recommendation containing implementable specifications for the Healthcare CPP electronic partner profile and Registry. The four working papers cover:

(1) Identifiers (2) Addresses and delivery channels (3) Elements of the Healthcare Collaboration-Protocol Profile (CPP) (4) "Discovery" of Healthcare CPPs (i.e., the Registry) It's my opinion that the urgent problem to be addressed and solved **before April, 2003** is how to complement the current business model **using the X12 Interchange control envelope** for the submission of claims and without forcing the entire industry on its head...there are sufficient challenges with just adopting a new set of formatting rules and standard data. Coming up with a "down and dirty" (if necessary) solution that will enable the industry to become operational today should be the urgent priority of this group. Critical Success Factors dream of frictionless e-commerce "without the need for bilateral Trading Partner agreements" - hopefully, what we do here in WEDI/SNIP will resuscitate his hopes

Critical Success Factors: * Provide basic core functions initially -- Give marketplace participants what they need to solve their current problems * Recognize that IT alone won’t produce optimal pricing and efficiency in the market -- User acceptance more critical than implementation of IT * Infrastructure should complement existing trade value chain * Infrastructure should provide for end-to-end integration of business applications & information sharing in value chain -- Must be able to be integrated into back-office applications of participants * Effective ownership and control of infrastructure -- Participants must have a perceived or real vested interest in infrastructure, both business and technical * Accurate, objective identification -- Marketplace accepted standardized product identification is crucial (I believe this factor can equally be applied to HIPAA's challenge of identifiers, whether for product/service or entity. A major issue and challenge for all industries as they move into the electronic information exchange world is unambiguous and accepted identifiers: for all the players, delivery end points, billing and paying entities, and for the products and/or services moving through the value chain. For HIPAA, I believe the medical code sets are the analogy to product/service identifiers. We're still awaiting the national identifiers for payers and providers - but we do know what the key characteristics of these identifiers most likely will be and we can begin planning to accommodate them in our respective systems. There is no mystery as to what the identifier will be for employers.)

* Fulfillment of strong, genuine existing need in marketplace -- Don’t use electronic market system/infrastructure to replace existing market practice * Satisfaction of need overarching critical success factor

Perhaps these learnings from other efforts can help inform this group's efforts towards coming up with solutions to solve the immediate needs as well as looking to the future. If the solution is only to the future, I don't believe it will be accepted by the industry.

Thus, I would suggest that the priority focus should be on coming up with an immediate (and even perhaps interim) solution that will address the need for identifiers that can be used to enable the correct routing of HIPAA transactions to the intended and correct receiving system and which also are complementary to today's business model. It seems to me that a key characteristic of today's business model is that the industry (whether it's a clearinghouse or other intermediary, or the provider, or the payer) does not use an enveloping scheme that in any way parallels the X12 enveloping structures with their ability to logically identify the sender and receiver. As a result, other mechanisms have evolved to get the transaction to the intended final destination. Perhaps it would be worthwhile to more fully understand how it works today and how today's mechanisms can be exploited in the near/short term to enable the players to become operational with the HIPAA transactions in the very short time remaining to achieve compliance. Once the industry is operational, the evolution to more elegant approaches using new and emerging standards and specifications becomes more achievable. If the work product of this group can specify how to become operational by April, 2003, **and** provide a vision and path to the future, we'll have achieved a worthwhile goal. If we look only to the future, the industry will find a way to become operational without our help.

Thus, while I'm a very strong supporter of looking to the ebXML framework specifications which include the CPP/CPA, the Message Handling Specifications, distributed registries and repositories, and the ebXML architecture which ties it all together, I am not at all confident that all of this can be brought together in the extremely narrow timeframe required for the industry to become operational....which is not October, 2003, by the way -- but April of 2003 as required by ASCA.

Standards Modifications There are no changes we can make to the ISA - it's impractical that any requests (other than qualifier code changes) could move through the glacially slow X12 process in time for it to be useful to us.

We're probably safest in assuming we (WEDi/SNIP ID & Routing) are not going to be developing any recommendations requiring X12 DM requests nor other than the most minimal changes to the HIPAA implementation guides.

"...would the current ISA ID values be used to do a lookup in the DNS table by the VAN/CH to get the proper routing, or will the entire route be in the ISA?" Only the entity ID (NAIC, DUNS, etc.) would be in the ISA receiver field. We are advocating no changes to the existing ASC X12 standards. All proposals assume a lookup for the routing would be done based on that ID (and its qualifier).

I can't imagine changes would be needed (or possible, given the time needed for data maintenance to wend its way through the standards bureaucracy) to the X12N standards in order to support any recommendations that come out of this sub-working group.

"Are we attempting to introduce new standards based on a transport layer function (IP)?" New standards, or "recommendations," are a very real possibility: e.g., a recommendation for exchanging interconnect information, or Kepa's proposed DNS structure for obtaining routing information, etc., etc. These would augment the existing X12 standards and the HIPAA IGs - not replace any parts of them: we have to live with what's already in place.

EbXML Of the various specifications coming out of ebXML, the Collaboration Protocol Profile (CPP) and Registry are the most relevant to our work in WEDi/SNIP. As reported earlier, Dick Brooks will be working with the OASIS ebXML CPP/A Technical Committee to ensure the next version of the CPP spec supports Healthcare's needs - specifically "EDI Addresses" and links to electronic companion guides.

We also have to have a way to electronically "discover" a Trading Partner's CPP, and that implies a registry of some sort. Though we have paid a lot of attention to Kepa's DNS "directory" proposal, prudence dictates that we at least look at what ebXML has to offer. So I took the liberty of apprising the OASIS ebXML Registry TC of our interest in the ebXML Registry for "discovering" Healthcare trading partners' CPPs. See "Discovery of WEDi/SNIP CPPs," in the Registry listserve at http://lists.oasis-open.org/archives/regrep/200203/msg00038.html.

It's expected that "hanging" our electronic trading partner profiles onto the CPP would not be too terribly traumatic to existing healthcare players: after all, it would not be replacing anything but clumsy paper documents or web pages. Likewise, a directory (whether Kepa's DNS "directory" or the ebXML Registry) would give us something we never had before - an automated means of finding a partner's profile - and make what had been done manually now automatic, all without upsetting already in-place systems. What exists is the ebXML CPP/CPA (Collaboration Protocol Profile and the Collaboration Protocol Agreement. These specifications were developed over an 18-month period with active participation from the best minds in the world. The continued support and maintenance of these ebXML specifications is now under the auspices of OASIS. The OASIS committee will continue the work of ebXML on Collaboration Protocol Profiles (CPPs) and Collaboration Protocol Agreements (CPAs). Development of the ebXML specifications is an on-going effort sponsored by OASIS and UN/CEFACT. Technical committees for the ebXML Registry, Messaging, Collaborative Partner, and Implementation are hosted by OASIS, and Business Process and Core Component work continues at UN/CEFACT.

A CPP defines one business partner's technical capabilities to engage in electronic business collaborations with other partners by exchanging electronic messages. A CPA documents the technical agreement between two (or more) partners to engage in electronic business collaboration. The committee will develop enhancements to the existing version 1 specifications that will result in at least one substantive new version. It will also coordinate its work with appropriate standards bodies within and outside OASIS. In addition, the committee will maintain version 1.0 of the ebXML Collaboration-Protocol Profile and Agreement Specification and will issue minor updates as needed.

All of the ebXML specifications are publicly available in electronic form at no cost to interested parties.

Thus, one of your proposed "requirements" could be stated as follows:

"The EDI Addressing specification for health care must enable the automation of the trading partner setup process."

This requirement could then be satisifed by stating:

"The automation of the trading partner setup will be accomplished according to the specifications and rules set forth in the ebXML Collaboration Protocol Profile and the Collaboration Protocol Agreement specifications. These specifications are available from OASIS at http://www.oasis-open.org/committees/ebxml-cppa/."

Just to give everyone an idea of which companies are involved in the continued support and development of the ebXML CPP/CPA specifications, here's a current list of members of the OASIS Technical Committee. As you can see, many of the world's leading ISV's are actively involved in this work effort.

Liaisons NCPDP Lynne Gilbertson [email protected] NIST Lisa Carnahan OASIS ebXML Collaboration Protocol Profile and Agreement TC. The chair, Dale Moberg

Identifiers Actually, in the WEDi/SNIP ID & Routing group, we're merely concerned with the manner in which entities are identified in the ISA interchange header (and perhaps the GS) segment for routing. As Rachel said yesterday, "the focus [of our group is] on the 'functional use' of the identifier in the ISA as the key to discovering the detailed EDI addressing information." Sometimes we do talk about the problems with the lack of standard identifiers (especially for providers) in the application transaction sets, but it's not in our charter to solve that big, hairy problem!

Background RosettaNet and other initiatives have chosen to identify every partner using the same ID domain, such as D-U-N-S. This does make things slightly simpler, in that no one has to remember what kind of identifier this 9 digit number is - it's always a D-U-N-S!

I don't really think it's necessary, though, to force all players to identify themselves using IDs from the same domain. Christopher J. Feahr, OD, may prefer to always identify himself with his Federal Tax ID - it's incumbent then for all his partners (payers and lens manufacturers) to address him with his TIN in the ISA. But, another provider, like Children's Hospital, may choose to use its HIN (Health Industry Number) for procurement transactions, but the D-U-N-S when exchanging administrative HIPAA standard transactions with payers. On the other hand, insurance companies might choose to be identified with their NAIC company codes.

Most entities have at least one ID from multiple domains - e.g., Christopher J. Feahr, OD most certainly has both a D-U-N-S and a TIN. Aetna has not only a D-U-N-S and a TIN, but also a NAIC company code. Some outfits even have more than one ID from the same domain - it's easy to have multiple D-U-N-S numbers due to mergers or acquisitions. Even though the Federal Tax ID number doesn't have the same weaknesses as the Socialist Security number used for individuals - it's almost never used for authentication, but only for identification - some entities still may prefer not to use it to identify themselves, leaving them to favor, say, the D-U-N-S.

Since an exchange of HIPAA standard transactions is initiated by the provider, it's easy enough for the provider to obtain the payer's EDI ID; for example, the NAIC company code of the payer could appear directly on the patient's insurance card as the "electronic" EDI address for inquiries and claims. From there, it's clear sailing to locate the payer's CPP based on the NAIC.

But as I ruminated on Tuesday, in "More Stuff and Questions on Routing Identifiers," how would the payer know how to address the provider it's responding to? There doesn't seem to be any clear way in the 837 or 270 for the provider to tell the payer which ID and domain to use for addressing transactions back to him. Always using the TIN for ISA IDs might solve this problem, but forcing an inflexible naming system on all partners ("You must always use the TIN") might be less desirable than figuring out some way for the 837 or 270 to communicate the preferred EDI ID (and domain) for responses.

I'll make one concession, though: mandating use of a single domain (e.g., the TIN or D-U-N-S) to identify all parties (e.g., providers, payers, repricers, TPAs, CHs) on the ISA would be far preferable to the situation we have today with a surfeit of payer-assigned provider IDs.

Aside from that, obtaining a DUNS for your own organization is free: I didn't pay anything to get assigned a DUNS from D & B, and as I explained to Chris Feahr this morning, he can get his DUNS for free by following the procedure I outlined. I think you have to pay $.75 or some other nominal charge to get the DUNS numbers of other organizations (though I, too, have gotten those free when I said the numbers were for "research" - I never pay retail).

In any event, you would rarely have to ask Dun & Bradstreet for the DUNS of your trading partner; more often is the case your trading partner would give you his DUNS, telling you that's how he is addressed in the ISA. Everyone knows his own DUNS or Federal Tax ID (by the way, the Federal Tax ID is the same thing as the Federal Employer Identification Number - EIN or FEIN) - which is "shorthand" for saying someone at his own organization (say, the CFO) certainly knows these IDs.

Once you have a DUNS, enumerating the DUNS+4 is free The National Provider ID (NPI) registrar will certainly not be assigning IDs to providers based on "contract" number, so it's clear that payers will already have to be working on separating the notion of contract from that of provider ID in their HIPAA remediation efforts. So whether payers used the NPI, D-U-N-S, DUNS+4, HIN, or Federal Tax ID to identify providers, assignment of these IDs will necessarily be based on licensed entity, individual, location or role - but never on the contract with the particular payer.

Nonetheless, even though we're sometimes forced to discuss the general notion of IDs as used in the application transaction sets, our primary problem to solve is getting some consistent way of identifying providers as EDI participants - and getting everyone (including payers) to use that same ID for looking up providers' EDI addresses (inter alia) in the Healthcare registry. It will be a great step forward if our small group gets all players singing from the same hymnal as far as ISA identification goes; it would be icing on the cake, indeed, if interim application solutions to the lack of an NPI came out of our group, too!

It sounds like we're coming to some sort of agreement that not only providers, but payers, too, find it cumbersome to deal with proprietary payer-assigned IDs as EDI Identifiers on the ISA. Are we getting closer to being able to make some definitive statement whereby we recommend that all providers' (or their agents') EDI portals be identified by DUNS, DUNS+4, HIN or Tax ID (the only current relevant choices in the Interchange ID Qualifier)?

Working with real examples helps in two ways: (1) it holds one's attention better to use real examples, instead of saying D-U-N-S xxxx for Hospital Y, and (2) if you have real good luck finding, say, a D-U-N-S for every practice and hospital you may have ever been interested in or heard about, perhaps it means D-U-N-S has great coverage and we could constrain the routing ID for providers to always be a D-U-N-S for consistency and simplicity. This is what RosettaNet and GISB have done: all trading partners must be identified with their D-U-N-S.

Some examples follow, with nothing changed to protect the innocent. The punctuation typically used to make the printed ID more readable - consisting of dashes in the D-U-N-S and the FEIN - would not be present in EDI or our registry.

D-U-N-S: 04-643-0013 - CHILDREN'S HOSPITAL, COLUMBUS , OH 07-164-3589 - RIVERSIDE METHODIST HOSPITAL,COLUMBUS , OH

Federal Tax IDs (FEINS): 23-2229683 - Aetna Inc. 61-0647538 - HUMANA INC. 95-4505291 - UCLA Orthopaedic Surgery Medical Group

NAIC: 68241 - Prudential 60054 - Aetna 54771 - Highmark

HCFA Carrier (Medicare) 16360 - Nationwide - Ohio 00880 - SOUTH CAROLINA BC/BS

The HIN (Health Industry Number) is kind of tricky to locate. I called HIBCC, the registrar for the HIN, and they wanted $10 for each ID!!! - even though I told them they were just for some examples in a paper. You would have thought they would have been grateful I wanted to mention them at all! I would prefer HIN examples for hospitals, clinics and other providers, so I would appreciate if someone on this list would supply me some. In actuality, if the HIN were going to be used as a routing identifier, the party identifying itself with a HIN would probably know what its own ID was. Here are some examples for the HIN: 52F8TXK00 - BAXTER HEALTHCARE I8IVONE00 - CARDINAL HEALTH INC. 43KEC3K00 - HUMANA HEALTHCHICAGO

I noticed that the 835 guide does not have the ABA Routing Identifier listed as one of the permissible codes for the Interchange ID Qualifier in the ISA. Wouldn't the ABA Routing Identifier typically be used as the receiver ID for payment orders (835) to banks? Can you even route a payment order through a clearinghouse (or VAN) to a bank, or do you always have to "hook" up with your bank directly? Clearly, the 835 EOB - containing PHI - should go between the payer and the provider directly, or through a CE like a clearinghouse. Are there even any Value-Added Banks that can handle PHI?

ABA Routing Codes for Banks: 071000013 - BANK ONE, NA, CHICAGO 021000018 - The Bank Of New York

We are attempting to develop recommendations to the Healthcare industry for Trading partner identification and transaction routing. In order to fulfill the spirit of the HIPAA law, it must be possible for entities willing to use the standard transactions to have a somewhat predictable (read: standardized) means of getting their standard transactions to the payers.

Everyone knows their own name(s). I even know my own D-U-N-S and FEIN. Providers probably know theirs, in addition to their HIN, and eventually their NPI. Payers know theirs, which might include their NAIC. My D-U-N-S should be the same, regardless which intermediaries I choose to use. A payer's NAIC, if he prefers to use it, should be the same regardless of the intermediaries the provider uses. Since these IDs have already been assigned, and are globally unique within their respective domains, why not use them? - at least until the globally unique National Payer and Plan IDs are available. And by all means, the "ZZ" should be banished: there should be no "mutually defined" in standards!

IDs can't be used for authentication: there's nothing secret about them. You can easily find my D-U-N-S, even if I didn't give it to you. And I can easily find out what your NAIC is, even if you didn't give it to me. Likewise with HINs and eventually, National Payer and Plan IDs. Since IDs are easy to discover (even lacking a central database), they make ideal EDI addresses - but lousy passwords! Actually you shouldn't even have to "discover" them - the provider should be able to find them on the back of the patient's insurance card. Given the payer's ID, it should be possible for a provider, who's willing to cobble together a standard transaction, to get it on its way to the payer in the least confusing way possible. Anything less might be construed as a roadblock in the way of Administrative Simplification.

You admit that you "...have a very non-standard situation in the ISA at this time, with the possibility of providers needing to identify themselves in different ways to each receiver." Standards are needed only for interoperability. Undoubtedly, your clearinghouse service is a well-oiled machine which works well for your customers, who are already seamlessly engaged in Healthcare electronic commerce. It probably matters little what we come up with here - your paying providers and payers are already electronically enabled, and they will happily accommodate themselves to whatever idiosyncrasies you mandate for the ISA.

But to require a provider new to electronic transactions to munge the ISA, using IDs other than the sender's and receiver's own, might be construed as adversely affecting the provider as surely as charging fees for the privilege of submitting a claim or eligibility request. Once this door is opened, then payers might very well use other tactics like requiring the submission of standard transactions on diskette, or enforcing weird or obsolete protocols like X.400 or BiSynch, if the (payer's) preferred VAN or Clearinghouse is not contracted with.

Proprietary IDs Marcallee Jackson told us "[e]ach healthcare clearinghouse maintains a list of payer ID's. These ID's are sometimes designated by the clearinghouse, sometimes by the clearinghouse's trading partner and sometimes by the payer. I believe its this code that is commonly sent in the ISA field."

Isn't our problem made easier if the payer tells everyone what its own name or ID is, constrained by the allowable qualifiers in the ISA Interchange ID Qualifier? In the absence of the National Plan ID, we should allow for a payer being identified whatever ID it prefers - Anthem might prefer the D-U-N-S and Highmark the NAIC. Some payers might have two or more D-U-N-S, any of which may be acceptable. Likewise, some providers will identify themselves by the HIN, others by the FEIN.

But it does no service to interoperability if a provider, using HIPAA standard transactions, has to make a determination like "Payer 'A' is on CH 'B', who demands that the payer be identified by 'C' in the ISA, except on Thursday, when it must be 'D'." Along the same lines, do we want to banish use of the "ZZ" (Mutually Defined) qualifier, which - as Kepa has pointed out - is often used to specify an ID given to the provider by the receiving payer? At the front of my mind always is the mess we have now with payer-assigned provider IDs. This is probably why I slipped and said "[our] primary problem to solve is getting some consistent way of identifying *providers* as EDI participants.." Indeed, we want consistent ways to identify all participants, including payers, Clearinghouses, Third Party Administrators, Re-pricers *and* Providers. It should be clear from all my monologue over the last two or so months that I understand we have to identify all players in order to access CPPs in a Registry and address parties in the ISA.

But as it is, there doesn't seem to be much argument over how payers are identified: the NAIC seems to be relatively well standardized upon, and for our purposes it's a perfect identifier. You don't see providers assigning proprietary provider-assigned payer IDs - instead we have a common sensible and standard means of identifying payers (e.g., the NAIC company code).

The big problem to solve, as I have oft-repeated, is to level the playing field and have the payers extend the same courtesy to providers: address them by their own "name," rather than forcing providers to "memorize" a bunch of payer-assigned proprietary IDs (whether for the ISA or within the application transaction). I can't speak for the other payors, but our Plan has been eager to see a national provider ID for some time now.

We use multiple proprietary IDs and have wanted to consolidate onto one new number -- we even had a project to modify the provider ID fields in all of our systems. Unfortunately, the proposed National Provider ID has us afraid to re-enumerate providers on our own as we are sure the final Reg will come out the day after we are done, making us do it all over again. ;-)

But seriously, multiple IDs is as much of a problem at our end as it is at the provider end.

As for whether there is intelligence in the numbers, the answer is no and yes. The no is because there is no intelligence in the number itself. Rather the number is the intelligence. For example, if a provider has multiple locations, he or she will receive multiple ID numbers with each number corresponding to a location on our system.

Because we started up new products in the mid-90's and took over an HMO at the same time, some providers received different ID numbers for different products. This is because those products or companies were supported on different systems than our traditional BCBS business, and those systems had different requirements for ID numbers.

Regarding the information we will require on a claim, we will follow the same process as described by Doug Renshaw, except that we will not modify the NAIC numbers.

NPI and National Plan ID I agree that the lack of standard Provider IDs is a problem. However, if the suggestion is that the industry ought to embrace the DUNS number (or any other number) as an unofficial standard, then I would object to that concept. The problem with that idea is that the release of the final NPI regulation is hanging over us.

Enumerating providers is not an easy thing to do. The communication of the new numbers and the process for doing this is time consuming and costly in terms of time, money, and resources. There is significant work involved in creating new provider tables/databases, loading this information, and making sure that all systems process this information correctly. Finally, there will undoubtedly be claim processing problems as an entity migrates from one number to the next.

If the industry (or parts) were to move to DUNS and HHS releases an NPI regulation which uses anything other than DUNS (which it is expected they will do), the industry will have to discard all the work to move to DUNS and re-duplicate the effort. There would be no way for the industry to recapture the lost time, effort, and money that it spent moving from today's proprietary IDs to the NPI.

The companies I work for have been poised to move to new provider IDs for a number of years now and have been unwilling to pull the trigger for fear that immediately after we do so the HHS reg will come out and the whole thing will be wasted. I would not be surprised if the same is true with other carriers. The best thing for all concerned is for HHS to release the NPI reg and for providers to act quickly in getting their new ID numbers. (Keep in mind that the move to a standard could break down if Providers don't hold up their end by getting these numbers.)

The same is true with standard group IDs and payer IDs, for what it is worth.

Application This seems like an overly broad mission, especially since we're mostly concerned with interoperable guidelines for "discovering" EDI addresses to use in the routing of standard EDI transactions. Reading the Identifiers subgroup's scope, I'm not surprised people would think we're going to get into the nitty grittty of using identifiers for providers, payers and contracts within application transaction sets! I have no objection to looking at this interesting problem or writing it up in our white paper (which would consist of just copying and pasting from Kepa's Identifier myths), but this is really a topic better served by the overall WEDi/SNIP Business Issues SWG. Identifiers are of interest to us here in the WEDi/SNIP ID & Routing group only insofar as they're used to assist in the routing of standard transactions - i.e., when they're used in the ISA receiver field. The MPD only affects identification of the provider (and the contract) in the claims ensconced within the X12 transaction. do think we will have to at least pay lip service to aspects of identifiers as they're used in the application transaction set - if only because applications will have to divine an ISA receiver ID from something, and that something will be the various combinations of IDs used today (within the application or the 837, say). For example, to do routing, a payer might need some way to find the provider's DUNS, HIN or EIN - one of the ID domains allowed by the HIPAA IGs in the ISA. We can't say you can key on any combination of criteria (including plans, contracts and line of business) to search for a (payer's) EDI address: a VAN or EDIINT software, which don't burrow into the application transaction, wouldn't have anything but the ISA receiver ID (and possibly some stuff at the GS) for making routing decisions. So keys used (as nodes) in Kepa's DNS "directory" would necessarily be restricted to ISA and GS information. my provider's application's programming problem to determine which identifier is used on the claim or eligibility or cert request. For all of them (many numbers for a single provider), and in my case, many providers, I'll still have a single EDI address (well, actually 4 - 2 for batch and 2 for near-real-time).

I guess the real question is how the endpoint responder gets my EDI address. What they get in the transaction will be the unique provider identifier they have told me to use. If my common EDI address is not in the message for them to generate a response to me, then they would have to discover it which means I'd have to register all provider identifiers pointing to one of the 4 EDI addresses (now there's a really ugly thought...). I guess that's why I thought the ISA address would be my ultimate response address, but if that's not the case......

Since Loop 1000 shouldn't be used as an "audit" trail - and, indeed, it can't because nobody along the way can *add* instances of the loop (because 1000A and 1000B both have a loop repeat of 1 in the HIPAA IG) - they can only change Submitter or Receiver - then it seems like it is an application transaction representation of the two parties identified on the ISA: the sender (submitter) and the receiver.

I can see how you would think "...that a 'repricer' would leave loop 1000 information on the repriced claim exactly the same as when he received it," but since the re-pricer opens the envelope and potentially changes stuff, I think we have a whole new "round" of sender and receiver.

In Raj's first example, when the provider (or his BA) formats and sends an 837 to Raj (the re-pricer), the provider or billing agent is the submitter or sender (in both Loop ID-1000A and the ISA), and Raj said he is the receiver (in both Loop ID-1000B and the ISA).

When Raj "re-prices" the claim, I agree with his intuition that he is no longer the "receiver," and he must change the loop somehow. I'd say he becomes the submitter (loop ID-1000A) and the payer should become the receiver. Because Raj is now the submitter, his name and telephone number can now appear in the 1000A PER segment, so the receiver can have a real person to talk to find out what the heck is going on! don't think the 1000A (Submitter Name) and 1000B (Receiver Name) "audit trail" in the 837 are all that important. Besides, the other transactions (like the 270/271, 276/277 and 835) don't have an analog of this "audit trail." Based on previous observations, though, it's probably the usual case that the 1000A and 1000B Electronic Transmitter Identification Numbers exactly reflect the sender and receiver IDs on the enclosing interchange envelope.

The ISA is incapable of carrying application data - unless you can manage to squeeze it into a ZZ-qualified sender or receiver ID! The ISA sender and receiver IDs must be valid identifiers from a limited set of domains, e.g., HIBCC HIN, NAIC Company Code, Dun & Bradstreet D-U-N-S, IRS Tax ID (FEIN), etc. IDs of this sort can serve as both routing identifiers *and* application identifiers. Therefore, it's entirely possible that any of these also appear in the "application" NM1s (e.g., the 837's 2000A loop to identify the billing provider).

Generally, you would use one of the NM1 "application" identifiers (say, the Tax ID) for a provider to locate his CPP (Electronic Partner Profile). The CPP would then tell you what identifier to use in the ISA for the receiver. It would be mere serendipity if it turned out to be the same (the Tax ID in this case) - it could just as well be the D-U-N-S or HIN of the provider.

As pointed out by various folks, including Jan Root and Bob Poiesz , the 1000A (Submitter Name) and 1000B (Receiver Name) "audit trail" are of limited usefulness - they most likely just reflect what's on the ISA. And the ISA sender ID is used solely for reporting TA1 and 997 acknowledgements.

Determining the ISA receiver of an interchange containing application transaction turnarounds depends on identifiers supplied for the billing provider (in the case of the 837) or information receiver (270 or 276). For example, at least one of the IDs supplied in the 837's 2000A loop to identify the billing provider would be used to locate the CPP (Electronic Partner Profile) for that provider.

Depending on attributes of the desired exchange (e.g., functional group of the response, say the 277U), the CPP may provide DeliveryChannels ("EDI Addresses") describing the portal to which the interchange is sent, along with the desired receiver ID to be inserted into the ISA. This ISA receiver ID may very well be different from that of the sender ID on the interchange containing the original 837!

Knowing what your own "name" is begs the question whether your trading partner can divine the ID you're known by. Imagine the scenario where a physician first encounters a patient. Let's assume Peter Barry's grandiose plans for insurance cards with National Plan IDs comes to fruition: the National Plan ID could be used to search the "National Plan ID database" to come up with, say, the NAIC company code of the payer. From there, the WEDI/SNIP Registry would be searched on the NAIC to come up with the WEDI/SNIP CPP (Electronic Trading Partner Profile) which is used to tell you how to deliver eligibility inquiries and claims to the payer handling the particular plan. Until the advent of the National Plan ID, I suppose the NAIC company code of the payer could appear directly on the insurance card as the "electronic" EDI address for inquiries and claims.

But I don't see any way for the provider to use the 270 Loop 2100B (Information Receiver Name) to convey his D-U-N-S to the payer for use in returning the 271 Eligibility Response. If the provider chose to identify himself by D-U-N-S, how would the payer know which ID to use in the response's ISA? This might be what Chris Feahr wanted to know, i.e., how to auto-discover the "return path" back to the provider?

Keep in mind that the provider's sender ID in the ISA should probably be directly used only for TA1 and 997 acknowledgements; there must be some other means of figuring out the ID of the provider for application responses since not only is the ISA long gone (discarded by the translator), but prudence would dictate that the ID be derived from the application data (or other data known to the payer) - rather than saving the ISA sender ID. This may not be a problem for the payer in the case of in-network providers (where the payer would have the provider's "preferred" EDI address - the D-U-N-S - on file). But a non-participating provider has to have some means in the 270 transaction to give the payer his preferred EDI ID.

The 837 Claim seems to have gone half-way in acknowledging this problem, and provides a way for the provider (or his agent) to send the "Electronic Transmitter Identification Number" (ETIN) to the payer in the 1000A Submitter Name loop. But there's no way to say whether that code is a D-U-N-S, a Tax ID, or a HIN, or whatever - the 837 IG unhelpfully says "Established by trading partner agreement." Like the 270, the 837 does have a way for the provider of telling the payer his FEIN (Tax ID) in the 2010AB Pay-to Provider loop; but even if the provider used the FEIN as his routing ID, there's no definitive way of saying that it *is* the EDI ID (as opposed to just one more ID the provider shares with the payer).

The definitions for Interchange Sender and Receiver seem quite adequate and appropriate - they say what I've maintained all along. The ISA Receiver field is only needed to return TA1s and 997s (and possibly 824s reflecting IG violations). Application acknowledgements, such as the 835 answer to the 837, and the 277 answer to the 276, would not necessarily be sent to the ISA sender of the original request - instead, the ISA receiver would be "calculated" based on NM1s in the original request.

Interchange Envelope But as it stands, there are only a few ways entities can be identified in the ISA based on the constraints HIPAA imposes on the ISA Interchange ID Qualifier. For providers, it leaves us with only the D-U-N-S (and D-U-N-S with suffix), the Federal Tax ID (or FEIN), or the HIN as acceptable domains for identifiers - if we rule out the 'ZZ' (Mutually Defined) qualifier (the ZZ qualifier is usually used for payer-assigned provider IDs, which are the bane of standardized identification). I assume that once the NPI is in place, there will be no problem getting it added as one of the acceptable ID types in the ISA.

X12 is meant to be independent of the transport method. The ISA only needs to hold "logical" identifiers that represent the sending and receiving entities - and 15 characters is more than enough for any conceivable identifier (e.g., DUNS, FEIN, HIN, NAIC, or even the National Plan ID and National Provider ID).

It was always understood that some sort of mapping table (whether at the VAN or CH, or in the EDIINT software) would take a logical identifier and "map" it onto an "EDI Address." An EDI Address would be a particular mailbox (in the context of a VAN or CH), or the protocol and addressing specifications in the case of EDIINT or FTP, say. Our project takes EDI Addresses to an extra level of indirection: identifiers would be "mapped" to a CPP, which in turn contains one or more EDI Addresses (selected by preference or functional purpose, e.g., "real-time" vs. batch). Each "EDI Address" would describe where (physical address, e.g., FTP address) and how (packaging, e.g, X12.58 security or EDIINT) to send the interchange. The logical identifiers used in the ISA are fairly static - how often does a DUNS, FEIN (or even an NPI, if it comes to pass) change? But EDI Addresses are ephemeral, subject to the whim of the recipient: one day I might want claims to go directly to me via FTP, and the next day I might change my mind and have them go through a Clearinghouse. A dynamic mapping system keyed on logical identifiers accommodates this nicely. We probably shouldn't call ISA08 an "EDI Address." It's the recipient's EDI Identifier. An "EDI Address," as Peter Barry would remind us, is all the technical mumbo-jumbo that defines the protocols, port addresses and other desiderata for moving EDI data to a particular point (e.g., FTP addresses, dial-up telephone numbers, etc.). The EDI Identifier in ISA08 will be used to retrieve the recipient's CPP (Electronic Trading Partner Profile), which in turn will contain the appropriate EDI addresses.

And yes, it's possible that interchanges can be "going out the door with identical ISA08 values (identifying the receiver), but be going to different EDI addresses... because of their specific transaction payloads." This seems to be a requirement raised in previous discussions; e.g., "real-time" 270s might be directed to a different EDI address than "batched" 837 claims. I don't know how this could be done today with current translators and communication software: how does the translator convey to the communication software that the interchange is "real-time" vs. "batch"? If anyone has an idea how they would implement this with their current systems, please don't hesitate to write in!

If there is no direct link between the translator and communication software, then the comm software does have to be sensitive to the payload contained in the interchange - at a minimum it will have to "drill" into the GS envelope to distinguish eligibility inquiries from claims, or to examine the GS Application Receiver's Code for hints in selecting the appropriate EDI address. Likewise, if all interchanges are sent to a single intermediary, such as a VAN, then the VAN would have to "drill" into the interchanges (so the correct EDI address can be determined).

As an example to show why "drilling" down into the GS may be required, consider the scenarios presented by Doug Renshaw earlier. Highmark might want interchanges delivered to a different EDI "gateway" depending on whether "V" (vision claims), "W" (if an institution is in its Western Region), or "C" (if in its Central Region) is appended to its NAIC in the GS Application Receiver's Code - these suffixes would determine the appropriate EDI address to send the interchange to.

If only X12 had adopted ISO 9735 UN/EDIFACT Syntax Version 4 for interchange control, then we could have avoided the problem of drilling into the interchange (to retrieve distinguishing information from the GS). The UNB Interchange Header in EDIFACT not only lets you specify the recipient identifier (in D.E. 0010 - Interchange recipient identification), but also an internal routing code (in D.E. 0014 - Interchange recipient internal identification), so you can make all your decisions for routing just by looking at the UNB without going further in the interchange. See http://www.gefeg.com/jswg/ if you're the least bit interested in the layout of the ISO 9735 EDIFACT interchange envelopes. But unfortunately, adopting ISO 9735 interchange envelopes is not in the cards, so we have to rule out this elegant solution! As an aside, I'm left wondering how all those translators out there today are going to handle out-of-network claims from a provider the payer has never seen before - will they have the capability to automatically create Trading Partner table entries, dynamically adapting to new ISA sender IDs as they arrive?

Now, as Rachel would say, I think I'm getting "wrapped around an axle" with this ISA and GS stuff. After thinking about it, the GS should only be used for internal routing by the recipient - something we all learned in EDI 101. No intermediary or communications package should ever have to "drill" down within an interchange to look at functional group envelopes.

So we probably only have the ISA available for routing. And if only the ISA can be used, that probably implies only the 15 character ISA08 Receiver Code is available for discerning EDI addresses - which might require different recipient IDs for various purposes.

So where does that leave us if a "real-time" 270 has to be sent to a different "portal" than a "batch" 837? Do we have to use a suffix on the payer's NAIC company code in the ISA08 receiver field to distinguish between batch and real-time?

Martin Scholl's impression that the HIPAA IGs allow you to choose the ISA qualifier "ZZ" so you can put "anything in there" is correct. As far as I know, the guides have not changed since I last saw them.

And we can accommodate the ZZ qualifier in our CPP Electronic Partner Profile: the receiver can specify in his DeliveryChannel ("EDI Address") that the ISA Receiver Interchange ID Qualifier and ID are to be whatever he deems fit. Perhaps his DeliveryChannel is assigned to his clearinghouse, and the clearinghouse only knows him by some *contrived* (CH-assigned) receiver ID using the ZZ "mutually-defined" qualifier. Since the receiver is a customer of the clearinghouse, he knows ahead of time what his proprietary CH-assigned receiver ID is, and can place it in the CPP so senders know what to use in the ISA receiver field.

Just make sure you understand that the sender would have no way, a priori, of knowing what proprietary ID to use in the ISA receiver field until he accessed the receiver's CPP. Remember that no proprietary IDs could be used to *search* the Healthcare CPP Registry since there would be no way to ensure their uniqueness across all CPPs for all entities - i.e., your notion of ZZ-BILLYJOE might be different from another's notion of the same pair. That same ambiguity doesn't exist for RA centrally managed identifier domains, e.g., HIBCC HIN, NAIC Company Code, Dun & Bradstreet D-U-N-S, IRS Tax ID (FEIN), etc. NAIC Company Code 54771 is Highmark, regardless who's doing the talking.

Keep in mind that there's no way to compel a sender to identify herself with a proprietary ID. Given the Open-EDI aspect of HIPAA, a payer may not even know ahead of time that he's about to receive a transaction from some provider: how would he ever manage to assign a proprietary payer-assigned ID to her? On the other hand, if she chooses, a sender may identify herself with a ZZ qualified sender ID (in actuality, she may have been forced to by her one and only VAN or clearinghouse).

It doesn't matter that the sender ID is mutually defined: the receiver never uses the pair except when turning around the TA1 or 997. This forces me to backtrack a little on what I told Todd Velnosky this morning: if an interchange using a ZZ-qualified sender field were being acknowledged, then the TA1 and 997 would have to be returned to the same clearinghouse the original interchange arrived from, simply because only that clearinghouse is guaranteed to know how to interpret the ZZ-pair.

To determine the receiver ID of application responses, the sender would use one of the NM1 "application" identifiers (say, the Tax ID) to locate his partner's CPP, which in turn (using the DeliveryChannel) says how to get the response where it's going and what to stuff in the ISA receiver field.

Didn't I say the ZZ-qualified proprietary ID would not be a problem? i.e., once the CPP was found, the EDI Address would inform the sender that the ISA receiver was to be a ZZ-qualified proprietary ID. I just wanted to make sure we all understand that the sender would have no way, a priori, of knowing what proprietary ID to use in the ISA receiver field until he accessed the receiver's CPP.

But a "mutually defined" ID is not necessarily unique (except within the domain comprised by a particular payer or CH), you have no idea who assigned it (just by looking at the ISA), and it cannot be used in a National Healthcare directory. It has a meaning only in the context of a particular payer or Clearinghouse. And if it's particular or peculiar, it has no place, really, in our recommendations. I see no way around this conundrum.

You may recall that we had submitted definitions for ISA sender and ISA receiver that I thought were considered acceptable. The basic concept is that the sender is the entity responsible for creating the exchange and it's contents and the receiver is responsible to processing the contents of the exchange. So, if the contents of the entire exchange (ISA to IEA) will be processed entirely by the receiver, then yes the ISA receiver will most likely be the provider or payor. if I understand this thread, we MUST choose one of the legal ISA identifiers as a KEY to this (yet-to-be-defined) record that explains all of the 'collaboration" details... including other ISA identifiers that might be acceptable?

If so, I would vote for the Fed. Tax ID# for the registry key. As I look down this list, the FTIN seems to be the only one reliably there 100% of the time and one that virtually every business will know (about itself) and have no qualms (and violate no user agreements) disclosing to "the world".

-Chris

01 Duns (Dun & Bradstreet) 14 Duns Plus Suffix 20 Health Industry Number (HIN) 27 Carrier Identification Number as assigned by Health Care Financing Administration (HCFA) 28 Fiscal Intermediary Identification Number as assigned by Health Care Financing Administration (HCFA) 29 Medicare Provider and Supplier Identification Number as assigned by Health Care Financing Administration (HCFA) 30 U.S. Federal Tax Identification Number 33 National Association of Insurance Commissioners Company Code (NAIC) ZZ Mutually Defined

In the absence of the national identifiers, we are left to select from one of these coding systems or to use the ZZ Mutually Defined. It's my opinion that if the objective is to be able to use the identifier from the ISA to discover more detailed EDI addressing information, then it's irrelevant which coding system the ISA identifiers are based on. The only requirement at the present time is that to be compliant with the HIPAA specifications, one must choose one of the above.

Thus, I'm not sure that I understand the detailed discussion of various identifiers and identification systems. Wouldn't it be more on point to be examining how the ISA identifier would/could/should be used to link to the EDI Addressing information?

Furthermore, when (notice that I'm the eternal optimist and didn't say if) the national identifiers are finalized, then I would certainly expect that the ZZ Mutually Defined option would go away....and even perhaps the other choices in favor of the national identifiers. Thus, I again reiterate that I think it's quite irrelevant to the goal of this work group to get too wrapped around the axle about various identification systems. Rather, shouldn't the focus be on the "functional use" of the identifier in the ISA as the key to discovering the detailed EDI addressing information?

Doug Renshaw was kind enough to respond to my pleas from 15 March for information on how folks currently (or will) handle the ISA and GS for routing standard transactions; he has graciously agreed to let me pass on Highmark's plans as grist for discussion. Other than Doug, only Tim Collins and John Bristor have responded. Tim divulged some information on how Kentucky Medicaid might be handling IDs, and John Bristor shared what appears to be some kind of Medicaid EOB with strange and wondrous proprietary IDs. At this rate, I don't have too much to work from: I hate to nag, but with the hundreds of people on this list, surely some more folks could throw information my way so Ron Bowron and I can do a "proper" requirements analysis.

Doug said that Highmark will require that its NAIC code (54771) be submitted as the Receiver ID in the ISA. In the GS, he will require the NAIC of the payer that the transaction applies to, which could be that of Highmark or several other associated payers. NAIC codes are 5 characters, and the GS receiver ID can have a payer-defined 3 character suffix applied to the NAIC. In some cases, they will use a Highmark-assigned alpha suffix to manage internal routing requirements of stuff within the same payer.

For the Sender ID in both the ISA and GS, Highmark requires the use of a proprietary trading partner ID. For transactions coming from a Clearinghouse, they'll have a trading partner ID for the clearinghouse which will be tied to individual providers.

Also, Highmark requires a logon and password to connect to its network for sending and receiving EDI files. Highmark is considering use of the Internet to replace its dial-in network, but use of a logon and password would still be required.

Highmark will only accept standard transactions, and only for a set list of payers who are in the Highmark "family". If a provider attempts to send transactions to payers not on Highmark's list, they will be rejected. Highmark is not attempting to offer providers a "portal" for submission of their claims to any and all payers - only a means of getting claims directly to itself and several of its subsidiaries. Doug does agree with my belief (by reading the NPRM) that payers will have to offer providers a direct "portal," or else will have to contract with a clearinghouse to collect standard transactions for them.

As for Highmark's use of NAIC suffixes in the GS, they spell out some specific uses for particular transactions as required for internal routing and processing purposes. Specifically, Highmark will require a "V" on vision claims, and for institutional claims, they will require a "W" if the institution is in its Western Region and a "C" if in its Central Region. Doug recognizes that NAIC codes are not a solution that works for all health plans, and that Highmark may need to change its requirements if and when a national plan ID is established.

Likewise, according to Tim Collins, Kentucky Medicaid now has plans to re-assign proprietary provider IDs in anticipation of HIPAA . These IDs are "intelligent," in that the 10-digit number used on the ISA denotes the type of submitter (e.g., Medical Practice, Software Vendor or Billing agent), further qualified by the type of institution on whose behalf the transaction is being submitted (e.g., Hospital, clinic, pharmacy, dental, etc.).

Doug Renshaw didn't go into detail on how Highmark's provider IDs are generated, or whether they are "intelligent" or not. I guess that doesn't matter. What I do know now from these few "scenarios" - including the Medicaid sample from John Bristor - is that payers sure do like proprietary provider IDs! But do providers feel the same way?

If anybody were thinking we would come up with a scheme whereby you could put a plan ID into an ISA (which you can't, because the Interchange ID Qualifier can only address carriers or entities addressable by the DUNS or EIN), and auto-magically the interchange would end up at the appropriate place (the repricer for claims, or the Third Party Administrator for eligibility requests), then (1) that would be neat, and more importantly (2) it would be really, really hard to do.

I think if you want to have an 837 go to a particular repricer, you're probably going to have to explicitly put the repricer's identifier (what is that? - a DUNS, an EIN?) in the ISA receiver field. And, likewise, if you want a 270 to end up at a particular Third Party Administrator, I suppose that TPA's identifier will have to appear in the ISA receiver field. How is this done today using X12 through Clearinghouses? - what's expected in the ISA (and perhaps the GS)? See "EDI Meets the Internet: Frequently Asked Questions about Electronic Data Interchange (EDI) on the Internet," RFC 1865 at http://www.ietf.org/rfc/rfc1865.txt, especially sections 5.8. Can the ISA 06 or 08 identify any entity other than the 'end' Trading Partners (i.e. a routing entity)?, and 5.10. Are there other options for routing EDI X12 messages?

...although the ISA06 and ISA08 elements are supposed to be used to identify the sender and receiver of the interchange, the receiver of the interchange could be a clearinghouse (as well as a VAN) that processes the interchange and then forwards the data to the ultimate recipient. In this case, you could put the receiver ID of the clearinghouse into the ISA08. The clearinghouse would probably have to determine the ultimate recipient of the message by looking inside the transaction set (or perhaps by using the GS03).

Though this IETF RFC is obviously not a HIPAA document, it proves as of 1996 that this was not a weird practice. The TA1 and 997 go back to the sender in the ISA, whether a CH, billing service or the "real" provider.

What's the problem with calling the CH who builds the ISA the "sender" or "submitter" in order to differentiate him from the "providers" he's aggregating? If the provider (or his agent) puts the provider's ID in ISA06, then the provider is also the sender (or submitter). Analogously, the "receiver" could be a CH or payer. A payer is always a payer, and even sometimes the "receiver" in the ISA.

The Present 1. The present is payer-centric. It could keep going that way, but the future health care electronic traffic will include provider-to-provider transactions involving delivery-of-care and reduction of medical errors (4th largest cause of death and injury). Having every provider set up in advance with every possible other provider is not very practical. In the future, eventually, providers will participate, not as clients, but as equal participants. Especially, a sender will be able to send an asynchronous message and the provider will be able to receive it. This is a hugely significant change from the payer-mailbox model now used for batch transactions and the client/server model now used for DDE transactions The note includes "distributed my EDI documentation". That would appear to include two types of information: (i) connectivity attributes, which are the primary subject of the CPP suggesting there might be a more efficient way to let provider computers know the terms for connectivity, and (ii) transaction requirement profiles, the subject of "companion guides", which might become electronic profiles, the "7-level" edit subjects. If these subjects cannot eventually be reduced to computer-readable information, we will have lost a lot in the goals of standardization.

The dominant business model in health care is:

1. For the most part, only health care claims are submitted electronically by providers to the party they've determined is the financially responsible party for reimbursement. 2. The format used for electronic claims is most often the NSF batch file format, or some variant thereof.

3. It's not typical that a provider submits claims directly to the financially responsible party. Rather, intermediaries are more likely than not to be in the picture. Intermediaries can be clearinghouses, TPAs, repricers, billing services, and so on.

4. These intermediaries typically determine the financially responsible party by interrogating data contained with the batch file.

5. While the NSF batch file has batch header and trailer records which start/end the batch, the records in the batch are fixed field/fixed record multiple record types.

6. The industry does not use the typical EDI VAN store and forward model. Thus, it has not built an infrastructure that uses an identifier from a batch header record to "mailbox" files for the receiver.

7. The industry model is one of the provider always have to "push" electronic claims to the financially responsible party through an intermediary and to then "pull" any return messages.

8. Other types of information exchanges, queries, referral requests, etc., are most often performed via phone, IVR, DDE, or fax. Thus, today's application systems do not typically support nor enable batch file transfers for these types of information exchanges.

As you know, the model which most other industries use for standards-based EDI exchanges is one where the receiver of the interchange maintains a mailbox at some "post office" - most often called a VAN. Thus, both parties to the information exchange maintain their own mailboxes (or multiple mailboxes) at a post office(s) of their choosing. It's this model that the current X12 control structures enable and support.

Providers' Perspective Noticed that I never answered your questions below, so I thought I'd take a minute & do so. When everything was fee-for-service, the world was simple - then HCFA decided to contract for certain services from certain providers, and to only pay "schedule" rates for other services. The flood gates are now wide open, and we have nearly as many health plans as we do employers represented in our databases. The carriers offer "specialized" plans and there are no guidelines on how these coverage agreements are structured - its truly a boutique business. The carriers sell the plans to employers, who turn around and offer the coverage to their employees - larger employers offer several different coverages, depending on the employee's needs. They (carriers, large self-insured employers, HMOs) then come to our front door (some thru the back door) and negotiate with us to be a contracted provider to perform some or all of the services they are selling at the other end.

Along with these plans came another cottage industry - third party administrators (TPAs) - who sell their services to employers and carriers - they contract to perform lots of different services including claims review, claims repricing (taking the provider's charges and "re-pricing" them to reflect contract agreed charges), eligibility & benefits checking, etc. Further, if the plan is capitated, they perform other services related to lifetime benefits and adjudication on behalf of the plans. There are numerous situations where more than one TPA can be in the mix - e.g. a professional repricer before the plan administrator, and even a separate reviewer. They can be in any sequence, though the repricer is usually the first stop for claims if one is present. The only good news is that usually (but not always) the TPAs can figure out amongst themselves where to send the claim next in the sequence because they only deal with a limited set of contracts.

The kicker is that these "third parties" usually get inserted into the mix because neither the employer nor carrier want to be burdened with figuring out the nuances of the ridiculous contracts they are negotiating. So they contract with the third party, and then tell us that "for plan INS-xxxx, send the claim to RPCyyy, and request eligibility & benefits from TPAzzz". So, it ends up being our problem to determine where to send claims and address inquiries. I have no doubt that this situation will continue with EDI, so having a separate set of addresses by plan and transaction makes a lot of sense to me. This assignment is somewhat dynamic, however, and needs to be kept up to date by whoever is contracting for the coverage. These contracts are usually not long-term, and when they change, often the claim destination can change along with other contract terms. I'm still not sure I understand how we would ever go about determination that re-discovery is necessary, but i'm learning more every day... Hope this helps to explain some of it.

One of your clients visits Iowa (vacation hotspot that it is)...a place you don't have a large presence. He is injured and end up at one of my hospitals. We don't have a trading partner agreement with you, as we have no prior relationship. We can't send you an automated eligibility inquiry, as we don't have your routing #. Do we have to train our registration staff to call and ask for routing #? What do we do to get the electronic process going? Or do we have to program our system to automatically drop to paper when the claim is processed? (totally shoots the standardization process.....) Youbetcha! If/when the NPID becomes real, and when payers all agree to apply for and get one, and then when they all agree to put the identifiers on the cards, we'll all be very happy. Ditto the Nat'l provider IDs for inclusion in the ISAs (are providers even required to apply for them?). Until then, however, we'll unfortunately have to live with a hodge-podge of identifiers, but that shouldn't keep us from making any forward progress.

What if we simply said, for example: ok, all you payers that want to post your CPPs to begin development of CPAs with potential provider trading partners, post in the DNS the address where your CPP can be found under whatever identifier you are currently using on your insurance cards - preferably your group/plan ID, but if that's not present, and all you have is a phone number, post it under that. Without waiting for a national identifier, and waiting for the hundreds of millions of insurance cards to be re-issued, we can just start moving forward with establishing CPAs, and sending 837s. If I could just convince 25 large carriers to do that, I could achieve 50% of my goal for development of TPAs by 4/16/03, with only a fraction of the work. If the payers want to designate a CH to be their receiver, then they can simply point their identifier to where the CH's CPP resides (all the same to me).

If this is true, and we want to eliminate the burden on the intermediate hops (CHs, VANs & whatnot) in not having to delve into the message to try to determine who the recipient should be, the only option left is to place the endpoint receiver into ISA08. Since that is effectively the envelop within which I'm sending the claims, I therefor can't place claims for other destinations into it (I suspect that Aetna wouldn't want to sort thru primaries to determine which were for them, and then forward the rest to their intended destinations...).

Realistically, this means that if I were to send claims for 50 different endpoints to a CH, I would send them 50 different ISA/IEA batches, some of which may only contain 1 or 2 claims. If the CH is performing routing for me, then they would probably have the CPAs already established with the endpoint receivers (the CHs would already know how & where to send the EDI packages without opening them). If the CH is a designated receiver for an endpoint, then they will have Trading Partner Agreements which tell them where/how to route the claims. In either event, routing should be easily accomplished without having to look inside the wrapper (which seems to me to be the most effective approach for everyone). I believe the extra cost of a few hundred bytes per day for additional ISA/IEAs is worth the price...

Payers' Perspective My current position is with Coventry Health Care, a nationally based Health Insurer. We currently receive our Inbound 837 claims from WebMD. We also receive Authorization requests from WebMD in a proprietary format. We send to them a number of other transactions, including 835 remittance information.

This is all accomplished through the use of a T1 line and the FTP Protocol. No file encryption involved.

For our inbound enrollment data, some of it does come to us utilizing PGP file encryption, and other data we dial out and retrieve using FTP, ZMODEM, and even old XMODEM.

Prior to coming to Coventry, I was with one of the nations largest Practice Management Software companies, now called Misys Health Care. They own one of the largest Clearing Houses as well. All the providers that utilized that Clearing House did so through the use of a modem and dial up connection, utilizing FTP to transfer the files. This was for 837 and 835 transactions, as well as reports.

I believe, as it appears to me, most of you do, that the Internet will be the transfer method of the future. My concern is that this group may have missed how things are working today and that the vast majority of Providers, not Hospitals, are not connected to the Internet through their PM Products. These Providers, for the most part, do not have the staff in place to implement anything outside of what their PM Software Company provides. What we will do is return a response to the submitter, depending on if it is an unknown trading partner or an unknown provider within data from a known trading partner. We will reject a transaction from an unknown trading partner. We will front end deny an unknown provider.

We have many obligations related to paying providers. Working an unknown is not one of them. And I did not see anything in the rules requiring us to do so.

A provider is not our customer, but potentially a trading partner. We have the liability of properly reporting income to the IRS and state income boards for payments to that provider. We will insist that they become known, not necessarily participating, to us before accepting their claims.

We currently use login information at the ISA level. This is then cross referenced with the system login/password that transmitted the interchange. Interchange/ISA information is not forwarded to the applicable application. Within the transactions we would use our business level IDs for the submitter. We separate security from identification to the application. (That makes it harder for someone to hack the system and submit business information) Also, we support multiple business entities submitting through a singe login/password. (Lots of reasons, too many to get into in detail.)

I was one of the first people to state that I expect to eventually see and want a clean, secure, Internet way for Health Care to conduct Ebusiness. But that is a long way off. that does not necessarily mean 'open' as I have seen it described here.

I would submit that, at least with the company with whom I am familiar, we never accept unsolicited claims, electronic or paper, from providers with whom we have no established relationship. The blues are perhaps unique in this, since providers located outside of the service region do not send claims directly to that blue, but rather to the entity licensed to perform the same function in that state or region.

We are not going to change the fact that we are fiscally responsible for paying claims to people actually licensed as providers and accredited by the state boards. Nor will we accept their assertion, by receiving a properly formatted claim, that they are who they say they are without some assurance, spelled contract, that we acknowledge their right to receive that payment.

Nothing in your CPP will assure any auditor, paid paranoiacs that they are, of the validity of the relationship or the security thereof. Solve that problem, for free, then we've got some good groundwork. I talked to a person from a large health insurance carrier the other day who's been "lurking" on the list. Though we've gotten into a lot of technical depth here, he's certainly enjoyed the discussion thus far - but as someone from the business side, he had a little problem in putting together just what we're attempting to do. Once I could give him the 20-second "elevator" pitch on what it all meant, it resonated with him and he became a "true" believer in the ID & Routing project. Basically, I told him, any provider who has his NAIC co-code will be able to *automatically* find out where his EDI "portal" is - and other technical information - from his electronic Trading Partner Agreement. He does millions of claims a month, 80% of them electronic, where 90% of those are direct from the providers using direct dial-up FTP. He wants to move to the open Internet, where encryption will be necessary. All these details of FTP addresses and security will be in the e-TPA. And, additionally, there's no reason the e-TPA couldn't contain a machine readable version of what he would have had in a "companion" document: e.g., testing requirements, EFT details, data clarification for situational elements, etc. etc. He'll be able to eliminate a lot of paper and in-person communication, and facilitate direct point-to-point exchange of standard transactions with providers.

Routing Interchanges It sounds like the electronics biz (EIDX) has some of the same problems we have when it comes to identification and routing. Just goes to show you that solutions coming out of our proposed Healthcare CPP Registry might be generally applicable across all business domains. Supply-chain, anyone?

Hypothetically, a payer has relationships with two clearinghouses to receive claims and submit remits: CHA and CHB. A provider sends an 837-I through CHB which, in turn submits to CHA to reach the payer. This process takes place due to the connectivity environment between the payer and CHB which only allows 837-P to be transmitted. The payer produces an 835 based on that 837. Could the payer submit the 835 to CHB or should it follow the same route through which came the 837 (via CHA)?

Your hypothetical scenario assumes the payer has an arrangement whereby all 835s (remittances) are submitted through CHB. Therefore, I suppose, the payer should return the 835 through CHB. The route whence the 837-I arrived is irrelevant, and all knowledge of the original claim's path is long gone. The 837 ceases to exist by the time it gets to adjudication: it has decayed into any number of atomic claims; see "Requirements Gathering - Information Flows," (16 Feb 2002) at http://www.mail-archive.com/[email protected]/msg00219.html.

As far as the provider is concerned, it doesn't matter what intermediaries are used to return application responses. In this case, CHB would likely recognize the ISA receiver ID for the provider (since the 837-I originally came in through CHB from the provider) and know where to deliver the 835. Even if CHB didn't recognize the receiver ID (say, the provider was using CHB as an "open portal" to reach the payer), the clearinghouse could use the Healthcare CPP Registry to look up the ISA receiver ID and figure out the EDI address of the provider.

TA1 and 997 acknowledgements would probably be treated similarly (i.e., there's no X12 requirement that these traverse the same path as the interchange they're acknowledging). Parties Who's arguing about the ISA receiver ID being any other than that of the end-point receiver? But as I asked Friday, though, couldn't the "end-point" be a repricer or TPA (as opposed to a payer)? If, as Ronald Bowron pointed out, a CH is the "end-point" for re-packaging or aggregation, then the ISA receiver ID would be that of the CH; is that at all controversial?

We shouldn't get all "wrapped around an axle" on this "financially responsible party" business. As I described yesterday, if the payer is using a clearinghouse as his inbound portal, his own ID (perhaps even a proprietary CH-assigned ID) will probably appear on the ISA. I don't know what CHs require on the ISA receiver field for aggregated claims appearing in a single 837, but it's probably not that of the "financially responsible party" since there would be many such parties to whom claims are being made (in the single 837).

Actually there's nothing keeping *both* the provider and the payer from using proprietary formats or NSF, even under HIPAA. If there's only one CH between them, as long as the CH converts (or is capable of converting) the data to and from the standard HIPAA formats for at least a millisecond, all is okay. I think anything going *between* separate clearinghouses has to be standard transactions, though. many of the payers are actually going to contract with CHs as their "front door" for EDI (whether the CHs are subsidiaries or otherwise), then that CH's identifier could, in fact, be the identifier that the payer tells us (via the CPP or other manual method) to place on the claim (in the ISA). It would be assumed, in that situation, that the CH is acting on behalf of (is the agent for) the payer, and therefor represents "the financially responsible party" in its dealings with the provider.

In that case, the CH would have specific arrangements with the payer (a TPA), that could, in fact, specify conversion to a proprietary format (such as NSF) for transfer of the claim to the payer. As long as the claim is transferred from provider to the CH as an 837, the law is satisfied (as I read it), because the CH would be operating as the payer's agent.

This is also true in reverse for the providers. Some billing software will be used by smaller providers to enter claims data, and will then transfer that data to a central location in a proprietary format (say, a "flat print image file"). The central location is the billing software's "hub" - just another CH in our view, but one with a special relation to the provider - it is the provider's "billing agent"). Again, the law is satisfied because the CH is the agent of the provider, and it communicates to payers via the mandated transaction set. One of the largest provider software suppliers in the country is planning on doing just that as their "answer" to making the software HIPAA compliant - and they are licking their chops at the millions of $$ to be made sending all those claims on behalf of the provider in that really difficult electronic format (and for only $.25 per claim - what a deal...). I'm inclined to believe that addressing the receiver should be independent of who the sender is. So I'm uncomfortable with your suggestion to use the ISA SENDER ID and the GS SENDER ID for selecting between alternate "EDI addresses." I think the other items from the ISA, GS and ST are acceptable for consideration in looking up EDI addresses.

"ISA ID(s) would probably be guaranteed to be unique only within the domain of the same VAN." This is true only in the case of CH (or payer) assigned proprietary IDs. But this group definitely will be recommending that all parties be identified by global identifiers (of their own choosing, e.g., DUNS, NAIC, HIN, etc.) - DUNS 04-643-0013 is unambiguously Children's Hospital in Columbus - regardless of which VAN or CH is being used. Unless an interchange is going through a pass-thru intermediary - a switch or a VAN - which delivers EDI for many entities, it probably really doesn't matter what's in the receiver field of the ISA, does it? If I deliver an interchange to Anthem, directly, doesn't it stand to reason that the interchange is somehow for none other than Anthem? Maybe Anthem will use the GS envelope for further routing, but would it even pay attention to the ISA receiver field?

But if the interchange is passed through an intermediary, such as a VAN or CH, clearly the immediate destination (the VAN or CH) will not be identified as the receiver on the ISA. The ISA receiver field probably should be that of the next entity to open the transaction set: this might be the payer (for a claim), but could just as well be a Re-pricer or Third Party Administrator - who I assume are not classified as "payers." Actually, the "real" payer (the insurance company behind a self-funded Employer plan) may never see standard transactions for a plan - is it correct in this case, then, to call the payer a "receiver"?

Blues Blues are perhaps unusual - if I've interpreted some folks including Robert Barclay and Bob Poiesz correctly - in that claims are submitted to the provider's local BC/BS, regardless of the Blue the subscriber is insured with. The local BC/BS serves as kind of a re-pricer before forwarding the claim to the "home" Blue. Or something like that. See http://www.mail-archive.com/[email protected]/msg00501.html.

We've talked about the payer's CPP DeliveryChannel ("EDI Address") being selected on criteria like the plan ID, payer identifier and transaction function (e.g., batch vs. real-time, claims vs. eligibility request) alone. But accommodating the Blues' desire to have claims sent to the provider's local BC/BS adds a bit of complexity. Note that I said "desire," not "need," because it seems the BC/BS ITS network could just as easily perform out-of-area forwarding instead of burdening the poor provider with the problem. Nevertheless, perhaps the folks designing the Elements of the CPP (electronic Partner Profile) can think of ways that selection of a DeliveryChannel can be based on attributes of the inquirer (in effect, the provider's location). Take the Blues for instance. HIPAA requires that we all accept claims etc. from providers. But it does NOT mandate how. If I am in Maine, I can say to a Utah provider "No, you can not send HIPAA transactions to me". And I will follow that with "My business associate that handles HIPAA transactions in your area for me is the UTAH Blue Plan - contact them".

Nothing in HIPAA mandates that I do the HIPAA transactions via the same route or business associate for all providers/trading partners. Now, somebody can 'say' that I am refusing to obey the law and conduct HIPAA transactions with that provider, but that is NOT the reality of the situation. I am just directing the provider to the proper routing for cliams from that provider to my plan. And, that means that I can not support 'open' EDI. That would negate my current right to deligate my HIPAA responsibilities to business associates as I see fit. To my knowledge, the only restriction under HIPAA is that my business associate could not charge that provider more that the cost of a long distance telephone call.

It has been a couple of years since I was involved with ITS/Blue Card but I will give you what I remember. If my mind wonders too far someone please correct me. The system is more than a convince to providers. It was also designed to give one Blue plan the benefit of other plan's rates when their subscribers traveled.

So if I am from California and see a doctor in Wisconsin. I give the doctor my Blue membership card which has an ITS prefix appended to my subscriber number. This prefix is different from the Plan code. The plan code is numeric and one is issued per plan. The ITS prefix is a three byte alpha ID. There can be more than one ITS ID per plan (i.e. HMO, PPO, etc...) For example, the plan code for Blue Shield of California is 542 and the ITS prefixes are XEA (PPO) and XEE (HMO) and there may be more.

The doctor submits the claim to BC/BS United of Wisconsin with my subscriber ID of XEA123456789. Wisconsin takes the claim and sees that I am a Blue Shield of CA member, based on the XEA prefix. Wisconsin then determines the local negotiated payment rate and forwards the claim to Blue Shield of CA. Blue Shield then finishes processing the claim. Then, here is were I am a little fuzzy, I can't remember if Blue Shield then cuts a check/denial or sends its decision to Wisconsin where the check/denial is created. Anyway, you get the idea. This is more than a clearinghouse arrangement. The participating Blue plans are acting as pre-pricers for each other. The Local Plan, where the provider is located, accepts a transaction and contacts the Plan where the member is from to determine if the person is eligible for coverage, whether the coverage includes the service provided, and what copays or coinsurance should be applied.

Upon receiving this response, the Local Plan processes the claim and responds to the provider.

The choice for the provider is whether they want to connect to one local Plan or 50 some odd Plans all around the country.

As for using the Blue Plan identifier, not all Plans want to use that identifier on the standard transactions. The ones I am familiar with are using the NAIC code. Furthermore, with HHS slated to issue a Payer ID regulation, I think you will find it difficult to influence Plans to change their processes prior to the HHS regulation being issued. Functional Group I don't have any strong feelings one way or another. In the health care supply chain sector, the common practice has been to use the same values at both the ISA and GS levels.....unless the sender and receiver agreed to use the GS identifiers to identify, for example, a business unit or operating unit within a larger enterprise. This is how I implemented the use in 1985-87 at Baxter Healthcare. I believe that this is common practice in other industries as well, i.e., the same values at both ISA/GS......

For HIPAA, I could certainly envision a payer, for example, specifying a GS receiver code(s) for one or more adjudication systems and other GS receiver codes for other types of transactions. This is closer to the original intent. When this approach is used your EDI translator can then output the correct file to the correct backend adjudication system.

Unfortunately, the original intent is not documented and all that we're left with in the standard is the data element name. It's just the old-timer's like me that remember some of this history!!! Personally, I think it's unfortunate that the HIPAA guides haven't provided for explicit guidance for the novices for not only the use of the ISA/GS identifiers, but also the other standard acknowledgments, such as the TA1 and the 997. As you know, confusion reigns!!!

I think that what has happened is that many people have not needed to use the GS for the original purpose. As a result, they have defaulted its function to being a restatement of the ISA values. That is different than morphing. Its fine to retain that default content when no other need exists. But it would be detrimental to assume that you could eliminate the other (original and primary) use and only leave the default. The fact is that these are not the sender and receiver ID. They are something different. I assume that by your "...but..." you are not in favor of retaining that original functionality (I apologize if I have misread that point). I believe that eliminating the "Application" capability from the GS would be a mistake.

The GS segment does not have either a Sender ID or a Receiver ID. What it has is an Application Sender's Code and an Application Receiver's Code. These are very different. They are intended to be used for routing and translation map identification. We are using these elements to determine both routing and mapping. In some cases, we need this information to determine which application gets the data.

In fact, I would say that the GS elements can not be standardized. The 270/271 implementation guide makes some recommendations on how to distinguish between Batch and Real Time transactions:

If trading partners are going to engage in both real time and batch eligibility, it is recommended that they identify the method they are using. One suggested way of identifying this is by using different identifiers for real time and batch in GS02 (Application Sender's Code) for the 270 transaction. A second suggested way is to add an extra letter to the identifier in GS02 (Application Sender's Code) for the 270 transaction, such as "B" for batch and "R" for real time. Regardless of the methodology used, this will avoid the problems associated with batch eligibility transactions getting into a real time processing environment and vice versa.

Overloading the GS sender code (using solely for internal routing by the recipient) is certainly preferable to requiring different sender or receiver IDs in the ISA, depending on Batch or real-time. But unless we come up with specific recommendations that apply across the board - for every provider and payer - stuff like what's in the IG will require a TPA (or "companion document"). We want to remove the need for TPAs, right?

Anybody have specific ideas for differentiating batch from real-time? How about keying in on BHT03 - the Submitter Transaction Identifier? It's required to be used (in the 270) if the transaction is processed in Real Time - and since it can only be returned in a real-time 271 response, it seems like a most excellent marker. I do realize that makes it tougher for the payer to distinguish between batch and real-time inquiries, in that you have to drill into the bowels of the transaction set before knowing which queue to insert the request - but is that any more difficult than relying on the GS?

Testing In a "test" mode, it would seem easier to pack only "test" transactions into an interchange anyway... so the T/P indicator should be useful right where it is. But the CPP record could certainly carry information that supports other ways of distinguishing test from real data.

In my experience with the ISA I14 is that people generally ignore it which is not to say it can't work. Most organizations do not have tight enough controls to trust that they use the ISA I14 correctly.

Re: Testing. The ISA I14 Usage Indicator (e.g., P for Production Data, T for Test Data) applies to the entire interchange - we can't change the X12 standards here. I'd say just put the production transactions (and functional groups) in one production interchange, and the test transactions in another. This technique requires nothing of the CPP, since theoretically a test interchange is sent to the same portal using the same IDs in the ISA as production data.

Unlike the ISA I14 T/P indicator, which is universally understood - if not universally implemented, some (or most) organizations demand that test interchanges be sent using a "testing" ISA receiver ID. I think we can handle this, too. There's nothing to keep us from adding the capability into the CPP for specifying a Test ID and Qualifier - along with the production pair. This would be done on a Delivery Channel ("EDI Address") basis, with some means to differentiate the production and test (and maybe even "real-time") ISA receiver ID and qualifier pairs. For example, in effect, the CPP would say if you end up using Delivery Channel X, then production data is sent with the ISA receiver field saying NAIC co-code 54901, but a test interchange would be sent with the "mutually defined" ID "54901TEST" - the NAIC with "TEST" appended. This is an augmentation of what we discussed before, where the CPP specifies what's stuck in the ISA receiver field depending on the circumstances; see "Why do we flap our lips so much....," at http://www.mail-archive.com/routing%40wedi.org/msg00438.html, from 12 April. It would be nice if everyone had the ability to process transactions based on the testing indicator as recommended by the X12 User Guides. And that all the information in the ISA would be used for both Production and Testing. Then the only data element to change when going live would be the Test/Production indicator. The problem with this indicator is it is not transaction specific - therefore it assumes all transaction within the interchange are valid for production. This is not always the case - for example, an entity may be in production with sending eligibility requests, but not claims.

Also, not many institutions have used the T/P indicator properly. Most organizations didn't setup their test environments to represent their production environments when it comes to sender and receiver ID's. Therefore, a sender may have one ID for testing and another for production - assuming the ID is dictated by the receiver (i.e. via ZZ codes). It's possible that some may consider building x-ref tables to address this and the use of standard identifiers like the D&B numbers.

Packaging I believe we are attempting to create a blueprint here for massively enabling communication between "EDI veterans" and a [possibly] large # of EDI neophytes (doctors, labs, DME suppliers, etc.). If the Big Boys are currently using "creative" implementations of the ISA information, I don't think that should deter us from recommending that the ISA be used exactly the way the standard envisioned it. If providers do enable themselves to create X12 interchanges, I would not be surprised to see lots of ISA/ISE envelopes containing a single transaction (e.g., a "real time" 270) or an interchange with 4 or 5 claims in it. Large batches of different transactions with multiple addressees is probably an artifact caused by the mere existence of the traditional form of the CH industry. As the CH industry develops new value-added services to support a model in which payors and providers collaborate more directly through EDI, then I suspect interchanges to get smaller and become more homogenous and more numerous.

Portals The Web Services "paradigm" is not exactly analogous to what we're grappling with here. But even if it were apt, shouldn't your conclusion be that the *submitter* (or requestor) do the splitting? - i.e., choose among the (possibly many) "addresses" to forward his interchange to?

Yes, the payer - through his CPP - is offering "services" to the provider: saying, in effect, "we do all these types of transactions: 837, 270-271, 835, 834, 276-277, etc." But should the provider have to make the decisions to implement the split - i.e., decide to send the 270 to the payer's designated "real-time" portal, and 837s to the payer's "batch" portal? Or should the payer always make it easy on the provider by saying "Send everything to this one portal," and then separate 270s from 837s for subsequent processing behind the scenes? don't believe that it's practical or reliable **today** to assume that the provider can select or determine how to address and where to send a given instance of a HIPAA transaction.

I suspect that many payers' architectures have evolved over the years as new transactions and capabilities were added to their business offerings, and as a result, there are several portals into/out of the organization depending on the type of transaction, the timeframe in which that transaction is to be processed, the destination backend system, and so on. I don't believe it's reasonable to expect payers to totally re-architect their systems environment in the short term, solely in response to the HIPAA transactions requirements.

A similar architecture most likely exists at many providers, especially the large multi-facility provider organizations, where disparate and disjoint systems initiate a variety of transactions, and where these transactions leave the organization through several exit points. An ideal architecture would/could be one of a single portal that would have the ability to immediately detect the type of transaction being presented and the expected timeframe within which that transaction should be processed and then appropriately address, envelope, route and receive, parse and process accordingly. But, that's an ideal and not in sync with today's situation.

I will be surprised if this is a significant problem. That being said, I do not support your suggestion that this problem be laid at the doorstep of payers.

I suspect it is true of most payers that they maintain eligibility on a different platform than claims. In fact, the data is probably on multiple platforms -- one for enrollment style information, another for benefit plan related information, yet another for information about deductible and co-insurance accumulators.

That fact notwithstanding, given how much trouble it is to get one translator set up I can't see plans setting up a separate entry point for each transaction.

What may occur is that Payors may prefer that transactions from a professional provider (e.g. doctors) go in through a different gateway that transactions from facility providers. This is likely to be true when doing business with a Blue Cross Blue Shield Plan and the member has non-HMO coverage. The reason is historical -- the BCBS Plan probably still is set up with a system for facilities and a system for professionals. However, even there, if you are doing business with a combined Blue Plan and they have been combined for some time, they may have unified their enrollment and eligibility systems.

This may also happen with any carrier (Blue or non-Blue) that outsources some processing services. This could occur if the carrier outsources processing of transactions from professional providers. More likely, it could happen if the carrier outsources processing from specialty providers. For example, how many carriers interact directly with pharmacists, as opposed to hiring a PBM to do it? The same is true of behavioral health providers. Many carriers outsource that interaction to another company. Remember that self-funded groups are a wild card. In those cases, it may be the group, not the carrier/TPA that chooses which claims go where. The members may be carrying an ID card that has a logo from a particular carrier/TPA, but the provider may be surprised if they try to send a transaction to that carrier/TPA. That situation is outside the control of the carrier/TPA.

It is a good point to document. It is a question that providers and clearinghouses basically need to ask and payers need to try to anticipate and answer. The responsibility cuts both ways -- it can't be laid just at the doorstep of payers.

In closing, I offer the following comment as a practical caution. Given the number of claims I have seen providers mess up -- sending them to the wrong address, the wrong carrier, empty envelopes, holding them for months before sending them, etc. and then they go crying to the regulators and legislators and say that the only reason their accounts receivables stink is because of big bad carriers -- I can tell you that if someone suggests that providers don't have to take any responsibility for figuring out where to send things that person will find carriers very unsympathetic.

Using the transaction set as one component to determine the destination of an interchange was never defined out of scope. But *requiring* anything other than what's available in the ISA to determine routing would place a burden on providers new to the standard transactions - or their agents (VANs). Altruistically, my concern is motivated solely by the needs and capabilities of the "little" people (providers).

Generally, anyone producing standard transactions is aware not only of the ISA sender or receiver fields, but also stuff in the GS and the ST - theoretically they could make decisions for routing, selecting the appropriate node in Kepa's DNS scheme. But it might be asking too much of their off-the-shelf practice management software to traverse Kepa's DNS tree (or even to use a CPP type of arrangement). Instead, they (the providers) should be able to dump all their interchanges into one conduit and be assured their "stuff" will get there safely, securely and reliably based solely on receiver ID.

If that conduit were a VAN, wouldn't it be too much to expect the VAN to burrow within each and every interchange, group and transaction set to determine routing? It's not impossible, certainly. But, again, why should the sender (or her agent) have to concern herself with each of the variables present in the ISA, GS and ST (and possibly more, if you consider real-time requests which are evident only by looking within the transaction set) and figure it out on her own where to send the interchange? Isn't the ISA receiver ID enough? She has already specified the recipient's NAIC, Plan ID, or whatever, in the ISA. Once it gets to the payer, I think it should be incumbent on him to figure out how to internally route the interchange (or functional groups within).

I know I sound like a broken record, but I doubt very much that many providers will be dumping transactions into any VAN. The norm will be to dump the transactions into a clearinghouse. Providers will probably have direct connects to a few payers with whom they do a large amount of business, but the rest will be via a clearinghouse. In many cases, that pre-packaged practice management system will send only to one place, the vedor/vendor's-selected clearinghouse. The software will force a submission route that guarantees a revenue stream for the vendor (not that I like it - it is reality - I have been in touch with at least 1 MAJOR vendor with that plan).

I believe that there are two probable solutions for the batch/realtime issue. The majority of the solutions will either use separate channels for the batch and realtime (different mailboxes), or different values in GS02 as suggested in the 270/271 guide. I believe that you are correct that the health plan should make sure that they handle the priorities, but I think the solutions will fall into these 2 main categories.

I haven't looked at the ISB to determine its viability as a technical solution. The fact that it is not part of the HIPAA guides is not an impediment, in my opinion. The 997 and TA1 are in the guides, but specifically not required as part of HIPAA. The unsolicited 277 is not a HIPAA transaction but at least some are planning to implement it as a claim pre-adjudication edit report. If willing trading partners wanted to implement the ISB as a batch/realtime solution, that is outside of the current scope of HIPAA and not a problem. The only issue would be that a health plan would not be able to require the ISB in order to accept an otherwise compliant interchange. The ISA06 and ISA08 sender and receiver "addresses" should be unique and not overloaded with extra duty. That's the only way they can be interpreted unambiguously by all intermediaries. In addition, all the information needed for correct processing should be contained within the interchange itself - between the ISA and the IEA - as a self-contained package because it's too much to expect PM systems to support alternate "channels" for conveying information to the payer. And besides, the provider can be anticipated to only have a single "conduit" to the outside world - his VAN - the simplest model for supporting inter-company exchange.

Clearinghouse Aggregation It's important to remember that for any one X12 interchange, there's only *one* sender (or submitter) and *one* receiver - regardless of the number of payers or providers whose "stuff" is embedded in a single 837. To get some boundary on definitions, is it safe to say that the sender is definitely the guy who creates the ISA? What can we say about the receiver?

I would submit that our job is only concerned with the identification of the trading partners (who may be clearinghouses, billing services, repricers, etc. - not just providers or payers) at the ISA level, and the issues of routing - what's needed to be known in order get the interchange from here to there.

What any intermediary - such as a clearinghouse - does with the enclosed transactions (and functional groups) is simply none of our business - project scope-wise. Such a simplifying assumption should assist us in maintaining focus.

If you're referring to the "problem" of end-points being only payers or providers (or TPAs), I've already given out my opinion that I don't think that is much of a problem. Addressing Clearinghouses can easily be accommodated in our recommendations.

I'd go a step further, and say that supporting aggregation can be made a first-class feature of our CPP EDI Address function. Take an example: a sophisticated provider, like Dave Minch, wants to send standard claim transactions to 20 payers. He looks these payers up in the Healthcare CPP Registry, and finds that 10 of the payers are supported by the same clearinghouse, and that claims for any of the 10 are to be directed to the same "portal" resident at the clearinghouse.

Normally, Dave could choose to build 10 interchanges, one for each of the payers, shunting them off to the designated CH portal seriatim. The CPP for an individual payer might even specify an alternate EDI ID to be used in the ISA receiver field - i.e., the proprietary CH-assigned payer ID.

Now imagine this: the CPP for the Clearinghouse (which has been referred to by the payers' CPPs) says somehow in the Delivery Channel for claims that claims can be "aggregated," with a special Receiver ID to be used. This could be of benefit to both Dave and the Clearinghouse: Dave now can "aggregate," or combine, the claims for all 10 payers (as described previously by Bob Poiesz) into one standard 837. Maybe there's some obscure advantage to Dave in doing this - as if he'd run out of incremented transaction set control numbers otherwise; I don't know - but it's Dave's option to do this as no one is forcing the provider to perform aggregation.

The CH receives Dave's aggregated 837, and assuming it's HIPAA-compliant, can then proceed to split and merge, combining other providers' claims (for the same payer) into consolidated 837s for each of the payers. Apparently, some payers find this to be a big advantage in having multiple providers' claims all munged together in the same 837. In any event, there's nothing that keeps our recommendations from elegantly supporting such "requirements."

But if a provider wants to send a batch of claims to different payers all bundled up in one 837, for subsequent re-sorting and distribution by his own clearinghouse, then by all means he should have that choice. The 837 HIPAA IG doesn't disallow this (it's silent on the issue) - therefore his 837 is still considered "HIPAA compliant."

More likely than not, our recommendations have *absolutely* no effect on this practice: the provider has determined that he would rather deal with a Clearinghouse and make a single 837, and has arranged with that Clearinghouse to do the "un-bundling" and aggregation. The provider will probably not be using our recommendations because he has no need to address, and route to, individual payers - he has devolved the responsibility on the CH for finding and routing transactions to the payers. I see no reason to act as if this practice is offensive. It isn't. But it's also one that really doesn't have to be documented in our recommendations, for the simple reason if you always package up 837s for your own Clearinghouse, you hardly have to go about "discovering" its EDI address.

It's important to remember that our recommendations are to effect the efficient, safe and secure routing of standard transactions between business partners - to describe a method for providers to discover where the heck they should send the stuff once they've gone to the trouble of building standard transactions. A provider who prefers to always use a CH has no need for our recommendations.

Switch Intermediaries If we do address the auditing issue, am I safe in saying that our concern should be limited to making recommendations for keeping track of an (intact) interchange as it hops through intermediaries on the way to the receiver?

If so, usage of the TA1 (Interchange Acknowledgment), transaction set 997 (Functional Acknowledgment) and transaction set 242 (Data Status Tracking) are all within our purview. The 997 and TA1 are covered in the HIPAA IGs; the X12 242 transaction is used between intermediaries (e.g. VANs) to say what the disposition was of interchanges as they passed through interconnections.

Once an interchange has been opened, tracking and auditing probably relies on application segments (perhaps the 837 Loop ID-1000), and thus is out of scope for this project.

Open-EDI Payers will have to be prepared for taking in anything coming along from providers - if they would have taken paper before, they can't put roadblocks up discriminating against the equivalent Federally mandated HIPAA standard transactions! Not only will they have to make available an open portal for receiving electronic claims and eligibility inquiries (advertised in our Healthcare CPP Registry), but they will have to make sure their translators can accommodate ISA senders they've never seen before.

1. It is potentially possible for a payer to receive an electronic claim from a non-participating provider 2. The payer cannot refuse to receive the claim 3. The payer is not obligated to process/adjudicate the claim 4. The payer, in my opinion, should anticipate the potential for receiving electronic claims from unknown providers and have a procedure for dealing with them 5. This process would be no different than what happens today if a payer receives a paper claim from a non-par provider....what do you do with it?

The real radical notion is this Open-EDI I'm talking about - though it seems few payers are thinking along these lines. Remember: "A health plan may not refuse to process a transaction simply because it is a standard transaction." I can't but think if a payer would have taken a paper claim (from a par *or* non-par provider), they absolutely must take the HIPAA standard transaction, the absence of a trading partner agreement or "certification" notwithstanding.

We do hope that no mis-routing of claims will happen - that's where the Healthcare CPP Registry will help: if you have the plan's identifier, you'll get the correct CPP, which points to the plan's open portal.

I agree, up to a point. But I still say that a form of pre-qualification must exist, at the trading partner level. The last thing I want to do, as a payer, is disclose eligibility data about one of my customers to someone not eligible to receive said data, also a clear violation of the only part of HIPAA with judicial recourse. And that puts us back to a trusted relationship with whomever is requesting the information.

In the electronic analog of this story, the payer will have to accept standard 837s from the "unknown" OSU. The payer took OSU's paper claim; the law is clear that it will also have to take a file formatted according to the HIPAA IG. Which leads to the need for the Healthcare CPP registry: (1) OSU would have to have some (easy) means of finding Anthem's (free) electronic portal for submitting standard transactions, and (2) Anthem would need some way to find OSU's portal for returning responses (technical acknowledgements, like the TA1 and 997, and application acks like the 835 EOB).

I'm NOT saying, under HIPAA, that ANY payer has the option of not accepting a valid 837 based on the provider's non-participation status with said payer. We did have a policy like that some years ago. I believe some other payers may still. It was better for the bottom line to take in as many receipts as we could via EDI, so we dropped that restriction. We have NO intention of restricting submission of claims to participating providers.

Our TPA's will not include any restrictive clauses not allowed in §162.915. We are writing our processes to the IG's trying to allow for as much flexibility on the submitters part as possible by including a lot of new business intelligence logic. We will only be including requirements that, if not met, will cause the transaction to be unprocessable by us. While these requirements (primarily codes) are specific to the HIPAA IG's, they correlate directly to elements contained in a paper submission. Bad data is bad data.

If a covered entity wishes to conduct a standard transaction with us, we will accommodate their request, set them up and take their data or, if the transaction is an outbound transaction like the 835, we will start routing the data to the portal identified during the set-up. Their claims generation and accounts receivables may not be on the same platform or use the same transmission medium. We are not, in any way discriminating against submitters who want to conduct standard transactions. We have no intention of violating any clauses under §162.925. The closest thing we have here the necessary *adversity* of bullet "(2)": (Allowing us to set-up the submitter in our system in order to reliably conduct the transaction(s)). There has to be some reasonable thought applied to all of this. Certain things are just understood under HIPAA. Certain questions are never asked. Like... If we wished to do away with paper Explanations Of Benefits in favor of HIPAA-standard 835's, must all providers we process a claim for be able to receive an 835?

I don't want to see this whole thing revert back to business as it has been done in the past and welcome the automation possibilities available to all of us under HIPAA. We should have been able to do all of this long ago without federal mandates, but we didn't. If we assume, now, that it's just a matter of opening all the spigots, I'm afraid we'll all drown. Q. Would you ever be sending claims to insurance companies you normally never dealt with?

A: Most of our business is done under some sort of contract - where we have agreed upon certain rate schedules and service lines in advance with the health plan. We do also operate a regional trauma unit through which we get patients from all over the US and abroad, and we do a lot of billing to payers with whom we have no pre-existing relationship.

Q. Would you be doing this on behalf of the patient? - if so, would payment usually go to the patient (on the assumption he paid you up front)?

A: Technically, all billing done by us is on behalf of the patient. Financial responsibility is the Guarantor's in ALL cases - even with programs such as Medicare, Medicaid, and Champus. This is because the Guarantor can always authorize procedures and other expenditures which go beyond the care covered by any particular plan. We direct bill payers as a service to the patient (and, of course, because the patient could never figure out how to navigate the reimbursement waters by themselves). It also assures us that we will get the bulk of our payment in a somewhat timely manner.

If the patient or guarantor cannot provide us with a verifiable plan prior to delivery of service, then we will bill the patient/guarantor for charges. If they pay, then we are generally done with that account - we would not bill after-the-fact on behalf of the patient. What does happen is that the patient will pay some of the bill (or pay deductibles which we later find have already been satisfied), and then present us with a verifiable plan, where upon we will bill that plan (payable to us) and refund any over-payment back to the patient.

History

It's good that Scott has identified this. Many of us EDI people should have recalled the Open-edi Reference Model and SITG since many of us, myself included, helped to develop these documents and actively participated in SITG (Strategic Implementation Task Group) of X12. UN/CEFACT/TMWG (and its predecessor AC.1) produced a document (N010) the Next Generation EDI Reference Model, which included the concept of discovering the capabilities of trading partner using electronic means. The development of this document started in the 1995-1996 timeframe, evolving from IDEF modeling techniques to UML. This effort determined that Open-edi scenarios could be modeled as use case scenarios. The N010 document was the stepping stone to N090 or UMM as we know it.

X12 also has the Trading Partner Profile (X12 838), first introduced at version release 3020 in the early 90's as well. It has several segments that provided information about transaction capabilities (TXN) and information about business applications (ENE) at a company. It was intended to configure new trading partners but few people really knew how to do this, or wanted to, because by that time AI techniques had a bad rap. Auto-configuration was never completely possible, since all the implementation guideline were different.

X12's SITG also participated with TMWG to work on both N010 and N090. IBM was invited by SITG to speak at X12 to discuss their efforts on Long Running Transactions, and speaker was our friend Marty Sachs. We thought this was an information sharing event at the time. Most know that Marty's R&D ultimately evolved into tpaML.

Open Portals Today, an open door can not work. There ARE security issues and connectivity issues and identification issues and contract issues and validation issues and - well, you get the point. We can not ignore those or just make them go away.

But, there must also be a vision for the future. I have had that vision for years, and shared it here. But, that IS very much a future vision today. We should be able to use the internet for open healthcare EDI. But that requires security and non-repudiation solutions and databases that provide identification and routing and validation and connectivity information. We do not have those today. This is not a simple situation.

The problem that I see with the current discussion is that we are not actively recognizing that we have a today and a future. The talk often sounds like one side saying "The future is here, accept it" and the other side saying "I am not ready for it".

As I recall from the beginning, the focus was on trying to establish a direction for the future vision and to facilitate the move to that future, not to impose the future. And, this group's focus is on only part of the total problem.

You make it sound as if payers will be obligated to open their gateways, carte blanch, to any who wish to direct a file our way. While there may, in the past, for some payers, have been requirements that a provider must be "participating" in order to submit their claims electronically or otherwise capitalize on their EDI investment(s), that in no way means that we have to take in a file from entities we haven't entered into a Trading Partner Agreement with and set up in our system(s)(participating or not).

If a provider were to unilaterally determine how to route data to us and get it wrong, it would increase the chance that we might be receiving another carriers information in error. There is also the issue of our not being able to process their information or inquiry as certain basic identifiers (part of the TPA) were not used or used correctly. I know it flies in the face of admin simp., but, until all the identifiers are finalized, we will have TPA's that look a lot like what we have today.

And by no means did I have say that a payer has to adjudiciate every claim received. Only that there is the potential to receive a claim from an unknown (to you) provider and that you cannot reject it out of hand. You at least have to take it in through your electronic mailroom and then decide what to do with it the same as you would have to do with a paper claim that hit your paper mailroom. This is where the TA1 segment could be used since of course, your EDI system won't recognize the ISA sender (or perhaps it could, if the sender was a clearinghouse with which you already do business and the provider isn't known until you peel back the transaction.) In that case, what do you plan to do?

We do anticipate receiving data from both par and non-par providers and processing/adjudicating those claims. If we receive claims from providers we can't identify or discern from what was received, they are not/will not be adjudicated whether they are received on paper or via EDI. Additionally, we reserve the right to not load data into our system that is coming from a submitter (which may be a provider) we don't know.

I guess you could say my e-mail server is an "open portal." You never know what's going to come across; see below. Now even without examining the headers (which probably aren't forged, otherwise the spaminator would've discarded the message), I can tell I needn't bother with this e-mail. But it did require me to read at least one paragraph of the missive.

This is analogous to a payer simply reading the (purported) EDI file coming in on the open portal: if it doesn't have the correct HTTP or MIME headers, for example, somebody's completely wasting your time, and it can be discarded or rejected with an HTTP response code or bounce e-mail. Same thing if you can't decrypt the S/MIME with your private key or make out an ISA in the body or an attachment. Once you do get the start of an interchange, if the remainder doesn't conform to X12 syntax, a negative TA1 or 997 can be returned. If it looks like good EDI, but doesn't comply with the HIPAA IG, an 824 can be returned.

Of course, maybe I have the order things are done all wrong here, and it's certainly more complicated than this depending on the protocol and packaging, but you get the drift. Keep in mind that IETF EDIINT AS1 and AS2 implemented by many commercial software packages takes care of a lot of these details in a well-defined sequence.

But suffice it to say, for those payers worried about viruses and fraud, it's clear a scofflaw isn't going to get too far if he can't fake a good transaction with the proper transport and packaging. And if he can fake a seemingly valid 837 using the proper segments, situational elements, codes, dates and IDs, hire him, 'cause a lot of smart folks are hung up over these very issues all over the country.

Assume a correctly formatted 837 got past this gauntlet, and it's from an "unknown" provider. For those payers still suspicious of the EDI and any "cooties" contained within, I suppose there's always the option of taking the 837 and printing it out on a HCFA 1500 or UB92 claim form, pretending as if it came in the mail or on the fax! At that point, the payer is home free: there's now no danger of "disadvantaging" standard transactions vis-à-vis paper! Somebody could even make a cottage industry doing exactly this: taking in standard transactions and dropping them to paper.

Actually, come to think of it, clearinghouses do this all the time! So a payer, in this case, would have his "open portal" maintained at the clearinghouse - a free conduit unburdened by logons, passwords, fees and subscriptions. The payer's CPP Electronic Partner Profile Delivery Channel ("EDI Address") would simply point to the clearinghouse. Standard transactions coming from "known" partners would be passed through to the payer as EDI, and "unknown" providers would have their stuff dumped to paper. If somehow that makes the payer happy (though Lord knows why), that's perfectly compliant with the law which says nothing about "disadvantaging" unknown or non-par providers vis-à-vis participating providers.

I think we've beaten this dead horse long enough. Payers must maintain open portals for accepting standard transactions. The HIPAA TCS Rule requires payers to take in standard transactions on a non-discriminatory basis: no "vetting," no "certification," no "enrollment," no nothing, period.

Clearinghouses could have taken care of trust issues between payers and "unknown" or non-par providers long ago, but payers would not hear of it. Kepa Zubeldia and Marcallee Jackson have written about an EDI "Power of Attorney" concept which never gained any traction. This PoA would allow CHs to automatically sign up providers (customers of the CH) with payers, saving the provider the heartbreak of onerous and manual EDI enrollment. See Kepa's sad story at Synaptek (a clearinghouse), in Re: Trading Partner Agreements, from 05 Mar 2002, at http://www.mail-archive.com/[email protected]/msg00296.html.

Open portals are not a matter of blind trust. A payer merely has to accept a file purported to be a standard transaction from any source (which could be a BA or CH acting on behalf of a provider); he would still presumably go through the same processes he would with a paper claim. If the file is not a correctly formatted standard transaction, a TA1 or 997 will suffice to express the payer's displeasure. These are text files - no one is asking the payer to "execute" viruses or executables within the transactions. The payer simply has to read the data, and discard it if it doesn't even begin to look like EDI (no ISA, for example). It would be very bad system design to load the file into memory and begin executing the byte codes: that's about the only way I imagine a payer could get bitten with viruses!

Key exchange is not necessary before a signed and encrypted file is read. The file is encrypted with the payer's *public* key, which he has freely made available to partners via the CPP Electronic Trading Partner Profile. The payer uses his own private key to decrypt the file. He can authenticate the source of the file by checking the signature against the public key supplied in an X.509 certificate pointed to by the purported provider's CPP. There is no "exchange" of keys: payers are expected to use and support standard ITU X.509 certificates. It is unreasonable to expect providers to use PGP whose PKI necessarily depends on out-of-band exchange of certificates for applying trusted signatures; PGP will be unsuitable for all but the most insular trading communities.

Rigorous testing, and perhaps even certification, is highly recommended for providers. But when push comes to shove, the spirit of the law mandates the payer must take purported standard transactions - no ifs, ands or buts. If they're not compliant standard transactions for some reason, the payer is perfectly within his rights to return a TA1, 997, 824 or an e-mail, depending on the circumstances, clearly indicating where the first problem was found.

Your company doesn't require me to become "certified" for e-mail before I send my first e-mail to you, does it? No, of course not: if I don't follow MIME or S/MIME conventions, you simply reject the e-mail - even though it eats up some of your precious processor cycles. The same logic attends standard HIPAA transactions: if the provider has made even one mistake, tell him so and then forget about it. Nobody's asking payers to agonize over provider's syntax and semantic errors in the standard transactions.

The HIPAA TCS Rule requires payers to take in standard transactions on a non-discriminatory basis: no "vetting", no "certification," no "enrollment," no nothing, period. As Rachel has reminded us, no payer has to adjudicate every claim received - he only has to receive it and cannot reject it out of hand simply because it is a standard transaction.

But when H-day arrives, an 800 number is no substitute under HIPAA for processing of eligibility inquiries: all payers must support the 270/271 Health Care Eligibility Benefit Inquiry and Response standard transaction sets. If a payer's support of the 270/271 sucks compared to its 800 number or DDE capabilities, that supposedly is a HIPAA violation (because it would discourage a provider from using the standard 270).

Listen folks: I didn't make the law. But at least here in the ID & Routing group, we can try to put together a framework whereby payers can easily support the 271 standard transactions when submitted a 270 by any provider. This is as clear-cut a case as I've ever seen of payers having to take in standard transactions on a non-discriminatory basis: no "vetting", no "certification," no "enrollment," no nothing, period - just like the 800 number.

Overall, I believe we have the same conceptual picture of what the HIPAA world should look like. But, till we truly have a standard, as envisioned, with all the appropriate identifiers locked-down, we won't be able to play effectively in that sandbox. As a payer, I can say, we are committed to building the best transaction processing capabilities we can. However... Whether we receive an unknown provider identifier on paper or via EDI, the result is the same. We can't process the bad info and need to get a response back to the provider telling them so. How we get the response back is really the only variable here. Of course we could attempt to determine who the provider is with the available information (which we do) and cut a check to his neighbor (which we do sometimes with both paper and EDI receipts), but it's a lot more work for all involved.

Of course we'll have the same problems with Employer, Payer and Patient identifiers as well. Just at different levels and points along the way.

Clearinghouses and VANs The open-portal concept certainly does not exclude VANs from participating. Sure, VANs have setup considerations for their *own* customers - as do Healthcare clearinghouses. But how often does one sign up for a VAN or Clearinghouse? - probably not too often: you only need the services of one of them (assuming yours can interconnect with other intermediaries and switches). There's nothing in our model to keep a provider from sending all of its standard transactions through its own VAN (or CH), who in turn uses the Healthcare CPP Registry to figure out how to send interchanges to "unknown" payers' open-portals. Likewise, a Healthcare entity may very well host its "open-portal" at a VAN (or CH), and its CPP's EDI Address would simply reflect the address of the intermediary.

Ed showed an example of a VAN actually "drilling" into the interchange to discover the functional group to determine whether the interchange would be delivered via "fast-batch" - this is directly analogous to an intermediary drilling into the interchange to discover that an eligibility inquiry was being sent (functional group "HS") and could accordingly use a different EDI address for real-time connect.

I'm guessing at the scenario, but this all seems perfectly natural: hundreds of little providers send their claims to a CH in whatever form they can (e.g., paper or proprietary electronic). The CH combines claims from all providers destined for Highmark (or its affiliates) and builds one nice 837 for you. When you receive the 837 from the CH, you politely respond with a 997 to that CH, using the CH's ID in the receiver field. Nice and symmetric. So, who has a problem with this?

I didn't ask what the CH's ID looked like, but if it isn't already a globally unique ID like the DUNS, I'm hoping that we can get it there.

The closest thing we have to that today is the clearinghouse network. Clearinghouses can take care of these trust issues. The problem is that there is an notion out there that HIPAA is a way to eliminate the need for clearinghouses. When we talk of open portals, that is what tends to be the thought. The reality is that a provider in Wisconsin can get a claim to a payer in New York by utilizing a clearinghouse network (I like to think in the majority of cases). There are definitely issues associated with that, such as a lack of total connectivity among clearinghouses. But I think the alternative is a Healthcare Network of Trust, such as the ATM network in banking. I do not know if that is realistic. And the alternative of blind trust is one that I am not willing to accept. I agree with others on this listserv who have said that VANs and Clearinghouses will/could use the same or functionally equivalent "Special Software", which I interpret to be addressing software that uses CPP addressing methodologies for subsequent distribution on the Internet or Intranet. This "Special Software" functionality would be standard and could be developed by individual trading partners, HIS and PMS vendors and any VAN or Clearinghouse. The business decision concerning whether a trading partner uses a VAN or Clearinghouse, or "Special Software" will in large part be made on price, availability, and ease-of-use (and additional considerations, especially other VAN or Clearinghouse value added services ). However if trading partners, including large and small providers, are otherwise HIPAA compliant, they will use the solution that best meets their needs, and many (probably most) will make the decision largely on cost. Accordingly, to the extent that health plans and/or the HIS and PMS vendors develop easy-to-use "Special Software" and integrate it into their systems for less than what a VAN or Clearinghouse would charge, I suspect many trading partners would use it -- especially if the VANs or Clearinghouses don't provide other value added services. see no need to explicitly focus our recommendations on direct point-to-point to the exclusion of clearinghouses. The discussions to date have talked about Delivery Channels within the CPP which are somewhat capable of supporting clearinghouses.

Actually, intermediaries - like VANs and CHs - will be able to use our recommendations just fine. I can imagine a provider contracting with a CH intermediary for all communications. Thus, the CH will benefit by being able to discover where the provider's partners (payers, TPAs, etc.) are automatically - and they certainly won't all be customers of the CH itself. The provider in this case has delegated the task of looking up and discovering CPPs to the CH - which itself is a valuable service (that the CH can tout).

But having said that, providers themselves who have contracted with clearinghouses have no direct need for our recommendations. The recommendations will be of most value for providers and payers (and CHs, TPAs, billers and repricers) who wish to connect to each other directly.

A clearinghouse can receive 10 837s from 10 providers. Each provider can be sending claims to 10 different payers in their 837. When the clearinghouse resorts and organizes the claims they produce 10 837s for each of the 10 payers that contain claims from each of the 10 providers. Each 837 from the CH to a payer contains claims from multiple original senders. Each 837 from a provider contains claims for multiple ultimate receivers.

For what it's worth, the design and requirements of our EDI interface use point-to-point sender and receiver ID's in the ISA. That is, if receiving a transaction from a clearinghouse, that clearinghouse's ID must be the shown as the sender. I expect that we are not the only payer to work this way. Nobody likes sharing their customer list, although clearinghouses, in order to get provider customers need to at least share their payer connectivity list.

Internet I wouldn't at all be surprised to learn that the actual situation of how CMS really handles communications is much different than its public policy statements ... and along the lines you outline below.

Unfortunately, I don't see anything in the HIPAA final or proposed regs that requires the use of the Internet or any other transport method....only that if the Internet is used, encryption is required.

So....I guest that the bottom line is that CMS can choose to go a different direction and not use the Internet, even though it has an Internet policy that would seem to allow it???

While the presentation I made includes a bullet as stated to emphasize the point made during the presentation, the dialog went on to explain the difference between the open internet, use of the internet as a private network when the appropriate security is used, and how confusing this all is to the lay person. The dialog continued to say that Medicare does allow their contractors to offer the use of the internet protocols (not 'open internet') but there are some steps (e.g. 128-bit encryption) to follow before transactions containing PHI can be sent over the internet. These steps assure the secured transmission while using internet protocols, and are specified by CMS for Medicare. The point is that telecommunication exchange of HIPAA transactions is not specified by the regulation and industry interpretation of 'over the internet' is inconsistent. We would all benefit from some consistency here, even if only to understand the terms, our options of 'over the internet', when to secure, how to tell, and perhaps specific design issues/solutions. I applaud the efforts regarding telecommunications - past and in progress. I think this could be a 'sleeper' issue when considering the full suite of HIPAA transactions and workload/workflow transitioning from today's telecommunication networks that are based on direct connections between payer-provider to browser-based connections. Sited from: (Dated July 24, 2001) http://www.hcfa.gov/security/fq011399.htm

Can provider and intermediaries/carriers begin using the Internet for sending and receiving Medicare claims and remittance advices? No. Although the policy does away with the restriction on use of the Internet it does not give organizations the authority to begin utilizing this media without obtaining full coordination and approval from all parties in the process, including HCFA. Implementation issues remain to be resolved, and allowances must be made for software and/or hardware upgrades or changes. I would agree that the need to be able to specify a variety of transport methods and protocols goes beyond just what CMS requires....but it's incorrect to presume that CMS prohibits the use of the Internet. See my other post with CMS' current Internet policies Encryption is required if you are going over an open network, meaning the Internet. This was reaffirmed by Bill Braithwaite in Chicago last week, who is now in private practice but was there when the final security rules were written even if they haven't been published yet. But if the network is itself secure, such as dial-in, leased line, VPN, then encryption is not required.

Trust and Authentication Though I don't see the AMA providing any VAN services, I do definitely see the value of the AMA-Verisign relationship. The AMA already knows all of their members, and those members' initial contact points. By merely giving the membership list to Verisign, the latter is guaranteed a good list of presumably vouched-for physicians. This information can be used by Verisign in a high-quality targeted "recruitment" of physicians for digital ID services. Since the AMA information is derived in an "out-of-band" context, in-person presentation of credentials (which adds to the horrific cost of digital certificates) might be avoided.

One of the uses of these digital IDs might be in EDI: If a payer receives a transaction from a provider, who has digitally signed his payload with one of these Verisign signed (on the AMA's behalf) certificates, it can be reasonably assured that it came from the real doctor (as opposed to an impersonator). How one determines whether a particular AMA certificate correlates with a transaction identified by National Provider ID or proprietary payer-assigned ID is another matter - the devil's in the details!

We mustn't lose sight of the role security (and PKI) plays in all of the recommendations we come up with. Even if Kepa's DNS "directory" works flawlessly and effortlessly for locating EDI Trading Partner information given an identifier, it's all for naught if any 13-year old in his bedroom can impersonate a provider (or a payer). The last thing we would want to see is Harry Hacker pretending to be Highmark by commandeering Kepa's DNS node 54771.NAIC.HIPAA.NET: every provider relying on the DNS "directory" wanting to send claims to Highmark could have them intercepted by the hacker if a PKI is not in place!

The ebXML initiative has looked at quite a few of the security aspects of maintaining a reliable Registry and Repository (for containing CPPs - the ebXML version of an Electronic Trading Partner Agreement). See https://www.oasis-open.org/committees/regrep/. Frankly, I think Kepa's DNS "directory" scheme is considerably less bloated than ebXML's effort, and can be implemented today within the HIPAA community. Having said that, maybe it's still worthwhile to look at the ebXML RegRep to see if there's something we can use or learn from.

Digital signatures require digital IDs or certificates which have themselves been signed by a trusted third party - a "Certificate Authority," or CA. Ronald Bowron pointed us last Friday to an example of such a CA, Verisign, who was collaborating with the AMA to certify providers' digital certificates. Presumably, the AMA is the expert in identifying doctors, so this certificate authorization model makes sense on the surface.

The Thawte notary model that Ronald asked about has the same weaknesses that any certification service has which is based on in-person presentation of credentials: those credentials are easily counterfeited. For example, the Thawte notaries rely on in-person presentation of a driver's license. I guess it kind of gives you some low-level assurance that an e-mail persona is possibly someone named on the driver's license - and that may be good enough in most cases. You have to ascertain the level of risk you're willing to bear relying on certificates backed by state-issued drivers licenses.

The Verisign EDI Digital certificates go a little further, in that Verisign vets the submitted information, such as company name, against Dun & Bradstreet reports and kind of makes sure the applicant really is with the organization he purports to be with. This service costs nearly $1000. Is that good enough for a payer to rely on for validating the identity of a provider submitting claims? Maybe yes, when combined with procedures where checks are mailed only to the address on file for participating providers, or to the subscriber for out-of-network claims.

In any event, the methodology - however imperfect - already exists for "verifying the identity of a CE as part of the TPA process." Our proposed system might be able to rely on CA-issued certificates which contain the entity identifiers being authenticated; I think it is out of scope for our group to worry about how those entities are authenticated (by the CA) in the first place.

CA-issued certificates should be sufficient for automating the TPA process. The process for obtaining a certificate is not entirely onerous on an entity, especially considering it only has to have *one* digital certificate for trading with *all* potential partners - unlike the horrible burden placed on it if separate paper TPAs have to be negotiated with each and every individual trading partner.

For some useful background on Heathcare PKIs, please see stuff about the AFEHCT/WEDi Healthcare Internet Security Interoperability Pilot at http://www.afehct.org/security.asp, and PKI in Healthcare at http://www.healthkey.org/library.htm.

One key issue mentioned in the note is sender authentication. The concept implied in the note is that the payer and provider set everything up in advance and establish a means of identifying themselves. That is, they exchange bilateral keys, usually only a log-in and password, possibly accompanied by a particular payer's script. Another means is to use the services of a middle party such as a clearinghouse or switch that establishes identities. But entity authentication in the future can be accomplished with more modern means that do not require the overhead of prior bilateral setup or switches. All payers - not just Blues - are concerned that they can be assured they're dealing only with the "Real McCoy." Identification, based on X.509 certificates, buttresses our entire model. If I'm not mistaken, Denial of Service (DoS) attacks are often targeted at the protocol layer: an attacker only needs the IP address of the "mark" - logon IDs and passwords aren't necessary to commence a DoS attack. I guess a payer might therefore want to keep his portal's IP address or URL a "secret," but how long can you hide this kind of stuff from a hacker? There are technical solutions to thwarting DoS attacks, but they are out of scope for our project. It's incumbent upon the payer's network administration staff to solve this problem using existing methods and technologies. The solution is not to place barriers in front of providers, forcing them to go through onerous EDI enrollment processes just so they can submit a HIPAA standard transaction.

When designing the automated Healthcare Registry for electronic partner profiles, we can address fraud only insofar as we can guarantee identity through the use of X.509 technology and CA-signed digital certificates. We can only assure folks that only the entity which "owns" a particular ID (e.g., a NAIC company code, Tax ID or National Provider ID) can create the CPP (electronic partner profile) which purportedly belongs to it. I addressed this issue in Re: Updated CPP Spreadsheet and Model Diagram, at http://www.mail-archive.com/[email protected]/msg00575.html.

Re: Fraud and Trust. We can't address fraud, except insofar as we can guarantee (through X.509 technology and CA-signed digital certificates) that only the entity which owns a particular ID (e.g., a NAIC co-code) can create the CPP which purportedly belongs to it. Once you are sure that you have a CPP really belonging to Saint Therese Hospital in Waukegan, our job is done. If Saint Therese Hospital's lack of internal controls result in false or over-billings, or the Insurance company lacks the controls to detect fraud, it's not our problem. All a payer could be reasonably sure of is that the 837 claims indeed came from Saint Therese Hospital, and that remittances, statuses and payments actually are returned to Saint Therese Hospital.

Likewise, hospitals would be sure that whomever they sent 837s to really was the payer they intended - as long as they used the correct ID to obtain the CPP. Valid digital signatures of incoming claims would indicate that the payer could trust the claim was coming from whom they thought - not that they can necessarily trust the sending entity itself. We can only guarantee identity on the Internet, not honesty or financial robustness. Since we're going to use X.509 digital certificates to buttress our trust model, we're dependent on the Trusted third-party CAs (such as Verisign) to properly vet entities.

If out-of-network providers send standard transaction claims to a payer, I would expect that electronic EOBs would be sent to the provider, and that paper EOBs and a check would be sent to the patient. It only makes sense to send payment to the patient, since in this case the payer only has a contract with the patient - not the provider. Actually, you would think that it would be prudent for the payer to always send some type of paper EOB to the patient, in or out of network, to increase the odds that funny business will be caught. Given the paper EOB, a patient treated in-network might have an incentive to report provider over-billing simply because it applies to his lifetime max.

I don't know how you could keep a provider from submitting an out-of-network over-billing to the payer (which would only benefit the patient since she receives the check). It's not my problem - I'm not paid to worry about it. But standard electronic transactions don't exacerbate the problem: these are probably also concerns when using the old HCFA paper form for out-of-network claims.

So, much like the Public Trust model discussed in another thread, when does one consider a business entity a trusted entity? How do you determine whether or not payment is valid?

In the old days, when a patient was "Out of Network", the physician simply billed the patient. It was the patients responsibility to forward the claim to the payer (this is still used today, my dentists bills this way). The payer then knows that the patient actually did visit the physician and received the services. With the CPP, does this become an automated process? What roll will the patient play, if any, to ensure the claim is sent to the proper insurance plan for payment? How does the Insurance Plan verify that the patient actually received the billed services?

When using X12.58 security services, authentication and encryption are done only at the Functional Group (GS/GE envelope) and Transaction Set (ST/SE envelope) levels - the ISA is kept in the clear so intermediaries know where to send the interchange. Note that X12.58 has NOT been addressed in HIPAA at all. If accepted by the payer's translator that would be great - but so far we can't assume either mandated use or acceptance of X12.58.

EDIINT, on the other hand, *does* encrypt the entire EDI Interchange - including the envelope headers (ISA/IEA) - when encryption security services are applied. Since the routing of the EDI Interchange is point-to-point through the Internet, and not via a VAN or Clearinghouse, the sender/receiver ids are not used in routing so no intermediaries (there are none!) need to see the ISA. By the time an EDIINT package encrypts the interchange, it has already gone through all the rigmarole Kepa proposes and has the final destination address available for the SMTP routing or HTTP post.

Certification Payers can require providers systems be certified. They can make this a condition of participating in the payer's provider network. HIPAA doesn't prohibit this. Requiring is also good business sense.

Your assumption that payers cannot require providers' systems to be certified is just plain invalid.

This just serves to remind me that we need to discuss supporting HIPAA transaction certification in the Healthcare CPP. I definitely think certification can be of real value, but I guess I just want to ensure that certification is not used as an excuse by payers to put even more hurdles in the way of providers, causing unnecessary manual intervention or creating onerous enrollment requirements. If certification credentialization can be automated - i.e., the third-party certification service could digitally "sign" the credentials in the party's CPP (electronic trading partner profile), which could be examined automatically - then I might be a lot less concerned. Remember: eliminating all friction points which have to handled manually - with pairwise negotiation - is one of our biggest problems to solve!

I would like to ask the folks writing the working paper describing the Elements of a Healthcare Collaboration-Protocol Profile (CPP) - Marcelee Jackson (who may not even know she was "volunteered" to work on this since she was absent from the Friday, 08 March teleconference), Dave Minch, Dick Brooks and Chris Feahr - to add certification credential verification to their list of requirements.

I'm of the (perhaps minority) opinion that payers can't mandate certification of providers: if a standard claim comes into a payer, I can't help but think Administrative Simplification requires the payer to take it into adjudication. Testing is obviously important (for anyone with sense) - and I can see where not only does a payer want to ensure all his systems are "go," but would like to be "certified" to cover his "behind" in case a provider claims they tried to send standard transactions which were rejected out-of-hand by him.

I don't expect providers have the same fear instilled - the worst that will happen to them is to have non-compliant standard transactions rejected, which they can then fix up and re-submit. It's not, like, y'know, a payer is going to stand up and complain to the government that this wretched little provider is screwing up in every way asking for his money! Nobody says the health plan has to "debug" the provider's non-compliant transactions: all the 997 has to do is report the first X12 syntax error encountered and reject the entire transaction set, or all the 824 (when we get one) has to do is report the first problem inconsistent with HIPAA, and refuse the transaction. There should be no back and forth "debugging" (on the phone), as long as the 997 and 824 are used correctly.

Certification. "Certification," as we use it in WEDI/SNIP, is defined in the Testing ("Transaction Compliance and Certification") whitepaper. It only "certifies" that an entity is capable of sending (or receiving?) syntactically and semantically correct standard transactions.

The second key issue is credentialing of trading partners. I don't think we are intending the CPP to get into that territory. But just as smaller payers now use services to assist them, there might develop more widespread third party credentialing, for example, a signed certificate on the CPP or other registry by a trusted third party that the entity is in fact a good citizen doctor, licensed and all that. Such certificates are not guarantees but certification that certain documentation was attested to, for which there are fraud laws and other protections. I don't know, but I would not be surprised if the credentialing now being done, except by larger payers, is possibly a little lower quality than folks like to think. There may well be room for improvement.

The note includes "nor have I tested to ensure your data". I believe that third party transaction certification beats individual testing all to pieces. That is the substance of my paper "ROI: Economics of Transaction Certification", which I'll send to anyone who would like it. The idea is that a trusted certificate by a professional firm is posted to a directory for access by trading partners.

With regards to "Certification". "Certification" will not guarantee that the transactions are not fraudulent, only that they are properly formatted and contain valid content based on the standards. Not that the content is appropriate for payment.

I have to agree with Rachel. Nothing in the regulation prohibits requiring a trading partner to prove that he or she is capable of sending a compliant transaction.

It was mentioned below that Payers are permitted to test with providers. We view certification as an initial step in testing. If a provider cannot show evidence of certification and we test with them, then past history shows that we will spend a lot of time and effort to help the provider debug their program. Our position is that the provider should offer some evidence that they have a compliant transaction before we commit the resources necessary to perform testing.

Also, keep in mind the current level and nature of dialogue between providers and payers. Providers are very shrill in criticizing carriers for claim payment processing -- even to the point that they are launching class action lawsuits, filing complaints with regulators, and seeking new laws and regulations. I suspect payers are going to want to insist that providers are capable of sending truly compliant claims so that the money payers are investing in becoming HIPAA compliant results in the efficiencies we are seeking. Otherwise, if the transactions just result in more bad claims coming in faster, it will exacerbate not reduce the current tensions.

Trading Partner Agreements 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?

Our legal area is not on the same page with the people that say we can do business without an agreement between the provider and the payer. In fact, this is a topic that has had EXTENSIVE debate here. The reigning opinion is that HIPAA will be forcing all payers toward agreements with the provider, not eliminate them.

What I (and others) have been advocating here is that there is a need for only two authorizations from the provider. One as a general trading partner to cover legal and other issues for all transactions except the 835, and a separate contact for authorization for the 835 (this does not necessarily mean a hardcopy document). There are people (legal types mostly) that want separate authorization for each transaction.

An initial authorization is necessary to start the relationship. That will include an agreement and reference guide that identifies all items about the payer that are allowed by section 1.1.1 of the HIPAA guides. At that point, all of the HIPAA transactions to date except the 835 are provider initiated. If the provider sends 837s, then the provider wants to do claims. So, once the electronic relationship is setup, the use of the transaction identifies the request to use the transaction.

The 835 is payer initiated, but only at the request of the provider. To send it out automatically would not be appropriate. The provider can even want the 835 without sending an 837, so we don't have any 'trigger' except the provider's request for the 835. Since the 835 route to the provider is not a given (it could be a bank that does dollars to data reconciliation for the provider), only the provider can tell the payer where the 835 should be sent.

On the other hand, I do wish to point out that when the federal government, most notably the Department of Defense, went full bore into EDI in the early to mid 1990's they initially required that each supplier to the government execute an EDI trading partner agreement. This was a huge failure and in fact, became a major barrier for getting the hundreds of thousands of suppliers willing to engage in EDI with the feds. Within 6 months the feds abandoned the requirement for an EDI trading partner agreement. Other industries also recognized the barrier an EDI trading partner agreement became when trying to establish EDI information exchanges. So, I would just urge health care to not rush into a business model that clearly didn't work for other industries, including our beloved federal government, without fully examining and understanding the impact and issues that will result....this is a prime example of beware of unintended results! I can vouch for Kepa's comment regarding many payers. We are a relatively small Health System, but we have over 2000 payers in the insurance table of our largest provider. Even if I assume that each company has at least 1 alias, that still leaves over 1000 profiles. That means if I want to send directly to each payer, I need to negotiate 1000 TPAs, perform 1000 tests, set up 1000 trading profiles, and implement however many unique transports to deliver the claim payloads to the "first hop" recipients. And I'm just 1 provider (well, actually 15) -- think of how many of us are going to be knocking at the payer's doors. Are you guys ready???

Then I shall simply pray a whole lot that if any one of the links in this frighteningly fragile chain of mail carriers decides to change transports, methods, passwords, encrypting, etc. that they give us good advance notification, and that the information they communicate is accurate, and that they don't decide to change things at the last minute..... Mess?? you got that right!

Lets see.... If I can average 3TPAs per day, and get them all set up for testing it should only take me 15 months to get all 1000 ready by 4/16/03. I guess I can just make it if I start tomorrow... Does any of this sound as absurd to anyone else as it does to me?????

"[if] HIPAA will end up forcing agreements between each provider and its payers, then the questions about who should be identified on the ISA becomes moot." There would be no point in us spending our time figuring out automated ways to share trading partner information (such as electronic addresses) if paper TPAs were required: this information (the ISA Identifiers and the electronic addresses) could just be placed on the same (expensive) piece of paper.

The issue of Trading Partner Agreements arose in the Business Issues Teleconference yesterday. Discussion led me to believe that it's still unclear whether paper Trading Partner Agreements will be needed or desirable under HIPAA. For background, you should definitely look at the WEDi document "Trading Partner Agreements: A White Paper Describing the Business Issues and Recommended Solutions Associated with Trading Partner Agreements," by Doug Renshaw. It's available under "Transactions Workgroup White Papers" at the WEDi/SNIP site at http://snip.wedi.org/public/articles/Trading113000.pdf.

The topic came up because one of the callers wanted to know how - other than by using a TPA - a sponsor (employer) would know whether to send to the payer a full compilation of enrollees, vs. just the changes since they last "talked." Other things a TPA might be required to resolve are the situations (as in "situational") where data is expected or desired. Fortunately, there seemed to be nothing in the discussion of a legal nature - i.e., everything was technical, which means a mechanical or electronic Trading Partner Agreement might suffice.

Besides these issues the caller brought up, I wanted to see what Doug and his team came up with. His document is an excellent compendium of the situations calling for agreement ahead of time. But, fortunately, I saw nothing which could not be mechanized! Though he had the usual stuff like specifying communication protocols, Clearinghouse designations, and agreements on maximum numbers of claims (e.g., 5000 claims in the 837), he mentioned nothing that would require Lawyer Man to get in the way of real business.

I probably can't emphasize enough how paper TPAs will gum up the works in automated partner recruitment - to the point where our work in the WEDi/SNIP ID & Routing Special Interest Group might be rendered moot. What's the point of automated "discovery" of trading partner technical requirements (communications and protocols) if that stuff may as well travel with the paper TPA? Marcallee Jackson has confirmed that signed paper TPAs would involve so much overhead that they "will cause the labor costs associated with EDI enrollment to sky rocket." Rachel Foerster has also related the story of the (bad) experience with TPAs when required by the Federal Government.

Even though we have sub-projects for looking seriously at the ebXML CPP (basically a mechanical Trading Partner Agreement or Profile) and the 838 - led by Dick Brooks and Dave Minch, resp. - I'm suggesting that we move the concept of Electronic Trading Partner Agreements to the front-burner. If we can mechanically represent in them everything Doug has enumerated in the white paper, we'll be better prepared to fight the conservative tendency to require paper TPAs.

Electronic Trading Partner Agreements fit into our scheme quite elegantly, in that Kepa's DNS "directory" would be used to find a trading partner's profile based on identifier. The profile itself would, in addition to the stuff mentioned in the white paper, have the technical routing information for interchanges. In effect, you'd be "discovering" electronic trading partner agreements, not "inboxes," "portals," or "front doors."

EDI enrolment Today providers who use a CH complete 3 - 5 TPA/Enrollment forms - Medicare, Medicaid, BCBS and Champus are payers that almost always require agreements. In my experience it takes an average of 2 - 3 weeks for a CH to receive completed paperwork from the provider and an additional 6 - 8 weeks for approval from the payer (though BCBS often approves in 2 - 3). It takes providers as long to complete their part of the enrollment paper work for these payers as it does for most to complete testing, implementation, training and full production for payers who don't require it. That's if the enrollment process goes well.

Many payers are very particular when it comes to their agreements. Some require the signature of every physician in a group (imagine that if you have 50+ physicians), most require a listing of every group number and provider ID, some require social security numbers, some that the agreement be sent in on a particular color of paper, others that only a particular color of ink may be used and most will reject the agreement for any error. Each agreement is proprietary. It often takes 2 or more attempts before the provider gets it right. The whole process is an incredible hassle.

In other situations, the payer does not require a written agreement between the provider and payer but does require the CH to obtain authorization. This process, while still time consuming, is far easier than the one described above.

I am strongly in support of TPA's combined with COT's and entered into only by the parties directly exchanging data. It also seems that some sort of power of attorney between the provider and CH should be sufficient to allow the CH to auto-enroll its clients with the payer, particularly for the simple exchange of data. More complicated data exchanges, such as EFT or split routing, may require a more manual process but those exchanges are not common today and not likely to be in the near future. I stress that the vast majority of payers today do not require any TPA or enrollment process between themselves and physicians who bill through a CH. These include payers such as Aetna, Cigna, United Healthcare, Coventry Healthcare, Humana and Prudential. I'd suggest we look at their current model and find ways to keep it.

AFEHCT is very interested in this issue and I believe is also planning on a work group.

1. Electronic TPAs - machine readable documents that outline information proprietary to the payer; e.g., information on routing and information related to proprietary requirements for HIPAA transactions (stuff that would normally be part of a companion guide).

2. EDI Enrollment - This is a process today that requires the provider to sign an EDI agreement before exchanging transactions. This is a time consuming process and a barrier to fuller utilization of EDI. It's of particular concern to providers and clearinghouses since many health plans seem to be planning on this same requirement which could dramatically impact cost and timelines to implementation. Among other payers, every Medicare intermediary requires this process today. The primary question would be - is this legal post HIPAA? If yes, then the second issue and third topic here would be:

3. An EDI Power of Attorney - This would allow a provider to assign their clearinghouse power to enroll them with other trading partners (clearinghouses, payers, etc) for the purpose of exchanging healthcare transactions. 2. But since then, Marcallee has certainly convinced me that if the TPA "problem" cannot be gotten out of the way, then automated trading partner "discovery" has less value. As far as I know, we are the only WEDI/SNIP group worried about this issue - the impediment of paper TPAs - at the moment.

If in their wisdom, the Business Issues SWG management finds it prudent to create a new group concerned with ways to lubricate healthcare e-commerce by eliminating or ameliorating the delays in trading imposed by paper TPAs, we in the WEDi/SNIP ID & Routing SIG will defer to that decision. In the meantime, I'm only too happy to see Dave and Marcallee succeed in developing a Clearinghouse Power of Attorney or the "WEDI Accord on TPAs" - if only to prove my good friend, Kepa Zubeldia, wrong for once in his life! We wanted to let you know that some progress is being made on the trading partner agreement front concerning the legal ramifications of creation of an entirely electronic eTPA. Yesterday William Kammerer, Marcallee Jackson, and I held a conference call with 3 legal types from the law firm of Davis, Wright, Tremaine (DWT), who have volunteered to provide some level of assistance to us pro bono as we wrestle with the non-technical privacy, security, and fraud-potential issues surrounding creation of an automated eTPA.

The question posed to the teleconference group was "how can DWT work with our WEDI-SNIP workgroup"? We discussed our plans to move the industry toward an "electronic TPA" rather than (in place of) signed paper agreements. The TPA we have envisioned includes technical communication protocols, security and encryption, and potentially even the "companion guide" type of information - all of that being generally classified as the "technical" business arrangement between the trading parties. Our most pressing concern is: even if we can get all of the nuances of the "technical" business arrangement included within our electronic definition, will there still be overriding legal barriers which will still require each trading partner to negotiate and sign a paper document to comply with the HIPAA regulations.

DWT explained how business agreements can be implied under the UCC. As a simple example, when a customer sends an unsolicited order to a supplier, and the supplier fills the order, there is an implied business agreement under the UCC. DWT also indicated that there is now an extension to the UCC which is being adopted in most states that specifically addresses electronic business exchanges. After some discussion, their suggestion was that if we could promote a health care industry-wide accord, that it could act as an anchor point for creation of the compliance portion of the paperless interchange agreement and would embody language which safeguards the participants.

Our next steps will be to work with DWT in drafting a "talking paper" over the next 3 weeks which lists some of the key elements that such an accord would have, and how the accord would be used in conjunction with the UCC to satisfy the regulatory needs (privacy/disclosure of PHI). Stay tuned...

Regarding your question: "what will a provider do to get transactions to Highmark when he is fully HIPAA capable and doesn't want to pay the freight (of a Clearinghouse)?"

We welcome providers or their billing agents to submit claims to us direct. We assign them an EDI Trading Partner number (proprietary number) and give them instructions on how to dial in to our EDI interface. This is how we connect today; I am not advocating our process as the best mechanism for the industry moving forward.

Requiring prior setup excludes the more occasional trading partner. There are reasonable conditions in which a payer could agree to accept a claim or other transaction from an infrequent provider, provided the technical means for doing so is less hassle.

Q. What do you think about onerous EDI enrollment processes and "certification"? Don't you want all these artificial barriers put up by the payers removed?"

A: You can bet that I don't like it one bit. Remember, I have 16 different entities who send bills, and two entities who receive them. Multiply 16 times the 500+ payers we correspond with and you can understand the problem (technically, all entities don't deal with all of the payers, but the subsets are large enough!).

Now the other side of my equation is that I receive claims (i & p) into two of my entities (including receiving them from my own senders). As a receiver, I have to ask myself, how much time do I want to spend dealing with paper TPAs and cert testing before allowing a provider to send x12s? The tradeoff is posting my CPP and letting claims flow in, and reject any that aren't HIPAA compliant. Since my chosen software can do a complete HIPAA check (similar to what our friends over at Claredi do), I'm banking on the fact that i'll spend a whole lot less time in auto-rejecting malformed batches/claims, and misdirected claims than if I did the manual TPAs & testing. The one caveat is that i'd like to have my TPs certify with an outside agency such as Claredi before they start sending to me (less rejection processing if they get their act cleaned up ahead of time). We should be able to incorporate a cert_id into the CPP/A. His point may be that since a known (or participating) provider will have gone through a vetting process - and signed all sorts of papers - that adding a few more pieces of paper related to electronic claims submissions isn't that burdensome. Compare this to Marcallee Jackson's comments from 23 January on EDI enrollment, where she inveighs against the practice of having providers enter into a "proprietary individual TPA with every payer with which it might ever need to exchange a transaction."

Our whole project here is predicated on some assumptions: viz., that 1) onerous setup and EDI enrollment is a real problem, 2) it can be automated, and 3) the solution is secure. Even though it may not be a critical factor - in that who wouldn't prefer an EDI enrollment process that was automated, secure, and needless to say, inexpensive? - the HIPAA law could be read in such a way that onerous (i.e., manual) EDI enrollment is an impediment to Administrative Simplification. My opinion is that if a payer would accept for processing a paper claim (payable to either the provider or subscriber), it must take the equivalent standard transaction set. And just as importantly, it must provide a non-discriminatory "portal" for exchanging standard transactions.

What we definitely wish to avoid, I believe, are onerous EDI enrollment procedures, negotiated TPAs, and other sundry hurdles and hoops placed in the way of providers who merely want to use the standard transaction sets. Not only are these processes exceedingly manual, but they may take months to consummate (per Marcallee Jackson) - surely an impediment to frictionless e-commerce if there ever was one!

Doug Renshaw, of Highmark, said yesterday "We welcome providers or their billing agents to submit claims to us direct. We assign them an EDI Trading Partner number (proprietary number) and give them instructions on how to dial in to our EDI interface. This is how we connect today." Fortunately, he adds: "I am not advocating our process as the best mechanism for the industry moving forward."

A common case will involve claims coming in from one of a payer's participating providers who has never used EDI before. Remember, HIPAA says you have to take their claim if presented in a standard electronic format - and that presumably means without placing any onerous hoops to jump through, such as TPAs, EDI enrollment, or waiting around for payer-assigned IDs, logon IDs and passwords. Less common would be a claim from a non-par provider, who wants to send a claim to be paid to the patient (who does have a contract with the payer) - one with whom the payer has absolutely no leverage and to whom the payer *must* provide a means of submitting standard transactions electronically.

EFT Re: Sharing financial information like routing codes and account numbers. Providers who have set up debit blocks, as NACHA's Priscilla Holland talked about, could safely place their account information in the CPP; see "Electronic Funds Transfer and Security" at http://www.mail-archive.com/[email protected]/msg00570.html, Others will probably have no choice but to use some kind of notation to indicate where a payer could obtain that information, e.g., an e-mail address or telephone number - necessarily involving a manual process. Even if we had a fool-proof method of protecting the registry from read access except by "vetted" participants, most people (providers) would still feel uncomfortable sharing that information.

I don't know any way around that issue! Except if, as I suggested, the 837 were changed to include it so it could be sent directly from the provider to the payer (encrypted or over a secure channel). A REF segment, in the Pay-to or Billing Provider loop, can handle this. The following says, in effect, bank account number 26000001538215 at Fidelity Federal Bank & Trust of West Palm Beach, Florida (ABA No. 267087358):

REF*11*26000001538215**01:267087358~

Some people wouldn't even like that (i.e., the provider giving the EFT information directly to the payer via the claim). Bruce T LeGrand, my "Deep Throat" Blue contact, says:

My EDI portal is not secure. Since I support dial-up, NDM, FTP, ...... ad nauseam ad infinitum, my process is fairly open. And I don't care. If a provider identifies himself to me properly in a claim, there is no way anyone can spoof me into sending the payment somewhere it is not supposed to go. I verified that initially with him and that data is secure within my system. If it comes in the claim, it can go anywhere. This is not a secure network like the banks have, and I don't see any reason why we should incur the costs of that on top of everything else. When I move money, it will be the bank portals that service that transaction.

Thanks very much for this information about the banking world... as unsettling as it is. It may turn out that other CPP information about payors and providers will have to be semi-restricted as well. I noticed, for example, that some Claredi customers have chosen to restrict public access to some of their directory fields, even though the information looks pretty harmless to me. Of course, the whole point of our CPP record is to make it widely available... but to one's potential partners... not necessarily to one's "competition"... and maybe not very much of it in one query, no matter who you are. I would expect payments in most low-volume or CPP-initiated trading relationships to continue to be paper checks for the next few years... mailed to the address in the CPP record. In the hi-volume relationships, it will probably be necessary to send a voided paper check, sign a few forms, etc. in order to set up a direct-deposit, electronic payment arrangement anyway. So all we may need in the CPP record now is a place to indicate preferences/abilities with respect to electronic payments. I think this settles the matter, though it's disappointing that banking account "security" relies on keeping these identifiers semi-secret.

Perhaps we can accommodate protection of the financial account information in the directory some technical way to ensure it is revealed only to legitimate payers (insurance companies) - by restricting it to only those folks who possess a directory entry themselves or somesuch nonsense. Or the 837 claim could be changed to send the provider's routing and account numbers for EFT payments directly to the payer (I was surprised it wasn't there already), bypassing the Healthcare CPP directory altogether.

CPP CPP is a Collaboration Protocol Profile CPA is a Collaboration Protocol Agreement

Companies define their E-Commerce capabilities and operational parameters in a CPP. When two companies want to setup a trading relationship they exchange CPP's. If there is a match in capabilities then the two parties agree to form a CPA which describes how they've agreed to conduct E-business. A CPP typically has contact information, EDI addresses/identifiers and other information. I like to think of the CPA as the intersection between two CPP's.

The CPP/CPA is all about the rules of electronic engagement between two trading partners, with the CPP describing what you are capable of doing and the CPA being an "agreement" between two entities regarding what they **will** do.

For any who have attempted to wade through the CPP/A Specification (are you listening, Chris Feahr?), it does seem daunting (at least to me). But more likely than not, Dick and Dale will probably figure out some way to use the CPP as a "template" just like what was done in the Open Travel Alliance, where we "hang" our stuff off of it. Even if we just use one or two parts from the CPP (such as the Delivery Channel stuff - which is an XML'ized means of expressing Peter Barry's "EDI addresses"), and design XML schemas for documents we refer to from the CPP, both of our groups will have a "victory" that can fuel many a press release.

There is indeed "versioning" in the CPP - that for the CPP schema itself (i.e., the version of the OASIS CPP specification), and for other related OASIS specifications. But I'm not sure whether there's also a capability to "version" the "instance" of the CPP, though. In any event, it's a real requirement for us to have some mechanism to tell whether the CPP electronic partner profile has changed at all.

I don't envy you reading all that OASIS stuff! I might warn you, though: when you read up on the ebXML CPP, it looks big, ugly and complex - and most of that stuff is irrelevant to traditional EDI. Actually we might end up using only two or three things from the existing CPP schema (e.g., Delivery Channel, Certificate Management, Party Definition), and be off on our own devising a (general-purpose) legacy EDI extension.

I would suggest putting aside the OASIS ebXML CPP specification. I think it will only confuse us for now. We really need to build our own requirements based on *our* needs - including everything we'd want to see in a partner profile if we were starting from scratch. It can be organized any way (UML diagram, spreadsheet, Access Database) that floats your boat. Then we can take that list and give it to the OASIS CPP/A group and let them help us to retrofit the existing CPP to allow for "legacy" EDI extensions. We might have to "educate" the OASIS CPP/A group on "legacy" EDI and Healthcare Transactions so they see just how this old message-centric stuff works!

Dick Brooks and I joined the OASIS CPP/A group on a teleconference call last Tuesday to apprise them of our status. I think we're on the same wavelength, in that we agree much of our EDI partner profile stuff will be in an XML document of our own schema design, XLINK'ed from the main CPP. Our stuff will eventually turn into the OASIS ebXML "legacy" EDI CPP extension schema. I may have forgotten to confirm with Dale Moberg, Chair of the OASIS CPP/A Technical Committee, but I believe that WEDI/SNIP is the first group in the world attempting to make ebXML work with "legacy" EDI. Given that HIPAA transactions are X12 only I would suggest that this group elect to use a "file transfer" business process for exchanging HIPAA transactions and avoid the complexities of the "deeper" business processes (Claim/enrollment business processes within the CPP).

A lot of this security and certificate stuff is already in the ebXML CPP, though I don't know how inextricably it's tied into the business process or transport mechanisms - neither of which we'll probably be using in our recommendations, unless we come up with a default "legacy" EDI business process.

In the matrix Chris developed for the Elements of the Healthcare Collaboration-Protocol Profile, please distinguish between stuff which is native to ebXML (I suspect this includes certificate handling) and that stuff which is completely new and not thought of by the ebXML people. We'll have to have some organized manner, perhaps in the form of a "subsidiary" schema, to give the OASIS ebXML Technical Committee to show our new elements which pertain to Healthcare EDI.

Actually, is there any possibility that our "kind" of stuff (e.g., which transactions are supported, with their start dates) is more properly part of a Business Process rather than an ebXML CPP? If so, then we might also have to "liase" with the UN/CEFACT ebTWG eBusiness Transition Working Group, at http://www.ebtwg.org/ - providing yet another opportunity for "volunteers" who are looking for work to do.

Funny you should mention that. This is exactly what we did in the Open Travel Alliance B2B specification (http://www.opentravel.org/. I'm currently working on an Energy Industry specification that *automates* trading partner setup through the exchange of "profile documents".. the CPP is simply an instrument to create the CPA - which is the electronic equivalent of the trading partner agreement.

I would certainly agree with all of the payer comments regarding trade with "unknowns", but the CPP exchange is our electronic (but certainly applies to semi- or even non-electronic) equivalent to "discover" information about the prospective trade partner. In my second paragraph of the "Conceptual Schematic" paper I state:

"The data sets to be communicated should be comprehensive enough to allow for a fully mechanized (no human) interaction, but the communication of such information does not necessarily have to be in a single transaction. In other words, exchange of all data necessary for loading trading partner tables and initiating EDI trade can be in multiple exchanges. The first exchange to identify and gather basic information, and a second and third more secure exchange to provide sensitive information which is not meant for display in a public setting."

I would further emphasize that if we assume for the moment that all data and signatures needed to create a physical TPA can be "computerized", then the CPP, even if printed out and snail-mailed back & forth can constitute creation of a trade agreement. We definitely need to realize that most of us will need transition time between the ultimate electronic future and where we are today (which is with a file cabinet full of paper agreements). The transition will be gradual as many people have observed, but we still have to paint the target to shoot at.

I propose that we take the conceptual model that we are working out, and apply it to a few real TPAs to fill the gaps. Then have all of you out there with TPAs do the same. When we are done, we should have a pretty comprehensive list of elements, and a pretty sound structure from which to build.

In the future state, when a transaction arrives from an unknown, the unknown's CPP can be accessed as a first step, and a CPP exchange can ensue (whether automated or manual or somewhere in-between, as internal company policies dictate). Through that process, the prospective trading partners may discover that they really don't want to do EDI. That's OK. But the legitimate providers & plans who do conform to the CPP standard & protocol - even if in a manual process - will have a much simpler way of consummating an agreement and beginning EDI.

History Thanks. I stand corrected and also heartened to know that the X12 838 did inform the work of the CPP/A effort. I remember the years (yes, years!) of debate and rancor that the development of the 838 went through. It was one of the most emotional and controversial efforts of X12 before Y2K hit us! Dave did compile trading partner data attributes, and provided a synopsis on the listserve. He was unable to really map to the 838, which we needed to know so we could honestly say we considered the 838 - we tried to eat our own EDI "dog food" and found it wanting! The matrix Dave shows will probably be useful to you in devising your CPP elements to describe partner capabilities.

Design suggest that the CPP elements be designed in a more general fashion. For example, instead of a number of elements like "ExpectedTestDate837I," "ExpectedTestDate837P," "ExpectedTestDate837D" and "ExpectedTestDate270," perhaps an overloaded "ExpectedTestDate" element might do the trick where the functional group (e.g., 004010X098 for the 837P) is specified as an attribute or subordinate element. This would better accommodate mechanical processing of the XML elements in the CPP, and further, make our CPP generally applicable to all "legacy" EDI as opposed to simply Healthcare.

Until translators are CPP enabled - i.e, they can update their trading partner tables with information from the CPP which has been automatically "discovered" - the sender can manually lookup the CPP and update his own trading partner files. I don't think that's particularly onerous, and he can do it all by himself. Having it automatically done by the translator is just icing on the cake.

Transaction Support Every health plan, if it does electronic transactions at all, will be required by HIPAA to support the 835 - both the Health care payment and the remittance advice. So every payer, after H-Day, which uses the Healthcare CPP and Registry (implying it is EDI capable) will have some kind of notation in its CPP (electronic partner profile) saying it supports not only both forms of the 835, but also all of the other HIPAA standard transactions applicable to their business.

The more variable side is that of the provider: generally it's optional for her to support the HIPAA standard transactions. She may support the inbound 271 and outbound 270 and 837, but prefers paper remittances and checks. It's problematical whether she really has to announce in her CPP that she sends 837s: the payer will know that when it receives one from her! But the payer does have to know which standard transactions the provider can accept; silence on the 835 would imply she doesn't support the 835 remittance. Now even though she doesn't take 835 EOBs, the provider may very well want to be paid electronically through her bank: our CPP extensions have to support some way of saying EFT payments are accepted, specifying her bank routing code and account number. it seems to me after re-reading the 837i IG that while we can make the recommendations regarding use of the GS for routing, this, also, is in the domain of the quasi-automated TPA, and can easily be accommodated by the CPP, even if the CPP for some payers ends up being a .txt file emailed to a requesting provider (i'm not advocating that approach, just recognizing that it will most likely be an evolutionary step toward the goal). Once the provider receives the CPP, whether emailed or picked up from the payer's registration, the next step may well be manual update of the trading partner configuration in the provider's software.

Business Processes I'll warn you, though, that there probably isn't too much in the CPP/A specification that we can use directly "out of the box" - most of the baggage in there is to support Business Processes and Messaging Services, with nothing at all practically for "legacy" EDI support. That's where we come in: as far as I know, we're the only folks who are working to make the CPP support traditional EDI in a first-class way. Except for the DeliveryChannel stuff in the CPP, you may be on your own for defining partner capabilities as they apply to EDI.

I propose that we learn to walk first by defining a simple "file exchange" business process that will allow organizations to exchange HIPAA compliant transaction files (per one of my earlier e-mails). There is nothing to prevent implementers from evolving their systems to become more integral with actual business processes (e.g. real time enrollments) in the future, but this is much more challenging achievement.

Any kind of "response timing" would probably apply at the transport layer. Though some kind of service level agreement for application transaction set processing would be nice - guaranteeing that real-time 270s are turned around with a 271 within 2 minutes, or that a claim will be processed and definitively rejected or accepted within 24 hours - I don't see the need for it right now to be specified in the CPP. I do think it would be reasonable to have a specification which says TA1 and 997s will be returned in a certain period of time. But as long as providers can query on the status of claims with the 276, or payers can keep them "posted" with the unsolicited 277, application response timing is overkill.

Application level things like "timeToPerform" in the ebXML CPP pertain to Business Processes, but I really don't think we're going to be able to apply more than the most rudimentary "default" business process to primitive "legacy" EDI messaging. Actually, I really have no problem with the way primitive "legacy" EDI works, including the HIPAA standard transactions. But I'm still in the habit of saying "legacy" because you look stupid - or just don't "get it" - if you fail to sneer at EDI in front of Venture Capitalists! Unfortunately, in a message centric system like the HIPAA standard transactions, there's really no "Business Process" evident at the interchange or transaction set level. See the thread entitled "Requirements Gathering - Information Flows", especially my messages from 02-16 and 03-01, at http://www.mail-archive.com/routing%40wedi.org/msg00219.html and http://www.mail-archive.com/[email protected]/msg00283.html, resp.

If a Business Process exists - apparent at the level of interchanges - it's solely that of sending an interchange and expecting a TA1 or 997 in acknowledgement. You can't really say an 835 is expected in response to an 837. I'm going to predict that our use of the CPP will probably exercise very little of the ebXML Business Process stuff.

DeliveryChannels The CPP people may not want to hear requests for supporting non-Internet transport protocols or non-ebXML packaging techniques (e.g., EDIINT) - I've kind of lost track of what's happening over there in OASIS, ever since the onset of the "SHALL" - "MAY" battles. If they aren't amenable to expanding the CPP, we just may have to go "off on another tangent and re-create something else" - something more like IBM's tpaML which was the progenitor of ebXML CPP - see http://www.ibm.com/developerworks/library/tpaml.html.

I've "volunteered" Tim Collins to look into discovering the tons of permutations "on a multitude of media, protocols, etc...", - including the ugly stuff like modem settings and initialization strings, blah, blah, blah. All that will have to be mechanically represented in some type of XML file (or the 838) - or as an extension of the CPP DeliveryChannel.

In that spirit, and in line with my e-mail yesterday, perhaps we should start enumerating the various protocols that providers and payers are likely to use (for describing EDI addresses in the "directory"). I would be inclined to ignore the various legacy dial-up techniques, but others may not be so inclined. And, obviously, someone who uses expensive point-to-point leased lines doesn't need a "directory" because they're already connected to the other party!

I would like to start off by suggesting simple old e-mail using S/MIME attachments. It's bi-directional, and everyone can use it today - at least as long as they're using standard e-mail clients like Outlook, Outlook Express or Netscape Communicator - but not the non-standard AOL play toy. The Microsoft-haters who use UNIX may have trouble with standard ITU X.509 certificates, so we'll have to accommodate PGP security. We should also provide for zipping (compressing) the EDI before encryption, too. This minimalist technique accommodates both the "disenfranchised" and the BIG PAYER (who can presumably automate his side of things in a lights-out fashion). I can even see the little "disenfranchised" doctor - the one who does his own electrical work - cobbling together scripts to automate his e-mail client to do this, in addition to coding up his own Javascript to build 837s and 270s (or to parse 835s and 271s)! I would add EDIINT into the mix, both the AS1 (SMTP e-mail) and AS2 (HTTP) varieties; the software is somewhat available, though probably not affordable, for the "little" person. And FTP, too, even though the "little" person might not have his own FTP server: he may have to poll drop-boxes if he insists on using FTP on the receive side. I would also leave a placeholder for ebXML Messaging Services, because that's the "Next Big Thing" - and software vendors are falling all over each other to provide practically free messaging service handlers (MSH). The ebXML Messaging Specifications provide for a SOAP based packaging of business payloads for direct point-to-point transfer over the Internet - one of many packaging techniques that will have to be supported in the WEDi/SNIP ID & Routing Specifications. Unfortunately, I would be remiss if I didn't say it would take quite a while for ebXML Messaging Services to catch on. Even though it can accommodate X12 EDI payloads, I doubt seriously that there will be many implementations of ebXML MS within Healthcare in the next couple of years, as new software would have to be interjected into the software mix at both ends of the trading relationship. We can expect Healthcare Clearinghouses and the more prosaic forms of point-to-point transmissions (e.g., FTP, Kermit) to predominate in the short term, and our "EDI Addresses" must support these "legacy" transport channels. Providers or their agents need to meet the payers half way. If the payers make it clear in the CPP where a particular transaction is supposed to be sent (and keep it updated), it is only fair that the providers follow the bread crumbs and send transactions where the payers tell them to.

Ken has expressed one of the key reasons why different addresses for different transactions are needed in the CPP -- in today's business environment all of the transactions don't even go to the same place. In my email earlier this week I indicated that there appear to be only 2 pieces of information that are consistent throughout all of the insurance card copies I have reviewed so far - and those are different addresses for claims and eligibility inquiries. Often, the agent that responds to eligibility is not even the same corporate entity as the payer. In fact, sending eligibility inquiries to payers for certain plans wouldn't work in any event, because if they are only providing the insurance shell and claims processing for a self-insured employer, the payer may not even know where the appropriate eligibility granting entity is... In fact, in that case, I would expect that the agency that actually produces the insurance card (in this case, the plan administrator) would be the entity that files the DNS & CPP entries.

So, bottom line, the CPP can and needs to be specific as to what transactions go where, and the providers or their agents need to be at least sophisticated enough to pick up the addresses and send things to the right place.

We've discussed selecting alternate Delivery Channels based on functional group (e.g., "real-time" 270 vs 837 batch), but I didn't think Plan ID was ever considered as a selection criteria. That wouldn't be impossible, I suppose. But consider the implications for a VAN or other intermediary who would have no idea what Plan ID applied to the transaction without drilling into the transaction set and looking at application segments like the SBR in the 837. Besides, an 837 would contain claims for multiple plans to be processed by a single payer or TPA. I would suggest that we stay away from criteria for selecting Delivery Channels which can only be obtained from the guts of the application transaction set - or which could very well be non-unique within an interchange.

Should we even waste time defining Delivery Channels (EDI Addresses) to accommodate non-IP protocols? IP is going to take over the world, anyway. See Michael C. Rawlins' exposé on ebXML, concluding with "ebXML - The Road Ahead," at http://www.rawlinsecconsulting.com/ebXML/. In it, Mike says:

"...IP was deliberately not specified because the TRP team wanted to promote an open, 'protocol neutral' solution. But, at the very basic level you can't achieve interoperability if you speak different network protocols. This is an almost pathological pursuit of openness over interoperability. That we didn't specify IP over the public Internet should be an embarrassment to all of us who participated. UN/CEFACT and OASIS need to bite the bullet and take a stand on this.

"If we care at all about interoperability, I see no excuse for failing to specify some subset of HTTP, SMTP, and FTP as the approved protocols. Only two would be best, but I could live with all three so long as some comprehensive, coherent recommendations were made about appropriate uses of the three. Again, we don't achieve interoperability if my application talks ebXML over CORBA IIOP, and yours talks IBM's MQ Series or RPCs a la RFC 1831. Even more to the point, SMEs and vendors of SME software need some reasonable guidance about whether to support HTTP, SMTP, or FTP, since cost-wise it may not be realistic to ask them to support all three."

I haven't heard any articulation on this list thus far giving the minimum set of protocols and packaging techniques we should accommodate in our Healthcare CPP (Electronic Partner Profile). There are all sorts of junk out there like dial-up Kermit, but is it fair to the authors of the "Addresses and delivery channels" working paper (Dave Minch, Tim Collins, and Dick Brooks) to speculate on what's actually used if nobody takes the trouble to inform them of their requirements?

Hearing none, I would say we can safely concentrate on IP protocols like FTP, SMTP and HTTP. The other "legacy" techniques could be accommodated by some provision in the CPP Delivery Channel for describing them in a textual format.

I made a concession towards proprietary IDs using the ZZ ISA Qualifier: perhaps the CPP could specify an ID and qualifier (including a ZZ mutually defined ID) to be placed in the ISA Receiver field if a particular EDI Address (Delivery Channel) is selected. But no proprietary IDs could be used to search the Healthcare CPP Registry, nor is there a way to compel a sender to identify himself with a proprietary ID.

HIPAA may well open the way for providers who haven't heretofore submitted electronic claims to "discover" the CPPs (electronic Trading Partner Profiles) of payers - which include EDI Addresses and perhaps even machine readable "companion" documents. This is as close to open-EDI as we'll probably see in the near term. Because of the standardized implementation guides and code sets, it's conceivable that partners could commence exchanging healthcare administrative standard transaction sets with no (or minimal) bi-lateral agreement. The HIPAA Implementation Guides really don't provide that much latitude for "customization" - the clear intent (of Congress) is that every healthcare player in the U.S. do the same thing consistently in order to avoid that very "customization" which induces friction any time B2B interoperability is attempted.

I don't think the ISA and GS sender IDs can be used for selecting Delivery Channels for the simple reason it would be cumbersome to enumerate every possible trading partner in the CPP. And besides, you may not even know ahead of time who your trading partners will be! I want our recommendations to exclude any unnecessary artifacts which give payers an excuse to require providers to endure a cumbersome EDI enrollment process.

But, anyway, I digress: the thing that made the biggest impression on me was that NEHEN participants rely on a single means of communicating with one another, viz. direct socket-to-socket TCP/IP network transmission. Eliminating communications options vastly simplifies things. This is obviously easier to do on a semi-proprietary network between a few big players who can afford special software.

Peter Barry has suggested before that we need to specify "addresses" in "three arenas": "dial-up (easy), Internet (easy), and private network (not so easy)." He went on to describe the attributes of an address, including "questions of media, packaging, security, and communications capabilities. For example, a given address might have attributes to say dial-in/login-script-X/security-A/ASCII-file-no-label/filename-path-sche me-3, or something like that. Another might say Internet/security-B/ebXML-scheme-1/etc."

What scares me if we don't limit the communications protocol possibilities, is that we could end up with a spiraling list of permutations. How do you describe - in a mechanical fashion - something like "use Kermit over a direct dial-up connection to 8005551212"? Do you also have to describe the modem mumbo-jumbo of 7-bit vs 8-bit and even or odd parity? I vaguely recall that was the junk you had to worry about when using pre-Internet BBSs or Compuserve.

Now that there's the Internet, I set my modem and dial-up connection once, as specified by my ISP, and have forgotten about it, thankfully. I now have a single digital dial-tone, which works for e-mail (secure or insecure), file uploads and downloads, and surfing the Web. And when I start getting fancy, like doing web services using SOAP, it's still the same dial-tone: never again will I have to fuss with a modem unless I change my entry ramp to the Information super-highway (moving to DSL or cable, or changing ISPs). I hate modems and I hate printers.

Even Kepa hinted at all the possibilities his DNS "directory" will have to handle, using examples like 8005551212.phone.hipaa.net and kermit.8005551212.phone.hipaa.net, adding nonchalantly "[the] sky is the limit. As long as we have some standard way to name them. We may need to 'create' such a standard." That's exactly what I'm afraid of! Let's assume for now that we'll be forced into supporting all the "legacy" dial-up connection types - to assuage fears of the open Internet's security "problems," what with some means of describing scripts, logins, passwords, modem-settings, etc. etc. Then does anyone know of any OASIS, W3C, IETF, etc. effort for devising XML files to describe all communication capabilities of a partner? The ebXML Collaboration Protocol Profile (CPP) specification only supports the common internet protocols (and then, only if ebXML Messaging services is used for packaging payloads - which could include HIPAA EDI). I want to see something that says "this is a dial-up using Kermit with this phone number." Surely someone has devised a schema for describing communication capabilities. There's no sense in us reinventing the wheel.

Versioning that for most/many trading partners accessing such a registry/repository doesn't necessarily have to be a dynamic task performed each time an interchange is created. Rather, it might be necessary to access such a registry/repository once or intermittently in order to obtain the needed information for addressing/routing. Of course, this assumes that the addressing/routing information is more static than volatile. But, my gut tells me that it will be more static rather than volatile....at least during the early months/years of HIPAA EDI deployment I agree that it would not seem to be necessary to check the repository info. very often. I was thinking, however, of including a "version indicator" field somewhere (maybe just Active/Inactive flag, version date, etc.) in the repository and possibly retaining several "expired" repository versions in case the owner needed to roll back to or look at one of them. But if the receiver wasn't yelling at the sender about something going to the wrong portal and/or transactions were not being rejected, then would there even be a reason for a sender to recheck this?

The other thing that occurred to me (I have approx. zero operational experience with EDI.. so please bear with me!) is that commercial translator systems must have some sort of configuration template/database into which the prospective user will have to key all/most of this repository data... sort of his local "EDI Address Book". Should we be talking to translator vendors about how this info is managed locally by the interchange senders? The obvious advantage of aligning our repository structure with a standard local user's "address book" would be auto-updating ability. What you're referring to is the trading partner profile management function that most good commercial EDI management systems provide. Some provide more or less functionality than others.

Security Should public encryption keys be available in this template?

IMO, yes. Along with other items needed to enable E-Commerce (e.g. self signed certificates for SSL, public keys for encryption, public keys for digital signature verification, Certificate Revocation List information).

CPA I described the CPA as being "... in the realm of science fiction. Theoretically, a provider would introduce himself to the payer with his CPP, saying he wanted to send claims electronically. Software at either end would electronically negotiate terms, resulting in a CPA which binds the provider and payer in a bi-lateral trading relationship."

The CPP's chief value appears to lie in the ability to use it to automatically negotiate the CPA, after which the two trading partners [previously unknown to each other] could launch right into a supported TRANSACTION. Clearly, this completely automatic model won't work in healthcare "out of the box", as you say. believe there should be certain information that should only be released until both parties can establish some level of trust. I presume a large majority of trading partners will require some form of testing, so all the testing information could be released without many of the concerns regarding live data.

Once a valid test is completed, then it's possible that credentials could be passed to the partner that will provide them information regarding submitting live data. And in between the testing and live data submission, processes could be performed to verify the validity of the business entity, thereby giving the receiver and sender some level of trust regarding the transactions.

I saw a thread recently that covered some method of establishing a certificate based, trust relationship, that may help address this as well. Using a PKI or PGP model, the ability to obtain information on sending live data could be based on an entities ability to pass the testing phase. A certificate or key would then be given to them that would allow them to obtain the live data submission information.

At first I thought this could be out of scope for the group, but then I realized we haven't created a strong enough definition of the overall business processes in use today. I'm sure most receiver's will require some form of testing, or some form of trusted certification that they are compliant before simply allowing data to be sent.

So, the CPP must have the ability to define testing criteria and requirements. Then, it should allow define the conditions in which testing be by-passed if the sending party already has been certified by so many other receivers.

I have not been too concerned with CPAs heretofore. CPAs, or Collaboration Protocol Agreements, are in the realm of science fiction. Theoretically, a provider would introduce himself to the payer with his CPP, saying he wanted to send claims electronically. Software at either end would electronically negotiate terms, resulting in a CPA which binds the provider and payer in a bi-lateral trading relationship. I suppose this is where Doug Renshaw could vet the provider, and give the provider a user ID, password and proprietary provider ID - all automatically in a matter of seconds. I'm not holding my breath waiting for this to happen, though! Wouldn't it be much simpler for Doug to describe, in his own CPP, an open portal for sending standard transactions to Highmark?

Repository The repository is the actual record of connectivity requirements and other information that is needed to set up a trading relationship. Some of our repository elements may be unique to healthcare or refer to a unique requirement of HIPAA, but most will be data elements commonly required by any 2 entities wishing to establish electronic data exchange.

The key points about the repository: 1. It is essentially one collection of data about one trading partner's requirements, although it may be compartmentalized and it may be spread over several linked "documents" or URLs 2. The repository remains under the direct control of the trading partner to whom it refers (the "owner") 3. There is only one copy of the repository in existence 4. Each TP can decide what parts of his/her repository are exposed to whom 5. The repository can have any physical or logical location that is acceptable to the owner

3. There is only one copy... -- this probably isn't needed as a statement in the requirements, because it would tend to limit one's flexibility to post a primary & alternate address (which can be provided for in the registry), or for a Plan to contract with a CH to use their repository to post a second copy. From a conceptual point of view, of course, you are correct that the CPP itself isn't distributed across several repositories.

2. The repository remains under the direct control of the trading partner to whom it refers ("the owner"). This statement would also tend to exclude Business Associate relationships -- e.g. where an entity wants to contract with a third party to use their services which may include posting a CPP for them. I would add the term "or their contracted agent" at the end of the sentence just to keep that door open.

The Healthcare Registry The attributes and addresses in the CPP will exist someplace. Everyone seems to forget that. If they exist in every participant for every trading partner--that's a whole lot of maintenance. Very expensive, very error prone, and discriminatory of the smaller players. Much better that each participant can maintain its own information, publicly posted, such that one change communicates to every trading partner.

But outfits are always merging and acquiring - and our registry and Electronic Partner Profiles (CPP) can easily accommodate these eventualities. There's really no need for cutover dates (at the routing level), since the obsoleted ID can still be searched on to either (1) produce a dummy CPP which in turn points to the surviving entity's CPP, or (2) retrieve the surviving entity's CPP directly (which contains the obsoleted ID as a non-preferred search key).

I don't recall that we have ever had a discussion on "the merits and demerits of using UDDI." Every time I've mentioned some kind of "directory," whether Kepa's DNS "directory" (always in quotes 'cause we've never given it a name) or the ebXML Registry, I have always included UDDI in the mix.

I remarked to the OASIS ebXML Registry TC that I had some reservations about UDDI's security: "Though UDDI remains a possibility for discovering business partners' technical capabilities, its security (or lack thereof) makes it somewhat problematical." That's the only slightly pejorative statement I've ever made with respect to UDDI. See http://lists.oasis-open.org/archives/regrep/200203/msg00038.html.

I have since been reassured by a correspondent that he "...can only assume that you are referring to UDDI V1 and V2. The UDDI V3 specifications due to be completed in the next few months will introduce more robust authentication, allow for authorization, and provide support for digital signatures. I would be happy to provide more details as needed. The discovery requirements that you have listed are exactly what UDDI is designed to do."

As I said in my e-mail to the OASIS ebXML Registry TC, pretty much all we want to do is store "pointers" to participants' CPPs (which reside as XML files in their own servers), retrievable by one or more entity IDs. For example, a Big Payer may well choose to be identified by their NAIC company code. Providers, on the other hand, like hospitals, may prefer to name themselves by any of a HIN, a D-U-N-S or a Federal Tax ID. Likewise, a small practice may be identified solely by Tax ID, at least until the National Provider ID is available.

Even if a small provider doesn't do standard HIPAA X12 transactions himself (but rather uses a Clearinghouse or Billing service), he would still have an entry in the Registry with a vestigial CPP (probably resident in the ebXML Registry itself) which points to his respective agent (e.g., via the ID of the clearinghouse or billing agent).

When the National Plan ID does comes into play, we would have multiple levels of indirection in the retrieval: the plan ID would be used to retrieve a pointer to the payer or Third Party Administrator (TPA), which in turn would be used to access that entity's CPP for technical trading partner information. Implementing search by Plan ID might be more efficacious with the ebXML Registry rather than with Kepa's DNS directory.

This should be a very simple use of the ebXML registry, and it allows us to get some experience in the best ways to identify partners. We need to get away from proprietary payer-assigned provider IDs in the context of standard transactions, so as to level the playing field between payers, providers and clearinghouses. The registry will also be a test-bed for experimenting with various means of authenticating partners (using X.509 certificates). It might be too much to expect Dick Brooks to do the liaisoning with both the OASIS ebXML Messaging and the Registry Technical Committees. Does anyone here want to volunteer to develop Registry use cases involving the discovery of WEDI/SNIP CPPs? It would be much more appropriate for a "real" health care person to take on this role: someone from either the payer, provider, or clearinghouse sectors needs to step up to the bar on this effort if it is to provide anything that will be acceptable to the user base and solve real problems.

It's only fair that the provider advertise her capabilities, just as the payer would. The provider's "directory" entry would say she's willing and able to take 835 electronic Remittance Advices. It could also have a notation that said she was willing to take electronic funds transfer at her bank, specifying an ABA routing code and her account number. Of course, the payer doesn't have to do EFT (even if he does do the 835 ERA), so this is optional on the part of the payer - but paper checks mailed to the billing provider are still always welcome! The registry is a separate database, built to standard specifications, and able to be accessed with a standard query protocol. It's purpose is to link the all the possible identifiers used by a single trading partner with his/her SINGLE repository ADDRESS (generally, a URL). For example, if Company A is known by 10 nationally unique alphanumeric codes or names, then he would probably want to have 10 different registry records, in which each ID code points to the same repository, containing all of his "TPA" information.

Key points about the registry: 1. The registry should conform strictly to an established standard (like ebXML) so that it can be queried automatically using standard protocols. 2. An industry like healthcare can support any number of registries. There might be a slight advantage in having only one registry for healthcare, but it would be almost the same effort to have a system query 3 or 4 or even 20 registries in rapid succession. All we would be looking for in the registry is the URL for the company's SINGLE repository record or record-collection. 3. There is no limit to the number of different identifiers that can be linked in a registry to a single CPP repository. This means that in addition to the identifiers permitted in the ISA, we could list a company's common names and abbreviations (e.g., "Vision Service Plan" or "VSP"), any of the company's National PlanIDs, etc. Some standardization here would be helpful and in general, we would expect the identifiers printed on the subscriber ID card to be the same ones placed in the registry. There is no requirement, however, to restrict the registry pointer IDs to the set of ID codes that are "legal" in the ISA. ISA receiver ID preferences would be spelled out in the CPP repository. 4. A company would be free to list itself in as many registries as it liked. Companies should list the same identifiers in every registry, but the system would still function OK if the different registries were not perfectly synchronized... as long as the repository URL was listed correctly in each record. 5. The registry would be a relatively static, low maintenance database. As long as the listed entity kept the URL of its CPP Repository constant, there would be no need to edit the pointers in the registry. The contents and even the physical location of the repository could be changed whenever necessary (by the owner), but it would only rarely be necessary to edit the registry.

Ownership I don't really think WEDI would agree to maintain a registry for HIPAA covered entities. This is really a full time job. If the Government were going to have the National Provider and Plan ID databases, maybe the CPPs could be pointed to by them. But at this rate, I don't think anyone is going to be seeing NPI and Plan ID databases any time soon!

So if we want a directory of Healthcare CPPs, it's going to have to be either 1) Kepa's DNS directory, (2) the ebXML Registry, or (3) UDDI - probably maintained by an organization that makes a living from this. Frankly, I don't know how you build a business model around directories, but there are enough vendors - and not just your chintzy pre-IPO B2B startups, but real substantial outfits like IBM and Sun - tripping over themselves to provide hosting, registry services and software. This is why, as part of our "liaison" with the OASIS ebXML Registry TC, we're also talking to vendors about an actual implementation. The same thing can be done with UDDI, which Joe McVerry has volunteered to research for the purposes of a Healthcare Registry.

I used to always call this Registry the "WEDI/SNIP" directory, really only to develop a sense of "ownership" among the WEDI/SNIP ID & Routing folks - in no way did I mean the WEDI Board of Directors has ever approved of such an animal or would have WEDI run it. From now on, to avoid confusion, we should just call it the "Healthcare" CPP directory.

Starting with the Patient If we had any "discussion about how information is processed prior to the lookup," it was solely in the context of the provider obtaining the ID of the plan or payer (somehow - perhaps from the insurance card), or the payer using the usually present Tax ID of the provider. We have to make the assumption that some ID is available (to either provider or payer, or their agents) for performing the initial lookup.

Once you have an ID, it should be clear sailing from there, even though multi-stage lookups might have to be performed: e.g., if the provider has the (future) National Plan ID in hand, he can look up the (1) Electronic Partner Profile (CPP) for the plan, which in turn might be nothing but a reference to the (2) Third Party Administrator or insurer's CPP, and finally, the TPA's CPP might reference its (3) Clearinghouse's CPP for the detailed Delivery Channel ("EDI Address") attributes which define the actual transport method and port address.

I hope we don't have to understand, in detail, the "major models of insurance" to describe a workable Registry and CPP system - except in order to illustrate examples of how the thing works, as I just did above (a model based on a self-insured plan handled by a TPA using a Clearinghouse). In that example, we used the Plan ID to arrive at the EDI portal at a CH to send claims or eligibility inquiries. The Plan ID would still presumably appear in the application transaction set, otherwise the TPA - which handles dozens or hundreds of self-insured plans - would not know for whom the claim was intended.

Solving the problem of how to obtain the National Plan ID (or in today's world, the payer and proprietary plan IDs) is out of scope for our project. But it is a real problem, which Chris Feahr confirms. As I indicated in my previous e-mail, it seems to have been solved adequately in the Pharmacy world according to David Feinberg.

There is no doubt that the patient is "the weakest link" in this discovery process. In vision care, when the patient is unsure of the payor/plan, we routinely query one or two of the largest payors with both the patient's and the presumed subscriber's SSN numbers... just because it's easy to do and we often find them listed. An additional source of confusion in identifying plans is the fact that the patient is often more aware of the name of the general medical plan (possibly a closed-panel HMO that we do not belong to). So the patient calls the eye doctor and states that she has a "vision plan" through "HealthNet". We know that our office is not a member of the HealthNet provider panel, but... avter investigation by my staff, the "vision plan" turns out to be Vision Service Plan (VSP), meaning that re really CAN see the patient after all.

The ONLY reliable info that you can get from the patient is WHO THE PATIENT IS! A central patient plan-membership registry would be VERY helpful. Otherwise, payors will want to essentially "SPAM" every payor in the world with general "type 30" eligibility queries until they get a "hit". The provider is in a tough spot here because many of these "unknown payor" cases can be served in his office, but a few can ONLY be served under the plan in an different office. Patients expect the doctor to magically resolve this at the reception desk... before the services are rendered. A good receptionist might remember that we have seen lots of folks from that particular employer and "worry about who the payor is" later (so as not to waste the appointment)... but occasionally, we get stung and the patient is NEVER happy about having to pay for a bunch of things that were supposed to be "free".

Searching and "Discovery" But after thinking about it, maybe we will need to employ ebXML's robust query technology: if there's nothing in the application transaction set (e.g., the 270 or 837) that definitively gives the provider's "return" EDI identifier, then perhaps the payer could use the ebXML Registry to search on known identifiers (such as the TIN) to indirectly find the provider's CPP, which in turn would have the preferred EDI identifier (say, the D-U-N-S). But until then, we're still left with problem of how a payer determines the type (D-U-N-S, FEIN or HIN) and value of the ISA receiver ID for a provider. Some of the more recent discussion has suggested taking an identifier the provider is known by to the payer (e.g., the FEIN), and using that ID to search the Registry for the provider's CPP, which in turn contains the provider's preferred ISA ID (and that preferred ID may be the FEIN itself, or another Tax ID, or one of the provider's D-U-N-S numbers). Keep in mind that if the Registry is powerful enough to be searched by any (non-proprietary) ID, then the sender could just blindly stick the FEIN in the ISA receiver ID, knowing full well that a VAN or CH intermediary could search the Registry for the CPP which contains the EDI addresses and ports. The whole concept of a "preferred" ID may give way to a more powerful notion whereby a receiver can be identified in the ISA by any of its known IDs (whose domains or type are allowed by the HIPAA IG). Regarding the discovery of the preferred "return path" to the small provider, a payor could take the provider's FEIN from the individual transaction (a 270, for example) and look up that provider's CPP... and determine [for example] that he likes all his 271s sent to a CH maintained by his OMS vendor, and his 835s sent to his bank.

if we don't have a consistent way of addressing partners (based on IDs), there's really no good way to do anything else, such as the lookup of partners' information in a directory. And it's that directory (whether a DNS lookup, ebXML Registry or UDDI) that contains the CPP which has all the good stuff for automatic trading partner hook-up.

The solution has already been modeled: I'm suggesting - not the first time, certainly - that a requirement of our specifications include the ability to search the Healthcare Registry by any number and type of identifiers. The illustration showed one possible means of how, in this case, the Blue Cross Blue Shield Plan Code could be described and used to locate the CPP (electronic Partner Profile) for the a particular Blue entity (Anthem).

The BC/BS Plan code(s), along with any number of Tax IDs, D-U-N-S, NAIC Company Codes, etc., etc., seem to be all perfectly acceptable keys to use for arriving at (or "discovering") the same CPP - part of a general requirement that has nothing to do with being "wedded" to any particular type of identifier. We have not yet discussed how identifiers would be qualified as search keys, and I was suggesting one possible means based on X12 coded element qualifiers - in order to avoid re-inventing the wheel. Other methods might involve the use of URNs (IETF Uniform Resource Names), but that's getting a little afield for the time being.

To allay Ken Fody's concerns that "not all Plans want to use [the BCBS plan code] on the standard transactions," let me emphasize that the example showed "discovery" of Anthem's CPP based on any one of its plan codes. Once the CPP is found, the junk inside the CPP would say where to deliver transactions (the Delivery Channel) and the ISA receiver qualifier and code to use. If Anthem were to prefer to have its NAIC company code used as the Receiver ID, that's perfectly possible with the requirements I've previously suggested in "Why do we flap our lips so much about the ISA Receiver ID?," from 12 April, at http://www.mail-archive.com/routing%40wedi.org/msg00438.html.

I have a tendency to write in prose, as if describing a system that already works - when in fact we all know we haven't written the specs yet! But I fancy that I'm setting forth the "Grand Vision," and (preferably) someone else is busy compiling my musings as a set of requirements within the respective Working Paper groups. Is it working? I'm not trying to shove anything down anyone's throat, but y'know: searching on various identifiers to "discover" CPPs does seem to be something people can use - and the ebXML Registry already supports this. A correspondent has confirmed that the most powerful ID for identifying BC/BS entities is the Plan Code. He said it was used in several inter-plan claims exchange systems and is universally used by all Blue plans on membership cards. Which is true enough, considering my own Anthem card shows plan codes of 332/834 (Institutional vs. Professional) on the front.

Now it seems reasonable that my doctor ("shorthand" for saying his staff, software, billing agent or Clearinghouse - let's not get pedantic here) could take the "834" and look up Anthem's electronic Partner Profile (CPP) in the Healthcare Registry to see where to send claims or eligibility inquiries.

Obviously, "834" by itself doesn't mean much - it has to be qualified by some code to say that it is a Blue Cross Blue Shield Association Plan Code (in both the CPP and the Registry search key). The first place to look for such qualifiers would be the X12 ISA Interchange ID Qualifier - even though the BC/BS Plan Code is obviously not a HIPAA compliant ISA receiver ID. Such an animal doesn't appear there, but D.E. 66 - Identification Code Qualifier - used in the NM1 does have code value AD meaning "Blue Cross Blue Shield Association Plan Code."

So the Registry search key could be shown (stylized) as something like 66:AD:834 (meaning D.E. 66 code value AD qualifies value 834) which could be used to locate Anthem's CPP (assuming Anthem placed a list of all their associated plan codes in their CPP: 160 and 660 for Kentucky, 130 and 630 for Indiana, and 332 and 834 for Ohio). There's no reason the Healthcare CPP parts which specify Delivery Channels could not account for all plans using the same or different EDI portals, depending on Anthem's preferences. I'll leave the details for defining this stuff in the CPP to the volunteers who are authoring the "Elements of the Healthcare CPP" working paper (Marcelee Jackson, Dave Minch, Dick Brooks and Chris Feahr).

I would also add an additional concept/idea that surfaced this week during discussions at X12 in Minneapolis, i.e., that for most/many trading partners accessing such a registry/repository doesn't necessarily have to be a dynamic task performed each time an interchange is created. Rather, it might be necessary to access such a registry/repository once or intermittently in order to obtain the needed information for addressing/routing. Of course, this assumes that the addressing/routing information is more static than volatile. But, my gut tells me that it will be more static rather than volatile....at least during the early months/years of HIPAA EDI deployment.

Folks did seem to doubt that anything as ambitious as our Healthcare directory and electronic Trading Partner profile could be available by the time H-day rolls around. I emphasized that the registry and electronic profiles will be usable in a manual fashion, where CPPs can be viewed with XSLT style sheets. Most of the value of the registry is just in the ability to locate trading partners' profiles - we don't need to wait for software vendors to update their software for completely automating the "Discovery" process.

We've been assuming all along that providers would have no problem "identifying" payers and plans, figuring that each patient carries his insurance card around with him (and that the cards would have the EDI identifier printed on them). But we've been disabused of that notion by comments at the meeting - either patients don't have their insurance cards 30% of the time, or the information that the provider has on file for them is woefully out of date. Pharmacy, according to David Feinberg, maintains a centralized database to solve this problem: apparently, insurance companies load demographic information about their covered subscribers at some clearinghouse for shared access by pharmacies.

Of course, this isn't the problem we're trying to solve (of patients not carrying their insurance card). We can make the assumption that the provider has some means of determining some ID of the plan or payer applicable to the particular patient. But to help things along, we may want to add searching by payer name as a requirement - to accommodate the situation where the patient knows the name of his plan or insurance company: refined searches in the registry can locate the actual CPP covering the plan to which eligibility inquiries can be sent.

Actually, the ISA receiver ID would generally *not* be the key into the Healthcare CPP (Electronic Trading Partner Profile) Registry, for the simple reason you would not know what to use as the ISA Receiver ID until you had obtained the CPP for the recipient - which in turn tells you which ID to use!

Imagine this scenario: a provider wants to send a claim to Big Insurance Co. She knows *some* payer ID either by (1) serendipity, e.g., she remembers the NAIC for Big Insurance Co., or (2) obtaining it indirectly through the particular National Plan ID (*future* - remember National Plan ID hasn't yet been implemented or funded) which appears on the patient's insurance card, or (3) obtaining the EDI ID (in this case, the NAIC) directly from the insurance card.

Either the NAIC company code or the National Plan ID could be used to search the Healthcare CPP Registry (notice I no longer call it the "WEDi/SNIP" Registry!) to obtain Big Insurance Co.'s CPP. The CPP then contains the EDI Addresses to be used (depending on criteria such as Functional Group ID) and the EDI ID to be used in the ISA Receiver field (in this case, Big Insurance Co. prefers - or mandates - the NAIC). The provider must use the Receiver ID specified in the CPP, because the EDI Address to which the interchange is sent could very well be a VAN or Clearinghouse that only knows the payer by the NAIC.

Or perhaps the Clearinghouse only knows the payer by some *contrived* (CH-assigned) receiver ID - neither the NAIC nor the HCFA carrier code or any other standard ID. In this case, the selected EDI Address in the CPP would say which qualifier and ID to use in the ISA receiver field (and it could be a ZZ "mutually-defined" ID). I want to emphasize I am not back-peddling on my abhorrence of the ZZ here: the "mutually defined" ID is not being used as a *key* into the Healthcare CPP Registry (it can't be, because the provider wouldn't know it ahead of time). The EDI Address in the CPP is simply saying the provider has to stick in this qualifier (ZZ) and an arbitrary receiver ID into the ISA before sending the interchange.

It works the same way when the payer wants to send an application message to the provider. And remember, standard transactions from the payer can be unsolicited: paper claims could result in electronic 835 EOBs! The payer might only have the FEIN (Tax ID) of the provider available. He uses the FEIN to search the Healthcare CPP Registry to locate the provider's CPP. The provider has said she accepts 835 EOBs at a particular EDI Address. Perhaps she is to be identified in the ISA receiver ID with her D-U-N-S, with a specification in the EDI Address that says the transaction set must be encrypted using X12.58 and sent through a VAN (since VANs are not covered entities generally, PHI has to be hidden from them using encryption). This illustrates the situation where a FEIN is used as a key into the Healthcare CPP Registry, but the D-U-N-S is the ISA Receiver ID. Again, the ISA Receiver ID was not used as the key - it wasn't even known until the CPP was obtained!

Or maybe the provider uses a Clearinghouse, and her CPP EDI Address has said 835 EOBs (or even all transactions) go to the Clearinghouse, using a CH-assigned ID in the receiver field. In this case, a FEIN was used as the key into the CPP Registry, but the ISA receiver ID is a ZZ-qualified CH-assigned provider ID. Since the provider is a customer of the CH, she knows ahead of time what her proprietary CH-assigned receiver ID is, and can place it in the EDI Address so senders know what to use in the ISA.

If it seems I'm softening on the ZZ qualifier, I'm not. Consider the first scenario again, where the provider has "discovered" Big Insurance Co. in the CPP Registry. In this case, the EDI Address for claims says to send the 837 to a clearinghouse. It's perfectly okay for Big Insurance Co. to say in the EDI Address within its own CPP that a ZZ qualified receiver ID be used in the ISA - after all, Big Insurance Co. is a customer of the Clearinghouse and has long known its contrived CH-assigned payer ID. But there is no way to tell the provider she must use a CH-assigned sender ID - she's not even a customer of the Clearinghouse, and this may be the first time she's ever sent anything through that Clearinghouse. It would be mighty presumptuous of the CH to insist that the non-customer provider identify herself by a proprietary CH-assigned provider ID - as if it could even be done technically.

Chris Feahr brought up the possibility of VANs and CHs sharing their "family jewels" - their directories. That's unlikely: the best we can hope for is for them to populate our directory with their payers, with pointers into themselves! But I would think it very improbable that CHs would give away the names and IDs of the providers they service. Visibility Yes, I was disappointed at the reticence of most of Claredi's directory participants to share their information. Most of it's locked down and available only to other members of their trading "group." Obviously, the main purpose of the Claredi directory is to share information on certification progress: perhaps folks are humbled that they are not further along in achieving compliance, and don't want the rest of the world to know! I guess that's only natural.

In any case, as Chris notes, the same "shyness" will affect our Healthcare CPP Registry. If people are not too keen on even publicizing their address and phone number, they probably won't give away to just anyone as to how to send transactions their way. Even though I'm absolutely confident we can come up with technological solutions to expose information only to others in certain categories, that still will not get people over their agoraphobia. This is a social engineering problem that mere technology will not solve.

On the positive side, clearinghouses are always anxious to advertise the payers they support - I suppose that's a selling point to providers. So at least CHs will probably be happy to prime the pump with payer CPPs - which will naturally point to portals at those very same clearinghouses!

Keep in mind that the CPP (electronic partner profile) is really not dependent on a global, public federated registry. These are just standardized XML documents with machine readable information that describe the partner's capabilities: certification, financial institution data and EDI addresses, inter alia. The CPP doesn't have to reside in a public directory. A payer could continue to do business the old way, where a provider has to fill out all sorts of paperwork, sign TPAs, endure hideous EDI enrollment delays and whatnot. And at the end of all this, he'd be e-mailed - what else? - a nice CPP!

If payers were the least bit reticent about sharing their companion guide information on the Internet as part of the WEDi/SNIP CPP (Electronic Trading Partner Profile), that would put a crimp in our efforts to automate "discovery" of trading partners and their technical requirements. Can anyone enlighten me as to what one might consider "confidential" in a companion guide? And if such proprietary information exists in there, is there the possibility that it, ....well, has no business being there in the first place?

Proof of Concept

Registry Thanks to Lisa Carnahan for tracking the list, and especially for writing in! There's certainly no need for me to speak up, because Lisa hasn't mis-characterized anything we've talked about! But as you know, I'm not one to resist writing in. Indeed, we're thrilled to have NIST take an interest in our modest effort to design a Healthcare CPP Electronic Partner Profile Registry, and I join Rachel in enthusiastically welcoming NIST as an active partner in the WEDI/SNIP ID & Routing Group. I want to add that NIST - the National Institute of Standards and Technology (part of the U.S. Commerce Department) - will find that Healthcare administration has perhaps more interesting needs than other verticals, simply because we have so many possible identifiers which would be used to key into the registry. This should make a prototype of the Healthcare CPP Registry a more valuable testbed for evaluating capabilities in the real world.

A number of Registry vendors have graciously offered their products and services in assisting us in developing a prototype. But I think having NIST help us in conducting a field trial adds a panache of integrity and objectivity to our evaluation. And it goes without saying that if we can pull off a successful prototype together, having the NIST imprimatur will go a long ways toward influencing WEDI/SNIP and AFEHCT - to say nothing of CMS - to formally adopt our recommendations.

CPP don't want to get people too concerned that they're going to have to wait for "smarter" auto-reconfigurable software before they'll get to see the benefits of electronic Trading Partner Agreements. As a proof of concept, I see us developing XSLT style-sheets for displaying e-TPAs that have been "discovered" via Kepa's DNS "directory." Since it's starting to look like our e-TPAs are probably going to be XML documents, XSLT style-sheets can render them in a human readable fashion on your web browser. In my crystal ball, I predict we'll have some "volunteers" develop these XSLT style-sheets for contribution as non-normative material for our work product.

All the standard trading partner setup information you'll need - including communications protocols, URLs, EDI contact addresses, "companion" document information (e.g., explanation of situational elements), supported transactions, security and acknowledgement requirements, etc. - will be available simply by providing an identifier (like a NAIC or DUNS) of your trading partner. So even if you have to copy and paste information from your web browser into your existing communication and translation software, it will sure beat paper documentation! And it will be in a consistent format, regardless of trading partner.

In short, you don't really have to wait around for Dick's "next-generation" auto-configurable ebXML software before you start to see the benefits of the WEDi/SNIP e-TPA!

Load more

  85

Copy Link